How I reduced typography debt with semantic tokens có gì mới?
Trong quá trình phát triển dự án thương mại điện tử SaaS, việc quản lý và tổ chức kiểu chữ đóng vai trò quan trọng trong việc duy trì tính nhất quán và hiệu quả thiết kế. Bài viết chia sẻ kinh nghiệm cá nhân về cách tác giả đã sử dụng kiến trúc token hai lớp kết hợp với các chế độ trong Figma để tái cấu trúc hệ thống typography. Phương pháp này giúp giảm thiểu nợ kỹ thuật liên quan đến kiểu chữ, đồng thời cải thiện khả năng mở rộng và bảo trì giao diện người dùng. Qua đó, người đọc có thể hiểu rõ hơn về cách áp dụng các công cụ thiết kế hiện đại nhằm tối ưu hóa quy trình làm việc.

Insight Summary
Tóm tắt nhanh
- Bài viết nói về cách tác giả sắp xếp lại hệ thống chữ trong sản phẩm để dễ quản lý hơn.
- Vấn đề cũ là quá nhiều kiểu chữ rời rạc, khó sửa khi cần đổi font hoặc đổi thương hiệu.
- Cách làm mới là tách chữ thành 2 lớp: phần “gốc” và phần “ý nghĩa sử dụng”.
- Tác giả còn đặt tên theo số, dùng vài mức độ đậm nhạt và độ giãn dòng cố định để dễ mở rộng.
- Kết quả là thiết kế và lập trình đều đỡ phải sửa tay, hệ thống gọn hơn và ít lỗi hơn.
Bài viết tổng hợp
Trong bài viết này, tác giả chia sẻ kinh nghiệm dọn lại hệ thống chữ trong một ứng dụng SaaS cho thương mại điện tử. Nghe có vẻ rất kỹ thuật, nhưng ý chính khá đơn giản: khi một hệ thống chữ phát triển lâu ngày, nó dễ bị rối, khó sửa và dễ phát sinh lỗi. Tác giả gọi đó là “nợ kỹ thuật” trong phần typography, tức là những cách tổ chức chưa tốt từ trước khiến về sau tốn công xử lý. Ban đầu, nhóm của tác giả dùng khoảng bảy kiểu chữ riêng lẻ, như tiêu đề lớn, tiêu đề nhỏ, chữ thường cỡ vừa, cỡ nhỏ, đậm hoặc không đậm. Cách này vẫn chạy được trong thời gian đầu, nhưng càng về sau càng khó kiểm soát. Chỉ cần đổi một font chữ, đổi độ đậm, hoặc làm lại bộ nhận diện, nhóm phải sửa rất nhiều chỗ bằng tay. Điểm quan trọng của bài là tác giả không chỉ “đổi kiểu chữ”, mà là đổi cách tổ chức toàn bộ hệ thống chữ. Thay vì coi mỗi kiểu chữ là một thứ độc lập, họ tách thành hai lớp rõ ràng:
- Lớp gốc: là các giá trị nền, như tên font và độ đậm cơ bản.
- Lớp ý nghĩa: là cách dùng trong giao diện, ví dụ chữ cho tiêu đề, chữ cho nút bấm, chữ cho ghi chú.
Cách nghĩ này giống như xây nhà từ phần khung và phần hoàn thiện. Nếu phần khung được định nghĩa tốt, việc thay màu sơn hay thay nội thất sẽ dễ hơn rất nhiều. Trong thiết kế hệ thống, điều này giúp đội ngũ thay đổi nhanh mà không phải sửa từng chi tiết rời rạc. Tác giả cũng chọn cách đặt tên theo số thay vì đặt tên theo cảm tính. Thay vì chỉ có những tên như “header 1” hay “text m”, họ dùng dãy số như 200, 300, 400, 500. Đây là một cách đánh số theo bậc, giúp sau này thêm một mức mới cũng không phá vỡ toàn bộ hệ thống đặt tên. Một lợi ích rất thực tế của cách đặt tên này là dễ mở rộng. Nếu hôm nay chỉ cần bốn cỡ chữ cơ bản, ngày mai cần thêm một cỡ ở giữa, nhóm chỉ việc thêm một mức mới vào dãy số. Không cần đặt lại tên từ đầu, không làm rối tài liệu, và không khiến cả nhóm phải học lại hệ thống. Tác giả cũng giải quyết phần độ đậm của chữ bằng “Variables Modes” trong Figma.
Nói đơn giản, đây là cách tạo một biến có nhiều trạng thái khác nhau, ví dụ regular, medium, bold. Thay vì tạo riêng từng kiểu như chữ vừa đậm, chữ đậm vừa, chữ đậm hẳn, họ tạo một biến độ đậm chung rồi chuyển chế độ khi cần. Điều này giúp làm việc nhanh hơn vì một thiết kế có thể đổi độ đậm chỉ bằng một lựa chọn, thay vì phải thay cả một bộ kiểu chữ mới. Với người không chuyên, có thể hiểu đây giống như một chiếc công tắc có nhiều nấc, thay vì phải thay cả bóng đèn mỗi lần muốn đổi ánh sáng.
**Một vài vấn đề mà cách làm cũ thường gây ra
** - Sửa một chỗ nhưng quên sửa chỗ khác.
- Cùng một kiểu chữ nhưng mỗi nơi lại lệch đôi chút.
- Khi đổi font, toàn bộ giao diện phải kiểm tra lại rất lâu.
- Tên kiểu chữ không phản ánh rõ mục đích sử dụng.
- Nhóm thiết kế và nhóm lập trình dễ hiểu khác nhau.
Sau phần độ đậm, tác giả nói đến độ cao của dòng chữ. Đây là khoảng cách theo chiều dọc giữa các dòng, ảnh hưởng trực tiếp đến việc đọc có dễ hay không. Nếu dòng quá sát, văn bản sẽ bí và khó nhìn; nếu dòng quá giãn, giao diện sẽ bị loãng. Điểm đáng chú ý là tác giả không dùng các con số lẻ khó chịu như 19.23 pixel. Họ gom lại thành ba mức dễ nhớ: chặt, tiêu chuẩn và thoáng. Chặt dùng cho nội dung ngắn như nút bấm, tiêu chuẩn cho ghi chú và mô tả nhỏ, còn thoáng cho đoạn văn dài để người đọc đỡ mỏi mắt. Cách làm này giúp giao diện vừa đẹp vừa nhất quán. Quan trọng hơn, nó tránh những con số “lưng chừng” gây khó cho cả thiết kế lẫn lập trình. Khi một hệ thống có quy tắc rõ ràng, người làm việc trên đó sẽ ít phải đo đạc lại từng chút một. Bài viết cũng nhấn mạnh việc đưa khoảng cách giữa các đoạn văn vào luôn trong token.
“Token” ở đây có thể hiểu là một biến thiết kế dùng chung cho cả hệ thống, giống như một quy tắc đã được đóng gói sẵn. Nhờ vậy, khi đặt văn bản vào giao diện, khoảng cách đã đi cùng luôn, không cần căn chỉnh thủ công nhiều lần. Điều này đặc biệt hữu ích với các đội làm sản phẩm có nhiều màn hình và nhiều loại nội dung. Nếu mỗi nơi tự canh lề, tự chỉnh khoảng cách, sai số sẽ tích tụ dần. Khi đó giao diện trông có thể vẫn ổn ở từng chỗ, nhưng tổng thể lại thiếu đồng nhất.
Tác giả còn chia sẻ một phần rất thực tế dành cho designer
Thay vì dùng Figma Styles theo cách cũ, họ tạo một bộ component text đã nối sẵn với các biến. Hiểu đơn giản, đây là các mẫu chữ có sẵn cấu hình bên trong, chỉ cần chọn là dùng được. Cách này tiện vì designer không phải “gỡ” style rồi sửa tay từng thông số. Họ có thể đổi font hoặc đổi kiểu chữ và nhận ngay một khối chữ đã được thiết lập sẵn. Điều đó tiết kiệm thời gian khi thiết kế nhiều màn hình, nhiều trạng thái khác nhau của sản phẩm.
Có thể tóm ý của bài theo vài điểm sau
- Hệ thống chữ cũ quá rời rạc nên khó bảo trì.
- Tách thành lớp gốc và lớp ý nghĩa giúp hệ thống rõ ràng hơn.
- Đặt tên theo số giúp việc mở rộng dễ hơn.
- Dùng biến cho độ đậm làm giảm việc tạo quá nhiều kiểu chữ riêng.
- Chuẩn hóa độ cao dòng và khoảng cách đoạn giúp giao diện ổn định hơn.
Bài học lớn nhất ở đây không nằm ở chuyện “dùng công cụ nào”, mà là “tổ chức như thế nào”. Một hệ thống chữ tốt không chỉ để nhìn đẹp hơn, mà còn để cả đội làm việc nhẹ hơn. Khi quy tắc rõ ràng, người thiết kế, người lập trình và người chỉnh sửa nội dung đều đỡ vất vả. Với người không làm thiết kế hay lập trình, câu chuyện này vẫn rất dễ hiểu nếu nhìn theo cách đời thường. Một căn phòng có đồ đạc để đúng chỗ sẽ dễ dọn hơn rất nhiều so với một căn phòng bày lung tung. Hệ thống chữ cũng vậy: càng sớm sắp xếp gọn, về sau càng ít tốn công sửa. Điểm hay của bài là tác giả không chọn giải pháp phức tạp quá mức. Họ chỉ làm những việc cốt lõi: gom lại quy tắc, đặt tên rõ hơn, giới hạn số lựa chọn và để các yếu tố liên quan tự đi cùng nhau. Đó là kiểu tối ưu âm thầm nhưng rất hữu ích trong công việc sản phẩm.
Vì sao nên đọc các bài tóm tắt trên Insight
Insight giúp bạn nắm ý chính của những bài dài chỉ trong vài phút, thay vì phải đọc hết toàn bộ bài gốc. Với các chủ đề như thiết kế, sản phẩm hay công nghệ, điều quan trọng nhất thường là cách làm, vấn đề gặp phải và bài học rút ra — Insight sẽ chắt lọc đúng phần đó. Lợi ích lớn nhất là tiết kiệm thời gian. Bạn vẫn hiểu được tác giả đang nói gì, vì sao cách làm đó hữu ích, và có thể áp dụng gì cho công việc của mình mà không cần đọc qua nhiều chi tiết kỹ thuật. Điều này đặc biệt phù hợp khi bạn muốn cập nhật kiến thức nhanh nhưng không có nhiều thời gian. Ngoài ra, Insight giúp lọc nhiễu tốt hơn. Bài gốc trên mạng thường có nhiều phần phụ, ví dụ lời giới thiệu, nội dung nền tảng, hoặc các chi tiết chỉ dành cho người làm chuyên sâu. Bản tóm tắt sẽ giữ lại phần cốt lõi, diễn giải bằng tiếng Việt tự nhiên, để người non-tech cũng hiểu ngay mà không bị ngợp bởi thuật ngữ.
Với người làm sản phẩm, đọc tóm tắt còn giúp bạn so sánh nhanh nhiều cách làm khác nhau trước khi đi sâu vào một chủ đề. Thay vì mất công đọc lan man, bạn có thể dùng Insight như bước sàng lọc ban đầu: biết bài nào đáng đọc tiếp, bài nào chỉ cần nắm ý là đủ.
Nguồn bài viết
Insight Graph
Khám phá hệ sinh thái 1997 Studio
Nếu bạn đang xây sản phẩm hoặc tăng trưởng, có thể tham khảo thêm các công cụ trong hệ sinh thái để áp dụng nhanh những insight này.
Bài liên quan


![Spec-Driven Development: The Smarter Way to Build with AI [2026]](/api/insight/image?url=https%3A%2F%2Fcdn-images-1.medium.com%2Fmax%2F784%2F1*lm8ORxCLMnkIaMOD5pI0xQ.png&v=20260315b)


