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 đó.
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.
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.
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
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ũ.
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ị.
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ị.
Chủ đề: Nên làm design system sớm hay chờ sản phẩm ổn định. Cẩm nang Sinh Vũ, sinhvu.com
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.
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.
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).
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.
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.