Phác thảo màn hình: thử với người dùng trước khi chỉnh cho đẹp

Màn hình đặt lịch đã có màu đẹp, ảnh xịn và nút bấm nhìn rất mượt. Bạn đưa cho một người thử. Họ nhìn một lúc rồi hỏi: “Muốn đổi lịch thì vào đâu?” Cả nhóm im vài giây. Suốt buổi sáng, mọi người đã bàn về bóng đổ của nút, còn đường đổi lịch chưa ai nghĩ tới.

Phác thảo màn hình giúp bạn thử cách người dùng làm việc trước khi đầu tư nhiều vào hình thức. Bản phác có thể đơn giản, miễn là đủ chữ và các bước cần thiết. Người thử cần hiểu mình đang ở đâu, có thể chọn gì và chuyện gì xảy ra tiếp. Những chỗ họ bị vướng chính là thông tin để sửa thiết kế.

Chữ trên giao diện cũng là thiết kế

Giả sử nhóm của An đang làm trang đặt lịch sửa xe. Bản đầu có một nút “Xác nhận” sau khi khách chọn giờ. Nhưng cửa hàng còn phải kiểm thợ trước khi nhận lịch. Người thử bấm xong tưởng đã có chỗ chắc chắn. Vấn đề nằm ngay trong câu chữ: nút đang hứa nhiều hơn điều hệ thống thực sự làm.

An đổi nút thành “Gửi yêu cầu đặt lịch” và thêm thông báo sau khi gửi. Thông báo nói cửa hàng sẽ liên hệ xác nhận theo quy trình đã thống nhất. Người dùng biết mình cần chờ bước nào. Nhóm chưa thay màu hay bố cục, nhưng ý nghĩa thao tác đã rõ hơn. Chữ trên giao diện có thể quyết định cách người dùng hiểu cả dịch vụ.

Trước khi vẽ, viết nhiệm vụ bằng một câu cụ thể. Ví dụ: khách đã có lịch và muốn chuyển sang chiều thứ sáu. Từ đó, liệt kê thông tin họ cần thấy: lịch hiện tại, giờ còn nhận và điều kiện đổi. Nếu chỉ ghi “làm màn hình quản lý lịch”, bản phác rất dễ có nhiều ô đẹp mà thiếu đúng việc người dùng muốn làm.

Đưa nội dung gần với thực tế vào bản thử. Tên dịch vụ dài, ngày hết chỗ hoặc một lời giải thích nhiều dòng đều có thể làm bố cục thay đổi. Các ô chữ giả ngắn và đều nhau thường che mất vấn đề. Bạn không cần dữ liệu khách thật; dữ liệu giả có độ dài và tình huống hợp lý đã đủ để thử nhiều điểm quan trọng.

Nhãn của ô nhập cần nói rõ thông tin cần điền. Nếu số điện thoại dùng để xác nhận lịch, có thể giải thích ngắn ngay cạnh ô. Đừng yêu cầu những thông tin chưa có mục đích rõ. Người thử bỏ qua một trường đôi khi không phải vì họ lười đọc, mà vì chưa hiểu tại sao dịch vụ cần biết điều đó.

Các trạng thái sau thao tác cũng cần được phác. Gửi thành công thì thấy gì? Không còn giờ phù hợp thì làm sao? Nhập thiếu thông tin thì quay lại đâu? Chỉ vẽ màn hình trước khi bấm sẽ bỏ sót phần người dùng cần được hướng dẫn nhất. Cách viết nội dung dễ tiếp cận giúp bạn kiểm lại câu hướng dẫn và thông báo lỗi.

Đừng nhầm bản vẽ với bằng chứng

Bản phác là một giả định để thử, chưa chứng minh người dùng sẽ làm được. Cả nhóm thiết kế hiểu nó vì đã bàn với nhau nhiều giờ. Người ngoài nhóm không có phần bối cảnh ấy. Khi họ hỏi một câu rất cơ bản, đó là cơ hội nhìn thấy điều giao diện chưa nói rõ, thay vì vội giải thích rằng họ phải bấm chỗ nào.

Chọn người thử phù hợp với công việc đang thiết kế. Một đồng nghiệp làm sản phẩm có thể giúp phát hiện lỗi rõ ràng, nhưng chưa đại diện cho khách đặt lịch. Nếu dịch vụ dành cho người ít dùng công nghệ, cần tìm cách nghe phản hồi từ họ. Ghi lại phạm vi người đã thử để tránh kể kết quả rộng hơn bằng chứng thực tế.

