Từ giải pháp trên giấy đến một MVP mà người dùng có thể thử

Từ giải pháp trên giấy đến một MVP mà người dùng có thể thử

Một ý tưởng có thể nghe rất thuyết phục trong buổi thuyết trình. Nhóm đã tìm hiểu thị trường, nói chuyện với khách hàng, so sánh những cách giải quyết hiện có và chọn ra hướng đi của mình. Trên slide, các phần nối với nhau khá hợp lý. Nhưng khi một người chưa từng nghe nhóm trình bày cầm sản phẩm lên sử dụng, chuyện gì sẽ xảy ra?

Họ có hiểu sản phẩm giúp mình làm gì không? Họ có hoàn thành được việc mình muốn làm không? Và nếu làm được, trải nghiệm ấy có đủ giá trị để họ muốn quay lại?

Đó là những câu hỏi của giai đoạn làm sản phẩm thử nghiệm. Trong nhiều dự án sinh viên, nhóm gọi phần lựa chọn giải pháp là CP2, còn giai đoạn làm và kiểm tra phiên bản đầu là CP3. Dù dùng tên gọi nào, bước chuyển quan trọng vẫn là đưa một giả thuyết ra khỏi bản thuyết trình để quan sát người thật sử dụng.

Bắt đầu từ vấn đề cụ thể, không bắt đầu từ danh sách tính năng

Giả sử một nhóm muốn làm công cụ đặt chỗ học nhóm. Sau khi tìm hiểu, họ nhận ra sinh viên thường mất thời gian tìm nơi còn trống vào giờ cao điểm. Một số bạn phải đi qua nhiều phòng hoặc nhắn hỏi từng nơi. Nhóm đề xuất hiển thị chỗ trống theo khung giờ và cho phép đặt trước.

Đến đây, nhóm có một hướng giải quyết hợp lý, nhưng chưa biết nó có hoạt động trong thực tế hay không. Liệu người dùng có tìm được chỗ phù hợp? Họ có tin thông tin còn trống? Người quản lý có đủ thời gian cập nhật trạng thái phòng? Chỉ cần một mắt xích không chạy, hành trình đặt chỗ có thể thất bại.

Vì vậy, trước khi vẽ giao diện, hãy viết ngắn gọn ba điều:

Điều đã biết hoặc đang giả địnhPhiên bản đầu cần cho phép làm gì?Quan sát gì khi người dùng thử?Sinh viên khó biết chỗ nào còn trốngXem chỗ và khung giờ có thể sử dụngHọ có tự tìm được lựa chọn phù hợp không?Việc hỏi và đi tìm chỗ tốn thời gianĐặt chỗ và nhận xác nhậnHọ có hoàn tất lượt đặt chỗ không? Bị kẹt ở bước nào?Tình trạng chỗ có thể thay đổi nhanhNgười quản lý cập nhật trạng tháiThông tin có đủ kịp thời để người đặt tin tưởng không?

Bảng này giúp nhóm thấy mỗi phần của sản phẩm phục vụ vấn đề nào và cần được kiểm tra ra sao. Ví dụ đặt chỗ chỉ mang tính minh họa; dự án của bạn cần bắt đầu từ dữ liệu và tình huống của chính khách hàng mình.

MVP là phiên bản nhỏ nhất giúp nhóm học được điều quan trọng

MVP là viết tắt của Minimum Viable Product, thường được hiểu là sản phẩm khả dụng tối thiểu. “Tối thiểu” không có nghĩa là làm qua loa. Phiên bản đầu có thể đơn giản, nhưng người dùng vẫn phải thực hiện được việc cốt lõi và nhóm phải thu được thông tin đáng tin từ lần thử đó. Cách tiếp cận này đặt trọng tâm vào việc kiểm tra giả định quan trọng trước khi đầu tư xây quá nhiều phần.

