Bắt đầu với yêu cầu sản phẩm

Hệ thống UI/UX nâng cao và wireframe nên bắt đầu từ một định nghĩa vấn đề thống nhất, thay vì một tập hợp các màn hình được trau chuốt. Hãy viết bằng ngôn ngữ dễ hiểu về người dùng chính, tác vụ, ràng buộc kinh doanh và tín hiệu thành công trước khi mở công cụ thiết kế. Với một dashboard thuê bao, tác vụ có thể là tìm hóa đơn tiếp theo và tải xuống, trong khi ràng buộc là dữ liệu thanh toán đến từ một API hiện có. Cách định khung này giúp hệ thống tập trung vào những quyết định người dùng cần đưa ra thay vì các pattern mang tính trang trí.

Hãy chuyển bản tóm tắt thành danh mục màn hình và nội dung trước khi vẽ layout. Với một luồng thanh toán, danh mục có thể bao gồm danh sách hóa đơn, màn hình chi tiết hóa đơn, thao tác tải xuống và trạng thái xác nhận. Ghi lại dữ liệu nào là bắt buộc, thao tác nào là chính và điều gì xảy ra khi thiếu dữ liệu hoặc request thất bại. Bản đặc tả nhỏ này giúp phát hiện sớm các khoảng trống và ngăn wireframe trở thành một tập hợp rời rạc gồm những màn hình bắt mắt.

Lập bản đồ user flow và kiến trúc thông tin

Hãy lập bản đồ tác vụ dưới dạng một chuỗi quyết định của người dùng, bao gồm điểm bắt đầu, kết quả thành công, các gián đoạn và những đường dẫn khôi phục. Bắt đầu từ hành động có ý nghĩa đầu tiên, chẳng hạn như chọn Quên mật khẩu, rồi tiếp tục qua các bước gửi email, xác minh, tạo mật khẩu mới và xác nhận. Với mã xác minh gồm sáu chữ số, hãy đưa vào các trạng thái mã không chính xác, hết hạn và gửi lại, thay vì chỉ lập bản đồ cho đường dẫn lý tưởng. Đánh dấu rõ các điểm quyết định để những wireframe sau này thể hiện đúng quy trình thực tế, thay vì một happy path chưa đầy đủ.

Chuyển flow đã được xác thực thành kiến trúc thông tin bằng cách nhóm nội dung và thao tác có liên quan. Một dashboard phân tích có thể sắp xếp khoảng thời gian, bộ lọc tài khoản, biểu đồ, bảng và thao tác xuất dữ liệu theo một cấu trúc phân cấp hỗ trợ cả việc quét nhanh lẫn xử lý chi tiết. Giữ cho nhãn điều hướng nhất quán với ngôn ngữ người dùng gặp trong sản phẩm, đồng thời đặt các tác vụ liên quan cạnh nhau thay vì nhóm màn hình theo quyền sở hữu của từng team nội bộ. Khi một flow yêu cầu người dùng liên tục quay lại các bước trước, hãy đơn giản hóa cấu trúc phân cấp trước khi thêm các thành phần giao diện khác.

Xây dựng wireframe theo mức độ trung thực

Sử dụng wireframe độ trung thực thấp để kiểm thử cấu trúc, mức độ ưu tiên và luồng thao tác trước khi dành thời gian cho phần tạo kiểu trực quan. Ở giai đoạn này, các hình chữ nhật, khối văn bản giữ chỗ và những điều khiển đơn giản là đủ để kiểm tra xem người dùng có thể xác định hành động tiếp theo hay không. Với luồng đặt chỗ trên thiết bị di động, hãy phác thảo phần tìm kiếm điểm đến, chọn ngày, số lượng khách, kết quả và xem lại đặt chỗ thành năm khung được kết nối. Không tinh chỉnh màu sắc hoặc đổ bóng khi thứ tự của các màn hình đó vẫn chưa chắc chắn, vì việc trau chuốt giao diện có thể che giấu một mô hình tương tác yếu.

Chuyển sang wireframe độ trung thực trung bình khi luồng chính đã ổn định và độ dài nội dung bắt đầu ảnh hưởng đến bố cục. Thêm nhãn thực tế, kích thước trường, cột bảng và hệ thống phân cấp nút để người đánh giá có thể xác định các điểm gây trở ngại trong bố cục thực tế. Wireframe của trang thanh toán nên thể hiện lỗi địa chỉ, phương thức thanh toán không khả dụng và ghi chú giao hàng dài ảnh hưởng đến trang như thế nào, thay vì chỉ biểu diễn các trường trống. UI độ trung thực cao nên được thực hiện sau, khi từng chuyển tiếp và ngoại lệ quan trọng đã được xem xét.

Xây dựng Hệ thống UI Có Khả năng Mở rộng

Một hệ thống UI cần có các quy tắc dùng chung cho quyết định trực quan, đồng thời cung cấp các component có thể tái sử dụng cho những hành động lặp lại. Hãy định nghĩa token cho màu sắc, kiểu chữ, khoảng cách, bán kính viền, độ nâng và chuyển động để một thay đổi có thể được áp dụng nhất quán trên mọi màn hình. Điểm khởi đầu thực tế có thể sử dụng cơ sở khoảng cách 8 pixel, cỡ chữ nội dung 16 pixel và các vai trò màu riêng cho nền bề mặt, văn bản, đường viền, trạng thái thành công, cảnh báo và lỗi. Đặt tên mỗi token theo mục đích của nó, chẳng hạn như surface-primary hoặc text-muted, để các quyết định sản phẩm vẫn dễ hiểu khi các giá trị trực quan thay đổi.

