Menu
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Đang tải...

Bài 27 — Form Design — Input Fields

Web Design Basics Bài 27/60

Mở đầu — vì sao bài này quan trọng

Hãy thành thật với nhau một chút: form là nơi mà người dùng phải làm việc nhiều nhất khi ghé thăm sản phẩm của bạn. Họ gõ tên, nhập số điện thoại, chọn ngày sinh, dán mã giảm giá, đặt mật khẩu. Mọi thao tác đó đều đòi hỏi sự tập trung và một chút kiên nhẫn. Và đây là sự thật phũ phàng: người dùng ghét điền form. Không ai mở app vì thích nhập liệu cả — họ điền form chỉ vì muốn đạt được thứ phía sau nó (đặt được vé, thanh toán xong đơn hàng, đăng ký xong tài khoản).

Điều đó có nghĩa là form chính là chiến trường sống còn về mặt chuyển đổi. Một ô input gây bối rối, một label đặt sai chỗ, một dòng helper text thiếu — bất kỳ chi tiết nhỏ nào cũng có thể khiến người dùng do dự, gõ sai, bực bội rồi bỏ ngang. Trong thương mại điện tử, mỗi bước form bị "rò rỉ" người dùng là tiền chảy ra khỏi túi doanh nghiệp theo đúng nghĩa đen.

Trong bài này, chúng ta tập trung vào viên gạch nhỏ nhất nhưng quan trọng nhất của mọi form: input field — ô nhập liệu. Bạn sẽ học cách cấu tạo (anatomy) một ô input đúng chuẩn: label, field, helper text, và cách sắp xếp chúng để người dùng nhập liệu nhanh, ít sai, ít nản. Đây không phải lý thuyết hàn lâm — đây là những nguyên tắc bạn sẽ áp dụng vào mọi dự án về sau. Còn các chủ đề như trạng thái lỗi (error state), validation real-time, hay focus state khi dùng bàn phím — chúng ta sẽ đào sâu ở các bài riêng phía sau. Hôm nay, hãy làm chủ giải phẫu của một ô input thật vững.

Khái niệm cốt lõi

Một ô input không phải chỉ là cái khung chữ nhật để người ta gõ vào. Nó là một cụm gồm nhiều thành phần phối hợp với nhau. Khi bạn hiểu từng thành phần làm gì, bạn sẽ không bao giờ thiết kế form một cách tùy hứng nữa.

Anatomy — Giải phẫu một ô input

Một input field hoàn chỉnh thường gồm năm thành phần, sắp theo thứ tự từ trên xuống:

  • Label (nhãn) — cho người dùng biết ô này dùng để nhập cái gì.
  • Input field (ô nhập) — vùng người dùng thực sự gõ vào.
  • Placeholder (chữ mờ gợi ý bên trong ô) — ví dụ minh họa định dạng, biến mất khi gõ.
  • Helper text (chữ hướng dẫn) — gợi ý thêm về format hoặc ràng buộc, đặt dưới ô.
  • Validation message (thông báo kiểm tra) — báo đúng/sai, sẽ học kỹ ở bài về error states.
Trong bài hôm nay ta tập trung vào ba thành phần đầu tiên cộng helper text, vì đây là bộ khung mà bạn dùng đi dùng lại hàng ngày.

Label — luôn luôn hiển thị, đừng bao giờ thay thế bằng placeholder

Đây là nguyên tắc quan trọng nhất của bài. Nhiều bạn mới học, thấy thiết kế trên Dribbble đẹp lung linh, liền bắt chước kiểu chỉ để mỗi placeholder mờ mờ bên trong ô ("Họ và tên", "Email...") mà bỏ luôn label phía trên. Nhìn thì gọn gàng, sang chảnh. Nhưng đó là một cái bẫy về trải nghiệm.

Vì sao? Vì placeholder biến mất ngay khi người dùng bắt đầu gõ. Hãy tưởng tượng một người đang điền form có 8 ô, đến ô thứ 5 thì khựng lại vì điện thoại reo. Họ quay lại, nhìn vào màn hình thấy một loạt ô đã có chữ — nhưng không nhớ ô nào là gì. Vì label thật chưa từng tồn tại, nó chỉ là placeholder đã bốc hơi. Người dùng phải xóa đi để xem gợi ý, hoặc đoán mò. Đây gọi là vấn đề "no anchor" — không có điểm neo.

Ngoài ra placeholder-only còn phá vỡ accessibility (trình đọc màn hình cho người khiếm thị nhiều khi không đọc placeholder như đọc label), và chữ placeholder thường có độ tương phản thấp nên khó đọc với người lớn tuổi hoặc người mắt kém.

Kết luận chắc nịch: Label luôn hiển thị, đặt phía trên ô input. Placeholder chỉ dùng để cho ví dụ định dạng, không bao giờ thay thế label.

