Bài 10 — Prototyping — Static vs Interactive

Mở đầu — vì sao bài này quan trọng

Hãy tưởng tượng bạn vừa hoàn thành một màn hình thanh toán cho ứng dụng đặt đồ ăn. Trên Figma, nó đẹp lung linh: nút bấm bo góc mềm mại, màu sắc hài hòa, font chữ chuẩn chỉnh. Bạn tự tin gửi cho stakeholder duyệt. Họ nhìn vào ảnh tĩnh, gật gù "đẹp đấy", rồi ký duyệt. Hai tuần sau, đội kỹ thuật build xong, người dùng thật bấm vào thử — và mọi người mới ngã ngửa ra: sau khi nhập mã giảm giá sai, không có thông báo lỗi nào hiện ra; người dùng bấm liên tục mà chẳng biết chuyện gì đang xảy ra.

Vấn đề ở đây không nằm ở thẩm mỹ. Vấn đề nằm ở chỗ một bản thiết kế tĩnh không thể trả lời câu hỏi quan trọng nhất: "Khi người dùng chạm vào đây thì điều gì xảy ra?" Đó chính là lý do prototype (bản mẫu) tồn tại. Prototype biến thiết kế từ một bức tranh thành một trải nghiệm có thể bấm, vuốt, chạm và cảm nhận trước khi viết một dòng code nào.

Trong bài này, chúng ta sẽ đi sâu vào các cấp độ prototype — từ bản giấy thô sơ nhất đến bản tương tác tinh vi — và quan trọng hơn cả: khi nào thì dùng cấp độ nào. Đây là kỹ năng phân biệt giữa một designer làm việc nhanh, thông minh và một designer tốn hàng giờ tô vẽ những thứ chưa cần thiết.

Khái niệm cốt lõi

Prototype là một phiên bản giả lập của sản phẩm dùng để kiểm tra ý tưởng, kiểm chứng luồng trải nghiệm và thu thập phản hồi — trước khi tốn công sức và tiền bạc để xây dựng thật. Điểm mấu chốt cần nhớ: prototype không phải là sản phẩm. Nó là công cụ giao tiếp và học hỏi. Một prototype tốt là prototype trả lời được câu hỏi bạn đang đặt ra với chi phí thấp nhất.

Có một phổ liên tục về độ "trung thực" (fidelity) và độ tương tác. Hãy hình dung nó như một chiếc thang ba bậc.

Cấp 1 — Paper prototype (bản mẫu giấy)

Đây là cấp độ thô sơ nhất nhưng cũng dễ bị xem thường nhất. Bạn in hoặc vẽ tay các màn hình lên giấy, rồi tự tay "di chuyển" giấy để mô phỏng việc chuyển màn hình khi người dùng "bấm". Người test chỉ tay vào một nút, bạn — đóng vai "máy tính" — rút tờ giấy hiện tại ra và đặt tờ giấy màn hình tiếp theo vào.

Nghe có vẻ ngây ngô, nhưng paper prototype có ba sức mạnh thực sự. Thứ nhất, tốc độ: bạn tạo ra 10 màn hình trong 15 phút. Thứ hai, chi phí tâm lý thấp: khi bản mẫu trông "nháp", người test sẵn sàng chê thẳng thừng, còn khi bản mẫu trông đẹp như thật, họ ngại góp ý vì sợ "phá hỏng công sức của bạn". Thứ ba, nó buộc bạn tập trung vào luồng và cấu trúc chứ không sa đà vào màu sắc, font chữ.

Paper prototype phù hợp ở giai đoạn cực sớm, khi bạn còn đang phân vân giữa nhiều hướng đi và muốn loại bỏ nhanh những hướng tệ.

Cấp 2 — Click-through static (bản tĩnh nối link)

Đây là cấp độ phổ biến nhất trong công việc hàng ngày. Bạn vẽ các frame (khung màn hình) trên Figma, rồi nối chúng lại với nhau bằng các liên kết: bấm vào nút "Đăng nhập" ở màn hình A thì nhảy sang màn hình B. Không có hiệu ứng phức tạp, không có animation tinh vi — chỉ là chuyển cảnh đơn giản từ màn hình này sang màn hình khác.

Bản chất của click-through là mô phỏng đường đi (navigation path) của người dùng. Nó trả lời câu hỏi: "Để hoàn thành nhiệm vụ X, người dùng phải bấm qua những màn hình nào, theo thứ tự nào?" Đây là cấp độ tuyệt vời để test usability cơ bản, để trình bày với team, và để kiểm tra xem luồng có bị thiếu bước hay rối rắm không.

