Prototype

Bấm được. Đó là chỗ prototype tách khỏi mọi bản vẽ đứng yên phía trước nó. Prototype là các màn thiết kế được nối với nhau theo luồng thật, người ta mở lên, bấm vào nút, màn nhảy sang màn tiếp theo — giống như đang dùng sản phẩm, dù bên dưới chẳng có database nào. Từ khi Figma cho phép nối màn bằng mấy cú kéo thả, việc làm prototype rẻ đi rất nhiều và không còn là đặc quyền của dự án lớn.

Mục đích của prototype là để người ta phát hiện ra họ ghét cái gì, từ lúc chưa ai viết dòng code nào.

Phân loại theo hai trục

Hai trục này ghép với nhau chứ không loại trừ nhau: một prototype hoàn toàn có thể vừa hi-fi vừa throwaway — dựng thật đẹp để test rồi vứt. BABOK v3 cũng tách đúng hai trục này ở kỹ thuật Prototyping, nên đừng hỏi "prototype của mình thuộc loại nào" mà hỏi "nó ở mức trung thực nào, và có định giữ lại không".

Loại evolutionary nghe hấp dẫn nhất và cũng nguy hiểm nhất: code nháp hay bị đẩy thẳng lên production rồi ở lại đó vài năm. Nếu chọn loại này thì phải thống nhất từ đầu về việc phần nào sẽ được viết lại.

Độ trung thực phải khớp với câu hỏi. Đưa bản xám cho khách xem để chốt luồng thì hợp lý, nhưng dùng chính bản xám đó để đo xem người dùng có tìm ra nút gửi hồ sơ không thì kết quả sai, vì màu sắc và độ tương phản ảnh hưởng trực tiếp tới thứ mắt người ta nhìn thấy trước.

Vì sao nó quan trọng

Đưa tài liệu 40 trang thì người ta gật cho xong. Đưa cái bấm được thì người ta chê, và chê rất cụ thể: "ơ, sao đến bước này lại bắt nhập lại mã khách hàng". Prototype sống bằng đúng chỗ đó.

Ngoài ra prototype còn là công cụ đàm phán. Khi hai bên trong nội bộ khách hàng cãi nhau về luồng duyệt, dựng hai prototype cho hai phương án rồi cho họ bấm thử thường kết thúc cuộc tranh cãi nhanh hơn ba buổi họp.

Ví dụ thực tế

Ví điện tử làm tính năng nạp tiền từ tài khoản ngân hàng liên kết. Thiết kế ban đầu: 5 bước, gồm một bước chọn nguồn tiền và một bước xác nhận có hiển thị lại phí.

Team dựng prototype trong Figma, đưa cho 6 người ngoài team bấm thử, mỗi người 10 phút. Bốn trong sáu người dừng lại ở bước xác nhận và hỏi cùng một câu: tiền về ngay hay phải chờ. Thông tin đó có trong màn hình, nhưng nằm ở dòng chữ xám nhỏ dưới cùng.

Sửa: đưa dòng "Tiền về ngay lập tức" lên cạnh số tiền, in đậm. Chi phí sửa ở giai đoạn prototype là hai tiếng của designer. Nếu để đến khi lên production mới phát hiện qua tỷ lệ bỏ giữa chừng, chi phí là một chu kỳ release, một lần thẩm định lại của bộ phận tuân thủ, và một đống giao dịch dở dang mà chăm sóc khách hàng phải gọi giải thích.

Lỗi hay gặp

• Khách xem prototype rồi tưởng sản phẩm sắp xong. Đây là cái bẫy kinh điển. Prototype càng đẹp thì hiểu lầm càng nặng, sếp bên khách hỏi luôn "tuần sau lên được chưa". Trước mỗi buổi demo, nói thẳng một câu: đây là bản vẽ bấm được, chưa có dữ liệu thật, chưa có xử lý phía sau.
• Prototype hóa toàn bộ hệ thống. Nối 60 màn cho một ERP nội bộ là lãng phí. Chỉ dựng những luồng có rủi ro cao hoặc đang gây tranh cãi.
• Không ghi lại kết quả. Bấm thử xong ai cũng gật gù rồi về, không ai ghi lại phát hiện nào. Buổi đó coi như mất.
• Dùng prototype thay đặc tả. Nó không chứa được quy tắc tính toán, ràng buộc dữ liệu, quyền hạn, hay xử lý lỗi phía server. Dev cần cả hai thứ.

Nếu team bạn chưa từng làm prototype, cứ bắt đầu bằng một luồng ngắn nhất mà khách hay phàn nàn nhất. Nối bốn màn trong Figma, gửi link, hẹn mười lăm phút. Buổi đầu tiên đó thường đủ để cả team hiểu vì sao nên làm tiếp.