Trong khoảng hai năm trở lại đây, mình đã nhìn thấy rất nhiều cuộc tranh luận xoay quanh một câu hỏi:

AI có thay thế UI/UX Designer hay không?

Khi các công cụ AI bắt đầu có khả năng tạo wireframe, thiết kế giao diện, xây dựng prototype hay thậm chí đề xuất design system chỉ từ vài câu lệnh, sự lo lắng của cộng đồng thiết kế là hoàn toàn dễ hiểu.

Nhiều người cho rằng đây là sự kết thúc của nghề Design. Một số khác lại tin rằng AI sẽ không bao giờ thay thế được khả năng sáng tạo của con người. Cá nhân mình nghĩ cả hai quan điểm trên đều đang tập trung vào một câu hỏi chưa thực sự đúng. Điều mình quan tâm hơn là:

AI sẽ làm thay đổi cấu trúc của ngành Design như thế nào?

Và để trả lời câu hỏi đó, mình muốn nhìn lại lịch sử.

2. Một quy luật lặp lại trong các cuộc cách mạng công nghiệp

Trong hơn 250 năm qua, nhân loại đã trải qua nhiều cuộc cách mạng công nghiệp. Mỗi lần công nghệ mới xuất hiện, nỗi sợ hãi gần như giống nhau:

• Máy móc sẽ cướp mất việc làm.

• Con người sẽ trở nên lỗi thời.

• Một ngành nghề nào đó sẽ biến mất.

Nhưng khi nhìn lại lịch sử, mình nhận thấy một quy luật thú vị:

Công nghệ không xóa bỏ hoàn toàn giá trị của con người. Công nghệ làm thay đổi cách giá trị được tạo ra

Từ người thợ thủ công đến người vận hành máy

Trước Cách mạng Công nghiệp lần thứ nhất, hầu hết sản phẩm được tạo ra bởi các thợ thủ công.

Một người thợ dệt phải tự làm gần như mọi công đoạn:

• Chuẩn bị nguyên liệu

• Dệt vải

• Kiểm tra chất lượng

• Hoàn thiện sản phẩm

Giá trị của họ nằm ở khả năng trực tiếp tạo ra sản phẩm bằng đôi tay của mình. Sau khi máy dệt cơ khí xuất hiện, rất nhiều người tin rằng nghề dệt sẽ biến mất. Nhưng điều thực sự xảy ra là:

• Năng suất tăng lên hàng chục lần.

• Vai trò của người lao động thay đổi.

• Người thợ chuyển sang vận hành và giám sát máy móc.

Họ không còn tạo ra từng mét vải bằng tay. Họ vận hành hệ thống tạo ra hàng nghìn mét vải.

Từ sản xuất thủ công sang dây chuyền sản xuất

Đến Cách mạng Công nghiệp lần thứ hai, dây chuyền sản xuất tiếp tục thay đổi cách con người làm việc.

Thay vì một người làm toàn bộ sản phẩm từ đầu đến cuối, công việc được phân chia thành nhiều vai trò chuyên biệt. Trong ngành sản xuất ô tô, một chiếc xe không còn được tạo ra bởi một cá nhân duy nhất. Thay vào đó xuất hiện nhiều vai trò khác nhau:

• Người thiết kế

• Người sản xuất

• Người kiểm tra chất lượng

• Người quản lý vận hành

Năng suất tăng mạnh nhưng quan trọng hơn, cấu trúc lao động thay đổi hoàn toàn. Không phải lao động biến mất mà là lao động được chuyên môn hóa.

Từ lao động thủ công sang lao động số

Sau đó là máy tính và Internet.

Một lần nữa, lịch sử lại lặp lại. Người ta từng cho rằng:

• Phần mềm kế toán sẽ thay thế kế toán.

• CAD sẽ thay thế kiến trúc sư.

• Photoshop sẽ thay thế nhà thiết kế đồ họa.

Nhưng điều thực sự xảy ra là:

• Công cụ giúp tăng năng suất.

• Một số kỹ năng mất giá trị.

• Một số kỹ năng mới xuất hiện.

• Giá trị dần dịch chuyển từ việc thao tác công cụ sang việc giải quyết vấn đề.

Điều giống nhau ở mọi cuộc cách mạng

Khi nhìn lại các cuộc cách mạng công nghiệp trong lịch sử, mình nhận thấy một điểm chung: công nghệ luôn giúp giảm chi phí thực thi. Những công việc trước đây đòi hỏi nhiều thời gian, công sức và nhân lực dần trở nên nhanh hơn, rẻ hơn và dễ tiếp cận hơn.

Và khi chi phí thực thi giảm xuống, cấu trúc của một ngành nghề cũng bắt đầu thay đổi.

Đó chính là điều khiến mình liên tưởng đến những gì đang diễn ra với ngành Design ngày nay.

3. AI đang công nghiệp hóa ngành Design

Nếu nhìn vào công việc của một UI/UX Designer cách đây vài năm, chúng ta thường phải:

• Vẽ wireframe

• Thiết kế UI

• Tạo prototype

• Xây dựng Design System

• Viết tài liệu hướng dẫn

Tất cả đều là những công việc tiêu tốn rất nhiều thời gian. Nhưng ngày nay, AI đã có thể hỗ trợ phần lớn các đầu việc này. Một wireframe có thể được tạo ra chỉ trong vài phút. Một bộ giao diện có thể được sinh từ một prompt. Một prototype có thể được dựng gần như tự động.

Điều đáng chú ý là AI không nhất thiết phải giỏi hơn Designer để tạo ra sự thay đổi.

Giống như máy dệt không cần dệt đẹp hơn người thợ để làm thay đổi ngành dệt, AI chỉ cần giúp giảm đáng kể chi phí và thời gian thực thi. Và đó chính xác là những gì đang diễn ra hiện nay.

Chi phí thực thi đang giảm mạnh

Nếu trước đây, để biến một ý tưởng sản phẩm thành một prototype có thể thử nghiệm, chúng ta thường phải trải qua nhiều bước: Ý tưởng → Wireframe → UI → Prototype → Test. Toàn bộ quá trình này có thể kéo dài từ vài ngày đến vài tuần.

Ngày nay, cùng một mục tiêu đó có thể được rút ngắn đáng kể thành: Ý tưởng → AI → Prototype ban đầu.

Điều này không có nghĩa Designer sẽ biến mất. Nó chỉ phản ánh một thực tế rằng giá trị của việc trực tiếp tạo ra các artifact đang dần giảm xuống. Và khi điều đó xảy ra, ngành Design cũng sẽ bắt đầu tái cấu trúc

4. Khoảng trống giữa hiện tại và tương lai

Lịch sử cho thấy mỗi cuộc cách mạng công nghiệp đều tạo ra những cơ hội mới, nhưng đồng thời cũng mang đến những thách thức mới. Ngành Design có lẽ sẽ không phải là ngoại lệ.

Theo mình, nhóm chịu ảnh hưởng mạnh nhất sẽ không phải những Designer giàu kinh nghiệm hay những người đã sở hữu năng lực trong nghành thiết kế. Thay vào đó, áp lực lớn nhất có thể sẽ rơi vào nhóm Fresher và Junior Designer.

Lý do là trong nhiều năm qua, con đường phát triển của một Designer thường bắt đầu từ các công việc mang tính thực thi như vẽ wireframe, thiết kế UI, xây dựng prototype, tạo component, thực hiện benchmark, viết tài liệu thiết kế hay chỉnh sửa và hoàn thiện giao diện. Đây cũng chính là những công việc mà AI đang cải thiện với tốc độ rất nhanh.

Một số đầu việc trước đây có thể mất vài ngày để hoàn thành thì hiện nay chỉ cần vài giờ, thậm chí vài phút. Điều đó không có nghĩa AI sẽ thay thế Junior Designer, nhưng nó làm giảm đáng kể giá trị của những công việc thực thi cơ bản.

Đây là điều đã từng xảy ra trong các cuộc cách mạng công nghiệp trước đây. Khi máy dệt xuất hiện, nhu cầu về lao động thủ công giảm xuống. Khi dây chuyền sản xuất ra đời, nhu cầu về những người thực hiện toàn bộ quy trình cũng dần giảm đi. Ngày nay, khi AI xuất hiện, những công việc thiết kế mang tính sản xuất hàng loạt đang đối mặt với áp lực tương tự.

Thách thức lớn nhất của Junior Designer

Theo mình, thách thức lớn nhất không phải là cạnh tranh với AI, mà là cạnh tranh với những Designer biết sử dụng AI.

Trước đây, một Junior Designer có thể tạo ra giá trị nhờ thành thạo công cụ, thiết kế nhanh hơn, tạo ra nhiều phương án hơn hoặc xử lý UI đẹp hơn. Tuy nhiên, những lợi thế đó đang dần trở nên phổ biến.

Khi mọi người đều có thể sử dụng AI để tạo wireframe, giao diện hay prototype trong thời gian rất ngắn, việc thành thạo công cụ không còn là lợi thế cạnh tranh bền vững.

Điều này buộc thế hệ Designer mới phải phát triển sớm hơn những năng lực như:

• Tư duy sản phẩm

• Hiểu biết về người dùng

• Kỹ năng giải quyết vấn đề

• Tư duy hệ thống

• Hiểu biết về kinh doanh

• Khả năng phối hợp và làm việc với AI

Một bài toán mới của ngành Design

Có một câu hỏi mà mình tin rằng ngành Design sẽ phải đối mặt trong vài năm tới:

Nếu AI ngày càng đảm nhận phần lớn công việc thực thi cơ bản, vậy những Senior Designer trong tương lai sẽ được đào tạo từ đâu?

Trước đây, phần lớn Senior Designer đều trưởng thành từ hàng nghìn giờ thực hành. Họ bắt đầu bằng việc thiết kế màn hình, xây dựng prototype, tạo user flow và giải quyết các vấn đề cụ thể của sản phẩm. Chính thông qua quá trình thực thi đó, họ tích lũy đủ trải nghiệm để đưa ra những quyết định ở cấp độ cao hơn.

Nhưng khi AI tham gia ngày càng sâu vào phần thực thi, con đường phát triển truyền thống ấy có thể sẽ thay đổi.

Và theo mình, đây có lẽ là một trong những thách thức lớn nhất của ngành Design trong tương lai.

Đây không phải là dấu chấm hết của ngành Design

Dù vậy, mình không cho rằng đây là một bức tranh bi quan.

Mỗi cuộc cách mạng công nghiệp đều khiến một số kỹ năng mất đi giá trị, nhưng đồng thời cũng tạo ra những kỹ năng và vai trò hoàn toàn mới. Theo góc nhìn của mình, điều tương tự đang diễn ra với ngành Design.

Những kỹ năng thuần thực thi có thể sẽ không còn giá trị như trước. Ngược lại, các năng lực liên quan đến việc hiểu con người, hiểu hành vi, hiểu sản phẩm, hiểu kinh doanh, hiểu hệ thống, vận hành AI và thiết kế quy trình sẽ trở nên quan trọng hơn bao giờ hết.

Vì vậy, thay vì xem AI là mối đe dọa đối với ngành Design, mình xem AI là chất xúc tác cho một quá trình tái cấu trúc đã bắt đầu.

5. Vision của mình về tương lai ngành UI/UX Design

Từ những quan sát trên, mình cho rằng tương lai của ngành Design sẽ không còn được phân chia chủ yếu theo cách truyền thống như UI Designer, UX Designer hay Visual Designer.

Thay vào đó, khi chi phí thực thi ngày càng giảm nhờ công nghệ và AI, ngành Design có thể sẽ dần phân hóa theo giá trị mà mỗi người tạo ra. Nói cách khác, sự khác biệt sẽ không còn nằm ở việc bạn thiết kế loại sản phẩm nào, mà nằm ở việc bạn đóng góp giá trị ở đâu trong toàn bộ quá trình tạo ra sản phẩm.

Và theo mình, sự phân hóa đó sẽ dần hình thành hai nhóm giá trị chính

Decision Group

Đây là nhóm chịu trách nhiệm đưa ra các quyết định mang tính định hướng. Thay vì tập trung vào việc tạo ra artifact, họ dành phần lớn thời gian để hiểu người dùng, phân tích hành vi, nhìn nhận hệ thống, phát triển sản phẩm và tạo ra giá trị cho doanh nghiệp.

Họ là những người trả lời các câu hỏi như:

• Chúng ta nên giải quyết vấn đề gì?

• Trải nghiệm nào nên được xây dựng?

• Giá trị nào cần tạo ra cho khách hàng?