Điểm cần lưu ý: click-through cố tình bỏ qua các trạng thái động. Nút bấm không đổi màu khi hover, danh sách không cuộn mượt, không có loading spinner. Đó là sự đánh đổi có chủ đích để đổi lấy tốc độ.

Cấp 3 — Interactive prototype (bản mẫu tương tác)

Đây là cấp độ cao nhất, nơi prototype bắt đầu "sống". Bạn thêm vào các vi tương tác (microinteraction): nút đổi màu khi nhấn, ô nhập liệu hiện trạng thái lỗi khi sai, menu trượt ra mượt mà, hiệu ứng chuyển động có thời lượng và độ trễ thật. Trong Figma, các tính năng như Smart Animate, các trigger "while pressing", "after delay", hay các component có nhiều variant (biến thể) cho phép bạn tạo ra cảm giác gần như sản phẩm thật.

Interactive prototype trả lời những câu hỏi mà hai cấp dưới không thể: "Hiệu ứng chuyển động này có quá nhanh/quá chậm không?", "Người dùng có hiểu rằng họ vừa kéo thanh trượt thành công không?", "Trạng thái lỗi này có rõ ràng không?" Đây là cấp độ bạn dùng khi đã chốt luồng và cần đánh bóng trải nghiệm, hoặc khi cần thuyết phục nhà đầu tư bằng một demo trông như app thật.

Cái giá phải trả là thời gian. Một interactive prototype công phu có thể ngốn gấp 5–10 lần thời gian so với một click-through cho cùng số màn hình. Vì vậy, nguyên tắc vàng là: chỉ nâng fidelity khi câu hỏi bạn cần trả lời đòi hỏi nó.

Bảng so sánh nhanh để ghi nhớ

Tình huống thực tế

Ví dụ 1 — Startup giao đồ ăn ở TP.HCM tiết kiệm 3 tuần nhờ paper prototype

Một startup giao đồ ăn tại TP.HCM (tạm gọi là "FoodGo") đang muốn thêm tính năng "đặt nhóm" — cho phép nhiều người trong một văn phòng cùng gom đơn để được miễn phí ship. Đội thiết kế ban đầu định lao vào Figma làm bản interactive ngay. May mắn là designer lead đề xuất làm paper prototype trước.

Họ vẽ tay 8 màn hình trong một buổi sáng, rồi mời 5 nhân viên từ một công ty đối tác xuống test ngay tại quán cà phê. Chỉ sau 3 lượt test, một vấn đề lớn lộ ra: người dùng không hiểu ai là "chủ đơn" và ai là "người tham gia". Hai người cùng bấm "Tạo nhóm" và tạo ra hai nhóm trùng nhau. Đây là lỗi về mô hình tư duy, không phải lỗi giao diện.

Bài học rút ra: nếu đội đã đổ công làm interactive prototype trước, họ sẽ mất khoảng 3 tuần để rồi phát hiện ra cùng một lỗi đó — và còn ngại sửa hơn vì "đã làm đẹp rồi". Paper prototype giúp họ phát hiện lỗi nền tảng với chi phí gần như bằng không, và họ kịp thiết kế lại vai trò "chủ đơn" rõ ràng trước khi vẽ một pixel nào trên Figma.

Ví dụ 2 — Ngân hàng số dùng click-through để chốt luồng mở tài khoản eKYC

Một ngân hàng số tại Việt Nam cần thiết kế luồng mở tài khoản trực tuyến bằng eKYC (xác thực danh tính điện tử qua chụp CCCD và khuôn mặt). Luồng này dài: 11 màn hình, rẽ nhánh tùy theo việc người dùng chụp CCCD thành công hay thất bại.

Đội thiết kế làm một click-through static trên Figma: vẽ đủ 11 màn hình ở mức mid-fidelity, nối link cho cả nhánh thành công lẫn nhánh thất bại. Họ không thêm bất kỳ animation nào. Rồi họ mang đi test với 8 người dùng và trình bày trước bộ phận tuân thủ (compliance).

Kết quả: bộ phận tuân thủ phát hiện thiếu một màn hình thông báo về điều khoản bảo mật dữ liệu — bắt buộc theo quy định. Đồng thời, qua test, họ thấy 6/8 người dùng bị kẹt ở bước chụp CCCD vì không biết cần đặt giấy tờ thẳng. Cả hai vấn đề được sửa bằng cách thêm một màn hình hướng dẫn và một màn hình điều khoản — tất cả chỉ trong vòng một ngày chỉnh sửa click-through.

