User flow, hay luồng người dùng, là sơ đồ đường đi của một người qua các màn hình và quyết định để làm xong một việc cụ thể: đặt bàn, mua hàng, đăng ký tài khoản, đổi mật khẩu. Nó trả lời câu hỏi "người dùng bắt đầu ở đâu, bấm gì, gặp gì, rẽ nhánh ở đâu và kết thúc ở đâu", trước khi bạn vẽ bất kỳ màn hình chi tiết nào.
Người làm đồ hoạ chuyển sang giao diện hay bỏ bước này vì nó không có gì để "thiết kế" theo nghĩa thị giác. Hệ quả là các màn hình đẹp riêng lẻ nhưng nối với nhau thì thiếu: không có đường quay lại, không có màn hình báo lỗi, người dùng kẹt ở giữa chừng. Bài này giải thích user flow khác gì sitemap và user journey, cách vẽ một luồng từ mục tiêu, một ví dụ giả định có đủ nhánh rẽ, và cách dùng AI để soát những nhánh con người hay quên.
User flow, sitemap và user journey: ba sơ đồ, ba câu hỏi
Ba loại sơ đồ này hay được vẽ cùng giai đoạn và dễ bị trộn vào nhau. Mỗi loại trả lời một câu hỏi khác nên không thay thế được nhau.
| Sơ đồ | Trả lời câu hỏi | Đơn vị trên sơ đồ | Ai dùng nhiều nhất |
|---|---|---|---|
| Sitemap | Trang web có những trang nào, xếp theo cấp nào | Trang | Người lập cấu trúc nội dung, người làm SEO |
| User flow | Để làm xong một việc, người dùng đi qua màn hình và quyết định nào | Màn hình, hành động, điểm rẽ nhánh | Người thiết kế giao diện, lập trình viên |
| User journey | Trải nghiệm của khách từ lúc biết tới lúc dùng xong, cả ngoài màn hình | Giai đoạn, cảm xúc, điểm chạm | Người làm sản phẩm, marketing, chăm sóc khách |
| Task flow | Một nhiệm vụ đơn, không rẽ nhánh, đi thẳng từ đầu tới cuối | Bước | Dùng để mô tả nhanh trong buổi họp |
Với dự án nhỏ, bạn thường cần sitemap cho phần nội dung và vài user flow cho các việc quan trọng nhất. User journey hữu ích khi khách muốn hiểu cả hành trình mua hàng, nhưng đó là việc rộng hơn phạm vi thiết kế giao diện.
Bắt đầu từ mục tiêu và điểm vào, không bắt đầu từ trang chủ
Luồng tốt bắt đầu bằng một câu: ai, muốn làm gì, thành công trông như thế nào. Ví dụ "khách quen muốn đặt bàn cho tối nay, thành công là nhận được xác nhận có giờ và số người". Câu này cho bạn điểm cuối của luồng, và mọi màn hình không đưa người dùng tới điểm cuối đó đều đáng nghi ngờ.
Câu hỏi thứ hai là người dùng vào luồng từ đâu. Người làm đồ hoạ hay mặc định mọi người bắt đầu từ trang chủ, nhưng thực tế khách có thể đến từ một đường dẫn trong tin nhắn, từ kết quả tìm kiếm thẳng vào trang con, từ thông báo của ứng dụng, hoặc từ mã QR dán trên bàn. Mỗi điểm vào có thể cần một luồng hơi khác: khách quét mã QR tại bàn đã ở quán rồi, không cần chọn chi nhánh.
Câu hỏi thứ ba là người dùng biết gì khi bắt đầu. Khách quen đã có tài khoản, khách mới thì chưa; người đặt bàn hộ sếp không biết số điện thoại của sếp đã đăng ký hay chưa. Ghi các giả định này ra cạnh sơ đồ giúp bạn nhận ra lúc nào cần thêm một nhánh rẽ.
Ví dụ giả định: luồng đặt bàn của một quán cà phê ở Đà Lạt
Ví dụ giả định: một quán cà phê có sân vườn ở Đà Lạt, tỉnh Lâm Đồng, muốn khách đặt bàn qua trang web vào cuối tuần. Luồng chính, viết dạng các bước trước khi vẽ:
- Khách vào trang đặt bàn từ nút trên trang chủ hoặc đường dẫn trong tin nhắn.
- Khách chọn ngày, giờ và số người. Nếu khung giờ đã kín, hệ thống gợi ý giờ gần nhất còn chỗ.
- Khách chọn khu vực: trong nhà hay sân vườn. Nếu trời mưa, quán có thể tạm đóng sân vườn, cần thông báo ngay ở bước này chứ không phải sau khi khách đã điền xong.
- Khách nhập tên và số điện thoại. Nếu số điện thoại sai định dạng, báo lỗi ngay tại ô, giữ nguyên các thông tin đã chọn.
- Khách xem lại toàn bộ thông tin, có thể quay lại sửa từng mục mà không mất phần khác.
- Khách bấm xác nhận. Nếu mạng chập chờn và yêu cầu không gửi được, hiện thông báo kèm nút thử lại, không để khách bấm nhiều lần sinh nhiều lượt đặt.
- Màn hình xác nhận cho biết giờ, số người, khu vực, cách huỷ hoặc đổi giờ; đồng thời gửi tin xác nhận.
Viết thành chữ trước khi vẽ giúp bạn và khách thống nhất logic mà không bị phân tâm bởi hình. Chuyện sân vườn đóng khi mưa không phải thứ AI tự biết: nó đến từ việc hỏi chủ quán "có lúc nào khách đặt được nhưng quán không phục vụ được không".
Dùng AI tìm nhánh rẽ và lối thoát bị quên
Khâu AI giúp tốt nhất trong user flow là liệt kê cho đủ. Con người vẽ luồng chính rất nhanh nhưng hay quên những nhánh ít gặp. Sau khi có bản chữ như trên, bạn có thể hỏi:
- "Đây là luồng đặt bàn của một quán cà phê [dán các bước]. Liệt kê mọi trường hợp lỗi hoặc bất thường có thể xảy ra ở từng bước, kể cả lỗi mạng, dữ liệu sai, khách đổi ý giữa chừng. Mỗi trường hợp ghi người dùng thấy gì và nên được đưa tới đâu."
- "Ở mỗi bước, người dùng có cách nào để quay lại hoặc thoát hẳn không? Chỉ ra bước nào đang là ngõ cụt."
- "Liệt kê các điểm vào khác nhau của luồng này và mỗi điểm vào cần bỏ bớt hoặc thêm bước nào."
- "Đếm số lần người dùng phải nhập liệu và số lần phải đưa ra quyết định trong luồng. Gợi ý bước nào có thể gộp hoặc bỏ mà không mất thông tin cần thiết."
Bạn sẽ nhận được danh sách dài, trong đó có những trường hợp không áp dụng. Gạch bỏ những cái đó, giữ những cái có thật, rồi hỏi khách về những cái bạn không chắc. Khi dán luồng của khách vào AI, bỏ tên quán, tên hệ thống nội bộ, quy định riêng chưa công bố; AI chỉ cần cấu trúc các bước để soát.
Ký hiệu khi vẽ luồng: đủ dùng, không cần cầu kỳ
Hình chữ nhật cho màn hình. Mỗi hình là một màn hình hoặc một trạng thái màn hình mà người dùng nhìn thấy. Ghi tên ngắn gọn bên trong, ví dụ "chọn giờ", "xem lại".
Hình thoi cho quyết định. Dùng khi luồng rẽ theo điều kiện: còn chỗ hay hết chỗ, đã đăng nhập hay chưa. Ghi câu hỏi trong hình thoi, và ghi "có" hay "không" trên từng mũi tên đi ra.
Mũi tên có nhãn hành động. Mũi tên nối hai màn hình nên ghi người dùng đã làm gì để đi qua, như "bấm tiếp tục" hay "vuốt xuống". Không có nhãn, người đọc không biết điều gì gây ra chuyển màn hình.
Hình tròn hoặc hình bo tròn cho điểm đầu và điểm cuối. Một luồng có thể có nhiều điểm vào và nhiều điểm kết thúc, kể cả kết thúc không thành công như "khách bỏ đi". Đánh dấu rõ giúp đếm được luồng thành công chiếm bao nhiêu nhánh.
Màu chỉ để phân loại, không để trang trí. Nếu dùng màu, chỉ dùng một hai màu để phân biệt luồng chính với nhánh lỗi, hoặc phần người dùng làm với phần hệ thống tự làm. Ghi chú nghĩa của màu ở góc sơ đồ.
Đếm bước và tìm chỗ người dùng bỏ cuộc
Khi luồng đã vẽ xong, đếm ba con số: số màn hình người dùng phải đi qua ở nhánh chính, số lần phải nhập liệu, số lần phải ra quyết định. Không có ngưỡng chuẩn chung, nhưng so sánh giữa các phương án của chính bạn rất có ích: phương án nào đạt cùng mục tiêu với ít quyết định hơn thường dễ dùng hơn.
Tiếp theo, tìm những điểm có nguy cơ bỏ cuộc cao: bắt tạo tài khoản trước khi cho xem giá, hỏi thông tin mà người dùng chưa thấy lý do phải đưa, báo hết chỗ ở bước cuối sau khi đã điền đủ mọi thứ. Trong ví dụ quán cà phê, chuyển việc kiểm còn chỗ lên ngay bước chọn giờ giúp khách không mất công điền tên rồi mới biết hết bàn.
Nếu sản phẩm đã chạy và có số liệu, người làm phân tích có thể cho bạn biết bước nào nhiều người rời đi nhất. Khi dùng AI để đọc bảng số liệu này, đưa vào số tổng hợp theo bước, không đưa dữ liệu từng khách. Nếu chưa có số liệu, cách rẻ nhất là nhờ ba bốn người chưa từng thấy luồng thử làm theo trên bản phác, và ghi lại chỗ họ dừng lại hỏi.
Từ luồng sang danh sách màn hình cần thiết kế
Một lợi ích ít được nói của user flow là nó cho bạn danh sách việc cần làm. Mỗi hình chữ nhật trên sơ đồ là một màn hình hoặc trạng thái cần thiết kế; đếm chúng lại, bạn biết khối lượng việc thật trước khi báo thời gian cho khách. Luồng đặt bàn trông đơn giản có thể ra mười hai trạng thái khi tính đủ lỗi, hết chỗ, sân vườn đóng và xác nhận.
Từ danh sách này, bạn nhóm các trạng thái dùng chung một khung. Ví dụ màn hình "chọn giờ" bình thường, "chọn giờ khi hết chỗ" và "chọn giờ khi sân vườn đóng" là ba trạng thái của cùng một màn hình, chỉ khác một khối thông báo. Nhóm đúng giúp bạn dựng ít khung hơn và giữ được sự nhất quán.
Cuối cùng, giữ sơ đồ luồng như một tài liệu sống trong tệp dự án. Khi khách muốn thêm tính năng, ví dụ cho đặt trước món, bạn thêm nhánh vào sơ đồ trước, xem nó đụng tới những màn hình nào, rồi mới báo khối lượng. Lập trình viên cũng dùng sơ đồ này để biết phải xử lý những trường hợp nào, nên bàn giao luôn cùng bản thiết kế.
Câu hỏi thường gặp
User flow nên vẽ trước hay sau wireframe?
Thường vẽ trước, vì luồng quyết định cần những màn hình nào. Tuy vậy, hai việc hay đi xen kẽ: phác vài wireframe giúp bạn phát hiện bước thừa trong luồng, và sửa luồng lại kéo theo sửa wireframe. Với dự án nhỏ, có thể vẽ luồng bằng chữ trước rồi phác màn hình ngay sau.
Một ứng dụng nhỏ cần vẽ bao nhiêu user flow?
Vẽ cho những việc quan trọng nhất với mục tiêu kinh doanh và những việc dễ sai nhất. Với một cửa hàng trực tuyến nhỏ, thường là tìm và mua sản phẩm, đăng ký hoặc đăng nhập, theo dõi đơn, đổi trả. Những trang chỉ để đọc nội dung thì sitemap là đủ.
Có cần phần mềm chuyên dụng để vẽ user flow không?
Không bắt buộc. Giấy, bảng trắng, phần mềm vẽ sơ đồ hay chính phần mềm thiết kế giao diện đều được. Điều quan trọng là ký hiệu nhất quán và người khác đọc hiểu. Chọn công cụ mà cả bạn, khách và lập trình viên cùng mở được.
AI có tự vẽ sơ đồ user flow được không?
Một số chatbot có thể trả về sơ đồ dạng văn bản hoặc hình đơn giản từ mô tả các bước. Kết quả dùng làm bản nháp được, nhưng logic rẽ nhánh cần bạn kiểm lại từng mũi tên. AI không biết quy định thật của khách, như giờ đóng sân vườn hay chính sách huỷ.
User flow cho người dùng lớn tuổi có gì khác?
Nên giảm số quyết định ở mỗi màn hình, giữ đường quay lại luôn rõ ràng, tránh những bước phụ thuộc vào thao tác vuốt hay giữ lâu mà không có nút thay thế. Thông báo lỗi cần nói rõ phải làm gì tiếp, và nên giữ lại thông tin đã nhập khi quay lại sửa.
Làm sao để khách không phải là dân kỹ thuật đọc được sơ đồ luồng?
Kể luồng như một câu chuyện có nhân vật: "chị Lan mở đường dẫn, chọn tối thứ bảy, bảy người…", rồi chỉ trên sơ đồ khi kể. Giữ sơ đồ ở mức đủ để kể, phần chi tiết kỹ thuật để ở bản dành cho lập trình viên.