Xác định các quyết định, không chỉ một thư viện ảnh chụp (style gallery)
Hệ thống thiết kế không chỉ là các ảnh chụp màn hình. Nó ghi lại các quyết định lặp lại: khoảng cách giữa các phần, cách điều trị hành động chính, cách một lỗi biểu mẫu hoạt động, và ngôn ngữ được dùng sau khi thành công hoặc thất bại. USWDS mô tả design token như các bảng rời rạc cho các giá trị như kiểu chữ, khoảng cách, màu sắc, chiều cao dòng và độ mờ. Ghi lại quy tắc, mục đích, biến thể được phê duyệt và người sở hữu. Bắt đầu với phần nền tảng và năm đến tám component được dùng nhiều nhất trong các hành trình quan trọng; việc chuẩn hóa mọi trang cùng lúc thường gây ồn thay vì rõ ràng.
Ghi nhận các vai trò màu được phê duyệt, kiểu chữ, khoảng cách, đường viền, bán kính, điểm gãy (breakpoints) và các lựa chọn chuyển động mà site của bạn thực sự sử dụng.
Dùng một pattern cho một bố cục nhiệm vụ có thể lặp lại, như tạo tài khoản hoặc kết quả tìm kiếm, thay vì cho một điểm nhấn hình ảnh đơn lẻ.
Dùng token để kiểm soát các giá trị lặp lại
Design token là một tên dễ đọc liên kết với một giá trị. Design Tokens Community Group mô tả token là cách diễn đạt quyết định thiết kế độc lập nền tảng; tối thiểu, một token là tên và giá trị. Dùng tên theo mục đích như color-action-primary hoặc space-section thay vì rải các giá trị thô trong template. Giữ một bản đối chiếu được ghi chép từ token mục đích tới các giá trị gốc. Token làm cho việc thay đổi có phối hợp dễ hơn, nhưng chúng không đảm bảo độ tương phản, nhận diện thương hiệu, hay hệ tầng (hierarchy) tốt. Xác thực từng kết hợp hiển thị và trạng thái trang.
Tạo token cho các lựa chọn lặp lại, không phải mọi ngoại lệ; nếu không danh sách token chỉ bảo tồn sự không nhất quán.
Với một token được dùng rộng, liệt kê các trang bị ảnh hưởng, kiểm thử các màn hình đại diện, và cung cấp hướng dẫn di cư hoặc hoàn nguyên khi cần.
Xây component có hành vi và giới hạn rõ ràng
Component là một phần giao diện có thể tái sử dụng với hành vi, không chỉ hình dạng hình ảnh. Ghi chép cấu trúc ngữ nghĩa, đầu vào bắt buộc và tùy chọn, biến thể, hành vi đáp ứng và tất cả các trạng thái liên quan: đang tải, bị vô hiệu hóa, lỗi, rỗng và thành công. Bao gồm hành vi bàn phím và hướng dẫn nội dung. Đừng ép mọi bố cục thành một component. GOV.UK đánh giá component chia sẻ theo tính hữu ích, độc đáo, khả dụng, nhất quán và đa dụng; đó là một kỷ luật hữu ích để quyết định điều gì xứng đáng được bảo trì chung. Một component được dùng rộng có thể lan rộng một lỗi, vì vậy hãy kiểm thử nó trên những trang nơi người dùng thực sự dùng.
Liệt kê mỗi trạng thái hiển thị với người dùng và trình bày nhãn thực, văn bản dài và lỗi để giới hạn triển khai rõ ràng.
Đánh dấu rõ các biến thể cũ, nêu tên thay thế, và chỉ gỡ bỏ sau khi các hành trình bị ảnh hưởng đã được rà soát.
Đặt khả năng truy cập (accessibility) thành điều kiện phát hành
Khả năng truy cập phải được xây vào hệ thống vì các lựa chọn lặp lại có thể lặp lại các rào cản. WCAG 2.2 yêu cầu, ở Cấp độ A, vận hành bàn phím cho chức năng ngoại trừ khi đường đi chuyển động là bản chất, và yêu cầu thứ tự tiêu điểm có ý nghĩa khi trình tự quan trọng. Hãy làm các điều khiển có ngữ nghĩa, tiêu điểm hiển thị, nhãn, chuyển động tiêu điểm hợp lý, nhận diện lỗi và hoàn thành nhiệm vụ không dùng con trỏ thành một phần hướng dẫn component. Dùng kiểm tra tự động sớm, sau đó kiểm tra bằng bàn phím thủ công, zoom, đáp ứng và kiểm thử trang. USWDS cảnh báo rằng component có tính truy cập không đảm bảo một dịch vụ truy cập được; mã tùy chỉnh, nội dung, tích hợp và ngữ cảnh vẫn cần rà soát.
Xác nhận người dùng có thể tiếp cận, thao tác, hiểu và rời khỏi điều khiển mà không cần chuột hoặc bị kẹt trong tiêu điểm.
Nghĩa vụ pháp lý khác nhau theo quyền tài phán và hợp đồng. Tìm kiếm rà soát về khả năng truy cập và pháp lý khi tuân thủ là vấn đề quan trọng.
Đối xử tiêu chuẩn nội dung như tiêu chuẩn giao diện
Từ ngữ là đầu vào của component, không phải trang trí thêm sau khi thiết kế xong. Đặt quy tắc cho nhãn hành động, nhãn biểu mẫu, thông báo lỗi, tiêu đề, liên kết, thuật ngữ, ngày tháng, số liệu và chữ viết tắt. Hướng dẫn của GOV.UK ưu tiên câu chủ động và xưng hô người dùng là you khi có thể; dùng nguyên tắc ngôn ngữ rõ ràng, nhất quán, đồng thời điều chỉnh giọng điệu cho khán giả của bạn. Ghép quy tắc với một mô hình nội dung: nêu trường nào là bắt buộc, hướng dẫn chiều dài hợp lý, và điều gì xảy ra khi thông tin thiếu. Đặt hướng dẫn vào tài liệu component và quy trình CMS để biên tập viên có thể sử dụng.
Nói rõ điều gì thất bại, xảy ra ở đâu và hành động tiếp theo khi an toàn và hữu ích để làm vậy.
Giới hạn là tín hiệu để thiết kế lại hoặc viết lại, không phải là giấy phép loại bỏ ý nghĩa thiết yếu.
Quản trị hệ thống trước khi nó phát triển nhanh hơn niềm tin
Quản trị là quy trình nhẹ để xác định quyền sở hữu, yêu cầu, rà soát, phát hành và nghỉ hưu. Đặt tên người chịu trách nhiệm và một nhóm rà soát có thể mang chuyên môn thiết kế, kỹ thuật, nội dung và khả năng truy cập. Phù hợp bằng chứng với bán kính ảnh hưởng (blast radius). Một pattern cục bộ có thể cần một tuyên bố vấn đề và kiểm thử trang. Một thay đổi nút chia sẻ hoặc token nên bao gồm các hành trình bị ảnh hưởng, kiểm tra khả năng truy cập, so sánh hình ảnh, ghi chú di cư và chỉ dẫn hoàn nguyên. GOV.UK yêu cầu người đóng góp chứng minh một component hữu ích cho nhiều đội, không trùng lặp, và được thử nghiệm với người dùng đại diện; dùng đó làm mô hình thực dụng hơn là quy tắc phổ quát.
Lưu vấn đề, các phương án, quyết định, người chịu trách nhiệm, phiên bản bị ảnh hưởng và ngày rà soát ở nơi các đội có thể tìm kiếm.
Gắn nhãn thay đổi là patch, additive, hoặc breaking để người tiêu thụ biết khi nào cần di cư và khoảng thời gian tương thích.
Ngăn ngừa thoái lui trước khi phát hành
Kết nối hệ thống với quá trình bàn giao. Yêu cầu một thay đổi phải xác định các token và component bị chạm tới, sau đó kiểm thử các trạng thái bị ảnh hưởng và các trang đại diện. So sánh hình ảnh, kiểm thử tương tác, rà soát nội dung và kiểm tra khả năng truy cập tìm ra các lỗi khác nhau. Ưu tiên các hành trình có hậu quả cao cũng như những hành trình có lưu lượng lớn; truy cập tài khoản và biểu mẫu liên hệ có thể quan trọng ngay cả khi lưu lượng khiêm tốn. Điều này hỗ trợ công việc tối ưu hóa tính khả dụng chủ động và khắc phục của Status Is UP bằng cách thu hẹp phạm vi lỗi và làm cho một bản sửa được phê duyệt dễ xác minh hơn. Nó không phải là giám sát thời gian chết hay thay thế kế hoạch sự cố.
Giữ phiên bản component, kết quả kiểm thử, phát hiện, phê duyệt và bất kỳ rủi ro được chấp nhận nào cùng với hồ sơ phát hành.
Bảo lưu phiên bản ổn định trước đó và kiểm tra các bước khôi phục và xác minh đã ghi trong thời gian bảo trì rủi ro thấp.