• Giá trị nào cần tạo ra cho doanh nghiệp?

Các vị trí trong nhóm này có thể bao gồm:

UX Designer

Thiết kế trải nghiệm sản phẩm dựa trên nhu cầu và hành vi của người dùng.

UX Strategist

Xây dựng chiến lược UX dài hạn gắn với mục tiêu kinh doanh.

CX Designer

Thiết kế trải nghiệm khách hàng xuyên suốt toàn bộ hành trình tương tác với doanh nghiệp.

Product Designer

Kết nối giữa trải nghiệm người dùng và mục tiêu của sản phẩm.

Product Manager

Chịu trách nhiệm về sự thành công của sản phẩm từ góc độ kinh doanh và thị trường.

Service Designer

Thiết kế trải nghiệm ở cấp độ dịch vụ và toàn bộ hệ sinh thái liên quan.

AI Experience Designer

Thiết kế trải nghiệm tương tác giữa con người và các AI Agent.

Execution Group

Đây là nhóm chịu trách nhiệm hiện thực hóa các quyết định thành sản phẩm cụ thể. Tuy nhiên, mình không cho rằng nhóm này sẽ biến mất.

Ngược lại, mình tin rằng nhóm này vẫn sẽ tiếp tục tồn tại, nhưng dưới một hình thức hoàn toàn khác. Giống như những người thợ thủ công trong các cuộc cách mạng công nghiệp trước đây dần chuyển sang vận hành máy móc thay vì làm mọi thứ bằng tay, các Designer trong tương lai cũng sẽ chuyển sang làm việc cùng AI thay vì trực tiếp tạo ra mọi artifact từ đầu.

Vai trò của họ sẽ không còn đơn thuần là thiết kế, mà là khai thác, điều phối và kiểm soát các hệ thống AI để tạo ra kết quả với tốc độ và quy mô lớn hơn.

Các vị trí trong nhóm này có thể bao gồm:

Creative Designer

Tập trung vào sáng tạo, thẩm mỹ đem lại những giá trị mà AI không thể thay thế.

Automation Designer

Sử dụng AI và các workflow tự động hóa để tạo ra sản phẩm thiết kế.

Design System Architect

Xây dựng và duy trì hệ sinh thái Design System ở quy mô lớn.

Design QA Specialist

Đảm bảo chất lượng của các đầu ra được tạo ra bởi AI hoặc các workflow tự động hóa.

Hai nhóm này tồn tại song song

Theo mình, đây không phải là mối quan hệ cấp trên và cấp dưới.

Không phải:

Decision Group > Execution Group

Mà là:

Decision Group || Execution Group

Mỗi nhóm tạo ra một loại giá trị khác nhau và đều đóng vai trò không thể thay thế.

Decision Group trả lời câu hỏi: Chúng ta nên làm gì?

Execution Group trả lời câu hỏi: Chúng ta sẽ hiện thực hóa điều đó như thế nào?

Một sản phẩm tốt luôn cần cả hai. Nếu không có chiến lược đúng, chúng ta sẽ không biết nên xây dựng điều gì. Ngược lại, nếu không có năng lực thực thi, mọi chiến lược cũng sẽ chỉ dừng lại ở ý tưởng.

6. Lựa chọn của mình trong kỷ nguyên AI

Sau tất cả những quan sát trên, mình nhận ra rằng AI không chỉ đang thay đổi cách chúng ta làm việc. Quan trọng hơn, AI đang buộc mỗi Designer phải trả lời một câu hỏi lớn hơn:

Mình muốn trở thành ai trong tương lai của ngành Design?

Đối với mình, câu trả lời khá rõ ràng.

Mình không lựa chọn trở thành người tập trung vào việc tối ưu hóa các quy trình thực thi bằng AI. Thay vào đó, mình muốn phát triển theo hướng của Decision Group. Đó là những vai trò tham gia trực tiếp vào việc đưa ra các quyết định liên quan đến người dùng, sản phẩm, trải nghiệm và kinh doanh, chẳng hạn như UX Designer, UX Strategist, CX Designer, Product Designer hay Product Manager.

Tuy nhiên, khi nhìn sâu hơn vào những vị trí này, mình nhận ra một điểm rất thú vị. Dù tên gọi khác nhau, tất cả đều được xây dựng trên một nền tảng kiến thức cốt lõi khá giống nhau.

Họ đều cần hiểu hành vi con người, hiểu sản phẩm và kinh doanh, hiểu hệ thống, hiểu cách xây dựng trải nghiệm, biết kiểm chứng giả thuyết và biết đo lường để liên tục tối ưu.

Nói cách khác, trước khi trở thành một UX Strategist hay Product Manager, mình cần xây dựng một nền móng UX đủ vững chắc.

Đó cũng là lý do mình bắt đầu xây dựng một framework học tập cá nhân. Một framework giúp mình trả lời câu hỏi:

Nếu muốn phát triển từ một UI/UX Designer thành người có khả năng tham gia vào các quyết định về sản phẩm, người dùng và kinh doanh, thì mình cần học những gì?

Mình gọi framework đó là UX Tower.

Kết

Mình không cho rằng AI sẽ thay thế Designer. Tương tự như những cuộc cách mạng công nghiệp trước đây, AI đang làm thay đổi cách giá trị được tạo ra trong ngành Design.

Theo góc nhìn của mình, tương lai của ngành Design sẽ dần phân hóa thành hai nhóm chính: Decision Group và Execution Group. Một nhóm tập trung vào việc đưa ra quyết định, trong khi nhóm còn lại tập trung vào việc vận hành các hệ thống AI để hiện thực hóa những quyết định đó.

Tuy nhiên, đây không phải là sự phân chia giữa bên quan trọng hơn và bên kém quan trọng hơn. Cả hai đều cần thiết và cùng tạo ra giá trị cho sản phẩm. Điều khác biệt nằm ở vai trò mà mỗi nhóm đảm nhận trong quá trình tạo ra giá

Và trong bối cảnh này, mỗi Designer sẽ cần tự tìm cho mình một hướng phát triển phù hợp.

Với mình, đó là con đường hướng tới Decision Group. Và UX Tower chính là lộ trình mà mình đang sử dụng để chuẩn bị cho hành trình đó.

Trong bài viết tiếp theo, mình sẽ chia sẻ chi tiết hơn về UX Tower, bao gồm:

• UX Tower là gì?

• Vì sao mình xây dựng mô hình này?

• Sáu tầng kiến thức cốt lõi của UX Tower gồm những gì?

• Và UX Tower có thể trở thành nền tảng để phát triển lên các vai trò như UX Strategist, CX Designer, Product Designer hay Product Manager trong kỷ nguyên AI như thế nào?

Cảm ơn bạn đã đọc! Đăng ký miễn phí để nhận
bài viết mới và ủng hộ mình nhé!

Subscribe now

Tuy nhiên, ngay từ khi bắt đầu dự án, tụi mình đã không xem đây là đích đến cuối cùng. Bởi vì đối với tụi mình: Một Component được tạo ra trong Figma chưa phải là một Component của Design System.

Nghe có vẻ mâu thuẫn. Nhưng càng tham gia sâu vào việc xây dựng Design System, tụi mình càng nhận ra rằng giá trị thực sự không nằm ở việc tạo ra được bao nhiêu Component, bao nhiêu Variants hay bao nhiêu trang Guideline. Giá trị thực sự nằm ở khả năng giúp những gì được tạo ra có thể được sử dụng, được hiểu và được duy trì bởi những người không tham gia xây dựng nó. Nói cách khác, Design System chỉ thực sự thành công khi nó có thể hoạt động mà không phụ thuộc vào người tạo ra nó.

Đó cũng là lý do ngay từ đầu, tụi mình đã xây dựng một quy trình Delivery & Handoff riêng cho Design System. Không đơn thuần là bàn giao file thiết kế hay gửi link Figma mà là một quy trình giúp chuyển đổi những gì thuộc về Design Team thành những tài sản có thể được toàn bộ tổ chức sử dụng.

Khi nào một Component thực sự hoàn thành?

Đây là một câu hỏi tưởng chừng đơn giản nhưng tụi mình đã dành khá nhiều thời gian để suy nghĩ trong quá trình xây dựng Design System. Nếu nhìn dưới góc độ của một dự án sản phẩm thông thường, câu trả lời có thể là Khi Designer hoàn thành thiết kế hoặc Khi Developer hoàn thành việc code.

Nhưng Design System không vận hành giống một dự án thông thường. Một màn hình của sản phẩm có thể chỉ phục vụ cho một tính năng cụ thể. Một Component trong Design System lại có thể được sử dụng trong hàng chục sản phẩm khác nhau, qua nhiều năm phát triển khác nhau. Điều đó khiến tiêu chuẩn hoàn thiện của một Component trở nên khác biệt.

Ví dụ:
Khi tạo ra một màn hình trong dự án, điều quan trọng nhất thường là giải quyết được nhu cầu của người dùng. Nhưng khi tạo ra một Component trong Design System, tụi mình phải suy nghĩ xa hơn.
Liệu Component đó có thể được tái sử dụng ở những sản phẩm khác không?
Liệu những người chưa từng tham gia dự án có hiểu được cách sử dụng nó không?
Liệu sau một năm nữa, khi team thay đổi nhân sự, người mới có thể tiếp tục duy trì nó hay không?
Nếu những câu hỏi đó chưa có lời giải thì dù Component đã hoàn thiện về mặt giao diện, tụi mình vẫn chưa xem nó là hoàn thành.

Theo thời gian, tụi mình dần hình thành một quan điểm chung:

Một Component chỉ thực sự hoàn thành khi nó có thể được hiểu, được triển khai và được tái sử dụng bởi những người khác.

Và đó chính là lý do Delivery & Handoff xuất hiện.

Từ Design Artifact đến Organizational Asset

Một trong những điều thú vị nhất khi làm Design System là sự thay đổi trong cách nhìn nhận về sản phẩm thiết kế. Trong phần lớn các dự án, Designer thường tạo ra Design Artifact. Đó có thể là:

• Wireframe

• Prototype

• UI Design

• Design Specification

Những tài sản này được tạo ra để hỗ trợ một dự án cụ thể nhưng Design System lại khác. Một Component được tạo ra hôm nay có thể tiếp tục được sử dụng trong:

• Dự án hiện tại

• Dự án mới trong năm sau

• Những sản phẩm mà thời điểm hiện tại còn chưa tồn tại

Điều đó khiến Component không còn là tài sản của riêng một dự án nữa, nó trở thành tài sản của tổ chức. Và khi đã là tài sản của tổ chức, yêu cầu dành cho nó cũng thay đổi. Nó không chỉ cần đẹp, nó không chỉ cần hoạt động, nó cần:

• Dễ tìm kiếm

• Dễ hiểu

• Dễ sử dụng

• Dễ bảo trì

• Dễ mở rộng

Đó là lý do tụi mình bắt đầu nhìn Delivery & Handoff dưới một góc nhìn khác. Đây không phải là hoạt động chuyển giao file mà là quá trình chuyển giao tri thức.Bởi vì thứ thực sự cần được bàn giao không phải là Component mà là toàn bộ kiến thức đằng sau Component đó.

Khoảng cách giữa Figma và sản phẩm thực tế

Trước khi tham gia xây dựng Design System, mình từng cho rằng quá trình handoff tương đối đơn giản.

1. Designer hoàn thành thiết kế.

2. Developer nhận file Figma.

3. Sau đó triển khai.

Trong phần lớn các dự án nhỏ, mô hình này vẫn có thể hoạt động tốt. Nhưng càng làm Design System, tụi mình càng nhận ra rằng Figma chỉ là một phần của câu chuyện.

Ví dụ với một Button Component, trong Figma chúng ta có thể nhìn thấy rất nhiều thứ:

• Màu sắc

• Typography

• Border Radius

• Dimensions

• Hover State

• Disabled State

• Variant

Nhưng khi Component được chuyển sang phía Development, hàng loạt câu hỏi mới bắt đầu xuất hiện. Ví dụ:

• Component hỗ trợ bao nhiêu Props?

• Props nào là bắt buộc?

• Props nào là tùy chọn?

• Có hỗ trợ icon hai phía hay không?

• Keyboard Interaction hoạt động như thế nào?

• Screen Reader sẽ đọc nội dung như thế nào?

• Accessibility cần đạt ở mức nào?

• Component có thể mở rộng trong tương lai hay không?

Điều thú vị là những câu hỏi này không xuất hiện vì phía Design làm chưa tốt. Chúng xuất hiện bởi vì Design và Development đang nhìn cùng một Component dưới hai góc độ khác nhau.

