Trên trang này ↓
Nhân viên hỗ trợ nhập số điện thoại để mở hồ sơ khách hàng. Sales nhớ một phần tên công ty, còn quản lý muốn lọc các đơn chậm xử lý tại một chi nhánh. Cùng một yêu cầu tìm kiếm nhưng đầu vào và kết quả mong đợi khác nhau. Thiết kế phải bắt đầu từ công việc sau khi tìm thấy bản ghi.
Viết tình huống tìm kiếm từ công việc thực tế
Yêu cầu "tìm khách hàng" chưa đủ rõ. Đội cần ghi đầu vào, đối tượng cần mở và hành động tiếp theo. Nhân viên hỗ trợ có thể biết số điện thoại, sales có tên gần đúng, kế toán có mã đơn trên nội dung chuyển khoản.
Mỗi tình huống cần truy vấn mẫu, kết quả đúng và trường hợp dễ nhầm. Mã đơn phải khớp chính xác, còn tên khách hàng có thể chấp nhận khác dấu hoặc sai một ký tự. Đây cũng là đầu vào cụ thể cho dev và QA.
Phân biệt tìm kiếm, bộ lọc và điều hướng
Tìm kiếm
Tìm kiếm phù hợp khi người dùng có một mẩu thông tin nhưng chưa biết bản ghi ở đâu.
Bộ lọc
Bộ lọc thu hẹp tập đã biết theo trạng thái, người phụ trách, chi nhánh hoặc thời gian. Màn hình đơn hàng có thể tìm theo mã, tên, số điện thoại và dùng bộ lọc cho trạng thái thanh toán.
Quy trình thiết kế chức năng tìm kiếm cho MVP
Bước 1: Chọn các đối tượng cần tìm
Liệt kê khách hàng, đơn hàng, tài liệu hoặc công việc mà người dùng cần mở nhanh. Giữ phạm vi hẹp theo luồng chính của MVP.
Bước 2: Ghi truy vấn mẫu và kết quả đúng
Thu thập cách người dùng thực sự nhập: số điện thoại có khoảng trắng, mã có tiền tố, tên có hoặc không dấu. Ghi bản ghi phải xuất hiện cho từng truy vấn.
Bước 3: Chốt trường tìm và cách chuẩn hóa
Xác định trường được lập chỉ mục, cách xử lý chữ hoa, dấu tiếng Việt, khoảng trắng và ký tự đặc biệt.
Bước 4: Đặt quy tắc xếp hạng
Ưu tiên khớp chính xác với mã, email hoặc số điện thoại. Sau đó mới xét tên gần đúng, nội dung phụ, thời gian cập nhật hay trạng thái nghiệp vụ.
Bước 5: Áp dụng quyền và giới hạn dữ liệu
Lọc theo quyền trước khi trả kết quả, số lượng và gợi ý. Bản ghi bị hạn chế không được xuất hiện trong gợi ý.
Bước 6: Đo bằng bộ truy vấn cố định
Chạy lại cùng một tập truy vấn sau mỗi thay đổi. Đo vị trí của kết quả đúng, thời gian phản hồi và truy vấn không có kết quả.
Nếu sản phẩm có nhiều vai trò, hãy nối đặc tả tìm kiếm với thiết kế quyền truy cập. Hai người nhập cùng truy vấn có thể nhận tập kết quả khác nhau, nhưng mỗi kết quả đều phải đúng với phạm vi họ được xem.
Xếp kết quả theo khả năng hoàn thành công việc
Khi tìm bằng mã đơn đầy đủ, bản ghi khớp chính xác phải đứng đầu dù đã tạo từ lâu. Với tên khách hàng, hồ sơ đang hoạt động có thể ưu tiên hơn hồ sơ đã đóng nếu quy tắc được ghi rõ.
MVP chưa cần mô hình xếp hạng phức tạp. Một thứ tự dễ giải thích thường đủ: khớp chính xác, bắt đầu bằng từ khóa, chứa từ khóa, sau đó xét trạng thái. Khi không có kết quả, giao diện nên giữ truy vấn và cho biết bộ lọc đang áp dụng.
Không để tìm kiếm làm lộ dữ liệu bị giới hạn
Trường nhạy cảm chỉ được lập chỉ mục khi có nhu cầu và quyền tương ứng. Truy vấn đã lưu cần thời hạn vì có thể chứa số điện thoại, email hoặc mã hồ sơ. Xem thêm cách quản lý dữ liệu nhạy cảm.
Checklist nghiệm thu chức năng tìm kiếm
Kết quả
- Mã đầy đủ và thông tin định danh chính xác đưa đúng bản ghi lên đầu.
- Tên tiếng Việt có dấu, không dấu và khác chữ hoa vẫn cho kết quả theo đặc tả.
- Bộ lọc kết hợp với từ khóa không làm mất bản ghi hợp lệ.
- Trạng thái rỗng cho biết bộ lọc hiện tại và bước người dùng có thể thử.
Quyền và dữ liệu
- Kết quả, gợi ý và số lượng đều tuân theo quyền truy cập.
- Trường nhạy cảm không xuất hiện trong đoạn trích ngoài phạm vi cho phép.
- Truy vấn đã lưu có thời hạn và mục đích sử dụng rõ.
Hiệu năng và thay đổi
- Bộ truy vấn kiểm thử chạy lại được sau mỗi lần đổi dữ liệu hoặc thuật toán.
- Thời gian phản hồi được đo với lượng dữ liệu dự kiến của MVP.
- Khi chỉ mục cập nhật chậm, giao diện không khẳng định dữ liệu đã có ngay lập tức.
Khi nào chưa cần dịch vụ tìm kiếm riêng?
Với vài nghìn bản ghi, ít trường và truy vấn chủ yếu là mã hoặc tên, cơ sở dữ liệu hiện có thường đáp ứng được. Hãy ưu tiên đặc tả, chỉ mục, quyền và bộ kiểm thử trước khi thêm hạ tầng.
Dịch vụ tìm kiếm riêng phù hợp khi dữ liệu lớn, cần tìm gần đúng trên nhiều loại nội dung hoặc quy tắc xếp hạng đổi thường xuyên. Quyết định phải dựa trên truy vấn thật và phép đo.
Dịch vụ Product Development của Auranium có thể giúp chuyển nhu cầu vận hành thành đặc tả, bộ truy vấn kiểm thử và tiêu chí nghiệm thu cho dev, QA.
