Các trường T21 được đánh dấu bằng dấu là bắt buộc. Các trường bắt buộc và tùy chọn khi điền biểu mẫu. Vùng Podolsk và Moscow

Có vẻ như không có gì phức tạp trong việc thiết kế các trường nhập: vẽ các hình chữ nhật trống để nhập dữ liệu, người dùng sẽ tự làm phần còn lại. Tuy nhiên, mọi thứ không đơn giản như vậy. Đánh giá theo độ dài của bài viết, rõ ràng có khá nhiều quy tắc và tính năng. Người dùng cần được “hướng dẫn tận tay” một cách cẩn thận, chỉ dẫn mọi thứ, giải thích và trợ giúp. Khi đó và chỉ khi đó chúng ta mới có thể lấy được dữ liệu mong muốn từ anh ta. Nào, hãy bắt đầu!

Hơn 7 quy tắc trường đầu vào

Quy tắc cơ bản nhất, như mọi nơi khác, là đặt mình vào vị trí của khách. Mọi thứ đã rõ ràng chưa? Có thể hiểu ngay từ cái nhìn đầu tiên những gì cần phải nhập vào trường này? Trường này có phản hồi đầy đủ với thông tin được nhập không?

Viết mô tả và lời khuyên

Cần có gợi ý và mô tả để hiển thị dữ liệu nào cần nhập, cách nhập chính xác và cách trang web sẽ sử dụng thông tin này trong tương lai.

Có một số loại gợi ý:

1) Biểu tượng

Biểu tượng là một ngôn ngữ hình ảnh phổ quát. Chúng giúp bạn hiểu những gì cần nhập ngay cả khi chỉ nhìn lướt qua. Và vâng, các biểu tượng là một thứ tôn sùng thiết kế =)

Tuy nhiên, chúng ta không nên quên rằng chúng luôn cần được giải thích.

2) Ví dụ

Cách dễ nhất để biết cách điền vào một trường là đưa ra một ví dụ. Ví dụ mẫu: " [email được bảo vệ]»

3) Giải thích

Loại mô tả này dùng để giải thích cách trang web sẽ sử dụng dữ liệu và nó cần thiết cho mục đích gì. Ví dụ: “Chúng tôi cần thư để thông báo cho bạn về trạng thái đơn hàng của bạn. Chúng tôi sẽ không gửi thư rác."

Sử dụng mặt nạ

Đối với các trường yêu cầu dữ liệu được định dạng theo một cách nhất định (ví dụ: số thẻ ngân hàng hoặc số điện thoại), nên sử dụng mặt nạ. Vì vậy, chúng tôi chuyển công việc định dạng thông tin từ vai của khách truy cập sang một cỗ máy vô hồn.

Dưới đây là một số ví dụ về các mặt nạ khác nhau:

Đánh dấu các trường bắt buộc

Nếu trong số các trường tùy chọn có các trường bắt buộc phải điền thì chúng phải được đánh dấu trong số các trường khác và cần nhấn mạnh vào việc bắt buộc phải điền chúng. Theo quy định, các trường bắt buộc được biểu thị bằng dấu hoa thị - *.

Tốt hơn là nhóm tất cả các trường bắt buộc lại với nhau và đặt chúng ở đầu biểu mẫu.

Nhân tiện, ví dụ trên cũng hiển thị 2 loại mẹo: ví dụ và giải thích.

Tập trung và bàn phím

Trường hoạt động mà con trỏ được định vị phải có tính năng đặc biệt. Theo quy định, các trình duyệt sẽ đánh dấu các trường hoạt động một cách độc lập. Tuy nhiên, bạn không nên để mọi thứ có cơ hội và tự mình kiểm tra chức năng của chức năng này.

Khi tải trang, trường nhập đầu tiên sẽ tự động hoạt động. Như thể đang mời gọi bạn điền vào toàn bộ mẫu đơn. Khi điền vào biểu mẫu, có thể chuyển đổi giữa các trường nhập mà không cần sử dụng chuột. Điều này thường xảy ra bằng cách nhấn nút Tab.