Vị trí của label — trên, trái, hay nổi?

  • Top-aligned (label nằm trên ô): Đây là lựa chọn mặc định tốt nhất cho hầu hết trường hợp, đặc biệt là mobile. Mắt người đọc theo một đường thẳng đứng, label sát ô nên dễ liên kết, và form co giãn tốt trên màn hình hẹp. Nielsen Norman Group đã đo bằng eye-tracking: label top-aligned giúp điền form nhanh nhất.
  • Left-aligned (label nằm bên trái ô): Tiết kiệm chiều cao, hợp với form dài trên desktop (ví dụ trang cài đặt tài khoản). Nhưng tốn chiều ngang và gần như không dùng được trên mobile.
  • Floating label (label nổi): Label nằm trong ô lúc trống, rồi "trượt" lên trên khi người dùng gõ. Trông hiện đại nhưng dễ gây nhầm với trạng thái rỗng và cần làm rất cẩn thận. Người mới nên ưu tiên top-aligned trước.

Helper text — đặt gợi ý format đúng chỗ

Helper text là dòng chữ nhỏ, nhạt màu hơn, đặt ngay dưới ô input. Vai trò của nó là trả lời trước câu hỏi mà người dùng sắp thắc mắc: "Mật khẩu cần bao nhiêu ký tự?", "Ngày tháng nhập kiểu gì?", "Mã số thuế gồm mấy số?".

Điểm mấu chốt: helper text phải luôn hiển thị, không biến mất khi gõ (khác hẳn placeholder). Nhờ vậy người dùng vừa gõ vừa nhìn được quy tắc. Ví dụ ô mật khẩu để helper text "Tối thiểu 8 ký tự, có ít nhất 1 số" ngay từ đầu sẽ giảm rất nhiều lỗi so với việc để người ta gõ xong rồi mới báo đỏ "mật khẩu quá yếu".

Một ô input còn cần gì nữa?

  • Kiểu input phù hợp (input type): Trên web, dùng đúng type (email, tel, number, date...) để mobile bật đúng bàn phím. Người Việt nhập số điện thoại mà bàn phím hiện bàn phím số thay vì bàn phím chữ thì nhanh hơn rất nhiều.
  • Vùng chạm đủ lớn (touch target): Trên mobile, ô input nên cao tối thiểu khoảng 44–48px để ngón tay chạm trúng.
  • Tự động hoàn thành (autocomplete): Cho phép trình duyệt gợi ý điền sẵn tên, email, địa chỉ — tiết kiệm hàng giây quý giá.

Tình huống thực tế

Ví dụ 1 — Tiki và cái bẫy placeholder-only ở form thanh toán

Giả sử đội thiết kế của một sàn TMĐT lớn như Tiki làm lại trang nhập địa chỉ giao hàng. Phiên bản đầu, để cho "sạch", họ bỏ hết label, chỉ để placeholder bên trong: "Họ tên người nhận", "Số điện thoại", "Địa chỉ chi tiết", "Tỉnh/Thành phố". Nhìn trên Figma đẹp thật.

Khi đưa ra test với 12 người dùng thật ở Hà Nội và TP.HCM, vấn đề lộ ngay. Một bác hơn 50 tuổi điền tới ô "Địa chỉ chi tiết", gõ được nửa chừng thì có người gọi. Quay lại, bác nhìn vào ô đang có dòng "143 Nguyễn..." và ô bên cạnh có "0903..." nhưng không chắc ô nào là số điện thoại, ô nào là gì, vì gợi ý đã biến mất. Bác xóa thử một ô để xem placeholder hiện lại — và làm mất luôn dữ liệu đã gõ. Có 3/12 người gõ nhầm số điện thoại vào ô địa chỉ.

Bài học: Đội thiết kế chuyển sang label top-aligned luôn hiển thị, giữ placeholder chỉ để làm ví dụ định dạng ("VD: 0901 234 567"). Tỷ lệ điền sai ở ô địa chỉ giảm rõ rệt trong vòng test sau. Sự "gọn gàng" của placeholder-only đổi lấy sự bối rối — không đáng.

Ví dụ 2 — Ngân hàng số và ô "Số tài khoản" thiếu helper text

Một ngân hàng số kiểu Timo hoặc Cake làm tính năng chuyển tiền. Ô "Số tài khoản người nhận" ban đầu chỉ có label, không có helper text, không gợi ý gì. Vấn đề là số tài khoản ở Việt Nam dài ngắn khác nhau tùy ngân hàng (có ngân hàng 9 số, có ngân hàng 12–14 số), và người dùng hay băn khoăn "có cần gõ dấu cách không, có gõ luôn mã chi nhánh không".