Designer quan tâm đến:

• Trải nghiệm người dùng.

• Hành vi mong muốn.

• Tính nhất quán.

Developer lại quan tâm đến:

• Khả năng triển khai.

• Tính ổn định.

• Hiệu năng.

• Khả năng bảo trì.

Không có góc nhìn nào đúng hơn góc nhìn nào. Thực tế cả hai đều cần thiết. Một Component đẹp nhưng khó triển khai sẽ không tạo ra nhiều giá trị. Ngược lại, một Component ổn định nhưng thiếu trải nghiệm tốt cũng không giải quyết được vấn đề. Chính vì vậy, tụi mình xây dựng thêm một lớp chuyển đổi giữa Design và Development.

Chuyển hóa thiết kế thành ngôn ngữ kỹ thuật

Sau khi nhận được Figma và Specification từ Design Team, Developer sẽ không lập tức bắt tay vào code. Thay vào đó, bước đầu tiên là xây dựng Component Design Document. Ban đầu, mình từng nghĩ đây chỉ là một loại tài liệu kỹ thuật. Nhưng sau này mới nhận ra vai trò thực sự của nó. Component Design Document giống như một bộ phiên dịch. Nó giúp chuyển đổi ngôn ngữ thiết kế thành ngôn ngữ triển khai.

Trong quá trình xây dựng tài liệu, Developer sẽ phân tích:

• Cách sử dụng Component

• Component Structure

• Properties

• User Interaction

• Keyboard Interaction

• Accessibility

• Những giới hạn kỹ thuật cần xem xét

Điều thú vị là đây thường là thời điểm xuất hiện nhiều cuộc thảo luận giá trị nhất.

Ví dụ:

Designer tạo một Dropdown.

Developer sẽ hỏi: Nếu có 500 lựa chọn thì sao?

Designer tạo một Input.

Developer sẽ hỏi: Validation sẽ hoạt động như thế nào?

Những cuộc trao đổi này giúp Component trưởng thành hơn rất nhiều trước khi bước vào giai đoạn triển khai. Theo kinh nghiệm của tụi mình, một giờ thảo luận ở giai đoạn này thường tiết kiệm được rất nhiều giờ sửa lỗi sau này.

Handoff không phải là kết thúc của Design

Một điều mà mình thấy khá thú vị là rất nhiều người xem handoff như điểm kết thúc của công việc thiết kế. Designer bàn giao xong, công việc chuyển sang cho Developer.

Nhưng trong Design System, mọi thứ không vận hành như vậy. Sau khi Component được triển khai thành React Component, vai trò của Design Team vẫn chưa kết thúc. Ngược lại, đây là lúc Design bắt đầu kiểm chứng xem những giả định ban đầu có thực sự đúng hay không. Rất nhiều tình huống mới thường xuất hiện ở giai đoạn này.

Ví dụ:

• Một Interaction hoạt động khác kỳ vọng.

• Một State chưa được mô tả đầy đủ.

• Một Property cần được bổ sung.

• Một yêu cầu Accessibility chưa được xem xét

Những điều này hoàn toàn bình thường. Bởi vì Design System không phải một tài liệu tĩnh. Nó là một sản phẩm đang liên tục được hoàn thiện.

Ba nguồn sự thật của một Component

Khi số lượng Component còn ít, việc duy trì tính nhất quán tương đối đơn giản. Mọi người vẫn nhớ Component hoạt động như thế nào. Designer và Developer vẫn có thể trao đổi trực tiếp. Nhưng khi Design System bắt đầu phát triển lớn hơn, một câu hỏi mới xuất hiện:

Đâu mới là phiên bản chính xác nhất của Component?

Designer thường nhìn vào Figma. Developer thường nhìn vào Storybook. Một số người khác lại tra cứu thông tin trong Documentation. Nếu ba nguồn này khác nhau, tổ chức sẽ nhanh chóng xuất hiện nhiều cách hiểu khác nhau về cùng một Component. Đó là lý do tụi mình bắt đầu xem:

• Documentation

• Figma

• React Component

như ba nguồn sự thật cần được duy trì song song. Trong các buổi Component Review, mục tiêu không chỉ là tìm lỗi. Mục tiêu còn là bảo vệ sự đồng bộ giữa ba nguồn tri thức này. Tụi mình thường sử dụng một nguyên tắc rất đơn giản:

Documentation = Figma = React Component

Nếu một bên thay đổi, các bên còn lại cần được xem xét và cập nhật tương ứng. Khi nhìn lại, tụi mình nhận ra rằng Component Review không chỉ là một hoạt động Quality Check. Nó là một hoạt động bảo vệ niềm tin dành cho Design System. Bởi vì khi người dùng không còn biết nên tin vào nguồn nào, họ cũng sẽ dần ngừng sử dụng Design System.

Tổ chức những gì đã tạo ra

Sau khi hoàn thành Review, công việc vẫn chưa kết thúc bởi vì lúc này tụi mình mới chỉ tạo ra được Component. Chúng ta vẫn cần đảm bảo mọi người có thể tìm thấy và sử dụng Component đó trong tương lai. Đây là lúc tụi mình bước vào giai đoạn Organize What Was Created.

Một bài học khá thú vị mà team học được là Việc lưu trữ kiến thức đôi khi quan trọng không kém việc tạo ra kiến thức. Một Design System có thể có Component rất tốt.

Nhưng nếu người dùng không tìm được tài liệu hướng dẫn, họ vẫn sẽ tạo ra giải pháp riêng của mình. Cuối cùng tổ chức lại quay về tình trạng thiếu nhất quán ban đầu.

Xây dựng ngôi nhà cho Design System

Sau nhiều thảo luận, tụi mình quyết định xây dựng một cổng thông tin tập trung dành cho Design System. Hiện tại tụi mình sử dụng Docusaurus để quản lý:

• Documentation

• Component Guideline

• Accessibility Guideline

• Release Note

• Changelog

• Best Practice

• Migration Guide

Điều quan trọng nhất không nằm ở Docusaurus. Điều quan trọng nằm ở việc mọi người đều biết nếu cần thông tin về Design System, đây là nơi phải tìm đến đầu tiên. Một nguồn thông tin duy nhất luôn tốt hơn năm nguồn thông tin rải rác.

Một số công cụ khác thay thế Docusaurus

Thực tế không có công cụ nào phù hợp với tất cả tổ chức. Tùy quy mô và cách vận hành, bạn hoàn toàn có thể cân nhắc:

Storybook

Phù hợp khi Development Team đóng vai trò trung tâm.

Zeroheight

Phù hợp với các tổ chức muốn liên kết chặt chẽ với Figma.

Supernova

Phù hợp với Design System quy mô lớn cần quản lý Token, Governance và Asset.

Confluence

Phù hợp với các tổ chức muốn triển khai nhanh và tận dụng hạ tầng sẵn có.

Theo quan điểm của mình, Công cụ quan trọng nhưng khả năng tiếp cận thông tin còn quan trọng hơn.

Publish không phải Release

Một trong những thay đổi lớn nhất trong cách suy nghĩ của tụi mình là phân biệt rõ Publish và Release. Ban đầu, tụi mình thường xem việc đưa Component vào Library là một dấu mốc hoàn thành. Nhưng khi Design System ngày càng lớn, cách suy nghĩ đó không còn phù hợp.

Một Component được Publish chỉ có nghĩa rằng nó đã xuất hiện trong hệ sinh thái. Nhưng chưa chắc nó đã sẵn sàng để Product Team sử dụng. Release mang ý nghĩa lớn hơn. Nó thể hiện rằng:

• Chất lượng đã được xác nhận.

• Documentation đã hoàn thiện.

• Design và Development đã thống nhất.

• Component đã sẵn sàng cho môi trường thực tế.

Chính vì vậy, tụi mình bắt đầu quản lý Design System giống như quản lý một sản phẩm.

Design System cũng là một sản phẩm

Đây có lẽ là một trong những bài học lớn nhất mà tụi mình học được trong suốt hành trình xây dựng Design System. Ban đầu, tụi mình nhìn Design System như:

• Một thư viện Component.

• Một bộ Guideline.

• Một bộ Design Tokens.

Nhưng càng phát triển, tụi mình càng nhận ra rằng Design System có đầy đủ đặc điểm của một sản phẩm. Nó có:

• Người dùng.

• Yêu cầu mới.

• Phản hồi.

• Vấn đề cần giải quyết.

• Roadmap.

• Release Plan.

Chỉ khác một điều. Khách hàng của Design System không phải người dùng cuối. Khách hàng của nó là:

• Designer

• Developer

• QA

• Product Team

Khi nhìn Design System dưới góc độ này, rất nhiều quyết định trở nên dễ hiểu hơn.

• Tại sao cần Documentation?

• Tại sao cần Review?

• Tại sao cần Governance?

• Tại sao cần Release?

Bởi vì tất cả những điều đó đều là những hoạt động quen thuộc trong quá trình phát triển sản phẩm.

Điều tụi mình học được

Sau toàn bộ hành trình xây dựng Design System, có một điều mà tụi mình ngày càng tin tưởng. Đó là:

Component không phải là sản phẩm cuối cùng của Design System.

Thứ mà Design System tạo ra thực chất là khả năng tái sử dụng tri thức. Khi nhìn lại, một Component phải trải qua rất nhiều giai đoạn:

Reseach → Design → Documentation → Development → Review → Publication → Release

Từ một ý tưởng trong Figma nó dần trở thành Source Code. Rồi trở thành Documentation. Xuất hiện trong Storybook, được đưa vào Library. Và cuối cùng trở thành một phần của Design System chính thức. Có lẽ đó cũng là điều thú vị nhất khi làm Design System.

Bởi vì sau tất cả, thứ tụi mình đang xây dựng không phải là những Component. Thứ tụi mình đang xây dựng là một hệ thống giúp kiến thức thiết kế có thể tồn tại, phát triển và được tái sử dụng bởi nhiều thế hệ sản phẩm khác nhau.

Đây là Design Process mà team mình đã phát triển và sử dụng tại GLORY trước đây. Dù ở thời điểm viết bài này chúng mình đã phát triển một quy trình mới và áp dụng AI rất nhiều nhưng vì vấn đề security nên mình không thể công khai. Các bạn có thể tham khảo quy trình cũ này và tự phát triển các để phù hợp cho team.

Design System Operation Process

Vậy là chúng ta đã khép lại Phần 4 của hành trình Xây dựng Design System. Ở phần tiếp theo, mình sẽ tiếp tục chia sẻ về cách Bảo trì và Cải tiến cho Design System. Hứa hẹn sẽ có nhiều insight thú vị, cùng theo dõi nhé!

Cảm ơn bạn đã đọc! Đăng ký miễn phí để nhận
bài viết mới và ủng hộ mình nhé!

Subscribe now

Hãy cùng mình khám phá xem bước đệm này đóng vai trò thế nào trong việc tối ưu hóa quy trình thiết kế nhé.

Reference Graphic Research

"Đứng trên vai người khổng lồ" trước khi xây dựng Design System

Trong quy trình xây dựng Design System (DS), một sai lầm phổ biến là bắt tay vào vẽ Component ngay lập tức theo cảm tính. Những hệ thống thiết kế lớn như Material Design, Human Interface (Apple) hay Carbon (IBM) không chỉ đẹp, chúng là kết quả của hàng nghìn giờ nghiên cứu và hàng triệu đô la thử nghiệm.

Việc thực hiện Reference Graphic Research (nghiên cứu thông số đồ họa của các DS tiêu chuẩn) là bước bắt buộc vì các lý do cốt lõi sau:

Kế thừa tư duy “Nguyên tử hóa” thông số

Các hệ thống lớn cung cấp cho chúng ta một bộ khung logic về các con số vàng trong Design Token:

• Hệ thống Grid và Spacing: Tại sao họ ưu tiên hệ 4px hoặc 8px? Nghiên cứu giúp bạn hiểu cách tạo ra sự nhịp điệu (Vertical Rhythm) cho layout.

• Corner Radius và Elevation: Cách họ sử dụng bo góc và đổ bóng (Shadow) để phân cấp thông tin mà không làm rối mắt, đặc biệt quan trọng trong các giao diện phức tạp như Dashboard.

Bảo chứng cho tính Khả dụng và Truy cập

Thay vì tự mình thử nghiệm sai số, bạn có thể kế thừa các tiêu chuẩn đã được kiểm chứng toàn cầu:

• Kích thước điểm chạm (Tap Targets): Tại sao nút bấm nên cao tối thiểu 44px hoặc 48px? Đó là để đảm bảo mọi ngón tay đều có thể tương tác chính xác.

