Trên trang này ↓
Người dùng đang nhập một hồ sơ khách hàng dài trong CRM. Họ đổi tab để kiểm tra mã số thuế, quay lại và thấy trạng thái “Đã lưu”. Vài giây sau, kết nối mạng chập chờn. Trên màn hình vẫn còn dữ liệu mới, nhưng máy chủ chỉ nhận được một phần. Nếu đóng trình duyệt lúc này, người dùng không biết nội dung nào sẽ còn lại khi mở lại hồ sơ.
Thêm bộ đếm thời gian rồi gửi biểu mẫu sau mỗi vài giây chưa giải quyết được vấn đề. Đội sản phẩm phải xác định đơn vị lưu, các trạng thái hiển thị, vai trò của bộ nhớ cục bộ và máy chủ, cách phát hiện chỉnh sửa đồng thời, đường phục hồi khi lỗi và bộ test cho từng thời điểm hỏng.
Chọn đơn vị lưu theo ranh giới dữ liệu
“Lưu toàn bộ trang” nghe đơn giản nhưng thường làm một lỗi nhỏ chặn mọi thay đổi. Ngược lại, lưu từng phím gõ tạo quá nhiều yêu cầu và khiến các trường phụ thuộc nhau đi vào máy chủ ở trạng thái chưa hoàn chỉnh. Đơn vị lưu nên khớp với cách dữ liệu được kiểm tra và sử dụng.
Lưu theo trường
Phù hợp với trường độc lập như ghi chú ngắn hoặc nhãn nội bộ. Hệ thống vẫn cần xử lý trường hợp người dùng rời ô trước khi yêu cầu hoàn tất.
Lưu theo nhóm trường
Dùng khi nhiều giá trị phải hợp lệ cùng nhau, chẳng hạn loại hợp đồng, ngày bắt đầu và ngày kết thúc. Một nhóm được xác nhận hoặc từ chối như một đơn vị.
Lưu theo bản ghi
Hợp lý với form ngắn có quy tắc chung. Người dùng cần thấy rõ trường nào làm lần lưu thất bại và dữ liệu chưa gửi có còn được giữ hay không.
Lưu theo bản nháp quy trình
Áp dụng cho báo giá, bài viết hoặc hồ sơ nhiều bước. Bản nháp có thể thiếu dữ liệu, còn hành động gửi duyệt phải kiểm tra đầy đủ điều kiện nghiệp vụ.
Đội cần tách “lưu bản nháp” khỏi “hoàn tất” hoặc “gửi duyệt”. Bản nháp cho phép tiếp tục sau, nhưng không được tự chuyển trạng thái công việc. Nếu một lần lưu có thể kích hoạt email, thay đổi giá hoặc tạo tác vụ cho người khác, đó đã là hành động nghiệp vụ và cần điều kiện riêng.
Mô hình hóa trạng thái lưu trên giao diện
Một nhãn “Đã lưu” không đủ nếu ứng dụng chưa nhận xác nhận từ máy chủ. Trạng thái hiển thị phải phản ánh điều hệ thống thực sự biết. Có thể bắt đầu với sáu trạng thái dưới đây rồi điều chỉnh theo loại sản phẩm.
| Trạng thái | Ý nghĩa | Hành vi cần có |
|---|---|---|
| Chưa thay đổi | Dữ liệu trên màn hình khớp phiên bản đã xác nhận. | Không gửi yêu cầu lưu. |
| Có thay đổi | Người dùng đã sửa nhưng chưa bắt đầu gửi. | Giữ dữ liệu, lên lịch lưu và cho phép lưu thủ công nếu cần. |
| Đang lưu | Yêu cầu đã được gửi, chưa có kết quả cuối. | Không ghi “Đã lưu”; tiếp tục nhận chỉnh sửa mới vào lượt kế tiếp. |
| Đã xác nhận | Máy chủ chấp nhận đúng phiên bản và trả kết quả. | Hiển thị thời điểm hoặc trạng thái xác nhận phù hợp. |
| Lưu lỗi | Yêu cầu bị từ chối hoặc không thể hoàn tất. | Giữ nội dung đang nhập, nêu nguyên nhân có thể xử lý và cho phép thử lại. |
| Xung đột | Máy chủ có phiên bản mới hơn phiên người dùng đang sửa. | Dừng ghi đè, cho xem khác biệt hoặc chọn phiên bản theo quy tắc đã định. |
Trạng thái lưu là một phần của trạng thái công việc, nhưng hai loại không đồng nghĩa. Một báo giá có thể ở trạng thái “đang soạn” trong nhiều ngày, trong khi mỗi lần chỉnh sửa bên trong đã được lưu thành công. Cách lập điều kiện vào và ra trong bài thiết kế trạng thái công việc trước khi tự động hóa giúp đội tránh gộp hai lớp này.
Quy trình từ thay đổi trên màn hình đến xác nhận của máy chủ
Bước 1: Cập nhật giao diện ngay
Ghi thay đổi vào trạng thái của form và đánh dấu đơn vị lưu tương ứng là có thay đổi. Không chờ phản hồi mạng mới hiển thị ký tự người dùng vừa nhập.
Bước 2: Giữ bản nháp cục bộ theo chính sách
Nếu sản phẩm cần phục hồi sau khi đóng tab, lưu bản nháp cùng ID người dùng, ID bản ghi, phiên bản gốc và thời điểm. Không để dữ liệu của tài khoản trước xuất hiện cho tài khoản đăng nhập sau trên cùng thiết bị.
Bước 3: Gom thay đổi hợp lệ
Chỉ gửi khi người dùng tạm dừng nhập hoặc rời nhóm trường, tùy đặc tả. Kiểm tra nhẹ trên trình duyệt giúp phản hồi sớm, nhưng máy chủ vẫn phải kiểm tra lại.
Bước 4: Gửi kèm phiên bản
Yêu cầu lưu mang theo phiên bản mà người dùng bắt đầu chỉnh sửa. Máy chủ dùng giá trị này để nhận ra bản ghi đã đổi ở nơi khác trước khi chấp nhận ghi.
Bước 5: Xác nhận đúng lượt lưu
Phản hồi cần chứa phiên bản mới hoặc mã của lượt lưu. Nếu phản hồi cũ đến sau phản hồi mới, giao diện không được đưa trạng thái và dữ liệu trở về kết quả trước đó.
Bước 6: Dọn bản nháp hoặc giữ để phục hồi
Chỉ xóa phần cục bộ sau khi máy chủ xác nhận đúng nội dung. Nếu lỗi, giữ dữ liệu chưa đồng bộ và chỉ rõ bước tiếp theo cho người dùng.
Phân biệt lưu cục bộ và lưu trên máy chủ
Lưu cục bộ giúp chống mất nội dung khi trình duyệt đóng hoặc mạng tạm ngắt. Nó không chứng minh dữ liệu đã có trên máy chủ, đã qua kiểm tra quyền hoặc đã sẵn sàng cho đồng nghiệp sử dụng. Giao diện nên dùng thông báo khác nhau, chẳng hạn “Đã giữ trên thiết bị, chưa đồng bộ” và “Đã lưu trên hệ thống”.
Với dữ liệu nhạy cảm, đội phải quyết định có được phép lưu trong trình duyệt hay không. Nếu có, cần giới hạn thời gian, phạm vi tài khoản và cơ chế xóa khi đăng xuất. Nếu không, sản phẩm vẫn phải cảnh báo rõ nguy cơ mất dữ liệu khi người dùng rời trang trong lúc chưa đồng bộ.
Xử lý chỉnh sửa đồng thời và xung đột
Xung đột xảy ra khi hai tab, hai thiết bị hoặc hai người mở cùng một bản ghi rồi cùng sửa. Ghi đè theo phản hồi đến sau có thể làm mất dữ liệu mà không ai nhận ra. Cách đơn giản là kiểm tra phiên bản: mỗi lần đọc nhận một số phiên bản, mỗi lần ghi phải nộp lại số đó. Nếu máy chủ đã có phiên bản mới hơn, yêu cầu bị từ chối với trạng thái xung đột.
Không phải sản phẩm nào cũng cần hợp nhất theo từng ký tự. Với ghi chú tự do, đội có thể hiển thị hai phiên bản để người dùng sao chép phần cần giữ. Với các trường độc lập, máy chủ có thể chấp nhận thay đổi nếu chúng không chạm cùng trường. Với báo giá hoặc cấu hình có quan hệ chặt, nên yêu cầu tải phiên bản mới rồi xác nhận lại.
Thiết kế phục hồi thay vì chỉ hiện thông báo lỗi
Thông báo “Có lỗi xảy ra” không cho người dùng biết nội dung còn ở đâu. Khi lưu thất bại, giao diện cần giữ nguyên phần vừa nhập, đánh dấu đơn vị chưa đồng bộ và cung cấp hành động phù hợp: thử lại, đăng nhập lại, sao chép nội dung, tải phiên bản mới hoặc xử lý xung đột.
Đội cũng phải xác định thời điểm dừng tự động. Nếu máy chủ từ chối cùng một yêu cầu vì dữ liệu sai, lặp lại không giúp ích. Nếu phản hồi không rõ yêu cầu đã được xử lý hay chưa, hệ thống cần tra cứu trạng thái trước khi gửi lại. Với phụ thuộc bên ngoài, hãy giữ công việc ở trạng thái an toàn và chuyển sang đường xử lý khác thay vì báo thành công sớm.
Checklist nghiệm thu lưu nháp và tự động lưu
Luồng lưu và phục hồi
- Chỉnh sửa trong lúc một lượt lưu đang chạy được đưa vào lượt kế tiếp, không bị bỏ qua.
- Phản hồi cũ đến muộn không ghi đè dữ liệu hoặc trạng thái mới hơn.
- Mất mạng rồi có mạng lại giữ được nội dung và đồng bộ theo đúng thứ tự.
- Đóng rồi mở lại tab phục hồi đúng bản nháp cho đúng tài khoản và bản ghi.
- Lỗi xác thực, thiếu quyền và dữ liệu không hợp lệ có thông báo cùng hành động khác nhau.
Xung đột và ranh giới nghiệp vụ
- Hai tab sửa cùng trường tạo xung đột thay vì âm thầm ghi đè.
- Hai người sửa các trường độc lập được xử lý theo quy tắc đã ghi trong đặc tả.
- Lưu bản nháp không tự gửi duyệt, gửi email hoặc chuyển trạng thái công việc.
- Đăng xuất xóa hoặc vô hiệu hóa dữ liệu cục bộ theo chính sách đã chọn.
- Nút rời trang và trạng thái lưu phản ánh đúng việc máy chủ đã xác nhận hay chưa.
Bộ test nên gây lỗi tại nhiều thời điểm: trước khi gửi, sau khi máy chủ nhận nhưng trước khi phản hồi, giữa hai lượt lưu và ngay khi người dùng đóng tab. Chuẩn bị dữ liệu, quyền và kết quả mong đợi theo hướng dẫn chuẩn bị dữ liệu và tiêu chí nghiệm thu sản phẩm sẽ giúp product, engineering và QA kiểm tra cùng một hành vi.
Bắt đầu bằng bản đồ trạng thái và đường lỗi
Trước khi chọn khoảng chờ tự động lưu, hãy vẽ luồng từ lúc người dùng sửa đến khi máy chủ xác nhận. Đánh dấu nội dung đang nằm trên màn hình, trong bộ nhớ cục bộ hay trên máy chủ ở từng bước. Sau đó đặt lỗi vào mỗi điểm chuyển và ghi hành vi phục hồi mong đợi.
Khi đơn vị lưu, trạng thái, phiên bản và đường phục hồi đã rõ, quyết định kỹ thuật trở nên cụ thể hơn. Đội biết yêu cầu nào có thể gom, dữ liệu nào cần giữ cục bộ và lúc nào phải dừng để người dùng xử lý. Dịch vụ Product Development của Auranium có thể hỗ trợ chuyển luồng này thành đặc tả, test case và phạm vi triển khai phù hợp với sản phẩm.
