Quy trình thiết kế UI/UX giúp chủ website và người thiết kế thống nhất người dùng cần làm gì, màn hình cần có gì và cách kiểm tra trước khi lập trình. Mỗi bước nên kết thúc bằng một đầu ra có thể xem, góp ý và duyệt.
Bài viết dùng ví dụ giả định về website dịch vụ có biểu mẫu liên hệ. Bạn có thể áp dụng các câu hỏi dưới đây khi chuẩn bị dự án mới hoặc thiết kế lại website.
1. Xác định vấn đề và đầu vào
Hãy viết một nhiệm vụ cụ thể, chẳng hạn: “Khách cần hiểu phạm vi dịch vụ và gửi yêu cầu phù hợp trên điện thoại”. Sau đó tập hợp nội dung hiện có, câu hỏi khách thường hỏi và phản hồi về website cũ.
Tách điều đã quan sát khỏi giả định. Trong ví dụ giả định, “Ba người được hỏi không tìm thấy nút liên hệ” là ghi nhận có phạm vi cụ thể. “Mọi khách đều muốn biểu mẫu ngắn” vẫn cần kiểm chứng.
Đầu ra: mục tiêu, nhóm người dùng, vấn đề ưu tiên và danh sách nội dung còn thiếu.
Cần duyệt: nhiệm vụ chính và người có quyền chốt phản hồi.
2. Chốt cấu trúc trang và luồng thao tác
Sitemap cho biết website gồm những trang nào. Luồng người dùng mô tả các bước để hoàn thành một nhiệm vụ. Với ví dụ trên, khách có thể đi từ trang dịch vụ đến biểu mẫu, kiểm tra thông tin rồi nhận xác nhận.
Hãy hỏi điều gì xảy ra khi khách chưa sẵn sàng liên hệ, nhập thiếu dữ liệu hoặc muốn quay lại. Ghi rõ nội dung cần xuất hiện ở mỗi bước, tránh để người lập trình tự đoán.
Đầu ra: sơ đồ trang và luồng chính, kèm các tình huống ngoại lệ quan trọng.
Cần duyệt: điểm bắt đầu, điểm kết thúc và bước có thể bỏ bớt.
3. Duyệt wireframe bằng nội dung gần thực tế
Wireframe là bản phác bố cục để kiểm tra thứ tự thông tin. Ở bước này, hãy đọc trang như một khách mới: tiêu đề có giải thích dịch vụ không, phần nào giúp quyết định, biểu mẫu cần những trường nào?
Thay văn bản mẫu bằng nội dung gần thực tế. Thử một tên dịch vụ dài và một đoạn mô tả nhiều dòng. Xem bản điện thoại để phát hiện thông tin quan trọng bị đẩy quá xa hoặc thứ tự khối chưa hợp lý.
Đầu ra: bố cục các màn hình chính với nội dung đại diện.
Cần duyệt: thứ tự đọc, vị trí hành động và trường nhập cần thiết.
4. Hoàn thiện giao diện và trạng thái
Mockup bổ sung màu sắc, kiểu chữ, hình ảnh và chi tiết giao diện. Bộ thành phần dùng chung giúp các nút, ô nhập liệu và thẻ nội dung có cách thể hiện nhất quán.
Yêu cầu xem cả trạng thái bình thường, đang xử lý, lỗi và thành công. Với biểu mẫu, lỗi nên chỉ rõ trường cần sửa và cách sửa. Kiểm tra nhãn, độ dễ đọc và cách bố cục thay đổi giữa điện thoại với máy tính.
Đầu ra: mockup responsive và bộ thành phần theo phạm vi dự án.
Cần duyệt: nội dung, trạng thái tương tác và quy tắc hiển thị.
5. Thử prototype theo nhiệm vụ
Prototype liên kết các màn hình để thử luồng thao tác. Nhờ một người thuộc nhóm người dùng dự kiến thực hiện nhiệm vụ: “Tìm dịch vụ phù hợp và gửi yêu cầu”. Hạn chế chỉ dẫn họ phải bấm nút nào.
Ghi lại chỗ họ dừng, hiểu sai hoặc cần trợ giúp. Ưu tiên sửa vấn đề cản trở hoàn thành nhiệm vụ, sau đó thử lại luồng đã sửa. Prototype chỉ mô phỏng tương tác; kiểm tra tốc độ, dữ liệu và chức năng thực cần làm trên bản triển khai.
Đầu ra: ghi nhận quan sát, vấn đề ưu tiên và phiên bản cập nhật.
Cần duyệt: luồng nào đã thử, vấn đề nào còn mở.
Minh họa giả định: bảng kiểm đầu ra cần duyệt, thư viện thành phần và giao diện desktop, mobile trong bộ bàn giao UI/UX.
6. Bàn giao cùng danh sách cần kiểm tra
Trước khi chuyển sang lập trình, hãy xác định phiên bản được duyệt và nơi tập trung phản hồi. File thiết kế cần có tên màn hình rõ ràng, thành phần dùng chung, nội dung và tài sản có quyền sử dụng.
Ghi chú quy tắc responsive, trạng thái lỗi và hành vi khó nhìn thấy trong ảnh tĩnh. Khi có bản chạy thử, đối chiếu lại nội dung, luồng và trạng thái đã thống nhất. Những thay đổi phát sinh nên được ghi nhận cùng quyết định xử lý.
Đầu ra: file nguồn, tài liệu bàn giao và danh sách vấn đề còn lại.
Cần duyệt: trách nhiệm kiểm tra và cách phản hồi sau bàn giao.
Góp ý thế nào để sửa đúng vấn đề?
Thay “giao diện chưa ổn” bằng phản hồi có vị trí, tình huống và lý do: “Ở biểu mẫu trên điện thoại, tôi chưa biết trường nào bắt buộc”. Gom phản hồi vào một nơi, phân biệt lỗi cần sửa với lựa chọn thẩm mỹ.
Các bước có thể lặp lại khi xuất hiện thông tin mới. Mô hình Double Diamond của Design Council mô tả việc tìm hiểu vấn đề, xác định trọng tâm, phát triển và thử giải pháp. Bài hướng dẫn này cụ thể hóa các điểm cần trao đổi cho một dự án website.
Nếu bạn đang chuẩn bị dự án, hãy dùng danh sách đầu ra trên để trao đổi phạm vi. Trang thiết kế UI/UX website theo yêu cầu trình bày các hạng mục thiết kế và thông tin nên chuẩn bị trước khi làm việc với Cường Design.
Bạn có thể đối chiếu các mốc duyệt với quy trình làm việc của Cường Design, rồi gửi yêu cầu và tài liệu đầu vào khi cần trao đổi phạm vi cụ thể.
