Thiết kế giao diện và mẫu thiết kế API thành phần cho hệ thống thiết kế

Giao diện mà người dùng có thể sử dụng không chỉ phụ thuộc vào sự nhất quán về hình ảnh mà còn phụ thuộc vào hành vi có thể dự đoán được: cùng một đầu vào sẽ cho ra cùng một kết quả, cùng một trạng thái sẽ hiển thị và hoạt động giống nhau, và một thành phần vẫn phải dễ hiểu khi chuyển đổi giữa bản thiết kế, mã nguồn và các nhóm sản phẩm. Bài viết này giải thích các mẫu thiết kế API thành phần cho hệ thống thiết kế giúp nhà thiết kế và kỹ sư cùng xác định biến thể, trạng thái và quy tắc tổng hợp.

Bắt đầu bằng một hợp đồng, không phải một thành phần

API thành phần là một hợp đồng giữa những người thiết kế giao diện và những người triển khai nó. Hợp đồng mô tả những gì có thể thay đổi, những gì phải giữ nguyên và các phần liên quan với nhau như thế nào. Hãy coi hợp đồng như một bộ từ vựng nhỏ thay vì một tập hợp các props không liên quan.

Hãy bắt đầu bằng cách nêu mục đích của thành phần trong một câu. Một nút bấm kích hoạt một hành động. Một hộp thoại ngắt task hiện tại bằng một quyết định tập trung. Một thẻ nhóm các nội dung liên quan và các hành động tùy chọn. Mục đích sẽ giới hạn API. Nếu một biến thể được đề xuất không giúp thành phần thực hiện mục đích của nó, có thể nó thuộc về một thành phần bọc hoặc một thành phần khác.

Tách biệt ba loại quyết định:

• Ý nghĩa ngữ nghĩa: những gì người dùng đang cố gắng thực hiện, chẳng hạn như hành động chính, hành động phá hủy hoặc hành động phụ.
• Xử lý hình ảnh: cách thể hiện ý nghĩa thông qua màu sắc, khoảng cách, typography và mật độ.
• Trạng thái hành vi: cách thành phần phản hồi với tương tác, tải dữ liệu, xác thực và focus.

Giữ ý nghĩa ngữ nghĩa trong API công khai. Để các token thiết kế v�� theme chuyển ý nghĩa thành xử lý hình ảnh. Hiển thị trạng thái hành vi thông qua các giá trị rõ ràng, có thể kiểm tra thay vì các cờ suy luận.

Xác định biến thể dựa trên ý nghĩa

Biến thể hữu ích khi chúng truyền tải một sự khác biệt có ý nghĩa. Một mẫu dự đoán là sử dụng một tập nhỏ các giá trị ý nghĩa như mặc định, chính, phụ, yên tĩnh và phá hủy. Những tên này vẫn ổn định ngay cả khi thương hiệu thay đổi màu sắc hoặc hình dạng.

Tránh các biến thể mô tả chi tiết triển khai. Các tên như xanh-lớn hoặc bo-góc-2 gắn API với một hệ thống hình ảnh cụ thể và khiến việc thay đổi trong tương lai tốn kém. Thay vào đó, kết hợp ý nghĩa với các trình sửa đổi được kiểm soát khi sự khác biệt thực sự rõ ràng, chẳng hạn như kích thước (nhỏ, trung bình, lớn) hoặc mức độ nhấn mạnh (thấp, trung bình, cao).

Tài liệu hóa các tổ hợp được phép. Hệ thống thiết kế nên khiến các tổ hợp không hợp lệ khó thể hiện. Nếu “phá hủy” và “yên tĩnh” không thể cùng tồn tại, API nên từ chối tổ hợp đó hoặc xác định quy tắc ưu tiên rõ ràng. Khi hai giá trị xung đột, hãy chỉ ra giá trị nào thắng và tại sao. Sự dự đoán đến từ các quy tắc rõ ràng, không phải từ việc hy vọng người dùng sẽ tự đoán.

Mô hình hóa trạng thái dưới dạng tập hợp hữu hạn

Trạng thái nên là hữu hạn, có thể quan sát và được hiểu chung. Một bộ cơ sở hữu ích bao gồm nghỉ, di chuột, focus, active, bị vô hiệu hóa, đang tải và lỗi. Không phải thành phần nào cũng cần tất cả trạng thái, nhưng mỗi trạng thái tồn tại nên có xử lý hình ảnh, hành vi tương tác và cân nhắc về khả năng truy cập được xác định.

Tách biệt “bị vô hiệu hóa” khỏi “đang tải”. Một điều khiển bị vô hiệu hóa là không khả dụng; một điều khiển đang tải đang hoạt động và nên truyền tải tiến trình. Tách biệt “lỗi” khỏi “không hợp lệ”. Lỗi truyền tải một vấn đề cần sự chú ý, trong khi không hợp lệ có thể mô tả một điều kiện xác thực rộng hơn. Các tên chính xác giảm thiểu sự mơ hồ trong các buổi đánh giá thiết kế và triển khai.