• Độ tương phản và Font size: Các DS lớn luôn tuân thủ chuẩn WCAG. Việc tham chiếu thông số giúp bạn đảm bảo sản phẩm có thể tiếp cận được với mọi đối tượng người dùng mà không cần các cuộc thử nghiệm lại gây tốn kém.

Tận dụng Mental Model

Người dùng dành phần lớn thời gian trên các nền tảng sản phẩm của các công ty đứng đầu trong nghành. Họ đã hình thành thói quen về cách một Input Field hay Dropdown hoạt động.

• Việc giữ các thông số Graphic (như chiều cao Input, vị trí Icon) tiệm cận với tiêu chuẩn chung giúp giảm tải nhận thức (Cognitive Load).

• Sản phẩm của bạn sẽ mang lại cảm giác quen thuộc và dễ dùng ngay từ lần chạm đầu tiên.

Tối ưu hóa sự phối hợp với Developers

Một Design System có thông số dựa trên các tiêu chuẩn phổ biến sẽ giúp đội ngũ Engineering dễ dàng triển khai hơn. Các thư viện code hiện nay như MUI, Tailwind, hay Ant Design thường mặc định theo các thông số của các DS nổi tiếng. Khi bạn thiết kế dựa trên nghiên cứu thực tế, việc giao tiếp và bàn giao (Hand-off) sẽ trở nên mượt mà, ít sai số.

Chúng ta sẽ Research những gì?

Context: Tại sao chúng ta cần nghiên cứu này?

Bối cảnh là lời giải thích vì sao dự án của bạn cần phải soi chiếu với các hệ thống khác. Thay vì viết những dòng lý thuyết suông, hãy tập trung vào thực trạng mà team đang đối mặt:

• Sự thiếu nhất quán: Nêu rõ các vấn đề hiện tại như việc mỗi designer đang sử dụng một kiểu bo góc hoặc đổ bóng khác nhau cho cùng một loại component.

• Đặc thù sản phẩm: Nếu bạn đang làm một hệ thống Dashboard phức tạp, bối cảnh sẽ là việc cần tìm kiếm các giải pháp hiển thị dữ liệu mật độ cao mà vẫn đảm bảo tính thẩm mỹ.

• Điểm chạm người dùng: Xác định xem người dùng của bạn thường xuyên sử dụng hệ điều hành hay nền tảng nào để chọn nguồn tham chiếu phù hợp nhất.

Goal: Chúng ta muốn đạt được điều gì?

Mục tiêu chính là kim chỉ nam giúp bạn không bị lạc lối trong “biển” thông số của các ông lớn. Một mục tiêu rõ ràng thường bao gồm:

• Chuẩn hóa thư viện: Thiết lập một bộ quy tắc đồ họa (UI Graphic) dựa trên các tiêu chuẩn công nghiệp đã được kiểm chứng để giảm thiểu sai sót.

• Tối ưu tốc độ bàn giao: Giúp Designer và Developer nói cùng một ngôn ngữ thông qua các thông số có tính logic cao, từ đó rút ngắn thời gian Hand-off.

• Nâng cao khả năng truy cập (Accessibility): Đảm bảo mọi component sau khi tham chiếu đều đáp ứng tốt các tiêu chuẩn về độ tương phản và kích thước tương tác.

Policy: Quy định về việc “Tham chiếu”

Chính sách là tập hợp các nguyên tắc để đảm bảo team không sao chép một cách máy móc. Đây là phần quan trọng nhất để giữ bản sắc cho sản phẩm:

• Tiêu chuẩn chọn nguồn: Quy định rõ chỉ tham chiếu từ những “người khổng lồ” có độ tin cậy cao như Material Design, Human Interface hoặc các hệ thống có cùng tệp khách hàng.

• Tỉ lệ kế thừa và tùy biến: Xác định xem khi nào team sẽ tuân thủ tuyệt đối theo tiêu chuẩn chung và khi nào cần phá cách để phù hợp với Brand Identity của sản phẩm.

• Nguyên tắc cập nhật: Quy định về tần suất rà soát lại tài liệu nghiên cứu để đảm bảo các thông số tham chiếu luôn bắt kịp với những bản cập nhật mới nhất từ các nền tảng gốc.

Examples of Other Companies’ Guidelines: 3 trụ cột phân tích

Một bảng nghiên cứu Reference Graphic khoa học thường được chia thành 3 trụ cột dữ liệu chính giúp bóc tách mọi khía cạnh của một component. Mình sẽ đưa ra một ví dụ cụ thể như Textarea Component

Image: Bằng chứng trực quan

Hình ảnh không chỉ để minh họa mà còn là điểm tham chiếu nhanh cho các Designer khi cần so sánh thẩm mỹ giữa các hệ thống:

• Cung cấp ảnh chụp màn hình thực tế của component trong nhiều trạng thái khác nhau.

• Giúp nhận diện các thành phần phụ trợ đi kèm như Resize handle (nút kéo giãn), Icon thông báo lỗi, hay Counter (bộ đếm ký tự)

Summary, Action và Animation: Định nghĩa hành vi

Đây là phần mô tả logic vận hành và các phản hồi tương tác của component:

• Summary: Phân loại các biến thể của component, ví dụ như dạng mặc định (Default), dạng tinh giản (Subtle) hoặc các loại hiển thị đặc thù.

• Action: Liệt kê đầy đủ các trạng thái tương tác mà người dùng sẽ trải nghiệm như Hover, Focus, Invalid, Validated hay Disabled.

• Animation: Làm rõ cơ chế chuyển động hoặc thay đổi kích thước. Đối với Text Area, phần này cực kỳ quan trọng để xác định các chế độ co giãn như Smart (tự giãn theo nội dung), None (cố định), hay Resize theo chiều dọc/ngang.

Style: Hệ thống hóa thông số kỹ thuật (Design Tokens)

Đây là “trái tim” của bản nghiên cứu, nơi các quyết định thiết kế được định lượng hóa thành các con số cụ thể để bàn giao cho lập trình viên:

• Color: Ghi nhận mã màu chính xác (thường là định dạng RGBA) cho Background, Border, Placeholder và Text theo từng trạng thái cụ thể.

• Size và Spacing: Xác định các thông số về kích thước mặc định (Width/Height), độ bo góc (Corner Radius), và các khoảng đệm (Padding) để đảm bảo tính cân đối thị giác.

• Typography: Phân tích chi tiết về Font family (như SF Pro, Segoe UI, Roboto), kích thước chữ (Size), trọng lượng chữ (Weight) và chiều cao dòng (Line height) cho nhãn và nội dung nhập liệu.

Visual Characteristics: Kim chỉ nam trước khi "đặt bút" trên Figma

Visual Characteristics không chỉ là những dòng mô tả kỹ thuật, mà chính là kim chỉ nam giúp các designer định hướng chính xác trước khi thực hiện thiết kế component thực tế trên Figma. Đây là bản tổng hợp những đề xuất chiến lược được đúc kết từ quá trình nghiên cứu Reference Graphic, đảm bảo mọi thành phần được tạo ra đều có sự nhất quán về tư duy và kỹ thuật ngay từ những pixel đầu tiên.

Việc xác lập bộ chỉ dẫn này mang lại giá trị thực thi cao thông qua các yếu tố cốt lõi:

• Định hình cấu trúc chuẩn: Đồng bộ hóa các thành phần dùng chung như nhãn (Label) và các thông số khoảng đệm (Padding) để tạo sự liền mạch trong toàn hệ thống.

• Xác lập ngôn ngữ tương tác: Quy định rõ ràng hệ thống màu sắc cho từng trạng thái (Active, Inactive) và các cơ chế co giãn (Resizing) để đảm bảo trải nghiệm người dùng luôn ổn định.

• Tối ưu hóa khả năng hiển thị: Thiết lập các tiêu chuẩn về Typography và các thành phần bổ trợ (Helper Text, Counter) dựa trên những nghiên cứu đã được kiểm chứng.

Khi nắm trong tay bản Visual Characteristics, designer không còn phải phân vân giữa các lựa chọn cảm tính. Mọi quyết định thiết kế lúc này đều dựa trên dữ liệu và tiêu chuẩn ngành, giúp quy trình làm việc trở nên khoa học, chuyên nghiệp và sẵn sàng cho các giai đoạn phát triển phức tạp hơn

Tóm lại, Reference Graphic Research là bước chuyển hóa từ quan sát thành tư duy hệ thống trước khi chính thức đặt bút vẽ pixel. Khi nắm vững các đặc tính thị giác đã được đúc kết, bạn sẽ sở hữu một kim chỉ nam vững chắc để tạo ra những component đạt chuẩn và chuyên nghiệp trên Figma. Việc chuẩn bị nền móng này thật kỹ chính là chìa khóa để tối ưu hóa và đảm bảo tính nhất quán cho mọi công đoạn triển khai chi tiết sau đó.

Tải mẫu [Component] - Reference Graphic

Design Component trên Figma

Sau khi đã nắm vững các đặc tính thị giác từ bước nghiên cứu, chúng ta chính thức bước vào giai đoạn thực thi: Xây dựng component trên Figma. Để một component không chỉ dừng lại ở mức “vẽ cho đẹp” mà thực sự trở thành một công cụ mạnh mẽ, có khả năng bao quát mọi kịch bản sử dụng (edge cases), designer cần tiếp cận theo một quy trình có hệ thống.

Dưới đây là 6 đầu mục cốt lõi mà bạn cần tuân thủ để đảm bảo tính hoàn thiện và khả năng mở rộng của component:

Structure (Cấu trúc hệ thống)

Cấu trúc là nền móng của mọi component. Ở bước này, designer tập trung vào việc tổ chức các lớp (layers) và các thành phần con (sub-components). Một cấu trúc tốt phải đảm bảo sự mạch lạc trong việc đặt tên, sử dụng tính năng Auto Layout một cách thông minh để component có thể co giãn linh hoạt. Việc tư duy về cấu trúc ngay từ đầu giúp team dễ dàng bảo trì và cập nhật hệ thống sau này.

Type (Phân loại biến thể)

Mỗi component thường tồn tại dưới nhiều hình thái khác nhau để phục vụ các mục đích cụ thể. Bạn cần xác định rõ các “Type” chính của thành phần đó. Ví dụ, với một Button, chúng ta có thể có các loại như Primary, Secondary, hay Basic. Việc phân loại rõ ràng giúp designer biết chính xác nên sử dụng “vũ khí” nào cho từng tình huống trải nghiệm cụ thể.

Options (Tùy chọn thuộc tính)

Đây là nơi bạn khai thác sức mạnh của Properties trong Figma. Các tùy chọn này cho phép designer bật/tắt các yếu tố phụ trợ mà không làm thay đổi cấu trúc cốt lõi của component.

• Toggle: Hiển thị hoặc ẩn các icon trái, icon phải hoặc các thẻ tag.

• Size: Xác lập các kích thước khác nhau (Small, Medium, Large) để phù hợp với từng mật độ giao diện.

Layout (Quy tắc bố cục)

Component sẽ tồn tại trong nhiều môi trường khác nhau, vì vậy việc thiết lập quy tắc bố cục là bắt buộc. Bạn cần xác định các thông số về khoảng cách (Padding), khoảng cách giữa các thành phần con (Gap) và cách component phản ứng khi thay đổi kích thước (Responsive). Một Layout chuẩn xác sẽ giúp component luôn giữ được sự cân đối thị giác dù ở bất kỳ không gian nào.

Behavior (Hành vi và Trạng thái)

Một thiết kế “tĩnh” sẽ không bao giờ phản ánh đúng trải nghiệm người dùng. Designer cần thiết lập đầy đủ các trạng thái tương tác (Interaction States) như Hover, Pressed, Focused hay Disabled. Bên cạnh đó, các quy tắc về hành vi như cơ chế co giãn (Resizing) hay cách xử lý khi văn bản quá dài (Truncation) cũng cần được quy định rõ ràng để dev có thể triển khai chính xác.

Content Guide (Quy tắc nội dung)

Component là cái khung, còn nội dung là linh hồn. Content Guide đóng vai trò là “cuốn hướng dẫn sử dụng” dành cho ngôn ngữ.

• Quy tắc đặt tên: Ví du như cách gọi tên nhãn (Label) sao cho nhất quán.

• Giới hạn ký tự: Quy định độ dài tối đa để tránh làm vỡ giao diện.

• Giọng văn: Ví dụ như đảm bảo nội dung hiển thị (Placeholder, Helper text) luôn đúng với cá tính thương hiệu.