Khi sử dụng gợi ý có tính năng tự động hoàn thành (ví dụ: trong tìm kiếm), bạn có thể chọn một mục bằng cách sử dụng mũi tên và xác nhận mục đó bằng cách nhấn phím Enter.

Khi nhập dữ liệu bí mật (ví dụ: mật khẩu), có thể ẩn và hiển thị dữ liệu này theo yêu cầu của người dùng.

Sử dụng dữ liệu đã nhập

Các trường đầu vào cần ghi nhớ những điều mà người bình thường quên. Thật thô lỗ khi yêu cầu cùng một thông tin hai lần. Nếu bạn đã từng đăng ký vào danh sách gửi thư của trang web thì khi đăng ký, trang web sẽ ghi nhớ bạn và nhập email của bạn vào trường thích hợp.

Nhóm trường nhập

Để dễ điền, tốt hơn nên nhóm các trường tương tự lại với nhau. Ví dụ: các trường có thông tin cá nhân (tên, họ, email) là một khối, các trường có địa chỉ gửi là một khối khác.

Hãy nhận biết kích thước trường

Kích thước trường trong hầu hết các trường hợp dùng để ước tính lượng dữ liệu được yêu cầu từ người dùng. Những thứ kia. nơi bạn cần nhập một địa chỉ dài, trường này lớn. Vì vậy, khi cần chỉ mục gồm 6 chữ số, trường này sẽ nhỏ.

Cuối cùng

Thiết kế của các trường đầu vào không đơn giản như thoạt nhìn. Bạn cần ghi nhớ nhiều sắc thái và liên tục tự hỏi mình câu hỏi: “Liệu mọi thứ có rõ ràng với người dùng không?”

Nhiều anh chàng tỉ mỉ sẽ nói rằng không có 7 quy tắc nào cả (và một số thậm chí còn không để ý, ha ha ha). Tuy nhiên, nhiều quy tắc còn nhỏ nên tôi tính chúng là một nửa. Và nói chung là mình chỉ thích số 7 thôi =))

Thông tin tối đa trong tối thiểu các từ.

Cách các trường được gắn nhãn ảnh hưởng lớn đến cách người dùng cảm nhận biểu mẫu và cách họ hoàn thành nó.

Từ quan điểm tâm lý học, mọi thứ khá đơn giản: chỉ ra những khía cạnh tích cực thì tốt hơn, bởi vì khi đưa ra quyết định, người dùng sẽ tin rằng anh ấy có một sự lựa chọn.

Mặt khác, nếu bạn chỉ định các trường bắt buộc, người dùng sẽ cảm thấy bị mắc kẹt, bị hạn chế và không thoải mái.

Đánh dấu các trường tùy chọn, không phải ngược lại

Hầu hết các nhà thiết kế sử dụng dấu hoa thị để biểu thị các trường bắt buộc. Nhưng bạn cần phải ngừng làm điều này. Nghiên cứu về vấn đề này chỉ ra rõ ràng rằng việc sử dụng dấu hoa thị cho các trường bắt buộc là một lỗi phổ biến.

Sẽ tốt hơn nếu đánh dấu các trường tùy chọn thay vì các trường bắt buộc vì:

Dấu hoa thị là hiển nhiên đối với bạn chứ không phải với tất cả mọi người, tin tôi đi, luôn có những người không hiểu
Luôn có nhiều trường bắt buộc hơn trường tùy chọn
Biểu mẫu của bạn càng ít nhiễu thì càng dễ đọc và do đó điền vào nhanh hơn.

Không yêu cầu vs Không bắt buộc

Nếu bạn viết một văn bản bằng tiếng Anh, hãy nhớ rằng trong mọi trường hợp, phủ định sẽ kém rõ ràng hơn. Do đó, hãy sử dụng từ “Tùy chọn” thay vì “Không bắt buộc” để mô tả các trường tùy chọn.

Đừng yêu cầu người dùng cung cấp thông tin vô ích. Nếu bạn có quá nhiều trường bổ sung (không bắt buộc) thì điều đó thật tệ và bạn biết điều đó. Cả bạn và tôi đều không thích hình dạng cuộn giấy vệ sinh.

