Wireframing & Prototyping Basics

Kỹ năng này cho bạn điều gì

Bắt đầu từ đây

Hiểu wireframe cố tình xấu để người xem bình luận về LUỒNG chứ không về màu sắc, và hiểu nó là công cụ tư duy chứ không phải bước thiết kế. Biết phải chốt bốn câu bối cảnh trước khi mở công cụ vẽ.

Khi đã làm được

Đi được cả đường: chốt phạm vi bằng bốn câu và tách sự thật khỏi giả định, chạy buổi brainstorm có cấu trúc 90 phút, suy ra màn hình từ luồng với đủ bốn trạng thái, tự kiểm bằng bảy câu và phép thử 5 giây, thử với 5 người dùng bằng câu hỏi về hành vi thay vì sở thích, và rút ra ước lượng đếm cả trạng thái lẫn phụ thuộc.

Roadmap — Cách học và đạt kỹ năng

Đã đọc 0/13 mục · còn khoảng 13 phút

Cách chúng tôi ghi nhận

Một mục được tính là đã đọc khi nó nằm giữa màn hình đủ lâu so với độ dài của nó (bảng và sơ đồ tính một nửa), bạn vẫn đang cuộn hoặc bấm phím, và bạn đã thấy tới cuối mục. Lướt nhanh hoặc để tab mở không được tính. Chúng tôi chỉ lưu thời gian đọc từng mục — không lưu gì khác.

Wireframe là gì — và quan trọng hơn, nó KHÔNG phải là gì

Wireframe là bản vẽ bố cục và luồng của một màn hình: cái gì nằm ở đâu, cái gì quan trọng hơn cái gì, bấm vào thì đi đâu. Nó cố tình xấu — không màu, không font đẹp, không ảnh thật.

Xấu là một tính năng, không phải thiếu sót. Khi bản vẽ trông đã xong, người xem bình luận về màu sắc và góc bo. Khi nó trông như bản nháp, người xem bình luận về việc thiếu bước nào — và đó mới là thứ bạn cần nghe ở giai đoạn này.

Mức độ	Trông như thế nào	Trả lời câu hỏi	Mất bao lâu
Phác thảo tay	Vẽ trên giấy, nguệch ngoạc	Luồng này có hợp lý không?	Phút
Wireframe	Hộp xám, chữ thật, không màu	Màn hình cần những gì, cái gì quan trọng nhất?	Giờ
Mockup	Đủ màu, font, hình ảnh thật	Trông có đúng thương hiệu không?	Ngày
Prototype	Bấm được, chuyển màn hình được	Người dùng có tự đi hết luồng được không?	Ngày

Sai lầm tốn kém nhất trong bảng này: nhảy thẳng lên mockup. Bạn mất nhiều ngày làm đẹp một màn hình mà hai tuần sau phát hiện luồng sai, và công sức làm đẹp đó khiến cả đội ngại vứt đi. Càng đẹp càng khó bỏ — đó là lý do tâm lý vì sao phải đi từ dưới lên.

Vì sao cần wireframe — ba việc mà tài liệu yêu cầu không làm được

Nó ép bạn quyết những thứ văn bản cho phép né. Tài liệu viết "hiển thị thông tin đơn hàng" là hợp lệ. Bản vẽ buộc bạn trả lời: thông tin nào lên trước, cái gì bị đẩy xuống dưới, cái gì phải bấm mới thấy. Những câu đó là quyết định sản phẩm thật, và văn bản cho phép hoãn chúng tới lúc lập trình — tức là tới lúc đắt nhất.
Nó làm lộ các bước còn thiếu. Khi vẽ, bạn buộc phải hỏi: nếu danh sách rỗng thì màn hình này trông ra sao? Nếu đang tải? Nếu lỗi? Nếu người dùng không có quyền? Đây là những trạng thái luôn bị bỏ quên trong tài liệu và luôn phải làm trong lúc lập trình — không có bản vẽ thì lập trình viên tự quyết, mỗi người một kiểu.
Nó cho cả đội một thứ chung để chỉ tay vào. Mười người đọc cùng một đoạn văn sẽ hình dung mười màn hình khác nhau, và ai cũng tin mình đã hiểu đúng. Sự hiểu lầm đó chỉ lộ ra khi demo — quá muộn.

