Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn viết một đoạn mô tả luồng đăng ký dài ba trang giấy: "Người dùng nhập số điện thoại, hệ thống gửi OTP, nếu OTP đúng thì vào màn hình tạo mật khẩu, nếu sai quá ba lần thì khóa 30 phút, trừ khi người dùng đã từng đăng ký bằng Google thì..."
Luồng đăng ký với các điểm rẽ nhánh và ngoại lệ:
flowchart TD
A[Nhập số điện thoại] --> B{Hệ thống gửi OTP}
B --> C{OTP đúng?}
C -->|Đúng| D[Màn hình tạo mật khẩu]
C -->|Sai| E{Sai quá 3 lần?}
E -->|Có| F[Khóa 30 phút]
E -->|Không| B
F --> G{Người dùng đã từng đăng ký bằng Google?}
G -->|Có| D
G -->|Không| F
Đọc đến câu thứ năm, kỹ sư đã bắt đầu cuộn lên cuộn xuống để hiểu cái "nếu" này thuộc về nhánh nào. Đến câu thứ mười, designer hỏi: "Vậy màn hình khóa tài khoản trông như thế nào, và nó có nút quay lại không?" — một câu hỏi mà đoạn văn của bạn vô tình bỏ sót.Đây chính là lý do flow diagram tồn tại. Ngôn ngữ tự nhiên rất giỏi diễn đạt sắc thái, nhưng rất tệ trong việc diễn đạt sự phân nhánh và song song. Một quy trình có ba điểm rẽ nhánh, mỗi nhánh lại có hai kết cục, sẽ tạo ra một mạng lưới mà não người không thể giữ trong đầu cùng lúc nếu chỉ đọc chữ. Flow diagram biến cái mạng lưới đó thành hình ảnh — và bộ não con người xử lý hình ảnh nhanh hơn chữ viết hàng chục lần.
Với một PM viết PRD, flow diagram không phải để cho đẹp. Nó là công cụ tự kiểm tra tư duy: khi bạn buộc phải vẽ ra mọi nhánh, bạn sẽ phát hiện những lỗ hổng mà chính bạn chưa nghĩ tới — cái nhánh "nếu thanh toán thất bại giữa chừng" mà lúc viết văn xuôi bạn đã lờ đi. Bài này tập trung vào công cụ nào nên dùng khi nào và những quy ước (conventions) khiến diagram của bạn được đọc hiểu ngay mà không cần giải thích. Chúng ta không bàn về việc khi nào nên dùng diagram thay vì chữ (bài 58 lo phần đó), cũng không đi sâu wireframe (bài 20) — ở đây chỉ tập trung vào flow: dòng chảy của hành động và quyết định.
Khái niệm cốt lõi
Flow diagram là gì và không phải là gì
Flow diagram (sơ đồ luồng) mô tả trình tự các bước, các điểm quyết định và các kết cục của một quy trình. Nó trả lời câu hỏi "chuyện gì xảy ra tiếp theo, và phụ thuộc vào điều kiện gì". Nó không phải là sơ đồ kiến trúc hệ thống (các service nói chuyện với nhau ra sao), cũng không phải là wireframe (mỗi màn hình trông thế nào). Trong PRD, flow diagram thường nằm ở phần Solution, ngay trước hoặc xen kẽ với phần mô tả user-facing behavior.
Có vài loại flow diagram phổ biến mà PM hay dùng:
- User flow: các bước người dùng đi qua, thường từ một điểm vào (entry point) đến một mục tiêu (goal). Ví dụ: từ trang chủ → tìm sản phẩm → thêm vào giỏ → thanh toán → xác nhận.
- Flowchart (sơ đồ quyết định): nhấn mạnh các điểm rẽ nhánh có/không. Phù hợp khi logic phức tạp, nhiều điều kiện.
- Sequence diagram (sơ đồ tuần tự): mô tả thứ tự các "tác nhân" gửi thông điệp cho nhau theo thời gian — người dùng, app, server, bên thứ ba. PM thường dùng khi spec một tính năng có nhiều bên tham gia (ví dụ thanh toán qua cổng VNPay).
Ba bộ công cụ và khi nào dùng cái nào
Không có công cụ "tốt nhất" — chỉ có công cụ phù hợp với ngữ cảnh và giai đoạn của bạn.
Whimsical — nhanh, sạch, có gói miễn phí rộng rãi. Đây là lựa chọn mặc định tôi khuyên cho hầu hết PM. Whimsical được thiết kế riêng cho việc vẽ flowchart và user flow: bạn gõ, kéo, nó tự căn chỉnh đẹp. Khi bạn cần dựng nhanh một sơ đồ để đính vào PRD và muốn nó trông gọn gàng mà không tốn nửa tiếng chỉnh khoảng cách, Whimsical là bạn của bạn. Điểm yếu: không mạnh về realtime collaboration kiểu workshop đông người, và khi sơ đồ quá lớn (vài chục node) thì bắt đầu rối.
Miro / FigJam — thiên về cộng tác (collaborative), tuyệt vời cho workshop. Khi bạn ngồi cùng team brainstorm luồng trong một buổi họp — mọi người cùng thả sticky note, kéo mũi tên, comment trực tiếp — thì Miro hoặc FigJam là sân nhà. FigJam có lợi thế nếu team design của bạn đã sống trong hệ sinh thái Figma (link thẳng từ flow sang mock). Điểm yếu: vì là canvas tự do nên sơ đồ dễ trở nên lộn xộn, thiếu chuẩn mực; sản phẩm cuối thường cần "dọn dẹp" lại trước khi đưa vào PRD chính thức.
Lucidchart — trang trọng (formal), mạnh về sơ đồ chuẩn công nghiệp. Khi bạn cần một sequence diagram đúng chuẩn UML, hoặc tài liệu sẽ được dùng trong môi trường enterprise nơi người ta quen với ký hiệu hình thức, Lucidchart vượt trội nhờ thư viện shape phong phú và tính năng tự động. Điểm yếu: nặng nề hơn, đường cong học tập dốc hơn, và gói miễn phí giới hạn số lượng object.
Ngoài ra, có một lựa chọn mà tôi luôn nhắc học viên: Mermaid — viết diagram bằng text. Bạn gõ vài dòng cú pháp đơn giản, nó render ra sơ đồ. Lợi ích lớn nhất: diagram nằm ngay trong file Markdown của PRD (Notion, GitHub, Confluence đều hỗ trợ), nên nó version-control được và không bao giờ lệch khỏi tài liệu. Khi bạn sửa một bước, bạn sửa text — không phải mở công cụ khác, export ảnh, rồi dán lại. Với team kỹ thuật, đây thường là lựa chọn thắng cuộc.
Quy ước (conventions) — thứ khiến diagram được hiểu ngay
Công cụ chỉ là phương tiện. Cái quyết định diagram của bạn có "đọc phát hiểu luôn" hay không chính là việc tuân thủ quy ước. Đây là bộ quy ước tối thiểu bạn nên ghim vào đầu:
- Hình dạng có ý nghĩa cố định. Hình chữ nhật (rectangle) = một bước/hành động. Hình thoi (diamond) = điểm quyết định, luôn có ít nhất hai nhánh ra. Hình bo tròn/oval = điểm bắt đầu (Start) hoặc kết thúc (End). Hình bình hành = input/output. Đừng dùng hình thoi cho một bước thông thường — người đọc sẽ tự động tìm nhánh rẽ và bối rối khi không thấy.
- Mũi tên đi một chiều, có hướng rõ ràng. Dòng chảy nên đi từ trên xuống hoặc trái sang phải — chọn một và nhất quán. Tránh mũi tên cắt chéo nhau như mạng nhện.
- Nhánh từ điểm quyết định luôn có nhãn. Mỗi mũi tên ra khỏi hình thoi phải ghi rõ điều kiện: "Có/Không", "OTP đúng/sai", "Số dư đủ/không đủ". Một hình thoi không nhãn là một diagram chưa hoàn thành.
- Một diagram = một mục tiêu. Đừng nhồi cả luồng đăng ký, luồng thanh toán và luồng hoàn tiền vào một sơ đồ. Tách ra. Nếu phải nối, dùng "connector" (vòng tròn nhỏ ghi chữ A, B) để trỏ sang sơ đồ khác.
- Phải có happy path nổi bật. Luồng chính (mọi thứ suôn sẻ) nên là một đường thẳng dễ thấy; các nhánh lỗi/ngoại lệ rẽ ra hai bên. Người đọc cần thấy "câu chuyện chính" trong ba giây đầu.
Tình huống thực tế
Ví dụ 1 — Tiki và luồng "thanh toán thất bại" bị bỏ quên
Một PM ở một sàn TMĐT lớn (gọi là bối cảnh kiểu Tiki) viết PRD cho tính năng "thanh toán bằng số dư ví". Bản đầu tiên chỉ có văn xuôi: "Người dùng chọn ví, nhập PIN, hệ thống trừ tiền và tạo đơn." Nghe rất gọn. Nhưng khi PM ngồi vẽ flowchart trên Whimsical, đến hình thoi "PIN đúng?" cô buộc phải vẽ nhánh "Sai". Rồi đến hình thoi "Số dư đủ?" — nhánh "Không đủ" dẫn đi đâu?
Luồng thanh toán bằng số dư ví phát hiện edge case thiếu số dư:
flowchart TD
A[Chọn ví] --> B[Nhập PIN]
B --> C{PIN đúng?}
C -->|Đúng| D{Số dư đủ?}
C -->|Sai| E[Thông báo sai PIN]
D -->|Đủ| F[Trừ tiền và tạo đơn]
D -->|Không đủ| G[Đề xuất nạp nhanh]
Lúc này cô nhận ra mình chưa hề nghĩ tới: nếu số dư thiếu 20.000đ thì người dùng có được gợi ý nạp thêm ngay không, hay bị đá về giỏ hàng?Việc vẽ diagram đã lôi ra hai edge case mà ba trang văn xuôi che giấu. Bài học: flow diagram không chỉ để giao tiếp, nó là một bài kiểm tra tính đầy đủ của tư duy. Cứ mỗi hình thoi bạn vẽ, bạn bị ép phải định nghĩa cả hai nhánh — và đó là lúc lỗ hổng lộ ra. Cô đã thêm một bước "Đề xuất nạp nhanh" vào nhánh thiếu số dư, và tính năng ship ra giảm 12% tỷ lệ bỏ giỏ ở bước thanh toán ví.
Ví dụ 2 — Một startup fintech ở Singapore và buổi workshop trên FigJam
Một startup fintech khu vực Đông Nam Á (trụ sở Singapore) cần thiết kế luồng onboarding KYC (xác minh danh tính) cho thị trường có quy định nghiêm ngặt. Quy trình dính tới: chụp CCCD, selfie đối chiếu, kiểm tra danh sách đen, và phê duyệt thủ công nếu hệ thống không chắc chắn.
Tương tác giữa người dùng, app, hệ thống KYC và phê duyệt thủ công:
sequenceDiagram
participant User as Người dùng
participant App as App
participant KYC as Hệ thống KYC
participant Admin as Phê duyệt thủ công
User->>App: Chụp CCCD
App->>KYC: Gửi ảnh CCCD
KYC-->>App: Kết quả trích xuất
User->>App: Chụp selfie
App->>KYC: Gửi selfie
KYC-->>App: Kết quả đối chiếu
App->>KYC: Kiểm tra danh sách đen
KYC-->>App: Kết quả
alt Hệ thống không chắc chắn
App->>Admin: Yêu cầu phê duyệt thủ công
Admin-->>App: Phê duyệt/Từ chối
end
Đây là loại luồng nhiều bên, nhiều nhánh, lại cần cả compliance, legal, engineering cùng đóng góp.PM chọn FigJam cho buổi workshop hai tiếng. Lý do: cần mười người cùng tham gia realtime, mỗi người dán sticky cho phần họ phụ trách — compliance dán các điểm bắt buộc theo luật, engineering dán giới hạn kỹ thuật của nhà cung cấp KYC. Canvas tự do giúp ý tưởng tuôn ra nhanh. Nhưng — và đây là điểm mấu chốt — sau workshop, sơ đồ FigJam trông như bãi chiến trường: mũi tên chồng chéo, không nhất quán hình dạng. PM dành hai tiếng tiếp theo vẽ lại sạch sẽ trên Lucidchart với đầy đủ ký hiệu chuẩn để đưa vào PRD chính thức nộp cho bộ phận compliance.
Bài học: dùng đúng công cụ cho đúng giai đoạn. FigJam/Miro để phát sinh ý tưởng trong workshop; công cụ trang trọng hơn (Lucidchart) hoặc gọn gàng (Whimsical) để trình bày kết quả cuối. Đừng nộp bản nháp workshop làm tài liệu chính thức.
Ví dụ 3 — Team kỹ thuật và Mermaid trong PRD trên Notion
Một PM tại một công ty SaaS B2B người Việt làm sản phẩm cho thị trường quốc tế. Team kỹ thuật của anh có thói quen review mọi thứ qua pull request và ghét những ảnh diagram "chết" — vì cứ mỗi lần đổi logic là ảnh lại lỗi thời, còn file gốc thì không ai tìm thấy. Anh chuyển toàn bộ flow diagram trong PRD sang Mermaid, viết thẳng trong Notion.
Kết quả: khi engineering đề xuất đổi thứ tự hai bước trong luồng, họ sửa luôn ba dòng Mermaid trong comment PRD, PM duyệt, và sơ đồ tự cập nhật — không có khoảng cách giữa "ảnh trong tài liệu" và "logic thực". Sau sáu tháng, anh ước tính tiết kiệm được khoảng hai tiếng mỗi tuần chỉ riêng việc không phải export-rồi-dán-lại ảnh.
Bài học: nếu khán giả chính của PRD là kỹ sư và tài liệu sống trong môi trường hỗ trợ Markdown (Notion, GitHub, GitLab, Confluence), diagram-as-text như Mermaid thường thắng về tính bền vững. Đánh đổi: nó kém linh hoạt cho những bố cục phức tạp, đẹp mắt — nhưng với flow đơn giản đến trung bình thì quá đủ.
Hướng dẫn từng bước
Đây là quy trình để dựng một flow diagram tốt cho PRD:
- Xác định điểm vào và mục tiêu. Trước khi vẽ bất cứ gì, viết một câu: "Sơ đồ này bắt đầu từ [đâu] và kết thúc khi [người dùng đạt được gì]." Nếu không trả lời được, bạn chưa sẵn sàng vẽ.
- Liệt kê happy path bằng chữ trước. Viết 4–7 bước của luồng lý tưởng (mọi thứ suôn sẻ) thành danh sách đánh số. Đây là xương sống.
- Tìm các điểm quyết định. Đọc lại happy path, hỏi ở mỗi bước: "Có điều kiện gì khiến luồng rẽ hướng không?" Mỗi câu "nếu" là một hình thoi tiềm năng.
- Vẽ nhánh cho từng quyết định — cả hai phía. Đây là bước lôi ra edge case. Với mỗi hình thoi, đừng để nhánh nào "lửng lơ". Nhánh thất bại dẫn đi đâu? Quay lại bước nào, hay đến màn hình lỗi nào?
- Chọn công cụ theo ngữ cảnh. Cần nhanh và gọn → Whimsical. Cần workshop nhiều người → Miro/FigJam. Cần chuẩn formal/enterprise → Lucidchart. Tài liệu Markdown, khán giả là dev → Mermaid.
- Áp quy ước hình dạng và nhãn. Rà soát: mọi hình thoi có hai nhánh có nhãn chưa? Mọi mũi tên đi cùng một hướng chưa? Có Start và End rõ ràng chưa?
- Đặt tiêu đề và đánh số phiên bản. Mỗi diagram cần một tiêu đề ("Luồng thanh toán bằng ví — v2") để khi tham chiếu trong PRD không bị nhầm.
- Nhúng vào PRD đúng chỗ. Đặt diagram ngay cạnh đoạn mô tả behavior tương ứng, kèm một câu dẫn: "Sơ đồ dưới đây mô tả luồng X; chú ý nhánh Y xử lý trường hợp Z."
Lỗi thường gặp & mẹo
Lỗi: Vẽ diagram quá to, ôm cả vũ trụ. Một sơ đồ 40 node không ai đọc nổi. Mẹo: nếu vượt quá ~15 node, tách thành nhiều sơ đồ con và dùng connector nối.
Lỗi: Hình thoi không nhãn nhánh. "PIN đúng?" rồi hai mũi tên trắng trơn — người đọc không biết cái nào là "đúng". Luôn ghi nhãn.
Lỗi: Trộn lẫn user flow và system flow. Khi nửa sơ đồ nói về việc người dùng bấm nút, nửa kia nói về việc server gọi API, người đọc lạc lối. Tách góc nhìn: hoặc kể từ phía người dùng, hoặc dùng sequence diagram để thể hiện cả hai bên rõ ràng.
Lỗi: Diagram "chết" lệch khỏi tài liệu. Bạn export ảnh, dán vào PRD, rồi tuần sau đổi logic mà quên cập nhật ảnh. Mẹo: với flow đơn giản, dùng diagram-as-text (Mermaid) để nó sống cùng tài liệu; với công cụ ngoài, luôn để link tới file gốc cạnh ảnh.
Mẹo: Tô màu happy path. Cho luồng chính một màu nổi (xanh lá), nhánh lỗi màu xám/đỏ nhạt. Người đọc nắm "câu chuyện chính" tức thì.
Mẹo: Đặt diagram đi đôi với chữ, đừng thay thế hoàn toàn. Diagram giỏi thể hiện cấu trúc; chữ giỏi thể hiện sắc thái và lý do. PRD tốt dùng cả hai.
Bài tập thực hành
Chọn một tính năng bạn từng dùng hằng ngày — ví dụ luồng "đặt xe" trên Grab, hoặc "đăng nhập bằng OTP" trên một app ngân hàng Việt Nam. Sau đó:
- Viết happy path bằng chữ thành danh sách đánh số (tối đa 7 bước).
- Xác định ít nhất ba điểm quyết định và vẽ cả hai nhánh cho mỗi điểm — bắt buộc ghi nhãn nhánh.
- Vẽ lại thành flow diagram trên một công cụ bạn chưa từng dùng (nếu hay dùng Whimsical thì thử Mermaid, và ngược lại). Mục tiêu là cảm nhận sự đánh đổi giữa các công cụ.
- Tự rà soát theo checklist quy ước: hình dạng đúng nghĩa? mũi tên một hướng? happy path nổi bật? mọi nhánh đều dẫn tới đâu đó (không lửng lơ)?
- Gửi cho một đồng nghiệp và hỏi: "Trong 10 giây, bạn có thấy được luồng chính không?" Nếu họ ngập ngừng, sơ đồ của bạn cần dọn lại.
Tóm tắt
Flow diagram là công cụ biến sự phân nhánh phức tạp — thứ mà văn xuôi diễn đạt rất tệ — thành hình ảnh mà não người nắm trong vài giây. Quan trọng hơn, hành động vẽ diagram là một bài kiểm tra tính đầy đủ: mỗi điểm quyết định ép bạn định nghĩa cả hai nhánh, lôi ra những edge case bị giấu trong các câu "nếu". Về công cụ: Whimsical cho tốc độ và sự gọn gàng (lựa chọn mặc định), Miro/FigJam cho workshop cộng tác, Lucidchart cho sơ đồ trang trọng kiểu enterprise, và Mermaid (diagram-as-text) khi bạn muốn sơ đồ sống ngay trong tài liệu Markdown và không bao giờ lệch. Dùng đúng công cụ cho đúng giai đoạn: canvas tự do để phát sinh ý tưởng, công cụ chuẩn mực để trình bày kết quả. Cuối cùng, conventions mới là thứ quyết định: hình dạng có ý nghĩa cố định, mọi nhánh quyết định đều có nhãn, một sơ đồ chỉ phục vụ một mục tiêu, và happy path luôn phải nổi bật để người đọc thấy "câu chuyện chính" ngay lập tức.