Thiết Kế Biểu Mẫu Cho Người Không Chuyên: Vì Sao Người Dùng Bỏ Dở Giữa Chừng Và Cách Khắc Phục

Hầu như ứng dụng nào cũng có một biểu mẫu ở đâu đó. Đăng ký tại đây. Thêm khách hàng mới. Đặt lịch hẹn. Cho chúng tôi biết điều gì đã sai. Và hầu như ứng dụng nào cũng để mất người dùng ngay tại đó—trên chính màn hình mà bạn yêu cầu họ gõ điều gì đó trả lại. Họ đã đủ tò mò để ghé vào, và biểu mẫu chính là nơi họ lặng lẽ đóng tab.

Thiết kế biểu mẫu đơn giản là tập hợp những lựa chọn đằng sau màn hình đó: bạn yêu cầu những trường nào, chúng xuất hiện theo thứ tự ra sao, và biểu mẫu phản hồi thế nào khi ai đó mắc lỗi hoặc hoàn tất. Đây là một trong những thay đổi có tác động lớn nhất bạn có thể thực hiện cho một ứng dụng do AI xây dựng, bởi biểu mẫu là khoảnh khắc bạn yêu cầu ai đó bỏ công sức—làm sai điều này và mọi nỗ lực bạn bỏ vào phần còn lại của ứng dụng sẽ chẳng bao giờ có cơ hội phát huy giá trị. Đây là lý do vì sao người dùng bỏ dở biểu mẫu, và một vài thay đổi giúp họ đi đến cuối cùng.

Vì sao người dùng bỏ dở biểu mẫu giữa chừng?

Người dùng bỏ dở khi những gì một biểu mẫu yêu cầu vượt quá những gì họ nhận lại được—đó là toàn bộ cơ chế. Hầu hết các biểu mẫu tệ không phải vì xấu; chúng chỉ đơn giản là yêu cầu quá nhiều, quá sớm, trước khi người dùng được thuyết phục rằng nó đáng công sức.

Hãy nghĩ mỗi trường là một yêu cầu riêng biệt. “Tên bạn là gì?” là một yêu cầu nhỏ. “Tải lên giấy phép kinh doanh của bạn” là một yêu cầu lớn. “Tạo mật khẩu” là mức trung bình, nhưng nó cũng là một cam kết—nó nói rằng bạn sẽ còn quay lại đây. Khi ai đó chạm vào biểu mẫu của bạn, họ đang âm thầm cộng dồn những yêu cầu đó và cân nhắc so với mức độ họ muốn có kết quả. Vì vậy, bước đi đầu tiên trong thiết kế biểu mẫu không phải là hình ảnh. Đó là quyết định bạn thực sự cần gì.

Một biểu mẫu nên có bao nhiêu trường?

Càng ít càng tốt trong khả năng cho phép. Cách khắc phục lớn nhất cho việc bỏ dở biểu mẫu là xóa bớt trường—không phải thu nhỏ chúng, không phải sắp xếp lại chúng. Xóa chúng đi.

Một người bạn của tôi từng xây dựng một công cụ đặt lịch cho dịch vụ dọn dẹp của cô ấy. Biểu mẫu ở phiên bản đầu tiên có mười một trường: tên, email, số điện thoại, địa chỉ, diện tích, số phòng ngủ, số phòng tắm, thú cưng, ngày mong muốn, giờ mong muốn, và “còn gì khác không.” Hầu như không ai hoàn tất được. Chúng tôi cắt xuống còn ba—tên, số điện thoại, và “khi nào tiện cho bạn?”—và để cô ấy hỏi phần còn lại trong cuộc gọi xác nhận mà cô ấy vốn đã thực hiện. Số lượt đặt lịch tăng lên ngay lập tức. Tám trường còn lại không hề thu thập thông tin; chúng đang khiến người dùng sợ hãi bỏ đi trước khi cô ấy kịp có được khách hàng tiềm năng.