Kết quả: tổng đài nhận rất nhiều cuộc gọi hỏi "em gõ số tài khoản kiểu gì", và một tỷ lệ giao dịch bị nhập thiếu/thừa số phải làm lại từ đầu.

Đội product thêm một dòng helper text ngay dưới ô: "Nhập liền không dấu cách. Số tài khoản gồm 9–14 chữ số tùy ngân hàng." Họ cũng đặt inputmode="numeric" để bật bàn phím số trên điện thoại. Lượng giao dịch phải nhập lại giảm hẳn, và cuộc gọi hỏi cách nhập gần như biến mất.

Bài học: Helper text không phải để trang trí. Mỗi khi bạn linh cảm "chỗ này người dùng sẽ phân vân", hãy trả lời trước bằng một dòng helper text. Một câu ngắn gọn đặt đúng chỗ rẻ hơn rất nhiều so với một đội tổng đài.

Ví dụ 3 — Form đăng ký của startup SaaS và chiếc bàn phím sai

Một startup SaaS Việt làm landing page đăng ký dùng thử. Form có 4 ô: Họ tên, Email, Số điện thoại, Tên công ty. Trên desktop chạy tốt. Nhưng hơn 60% lượt truy cập đến từ mobile, và ở đó tỷ lệ bỏ form cao bất thường.

Khi quay lại xem session replay, đội phát hiện: ô "Số điện thoại" dùng type="text", nên khi người dùng chạm vào, điện thoại bật bàn phím chữ. Người dùng phải tự bấm chuyển sang bàn phím số — một thao tác thừa, gây khó chịu. Tương tự, ô Email không bật sẵn ký tự "@".

Sửa lại: ô điện thoại dùng type="tel", ô email dùng type="email", bật autocomplete cho cả tên và email. Trên mobile, chạm vào ô điện thoại là hiện bàn phím số ngay. Trải nghiệm trơn tru hơn hẳn, tỷ lệ hoàn thành form trên mobile cải thiện đáng kể.

Bài học: Một input field tốt không chỉ đẹp về mặt thị giác — nó còn phải thông minh về mặt kỹ thuật. Chọn đúng input type là chi tiết nhỏ mà tác động cực lớn trên mobile, nơi đa số người Việt truy cập.

Hướng dẫn từng bước

Đây là quy trình bạn có thể áp dụng để thiết kế bất kỳ ô input nào.

Bước 1 — Xác định dữ liệu cần thu thập. Ô này lấy thông tin gì? Định dạng ra sao (chữ, số, ngày, email)? Có ràng buộc gì (độ dài, bắt buộc hay không)? Viết ra trước khi vẽ.

Bước 2 — Viết label rõ ràng, ngắn gọn. Dùng từ người dùng hiểu, không dùng thuật ngữ nội bộ. "Số điện thoại" tốt hơn "SĐT liên hệ chính"; "Mật khẩu" tốt hơn "Passphrase". Đánh dấu trường bắt buộc nhất quán (ví dụ dấu * đỏ, hoặc ghi "(không bắt buộc)" cho trường tùy chọn — chọn một cách và dùng xuyên suốt).

Bước 3 — Đặt label phía trên ô. Mặc định chọn top-aligned. Khoảng cách label–ô nhỏ (4–8px) để mắt liên kết chúng là một cụm; khoảng cách giữa các ô lớn hơn để tách bạch.

Bước 4 — Thiết kế ô input đủ rộng và đủ cao. Chiều rộng ô nên gợi ý độ dài dữ liệu: ô mã PIN 4 số thì ngắn, ô địa chỉ thì dài. Chiều cao tối thiểu 44–48px trên mobile.

Bước 5 — Thêm placeholder làm ví dụ định dạng (nếu cần). Chỉ dùng để minh họa: "VD: 0901 234 567". Tuyệt đối không nhét nội dung label vào placeholder.

Bước 6 — Thêm helper text cho mọi ràng buộc. Bất cứ chỗ nào người dùng có thể phân vân về format, độ dài, hay quy tắc — viết một dòng helper text luôn hiển thị bên dưới.

Bước 7 — Chọn đúng input type và bật autocomplete. email → type="email", điện thoại → type="tel", số → inputmode="numeric". Bật autocomplete cho tên, email, địa chỉ.

Bước 8 — Kiểm tra bằng "test 5 giây". Che label đi, nhìn ô input — bạn có còn đoán được nó là gì không? Nếu không, dữ liệu của bạn phụ thuộc vào label quá ít, hoặc placeholder đang gánh việc của label. Sửa lại.

Lỗi thường gặp & mẹo

Lỗi 1 — Placeholder-only (bỏ label). Đã nói nhiều ở trên, nhưng nhắc lại vì đây là lỗi phổ biến nhất. Đừng bao giờ để placeholder thay label.