Việc hoàn thiện component trên Figma dựa trên 6 trụ cột hệ thống là bước chuyển mình quan trọng từ nghiên cứu sang thực thi. Cách tiếp cận này giúp bạn tạo ra những thực thể thiết kế bền vững và có khả năng bao quát mọi kịch bản sử dụng thực tế.

Khi áp dụng chặt chẽ các đặc tính thị giác đã đúc kết, designer sẽ có một kim chỉ nam vững chắc để đảm bảo tính nhất quán cho toàn bộ sản phẩm. Những quy chuẩn về hệ thống trạng thái tương tác hay cơ chế co giãn linh hoạt chính là chìa khóa để giải phóng sức sáng tạo mà không làm mất đi tính logic của hệ thống.

Trong phần tiếp theo, chúng ta sẽ cùng bước ra khỏi không gian thiết kế để kiểm chứng sản phẩm qua Usability Testing. Đồng thời, mình sẽ chia sẻ về quy trình Delivery và Handoff kỹ thuật để đảm bảo mọi thông số đồ họa từ bản nghiên cứu được truyền tải chính xác nhất đến đội ngũ lập trình. Hẹn gặp lại bạn ở phần 4 để cùng hoàn tất hành trình xây dựng Design System chuyên nghiệp.

Cảm ơn bạn đã đọc!

Đăng ký miễn phí để nhận bài viết mới và ủng hộ mình nhé!

Subscribe now

Trong phần này, mình sẽ cùng bạn khám phá cách chúng mình tại GLORY tiến hành nghiên cứu và xác định các thông số thiết kế cho một component. Đây là bước khởi đầu trong chuỗi quy trình xây dựng component, gồm các phần 2, 3 và 4.

Ở phần 4, mình sẽ tổng hợp toàn bộ quy trình thành một sơ đồ trực quan, giúp bạn nắm bắt rõ ràng cách vận hành của Design System thông qua sơ đồ Design System Operation Rules.

Vì sao cần Research?

Bạn đang thiết kế một “Button” như thế nào? Có thể bạn đã từng lướt qua vài Design System nổi tiếng, xem họ làm ra sao, rồi nhanh chóng sao chép về, chỉnh sửa đôi chút cho phù hợp với sản phẩm của mình và coi như đã xong.

Cách làm này tuy giúp tiết kiệm thời gian, nhưng không đảm bảo rằng hệ thống của bạn được xây dựng trên một nền tảng vững chắc, có khả năng đáp ứng nhu cầu thực tế của người dùng, cũng như phục vụ hiệu quả cho các mục tiêu dài hạn của sản phẩm và doanh nghiệp.

Hiểu rõ vấn đề và yêu cầu

Mọi hệ thống thiết kế hiệu quả đều bắt đầu từ việc hiểu rõ vấn đề. Một bước không thể thiếu trong giai đoạn đầu là kiểm toán thiết kế (Design Audit). Đây là cách để rà soát toàn bộ giao diện hiện tại, phát hiện những điểm chưa nhất quán, và từ đó xác định các nhu cầu thực tế cũng như tiềm năng trong tương lai mà hệ thống cần đáp ứng. Việc này không chỉ giúp làm rõ hiện trạng mà còn tạo nền tảng vững chắc cho các quyết định thiết kế tiếp theo.

Phát hiện các yêu cầu ẩn và cạnh (Edge Cases)

Một bản thiết kế đẹp không đồng nghĩa với việc đã đầy đủ. Những gì bạn thấy thường chỉ là phần nổi của tảng băng. Để hiểu toàn diện, cần chủ động trao đổi với các nhà thiết kế và kỹ sư backend nhằm làm rõ các yêu cầu chưa được thể hiện và những edge case dễ bị bỏ sót. Nếu không làm rõ từ đầu, bạn có thể phải đối mặt với việc sửa lại hoặc phát sinh nợ kỹ thuật ngay trong giai đoạn đầu triển khai.

Một số Loại Edge Case thường gặp:

• Dữ liệu thiếu hoặc lỗi

• Nội dung quá khổ

• Trạng thái ngoại lệ

• Yêu cầu hỗ trợ đa nền tảng

Việc nhận diện sớm các tình huống này sẽ giúp hệ thống vận hành ổn định hơn trong thực tế.

Nắm bắt tác động toàn hệ thống

Mỗi khi thêm mới hoặc điều chỉnh một component, điều quan trọng là phải hiểu rõ sự thay đổi đó ảnh hưởng đến hệ thống tổng thể và trải nghiệm người dùng như thế nào. Một thay đổi nhỏ ở một phần có thể gây ra hiệu ứng dây chuyền, làm xáo trộn giao diện hoặc hành vi ở nơi khác. Thiết kế không thể tách rời khỏi bối cảnh toàn hệ thống, và việc cân nhắc kỹ lưỡng sẽ giúp bạn tránh được những rủi ro không đáng có.

Tránh những giả định sai lầm

Thiết kế tốt bắt đầu từ việc đặt ra những câu hỏi đúng. Nghiên cứu giúp bạn tránh được các giả định thiếu cơ sở hoặc bỏ sót những tính năng quan trọng. Các bản thiết kế thường mô tả kịch bản lý tưởng, nhưng người dùng thực tế thì không phải lúc nào cũng tương tác trong điều kiện hoàn hảo. Bạn cần hình dung được giao diện sẽ vận hành ra sao khi dữ liệu bị thiếu, sai định dạng, hoặc khi người dùng thao tác ngoài dự kiến. Đây là cách để đảm bảo sản phẩm không chỉ đẹp mà còn thực sự hiệu quả.

Chúng ta sẽ Research những gì?

Trước khi bắt tay vào thiết kế, điều quan trọng là phải hiểu rõ component bạn đang xây dựng là gì, sẽ được sử dụng trong bối cảnh nào, và mục tiêu chính của nó là gì.

Đây là những yếu tố nền tảng giúp định hướng toàn bộ quá trình thiết kế, đảm bảo rằng component không chỉ đẹp mà còn phù hợp với nhu cầu thực tế và mục tiêu sản phẩm. Nếu bỏ qua bước này, rất dễ dẫn đến việc thiết kế thiếu trọng tâm, khó tái sử dụng hoặc không đáp ứng đúng kỳ vọng của người dùng.

Bối cảnh

Xác định rõ component bạn đang xây dựng sẽ phục vụ chức năng gì và thường xuất hiện trong những tình huống nào. Việc hiểu rõ ngữ cảnh sử dụng sẽ giúp bạn đưa ra quyết định thiết kế phù hợp, đảm bảo component hoạt động hiệu quả và dễ tái sử dụng trong hệ thống.

Ví dụ: Badge là một thành phần UI linh hoạt, dùng để hiển thị thông tin bổ sung hoặc trạng thái liên quan đến các phần tử khác. Nó thường được sử dụng để làm nổi bật thông báo, số lượng hoặc trạng thái, góp phần nâng cao tính tương tác và khả năng truyền đạt trong giao diện.

Mục tiêu

Trước khi bắt đầu thiết kế, hãy xác định rõ component đó mang lại giá trị gì cho người dùng. Nó giải quyết vấn đề nào, cải thiện trải nghiệm ra sao, và có thực sự cần thiết trong bối cảnh sản phẩm hiện tại không.

Việc làm rõ mục tiêu sẽ giúp team cân nhắc kỹ giữa chi phí thiết kế và giá trị thực tế mà component đóng góp, tránh đầu tư vào những phần không tạo ra tác động rõ ràng. Đây là bước quan trọng để đảm bảo mọi nỗ lực đều hướng đến hiệu quả và người dùng.

Ví dụ: Huy hiệu (Badge) được thiết kế để truyền đạt thông tin bổ sung một cách nhanh chóng và dễ hiểu. Nó giúp người dùng nhận biết trạng thái, số lượng hoặc thông báo liên quan mà không làm gián đoạn trải nghiệm tổng thể.

Kiểm toán thiết kế

Phân tích dự án thiết kế của công ty

Nếu công ty bạn chưa có sản phẩm, bạn có thể bỏ qua bước này. Nhưng nếu team đã từng triển khai các dự án trước đó, hãy dành thời gian rà soát và tổng hợp những sản phẩm có sử dụng component bạn đang chuẩn bị thiết kế. Việc này giúp bạn hiểu rõ cách component từng được dùng, từ đó đưa ra quyết định thiết kế phù hợp hơn. Bảng tổng hợp nên bao gồm các mục như:

• Tên dự án

• Tên gọi component

• Hình ảnh minh hoạ

• Mô tả cách sử dụng

• Mức độ xuất hiện

• Các ghi chú liên quan

Phân tích từ các Design System khác

Trong thiết kế, cách nhanh nhất để khơi gợi ý tưởng là nhìn vào những gì đã tồn tại. Khi xây dựng Design System, việc tham khảo các hệ thống thiết kế từ những công ty khác không chỉ giúp tiết kiệm thời gian nghiên cứu mà còn mở ra góc nhìn mới về các edge case mà dự án nội bộ có thể chưa từng gặp. Đây là cách thông minh để học hỏi từ thực tiễn và tránh lặp lại sai lầm của người đi trước.

Bảng nghiên cứu Reference Design System nên bao gồm các mục như:

• Tên Design System

• Tên gọi component tương ứng

• URL kèm theo

• Hình ảnh minh hoạ

• Mô tả cách sử dụng

• Mức độ tương thích với sản phẩm của công ty

• Các ghi chú hoặc lưu ý đặc biệt

Một số Design System hàng đầu mà bạn có thể dùng để nghiên cứu:

• Polaris

• Primer

• Fluent

• Evergreen

• Atlassian

• Ant Design

• Paste

• Spectrum

• Pajamas

• Carbon

• Gestalt

• Dell

Lưu ý:

• Hãy ưu tiên nghiên cứu những Design System thường được sử dụng trong lĩnh vực mà sản phẩm của bạn tham gia.. Ví dụ, nếu thiết kế cho ngành y tế, Ant Design là lựa chọn phù hợp.

• Bạn chỉ nên chọn lọc và tập trung nghiên cứu khoảng 5–7 Design System phù hợp. Việc giới hạn số lượng giúp tiết kiệm thời gian, tránh bị quá tải thông tin và đảm bảo chất lượng phân tích sâu hơn cho từng hệ thống.

Tổng hợp yêu cầu thành phần

Sau khi bạn đã thực hiện Design Audit trên các sản phẩm nội bộ và tham khảo những Design System nổi bật trong ngành, bước tiếp theo là tổng hợp và đánh giá dữ liệu thu được thành một bảng yêu cầu thành phần (Component Requirement Sheet). Đây là công cụ giúp bạn hệ thống hóa thông tin, xác định rõ nhu cầu thực tế và chuẩn bị nền tảng cho quá trình thiết kế.

Ở giai đoạn này, bạn chưa cần chốt thiết kế cuối cùng cho component, vì vậy công việc có thể được thực hiện độc lập bởi researcher. Tuy nhiên, việc tham khảo thêm ý kiến từ UI Designer và Front End Developer là rất quan trọng. Họ có góc nhìn sâu hơn về tính khả thi, khả năng triển khai và những ràng buộc kỹ thuật liên quan.

Một bảng yêu cầu thành phần nên bao gồm:

• Đặc tính kĩ thuật: Nêu rõ các thông số liên quan đến chức năng và hành vi của component như:

  • Hình dáng: Mô tả cấu trúc hoặc layout tổng thể.

  • Màu sắc: Các màu được sử dụng, bao gồm cả trạng thái mặc định và khi tương tác.

  • Vị trí: Thành phần thường xuất hiện ở đâu trong giao diện.

  • Kích thước: Chiều cao, chiều rộng, khoảng cách…

  • Trạng thái: Các biến thể như hover, active, disabled…

  • Tương tác: Thành phần có thể tương tác được hay không.

  • Etc…

• Mô tả chi tiết: Giải thích rõ về các đặc tính kĩ thuật.

• Hình ảnh minh hoạ: Giúp hình dung trực quan về component.

• URL kèm theo: Link đến tài liệu, ví dụ hoặc hệ thống tham khảo.

• Checkbox: Dùng để đánh dấu những yêu cầu được chọn để triển khai.

Sau khi hoàn tất việc nghiên cứu và tổng hợp yêu cầu cho component, bạn nên trình bày kết quả trước Team Design và các Stakeholder liên quan. Những buổi họp thảo luận sẽ giúp mọi người cùng xem xét, phản biện và thống nhất các yếu tố quan trọng như tên gọi, đặc tính kỹ thuật, cách triển khai…