Cách nhìn đúng: wireframe không phải bước thiết kế. Nó là công cụ tư duy và công cụ giao tiếp — rẻ tiền để tạo ra, rẻ tiền để vứt đi, và đó chính là giá trị của nó.

BƯỚC 1 — Chốt phạm vi đủ để vẽ: PM/PO làm gì trước khi mở công cụ

Đây là phần bị bỏ qua nhiều nhất, và là nguyên nhân số một khiến wireframe phải vẽ lại ba lần. Bạn chưa cần phạm vi hoàn chỉnh — bạn cần phạm vi đủ ổn định để bản vẽ không vô nghĩa.

Bốn câu phải trả lời được trước khi vẽ. Thiếu câu nào thì đi tìm câu đó, đừng vẽ.

Câu hỏi	Câu trả lời tốt trông như thế nào	Câu trả lời yếu
Ai dùng, và họ đang ở trong tình huống gì?	"Trưởng kho, đứng giữa kho, một tay cầm điện thoại, đang vội cuối ca"	"Người dùng nội bộ"
Họ đang cố hoàn thành việc gì?	"Xác nhận 40 mã hàng vừa nhập khớp với phiếu giao"	"Quản lý hàng tồn"
Hôm nay họ làm việc đó ra sao?	"Đánh dấu trên phiếu giấy, tối về gõ lại vào Excel"	"Thủ công"
Cái gì được coi là thành công?	"Xong trước khi hết ca, không phải gõ lại lần hai"	"Tiện lợi hơn"

Vì sao câu thứ ba là câu quan trọng nhất: quy trình hiện tại chứa toàn bộ các ca ngoại lệ thật. Người ta đã tự nghĩ ra cách xử lý khi thiếu hàng, khi phiếu sai, khi mất mạng. Nếu bạn không hỏi, những ca đó sẽ không có trong bản vẽ, và sẽ xuất hiện dưới dạng lỗi sau khi phát hành.

Tách ba loại phát biểu ra riêng — đây là kỹ thuật thực tế nhất trong cả kỹ năng này:

Loại	Nghĩa là	Làm gì với nó
Sự thật	Đã quan sát được, có bằng chứng	Vẽ theo nó
Giả định	Đội đang tin nhưng chưa kiểm	Ghi ra thành danh sách có đánh số. Giả định không được viết ra sẽ được coi là sự thật
Ý kiến	Sở thích cá nhân, không có dữ liệu	Ghi nhận rồi gác lại; đừng để nó dẫn dắt bản vẽ

Với mỗi giả định, hỏi tiếp: nếu điều này sai thì bản vẽ phải đổi bao nhiêu? Giả định nào mà sai sẽ làm đổ cả màn hình thì phải kiểm trước khi vẽ chi tiết. Giả định nhỏ thì cứ vẽ theo và kiểm sau.

BƯỚC 2 — Buổi brainstorm có cấu trúc: từ vấn đề ra bộ tính năng

Có cần brainstorm không? Có — nhưng không phải kiểu ngồi nói tự do. Brainstorm tự do luôn cho ra kết quả nghiêng về người nói to nhất và người có chức vụ cao nhất. Buổi dưới đây chạy 90 phút và cho ra bộ tính năng đã xếp ưu tiên.

