Vỡ lòng (2) sẽ xoay quanh thành phần tiếp theo trong product documents mà công ty cũ của Py thường dùng: screen flow1. Như đúng tên gọi, screen flow chủ yếu tập trung mô tả user sẽ tương tác như thế nào trên các màn hình để hoàn thành “tác vụ”, và những cách “biến tấu” để khai thác tối đa sức mạnh của screen flow.
Wireframe và Mockup2
Khái niệm “vỡ lòng” khác cần nắm để hiểu screen flow là wireframe và mockup. Trong hành trình thiết kế sản phẩm:
- Wireframe là khung xương – một bản phác thảo đơn giản, không màu mè, giúp đội ngũ định hình cấu trúc và luồng trải nghiệm cơ bản của người dùng. Nó giống như việc bạn vẽ sơ đồ bố trí căn phòng trước khi bắt tay vào trang trí – không cần đẹp, chỉ cần đúng.
- Mockup là bước “lên màu” cho bản thiết kế, nơi mọi chi tiết về màu sắc, hình ảnh, kiểu chữ bắt đầu xuất hiện, giúp hình dung rõ hơn sản phẩm sẽ trông như thế nào khi hoàn thiện.
Cũng có lẽ vì vậy nên wireframe thường ở dạng ảnh đen trắng và do PO vẽ. Ở một số công ty, mockup đôi khi còn được xem như bản design cuối cùng nên sẽ thuộc SoW của Designer.
Ví dụ về wireframe và mockup (by ChatGPT 4o)
Để vẽ wireframe, gần đây Py thường dùng Figma nhiều hơn (có giai đoạn cũng dùng Adobe XD). Tool này có hỗ trợ nhiều bộ kit mà chắc Py sẽ nói rõ hơn ở Vỡ lòng (3) về vai trò của những bộ kit đó. Trước đây, Py có dùng Balsamiq (https://balsamiq.com/) và vẫn đề xuất các bạn trải nghiệm tool này:
- Thứ nhất, vì nó đơn giản do đã loại bỏ kha khá các yếu tố liên quan đến design (ví dụ như kích thước màn hình).
- Thứ hai, vì Balsamiq cung cấp tương đối đa dạng các components trong thiết kế phần mềm (dropdown list, combo box…). Việc gọi chính xác các loại components phổ biến cũng giúp BA/PO diễn giải yêu cầu cho team Dev, cũng như thống nhất những vấn đề UX cơ bản với Requester (stakeholders) hay Designers.
- Thứ ba, vì Balsamiq mang đến cảm giác “low-fidelity wireframe” – wireframe nên “mộc” nhất có thể để tập trung vào diễn giải user flow trên mỗi màn hình, thay vì thiết kế chi tiết từng màn hình.
Ở một vài dự án, sẽ có những team chuyên biệt trau chuốt thêm về UI/UX (ví dụ như UI/UX Designer), và trong các dự án có nhiều team tham gia thì sử dụng “low-fidelity wireframe” là cách thể hiện sự tôn trọng phạm vi công việc của nhau – gián tiếp gia tăng hiệu quả tổng thể, điều ít được nói đến nhưng không có nghĩa là không quan trọng.
Túi mù: https://wireframe.cc/
Đây là tool mới Py tìm được gần đây. Tương tự như Balsamiq, wireframe.cc cung cấp sẵn các component phổ biến với giao diện/màu sắc đơn giản. Nhưng cũng như Balsamiq, tool này có tính phí, nên có thể dùng để trải nghiệm và làm quen với việc vẽ wireframe. Còn để sử dụng lâu dài thì có vẻ Figma vẫn có lợi thế hơn.
Screen Flow / Wireflow
Trong screen flow, “screen” có thể là wireframe hoặc mockup, vì mục đích chính là cần diễn tả user cần tương tác (với UI elements) ở đâu trên mỗi màn hình. Bên cạnh screen flow còn có khái niệm wireflow – sự kết hợp giữa wireframe (khung giao diện) và user flow (luồng người dùng), giúp mô tả chi tiết cách người dùng tương tác với từng màn hình trong ứng dụng hoặc website.
Trở về task “vỡ lòng”, vì docs được viết sau khi tính năng đã được build, nên trong docs Py sử dụng chính ảnh chụp màn hình (screenshot) từ app để vẽ lại. Thật ra giữa user flow và screen flow có mối liên hệ tương đối chặt chẽ: một (hoặc vài) bước sẽ được diễn tả trên một màn hình tương ứng. Screen flow giống như một cách diễn giải khác của user flow, nhưng thiên về chi tiết hóa việc user cần làm gì trên mỗi màn hình.
Qua trải nghiệm của Py, screen flow/wireflow là thành tố quan trọng nhất trong docs, vì nó thể hiện cả phần logic (user cần thực hiện các bước nào – giống như user flow) và UX (user tương tác như thế nào – giống như wireframe). Nên đến thời điểm hiện tại, đây là công cụ Py thường xuyên sử dụng nhất để mô tả/xác nhận yêu cầu với các teams. Vì thông thường, hơn một nửa các vấn đề sẽ phát sinh xung quanh việc user cần làm gì, làm xong rồi làm gì, bấm ở đâu trên màn hình… (bên cạnh các câu hỏi như “vì sao user cần làm cái này” hay “làm cái này để được gì”) – nghe có vẻ thô nhưng đây là những câu hỏi Py thường xuyên phải tìm lời giải.
Trên thực tế, screen flow/wireflow đôi khi không chỉ bao gồm các màn hình. Tùy flow, Py sẽ chèn thêm cả “user step” để diễn giải rõ hơn về logic. Nói chung, sứ mệnh của flow là hình ảnh hóa các sợi tư duy, nên không cần đảm bảo nghiêm ngặt các tiêu chuẩn chung, miễn là đạt được mục tiêu cuối cùng – giao tiếp – là được.
Để vẽ screen flow/wireflow, Py thường dùng FigJam. Nhìn chung, Py ưu tiên các công cụ web-based để tiện truy cập và dễ chia sẻ.
Ví dụ by Anpy
Đến phần này, sau khi vẽ lại screen flow, Py cũng đã trao đổi lại lần nữa với anh PM để xem mình đang đi đúng hướng hay chưa (cho cả user flow và screen flow) trong lần đầu chạm ngõ công việc product. Mặc dù nghe có vẻ tốn thời gian, nhưng chính những lần catch-up liên tục như vậy Py mới kịp nhận ra những điểm chưa ổn thỏa và hoàn thiện trước khi tốn nhiều công sức hơn ở phần 3: Screen Description – phần cuối của chuỗi Vỡ lòng.
- Miro. (n.d.). Screen flow template. Miro. Retrieved May 5, 2025, from https://miro.com/templates/screen-flow/
- Thịnhnotes. (n.d.). Phân biệt Sketch, Wireframe, Mockup và Prototype. Thịnhnotes. Retrieved May 5, 2025, from https://thinhnotes.com/chuyen-nghe-ba/phan-biet-sketch-wireframe-mockup-va-prototype/
- Babich, N. (2017, September 3). Wireflows: A UX deliverable for documenting interaction design. Nielsen Norman Group. https://www.nngroup.com/articles/wireflows/
Cám ơn bạn đã nán lại cho đến những dòng cuối cùng này.
Chúc bạn nhiều may mắn và bình an.
Anpy
Leave a Reply