Có rất nhiều lầm tưởng và quan niệm sai lầm trong thế giới phát triển phần mềm. Để tiến về phía trước và không bị trì trệ thì việc tiêu diệt chúng là điều hết sức cần thiết. Hôm nay chúng ta đang nói về một trong những quan niệm sai lầm sâu xa nhất và cũng khá có hại, được gọi là “Huyền thoại về tình dục bắt buộc”.

Chúng ta sẽ nói về hầu hết mọi hệ thống sử dụng biểu mẫu để nhập thông tin. Trường bắt buộc là trường biểu mẫu, nếu không có trường này hệ thống sẽ không chấp nhận thông tin của bạn. Trong số đại đa số các nhà phát triển phần mềm, có ý kiến cho rằng các trường bắt buộc phải là:

Tất cả các trường cần thiết theo quan điểm của chủ đề (ví dụ: tên đầy đủ và ngày sinh của một người, nếu chúng ta đang nói về văn phòng hộ chiếu);
Tất cả các trường cần thiết cho hoạt động của hệ thống (những trường mà không có những trường này thì thuật toán sẽ không hoạt động - ví dụ: ngày bắt đầu cung cấp dịch vụ để tích lũy chúng);
Các trường quan trọng là những trường không cần thiết nhưng tốt nhất làđiền vào (ví dụ: lý do căn bản cho sự thay đổi được thực hiện) - với động cơ là người dùng sẽ thà đổ mồ hôi khi không cần thiết hơn là quên nhập giá trị khi cần thiết.

Như bạn có thể thấy, ở đây có cả một mớ huyền thoại phức tạp cần được xua tan một cách cẩn thận và có hệ thống. Vì vậy, hãy bắt đầu với hai quan niệm sai lầm khác.

Theo truyền thống, các lập trình viên tin rằng họ đang mang lại lợi ích cho phần còn lại của thế giới bằng cách tạo ra một sản phẩm tuyệt vời cho họ dưới dạng “thay thế bất kỳ tên sản phẩm nào”. Chương trình của họ gần như là một eidos Platonic, một sự trừu tượng thuần túy, một công thức toán học, tất nhiên có thể tính toán được, hoàn toàn dựa trên một tập hợp các tham số từ miền định nghĩa của nó. Từ quan điểm này, các trường bắt buộc là một điều nhỏ khó chịu phải được chèn vào để dạy cho những người dùng ngu ngốc và thô lỗ cách Phải nhập thông tin vào hệ thống mà họ có đặc quyền làm việc.

Người ta cũng tin rằng dữ liệu không chính xác (không đầy đủ) khủng khiếp đến mức ngay cả việc lưu trữ nó trong cơ sở dữ liệu cũng không còn chính xác nữa. Tất nhiên, sự lười biếng - theo quan điểm của nhà phát triển, việc kiểm tra tính chính xác của dữ liệu ở giai đoạn đầu vào sẽ dễ dàng hơn và yêu cầu người dùng kiểm tra kỹ dữ liệu của họ hơn là viết xử lý lỗi ở nơi dữ liệu này thực sự sẽ được sử dụng trong hệ thống.

Khoa học thiết kế trải nghiệm người dùng hiện đại nói gì về điều này? Đầu tiên, mọi chuyện trở nên rõ ràng (tôi không biết với ai và khi nào, nhưng chắc chắn đã khá lâu rồi, hãy xem và) rằng xét cho cùng thì các chương trình đều được phát triển cho người dùng. Theo nghĩa này, lập trình viên không còn ra lệnh cho các điều kiện nữa mà khiêm tốn tạo ra một sản phẩm thuần túy tiện dụng, một công cụ mà mọi người sẽ sử dụng để giải quyết. của họ nhiệm vụ và thành tích của họ bàn thắng. Giống như một cái bàn ủi - nếu bạn cần ủi cái gì đó, bạn hãy bật nó lên. Nếu, thay vì ủi, nó đề nghị tải xuống các bản cập nhật từ Internet một cách phương thức, thì rõ ràng chiếc bàn ủi như vậy sẽ bay đến đâu. Alan Cooper khuyên bạn nên miêu tả người dùng sản phẩm của mình là những người rất thông minh nhưng rất bận rộn. Họ nói rằng họ không ngu ngốc và sẽ hiểu cách sử dụng sản phẩm của bạn, điều quan trọng chính là bạn không cản trở họ.

Nói chung, tôi tin rằng mọi lập trình viên (nhà thiết kế, quản lý, nhà phân tích) nên thực hiện bài thiền đã được Sergei Bodrov Jr. đề cập:

Bạn đứng ở góc một con phố đông đúc và tưởng tượng rằng bạn không có ở đó. Hay đúng hơn là bạn hoàn toàn không tồn tại. Người đi bộ bước đi, ô tô bấm còi, cửa hàng mở ra, hành khách đổi xe ở bến xe buýt. Về nguyên tắc, đó là thế giới tiếp tục sống mà không có bạn. Điều này thật đau đớn để hiểu. Nhưng nó quan trọng...

Tất nhiên, tôi không muốn nói rằng lập trình viên là một nghề không cần thiết; bản thân tôi cũng là một lập trình viên và tôi không hề nghĩ như vậy. Đó chỉ là một nghề vô ơn. Sẽ không có ai đến và khen ngợi bạn về một thuật toán được triển khai tốt. Nếu chương trình tốt, nó sẽ được sử dụng mà không cần thắc mắc gì thêm. Vốn dĩ là thế này, đã là lập trình viên thì phải làm quen thôi. Và những người đi bộ xuống phố và thay phiên nhau ở bến xe buýt là người dùng của bạn. Họ sử dụng mọi thứ theo cách họ làm họ cần thiết. Bao gồm cả sản phẩm của bạn. Không có bạn. Họ không biết gì về bạn, không muốn biết và sẽ không bao giờ biết. Sergei Vitalievich, khi anh ấy đang ở vùng lãnh nguyên vùng cực cố gắng nhập các số liệu lấy từ đồng hồ vào hệ thống, không hề quan tâm đến lý do tại sao hệ thống lại nói với anh ấy rằng trước tiên bạn cần chỉ ra một số loại thuế quan, ngay cả khi vào thời điểm đó. về thiết kế, đối với bạn, dường như nếu không có loại thuế quan thì sẽ không có cách nào giải quyết được. Đối với ví dụ về các bản cập nhật tải xuống sắt, nó không được lấy từ không khí - hãy chú ý đến cách trình duyệt Firefox hoạt động khi được bật.

Habrowser hỏi liệu có điều gì về các trường bắt buộc không? Nó sắp bắt đầu.

Vấn đề là thế giới thực của chúng ta không phải là một mô hình toán học có các tham số được biết bất cứ lúc nào. Cuộc sống thực được đặc trưng bởi sự thiếu thông tin hơn là sự hiện diện của nó. Người điền vào biểu mẫu có thể không có dữ liệu cần thiết - và có thể không có dữ liệu đó trong tầm tay có thể thấy trước, nghĩa là cuối cùng nó có thể không tồn tại. Vấn đề này không thể được giải quyết bằng cách đơn giản là bắt buộc nhập trường - giá trị sẽ không bị lấy ra ngoài không khí. Bằng cách giới thiệu các trường bắt buộc trên biểu mẫu nhằm đảm bảo tính toàn vẹn và đầy đủ của dữ liệu, chúng tôi thực sự can thiệp vào việc sử dụng hệ thống. Đối mặt với tình huống như vậy, người dùng sẽ không điền vào biểu mẫu (và hoàn toàn không thể làm việc với hệ thống) hoặc sẽ điền dữ liệu còn thiếu bằng cá - dữ liệu hư cấu hoặc vô nghĩa. Và điều này không có nghĩa là người dùng kém hoặc không cố gắng hết sức mà chỉ có nghĩa là hệ thống đã phát triển không đủ linh hoạtđể sử dụng trong điều kiện thực tế hòa bình. Những gì xảy ra trong trường hợp thứ hai (giới thiệu cá) hoàn toàn là một sự lừa dối. Nhà phát triển hệ thống có thể giả vờ tùy ý rằng mọi thứ đều ổn, nhưng thực tế chính anh ta là người phải chịu trách nhiệm về sự lừa dối này. Hơn nữa, không rõ ai thắng và cái gì - người dùng đau đầu và dữ liệu nhập vào hệ thống không chính xác. Có, họ đã rơi vào tình huống không thể phát hiện, lọc hoặc dọn dẹp chúng một cách tự động - không giống như trường hợp người dùng chỉ đơn giản chỉ ra rằng thông tin bị thiếu.

Phải làm gì? Bạn cần làm những chương trình hay. Cụ thể là, vâng, không đặt tính toàn vẹn của lược đồ cơ sở dữ liệu lên hàng đầu mà đặt mục tiêu và mục tiêu của người dùng vào đó. Nói cách khác, việc chấp nhận dữ liệu không đầy đủ và trong một số trường hợp là không chính xác từ người dùng, một cách tự nhiên, có cơ hội sửa chúng trong tương lai. Trái ngược với quan niệm sai lầm (vâng, một quan niệm khác), điều đó là có thể, nó không quá khó và thậm chí còn hiệu quả. Ngoài ra, bạn vẫn cần trợ giúp bằng cách nào đó, cho người dùng biết ở đâu, dữ liệu gì và tại sao anh ta bị thiếu. Để anh ta có thể nhìn thấy và kiểm soát tình hình.

Nên có bao nhiêu trường bắt buộc trên biểu mẫu? Lý tưởng nhất là bằng không. Điều này luôn có thể thực hiện được phải không? Đối với tôi, một trong những ví dụ về nhào lộn trên không là thao tác tạo thư mục trong Windows. Có vẻ như bạn không thể thực hiện ít hơn một trường ở đây, nhưng không, họ đã cố gắng thực hiện việc tạo theo cách mà hệ thống không yêu cầu bất cứ điều gì - mặc dù các giới hạn kỹ thuật không cho phép hệ thống tạo thư mục không có tên. Đây là một lý tưởng để phấn đấu.

Đương nhiên, hệ thống phải thông minh ở mức tối thiểu, chỉ hỏi người dùng những gì liên quan đến nhiệm vụ của người dùng chứ không liên quan đến nhu cầu của chính hệ thống. Hệ thống này giống như một công cụ, bạn nhớ chứ? Ví dụ như với Firefox - Google Chrome chẳng hạn, đã giải quyết vấn đề Firefox bằng cách cập nhật lặng lẽ vào thời điểm người dùng khởi động lại nó. Người dùng hoàn toàn không cần biết về điều này - anh ta không biết. Một tấm gương đáng để noi theo. Tôi phải thừa nhận, lúc đầu tôi thậm chí còn không hiểu, tại sao anh ấy không bao giờ hỏi tôi khi nào nên cập nhật?

Cũng có một huyền thoại về các lĩnh vực quan trọng (đây là những lĩnh vực không bắt buộc nhưng mong muốn được điền vào). Ở đây mọi thứ thậm chí còn đơn giản hơn - bạn không thể buộc điền vào trường. Vì vậy, dù bạn đánh dấu trường này là bắt buộc, hoặc không đánh dấu, họ vẫn sẽ viết cá, vớ vẩn, hủy đăng ký nếu không muốn điền. Không có giải pháp giao diện cho vấn đề này. Tầm quan trọng của các lĩnh vực này phải được thông báo cho nhân viên hiện trường. Và nhà phát triển nên đánh dấu trường này là tùy chọn. Và hãy để tôi chỉnh sửa.

Văn học:

Alan Cooper về giao diện. Nguyên tắc cơ bản của thiết kế tương tác. Biểu tượng-Plus, 2009
Jeff Raskin. Giao diện: hướng đi mới trong thiết kế hệ thống máy tính. Biểu tượng-Plus, 2005

CẬP NHẬT: Trong các bình luận, đạo đức chính của chủ đề đã được xây dựng rõ ràng hơn: chúng ta đang nói về hệ thống dự thảo, về việc loại bỏ yêu cầu nhập tất cả dữ liệu cùng một lúc và nhất quán. Nghĩa là, vâng, hãy đặt tùy chọn ngay cả những trường mà nếu không có thì hệ thống sẽ không hoạt động. Đương nhiên là nó sẽ không hoạt động nhưng ít nhất nó sẽ cứu được dữ liệu.

CẬP NHẬT #2: Xin nói rõ thêm một điều mà bản thân tôi cũng chưa nhận thức rõ ràng khi viết đề tài này. Tôi không thảo luận ở đây về tính phù hợp của một số trường nhất định trên biểu mẫu (đây là một chủ đề quan trọng nhưng vẫn hơi khác so với chủ đề tôi muốn truyền tải). Đúng hơn, tôi đề xuất suy nghĩ lại chính khái niệm nhập thông tin bằng biểu mẫu, cách tiếp cận truyền thống đó khi bạn cần điền vào toàn bộ biểu mẫu cùng một lúc và chính xác. Thay vào đó, tôi đề xuất rằng trạng thái trung gian (không đầy đủ, không chính xác, mâu thuẫn) cũng được phép lưu vào cơ sở dữ liệu, đánh dấu rõ ràng trạng thái đó là không đầy đủ/không chính xác/không nhất quán. Do đó, tất cả các tình huống “Bây giờ tôi không biết mọi thứ, nhưng có thể ngày mai tôi sẽ biết”, thường được giải quyết bằng cách viết chúng ra một tờ giấy, có thể được xử lý bằng hệ thống thông tin. Đương nhiên, những dữ liệu đó không được phép đưa vào quy trình kinh doanh do tính không chính xác của nó - mọi thứ vẫn như trước. Chúng sẽ chỉ nằm trong cơ sở dữ liệu cho đến thời điểm tốt hơn - chúng sẽ không hữu ích, à, Chúa phù hộ cho chúng.

Tất cả các trường cần thiết theo quan điểm của chủ đề (ví dụ: tên đầy đủ và ngày sinh của một người, nếu chúng ta đang nói về văn phòng hộ chiếu);
Tất cả các trường cần thiết cho hoạt động của hệ thống (những trường mà không có những trường này thì thuật toán sẽ không hoạt động - ví dụ: ngày bắt đầu cung cấp dịch vụ để tích lũy chúng);
Các trường quan trọng là những trường không cần thiết nhưng tốt nhất làđiền vào (ví dụ: lý do căn bản cho sự thay đổi được thực hiện) - với động cơ là người dùng sẽ thà đổ mồ hôi khi không cần thiết hơn là quên nhập giá trị khi cần thiết.

Nói chung, tôi tin rằng mọi lập trình viên (nhà thiết kế, quản lý, nhà phân tích) nên thực hiện bài thiền đã được Sergei Bodrov Jr. đề cập:

Bạn đứng ở góc một con phố đông đúc và tưởng tượng rằng bạn không có ở đó. Hay đúng hơn là bạn hoàn toàn không tồn tại. Người đi bộ bước đi, ô tô bấm còi, cửa hàng mở ra, hành khách đổi xe ở bến xe buýt. Về nguyên tắc, đó là thế giới tiếp tục sống mà không có bạn. Điều này thật đau đớn để hiểu. Nhưng nó quan trọng...

Habrowser hỏi liệu có điều gì về các trường bắt buộc không? Nó sắp bắt đầu.

Văn học:

Alan Cooper về giao diện. Nguyên tắc cơ bản của thiết kế tương tác. Biểu tượng-Plus, 2009
Jeff Raskin. Giao diện: hướng đi mới trong thiết kế hệ thống máy tính. Biểu tượng-Plus, 2005

CẬP NHẬT: Trong phần nhận xét, trijin và zhindetz đã trình bày rõ ràng hơn đạo đức chính của chủ đề: chúng ta đang nói về hệ thống dự thảo, về việc loại bỏ yêu cầu nhập tất cả dữ liệu cùng một lúc và nhất quán. Nghĩa là, vâng, hãy đặt tùy chọn ngay cả những trường mà nếu không có thì hệ thống sẽ không hoạt động. Đương nhiên là nó sẽ không hoạt động nhưng ít nhất nó sẽ cứu được dữ liệu.

Ngày 13 tháng 1 năm 2011 lúc 01:09

Giao diện

Dịch

Các biểu mẫu web đóng một vai trò lớn trong việc sử dụng Internet hàng ngày. Nếu bạn phát triển trang web, thì rất có thể chúng sẽ hiện diện trong đó: có thể là một biểu mẫu phản hồi đơn giản hoặc một ứng dụng web phức tạp. Dưới đây là một số mẹo giúp bạn tạo các biểu mẫu dễ sử dụng.

1. Đánh dấu rõ ràng các trường bắt buộc

Thật khó chịu khi người dùng gửi biểu mẫu đã điền đầy đủ và sau đó phát hiện ra rằng họ đã bỏ sót các trường bắt buộc.
Thông thường, đánh dấu các trường bắt buộc bằng dấu hoa thị (*) bên cạnh tên của chúng. Việc chỉ rõ một trường có bắt buộc hay không là một ý tưởng hay.

Trên mẫu đăng ký Zappos.com, các trường bắt buộc được đánh dấu bằng dấu hoa thị (*). Các trường tùy chọn cũng được đánh dấu rõ ràng.

2. Sử dụng thông báo lỗi rõ ràng và chi tiết

Tôi chắc rằng bạn sẽ rất ghét khi điền sai biểu mẫu, thông báo lỗi sẽ xuất hiện với nội dung: “Bạn phải hoàn thành tất cả các trường bắt buộc” thay vì cung cấp thông tin chi tiết hơn, chẳng hạn như “Bạn quên điền địa chỉ email của mình”. .”
Sử dụng xác thực thời gian thực của dữ liệu đã nhập là một giải pháp tốt. Ví dụ: ngay sau khi điền địa chỉ email, biểu mẫu web phải kiểm tra xem định dạng đã nhập có đúng không và nếu có sai sót thì hãy thông báo ngay cho người dùng.

3. Sử dụng xác thực định dạng dữ liệu phía máy khách (JavaScript)

Sử dụng xác thực dữ liệu JavaScript giúp tiết kiệm thời gian của người dùng và cũng giảm tải cho máy chủ web, giải phóng nó khỏi việc xử lý các giá trị trường biểu mẫu đến. Xác thực phía máy khách cho phép người dùng thấy rằng họ vừa mắc lỗi chứ không phải sau khi gửi biểu mẫu. Điều này đúng với bất kỳ trường nào không được liên kết với cơ sở dữ liệu của bạn. Chẳng hạn như kiểm tra định dạng của địa chỉ email hoặc số chữ số trong số điện thoại.

Biểu mẫu đăng ký SurveyGizmo cho bạn biết liệu địa chỉ email bạn đã nhập có đúng định dạng hay không.

4. Đánh dấu trực quan các trường cần điền để người dùng không bị lạc

Đảm bảo rằng bạn có thể xác định trực quan trường nào người dùng hiện đang điền. Điều này có thể đạt được bằng cách sử dụng bộ chọn tiêu điểm: giả lớp trong CSS.

Biểu mẫu web Wufoo làm nổi bật các phần tử đang hoạt động một cách trực quan bằng màu nền.

Ở mức tối thiểu, hãy triển khai đường viền được đánh dấu cho các trường - theo mặc định, trình duyệt sẽ thực hiện việc này cho bạn nhưng hãy đảm bảo màu khác với thiết kế trang web (nền).

Google Chrome làm nổi bật phần tử đang hoạt động bằng khung màu vàng. Firefox màu xanh nhạt.

5. Hiển thị kết quả tiến độ

Nếu biểu mẫu web của bạn lớn và bao gồm nhiều trang (hoặc có nhiều bước), hãy đảm bảo rằng người dùng được thông báo liên tục về tiến trình của các hành động đang được thực hiện và họ có thể cần thêm bao nhiêu thời gian để hoàn thành. Điều này thường xảy ra trong trường hợp khảo sát (nghiên cứu) trực tuyến với nhiều câu hỏi hoặc trong quá trình đặt hàng tại cửa hàng trực tuyến.
Tất cả những gì bạn phải làm là viết “Bước 4 trên 5” hoặc đại loại như thế. Nếu người dùng tiếp tục nhấp vào nút “tiếp tục” mà không hiểu rõ bước cuối cùng sẽ diễn ra khi nào, họ sẽ ngừng điền biểu mẫu sớm hơn bạn mong đợi.

Thanh toán Amazon có 4 trang. Biểu mẫu này cho bạn biết hiện tại bạn đang ở đâu và còn bao nhiêu thời gian nữa cho đến khi hoàn thành.

Tất nhiên, giải pháp thay thế tốt hơn là rút ngắn biểu mẫu web của bạn - nếu điều này không thể thực hiện được thì ít nhất hãy cung cấp cho người dùng thông tin về mức độ họ sắp hoàn thành các hành động đang được thực hiện.

6. Định kỳ lưu dữ liệu biểu mẫu (bộ đệm)

Các biểu mẫu có nhiều trang hoặc nhiều bước thường có thể mắc lỗi. Để tránh mất dữ liệu, bạn cần triển khai cách lưu thông tin người dùng nhập cho mỗi phiên. Điều này làm tăng độ tin cậy và tỷ lệ phần trăm mà biểu mẫu sẽ được điền ngay cả sau khi người dùng rời khỏi trang (ví dụ: nhấp vào nút quay lại trong trình duyệt). Việc phải điền lại tất cả các trường của biểu mẫu có thể khiến người dùng rời đi.

7. Không sử dụng văn bản “Gửi” tiêu chuẩn (gửi)

Thay vì đặt nút biểu mẫu của bạn có tên là “Gửi”, hãy sử dụng văn bản nhắc nhở người dùng về hành động của họ. Ví dụ: “Đăng ký”, hoặc tốt hơn là cho người dùng biết về các lợi ích sau khi điền vào biểu mẫu.

Trên biểu mẫu đăng ký Basecamp, dòng chữ “Gửi” đã được thay thế bằng nội dung hữu ích hơn.

8. Nút “Hủy” khiến bạn chần chừ

Hãy tưởng tượng bạn đang mua một chiếc áo sơ mi mới trong cửa hàng và người bán hỏi bạn: “Bạn có thực sự muốn chiếc áo đặc biệt này không?” Bạn vẫn sẽ mua nó chứ? Rất có thể là không. Bạn có thể nghi ngờ, cho rằng người bán cho rằng chiếc áo đó không phù hợp.
Điều tương tự cũng xảy ra với các biểu mẫu web: việc sử dụng nút “hủy” có thể khiến người dùng của bạn phải suy nghĩ kỹ về những gì họ đang điền.

9. Hiển thị các trường người dùng ở định dạng chính xác

Nếu bạn yêu cầu người dùng cung cấp thông tin cụ thể - chẳng hạn như số điện thoại hoặc thẻ tín dụng - hãy cho họ biết bạn mong đợi điều gì. Nếu mật khẩu phải có số lượng ký tự nhất định hoặc phải chứa một bộ ký tự nhất định, hãy mô tả rõ ràng các yêu cầu này. Điều này làm giảm sự mơ hồ và tăng tốc quá trình điền.

Biểu mẫu đăng ký của Geico cung cấp hướng dẫn rõ ràng về định dạng của dữ liệu đầu vào.

10. Hình thức một cột là giải pháp tốt nhất

Theo nghiên cứu chuyển động của mắt từ cơ quan thiết kế trải nghiệm người dùng cxpartners, việc quét biểu mẫu từ dưới lên sẽ thích hợp hơn là quét từ trái sang phải. Điều này làm giảm số lượng chuyển động của mắt cần thiết để hoàn thành biểu mẫu.

Dạng cột đơn

Mẫu đăng ký của Backpack là mẫu một cột.

Biểu mẫu có nhiều cột