Phút	Hoạt động	Cách làm	Vì sao bước này tồn tại
0–10	Đọc lại bốn câu ở bước 1	Dán lên tường, đọc to	Không có nó, mỗi người brainstorm cho một bài toán khác nhau
10–20	Viết lại bài toán dạng "Làm sao để…"	Mỗi người viết 3 câu bắt đầu bằng "Làm sao để…"	Chuyển từ than phiền sang lời mời giải pháp; cũng làm lộ việc mọi người đang hiểu vấn đề khác nhau
20–35	Vẽ 8 ý trong 8 phút, im lặng	Mỗi người gấp giấy làm 8 ô, mỗi ô một ý, không nói chuyện	Im lặng là điều kiện bắt buộc — nó ngăn ý đầu tiên của người cấp cao nhất neo cả phòng
35–50	Dán lên tường, mỗi người trình bày 60 giây	Không ai được phản biện trong vòng này	Cấm phản biện giữ cho ý táo bạo không chết sớm
50–65	Gom ý giống nhau thành nhóm	Di chuyển giấy, đặt tên cho từng nhóm	Các nhóm hiện ra chính là bộ tính năng — nó được phát hiện, không phải được áp đặt
65–80	Chấm điểm bằng sticker	Mỗi người 3 điểm: "cái này giải quyết được việc ở bước 1"	Bỏ phiếu đồng thời tránh được hiệu ứng nghe theo người nói trước
80–90	Chọn một luồng để vẽ	Lấy nhóm điểm cao nhất, viết luồng thành các bước bằng lời	Kết thúc bằng một thứ vẽ được ngay, không phải một danh sách mong muốn

Ai phải có mặt: PO/PM, một người thiết kế, ít nhất một engineer, và một người hằng ngày nói chuyện với người dùng (hỗ trợ khách hàng, kinh doanh, hoặc vận hành). Thiếu người cuối là thiếu người duy nhất biết các ca ngoại lệ thật.

Engineer phải có mặt từ đầu, không phải mời vào lúc cuối để ước lượng. Họ sẽ nói "cái này khó gấp mười, còn cái kia gần như miễn phí" — thông tin đó thay đổi lựa chọn của bạn ngay trong buổi, chứ không phải sau ba tuần vẽ.

BƯỚC 3 — Từ luồng ra danh sách màn hình (suy ra, không đoán)

Đừng bắt đầu bằng câu "app này cần những màn hình nào". Bắt đầu bằng luồng công việc, rồi màn hình sẽ tự hiện ra.

Viết luồng thành câu, mỗi bước một dòng. "Trưởng kho mở phiếu giao → quét mã từng thùng → hệ thống báo khớp hay lệch → xử lý phần lệch → ký xác nhận."
Với mỗi bước, hỏi: người dùng cần THẤY gì và cần LÀM gì? Đó chính là nội dung của một màn hình.
Gộp các bước liền nhau nếu chúng xảy ra cùng một chỗ. Đừng tạo ra màn hình chỉ vì có một bước — mỗi lần chuyển màn hình là một lần người dùng mất ngữ cảnh.
Với mỗi màn hình, liệt kê bốn trạng thái bắt buộc: bình thường, rỗng, đang tải, có lỗi. Đây là bước hay bị bỏ nhất.
Đánh dấu chỗ rẽ nhánh. Mỗi chỗ có "nếu… thì…" là một nhánh phải vẽ, hoặc một quyết định phải chốt rằng ta không làm nhánh đó trong lần này.

Về trạng thái rỗng: nó là màn hình đầu tiên mọi người dùng mới nhìn thấy, và nó gần như luôn được thiết kế cuối cùng hoặc không được thiết kế. Một màn hình rỗng tốt dạy người dùng phải làm gì tiếp; một màn hình rỗng tệ chỉ hiện chữ "Không có dữ liệu" và bỏ mặc họ.

BƯỚC 4 — Vẽ: bố cục nói lên điều gì

Khi vẽ, bạn đang ra ba quyết định, và mỗi quyết định đều có hệ quả thật.

Quyết định	Thể hiện qua	Nó nói với người dùng rằng
Cái gì quan trọng nhất	Vị trí trên cùng, kích thước lớn hơn	"Đây là việc bạn đến đây để làm"
Cái gì đi cùng nhau	Khoảng cách gần, đóng khung chung	"Những thứ này liên quan tới nhau"
Cái gì làm sau	Đẩy xuống dưới, giấu sau một cú bấm	"Bạn không cần cái này ngay bây giờ"

Quy tắc thực tế khi vẽ:

Một màn hình, một việc chính. Nếu bạn không chỉ ra được hành động chính duy nhất, người dùng cũng sẽ không chỉ ra được.
Dùng chữ thật, không dùng chữ giả. Chữ giả che giấu vấn đề: tên sản phẩm thật dài gấp ba, số tiền thật có nhiều chữ số hơn, tên người Việt có dấu làm vỡ dòng.
Vẽ luôn ca xấu nhất. Danh sách 200 dòng, tên dài nhất, số lớn nhất. Bố cục đẹp với 3 dòng dữ liệu mẫu thường vỡ với dữ liệu thật.
Đánh số từng màn hình và ghi chú ngay trên bản vẽ. Bản vẽ không có chú thích sẽ bị hiểu sai đúng như tài liệu bị hiểu sai.
Vẽ trên đúng kích thước thiết bị thật. Vẽ cho màn hình rộng rồi mới lo điện thoại là cách chắc chắn phải làm lại — hãy vẽ cái hẹp trước.

BƯỚC 5 — Làm sao biết đây là UI/UX tốt?

Câu trả lời trung thực: bạn không biết chắc, và bất cứ ai nói chắc đều đang đoán. Nhưng bạn loại được phần lớn thiết kế tệ bằng một bộ câu hỏi, rồi kiểm phần còn lại bằng người dùng thật.

Tự kiểm trước — bảy câu, trả lời trên chính bản vẽ:

Câu hỏi	Đạt khi	Không đạt nghĩa là
Người dùng biết mình đang ở đâu?	Có tiêu đề rõ và dấu hiệu vị trí	Người dùng lạc, nhất là khi vào từ đường liên kết
Việc chính có rõ không?	Chỉ ra được đúng một hành động nổi bật nhất	Màn hình đang phục vụ nhiều mục đích cùng lúc
Có bao nhiêu bước để xong việc?	Đếm được, và đã bỏ hết bước thừa	Mỗi bước thừa làm rơi rụng một phần người dùng
Sai thì sao?	Có thông báo nói rõ sai gì và sửa thế nào	Người dùng kẹt và bỏ cuộc
Có hoàn tác được không?	Hành động nguy hiểm có xác nhận hoặc hoàn tác	Người dùng sợ bấm, nên không dùng tính năng
Người mới lần đầu thấy gì?	Trạng thái rỗng dạy được việc cần làm	Người dùng mới không biết bắt đầu
Cần nhớ gì trong đầu không?	Thông tin cần thiết hiện sẵn trên màn hình	Bắt người dùng nhớ số từ màn hình trước — lỗi rất phổ biến

Kiểm thêm bằng hai phép thử rẻ tiền:

Phép thử 5 giây. Cho ai đó chưa từng thấy nhìn bản vẽ 5 giây rồi che đi. Hỏi: màn hình này để làm gì, việc chính là gì? Trả lời sai nghĩa là thứ tự ưu tiên trên bố cục đang sai.
Phép thử kể lại. Đưa bản vẽ cho một đồng nghiệp không dự buổi brainstorm và nhờ họ kể lại luồng. Chỗ họ ngập ngừng là chỗ bản vẽ chưa rõ.

Điều cần nói thẳng: "UI đẹp" và "UX tốt" là hai chuyện khác nhau. Một màn hình rất đẹp có thể bắt người dùng đi năm bước cho việc lẽ ra một bước. Ở giai đoạn wireframe bạn đang quyết UX; cái đẹp đến sau và không cứu được luồng sai.

BƯỚC 6 — Kiểm chứng với người dùng: hỏi gì và tuyệt đối không hỏi gì

Năm người là đủ để tìm ra phần lớn vấn đề nghiêm trọng. Bạn không cần mẫu lớn — bạn cần đúng năm người thuộc nhóm mục tiêu thật.

Cách chạy một buổi 30 phút:

Nói rõ đây là bản nháp và bạn đang kiểm bản vẽ, không kiểm họ. Câu này phải nói ra thành lời, nếu không người ta sẽ cố tỏ ra thông minh thay vì làm thật.
Giao một nhiệm vụ, không hướng dẫn. "Anh/chị hãy thử xác nhận lô hàng vừa nhập." Rồi im lặng.
Im lặng là công cụ chính của bạn. Khi họ ngập ngừng, đừng cứu. Sự ngập ngừng đó chính là dữ liệu bạn đến để lấy.
Nhờ họ nói ra suy nghĩ: "Anh/chị đang nghĩ gì lúc này?"
Khi họ kẹt, hỏi: "Anh/chị đang mong chuyện gì xảy ra?" — câu này cho bạn biết mô hình trong đầu họ, thứ quý hơn nhiều so với việc họ bấm đúng hay sai.