Với mỗi trường, hãy tự hỏi một câu: tôi có cần thông tin này ngay bây giờ, để thực hiện bước tiếp theo hay không? Nếu câu trả lời là “không, nhưng có thì cũng tốt,” hãy cắt bỏ nó. Bạn luôn có thể hỏi sau, một khi người dùng đã trở thành khách hàng thay vì một người lạ đang cân nhắc có nên bận tâm hay không. Một biểu mẫu chỉ hỏi ba điều và hoạt động tốt sẽ hơn hẳn một biểu mẫu kỹ lưỡng mà chẳng ai hoàn thành.

Các trường trong biểu mẫu nên được sắp xếp theo thứ tự nào?

Bắt đầu với những trường dễ nhất, ít cam kết nhất—những trường không cần suy nghĩ nhiều, như tên hay email—và để dành bất cứ điều gì đòi hỏi nỗ lực thực sự cho sau này, khi người dùng đã có đà. Thứ tự quan trọng hơn nhiều người nghĩ. Một khi ai đó bắt đầu gõ, họ có xu hướng tiếp tục nhiều hơn hẳn; phần khó nhất là việc bắt đầu. Mở đầu bằng “tạo mật khẩu” hay “tải lên tài liệu” là yêu cầu một cam kết lớn trước khi có bất kỳ đà nào, và đó chính là nơi người dùng bỏ cuộc.

Nếu một biểu mẫu thực sự dài—một đơn đăng ký chi tiết, một quy trình tiếp nhận với giấy tờ thực sự—hãy chia nó thành các bước và cho biết họ đang ở đâu. “Bước 2 trên 3” là một điều nhỏ nhưng có tác dụng thực sự: nó cho người dùng biết điểm kết thúc đang trong tầm mắt, để họ không bỏ cuộc giữa một cuộn dài chỉ vì không biết còn bao nhiêu nữa. Một vạch đích rõ ràng giữ chân người dùng tiếp tục tiến về phía đó.

Những trường nào trong biểu mẫu nên là bắt buộc?

Càng ít càng tốt. Đánh dấu các trường bắt buộc rõ ràng, và—quan trọng hơn—hãy để hầu như không có gì là bắt buộc. Mỗi trường bắt buộc là một nơi mà biểu mẫu có thể từ chối ai đó, và không gì giết chết một biểu mẫu nhanh hơn việc ai đó điền xong, nhấn gửi, rồi bị trả lại với ba lỗi màu đỏ cho những trường mà họ không hề biết là phải điền.

Nếu một trường có thể là tùy chọn, hãy để nó là tùy chọn. Số điện thoại mà bạn “muốn có” không đáng để đánh đổi bằng việc người dùng không muốn cung cấp nó và bỏ cuộc thay vì tiếp tục.

Cách xác thực lỗi trong biểu mẫu nên hoạt động ra sao?

Xác thực tốt bắt lỗi ngay khoảnh khắc nó xảy ra và giải thích cụ thể cần sửa gì, thay vì đợi đến khi gửi rồi tung ra cả mảng lỗi màu đỏ. Một biểu mẫu tốt bắt vấn đề ngay tại nơi nó xảy ra, ngay khi người dùng điền xong trường đó, và nói điều gì đó cụ thể và tử tế: “Email này thiếu ký hiệu @.” Một biểu mẫu tệ đợi đến khi họ nhấn gửi, tung ra cả mảng đỏ, và nói “Dữ liệu không hợp lệ”—điều này chẳng cho họ biết cái gì cần sửa.

Sự khác biệt nằm ở chỗ biểu mẫu có cảm giác như đang đứng về phía người dùng hay không. “Ngày đó đã qua rồi—hãy chọn một ngày trong tuần này” là một lời trợ giúp. “Lỗi” là một lời khiển trách. Cái này giúp hoàn tất; cái kia khiến người ta bỏ cuộc. Đây là một phần nhỏ nhưng thực sự quan trọng trong thiết kế biểu mẫu, và đáng để kiểm tra lại mọi thông báo lỗi mà ứng dụng của bạn có thể hiển thị.