Bài học: với một luồng nghiệp vụ phức tạp có yếu tố pháp lý, click-through static là cấp độ vừa đủ. Nó đủ chi tiết để bộ phận tuân thủ soi từng màn hình, nhưng đủ nhẹ để sửa nhanh khi phát hiện thiếu sót. Bỏ thời gian làm animation lúc này là hoàn toàn lãng phí.

Ví dụ 3 — App học tiếng Anh dùng interactive prototype để gọi vốn

Một startup edtech làm app học tiếng Anh cho trẻ em chuẩn bị gọi vốn vòng hạt giống. Tính năng "ngôi sao" của họ là một bài luyện phát âm: trẻ nói vào micro, một con vật hoạt hình phản ứng theo độ chính xác — nhảy múa nếu đúng, lắc đầu đáng yêu nếu sai.

Ở đây, một click-through tĩnh sẽ "giết chết" sản phẩm khi demo, vì toàn bộ giá trị nằm ở cảm giác chuyển động và phản hồi tức thì. Đội thiết kế đầu tư làm một interactive prototype công phu trong Figma: dùng Smart Animate cho nhân vật, thêm độ trễ mô phỏng thời gian xử lý giọng nói, có cả trạng thái "đang nghe", "đúng rồi!", "thử lại nhé". Họ chỉ làm kỹ đúng 3 màn hình cốt lõi này, các phần còn lại của app vẫn để ở mức click-through.

Khi demo cho nhà đầu tư, chính 3 màn hình tương tác đó tạo ra khoảnh khắc "wow" và giúp họ chốt vòng vốn. Bài học: interactive prototype xứng đáng với công sức khi và chỉ khi trải nghiệm động chính là phần cần được kiểm chứng hoặc trình bày. Đừng làm interactive cho cả app — hãy làm interactive cho đúng phần "ăn tiền".

Hướng dẫn từng bước

Đây là quy trình giúp bạn chọn đúng cấp độ và thực thi gọn gàng.

Bước 1 — Viết ra câu hỏi bạn cần trả lời. Trước khi mở Figma, hãy viết một câu: "Prototype này giúp tôi học được điều gì?" Ví dụ: "Người dùng có hiểu cách thêm sản phẩm vào giỏ không?" hay "Hiệu ứng chuyển trang này có gây khó chịu không?". Câu hỏi quyết định cấp độ.

Bước 2 — Chọn cấp độ thấp nhất đủ để trả lời câu hỏi. Nếu câu hỏi về luồng và cấu trúc → paper hoặc click-through. Nếu câu hỏi về navigation và usability cơ bản → click-through. Nếu câu hỏi về cảm giác, animation, trạng thái động → interactive. Luôn ưu tiên cấp thấp nhất có thể.

Bước 3 — Xác định "đường đi vàng" (happy path) trước. Vẽ luồng chính mà đa số người dùng sẽ đi, từ điểm bắt đầu đến khi hoàn thành nhiệm vụ. Đừng vội vẽ mọi nhánh ngoại lệ.

Bước 4 — Dựng các frame và đặt tên rõ ràng. Trong Figma, mỗi màn hình là một frame. Đặt tên có hệ thống như "01-Trang chủ", "02-Chi tiết SP" để dễ quản lý khi luồng dài ra.

Bước 5 — Nối các liên kết (với click-through). Vào tab Prototype, kéo các kết nối từ nút bấm sang frame đích. Bắt đầu với chuyển cảnh "Instant" (tức thì) để kiểm tra luồng đã thông chưa.

Bước 6 — Nâng fidelity có chọn lọc (nếu cần interactive). Chỉ khi đã chốt luồng, hãy thêm Smart Animate, các variant cho trạng thái hover/pressed/error, và tinh chỉnh thời lượng animation cho những màn hình thực sự cần.

Bước 7 — Test với người thật. Đưa cho 5 người dùng đại diện, giao một nhiệm vụ cụ thể, và quan sát trong im lặng. Đừng giải thích, đừng "cứu" họ. Chỗ nào họ vấp chính là chỗ thiết kế có vấn đề.

Bước 8 — Ghi nhận, sửa, lặp lại. Sửa những lỗi nghiêm trọng nhất trước, rồi test lại. Prototype là vòng lặp, không phải đích đến.

Lỗi thường gặp & mẹo

