Một giao diện bắt mắt vẫn có thể khiến người dùng mệt mỏi, nếu mỗi lần chuyển trang là một lần phải “học lại”.
Thiết kế website bao gồm rất nhiều quyết định, từ bảng màu, kiểu chữ đến cách nút bấm và form hoạt động. Khi designer và developer cùng tham gia, những lựa chọn này cần được thống nhất để các phần của website không rơi vào tình trạng “mỗi người một ý”.
Đây là vai trò của design system (hệ thống thiết kế) – nơi đội ngũ cùng tham chiếu những tiêu chuẩn về giao diện, mã nguồn và cách sử dụng các thành phần. Vậy hệ thống này gồm những gì, và sự nhất quán trong thiết kế liên quan thế nào đến trải nghiệm mua hàng?
Design system là gì?
Nhiều người hình dung design system là một file Figma chứa những nút bấm mẫu để dùng lại khi cần. Thực chất, đây là một hệ thống bao gồm tiêu chuẩn thiết kế, triết lý cốt lõi, ngôn ngữ thương hiệu, thư viện mã nguồn và cả quy trình quản trị được ghi thành tài liệu rõ ràng.
Design system đóng vai trò là “nguồn sự thật duy nhất” (Single Source of Truth), nơi designer và developer cùng tham chiếu một chuẩn chung để việc thiết kế và lập trình không rơi vào tình trạng “mỗi người một kiểu”. Một website thiếu hệ thống này giống như ngôi nhà không có bản vẽ kỹ thuật. Thợ xây tầng một đặt cửa sổ một kiểu, người xây tầng hai lại làm theo kiểu khác. Từng phần có thể trông ổn, nhưng khi ghép lại thì không còn thống nhất.
Design system, style guide và pattern library khác nhau thế nào?
Style guide tập trung vào những thuộc tính trực quan tĩnh như bảng màu, kiểu chữ, logo, hình minh họa và quy chuẩn viết nội dung. Nó giúp bạn định hình phong cách của website. Tuy nhiên các hướng dẫn này không đưa ra giải pháp lập trình cho những yếu tố đó.
Trong khi đó, pattern library tập hợp các giải pháp cho những vấn đề thiết kế lặp lại, như luồng đăng ký hay form tìm kiếm. Trọng tâm của thư viện này là bố cục và tính tương tác của một nhóm yếu tố cụ thể, để bạn có thể dùng lại khi gặp nhu cầu tương tự.
Design system bao gồm cả hai phần trên, cùng thư viện cấu phần (component) được lập trình sẵn bằng React, Vue, CSS… và quy trình bảo trì, cập nhật liên tục. Nếu style guide cho bạn biết giao diện “trông như thế nào”, design system còn trả lời nó hoạt động ra sao và ai chịu trách nhiệm duy trì.
Vì sao não bộ “khó chịu” với giao diện thiếu nhất quán?
Não phải liên tục “học lại” cách sử dụng
Não bộ con người xử lý thông tin qua hai cơ chế là Hệ thống 1 và Hệ thống 2. Hệ thống 1 hoạt động nhanh, tự động và dựa vào những thói quen đã có. Còn Hệ thống 2 xử lý chậm hơn, cần tư duy logic và tiêu tốn nhiều năng lượng.
Khi mỗi trang trên website có một kiểu nút, bảng màu hay kiểu chữ khác nhau, người dùng phải liên tục kích hoạt Hệ thống 2 để “giải mã” xem yếu tố mới xuất hiện dùng để làm gì. Quá trình này tạo ra tải nhận thức (cognitive load).
Theo các nghiên cứu về tâm lý học nhận thức, khi tải nhận thức tăng lên, những hoạt động cảm xúc tích cực trong não bộ sẽ bị dập tắt. Bạn đang hào hứng mua hàng, nhưng mỗi lần chuyển trang lại phải “học lại” giao diện. Cảm giác thích thú ban đầu cũng vì vậy mà nguội dần, khi não phải dành nhiều năng lượng cho việc tìm hiểu cách thao tác.
Người bán có thể cho rằng khách hàng “khó tính”, trong khi chính giao diện đang buộc não bộ của họ làm việc nhiều hơn mức cần thiết. Design system chuẩn hóa giao diện để đưa các thao tác về vùng xử lý tự động của Hệ thống 1, nơi chúng ta sử dụng website nhanh, nhẹ nhàng và không cần suy nghĩ về cách dùng.
Nhờ vậy, bạn có thể dành toàn bộ năng lượng cho việc đọc nội dung và ra quyết định mua hàng, thay vì phải phân tích từng phần của giao diện.
Khoảng cách và hình dạng cũng giúp não nhận diện
Các nguyên lý thị giác Gestalt lý giải cách não bộ nhóm và sắp xếp những gì chúng ta nhìn thấy. Design system vận dụng những nguyên lý này để tổ chức bố cục, từ khoảng cách giữa các phần tử đến hình dạng của nút bấm:
- Tiệm cận (Proximity): Những phần tử nằm gần nhau được não tự động nhóm thành một cụm có liên kết chức năng. Điều này lý giải vì sao khoảng cách (spacing) trong design system thường được mã hóa thành những giá trị chuẩn, như bội số của 4px hoặc 8px.
- Đồng dạng (Similarity): Khi các đối tượng có cùng màu sắc, hình dạng và kích thước, não sẽ hiểu chúng có cùng vai trò. Chẳng hạn các nút kêu gọi hành động (Call-to-Action, CTA) chính đều có chung kiểu dáng. Nhờ đó, bạn nhận ra ngay nơi có thể click mà không cần suy nghĩ.
- Trật tự & Đơn giản (Prägnanz): Não bộ có xu hướng đơn giản hóa bố cục phức tạp thành những khối đối xứng, cân bằng – nhu cầu được đáp ứng bằng hệ thống lưới (grid) và cách căn lề chặt chẽ trong design system.
Người dùng đã quen với những website khác
Theo Định luật Jakob, người dùng dành phần lớn thời gian trên những sản phẩm số khác, nên thường kỳ vọng website của bạn hoạt động theo cách họ đã quen. Chúng ta nhìn lên góc trên bên phải để tìm giỏ hàng, hoặc thấy biểu tượng thùng rác thì hiểu đó là thao tác xóa. Những cách sử dụng này vốn đã quen thuộc với người dùng.
Design system giúp chuẩn hóa các mẫu hành vi (UI Patterns) theo tiêu chuẩn chung của ngành. Khi gặp lại cách thao tác đã biết, bạn sẽ không phải học cách sử dụng từ đầu, dù đây là lần đầu tiên mình vào website đó.
Một design system gồm những gì?
Để duy trì sự nhất quán từ giao diện đến cách hoạt động, một design system đầy đủ thường có 6 lớp liên kết với nhau, từ những giá trị nền tảng đến quy trình quản trị hệ thống.
Triết lý thiết kế và các giá trị nền tảng
Design Principles (triết lý thiết kế) là những giá trị cốt lõi giúp đội ngũ đưa ra quyết định khó một cách khách quan. Khi có nhiều phương án khác nhau, bạn có thể dựa vào nguyên tắc “đơn giản trước tiên” hay “rõ ràng hơn là thời thượng” để cân nhắc, thay vì chỉ lựa chọn theo cảm nhận riêng của mình.
Design Tokens lưu trữ những giá trị nhỏ nhất của hệ thống, được đặt tên theo biến số lập trình. Đây là các thuộc tính CSS cơ bản như màu sắc, độ đậm chữ, khoảng cách, độ bo góc và đổ bóng, để chúng có thể được dùng thống nhất ở nhiều nơi.
Thư viện component và những luồng thao tác
UI Component Library, hay thư viện cấu phần, được xây theo phương pháp Atomic Design, đi từ Atoms là những thành phần không thể chia nhỏ hơn như nút bấm, ô nhập liệu hay icon, đến Molecules là nhóm kết hợp vài Atoms, chẳng hạn một ô tìm kiếm. Những cụm phức tạp hơn như thanh header được gọi là Organisms.
Tiếp theo là Templates – những khung bố cục chưa có dữ liệu thật. Cuối cùng, Pages là giao diện hoàn chỉnh mà bạn nhìn thấy. Nói cách khác, thư viện này đi từ những thành phần nhỏ nhất đến toàn bộ trang, để chúng có thể kết hợp với nhau trong cùng một hệ thống.
Pattern library chuẩn hóa các luồng phức tạp hơn, như đăng ký/onboarding hay thanh toán. Nếu form có nhiều nội dung cần điền, việc chia thành nhiều bước giúp bạn bớt ngợp khi đăng ký. Còn với thanh toán, bố cục một cột giúp người dùng thực hiện thao tác của mình nhanh hơn.
Nội dung và cách duy trì hệ thống
Content & Editorial Guidelines quy định giọng nói thương hiệu, cách đặt tiêu đề và viết nhãn nút bấm. Nếu mỗi trang lại xưng hô một kiểu, nội dung cũng sẽ thiếu nhất quán như cách dùng màu hay kiểu chữ. Vì vậy phần này cần thống nhất cách xưng “tôi” hay “bạn”, viết hoa chữ cái đầu hay toàn bộ chữ trên nút.
Governance & Tooling bao gồm các công cụ như Storybook, Zeroheight để quản lý mã nguồn, Figma UI Library cho designer, cùng quy trình đồng bộ nhằm đảm bảo code và file thiết kế luôn khớp nhau trong quá trình duy trì hệ thống.
Thiếu một trong 6 lớp trên, hệ thống vẫn có thể trông giống một design system nhưng thực chất chỉ dừng ở style guide hoặc pattern library. Điều này cũng lý giải vì sao một file giao diện đẹp chưa đủ để cả đội ngũ cùng sử dụng và duy trì lâu dài.
Các công ty lớn xây design system thế nào?
Những hệ thống đã được Google, Apple, IBM hay Shopify triển khai giúp bạn hình dung rõ hơn cách design system phục vụ từng sản phẩm. Dù cùng xây hệ thống thiết kế, mỗi công ty lại có một trọng tâm riêng.
Material Design của Google được xây trên nền tảng mô phỏng thế giới vật lý. Bạn có thể thấy điều này qua bóng đổ và những lớp chiều sâu trực quan trong giao diện. Điểm nổi bật của hệ thống là khả năng mở rộng trên hàng ngàn thiết bị Android và dịch vụ web khác nhau.
Human Interface Guidelines (HIG) của Apple đề cao sự tối giản, tinh tế và các cử chỉ vuốt chạm mượt mà. Bên cạnh đó, hệ thống đặt yêu cầu khắt khe với phản hồi xúc giác (Haptic Feedback) và cách người dùng thao tác bằng một tay trên di động.
Carbon Design System của IBM được tối ưu cho các phần mềm doanh nghiệp phức tạp như B2B, nền tảng đám mây, với thế mạnh là tổ chức những bảng dữ liệu và bộ lọc phức tạp một cách khoa học.
Với Polaris Design System của Shopify, trọng tâm nằm ở tối ưu tỷ lệ chuyển đổi cho thương mại điện tử. Quy chuẩn nội dung và trải nghiệm thanh toán được chú ý đặc biệt. Việc giúp người dùng thanh toán mượt mà cũng nhằm loại bỏ những ma sát tâm lý khi chúng ta mua hàng.
Bốn hệ thống phục vụ những mục tiêu khác nhau, nhưng đều xuất phát từ việc giảm tải nhận thức cho người dùng cuối. Điều này cũng lý giải vì sao design system gắn với cách chúng ta sử dụng sản phẩm, thay vì chỉ nằm ở hình ảnh bên ngoài.
Bắt đầu xây design system từ đâu?
Xây một design system là quá trình dài hạn, khó có thể hoàn thành chỉ trong một buổi chiều. Bạn có thể hình dung quá trình này qua 5 giai đoạn:
- UI Audit (đánh giá hiện trạng): Chụp lại toàn bộ giao diện đang có, gom những biến thể của nút bấm, kiểu chữ, bảng màu và khoảng cách. Việc đặt chúng cạnh nhau giúp cả đội ngũ nhìn rõ những điểm bất nhất đang tồn tại.
- Định nghĩa nền tảng trực quan: Bạn cần xây bảng màu chính, phụ, trung tính và màu báo trạng thái, cùng thang đo kiểu chữ tương thích với mọi kích thước màn hình và hệ thống khoảng cách dựa trên lưới cơ sở 4px hoặc 8px.
- Lập trình hóa & module hóa: Designer dựng Atoms, Molecules trong Figma dưới dạng component có nhiều biến thể linh hoạt. Developer viết code song song, chia nhỏ các thuộc tính để có thể tùy biến qua Props khi cần sử dụng cho sản phẩm của mình.
- Viết tài liệu: Đưa hệ thống lên Storybook hoặc Zeroheight. Tài liệu cần ghi rõ component dùng khi nào, khi nào không nên dùng và cách cấu hình để mọi người có thể sử dụng. Bên cạnh đó là thông tin về việc component có đạt chuẩn khả năng tiếp cận (Accessibility – WCAG) hay không.
- Triển khai & thiết lập quản trị: Thay dần component cũ bằng component mới, đồng thời lập hội đồng quản trị hệ thống (Design System Guild) gồm cả Design và Dev. Nhóm này chịu trách nhiệm duyệt mọi thay đổi để hệ thống không “phình to” ngoài kiểm soát.
Vì sao design system dễ bị bỏ dở?
Chuẩn bị quá nhiều cho những nhu cầu chưa có
Không ít đội ngũ muốn tạo component với hàng trăm biến thể để phòng mọi tình huống có thể xảy ra trong tương lai. Đây là tình trạng quá tải kỹ thuật (over-engineering). File thiết kế và mã nguồn “phình to” không cần thiết, còn chính người thiết kế cũng phải chịu thêm tải nhận thức khi sử dụng nhiều biến thể như vậy.
Để tránh việc này, bạn có thể bắt đầu với tư duy MVP: làm component đơn giản trước, chỉ bổ sung biến thể khi sản phẩm thực sự cần. Nếu cố chuẩn bị cho mọi nhu cầu từ đầu, hệ thống sẽ trở nên khó sử dụng với chính đội ngũ của mình.
Designer và developer đặt tên mỗi người một kiểu
Cùng một biến màu, designer gọi là $blue-primary nhưng developer lại đặt tên $brand-color-main trong code, khiến tính nhất quán mà design system vốn cần bảo vệ bị phá vỡ. Vì vậy bạn cần thống nhất quy chuẩn đặt tên ngay từ bước Audit. Công cụ như Figma Tokens Studio cũng giúp xuất biến trực tiếp thành file cấu hình cho lập trình viên.
Component mới liên tục được tạo ra
Khi không có quy trình phê duyệt, mỗi dự án con có thể tự vẽ hoặc code component mới thay vì kế thừa thư viện đã có. Sau một năm, hệ thống dễ trở thành “nghĩa địa cấu phần” với nhiều thành phần trùng lặp, bởi các dự án đều tự làm thêm phần của mình mà không kiểm tra những gì đã có.
Để phòng tránh, bạn cần duy trì quy trình quản trị nghiêm ngặt: kiểm tra xem thư viện hiện tại có thể tùy biến để đáp ứng nhu cầu hay không, trước khi đề xuất component mới.
Chăm chút vẻ ngoài nhưng quên khả năng tiếp cận
Khi chỉ tập trung vào hình thức, đội ngũ dễ bỏ sót độ tương phản giữa chữ và nền, hay khả năng điều hướng bằng bàn phím và trình đọc màn hình. Những yếu tố về khả năng tiếp cận này cũng cần được chú ý khi xây dựng hệ thống. Bạn cần đưa kiểm tra độ tương phản (Contrast Audit) thành tiêu chí bắt buộc trước khi xuất bản component mới, để tránh việc chỉ chăm chút vẻ ngoài.
Làm sao biết hệ thống đang có hiệu quả?
Hoàn thành thư viện và tài liệu không có nghĩa là công việc đã kết thúc. Để biết design system có giúp sản phẩm và đội ngũ làm việc tốt hơn hay không, bạn cần đánh giá định kỳ qua 5 tiêu chí:
- Tốc độ bàn giao sản phẩm: Đội ngũ có ra mắt tính năng mới nhanh hơn so với trước khi dùng design system không?
- Độ đồng bộ trực quan: Khi lướt qua 5 trang ngẫu nhiên, trải nghiệm có mượt và nhất quán để người dùng thao tác tự động bằng Hệ thống 1 không?
- Tần suất tái sử dụng: Bao nhiêu phần trăm mã nguồn của sản phẩm thực tế đang kế thừa trực tiếp từ thư viện design system?
- Sự hài lòng của đội ngũ: Designer và developer có bớt căng thẳng, phối hợp ăn ý hơn trong quá trình làm việc không?
- Tác động đến tỷ lệ chuyển đổi: Giao diện gọn gàng, giảm tải nhận thức có thực sự cải thiện mức độ tương tác và việc mua hàng cuối cùng không?
Nếu một trong 5 tiêu chí chưa đạt, đó là tín hiệu để bạn quay lại xem xét hệ thống, thay vì coi đây là lý do để bỏ cuộc.
Một website đẹp nhưng thiếu nhất quán vẫn có thể khiến người dùng mệt mỏi, bởi bộ khung phía sau chưa giúp giảm tải cho não bộ. Ngược lại, website đơn giản nhưng có design system chặt chẽ có thể khiến hành trình mua hàng gần như “vô hình”. Chúng ta thao tác nhẹ nhàng đến mức không nhận ra mình đang phải suy nghĩ nhiều.
Vì vậy trước khi đầu tư thêm cho một bản thiết kế mới, có lẽ bạn cần nhìn lại giao diện website của mình. Nó đang dựa trên một hệ thống thống nhất, hay chỉ là những mảnh rời rạc được ghép với nhau?