Làm sao để biểu mẫu thân thiện với điện thoại di động?

Có hai điều quan trọng nhất trên điện thoại, và điện thoại không khoan nhượng với những biểu mẫu làm ẩu. Thứ nhất, yêu cầu đúng loại bàn phím: một trường email nên bật lên bàn phím có ký hiệu @, một trường số điện thoại nên hiện bàn phím số. Trình xây dựng của bạn có thể thiết lập điều này, và nó biến việc gõ chữ từ một việc phiền phức thành một cú chạm. Thứ hai, dùng bộ chọn ngày thực sự cho các trường ngày tháng thay vì bắt ai đó phải gõ “06/21/2026” bằng ngón cái—một lịch mà họ chỉ cần chạm vào thì nhanh hơn và không bao giờ tạo ra một ngày sai định dạng.

Hãy tự thử điều này: mở biểu mẫu trong ứng dụng của bạn trên chính điện thoại của mình và điền nó như thể bạn là một người lạ đang vội. Sự trở ngại sẽ lộ ra trong khoảng mười giây.

Điều gì nên xảy ra sau khi ai đó gửi biểu mẫu?

Hiển thị một xác nhận rõ ràng ngay khi họ gửi—một thông điệp, một lời cảm ơn, một câu “chúng tôi đã nhận được, đây là điều sẽ xảy ra tiếp theo.” Phần bị bỏ qua nhiều nhất của một biểu mẫu là phần kết. Ai đó nhấn gửi và… không có gì xảy ra rõ ràng cả. Nó đã gửi đi chưa? Họ có nên làm lại không? Sự im lặng đó khiến người dùng gửi lại, hoặc tệ hơn, cho rằng nó bị hỏng và bỏ đi. Đó chỉ là một màn hình, nhưng nó tạo nên sự khác biệt giữa việc ai đó tin tưởng ứng dụng của bạn và việc ai đó tự hỏi liệu mình vừa lãng phí thời gian hay không.

Cách yêu cầu trình xây dựng của bạn

Phần lớn những điều này bạn có thể giao thẳng cho trình xây dựng AI của mình nếu bạn nói rõ ràng, cụ thể:

• “Biểu mẫu này chỉ nên có ba trường: tên, số điện thoại, và ngày mong muốn. Chuyển mọi thứ khác sang một bước sau.”
• “Làm cho mọi trường đều là tùy chọn ngoại trừ tên và email.”
• “Hiển thị thông báo lỗi ngay cạnh từng trường khi người dùng đang gõ, kèm gợi ý bằng ngôn ngữ đơn giản—không phải một danh sách lỗi duy nhất ở cuối.”
• “Dùng bàn phím email cho trường email và bộ chọn ngày cho trường ngày trên điện thoại di động.”
• “Sau khi họ gửi, hiển thị màn hình xác nhận nói rằng chúng tôi đã nhận được và điều gì sẽ xảy ra tiếp theo.”

Mỗi điều trong số đó là một chỉ dẫn rõ ràng mà trình xây dựng của bạn có thể thực hiện, và cùng nhau chúng bao quát phần lớn những gì phân biệt một biểu mẫu mà người dùng hoàn tất với một biểu mẫu mà họ bỏ chạy.

Làm sao để kiểm tra một biểu mẫu trước khi ra mắt?

Mở nó trên điện thoại của bạn và cố gắng hoàn tất nó nhanh nhất có thể, như thể bạn chưa từng thấy nó bao giờ. Đó là toàn bộ bài kiểm tra. Chú ý đến mọi điểm mà bạn do dự, nheo mắt, hoặc phải suy nghĩ—những khoảnh khắc do dự đó chính xác là nơi người dùng thật sự của bạn sẽ bỏ cuộc, và giờ bạn đã biết chính xác điều gì cần sửa trước tiên.