Bỏ qua điều hướng
Blog

Form RFQ nhiều bước: giữ dữ liệu và chỉ rõ tiến trình

Khi nào nên chia form RFQ thành nhiều bước; cách giữ dữ liệu khi quay lại, báo lỗi và kiểm thử bàn phím, thời hạn, bước tùy chọn trước khi bàn giao.

Chia sẻFacebookLinkedInZalo
RFQ nhiều bước: giữ dữ liệu và chỉ lỗi đúng bước
Nội dung bài viết

Form RFQ nhiều bước chỉ có ích khi người gửi hiểu mình đang ở đâu và không phải nhập lại dữ liệu mỗi lần quay về sửa. Chia một biểu mẫu dài thành nhiều màn hình không tự làm yêu cầu báo giá rõ hơn. Cần thiết kế cả tiến trình, thông báo lỗi, dữ liệu đang nhập và trạng thái gửi cuối.

Đây là hướng dẫn lập yêu cầu và kiểm thử website. Bài viết không xác nhận một công cụ Onter hiện có đã hỗ trợ lưu nháp, khôi phục phiên hoặc các chức năng được nêu dưới đây.

Khi nào nên chia form thành nhiều bước?

Có thể cân nhắc khi yêu cầu gồm các nhóm thông tin khác nhau, có nhánh tùy chọn hoặc cần xem lại trước khi gửi. Một form ngắn chỉ hỏi sản phẩm và thông tin liên hệ có thể thuận tiện hơn trên một trang. W3C WAI về biểu mẫu nhiều trang khuyến nghị nhóm bước theo logic, thông báo tiến trình và giúp người dùng nhận biết phần tùy chọn.

Trước khi chia màn hình, loại bỏ trường không cần cho lần trao đổi đầu. Yêu cầu báo giá chưa phải đơn đặt hàng: người gửi cần biết gửi xong sẽ nhận xác nhận hay được liên hệ làm rõ, thay vì thấy thông báo có thể bị hiểu là đã chốt giá.

Ví dụ luồng RFQ ba nhóm thông tin

  1. Nhu cầu: chọn nhóm sản phẩm hoặc mô tả bài toán.
  2. Yêu cầu kỹ thuật: nhập thông số cần thiết và chọn phần bổ sung nếu phù hợp.
  3. Liên hệ và xem lại: kiểm tra nội dung, hiểu mục đích xử lý thông tin rồi gửi.

Đây là ví dụ thiết kế, không phải cấu hình bắt buộc cho mọi ngành. Với RFQ gia công, tham khảo riêng các trường và file yêu cầu gia công cơ khí; bài đó xử lý nội dung kỹ thuật, còn bài này tập trung việc chuyển bước và sửa thông tin.

Minh họa RFQ ba nhóm thông tin, giữ dữ liệu khi quay lại và báo lỗi đúng bước
Minh họa nguyên tắc đề xuất; không phải screenshot hay chức năng đã được nghiệm thu của Onter.

Tiến trình phải đọc được, không chỉ nhìn được

Thông báo “Bước 2 trên 3: yêu cầu kỹ thuật” nên xuất hiện ở tiêu đề hoặc heading phù hợp. Đánh dấu bước hiện tại bằng chữ hoặc cấu trúc có thể đọc được; đừng chỉ đổi màu. Với luồng có nhánh, tránh hiển thị số bước cố định nếu một lựa chọn có thể thêm màn hình.

Nút “Quay lại” và “Tiếp tục” cần nói rõ tác dụng. Người dùng bàn phím phải đến được các nút và nhận biết vùng nhập hiện tại. Nếu cho phép mở lại bước đã hoàn thành, dữ liệu ở bước đang nhập cần được giữ theo thiết kế đã thống nhất.

Giữ dữ liệu là yêu cầu cần chứng minh

Phân biệt giữ giá trị khi đổi bước trong cùng phiên với lưu nháp để quay lại ngày khác. Hai việc này khác về nơi lưu, thời hạn và quyền truy cập. Không ghi “đã lưu” nếu mới giữ tạm trên giao diện. Nếu hệ thống có giới hạn thời gian, cần thông báo và cách xử lý phù hợp trước khi người gửi mất công nhập lại.

Với file tải lên, quay lại bước không được mặc nhiên coi là file còn hợp lệ. Kiểm tra trạng thái file và thông báo khi phải tải lại. Các yêu cầu bảo mật file cần được thẩm định riêng, không được suy ra từ việc nút chuyển bước hoạt động.

Ma trận kiểm thử trước khi bàn giao

Các tình huống kiểm thử form RFQ nhiều bước
Thao tác Điều cần quan sát Không được kết luận sớm
Tiếp tục rồi quay lại Giá trị hợp lệ còn nguyên; lựa chọn nhánh được giữ Chưa chứng minh lưu nháp qua phiên
Một trường sai Thông báo gắn đúng trường; phần hợp lệ không bị xóa Màu đỏ chưa đủ là thông báo có thể tiếp cận
Bỏ qua bước tùy chọn Tiến trình và màn xem lại phản ánh đúng lựa chọn Không biến trường tùy chọn thành bắt buộc ngầm
Hết phiên hoặc mất mạng Thông báo đúng trạng thái, hướng dẫn phục hồi Không báo gửi thành công khi chưa có xác nhận
Gửi và tải lại trang Nhận diện yêu cầu đã gửi; kiểm tra trùng theo thiết kế backend Giao diện không chứng minh đã ghi nhận trong hệ thống

W3C WAI về thông báo biểu mẫu hướng dẫn mô tả lỗi rõ và giúp người dùng tìm trường cần sửa. Hãy kiểm tra bằng bàn phím trên mobile lẫn desktop, thay vì chỉ chụp màn hình trạng thái đẹp.

Góc nhìn biên tập của Onter

Đội ngũ Onter xem số bước là hệ quả của bài toán, không phải mục tiêu thiết kế. Một form ba bước có khả năng quay lại và báo lỗi rõ có thể phù hợp với yêu cầu kỹ thuật dài; một form ngắn thường không cần thêm bước. Chỉ nghiệm thu từng chức năng khi có quan sát tương ứng, nhất là lưu nháp và ghi nhận yêu cầu cuối.

Nếu đang chuẩn bị thiết kế website, hãy đưa danh sách trường, các nhánh và tình huống lỗi vào brief. Có thể dùng công cụ tạo form thu lead hiện có để xem phạm vi được công bố của công cụ; đừng mặc định nó là hệ thống RFQ nhiều bước theo bản thiết kế này.

Tài khoản Onter

Đăng nhập rồi tiếp tục việc đang làm.

Mở trang đăng nhập riêng nếu trình duyệt chưa hiển thị biểu mẫu.

Contact Me on Zalo