Mở đầu — vì sao bài này quan trọng
Đến sáng thứ Năm của một Design Sprint, bạn đã có trong tay một storyboard hoàn chỉnh — từng khung hình mô tả trải nghiệm mà người dùng sẽ đi qua khi thử prototype vào thứ Sáu. Nhưng storyboard trên giấy hay trên tường không phải là thứ bạn có thể đưa cho một người lạ và bảo "hãy dùng thử đi". Nhiệm vụ của cả ngày thứ Năm là biến những khung hình tĩnh đó thành một prototype có thể bấm được, trông đủ thật để người dùng phản ứng như với một sản phẩm thật.
Và đây là chỗ nhiều team vấp ngã. Không phải vì họ không biết dùng Figma, mà vì họ tổ chức việc dựng prototype sai cách. Bốn, năm người cùng lao vào một file, mỗi người vẽ một kiểu, font khác nhau, nút bấm lệch nhau vài pixel, đến chiều thứ Năm thì có một mớ hỗn độn không ghép lại được. Tôi đã chứng kiến những sprint tan vỡ đúng vào 4 giờ chiều thứ Năm — không phải vì ý tưởng dở, mà vì khâu build hỗn loạn đến mức thứ Sáu không có gì để test.
Bài này tập trung riêng vào một mảnh việc rất cụ thể: cách tổ chức và vận hành việc dựng prototype trong Figma vào ngày thứ Năm. Chúng ta sẽ không bàn về chiến lược prototype nên "giả thật" đến đâu (đó là bài trước), cũng không bàn về việc viết kịch bản phỏng vấn (đó là bài sau). Ở đây chỉ có một câu hỏi: làm thế nào để 4-5 người, trong vòng khoảng 6-7 tiếng đồng hồ, cùng tạo ra một prototype Figma gọn gàng, nhất quán và chạy được. Đây là kỹ năng vận hành thuần túy, nhưng nó quyết định chất lượng của cả ngày thứ Sáu.
Khái niệm cốt lõi
Nguyên tắc "một chủ file duy nhất"
Nguyên tắc quan trọng nhất của ngày build là: một người duy nhất sở hữu file Figma master (the Stitcher — người khâu nối). Nghe có vẻ ngược đời — Figma nổi tiếng là công cụ collaborative, nhiều người cùng edit real-time cơ mà? Đúng, nhưng chính vì thế mà nó nguy hiểm trong bối cảnh sprint áp lực cao.
Khi 5 người cùng thao tác trên một artboard, bạn sẽ có: chuột đè lên nhau, người này xóa nhầm layer của người kia, style bị ghi đè, và không ai biết phiên bản "thật" là cái nào. Trong sách "Sprint" của Jake Knapp, vai trò này được gọi là Stitcher — người khâu nối. Người này sở hữu file master, chịu trách nhiệm về tính nhất quán tổng thể (font, màu, spacing, tên frame), và là người duy nhất quyết định thứ gì được đưa vào bản cuối.
Những người còn lại (thường 2-3 người) là Contributors — người đóng góp. Mỗi người làm việc trong khu vực riêng của mình, rồi phần việc hoàn thành mới được merge vào file master.
Chia việc theo màn hình, không phải theo tính năng
Cách chia việc hiệu quả nhất là cắt storyboard thành các phân đoạn (segment) và giao mỗi contributor một chuỗi màn hình liên tiếp. Ví dụ storyboard có 15 khung: người A dựng khung 1-5 (màn hình mở đầu và onboarding), người B dựng khung 6-10 (luồng chính), người C dựng khung 11-15 (thanh toán và xác nhận). Cách chia theo màn hình liên tiếp giúp mỗi người tự chịu trách nhiệm về sự mạch lạc trong đoạn của mình, và giảm thiểu điểm giao cắt.
Tránh chia theo kiểu "người này làm header cho tất cả màn hình, người kia làm footer" — kiểu chia ngang này tạo ra hàng chục điểm phụ thuộc, ai cũng phải chờ ai.
Làm việc trong frame riêng rồi merge
Về mặt kỹ thuật trong Figma, có hai mô hình phổ biến:
Mô hình A — Cùng một file, các page riêng: Stitcher tạo sẵn file master với nhiều page (tab). Mỗi contributor được giao một page nháp riêng để dựng ("Page - An", "Page - Bình"...). Khi xong, Stitcher copy các frame hoàn thiện sang page "Master Flow" và sắp xếp theo đúng thứ tự bấm. Đây là mô hình được khuyên dùng nhất vì mọi người vẫn chung một design system, chung một file, dễ đồng bộ style.
Mô hình B — File riêng rồi copy sang: Mỗi contributor có file Figma riêng, cuối buổi copy-paste frame vào file master. Cách này an toàn hơn về xung đột nhưng dễ lệch style nếu không dùng chung thư viện component.
Với đa số sprint, Mô hình A là lựa chọn tối ưu.
Vai trò của design system dùng chung
Đây là "vũ khí bí mật" để đạt được sự nhất quán mà không tốn thời gian. Nếu công ty bạn đã có sẵn một design system — thư viện component Figma với các nút, ô input, card, màu sắc, typography đã định nghĩa — thì hãy dùng nó ngay từ đầu buổi sáng. Contributors chỉ việc kéo-thả component có sẵn thay vì vẽ lại từng nút. Kết quả: 4 người dựng 4 màn hình khác nhau nhưng trông như do một người làm.
Nếu chưa có design system chính thức, Stitcher nên dành 20-30 phút đầu giờ tạo một "mini kit": định nghĩa 1 font, 2-3 màu, một bộ nút cơ bản, một ô input, và biến chúng thành component. Sau đó chia sẻ cho cả team. Nửa giờ đầu tư này tiết kiệm hàng giờ chỉnh sửa về sau.
Tình huống thực tế
Ví dụ 1 — Tiki và bài học "hỗn loạn 5 con trỏ chuột"
Một team thuộc mảng thương mại điện tử (bối cảnh mô phỏng theo kiểu Tiki tại TP.HCM) chạy sprint để thử một luồng "mua lại nhanh" cho khách hàng quen. Ngày thứ Năm, cả 5 thành viên cùng nhảy vào một artboard duy nhất trong Figma vì "cho nhanh". Đến 2 giờ chiều, họ có 5 con trỏ chuột chen chúc trên cùng vài màn hình, một designer vô tình xóa nguyên component giỏ hàng mà người khác đang dựng, và không ai chắc màu nút CTA là đỏ #E4393C hay đỏ #FF424E.
Kết quả: đến 5 giờ chiều họ vẫn chưa có prototype liền mạch, phải làm thêm 2 tiếng và sáng thứ Sáu vẫn còn vài màn hình chưa link được. Buổi test bị lùi 90 phút.
Bài học: Sang sprint sau, họ áp dụng đúng mô hình một Stitcher. Anh lead designer sở hữu file master, 3 người còn lại mỗi người một page nháp. Đến 4 giờ chiều prototype đã hoàn chỉnh, còn dư thời gian chạy thử một lượt. Sự khác biệt không nằm ở kỹ năng — cùng những con người đó — mà nằm ở cách tổ chức file.
Ví dụ 2 — Một fintech ở Singapore và sức mạnh của design system
Một startup fintech tại Singapore làm sản phẩm ví điện tử cho SME chạy sprint thử tính năng "đối soát hóa đơn tự động". May mắn là họ đã có một design system khá đầy đủ trên Figma (thư viện tên "Pulse DS") với hơn 40 component. Sáng thứ Năm, Stitcher chỉ mất 15 phút import thư viện đó vào file sprint và hướng dẫn team cách dùng.
Ba contributor dựng ba đoạn luồng khác nhau. Vì tất cả đều kéo-thả từ Pulse DS — cùng nút, cùng card, cùng bảng dữ liệu — nên khi Stitcher ghép lại, ba đoạn trông như một sản phẩm hoàn chỉnh không hề có đường nối. Họ hoàn thành prototype gồm 22 màn hình chỉ trong khoảng 5 tiếng, dư thời gian để thêm một vài micro-interaction cho thật hơn.
Bài học: Design system không phải thứ xa xỉ — nó là đòn bẩy tốc độ cho ngày build. Đầu tư vào một thư viện component dùng lại được sẽ được hoàn vốn ngay trong sprint đầu tiên áp dụng nó.
Ví dụ 3 — Team nội bộ ngân hàng và cái bẫy "prototype đẹp quá mức"
Một team sản phẩm trong một ngân hàng ở Hà Nội chạy sprint cho tính năng mở tài khoản online. Vấn đề của họ ngược lại: hai designer trong team quá giỏi và quá cầu toàn. Họ dành cả buổi sáng thứ Năm để tinh chỉnh shadow, gradient, animation của màn hình đầu tiên đến mức hoàn hảo — trong khi 8 màn hình còn lại chưa động tới.
Đến trưa, Stitcher (là product manager) nhận ra nguy cơ và ra một quy tắc cứng: "Từ giờ, mỗi màn hình tối đa 25 phút, và chỉ dùng component có sẵn, cấm vẽ mới." Buổi chiều họ tăng tốc, hoàn thành đúng hạn. Prototype không lung linh bằng màn hình đầu, nhưng đủ thật để người dùng phản ứng — mà đó mới là mục tiêu.
Bài học: Ngày thứ Năm, "đủ tốt để test" quan trọng hơn "đẹp". Vai trò của Stitcher không chỉ là ghép file, mà còn là người canh giờ và ngăn cầu toàn. Prototype là công cụ học hỏi, không phải tác phẩm nghệ thuật.
Hướng dẫn từng bước
Dưới đây là quy trình một ngày build điển hình cho một team 4-5 người.
Bước 1 — Sáng sớm (9:00-9:30): Stitcher dựng khung file master. Chọn một người sở hữu file (thường là designer mạnh nhất hoặc người quen Figma nhất). Người này tạo file, đặt kích thước artboard chuẩn (ví dụ khung điện thoại 375×812 cho mobile), tạo các page nháp cho từng contributor, và một page "Master Flow" để ghép cuối.
Bước 2 — (9:30-10:00): Thiết lập design system hoặc mini kit. Import thư viện component có sẵn, hoặc nhanh chóng tạo một bộ component tối thiểu: font, bảng màu, nút, ô input, card. Publish để cả team dùng chung.
Bước 3 — (10:00-10:15): Chia storyboard thành các segment. Cả team cùng nhìn storyboard, đánh số các khung, và chia mỗi contributor một chuỗi màn hình liên tiếp. Ghi rõ ai làm khung nào lên chính storyboard.
Bước 4 — (10:15-13:00): Contributors dựng độc lập. Mỗi người làm trong page riêng, dùng component chung. Nguyên tắc vàng: dùng lại, đừng vẽ mới. Không cầu toàn, ưu tiên hoàn thành hết các màn hình trước, tinh chỉnh sau.
Bước 5 — Nghỉ trưa, và điểm danh giữa buổi. Sau trưa, mỗi contributor báo cáo nhanh: đã xong bao nhiêu màn hình, còn vướng gì. Stitcher điều chỉnh phân bổ nếu ai đó quá tải.
Bước 6 — (14:00-16:00): Stitcher bắt đầu khâu nối. Khi một contributor báo xong một đoạn, Stitcher copy các frame đó sang page "Master Flow", đặt tên frame nhất quán (ví dụ "01-Home", "02-Search", "03-Product"), và kiểm tra style có khớp không. Vừa ghép vừa vá lỗi lệch màu, lệch font.
Bước 7 — (16:00-16:45): Nối liên kết (prototyping links). Đây là bước biến các màn hình tĩnh thành thứ bấm được. Trong tab Prototype của Figma, kéo các nút/vùng bấm sang màn hình đích theo đúng luồng storyboard. Chú ý các "hotspot" mà người dùng sẽ bấm trong buổi test.
Bước 8 — (16:45-17:15): Chạy thử toàn bộ (dry run). Stitcher hoặc một người đóng vai người dùng bấm qua toàn bộ luồng ở chế độ Present. Tìm những chỗ "ngõ cụt" — bấm vào mà không đi đâu — và vá ngay. Kiểm tra trên đúng thiết bị sẽ dùng để test (điện thoại thật nếu là sản phẩm mobile).
Bước 9 — (17:15-17:30): Chốt và khóa. Xác nhận link chia sẻ hoạt động, prototype mở được trên thiết bị test. Khóa các layer chính để tránh chỉnh nhầm. Kết thúc ngày với một prototype hoàn chỉnh, sẵn sàng cho thứ Sáu.
Lỗi thường gặp & mẹo
Lỗi 1 — Tất cả cùng edit một artboard. Đây là lỗi phổ biến và tai hại nhất. Luôn tách page/frame riêng cho từng người, chỉ Stitcher chạm vào Master Flow.
Lỗi 2 — Không thống nhất style trước khi làm. Nếu mỗi người tự chọn font và màu, kết quả là một prototype "chắp vá". Mẹo: khóa cứng font, màu, spacing trong 30 phút đầu, thành component chung, rồi cấm chế thêm.
Lỗi 3 — Cầu toàn từng pixel. Người có gu thẩm mỹ cao dễ sa đà. Mẹo: đặt giới hạn thời gian mỗi màn hình (20-25 phút), và nhắc cả team rằng người dùng test sẽ không nhận ra shadow lệch 2 pixel.
Lỗi 4 — Để việc nối link đến phút chót. Nhiều team dựng xong hết màn hình mới bắt đầu nối, rồi phát hiện thiếu màn hình trung gian. Mẹo: Stitcher bắt đầu ghép và nối link ngay khi đoạn đầu tiên xong, không chờ tất cả.
Lỗi 5 — Không dry run trên thiết bị thật. Prototype chạy mượt trên laptop nhưng vỡ layout trên điện thoại là chuyện thường. Luôn thử trên đúng thiết bị của buổi test.
Lỗi 6 — Đặt tên frame lộn xộn. "Frame 47", "Untitled", "Copy of Copy" khiến việc nối link thành ác mộng. Mẹo: đặt tên theo số thứ tự và nội dung ("01-Home", "02-Cart") ngay từ khi ghép.
Mẹo bổ sung — Dùng component và variant cho trạng thái. Nếu một nút có trạng thái thường/nhấn/vô hiệu, hãy làm thành variant. Điều này giúp các màn hình đồng bộ và dễ tái sử dụng.
Mẹo bổ sung — Chuẩn bị sẵn dữ liệu giả thật. Đừng dùng "Lorem ipsum" hay "Nguyễn Văn A / 123 đồng". Dữ liệu càng giống thật (tên sản phẩm thật, giá thật, số dư thật) thì phản ứng của người dùng thứ Sáu càng đáng tin.
Bài tập thực hành
- Lập kế hoạch phân công. Lấy một storyboard 12-15 khung (có thể là từ sprint giả định của bạn). Đánh số các khung, rồi vẽ một bảng phân công cho 3 contributor và 1 Stitcher. Ghi rõ ai làm khung nào, ai sở hữu file master.
- Dựng mini design system. Mở Figma, trong 30 phút tạo một bộ component tối thiểu: 1 font, 3 màu, 1 nút (kèm 3 variant: thường/nhấn/vô hiệu), 1 ô input, 1 card. Publish thành thư viện.
- Dựng và nối 5 màn hình. Chọn 5 khung liên tiếp trong storyboard, dựng chúng bằng đúng component vừa tạo, đặt tên frame theo chuẩn "01-...", rồi vào tab Prototype nối các nút để bấm qua được cả 5 màn hình.
- Dry run và ghi lỗi. Bật chế độ Present, bấm qua toàn bộ luồng trên điện thoại. Ghi lại mọi "ngõ cụt" và lỗi layout. Đặt mục tiêu: sau khi vá, người khác có thể bấm qua toàn luồng mà không cần bạn giải thích.
Tóm tắt
Ngày thứ Năm là ngày biến storyboard tĩnh thành prototype bấm được, và thành bại của nó nằm ở khâu tổ chức chứ không chỉ ở kỹ năng Figma. Ba trụ cột cần nhớ:
- Một Stitcher duy nhất sở hữu file master và chịu trách nhiệm nhất quán tổng thể; các contributor làm trong page/frame riêng rồi mới merge vào Master Flow.
- Design system dùng chung (hoặc mini kit tạo nhanh đầu buổi) là đòn bẩy giúp nhiều người dựng nhiều màn hình mà kết quả vẫn như một người làm.
- "Đủ tốt để test" thắng "hoàn hảo" — canh giờ chặt, dùng lại component thay vì vẽ mới, nối link sớm, và luôn dry run trên thiết bị thật trước khi kết thúc ngày.