Nghiên cứu trước khi vẽ
Bước đầu là xác định người dùng đang cố hoàn thành việc gì, trong hoàn cảnh nào. Một ứng dụng cho nhân viên kho dùng bằng một tay khi đang bê hàng khác hoàn toàn một dashboard cho quản lý xem trên màn hình lớn — dù cả hai hiển thị cùng một dữ liệu.
Với sản phẩm đã có người dùng, dữ liệu sẵn có thường trả lời được nhiều câu hỏi: màn nào người ta bỏ giữa chừng, thao tác nào phải làm lại nhiều lần, chỗ nào có người gọi lên hỗ trợ. Với sản phẩm mới, cần phỏng vấn — nhưng phỏng vấn về việc họ đang làm hôm nay, không hỏi họ muốn tính năng gì.
Design system, không phải từng màn rời rạc
Thiết kế từng màn hình một sẽ dẫn tới ba kiểu nút bấm khác nhau trong cùng một sản phẩm. Không ai cố ý làm vậy; nó xảy ra vì mỗi màn được vẽ ở một thời điểm khác nhau bởi người khác nhau.
Design system — bộ quy tắc và thành phần dùng lại được — xử lý gốc rễ vấn đề. Nó định nghĩa màu, khoảng cách, kiểu chữ, và một tập component có trạng thái rõ ràng: bình thường, hover, disabled, loading, lỗi, và rỗng.
Trạng thái rỗng và trạng thái lỗi là hai thứ hay bị bỏ quên nhất trong file thiết kế, và cũng là hai thứ người dùng gặp đúng vào lúc họ bối rối nhất. Một màn hình danh sách chưa có dữ liệu cần nói cho người dùng biết phải làm gì tiếp theo, chứ không nên chỉ là khoảng trắng.
Bàn giao cho đội phát triển
Thiết kế chỉ có giá trị khi nó được dựng ra đúng. Vì vậy bản bàn giao gồm file Figma với component và token đầy đủ, đặc tả trạng thái tương tác, quy tắc responsive cho từng breakpoint, và ghi chú về accessibility — thứ tự tab, nhãn cho screen reader, độ tương phản màu.
Khi 9S làm cả thiết kế lẫn phát triển, design system được chuyển thẳng thành biến CSS và component code, nên thứ chạy trên production khớp với thứ trong file thiết kế.