Chuyên môn · Có nên làm và làm khi nào

Làm design system sớm hay chờ sản phẩm ổn định

Câu trả lời không phải sớm hay muộn, mà là làm ở mức nào và lúc nào thì đúng mức đó.

Chốt nhanh

Nếu sản phẩm còn đang tìm hình hài, làm hệ thống thiết kế đầy đủ ngay lúc này là trừu tượng hóa non, dễ khóa cứng những quyết định chưa nên khóa. Tuy nhiên, đừng chờ đến khi nợ giao diện chồng chất rồi mới bắt đầu, vì lúc đó chi phí chuyển đổi sẽ cao hơn nhiều. Hướng đúng là chuẩn hóa dần theo mức độ chín của sản phẩm: làm nền tảng token khi màu và font đã chốt, còn hệ thống component đầy đủ thì để dành cho lúc các mẫu giao diện đã lặp lại và đứng yên.

Đối sánh nhanh
Nên chọn hướng này khi
  • màu và font đã chốt dù component còn thay đổi
  • sản phẩm đã ổn định, các mẫu giao diện lặp lại rõ
  • chuẩn hóa dần từng đợt thay vì làm hết ngay
Chưa cần khi
  • sản phẩm còn khám phá, mỗi tuần một hình hài
  • sản phẩm chưa có người dùng thật

Câu hỏi này thường được đặt ra ở hai đầu cực: một bên muốn làm hệ thống thiết kế (design system, tức bộ quy tắc và thư viện dùng chung cho giao diện) ngay từ đầu để mọi thứ gọn gàng, một bên muốn chờ đến khi sản phẩm chắc chắn rồi mới đầu tư. Cả hai đều có thể đúng, và cũng đều có thể sai, tùy vào giai đoạn sản phẩm đang đứng.

Vì sao làm quá sớm lại nguy hiểm

Khi sản phẩm còn ở giai đoạn khám phá, tức là chưa biết chắc người dùng cần gì, luồng trải nghiệm còn thay đổi mỗi tuần, thì dựng một thư viện component đầy đủ ngay lúc này là trừu tượng hóa non. Anh / Chị đang bỏ công xây quy tắc cho những quyết định chưa nên khóa.

Kết quả thường thấy: khi sản phẩm cần xoay hướng, cả thư viện phải làm lại. Tệ hơn, nhóm thiết kế bắt đầu bị ràng buộc bởi hệ thống đã dựng và ngại thay đổi dù biết cần thay. Dan Mall gọi đây là "tối ưu sớm" (premature optimization), một dạng lãng phí mà chi phí thực không hiện ra ngay mà tích lại dần.

Đừng bắt đầu bằng cách dựng nút và component. Hãy dựng luồng thật rồi làm ngược lại: khi thấy tái sử dụng mới rút xuống thành mẫu chung. Trừu tượng hóa nên đến sau khi thấy sự lặp lại, không phải trước.

Brad Frost, Atomic Design

Vì sao chờ quá lâu cũng đắt giá

Ngược lại, nếu Anh / Chị để sản phẩm chạy mà không có bất kỳ quy chuẩn nào, nợ giao diện (design debt, tức sự không nhất quán và mã giao diện rối tích lũy theo thời gian) sẽ phình ra từng ngày. Khi nhóm dựng cùng một loại nút theo ba cách khác nhau ở ba màn hình, hay khi sửa màu ở một chỗ mà không biết còn bao nhiêu chỗ khác cần sửa theo, đó là nợ giao diện đang chạy.

Chuyển đổi từ trạng thái nợ chồng chất sang hệ thống có trật tự tốn nhiều hơn so với chuẩn hóa dần khi các mẫu vừa đủ chín. Lúc đó không chỉ tốn công xây hệ thống mới mà còn phải dọn sạch cái cũ.

Cách chia theo mức thay vì chọn cực đoan

Sinh Vũ không khuyên chọn một trong hai đầu cực. Thay vào đó, câu hỏi đúng là: phần nào của hệ thống có thể làm ngay vì đã ổn định, phần nào nên chờ vì còn biến động.