Ngoài những thảo luận cơ bản, team mình thường dùng tới một số phương pháp đánh giá để đưa ra các quyết định. Bạn có thể tham khảo một số phương pháp sau:

• Impact Effort Matrix

• ICE Scoring

• RICE Framework

• MoSCoW Prioritization

Quyết định cuối cùng nên được đưa ra bởi người có thẩm quyền như Design Leader, Design Manager hoặc cấp cao hơn để đảm bảo tính định hướng, nhất quán và quản trị chi phí cho toàn bộ hệ thống.

Tải mẫu [Component] - Definition

Xây dựng Document đầu tiên

Sau khi hoàn tất quá trình research và cùng stakeholder thống nhất các quyết định liên quan đến việc xây dựng component, bước tiếp theo bạn cần thực hiện là xây dựng tài liệu đầu tiên cho component. Đây sẽ là kim chỉ nam giúp bạn bám sát trong suốt quá trình thiết kế và phát triển component này, tương tự như việc tạo Persona trong UX Process.

Vậy tài liệu này cần bao gồm những nội dung gì?

Định nghĩa

Mỗi Design System có cách định nghĩa component riêng, dẫn đến sự khác biệt trong cách thiết kế và triển khai. Ví dụ, cùng là “Tag” nhưng cách thể hiện trong Carbon Design và Ant Design lại không giống nhau.

Vì vậy, trước khi bắt đầu thiết kế, team cần thống nhất một định nghĩa rõ ràng cho component mà mình chuẩn bị xây dựng. Đây là bước quan trọng để đảm bảo sự nhất quán trong toàn bộ quá trình phát triển..

Ví dụ: Huy hiệu (Badge) là một thành phần giao diện người dùng (UI component) dùng để hiển thị thông tin bổ sung hoặc biểu thị trạng thái liên quan đến các thành phần khác trong giao diện. Đây là dạng nhãn chỉ đọc, không có tính tương tác, thường được sử dụng để làm nổi bật số lượng, trạng thái hoặc phân loại nội dung một cách trực quan.

Cách sử dụng (Usage)

Viết mô tả về cách sử dụng cho component là một bước rất quan trọng trong quá trình xây dựng Design System. Đây cũng chính là điểm khác biệt lớn giữa Design System và UI Kit. Trong quá trình tham khảo, có thể thấy nhiều UI Kit thường thiếu phần mô tả hoặc chỉ ghi chú sơ sài, dẫn đến việc sử dụng component không đúng mục đích và thiếu nhất quán giữa các nhà thiết kế trong team.

Vấn đề này càng trở nên nghiêm trọng hơn ở những team đông người, khi mỗi designer có thể hiểu và áp dụng component theo cách riêng. Việc bổ sung phần mô tả sử dụng rõ ràng sẽ giúp đảm bảo tính thống nhất, giảm sai sót và nâng cao hiệu quả phối hợp trong toàn bộ quá trình thiết kế.

Mô tả cách sử dụng nên bao gồm:

• Khi nào nên sử dụng: Liệt kê các trường hợp nhà thiết kế nên sử dụng component.

• Khi nào không nên sử dụng: Liệt kê các trường hợp cần tránh, không nên sử dụng component.

• Tài liệu tham khảo (nếu có): Liệt kê những Design System mà bạn sử dụng làm cảm hứng thiết kế

Giải phẫu (Anatomy)

Tiếp theo, hãy đi sâu vào phần “giải phẫu” của component, tức là cấu trúc bên trong và cách các phần của nó kết hợp với nhau. Ở bước này, hình ảnh minh họa là bắt buộc. Đừng chỉ mô tả bằng lời; một sơ đồ hoặc ảnh chụp trực quan sẽ giúp người đọc hiểu nhanh hơn rất nhiều về cách component của bạn được tạo nên và hoạt động ra sao.

Loại (Type)

Tiếp theo, bạn hãy trình bày các type đã được xác định trong tài liệu Definition mà nhóm đã thống nhất từ trước. Chỉ nên chọn những type thật sự phù hợp với sản phẩm để đảm bảo hệ thống thiết kế gọn gàng, hiệu quả và tránh lãng phí thời gian cũng như chi phí cho các trường hợp không cần thiết.

Khi mô tả từng type, hãy kèm theo hình ảnh minh họa và phần mô tả ngắn gọn về ngữ cảnh, mục đích sử dụng hoặc hành vi đặc trưng của type đó. Cách trình bày trực quan này sẽ giúp người đọc nhanh chóng hiểu được sự khác biệt giữa các type và dễ dàng áp dụng trong thực tế thiết kế.

Biến thể (Variant)

Bạn hãy mô tả rõ các biến thể mà component có thể có, chẳng hạn như kích thước, trạng thái, có hoặc không có icon. Giống như khi xác định type, chỉ nên chọn những biến thể thực sự phù hợp với sản phẩm của công ty để đảm bảo tính nhất quán và tránh lãng phí tài nguyên thiết kế.

Với mỗi biến thể, nên bổ sung hình ảnh minh họa cùng phần mô tả ngắn gọn về mục đích và ngữ cảnh sử dụng, giúp người đọc dễ dàng hiểu và áp dụng trong quá trình thiết kế thực tế.

Bố cục (Layout)

Tương tự, bạn hãy mô tả rõ cách sắp xếp component trong giao diện để đảm bảo tính nhất quán và dễ sử dụng. Hãy trình bày các thông tin như hướng sắp xếp (ngang hay dọc), vị trí của component trong layout, cũng như khoảng cách giữa các phần tử khi có nhiều mục tiêu được đặt cạnh nhau.

Việc thể hiện trực quan bằng hình ảnh hoặc sơ đồ sẽ giúp người xem dễ hiểu hơn về logic bố cục và cách component hoạt động trong ngữ cảnh thực tế của sản phẩm.

Hành vi (Behavior)

Bạn hãy mô tả chi tiết về hành vi của component trong quá trình tương tác. Hãy thể hiện rõ cách component thay đổi bố cục ở từng trạng thái, cách nó phản hồi khi người dùng thao tác, cũng như các hiệu ứng chuyển động hoặc hoạt ảnh khi hiển thị.

Việc làm rõ hành vi giúp người thiết kế và lập trình viên hiểu được trải nghiệm mà component mang lại, từ đó đảm bảo sự thống nhất trong cách triển khai trên giao diện thực tế.

Nguyên tắc nội dung (Content Guidelines)

Hãy xác định rõ các nguyên tắc về nội dung được sử dụng trong component, chẳng hạn như cách viết label, độ dài tối đa của văn bản, hoặc cách hiển thị khi nội dung vượt quá giới hạn…

Những quy định này sẽ giúp UX Writer và Content Designer dễ dàng phối hợp, đảm bảo nội dung luôn nhất quán, dễ hiểu và phù hợp với không gian thiết kế. Việc thống nhất từ đầu cũng giúp tiết kiệm thời gian chỉnh sửa và giữ trải nghiệm người dùng liền mạch hơn.

Ví dụ về sử dụng

Cuối cùng, bạn hãy trình bày các ví dụ cụ thể về cách sử dụng component trong thực tế. Có thể thể hiện dưới dạng Do – Don’t để làm rõ những cách dùng đúng và sai, hoặc bổ sung thêm các hình ảnh minh họa từ sản phẩm thực tế kèm phần mô tả ngắn gọn cho từng trường hợp.

Cách tiếp cận này giúp người đọc hiểu rõ hơn về mục đích, giới hạn và cách áp dụng component trong ngữ cảnh thiết kế thật. Ở GLORY, tụi mình thường kết hợp cả hai dạng, vừa Do – Don’t, vừa ví dụ minh họa từ sản phẩm thực tế để truyền tải nội dung một cách rõ ràng và trực quan nhất.

Những điều cần được giải quyết trong tương lai

Bạn có thể ghi lại những vấn đề cần giải quyết trong thời gian tới, chẳng hạn như các trường hợp chưa thể xử lý ngay hoặc những type, variant sẽ được bổ sung trong tương lai. Đây chính là nền tảng để team design tiếp tục phát triển và hoàn thiện các phiên bản component sau này, giúp hệ thống thiết kế ngày càng đầy đủ và nhất quán hơn.

Tải mẫu [Component] - Document

Vậy là chúng ta đã hoàn tất Phần 2 của hành trình Nghiên cứu và Xác định. Ở phần tiếp theo, mình sẽ cùng bạn khám phá quy trình triển khai và thiết kế các component trên Figma, xem cách biến ý tưởng thành các module thực tế. Hãy cùng theo dõi nhé!

Design System (gọi tắt là DS) ngày nay đã trở thành một khái niệm quen thuộc trong lĩnh vực Product Design. Tuy nhiên, việc xây dựng một DS bài bản, đáp ứng các tiêu chí về khả năng tái sử dụng, dễ bảo trì và linh hoạt nâng cấp vẫn là một thách thức lớn đối với nhiều đội ngũ thiết kế.

Trong series “Xây dựng Design System”, mình sẽ chia sẻ những kinh nghiệm thực tế khi phát triển DS tại GLORY. Hệ thống thiết kế mà chúng mình xây dựng có tên là Stella.

Dự kiến series này bao gồm 6 phần:

• Phần 1: Những thiết lập ban đầu

• Phần 2: Nghiên cứu và Xác định

• Phần 3: Triển khai và Thực hiện

• Phần 4: Delivery và Handoff

• Phần 5: Bảo trì và Cải tiến

• Phần 6: Tổ chức Design System trên Figma

Phân biệt Design System và UI Kit

Khi lướt qua các group và đọc các case study, mình thấy nhiều designer vẫn nhầm lẫn giữa Design System và UI Kit. Dù không ảnh hưởng nhiều ở công ty nhỏ, sự nhầm lẫn này dễ gây khó khăn tại các tổ chức có Design Maturity cao.

Chính vì vậy, mình muốn nhấn mạnh lại hai khái niệm này để các bạn có thể phân biệt rõ giữa Design System và UI Kit trước khi bắt đầu xây dựng hệ thống thiết kế một cách bài bản.

Design System là gì?

Design System là một tập hợp toàn diện các quy tắc, nguyên tắc, thành phần và tài liệu hướng dẫn giúp đảm bảo tính nhất quán trong thiết kế và phát triển sản phẩm.

Bao gồm:

• Thành phần UI: nút, biểu mẫu, bảng, v.v.

• Hướng dẫn sử dụng: cách dùng màu sắc, typography, khoảng cách, v.v.

• Nguyên tắc thiết kế: triết lý thiết kế, accessibility, responsive, v.v.

• Tài liệu kỹ thuật: cách triển khai các thành phần bằng code (React, Vue, v.v.)

• Quy trình làm việc: cách cập nhật, kiểm thử, quản lý phiên bản

Ví dụ nổi bật: Material Design của Google, Carbon Design của IBM, Fluent Design của Microsoft.

UI Kit là gì?

UI Kit là một tập hợp các yếu tố giao diện người dùng được thiết kế sẵn, thường dưới dạng file thiết kế (Figma, Sketch, Adobe XD) để giúp các nhà thiết kế tạo mockup nhanh chóng.

Bao gồm:

• Các thành phần giao diện như nút, biểu mẫu, icon, card, v.v.

• Không nhất thiết có tài liệu hướng dẫn hoặc quy tắc sử dụng

• Thường là phần hình ảnh, không có mã nguồn đi kèm

Ví dụ: Bộ UI Kit cho ứng dụng ngân hàng, UI Kit cho dashboard quản trị, v.v.

Các quy tắc xây dựng Design System

Đương nhiên rồi, trước khi bắt đầu xây dựng các component trên Figma hay bất kỳ nền tảng nào khác, chúng ta cần xác lập các quy tắc nền tảng để đảm bảo tính nhất quán trong suốt quá trình phát triển Design System. Một số danh mục quan trọng cần được xác định bao gồm:

• Giới thiệu chung về DS (About Design System)

• Nguyên tắc thiết kế (Design Principles)

• Các yếu tố cơ bản (Basic Elements)

Stakeholders tham gia xây dựng DS

Việc xây dựng Design System là một quá trình phức tạp, đòi hỏi sự phối hợp của nhiều bên liên quan để đảm bảo hệ thống thiết kế được hiểu đúng, sử dụng hiệu quả và phản ánh chính xác tinh thần thương hiệu của sản phẩm hoặc doanh nghiệp. Vì vậy, trước khi bắt đầu triển khai dự án DS, team design cần xác định rõ những đối tượng liên quan và chủ động mời họ cùng tham gia đóng góp, từ việc lên ý tưởng đến hoàn thiện hệ thống để tạo ra một Design System thực sự phù hợp và bền vững.