Lỗi 2 — Placeholder quá giống dữ liệu thật. Nếu placeholder ghi "Nguyễn Văn A" mà không đủ nhạt màu, người dùng tưởng ô đã điền sẵn và bỏ qua. Placeholder phải nhạt rõ rệt và nên có chữ "VD:" để phân biệt.

Lỗi 3 — Nhồi quá nhiều thông tin vào helper text. Helper text là một câu gợi ý, không phải đoạn văn điều khoản. Nếu cần giải thích dài, dùng tooltip hoặc link "Tìm hiểu thêm".

Lỗi 4 — Label mơ hồ. "Tên" — tên gì, tên người nhận hay tên đăng nhập? "Mã" — mã gì? Label phải tự nó đủ nghĩa.

Lỗi 5 — Ô input quá nhỏ hoặc dồn sát nhau trên mobile. Ngón tay chạm trượt qua ô khác, gây bực bội. Luôn để khoảng cách thoáng và chiều cao đủ lớn.

Lỗi 6 — Bắt người dùng nhập đúng định dạng cứng nhắc. Ví dụ bắt buộc số điện thoại không được có dấu cách, nhưng người dùng quen gõ "0901 234 567". Tốt hơn là tự động chuẩn hóa dữ liệu phía sau, đừng bắt người dùng làm việc của máy.

Mẹo hay:

  • Một ý một dòng: mỗi ô input chỉ thu thập một thông tin. Đừng gộp "Họ và tên" với "Email" vào một ô.
  • Gom nhóm các ô liên quan (ví dụ địa chỉ) lại gần nhau bằng khoảng trắng, để form có nhịp điệu rõ ràng.
  • Với form dài, cân nhắc chia bước (multi-step) thay vì một trang dằng dặc — nhưng đó là chuyện của bài layout form nâng cao.
  • Ưu tiên trải nghiệm gõ một mạch: thứ tự ô hợp logic, cho phép nhấn Tab/Next để nhảy ô.

Bài tập thực hành

  • Tìm và sửa. Mở 3 website hoặc app Việt Nam bạn hay dùng (ví dụ một sàn TMĐT, một app ngân hàng, một form đăng ký sự kiện). Chụp lại 3 form. Với mỗi form, hãy chỉ ra: ô nào dùng placeholder-only, ô nào thiếu helper text, ô nào label mơ hồ. Viết phương án sửa cho từng lỗi.
  • Vẽ lại một ô input chuẩn. Trên giấy hoặc Figma, vẽ một ô "Mật khẩu" hoàn chỉnh gồm: label phía trên, ô input đủ cao, placeholder ví dụ, helper text "Tối thiểu 8 ký tự, có ít nhất 1 số". Chú thích từng thành phần và lý do bạn đặt nó ở đó.
  • Thiết kế form đăng ký tài khoản. Tạo form gồm 5 ô: Họ tên, Email, Số điện thoại, Mật khẩu, Tên công ty (không bắt buộc). Áp dụng đủ 8 bước trong phần hướng dẫn. Ghi rõ với mỗi ô bạn chọn input type nào và vì sao.
  • Thử nghiệm test 5 giây. Đưa form ở bài tập 3 cho một người bạn không làm thiết kế. Che hết label, hỏi họ đoán từng ô là gì. Ghi lại chỗ họ đoán sai và rút ra điều cần cải thiện.

Tóm tắt

Input field là viên gạch nhỏ nhất nhưng quyết định nhất của mọi form. Một ô input hoàn chỉnh gồm label, input field, placeholder và helper text — mỗi thành phần một vai trò.

Ba điều cốt lõi cần khắc cốt ghi tâm:

  • Label luôn hiển thị, đặt phía trên ô — không bao giờ dùng placeholder thay label. Placeholder biến mất khi gõ và để lại người dùng không có điểm neo.
  • Helper text trả lời trước mọi phân vân về format, luôn hiển thị bên dưới ô, ngắn gọn và rõ ràng.
  • Chọn đúng input type và bật autocomplete — chi tiết kỹ thuật nhỏ này tạo khác biệt lớn trên mobile, nơi đa số người Việt truy cập.
Form tốt không làm người dùng phải suy nghĩ. Khi bạn thiết kế từng ô input với sự tỉ mỉ này, bạn đang gỡ bỏ ma sát từng chút một — và mỗi chút ma sát được gỡ là thêm một người dùng đi tới cuối hành trình. Ở các bài tiếp theo, chúng ta sẽ xây tiếp lên nền móng này với nút bấm, trạng thái lỗi và validation. Nhưng nếu hôm nay bạn làm chủ giải phẫu của một ô input, bạn đã đi được một chặng rất xa rồi.