Mức 1: Nền tảng token (token là các giá trị nguyên tử như màu, font, khoảng cách được đặt tên và dùng chung). Có thể làm sớm ngay cả khi sản phẩm còn thay đổi, vì màu thương hiệu và font chữ thường chốt trước component. Đây là mức ít rủi ro nhất và mang lại nhất quán tức thì.

Mức 2: Hệ thống component đầy đủ. Để dành cho khi sản phẩm đã có người dùng thật, nhịp phát triển đã đều, và Anh / Chị thấy cùng một loại thành phần giao diện xuất hiện lặp đi lặp lại ở nhiều nơi. Lúc đó rút ra thành component mới có giá trị.

Sinh Vũ tiếp cận như thế nào

Trước khi đề xuất bắt đầu ở mức nào, Sinh Vũ luôn rà soát giao diện hiện có để tách phần đã đứng yên khỏi phần còn biến động. Chỉ hệ thống hóa những gì đã ổn định, không hệ thống hóa toàn bộ cùng lúc.

Với sản phẩm chưa có người dùng thật, lời khuyên thẳng thắn là: tập trung làm cho sản phẩm chạy và tìm được người dùng trước. Đầu tư vào hệ thiết kế số ở giai đoạn này thường không sinh lợi bằng đầu tư vào sản phẩm. Khi sản phẩm đã có tín hiệu thật từ thị trường và nhóm bắt đầu dựng lại cùng một thứ theo nhiều cách khác nhau, đó là lúc hệ thống hóa có giá trị.

Lỗi hay gặp khi quyết định thời điểm

  • Hiểu nhầm rằng phải làm tuần tự từ nguyên tử nhỏ nhất lên mới đúng. Thực tế, quá trình thường là song song và rút dần từ những gì đã xây trong thực tế.
  • Chờ đến khi "hoàn toàn sẵn sàng" rồi mới làm một lần, trong khi chuẩn hóa từng phần theo đợt thường hiệu quả hơn và ít rủi ro hơn.
  • Nhầm lẫn giữa tài liệu hóa giao diện hiện tại với xây hệ thống thiết kế. Đó là hai việc khác nhau, chi phí và giá trị cũng khác nhau.
Công cụ mang về

Checklist quyết định

Chủ đề: Nên làm design system sớm hay chờ sản phẩm ổn định. Cẩm nang Sinh Vũ, sinhvu.com

0 trên 6 mục

Bấm chọn từng mục Anh / Chị thấy đúng, rồi bấm in hoặc lưu thành PDF để mang theo.

Dấu hiệu cho thấy Anh / Chị nên làm
Câu hỏi cần trả lời trước khi quyết định

Nếu Anh / Chị đánh dấu phần lớn ở nhóm dấu hiệu trên, đây là lúc nên trao đổi kỹ hơn. Sinh Vũ có thể cùng Anh / Chị soi lại và đề xuất hướng đi.

Nguồn tham khảo

Dan Mall, Beware premature optimization, Practical Design Systems. Brad Frost, Atomic Design. Sinh Vũ, tài liệu dịch vụ A3 (ba mức tiếp cận, rà soát trước khi hệ thống hóa).

Câu hỏi thường gặp

Startup mới ra mắt có nên làm design system ngay không?

Nếu sản phẩm chưa có người dùng thật và hình hài còn thay đổi mỗi tuần, chưa nên làm hệ thống component đầy đủ. Tập trung làm sản phẩm chạy trước. Việc có thể làm ngay là chốt màu, font và khoảng cách cơ bản thành token nền tảng, vì các thứ đó ít thay đổi hơn và giúp nhóm giữ nhất quán ngay cả khi component còn biến động.

Dấu hiệu nào cho thấy đã đến lúc làm design system?

Ba dấu hiệu rõ nhất: các mẫu giao diện lặp lại ở nhiều màn hình và nhóm bắt đầu dựng lại cùng một thứ theo nhiều cách khác nhau; sản phẩm có người dùng thật và nhịp phát triển đã đều hơn; khi sửa một chỗ thì các chỗ khác bị lệch theo và mất thời gian kiểm tra thủ công. Khi ba dấu hiệu này xuất hiện cùng lúc, chi phí chưa có hệ thống bắt đầu vượt chi phí xây.

← Về Hệ thiết kế số
{INJ}