Một số Stakeholder thường tham gia cùng team UI/UX Design như:

• Front End Developer

• Visual Designer

• UX Researcher

• Motion Designer

• Etc…

Mô tả về DS

Giới thiệu khái niệm về Design System của bạn. Nó tên gì? Xây dựng dựa trên những nguyên tắc gì? Mục đích xây dựng DS này là gì?

Cấu hình

Design System được tạo thành từ các hướng dẫn, tài nguyên thiết kế và tài nguyên triển khai.

Mục đích xây dựng

Hãy nói về các mục đích mà bạn xây dựng DS này. Ví dụ:

• Để hợp lý hóa thiết kế và phát triển để chúng tôi có thể tập trung vào việc giải quyết các vấn đề của người dùng.

• Đảm bảo tính nhất quán giúp sản phẩm và dịch vụ dễ sử dụng.

• Đạt được sự hợp tác nhóm và trải nghiệm người dùng vượt trội

• Etc…

Phạm vi áp dụng

DS này sẽ được áp dụng cho những sản phẩm và dịch vụ nào của công ty?
Nếu có thể hãy mô tả cụ thể hơn về cách áp dụng nó cho từng sản phẩm. Điều này sẽ đảm bảo được tính chính xác khi sử dụng Design System.

Nguyên tắc thiết kế

Những nguyên tắc này phản ánh tư duy thiết kế của bạn, cách bạn tiếp cận vấn đề, đưa ra giải pháp và tạo ra trải nghiệm người dùng. Đây cũng là những tiêu chuẩn mà team sử dụng để đánh giá các yếu tố thiết kế bạn tạo ra, cả về hình thức lẫn cách triển khai. Ví dụ:

• Đáng tin cậy

• Đơn giản và thân thiện với người dùng

• Đảm bảo lấy người dùng làm trung tâm

• Etc…

Nếu có thể, hãy mô tả càng chi tiết càng tốt vì đây là nền tảng quan trọng để hiểu toàn bộ DS mà bạn xây dựng.

Các yếu tố cơ bản

Sau khi đã xác lập các nguyên tắc thiết kế cho Design System, bước tiếp theo là xác định những yếu tố cơ bản tạo nên hệ thống này. Đây chính là nền tảng giúp truyền tải trực quan ngôn ngữ thiết kế mà DS hướng đến. Một vài yếu tố tiêu biểu có thể kể đến như:

• Colors

• Typography

• Design Token

• Icons

• Writing Style

• Motion

• Etc…

Chúng ta hãy tìm hiểu chi tiết hơn về cách phát triển các yếu tố cơ bản này cho DS.

Colors

Màu sắc là yếu tố then chốt trong việc truyền tải tinh thần thương hiệu và thông điệp thiết kế. Khi hiểu rõ ý nghĩa mà từng màu sắc mang lại và duy trì sự nhất quán về chức năng lẫn cảm xúc trên mọi sản phẩm và dịch vụ, chúng ta giúp người dùng dễ dàng nhận diện và tiếp cận trải nghiệm một cách rõ ràng.

Bảng màu

Khi bắt đầu xây dựng bảng màu cho DS, điểm xuất phát nên là màu sắc thương hiệu của công ty hoặc sản phẩm bạn đang thiết kế. Hãy chọn màu này làm màu chủ đạo, sau đó phát triển các màu bổ trợ xoay quanh nó, đảm bảo sự hài hòa, nhất quán và phù hợp với ngữ cảnh sử dụng trong giao diện.

Một bảng màu cơ bản thường bao gồm:

• Neutral Colors

  • White/Black

  • Neutral

• Chromatic Colors

  • Blue

  • Red

  • Green

  • Yellow

  • Etc…

Mỗi màu sắc trong bảng màu nên có từ 6-10 sắc độ, mỗi sắc độ nên bao gồm:

• Mô tả màu

• Tên màu

• Mã HEX

• Thông số RGB

• Etc…

Tips: Hiện nay, việc sử dụng plugin để tạo bảng màu từ màu gốc đã trở nên phổ biến nhờ tính tiện lợi và tốc độ xử lý. Tuy nhiên, mình vẫn khuyến khích các bạn tự xây dựng bảng màu một cách thủ công bằng cách điều chỉnh các thông số trên hệ màu như HSL, HSB… Cách làm này tuy mất thời gian hơn nhưng sẽ giúp bạn kiểm soát độ chính xác tốt hơn và giảm thiểu việc phải chỉnh sửa nhiều lần trong suốt quá trình phát triển Design System.

Hướng dẫn sử dụng

Sau khi hoàn thiện bảng màu, đừng quên viết hướng dẫn sử dụng đi kèm. Mỗi màu sắc đều mang một ý nghĩa riêng, và tài liệu hướng dẫn sẽ giúp đảm bảo tính nhất quán trong cách áp dụng màu, từ quá trình xây dựng DS cho đến thiết kế UI về sau.

Hãy đảm bảo màu sắc được sử dụng một cách nhất quán để chúng luôn truyền tải đúng thông điệp đã định. Việc lựa chọn màu cần dựa vào mục đích sử dụng cụ thể, tránh để màu sắc gây hiểu nhầm hoặc mang ý nghĩa ngoài mong muốn trong thiết kế.

Màu sắc không nên là yếu tố duy nhất dùng để phân biệt thông tin, vì bản thân nó không đủ khả năng truyền tải ý nghĩa một cách chính xác. Thay vào đó, hãy kết hợp màu sắc với các yếu tố trực quan khác như văn bản, biểu tượng hoặc hình dạng để đảm bảo người dùng dễ dàng nhận biết và hiểu đúng thông tin được truyền tải.

Khả năng tiếp cận của màu sắc

Một trong những điều rất quan trọng khi sử dụng màu sắc trong thiết kế là Khả năng tiếp cận (Accessibility). Tuy nhiên mình thấy rất nhiều designer quên hoặc cố tình bỏ qua điều này. Tại GLORY - một tập đoàn toàn cầu, việc đảm bảo Khả năng tiếp cận trong thiết kế luôn là một những tiêu chí đánh giá hàng đầu của Team Design.

Duy trì tỷ lệ tương phản tốt giữa văn bản và nền

Tỷ lệ tương phản thể hiện mức độ chênh lệch độ sáng giữa màu nền và màu chữ, giúp nội dung dễ đọc và tiếp cận hơn. Khi xây dựng bảng màu, hãy đảm bảo các cặp màu đạt tối thiểu mức AA theo tiêu chuẩn WCAG 2.2 về khả năng truy cập. Dù quy định này chủ yếu áp dụng cho văn bản, bạn cũng nên chú ý duy trì độ tương phản hợp lý cho các yếu tố phi văn bản như biểu đồ, hình ảnh hay đồ thị, đặc biệt khi chúng đóng vai trò truyền tải thông tin.

Bạn có thể sử dụng tính năng Color Check Contrast có sẵn của Figma để kiểm tra.

Một số nguồn tham khảo:

• WCAG 2.2 “Success Criterion 1.4.3: Understanding Contrast (Minimum)”: Web Content Accessibility Guidelines (WCAG) 2.2

• Large size (text): Success Criterion 1.4.3: Understanding Contrast (Minimum)

• Ameba Accessibility Guidelines: 1.4.3 Ensuring Contrast between Text and Character Images Ameba Accessibility Guidelines

Thiết kế màu sắc hỗ trợ đa dạng thị giác màu

Một số người gặp khó khăn (các bệnh về màu sắc gây ra tình trạng mù màu) khi phân biệt các tổ hợp màu, gây bất tiện trong trải nghiệm. Vì vậy, chúng ta cần thiết kế màu sắc phù hợp với đa dạng thị giác màu, đồng thời bổ sung các dấu hiệu phi màu như độ sáng, văn bản, hình dạng… để tăng khả năng nhận diện.

Sử dụng công cụ sau để mô phỏng màu sắc:

• Adobe Photoshop – Proof Colors

• Adobe Illustrator - Proof Colors

• Color Simulator (application)

Design Tokens

Design Tokens là một chủ đề khá “hóc búa” mà không ít Designer vẫn còn cảm thấy mơ hồ. Chính vì vậy, mình sẽ dành riêng một bài viết để đào sâu vào chủ đề này.

Còn trong phạm vi của series “Xây dựng Design System”, mình sẽ tập trung chia sẻ về phiên bản đầu tiên của Design Tokens mà team đã phát triển cho Stella. Hy vọng phần này sẽ giúp các bạn hình dung rõ hơn về cách áp dụng tokens vào quy trình xây dựng DS, đặc biệt là với những team đang bắt đầu chuẩn hóa hệ thống thiết kế của mình.

Vì sao Design Tokens lại cần thiết?

Mặc dù trước đây, DS được phân cấp và quản lý dựa trên phương pháp Atomic Design nhưng hiện nay, Design Tokens đang được thử nghiệm rộng rãi và tìm thấy sự cân bằng tốt hơn giữa tính linh hoạt mong muốn mà chúng mang lại và sự phức tạp của việc quản lý chúng. Nói cách khác, Token là mắt xích còn thiếu của Atomic Design.

Phiên bản đầu tiên

Mặc dù hiện tại Stella đã phát triển Design Tokens với 3 levels, nhưng ở phiên bản đầu tiên, tụi mình chỉ xây dựng 2 levels và tập trung áp dụng cho màu sắc.

Vì vậy, trong bài viết này, mình muốn chia sẻ phiên bản sơ khai nhất của quá trình phát triển Design Tokens cho DS để các bạn dễ hình dung và tiếp cận hơn khi bắt đầu xây dựng hệ thống thiết kế cho riêng mình.

Loại Tokens

Stella sử dụng hai loại token thiết kế, bao gồm:

• Primitive Tokens: Đây là loại design token cơ bản và nguyên thủy nhất, đại diện cho các giá trị cụ thể. Việc đặt tên nhất quán giúp mở rộng và bảo trì dễ dàng hơn.

• Semantic Tokens: Loại design token này được xây dựng từ các token cơ bản, bổ sung ý nghĩa thông qua thành phần hoặc ngữ cảnh. Tên gọi được đặt nhằm truyền tải rõ ràng thuộc tính, thành phần hoặc mục đích sử dụng.

Quy ước đặt tên

Hệ thống phân cấp đặt tên Semantic Token

Tên Design Tokens mô tả cách chúng được sử dụng và mỗi phần của tên truyền đạt một phần của cách sử dụng đó.

Cơ sở

Áp dụng các yếu tố như màu sắc và khoảng cách cấu thành hệ thống thiết kế, cùng với các thuộc tính xác định thành phần và kiểu thiết kế.

• Category: Tên đại diện cho các yếu tố như màu sắc, khoảng cách…

• Property: Tên biểu thị vị trí hoặc thuộc tính được đại diện bởi Category.

Objects

Áp dụng các yếu tố được định nghĩa theo Category:

• Group: Tên gọi cho các tổ hợp gồm nhiều thành phần kết hợp.

• Item: Tên gọi chỉ thành phần hoặc cách sử dụng.

• Element: Tên gọi cho các phần tử nằm trong một thành phần.

Modifier

Dưới đây là các nhóm tên thể hiện chi tiết bổ sung liên quan đến mục đích của design tokens, như biến thể hình ảnh, trạng thái thành phần hoặc kích thước:

• Variant: Tên biểu thị các biến thể khác nhau của một thành phần.

• Input state: Tên phản ánh trạng thái trước và sau khi người dùng thao tác với đối tượng.

• User state: Tên thể hiện các tương tác của người dùng với đối tượng.

• Scale: Tên biểu thị các chỉ số định lượng như kích thước hoặc tỷ lệ.

• Color: Tên đại diện cho bản thân các màu sắc.

• Emphasize: Tên thể hiện mức độ nhấn mạnh hoặc cường độ.

• Mode: Tên biểu thị các chế độ nền cụ thể (ví dụ: sáng, tối).

Lưu ý: Nếu muốn sử dụng nhiều từ trong tên token, hãy phân cách bằng dấu gạch ngang. Ví dụ: on-light, on-dark. Dùng dấu chấm để phân cấp tên theo thứ bậc. Sử dụng chữ thường cho toàn bộ tên token.

Cách đặt tên