Xác định các chuyển đổi giữa các trạng thái. Ví dụ, một nút bấm có thể chuyển từ nghỉ sang di chuột khi con trỏ di chuyển, sang active khi nhấn, và sang đang tải khi hành động bắt đầu. Trạng thái đang tải nên giữ nguyên kích thước của thành phần để tránh dịch chuyển bố cục. Focus nên luôn hiển thị ngay cả khi thành phần đang tải hoặc bị vô hiệu hóa, trừ khi hướng dẫn khả năng truy cập yêu cầu rõ ràng ngược lại.

Làm rõ thứ tự ưu tiên của trạng thái. Nếu một thành phần vừa đang tải vừa bị vô hiệu hóa, hãy chỉ ra xử lý nào được ưu tiên. Nếu lỗi xuất hiện khi thành phần đang focus, hãy quyết định thông báo lỗi hay chỉ báo focus được hiển thị trước. Các quy tắc này ngăn nhà thiết kế và kỹ sư đưa ra các lựa chọn mâu thuẫn.

Sử dụng tổng hợp cho cấu trúc

Tổng hợp giữ cho thành phần linh hoạt mà không biến nó thành một mê cung cấu hình. Thay vì hiển thị hàng chục props cho mọi bố cục có thể có, hãy cung cấp các slot ổn định hoặc vai trò con. Một hộp thoại có thể tổng hợp tiêu đề, mô tả, nội dung chính và các hành động. Một bảng có thể tổng hợp header, hàng, ô và toolbar.

Các quy tắc tổng hợp nên trả lời ba câu hỏi:

• Cái gì là bắt buộc?
• Cái gì là tùy chọn?
• Thứ tự hoặc mối quan hệ giữa các phần là gì?

Ví dụ, một hộp thoại có thể yêu cầu tiêu đề và một hành động, cho phép mô tả và các hành động bổ sung, và đặt tiêu đề trước nội dung chính. Thành phần có thể xác thực các mối quan hệ này trong quá trình phát triển và cung cấp giá trị mặc định hợp lý khi phù hợp.

Ưu tiên slot có tên hơn là con theo vị trí khi bố cục quan trọng. Slot có tên giúp ý nghĩa rõ ràng trong mã nguồn và giảm nguy cơ một phần tử con mới thay đổi bố cục một cách vô tình. Khi các phần tử con linh hoạt, hãy tài liệu hóa loại nội dung và hành vi tương tác được mong đợi. Một footer slot chấp nhận nút bấm không nên ngầm chấp nhận các liên kết tùy ý nếu điều đó sẽ phá vỡ thứ tự bàn phím.

Viết các quy tắc mà nhà thiết kế và kỹ sư cùng sử dụng

Tài liệu API tốt là một tài liệu tham khảo chung, không phải một bản giao phó. Bao gồm một tuyên bố mục đích ngắn, bảng biến thể, ma trận trạng thái và các ví dụ tổng hợp. Hiển thị một ví dụ tối thiểu và một trường hợp biên, chẳng hạn như nhãn dài, hành động bị vô hiệu hóa hoặc thông báo lỗi. Giải thích những gì thành phần đảm bảo: thứ tự focus, kích thước mục tiêu tối thiểu, hành vi tràn nội dung và liệu thành phần có tự kiểm soát bố cục của mình hay không.

Sử dụng token thiết kế cho các giá trị nên được đồng bộ trên các công cụ. Khoảng cách, typography, vai trò màu sắc, th���i lượng chuyển động và độ cao nên đến từ cùng một nguồn trong thiết kế và mã nguồn. Khi một token thay đổi, cả hai phía của hệ thống nên được cập nhật mà không cần viết lại API ngữ nghĩa của thành phần.

Thử nghiệm hợp đồng. Thêm kiểm tra hình ảnh cho mọi trạng thái được tài liệu hóa, kiểm tra tương tác cho các chuyển đổi và kiểm tra khả năng truy cập cho focus, nhãn và thông báo. Đánh giá các biến thể mới theo các quy tắc trước khi hợp nhất. Một API nhỏ, kỷ luật dễ học hơn, dễ kiểm tra hơn và có khả năng phục hồi tốt hơn khi sản phẩm phát triển.

Mục tiêu không phải là loại bỏ sự linh hoạt. Mục tiêu là làm cho sự linh hoạt trở nên có thể dự đoán được. Khi nhà thiết kế và kỹ sư đồng thuận về ý nghĩa, trạng thái và quy tắc tổng hợp, thiết kế giao diện trở thành một hệ thống mà mọi người có thể sử dụng một cách tự tin.