Với công cụ đặt chỗ, một hành trình đủ rõ có thể là: xem khung giờ còn trống → chọn chỗ → nhận xác nhận → đến sử dụng. Để thử hành trình ấy, nhóm có thể chỉ triển khai tại một địa điểm, với vài khung giờ và một loại phòng. Hệ thống gợi ý thông minh, tích điểm hay bảng tin cộng đồng có thể để sau.

Lý do rất thực tế: nếu người dùng không đặt được chỗ, thêm nhiều màn hình sẽ không giúp nhóm hiểu nguyên nhân. Phạm vi nhỏ giúp nhóm dành thời gian cho phần quyết định giá trị của giải pháp và phát hiện lỗi sớm.

Phiên bản thử cũng không bắt buộc phải là một ứng dụng hoàn chỉnh. Tùy bài toán, nó có thể là trang web đơn giản, mẫu tương tác, biểu mẫu kết hợp xử lý thủ công hoặc một dịch vụ được nhóm trực tiếp vận hành. Hình thức nào phù hợp phụ thuộc vào điều nhóm cần kiểm tra. Nếu muốn biết người dùng có hiểu cách đặt chỗ, một mẫu tương tác có thể đủ cho vòng đầu. Nếu muốn biết thông tin phòng trống có thể duy trì chính xác mỗi ngày, nhóm còn phải thử quy trình cập nhật ở phía vận hành.

Đừng để bản demo chỉ chạy khi có người thuyết trình bên cạnh

Trong phòng họp, người làm sản phẩm biết chính xác nút nào phải bấm. Người dùng mới thì không. Họ nhìn vào màn hình, đọc những gì mình thấy và tự đoán bước tiếp theo. Chính khoảng cách ấy là nơi nhiều vấn đề lộ ra.

Hãy tự hỏi: người dùng có nhận ra điểm bắt đầu không? Sau khi bấm đặt chỗ, họ có biết mình đã đặt thành công chưa? Nếu không còn phòng, hệ thống nói gì? Nếu thông tin sai hoặc có trục trặc, họ tìm hỗ trợ ở đâu?

Một trải nghiệm “dùng được” còn liên quan đến tốc độ, độ chính xác và cách giải pháp được cung cấp. Giao diện đặt chỗ đẹp cũng không có ích nếu hệ thống thường báo phòng trống sai. Ngược lại, quy trình cập nhật phòng chính xác nhưng bắt người dùng đi qua quá nhiều bước cũng có thể khiến họ bỏ cuộc.

Nhóm không cần giải quyết hoàn hảo mọi tình huống ngay từ đầu. Nhưng nên chỉ rõ điều gì đã hoạt động, điều gì còn do nhóm hỗ trợ thủ công và giới hạn nào có thể ảnh hưởng đến kết quả thử.

Cho người dùng một nhiệm vụ, rồi quan sát

Khi đã có bản thử, hãy mời những người gần với nhóm khách hàng mục tiêu sử dụng nó. Thay vì hỏi “Bạn có thích ý tưởng này không?”, hãy đặt một tình huống cụ thể: “Chiều mai bạn cần chỗ học nhóm cho bốn người. Hãy thử tìm và đặt một chỗ phù hợp.”

Nói rõ mục tiêu, sau đó để họ tự thao tác. Đừng vội chỉ nút bấm khi họ dừng lại. Nếu ai cũng cần nhóm hướng dẫn mới hoàn thành, đó là một phát hiện quan trọng. Hướng dẫn về kiểm thử khả dụng của Nielsen Norman Group cũng khuyến nghị dùng nhiệm vụ thực tế và quan sát hành vi của người thử, đồng thời tránh chỉ dẫn quá chi tiết khiến kết quả bị dẫn dắt.

Trong lúc quan sát, ghi lại những điều cụ thể:

• Người thử có bắt đầu đúng chỗ không?

• Họ có hoàn thành nhiệm vụ không, và mất khoảng bao lâu?

• Họ dừng ở bước nào, bấm nhầm ở đâu, hỏi câu gì?

• Kết quả họ nhận được có đúng với kỳ vọng không?