Xây dựng component dựa trên hành vi và ngữ cảnh, không chỉ dựa trên diện mạo. Một nút cần có các biến thể hiển thị, hover, focus, disabled, loading và destructive khi sản phẩm hỗ trợ những tình huống đó. Một trường biểu mẫu nên định nghĩa nhãn, văn bản trợ giúp, thông báo lỗi, thời điểm xác thực và cách xử lý nội dung dài như một phần của hợp đồng component. Giới hạn số lượng biến thể ở các trường hợp sử dụng thực tế, vì một component có hàng chục tùy chọn gần như giống hệt nhau sẽ khó bảo trì hơn một số component chuyên biệt.

Thiết kế Trạng thái Responsive và Có thể Truy cập

Wireframe responsive nên thể hiện cách nội dung thay đổi ở từng độ rộng có ý nghĩa, thay vì chỉ thu nhỏ bố cục desktop. So sánh một khung desktop rộng 1440 pixel, một khung tablet rộng 768 pixel và một khung điện thoại rộng 375 pixel để xác định những thay đổi về cột, điều hướng, khoảng cách và mức độ ưu tiên nội dung. Một bảng dữ liệu có thể giữ lại toàn bộ cột trên desktop, cho phép cuộn ngang trên tablet và chuyển sang các bản ghi xếp chồng trên mobile. Ghi lại quy tắc đằng sau mỗi thay đổi để developer có thể triển khai hành vi thay vì phải đoán dựa trên các ảnh chụp màn hình riêng lẻ.

Trạng thái là một phần của hệ thống giao diện, đặc biệt đối với người dùng phụ thuộc vào điều hướng bằng bàn phím hoặc công nghệ hỗ trợ. Một component tải tệp nên bao quát các trạng thái chờ, đang chọn, đang tải lên, hoàn tất, thất bại và thử lại, cùng với cách thể hiện focus rõ ràng và thông báo lỗi có khả năng truy cập. Hãy kiểm tra để bảo đảm ý nghĩa không chỉ được truyền đạt bằng màu sắc, đồng thời xác nhận rằng các điều khiển vẫn sử dụng được khi văn bản xuống dòng hoặc khi mức thu phóng của trình duyệt tăng lên. Chú thích trực tiếp các hành vi này bên cạnh wireframe hoặc đặc tả component liên quan để chúng không bị mất trong quá trình bàn giao.

Xác thực Trước Khi Trau chuốt Độ Trung thực Cao

Việc xác thực nên trả lời các câu hỏi cụ thể về hành vi, không phải hỏi liệu giao diện có hấp dẫn hay không. Giao cho một người tham gia nhiệm vụ như tìm một hóa đơn, thay đổi khoảng thời gian và xuất kết quả, sau đó quan sát nơi họ do dự, quay lại hoặc chọn một điều khiển ngoài dự kiến. Ghi lại liệu nhiệm vụ có hoàn tất hay không, những lỗi nào xảy ra và người dùng mong đợi điều gì sẽ xảy ra tiếp theo. Trong luồng đặt chỗ, việc này có thể cho thấy mọi người tìm ngày giao hàng trước khi chọn sản phẩm, từ đó đòi hỏi thay đổi luồng thay vì điều chỉnh mang tính hình thức.

Đối chiếu các phát hiện trong quá trình đánh giá với yêu cầu ban đầu và ưu tiên những vấn đề cản trở việc hoàn thành hoặc gây ra sai sót tốn kém. Nếu hai phiên đánh giá cho thấy người dùng đều bỏ qua cùng một hành động chính, hãy thử thiết lập thứ bậc thị giác rõ hơn hoặc thay đổi vị trí trước khi điều chỉnh các chi tiết về kiểu chữ. Sau khi cập nhật wireframe, hãy thực hiện thêm một phiên đánh giá ngắn và so sánh cùng các bước thực hiện tác vụ, đồng thời duy trì tính nhất quán trong quá trình đánh giá. Ghi lại lý do cho từng lựa chọn thiết kế để những người đóng góp sau này có thể phân biệt hành vi đã được kiểm chứng với sở thích cá nhân.

Tài liệu hóa và quản trị hệ thống

Một hệ thống nâng cao chỉ thực sự hữu ích khi một designer khác có thể hiểu được nó mà không phải tái dựng các quyết định thiết kế từ những màn hình đã hoàn thiện. Mỗi trang component nên giải thích mục đích, cấu trúc, các biến thể được hỗ trợ, giới hạn nội dung, trạng thái tương tác và hành vi responsive của component đó. Hãy đưa vào các ví dụ cho những ngữ cảnh phổ biến như biểu mẫu, một hàng trong bảng và modal, thay vì chỉ hiển thị một component độc lập. Đối với bảng dữ liệu, hãy nêu rõ cách xử lý tối thiểu đối với các cột, trạng thái không có kết quả, các hàng đang tải và giá trị dài, để pattern luôn có thể áp dụng trong thực tế.

Quản trị giúp hệ thống duy trì độ tin cậy sau phiên bản phát hành đầu tiên. Hãy thiết lập quy trình đánh giá cho các component mới, xác định người phụ trách các pattern dùng chung và ghi nhận các thay đổi khi token hoặc quy tắc tương tác được cập nhật. Trong quá trình triển khai, hãy đối chiếu các màn hình production với hệ thống đã được phê duyệt và loại bỏ những style riêng lẻ tạo ra các biến thể không cần thiết. Định kỳ kiểm tra các luồng quan trọng như đăng ký, tìm kiếm và thanh toán tại các mốc phát hành để phát hiện sự sai lệch giữa wireframe, thư viện component và giao diện đã phát hành.

Đọc thêm

Hệ thống thiết kế

Thiết kế trải nghiệm người dùng

Kiến trúc thông tin

Xây dựng hệ thống hoàn chỉnh

Tiếp tục học với khóa học liên quan: