Bỏ qua tới nội dung
Kiến thức Website· ·12 phút đọc

Prototype là gì và bấm thử được tới đâu trước khi web thật ra đời

Nguyen Hien
Prototype là gì và bấm thử được tới đâu trước khi web thật ra đời
Cỡ chữ

Khi đội thiết kế gửi đường link và bảo “bấm thử xem nhé”, thứ bạn đang cầm là prototype. Nhiều người xem xong rồi không chắc mình vừa duyệt cái gì, liệu nó đã gần với website thật chưa, hay còn phải chờ thêm bao lâu. Bài này giải thích rõ: prototype là gì, bấm thử được tới mức nào, và khi ngồi duyệt thì cần nhìn vào đâu.

Prototype là gì, và tại sao nó quan trọng hơn bản vẽ thông thường

Prototype (bản mẫu tương tác) là phiên bản mô phỏng của sản phẩm số, có thể bấm, cuộn và điều hướng giữa các màn hình được. Điểm khác biệt lớn so với wireframe (bản vẽ khung) hay mockup (bản thiết kế đầy màu) là prototype cho bạn cảm giác thật về cách giao diện hoạt động, không chỉ trông như thế nào.

Cách dễ nhớ nhất: wireframe cho bạn thấy “đặt gì ở đâu”, mockup cho bạn thấy “trông ra sao”, còn prototype cho bạn thấy “dùng thế nào”. Nếu bạn từng nhận một file Figma rồi bấm vào mũi tên nhỏ để chuyển trang, đó chính là prototype ở dạng đơn giản nhất.

So sánh wireframe, mockup và prototype: khác nhau về chi tiết, màu sắc và khả năng bấm

Prototype bấm được những gì, và chưa làm được những gì

Một prototype chất lượng cho phép bạn di chuyển giữa các trang, thấy menu mở ra như thế nào, form trông ra sao khi có lỗi, và animation chuyển trang xuất hiện lúc nào. Nó đủ sống động để bạn hình dung trải nghiệm thật của khách hàng khi vào website.

Mức độ chi tiết của tương tác trong prototype phụ thuộc vào công cụ và mục tiêu của vòng duyệt đó. Prototype đơn giản (low-fidelity interactive prototype) chỉ kết nối các trang với nhau, bấm đây thì qua đó.

Prototype nâng cao hơn (high-fidelity prototype) có thể giả lập cả animation (hiệu ứng chuyển động), micro-interaction (phản hồi nhỏ khi thao tác) như nút đổi màu khi rê chuột qua, hay dropdown (danh sách xổ xuống) mở ra đúng như website thật. Biết prototype đang ở mức nào giúp bạn đặt đúng kỳ vọng khi duyệt.

Tuy nhiên, prototype không có dữ liệu thật. Khi bạn bấm “Gửi” ở form liên hệ, không có email nào được gửi đi. Giỏ hàng không thật, số sản phẩm hiển thị là mẫu, và mọi nút đặt lịch chỉ dẫn tới trang xác nhận giả. Biết điều này giúp bạn không bị bối rối khi thấy “đặt lịch thành công” trong prototype mà thực ra không có gì được ghi lại phía sau.

Vị trí prototype trong quy trình làm website: từ nghiên cứu đến wireframe, prototype, code và ra mắt

Ai làm prototype và bằng công cụ gì

Hiện nay Figma là công cụ phổ biến nhất để làm prototype cho web. Thiết kế và tương tác nằm trong cùng một file, đội thiết kế gửi bạn một link, bạn mở trình duyệt rồi bấm thử được ngay mà không cần cài thêm gì. Tính năng này trong Figma gọi là “Prototype mode” và cho phép kéo thả kết nối giữa các frame (khung màn hình).

Framer cho phép làm prototype gần với web thật hơn, có animation phức tạp và phản hồi mượt mà, thường được dùng cho các dự án cần kiểm tra kỹ trải nghiệm trước khi code. Web22 cũng hay dùng bản giao diện chạy thật tự code để khách duyệt, thay vì chỉ xem file Figma tĩnh, vì cách đó cho cảm giác rất gần với website thành phẩm.

Ba công cụ làm prototype phổ biến: Figma, ProtoPie và InVision

Khi ngồi duyệt prototype, bạn cần kiểm tra cái gì

Bước đầu tiên là đi qua đúng luồng khách hàng thật: từ trang chủ vào sản phẩm, rồi thêm vào giỏ, rồi ra trang thanh toán. Đừng chỉ nhìn từng màn hình rời, vì thiết kế xét tổng thể và thiết kế từng phần trông khác nhau nhiều.

Kiểm tra CTA (call to action, nút kêu gọi hành động) đặt ở đâu: chúng có nổi bật không, có bị các phần tử khác lấn không, và chữ trên nút có nói rõ người dùng nhận được gì không. Phần này dễ bị bỏ qua khi duyệt nhưng lại ảnh hưởng nhiều tới tỉ lệ bấm của website sau này.

Xem trên điện thoại nếu có thể. Nhiều prototype Figma cho phép preview trên mobile, và bố cục điện thoại thường khác nhiều so với desktop. Để biết toàn cảnh wireframe và mockup nằm ở đâu trong quy trình, xem bài wireframe, mockup và prototype khác nhau ra sao.

Ví dụ prototype flow đặt lịch phòng khám: từ trang chủ, chọn ngày, điền thông tin đến xác nhận

Đừng bỏ qua phần phản hồi “cảm giác sử dụng”. Đây là điều bạn cảm nhận được rõ nhất khi bấm thử mà đội thiết kế khó tự đánh giá vì họ đã nhìn vào file đó quá lâu. Nếu thấy mình do dự ở một bước nào đó, bấm nhầm nút, hay không biết trang tiếp theo là trang gì, ghi lại ngay đó là điểm cần điều chỉnh.

Điện thoại là thiết bị nhiều khách hàng dùng nhất để vào web. Nếu prototype cho phép preview (xem trước) trên màn hình nhỏ, hãy dùng ít nhất 5 phút để bấm thử trên điện thoại. Khoảng cách giữa các nút, kích thước chữ, và vị trí CTA trên màn hình nhỏ thường khác đáng kể so với desktop (màn hình máy tính), và vấn đề hiện ra rõ hơn nhiều khi bạn tự trải nghiệm thay vì chỉ xem trên máy tính.

Chủ doanh nghiệp cần quan tâm tới prototype không

Câu trả lời ngắn là có, và lý do thực tế: sửa trong prototype không phát sinh chi phí lập trình. Khi bạn phát hiện nút liên hệ bị khuất ở trang dịch vụ, hoặc ảnh banner quá to ép nội dung xuống quá sâu, sửa ở giai đoạn này là vài phút. Chờ sau khi code xong rồi mới nói, phí thay đổi có thể phát sinh tùy phạm vi sửa.

Bạn không cần rành kỹ thuật hay thiết kế để duyệt prototype. Cứ ngồi dùng như một khách hàng thật: bấm xem trang liên hệ mở ra có đủ thông tin không, nút đặt lịch có dễ tìm không, và trang giới thiệu đọc xong có hiểu họ làm gì không. Những phản hồi kiểu đó mới là thứ đội thiết kế cần từ bạn, không phải nhận xét về màu sắc hay font chữ ở giai đoạn này.

Một vòng duyệt prototype hay nhiều vòng, và khi nào thì chốt được

Không có con số cố định, nhưng hai đến ba vòng duyệt là phổ biến với đa số dự án vừa và nhỏ. Vòng đầu sau khi prototype hình thành: kiểm tra tổng thể, phát hiện vấn đề lớn về cấu trúc và luồng. Vòng hai sau khi đội thiết kế chỉnh: kiểm tra lại những điểm đã góp ý, xem đã đúng ý chưa. Vòng ba nếu cần: tinh chỉnh chi tiết nhỏ.

Dấu hiệu để chốt và chuyển sang code là khi bạn bấm thử qua toàn bộ luồng chính mà không còn điểm nào gây bối rối hay muốn thay đổi nữa. Không cần hoàn hảo tuyệt đối, vì một số chi tiết sẽ rõ hơn sau khi code thật. Mục tiêu là loại bỏ hết những vấn đề về cấu trúc và điều hướng trước khi lập trình, vì đó là phần tốn công sửa nhất.

Nếu sau ba vòng vẫn còn thay đổi lớn, thường có một trong hai nguyên nhân: yêu cầu ban đầu chưa đủ rõ, hoặc có thêm nhu cầu mới phát sinh trong quá trình duyệt. Cả hai trường hợp đều nên trao đổi thẳng với đội thiết kế thay vì cứ chỉnh mãi một prototype.

Câu hỏi thường gặp về prototype

Prototype và demo có giống nhau không?

Không hoàn toàn. Prototype là bản mô phỏng giao diện trước khi code thật, dùng để duyệt thiết kế và phát hiện vấn đề sớm. Demo thường là phiên bản đã code xong hoặc gần xong, dùng để trình bày cho khách hàng hay nhà đầu tư. Prototype để phòng ngừa, demo để trình bày.

Link Figma gửi cho tôi bấm thử, đó có phải prototype không?

Đúng. Khi Figma ở chế độ “Present” và cho phép bạn bấm nút để chuyển trang, đó là prototype. Nếu bạn chỉ xem ảnh tĩnh không bấm được, đó là mockup. Cách phân biệt nhanh: bấm thử một nút bất kỳ, nếu có gì đó xảy ra thì là prototype.

Tôi duyệt prototype xong rồi có đổi thêm được không?

Được, đó chính là mục đích của bước này. Sau khi bạn phản hồi, đội thiết kế chỉnh lại rồi gửi link mới để bấm thử tiếp. Khi cả hai bên đồng thuận thì mới chuyển sang code. Cứ ghi lại thứ bạn muốn thay rồi phản hồi cụ thể.

Prototype khác gì so với staging site (máy chủ kiểm thử)?

Prototype là file thiết kế có tương tác, chạy trong công cụ như Figma, chưa có code thật. Staging site là phiên bản đã code xong và chạy trên server thật nhưng chưa đưa ra public (công khai). Prototype dùng để kiểm tra thiết kế và luồng trước khi code. Staging site dùng để kiểm tra code trước khi đưa lên server chính. Hai bước khác nhau trong quy trình, không thay thế được cho nhau.

Đọc tiếp

Bài viết
cùng chủ đề.

Tất cả bài viết