• Khi hỏi sau buổi thử, họ giải thích khó khăn ấy như thế nào?

Nên tách điều quan sát được khỏi cách nhóm diễn giải. “Người thử bấm ba lần vào tên phòng nhưng không mở được chi tiết” là quan sát. “Họ không thích giao diện” là một suy đoán cần hỏi hoặc kiểm tra thêm. Nếu được người tham gia đồng ý, nhóm có thể lưu ghi chú hoặc bản ghi buổi thử; khi chia sẻ công khai, cần loại thông tin cá nhân và chỉ dùng dữ liệu được phép công bố.

Lời khen cũng nên được đặt cạnh hành vi. Một bạn có thể nói giao diện đẹp nhưng không hoàn tất lượt đặt. Một bạn khác ít nhận xét hơn nhưng dùng trơn tru và muốn quay lại lúc cần. Cả hai đều cho nhóm thông tin, song thông tin ấy không giống nhau. Tương tự, “tôi có thể trả tiền” là một câu trả lời về ý định, chưa phải giao dịch thực tế.

Kết quả thử phải dẫn đến một quyết định

Trước khi mời người dùng, nhóm nên viết ra điều mình đang kiểm tra. Ví dụ: “Một sinh viên mới có thể tự tìm và đặt chỗ học nhóm mà không cần người hướng dẫn.” Sau vài buổi thử, đối chiếu giả định đó với những gì đã xảy ra.

Nếu người thử thường không hiểu khung giờ, nhóm có thể sửa cách hiển thị rồi thử lại. Nếu họ đặt rất dễ nhưng đến nơi mới biết phòng đã có người, vấn đề nằm ở dữ liệu và quy trình vận hành. Nếu họ không muốn đặt trước dù đã hiểu cách dùng, nhóm cần quay lại xem mình có chọn đúng nhu cầu hay chưa.

Một lần thử tốt không nhất thiết phải nhận toàn lời khen. Nó giúp nhóm chọn bước tiếp theo có căn cứ. Có lúc nên chỉnh sửa một phần sản phẩm; có lúc nên giữ hướng hiện tại và thử với nhiều tình huống hơn; cũng có lúc phải xem lại chính giải pháp đã chọn. Đừng chỉ kết luận “người dùng thấy ổn”. Hãy nói rõ nhóm dự đoán điều gì, quan sát thấy điều gì và vì sao quyết định thay đổi hoặc tiếp tục.

Kể câu chuyện sản phẩm bằng bằng chứng của chính nhóm

Khi giới thiệu dự án, hãy bắt đầu từ một tình huống thật mà khách hàng gặp phải. Tiếp theo, cho người xem thấy phiên bản hiện tại xử lý tình huống đó từ đầu đến cuối. Sau phần demo, chia sẻ người dùng đã làm gì khi thử, đâu là điểm khiến họ gặp khó và nhóm đã sửa hoặc sẽ kiểm tra tiếp điều gì.

Người nghe, dù là sinh viên, giảng viên hay một người lần đầu biết dự án, đều có thể theo dõi một mạch đơn giản: vấn đề cụ thể → cách giải quyết có thể dùng thử → hành vi thực tế → quyết định tiếp theo. Mạch này cũng giúp nhóm tự kiểm tra sản phẩm. Một tính năng không nối được với vấn đề hoặc điều cần học có thể chưa cần xuất hiện trong phiên bản đầu.

Từ một ý tưởng được trình bày hợp lý đến một sản phẩm có giá trị là cả quá trình thử và sửa. Bản đầu không cần chứng minh rằng nhóm đã đúng ở mọi điểm. Nó cần giúp nhóm trả lời rõ hơn: Người dùng có thực hiện được việc quan trọng nhất không? Điều gì cản họ? Và nhóm sẽ làm gì với điều vừa học được?

Đọc thêm

• Strategyzer — MVP và kiểm tra giả định

• Y Combinator — Cách nghĩ về phiên bản đầu

• Nielsen Norman Group — Hướng dẫn kiểm thử với người dùng