Lỗi 1 — Đánh bóng quá sớm. Đây là cái bẫy phổ biến nhất. Designer mới thường sa vào tinh chỉnh màu sắc, bo góc, animation khi luồng còn chưa chốt. Mẹo: hãy tự hỏi "Mình đang trả lời câu hỏi nào?" — nếu câu trả lời là "chưa rõ", bạn đang đánh bóng quá sớm.

Lỗi 2 — Prototype "tê liệt" khi test. Bạn đưa bản click-through cho người dùng, họ bấm vào một nút chưa được nối link, và màn hình đứng im. Họ bối rối, mất mạch. Mẹo: với những nút ngoài luồng test, hãy thêm một overlay nhỏ ghi "Tính năng này chưa có trong bản mẫu" hoặc ít nhất là một hiệu ứng nhấp nháy để người dùng biết họ đã bấm trúng.

Lỗi 3 — Nhầm prototype với spec bàn giao. Prototype dùng để học và thuyết phục, không phải tài liệu kỹ thuật đầy đủ cho lập trình viên. Đừng kỳ vọng mọi trạng thái phải hoàn hảo trong prototype.

Lỗi 4 — Làm interactive cho toàn bộ app. Như ví dụ app edtech đã chỉ ra, hãy làm interactive cho đúng 3–5 màn hình "ăn tiền", còn lại để click-through. Đừng phung phí cả tuần để animate những màn hình mà chẳng ai quan tâm tới chuyển động.

Mẹo vàng: Hãy bắt đầu mỗi dự án bằng câu hỏi "Cấp độ thấp nhất nào trả lời được câu hỏi của tôi?" Một designer giỏi không phải người làm prototype đẹp nhất, mà là người làm prototype vừa đủ để học được điều cần học, nhanh nhất có thể.

Bài tập thực hành

Bài tập 1 — Thang ba bậc. Chọn một luồng quen thuộc (ví dụ: đặt vé xem phim trên một app bất kỳ). Tạo cùng luồng đó ở cả ba cấp độ: vẽ tay paper prototype (5 phút), dựng click-through trên Figma (45 phút), và nâng một màn hình lên interactive với ít nhất một Smart Animate (30 phút). Viết lại: ở mỗi cấp độ, bạn học được điều gì mà cấp dưới không cho biết?

Bài tập 2 — Chọn cấp độ. Cho 3 tình huống sau, hãy quyết định cấp độ phù hợp và giải thích lý do trong 2–3 câu: (a) Bạn phân vân giữa hai cách sắp xếp menu chính. (b) Bạn cần thuyết phục CEO về cảm giác mượt mà của một tính năng vuốt thẻ. (c) Bạn cần kiểm tra xem luồng thanh toán 6 bước có bị rối không.

Bài tập 3 — Test 5 người. Lấy bản click-through từ Bài tập 1, mời 5 người thật thực hiện một nhiệm vụ cụ thể. Quan sát im lặng, ghi lại mọi điểm họ vấp. Sửa lỗi nghiêm trọng nhất rồi test lại với 2 người mới. So sánh trước và sau.

Tóm tắt

Prototype tồn tại để trả lời một câu hỏi mà bản thiết kế tĩnh không bao giờ trả lời được: "Khi người dùng tương tác, điều gì xảy ra?" Có ba cấp độ chính trên một phổ liên tục: paper prototype thô sơ và siêu nhanh, lý tưởng cho việc kiểm tra ý tưởng và luồng ở giai đoạn cực sớm; click-through static nối các frame Figma lại với nhau, hoàn hảo để kiểm tra navigation và cấu trúc luồng; và interactive prototype với animation cùng các trạng thái động, dành cho việc đánh bóng trải nghiệm và demo thuyết phục.

Nguyên tắc cốt lõi xuyên suốt bài này: luôn chọn cấp độ thấp nhất đủ để trả lời câu hỏi bạn đang đặt ra. Đừng đánh bóng quá sớm, đừng làm interactive cho cả app, và luôn bắt đầu từ câu hỏi "Mình cần học điều gì?". Như ba ví dụ đã cho thấy — startup giao đồ ăn tiết kiệm 3 tuần nhờ paper, ngân hàng số chốt luồng eKYC nhờ click-through, app edtech gọi vốn thành công nhờ interactive — mỗi cấp độ đều có chỗ đứng riêng. Kỹ năng thực sự của một product designer không phải là làm prototype đẹp nhất, mà là chọn đúng công cụ cho đúng câu hỏi, vào đúng thời điểm.