Đừng hỏi	Vì sao hỏng	Hãy hỏi
"Anh/chị thấy có thích không?"	Người ta sẽ nói thích để bạn vui — gần như luôn luôn	"Anh/chị sẽ làm gì tiếp theo?"
"Cái này dễ dùng chứ?"	Câu hỏi dẫn dắt, chỉ có một câu trả lời lịch sự	"Lúc nãy anh/chị dừng lại ở đây, lúc đó đang nghĩ gì?"
"Anh/chị có muốn thêm tính năng X không?"	Ai cũng muốn thêm mọi thứ khi không phải trả giá	"Lần gần nhất anh/chị gặp việc này là khi nào, xử lý ra sao?"
"Anh/chị hiểu nút này chứ?"	Ép người ta nói hiểu để khỏi ngại	"Theo anh/chị, bấm nút này thì chuyện gì xảy ra?"

Nguyên tắc bao trùm: hỏi về hành vi đã xảy ra và điều họ đang làm ngay lúc này. Đừng hỏi về tương lai hay sở thích — con người dự đoán hành vi tương lai của chính mình rất kém, và điều đó không phải lỗi của họ.

Ghi chép: đếm số người gặp cùng một vấn đề. Ba trên năm người kẹt ở cùng một chỗ là vấn đề phải sửa. Một trên năm có thể chỉ là thói quen riêng.

BƯỚC 7 — Từ wireframe ra ước lượng công sức

Wireframe là đầu vào tốt nhất cho việc ước lượng, vì nó biến "làm màn hình quản lý kho" thành một danh sách đếm được.

Đếm màn hình, và đếm cả trạng thái. Bốn màn hình × bốn trạng thái là mười sáu thứ phải làm, không phải bốn. Đây là lý do phổ biến nhất khiến ước lượng thiếu một nửa.
Đánh dấu chỗ cần dữ liệu mới. Mỗi ô trên màn hình đều phải lấy dữ liệu từ đâu đó. Ô nào hệ thống chưa có là một phần việc ẩn, thường lớn hơn phần giao diện.
Đánh dấu chỗ phụ thuộc bên ngoài. Gọi sang hệ thống khác, cần quyền mới, cần đội khác làm trước — mỗi cái là một rủi ro về thời gian chứ không chỉ về công sức.
Cho engineer đi qua bản vẽ và gắn nhãn S / M / L cho từng màn hình. Đừng đòi số giờ ở giai đoạn này; kích cỡ tương đối chính xác hơn nhiều so với số giờ tuyệt đối.
Hỏi đúng một câu cho mỗi màn hình L: "Có cách nào làm nó thành M bằng cách bỏ bớt gì không?" Câu này thường tiết kiệm nhiều hơn mọi nỗ lực tối ưu sau đó.

Dấu hiệu ước lượng sắp sai: nếu đội ước lượng mà không hỏi câu nào về bản vẽ, nghĩa là họ chưa thật sự đọc nó. Ước lượng tốt luôn đi kèm vài câu hỏi khó.

Nhịp làm việc của đội quanh wireframe

Buổi	Ai dự	Kéo dài	Kết quả
Chốt bối cảnh	PO, BA, một người gần người dùng	60 phút	Bốn câu ở bước 1 có câu trả lời, danh sách giả định có đánh số
Brainstorm có cấu trúc	PO, thiết kế, engineer, người gần người dùng	90 phút	Bộ tính năng đã chấm điểm, chọn một luồng để vẽ
Vẽ	Thiết kế hoặc PO/BA tự vẽ	2–4 giờ	Bản vẽ có đủ bốn trạng thái mỗi màn hình
Đội soi bản vẽ	Cả đội	45 phút	Danh sách chỗ thiếu; engineer nêu chỗ đắt
Thử với người dùng	Người điều phối + 5 người dùng	5 × 30 phút	Danh sách vấn đề kèm số người gặp phải
Sửa và chốt	PO + thiết kế	2 giờ	Bản vẽ đã chốt, ghi rõ phần nào cố tình để lại lần sau

