Mở đầu — vì sao bài này quan trọng
Có một sự thật phũ phàng mà nhiều designer trẻ chỉ nhận ra sau vài năm đi làm: thiết kế đẹp không có nghĩa là thiết kế đúng. Bạn có thể dành ba tuần trau chuốt một luồng đăng ký với typography hoàn hảo, spacing chuẩn hệ 8, dark mode mượt mà — rồi phát hiện ra người dùng thật không hiểu nút "Tiếp tục" nằm ở đâu, hoặc bỏ cuộc ngay ở bước nhập số điện thoại vì họ tưởng phải nhập cả mã quốc gia.
Bài học hôm nay không bàn về việc làm giao diện đẹp hơn. Nó bàn về việc kiểm chứng xem thiết kế của bạn có thật sự hoạt động hay không, trước khi kỹ sư viết một dòng code. Và điều quan trọng nhất: làm việc đó một cách sớm và rẻ.
Tại sao "sớm và rẻ" lại là hai từ khóa? Vì rào cản lớn nhất khiến designer không test không phải là thiếu kỹ năng — mà là niềm tin sai lầm rằng testing tốn kém, cần phòng lab, cần chuyên gia UX research, cần ngân sách. Trong bài này tôi sẽ chứng minh điều ngược lại: bạn có thể phát hiện phần lớn lỗi usability chỉ với 5 người dùng, một link Figma prototype, và 30 phút. Đây là kỹ năng phân biệt một junior designer chỉ biết "vẽ" với một designer thực thụ biết ra quyết định dựa trên bằng chứng.
Khái niệm cốt lõi
Chi phí của việc sửa sai tăng theo cấp số nhân
Nguyên lý nền tảng của toàn bộ bài học nằm ở đường cong chi phí thay đổi. Một ý tưởng sai, nếu phát hiện ở giai đoạn sketch trên giấy, tốn vài phút để sửa. Cũng ý tưởng đó nếu lọt qua đến bản Figma hoàn chỉnh, tốn vài giờ. Nếu lọt tiếp vào giai đoạn code đã build, tốn vài ngày của cả designer lẫn engineer. Và nếu nó ra tới production rồi mới bị người dùng phàn nàn, chi phí có thể gấp 10–100 lần: vừa mất công sửa, vừa mất người dùng, vừa tổn hại uy tín.
Testing sớm chính là cách bạn kéo điểm phát hiện lỗi về càng gần đầu đường cong càng tốt. Mỗi lỗi bạn bắt được ở bản prototype là một khoản tiền và thời gian bạn tiết kiệm cho cả team.
"Sớm và rẻ" nghĩa là gì trong thực tế
Testing rẻ không có nghĩa là testing kém chất lượng. Nó dựa trên một phát hiện kinh điển của Jakob Nielsen: chỉ cần 5 người dùng là đủ để phát hiện khoảng 85% vấn đề usability của một giao diện. Sau người thứ năm, mỗi người tiếp theo chỉ lặp lại những lỗi bạn đã thấy. Thay vì test 15 người một lần cho tốn kém, hãy test 5 người, sửa, rồi test 5 người khác — bạn học được nhiều gấp bội với cùng ngân sách.
Điểm mấu chốt cần hiểu: mục tiêu của cheap testing không phải là dữ liệu thống kê. Bạn không đi tìm con số "72% người dùng thích màu xanh". Bạn đi tìm những khoảnh khắc người dùng khựng lại, bối rối, làm sai, hoặc bỏ cuộc. Chỉ cần một người dùng loay hoay 20 giây tìm nút đóng modal là bạn đã có bằng chứng đủ mạnh để sửa.
Ba loại test rẻ mà designer nào cũng làm được
Hallway testing (test hành lang): Bạn túm bất kỳ ai đi ngang — đồng nghiệp phòng kế toán, bạn cùng phòng, người thân — và nhờ họ thử luồng. Nghe không "khoa học", nhưng cực kỳ hiệu quả để bắt lỗi rõ ràng. Với điều kiện: người đó không phải là designer hay dev của dự án.
Moderated usability test (test có người điều phối): Bạn ngồi cùng người dùng (trực tiếp hoặc qua Google Meet share màn hình Figma prototype), giao cho họ một nhiệm vụ thật, và quan sát họ làm — trong khi im lặng hết mức có thể. Đây là loại test cho ra insight sâu nhất.
Unmoderated test (test không người điều phối): Bạn gửi prototype qua công cụ như Maze, Useberry hoặc thậm chí một link Figma kèm bảng câu hỏi Google Form, người dùng tự làm và bạn xem lại kết quả. Rẻ về thời gian, dễ scale, phù hợp khi bạn cần nhiều mẫu ở nhiều tỉnh thành.
Task-based testing: nền tảng của mọi buổi test
Sai lầm lớn nhất khi test là hỏi "bạn thấy giao diện này thế nào?". Câu đó chỉ nhận về lời khen xã giao. Thay vào đó, hãy giao nhiệm vụ dựa trên tình huống thật: "Hãy tưởng tượng bạn muốn đặt một lớp học yoga vào thứ Bảy tuần này. Bạn sẽ làm gì?" Rồi im lặng và quan sát. Nhiệm vụ tốt là nhiệm vụ có mục tiêu rõ ràng nhưng không tiết lộ đường đi — bạn muốn xem người dùng tự tìm đường, không phải làm theo chỉ dẫn của bạn.
Tình huống thực tế
Ví dụ 1: App đặt lịch spa và cái nút "vô hình"
Một studio thiết kế nhỏ ở TP.HCM nhận làm app đặt lịch cho một chuỗi spa 6 chi nhánh. Designer làm bản Figma prototype cho luồng đặt lịch, tự tin gửi thẳng cho dev vì "luồng rõ ràng quá rồi". Trước khi đóng gói handoff, chị lead ép cả team làm một buổi hallway test nhanh: nhờ 5 nhân viên lễ tân của spa — đúng nhóm người dùng cuối — thử đặt một buổi massage 90 phút.
Kết quả gây sốc: 4/5 người không tìm thấy nút "Chọn dịch vụ". Lý do? Designer đã thiết kế nút đó theo kiểu ghost button (viền mảnh, nền trong suốt) để trông tinh tế, nhưng trên màn hình điện thoại Android tầm trung ngoài nắng, gần như không ai thấy nó. Trung bình mỗi người mất 25 giây loay hoay, hai người còn thử bấm vào ảnh banner tưởng đó là nút.
Bài học: chỉ một buổi test 40 phút, không tốn đồng nào, đã bắt được một lỗi mà nếu lọt vào production sẽ khiến tỷ lệ đặt lịch thành công sụt thảm hại. Designer sửa nút thành filled button màu chủ đạo — lần test lại, 5/5 người tìm thấy trong dưới 3 giây.
Ví dụ 2: Grab và văn hóa test trước khi build
Ở quy mô lớn hơn, các sản phẩm như Grab hay các ví điện tử tại Đông Nam Á (MoMo, ZaloPay) đều có nguyên tắc bất di bất dịch: không tính năng nào ra production mà chưa qua usability test với người dùng thật ở nhiều thị trường. Khi Grab thiết kế lại luồng thanh toán, họ không cho rằng người dùng ở Jakarta, Manila và Hà Nội sẽ hiểu icon giống nhau.
Một chi tiết kinh điển: icon "ví" hình chiếc ví da phương Tây bị người dùng ở một số thị trường không nhận ra, vì họ hình dung "ví tiền" khác. Chỉ khi test prototype với vài chục người ở từng nước, đội thiết kế mới phát hiện và điều chỉnh. Nếu bỏ qua bước này và build luôn, họ sẽ phải sửa trên hàng chục màn hình đã code, dịch lại nhiều ngôn ngữ, và deploy lại toàn khu vực — chi phí gấp hàng chục lần so với đổi một prototype.
Bài học: kể cả team lớn với ngân sách dồi dào vẫn chọn test sớm và rẻ trên prototype, vì họ hiểu rõ đường cong chi phí. Testing không phải đặc quyền của công ty lớn — mà là kỷ luật của người làm nghề nghiêm túc.
Ví dụ 3: Form đăng ký khóa học và giả định chết người
Một bạn junior designer làm freelance thiết kế trang đăng ký cho một nền tảng học trực tuyến. Bạn ấy tin chắc luồng của mình hoàn hảo: 3 bước gọn gàng, progress bar đẹp, microcopy thân thiện. Bạn ấy làm một unmoderated test đơn giản: đăng prototype Figma lên Maze, gửi link cho 8 người quen ở các độ tuổi khác nhau, kèm nhiệm vụ "đăng ký khóa học Tiếng Anh giao tiếp".
Dữ liệu Maze trả về cho thấy 3/8 người drop ngay ở bước 2 — bước nhập ngày sinh. Xem lại heatmap, hóa ra người dùng lớn tuổi không hiểu date picker dạng cuộn (wheel picker) kiểu iOS; họ cố gõ tay vào ô nhưng ô không cho gõ. Đây là giả định ngầm nguy hiểm: designer trẻ nghĩ "ai chẳng biết dùng date picker", nhưng nhóm người dùng thật thì không.
Bài học: một giả định của designer, nếu không kiểm chứng, có thể giết chết cả một luồng chuyển đổi. Chi phí test: một buổi tối và tài khoản Maze miễn phí. Chi phí nếu không test: mất một phần đáng kể học viên tiềm năng ở nhóm tuổi trung niên — vốn thường là nhóm chịu chi.
Hướng dẫn từng bước
Đây là quy trình một buổi cheap usability test mà bạn có thể chạy trong một buổi chiều.
Bước 1 — Xác định câu hỏi bạn muốn trả lời. Đừng test chung chung. Viết ra 1–3 câu hỏi cụ thể: "Người dùng có tự tìm được nút thanh toán không?", "Họ có hiểu bước xác thực OTP không?". Câu hỏi rõ thì buổi test mới có trọng tâm.
Bước 2 — Chuẩn bị prototype vừa đủ dùng. Bạn không cần prototype hoàn chỉnh mọi màn hình. Chỉ cần luồng liên quan đến câu hỏi ở bước 1 chạy được (clickable) trong Figma. Prototype thô vẫn test được — thậm chí paper prototype hoặc wireframe cũng đủ ở giai đoạn rất sớm.
Bước 3 — Viết kịch bản nhiệm vụ (task script). Mỗi nhiệm vụ đặt trong một tình huống đời thực, có mục tiêu, không có chỉ dẫn đường đi. Ví dụ: "Bạn vừa được tặng một mã giảm giá. Hãy dùng nó để mua khóa học này với giá rẻ hơn."
Bước 4 — Tuyển 5 người đúng nhóm đối tượng. Không lấy designer, không lấy dev trong dự án. Ưu tiên người giống người dùng thật. Nếu không có, người ngoài dự án vẫn tốt hơn tự mình đánh giá.
Bước 5 — Chạy buổi test và IM LẶNG. Đây là kỹ năng khó nhất. Giao nhiệm vụ rồi ngồi im. Khi người dùng khựng lại, đừng cứu họ. Chỉ nhắc nhẹ "bạn đang nghĩ gì vậy?" để họ nói ra suy nghĩ (think-aloud). Đừng bao giờ hỏi "cái nút kia có dễ thấy không?" — đó là câu hỏi dẫn dắt.
Bước 6 — Ghi lại quan sát, không phải ý kiến. Ghi hành vi: "Người 3 bấm vào banner tưởng là nút", "Người 5 mất 20 giây tìm nút back". Đừng ghi "người dùng thích màu này".
Bước 7 — Tổng hợp theo mức độ nghiêm trọng. Gom các vấn đề lặp lại, xếp hạng: nghiêm trọng (chặn hoàn thành nhiệm vụ) > vừa (gây bối rối) > nhỏ (thẩm mỹ). Ưu tiên sửa nhóm nghiêm trọng trước.
Bước 8 — Sửa, rồi test lại vòng mới. Testing là vòng lặp, không phải sự kiện một lần. Sửa xong, chạy lại với 5 người khác để xác nhận đã hết lỗi cũ và không sinh lỗi mới.
Lỗi thường gặp & mẹo
Lỗi 1 — Hỏi ý kiến thay vì giao nhiệm vụ. "Bạn thấy sao?" chỉ nhận về lời khen lịch sự. Luôn giao task và quan sát hành vi.
Lỗi 2 — Designer tự cứu người dùng. Khi thấy người dùng loay hoay, bản năng của bạn là chỉ đường. Đừng. Chính khoảnh khắc họ bối rối mới là insight quý nhất. Cắn răng im lặng.
Lỗi 3 — Test với người trong nghề. Đồng nghiệp designer, dev, hay PM của dự án đã "nhiễm" bối cảnh, họ không còn nhìn giao diện bằng con mắt người dùng mới nữa.
Lỗi 4 — Chờ đến khi thiết kế "hoàn hảo" mới test. Đây là cái bẫy tâm lý lớn nhất. Bạn càng đầu tư nhiều vào bản thiết kế, bạn càng gắn bó cảm xúc và càng khó chấp nhận nó sai. Test sớm, khi còn dễ đổi.
Lỗi 5 — Câu hỏi dẫn dắt (leading question). "Bạn có thấy nút thanh toán dễ dùng không?" đã gợi ý rằng có nút thanh toán và nó dễ dùng. Hỏi mở: "Tiếp theo bạn sẽ làm gì?".
Mẹo 1 — Quy tắc 5 người, nhiều vòng. Chia ngân sách thành nhiều vòng test 5 người thay vì một vòng lớn.
Mẹo 2 — Ghi màn hình. Với sự đồng ý của người dùng, ghi lại màn hình và giọng nói. Xem lại giúp bạn thuyết phục cả team — không gì mạnh bằng cho stakeholder xem clip người dùng thật vật lộn với thiết kế.
Mẹo 3 — Dùng clip test để "chốt" tranh luận. Khi bạn muốn thuyết phục sếp hoặc dev rằng một thiết kế cần đổi, một đoạn video 30 giây người dùng bỏ cuộc có sức nặng hơn mọi lý lẽ. Đây chính là cách testing giúp bạn "convince stakeholders".
Mẹo 4 — Bắt đầu với công cụ miễn phí. Figma prototype + Google Meet + Google Form là đủ để chạy hầu hết mọi buổi test. Maze/Useberry có gói free đủ dùng cho unmoderated test quy mô nhỏ.
Bài tập thực hành
Bài 1 — Viết task script. Chọn một luồng bất kỳ bạn đang thiết kế (hoặc một app bạn hay dùng). Viết 3 nhiệm vụ dựa trên tình huống thật, mỗi nhiệm vụ không quá 2 câu, tuyệt đối không tiết lộ đường đi.
Bài 2 — Chạy hallway test thật. Nhờ 3 người ngoài nghề (người thân, bạn bè không làm design/dev) thử một prototype Figma của bạn với 3 nhiệm vụ trên. Ngồi im, quan sát, ghi lại hành vi (không phải ý kiến). Đếm xem mỗi người mất bao lâu và khựng lại ở đâu.
Bài 3 — Bảng tổng hợp lỗi. Sau buổi test, lập một bảng gồm các cột: Vấn đề quan sát được — Số người gặp — Mức độ nghiêm trọng (nghiêm trọng/vừa/nhỏ) — Hướng sửa đề xuất. Sắp xếp theo mức độ nghiêm trọng giảm dần.
Bài 4 — Vòng lặp. Sửa 2 lỗi nghiêm trọng nhất trong bảng, rồi test lại với 3 người khác. Ghi lại: lỗi cũ đã hết chưa? Có lỗi mới nào phát sinh không?
Tóm tắt
Testing sớm và rẻ là một trong những kỹ năng tạo ra sự khác biệt lớn nhất giữa designer nghiệp dư và chuyên nghiệp — mà lại gần như không tốn tiền. Những điều cần nhớ:
- Chi phí sửa sai tăng theo cấp số nhân theo giai đoạn. Bắt lỗi ở prototype rẻ hơn 10× so với bắt ở production. Đây là lý do kinh tế cốt lõi để test sớm.
- Chỉ cần 5 người là đủ phát hiện ~85% lỗi usability. Mục tiêu là tìm khoảnh khắc bối rối, không phải số liệu thống kê.
- Luôn giao nhiệm vụ, không hỏi ý kiến. Quan sát hành vi, giữ im lặng, tránh câu hỏi dẫn dắt.
- Test với người ngoài dự án, càng giống người dùng thật càng tốt.
- Testing là vòng lặp: test → sửa → test lại. Và clip người dùng thật là vũ khí mạnh nhất để thuyết phục cả team đồng ý thay đổi.