Cách đặt tên Design Token ở trên chỉ là một trong rất nhiều cách tiếp cận. Mỗi team sẽ có phong cách và quy chuẩn riêng, nên không có một công thức cố định nào cả. Điều quan trọng là hãy cùng nhau thảo luận trong team để tìm ra cách đặt tên phù hợp nhất với DS mà bạn đang xây dựng, vừa dễ hiểu, vừa dễ duy trì về lâu dài.

Quản lí Tokens

Tại GLORY, tụi mình đã xây dựng một website quản lý tập trung dành riêng cho Stella, nơi lưu trữ và kiểm soát toàn bộ bảng Design Token một cách có hệ thống.

Tuy nhiên, nếu team bạn chưa có đủ ngân sách để đầu tư vào nền tảng riêng, vẫn hoàn toàn có thể linh hoạt quản lý hệ thống token này bằng các công cụ đơn giản như Excel, Google Sheet, hoặc sử dụng các platform chuyên dụng như Supernova. Quan trọng nhất là đảm bảo mọi người trong team đều có quyền truy cập và cập nhật dễ dàng.

Typography

Đối với Typography, các bạn cần xác định và mô tả chi tiết nhất có thể về một số mục sau đây:

• Font Family

  • Type

  • How to use

• Style

  • Font color

  • Font weight

  • Font size

  • Light height

  • Character spacing

  • Etc…

Bạn nên tham khảo WCAG 2.2 “Success Criterion 1.4.12 Text Spacing”: Web Content Accessibility Guidelines (WCAG) 2.2 để xác định các thông số cho Typography.

Nếu DS của bạn sử dụng nhiều hơn một font family, hãy dành thời gian định nghĩa rõ cách dùng cho từng loại font. Việc phân chia vai trò cụ thể, font nào dùng cho tiêu đề, font nào cho nội dung, font nào cho UI, sẽ giúp đảm bảo tính nhất quán trong toàn bộ trải nghiệm thiết kế và tránh sự lộn xộn khi triển khai trên nhiều nền tảng.

Icons

Biểu tượng (icon) là các hình ảnh hoặc ký hiệu minh họa được đơn giản hóa từ hình dạng của sự vật và đối tượng, nhằm truyền tải trực quan các lệnh, thiết bị, thư mục hoặc hành động và nội dung chung. Chúng cũng có thể được sử dụng để hiển thị thông báo và cảnh báo như lỗi hoặc nhắc nhở.

Khi xây dựng tài liệu về Icons trong Design System, bạn nên xác định rõ một số danh mục sau đây:

Loại Icons

Khi xây dựng Stella, chúng tôi thiết kế 2 loại icon chính:

• UI Icons: Biểu tượng được sử dụng để biểu thị trực quan các chức năng và thông tin trong ứng dụng.

• Application Icons: Biểu tượng dùng để đại diện cho các ứng dụng. Chúng thường được đặt trên màn hình chính của hệ điều hành và được sử dụng để khởi chạy ứng dụng. Mỗi biểu tượng nên được tạo riêng để phù hợp với chủ đề hoặc thương hiệu.

Ngoài ra, tuỳ vào sản phẩm và nhu cầu của mỗi team, bạn có thể sử dụng thêm một số loại sau đây:

• Featured icons

• Miscellaneous icons

• Social icons

• Country icons

• Integration icons

• Etc…

Cách sử dụng

Biểu tượng nên được sử dụng kết hợp với nhãn và văn bản bổ sung để tránh việc người dùng diễn giải sai lệch. Đảm bảo rằng người dùng có thể hiểu đúng ý nghĩa được truyền tải. Ví dụ:

Kết hợp biểu tượng với nhãn văn bản để thể hiện rõ ý nghĩa mà biểu tượng đại diện.

Nếu biểu tượng không đi kèm với nhãn, ý nghĩa của nó có thể không được hiểu đúng.

Việc sử dụng biểu tượng mà không có nhãn hoặc văn bản bổ sung vẫn có thể chấp nhận được trong một số trường hợp, chẳng hạn khi không gian hiển thị bị hạn chế. Trước khi áp dụng cách này, hãy cân nhắc xem liệu biểu tượng đơn lẻ có thể truyền đạt chính xác ý nghĩa trong ngữ cảnh sử dụng của người dùng hay không.

Chỉ chọn lọc những chức năng thật sự quan trọng, sau đó sử dụng biểu tượng để đại diện cho các chức năng đó.

Không nên sử dụng biểu tượng chỉ để trang trí hoặc thu hút sự chú ý. Việc lạm dụng biểu tượng có thể gây rối mắt, nhiễu thị giác và tạo cảm giác khó hiểu.

Nhóm các chức năng đại diện cho cùng một khái niệm vào một nhóm duy nhất.

Hãy gom các chức năng cùng khái niệm vào một menu bất cứ khi nào có thể. Tránh phân tách chúng thành nhiều menu riêng biệt, vì điều này có thể làm tăng sự đa dạng không cần thiết của biểu tượng.

Style

Đối với style, bạn cần xác định 2 yếu tố chính, bao gồm:

• Size: Bao gồm kích thước tiêu chuẩn (thường là 24px), kích thước tối thiểu trên mỗi thiết bị và quy tắc khi thực hiện scale icons.

• Color: Xác định một số quy tắc về màu sắc cho icons. Điều này có thể được thể hiện rõ ràng hơn ở Design Tokens

Lưu ý: Hãy thể hiện rõ hơn bằng hình ảnh nếu có thể, ví dụ như dạng DO - DON’T.

Yếu tố toàn cầu hoá

Bởi vì GLORY là một tập đoàn đa quốc gia nên chúng tôi phân phối sản phẩm tới toàn cầu. Vì vậy, chúng tôi luôn xem xét biểu tượng dưới góc nhìn toàn cầu và nỗ lực sử dụng các biểu tượng được công nhận rộng rãi trên thế giới.

Phương pháp tạo Icons

Tuỳ vào ngân sách và nguồn lực của team, bạn có thể lựa chọn sử dụng các bộ icon có sẵn (đừng quên kiểm tra kỹ vấn đề bản quyền), hoặc tự thiết kế một bộ icon riêng cho Design System. Trong quá trình phát triển Stella, team mình đã chọn phương án tự xây dựng bộ icon riêng, nhằm đảm bảo tính đồng nhất về mặt hình ảnh, đồng thời tuân thủ chặt chẽ các nguyên tắc thiết kế đã được xác lập từ đầu.

Nếu bạn quyết định tự xây dựng bộ icon riêng, hãy lưu ý một số danh mục sau:

Icon grid

Lưới biểu tượng được cấu tạo từ một ma trận gồm 24 × 24 ô vuông và bốn loại đường chuẩn. Việc sử dụng hình dạng này làm đường tham chiếu giúp tạo cảm giác đồng nhất về kích thước giữa các biểu tượng.

Layout

Layout area

Đặt trong phạm vi màu hồng (20 × 20 ô vuông) làm khu vực bố cục (có thể thực hiện bố cục trong phạm vi này).

Thiết lập vùng lề bằng diện tích tương đương hai ô vuông xung quanh biểu tượng (không được bố cục trong vùng này).

Trường hợp ngoại lệ, có thể mở rộng vùng bố cục để tạo cảm giác đồng đều về kích thước. Khi đó, cần đảm bảo thiết lập vùng lề bằng diện tích tương đương một ô vuông xung quanh biểu tượng.

Stroke

Thiết lập độ dày nét vẽ tương đương với hai ô vuông cho cả đường thẳng và đường chéo. Cạnh của nét vẽ được thể hiện như trong hình minh họa bên dưới.

Corner

Đối với góc bo, hãy nhân bán kính với giá trị bằng một nửa kích thước của một ô vuông. Ví dụ: Khi một ô vuông = 1px, thì bán kính góc bo sẽ là 0.5px.

Size

Đối với các icon thể hiện trạng thái thông qua kích thước hình minh họa, hãy thiết kế sao cho chúng không bị lệch hoặc mất cân đối khi được sắp xếp cạnh nhau với cùng một kích thước hiển thị.

Ví dụ: Icon “brightness-low” được bố trí với kích thước nhỏ hơn so với biểu tượng “brightness-high” để thể hiện mức độ sáng thấp hơn.

Các điểm cần thận trọng

Khi thiết kế icons cho Design System, hãy xác lập rõ các nguyên tắc cần tuân thủ để đảm bảo toàn bộ bộ icon giữ được sự đồng nhất. Việc này sẽ giúp hệ thống trực quan hơn, dễ nhận diện và tạo cảm giác chuyên nghiệp xuyên suốt các sản phẩm thiết kế.

Ví dụ như đối với Stella:

Biểu diễn bằng hình dạng nhìn trực diện

Không sử dụng hình ảnh biểu tượng theo kiểu ba chiều. Trường hợp không thể biểu diễn bằng hình dạng nhìn trực diện, có thể chấp nhận sử dụng hình ba chiều. Tuy nhiên, hãy đảm bảo rằng hình dạng được sử dụng đơn giản và dễ hiểu.

Giữ cho hình dạng biểu tượng đơn giản và dễ hiểu

Để đảm bảo người dùng có thể nhận diện biểu tượng một cách chính xác, tránh sử dụng các hình dạng phức tạp.

Quy ước đặt tên

Cách đặt tên

Tên biểu tượng bao gồm bốn thành phần, được nối với nhau bằng dấu gạch ngang.
Sử dụng ký tự chữ và số để đặt tên.

Các điểm cần thận trọng

Nếu không có tùy chọn chức năng, hãy tinh giản hình dạng và phong cách biểu tượng.
Không sử dụng khoảng trắng trong tên biểu tượng.
Nếu cần dùng nhiều từ trong một chức năng hoặc tùy chọn chức năng, hãy phân tách bằng dấu gạch dưới (_).
Ví dụ: caret_skip, up_right

Ví dụ đặt tên

Writing Style

Writing Style là một thành phần cốt lõi nhưng thường bị bỏ qua trong quá trình xây dựng DS. Nó không chỉ ảnh hưởng đến cách người dùng tương tác với sản phẩm mà còn định hình tính cách thương hiệu, trải nghiệm người dùng, và tính nhất quán trong giao tiếp

Cách diễn đạt, thuật ngữ và ký hiệu

Chúng ta cần xác định các quy tắc liên quan đến cách viết một số danh mục sau:

• Symbols

• Numbers

• Date and time

• Denomination'

• Amounts

• Etc…

Hướng dẫn kiểm tra nội dung viết

Bạn nên thiết lập một bộ guideline rõ ràng để kiểm tra và duy trì phong cách viết xuyên suốt toàn bộ quá trình, từ giai đoạn lên ý tưởng đến khi triển khai nội dung trong sản phẩm. Điều này sẽ giúp đảm bảo sự nhất quán về giọng điệu, ngôn ngữ và trải nghiệm người dùng trong toàn bộ hệ thống thiết kế.

Motion

Motion trong DS không chỉ là yếu tố trang trí, nó là công cụ UX mạnh mẽ giúp nâng cao trải nghiệm, điều hướng hành vi, và truyền tải cảm xúc của thương hiệu.

Quy tắc chuyển động

Khi thiết kế chuyển động cho Design System, bạn nên xây dựng một bộ nguyên tắc rõ ràng để đảm bảo tính nhất quán và an toàn trong trải nghiệm người dùng.

Đặc biệt, cần tránh sử dụng hiệu ứng nhấp nháy vượt quá ba lần mỗi giây, vì điều này có thể gây ra các phản ứng tiêu cực như đau đầu, chóng mặt, buồn nôn, thậm chí kích thích co giật ở một số người dùng nhạy cảm. Thiết kế chuyển động nên hướng đến sự tinh tế, hỗ trợ nhận thức và không gây xao nhãng. Tham khảo:( WCAG 2.3.2)

Trường độ

Thời lượng là khoảng thời gian từ khi chuyển động bắt đầu đến khi kết thúc. Có hai loại chuyển động: chuyển động vi mô (micro-animation) và chuyển động vĩ mô (macro-animation).

Cần điều chỉnh phù hợp với thông số thiết bị, hệ điều hành, kích thước màn hình và ngữ cảnh giao diện người dùng (UI).

Easing

Easing là thuật ngữ chỉ “tăng tốc và giảm tốc của chuyển động”. Việc thiết lập easing giúp mang lại cảm giác vận hành mượt mà và dễ chịu cho người dùng.

Vậy là chúng ta đã khép lại Phần 1 của hành trình Xây dựng Design System. Ở phần tiếp theo, mình sẽ tiếp tục chia sẻ về quy trình nghiên cứu và xác định cách thiết kế các Component trong hệ thống. Hứa hẹn sẽ có nhiều insight thú vị, cùng theo dõi nhé!