Giao nhiệm vụ bằng tình huống, đừng chỉ đường. Bạn có thể nói: “Bạn đã đặt sáng thứ sáu, giờ muốn chuyển sang chiều. Hãy thử đổi lịch.” Nếu nói “bấm mục Lịch của tôi rồi chọn Sửa”, bạn đang kiểm khả năng làm theo hướng dẫn. Bạn sẽ không biết người đó có tự tìm được đường đi từ màn hình đầu tiên hay không.

Trước buổi thử, nói rõ đây là bản đang làm và bạn muốn tìm điểm chưa ổn. Người dùng dễ ngại chê khi thấy nhóm đã đầu tư nhiều. Có thể nhắc rằng họ đang giúp kiểm bản thiết kế, không phải làm bài thi. Giữ thái độ bình tĩnh khi họ đi khác đường bạn dự tính; chính đường đi ấy thường cho thấy cách họ hiểu giao diện.

Trong lúc quan sát, ghi việc xảy ra trước khi ghi cách giải thích. “Người thử mở trang hỗ trợ để tìm cách đổi lịch” là quan sát. “Họ không thích menu” là suy luận cần hỏi thêm. Bạn có thể hỏi họ đang tìm gì hoặc nghĩ nút này sẽ làm gì. Tránh câu hỏi gợi đáp án như “nút này hơi khó thấy đúng không?”.

Nếu bản phác chưa làm được một thao tác, nói rõ giới hạn đó khi cần. Một người không bấm được vì liên kết thử chưa nối khác với việc họ không tìm thấy nút. Ghi hai loại vấn đề riêng. Đừng đưa lỗi của công cụ mô phỏng thành kết luận về sản phẩm, cũng đừng bỏ qua vướng mắc thật chỉ vì bản thử còn đơn giản.

Sửa đúng điểm vừa quan sát

Sau buổi thử, An có ba ghi nhận: người dùng không thấy lịch cũ, nhầm gửi yêu cầu với xác nhận và chưa hiểu giờ nào còn nhận. Nhóm sắp theo ảnh hưởng tới nhiệm vụ. Họ sửa thông tin và đường đi trước, rồi mới bàn chuyện màu nút. Không phải mọi góp ý đều cần làm ngay, nhưng mỗi lựa chọn nên có lý do liên quan đến việc người dùng cần hoàn thành.

Với mỗi vấn đề, nêu thay đổi dự kiến và điều muốn kiểm lại. Chẳng hạn, thêm lịch hiện tại ở đầu trang để người dùng biết đang đổi lịch nào. Sau đó thử lại cùng loại nhiệm vụ với người phù hợp. Nếu chỉ sửa rồi nhìn nội bộ thấy đẹp hơn, nhóm vẫn chưa biết thay đổi có giải quyết đúng vướng mắc ban đầu không.

Đừng ghép mọi đề xuất của người thử thành danh sách tính năng. Một người muốn có nút gọi nhanh có thể đang thiếu thông tin để tự quyết định. Hỏi thêm tình huống khiến họ muốn gọi. Có thể giải pháp phù hợp là giải thích điều kiện đổi lịch, cũng có thể thực sự cần kênh hỗ trợ. Nhu cầu phía sau đề xuất mới giúp nhóm chọn cách xử lý.

Giữ lại bản trước và ghi thay đổi chính. Khi có nhiều người sửa, tên bản rõ ràng giúp tránh thử nhầm giao diện cũ. Bài quản lý phiên bản tài liệu có thể áp dụng cho file thiết kế. Người tổng hợp cần biết phản hồi nào thuộc bản nào để không yêu cầu sửa lại một lỗi đã được xử lý.

Khi người dùng đã đi được các bước chính, nhóm mới có nền rõ hơn để hoàn thiện hình ảnh. Màu sắc, khoảng cách và kiểu chữ vẫn quan trọng. Chúng nên hỗ trợ nội dung và thao tác đã được hiểu, thay vì che một đường đi còn rối. Một bản phác giản dị tìm ra chỗ người dùng mắc sẽ có ích hơn màn hình bóng bẩy khiến cả nhóm tự tin quá sớm.