Cả vòng này thường gọn trong một tới hai tuần, và nó rẻ hơn rất nhiều so với việc phát hiện luồng sai sau khi đã lập trình xong.

Hiccups thường gặp và cách xử lý

Hiccup	Vì sao xảy ra	Xử lý
Buổi duyệt bản vẽ chỉ bàn về màu sắc	Bản vẽ trông quá hoàn thiện	Giữ ở mức xám, không màu; nói rõ đầu buổi rằng hôm nay chỉ bàn luồng
Vẽ xong rồi mới phát hiện thiếu dữ liệu	Không ai hỏi mỗi ô lấy dữ liệu từ đâu	Có engineer trong buổi soi bản vẽ; đánh dấu ô cần dữ liệu mới
Chỉ vẽ trạng thái bình thường	Trạng thái rỗng và lỗi không ai nghĩ tới	Bắt buộc bốn trạng thái cho mỗi màn hình, coi như một mục kiểm
Người dùng khen hết lời, phát hành xong thì không ai dùng	Hỏi về sở thích thay vì quan sát hành vi	Giao nhiệm vụ và im lặng quan sát; không hỏi có thích không
Bản vẽ đẹp tới mức không ai dám bỏ	Nhảy thẳng lên mockup	Đi từ phác thảo tay; giữ mức thấp cho tới khi luồng được xác nhận
Mỗi engineer hiểu bản vẽ một kiểu	Bản vẽ không có chú thích	Đánh số màn hình, ghi chú ngay trên bản vẽ, ghi rõ chỗ cố tình chưa làm
Ước lượng thiếu một nửa	Chỉ đếm màn hình, không đếm trạng thái và phụ thuộc	Đếm màn hình × trạng thái; đánh dấu dữ liệu mới và phụ thuộc bên ngoài

Vì sao vai trò của bạn cần cái này

Vai trò	Bạn dùng nó để
Product Owner	Bản vẽ là nơi bạn ra quyết định ưu tiên một cách cụ thể — cái gì lên trên, cái gì để lần sau. Nó cũng là cách rẻ nhất để kiểm tra giả định trước khi tiêu tiền lập trình.
Business Analyst	Bản vẽ làm lộ ca ngoại lệ mà tài liệu giấu được. Vẽ bốn trạng thái mỗi màn hình chính là việc phân tích, chỉ khác cách thể hiện.
Product Manager	Bạn dùng nó để căn chỉnh nhiều bên về cùng một hình dung, và để lấy ước lượng đáng tin trước khi cam kết ngày.
Designer	Bạn dẫn phần bố cục và thứ tự ưu tiên thị giác, và giữ cho đội không nhảy lên mockup quá sớm.
Engineer	Bạn có mặt sớm để nêu cái gì đắt cái gì rẻ — thông tin đó đổi thiết kế ngay tại buổi, thay vì sau ba tuần.
QA	Bốn trạng thái mỗi màn hình chính là bộ ca kiểm thử đầu tiên của bạn, có sẵn từ trước khi code tồn tại.

Definition of done

Bốn câu bối cảnh đã có câu trả lời cụ thể, không chung chung.
Giả định được viết thành danh sách đánh số, và giả định rủi ro cao đã được kiểm trước khi vẽ chi tiết.
Bộ tính năng đến từ một buổi brainstorm có cấu trúc, có engineer và người gần người dùng tham gia.
Mỗi màn hình có đủ bốn trạng thái: bình thường, rỗng, đang tải, lỗi.
Bản vẽ dùng chữ thật và đã thử với ca dữ liệu xấu nhất.
Đã qua bảy câu tự kiểm và phép thử 5 giây.
Đã thử với ít nhất 5 người dùng thật, ghi lại số người gặp mỗi vấn đề.
Ước lượng đếm cả trạng thái, dữ liệu mới và phụ thuộc bên ngoài.
Ghi rõ phần nào cố tình để lại lần sau, để không ai tưởng là bỏ sót.