Một màn hình ứng dụng thường trông rất yên tĩnh. Vài nút bấm, một bức ảnh sản phẩm, một mức giá, một lời kêu gọi hành động. Nhưng để màn hình đó trở nên đơn giản, phía sau có thể là hàng chục câu hỏi chưa đơn giản chút nào.
Người dùng đang muốn mua hay chỉ đang khám phá? Họ đã hiểu cơ chế tương tác chưa? Nếu mạng chậm thì điều gì xảy ra? Nếu sản phẩm vừa hết hàng, thanh toán chưa hoàn tất hoặc người dùng muốn đổi trả, hệ thống sẽ dẫn họ đi đâu? Nhà bán và đội ngũ chăm sóc khách hàng sẽ nhìn thấy thông tin nào để xử lý cùng một tình huống?
Đó là lý do TIDO xây trải nghiệm người dùng không bắt đầu bằng việc chọn màu cho một nút bấm.
Chúng tôi bắt đầu từ hành vi, nỗi lo và kỳ vọng của những người sẽ tham gia vào giao dịch.
1. Ý tưởng đầu tiên không phải lúc nào cũng là lời giải
TIDO được hình thành từ mong muốn làm cho mua sắm trực tuyến thú vị hơn, thay vì chỉ lặp lại hành trình tìm kiếm – thêm vào giỏ – thanh toán. Hướng đi này mở ra nhiều ý tưởng về Shoppertainment, Interactive Commerce, gamification, nội dung và các cơ chế tạo thêm giá trị sau giao dịch.
Nhưng một ý tưởng hấp dẫn trên giấy chưa phải là một trải nghiệm tốt. Nếu người dùng phải đọc quá lâu mới hiểu mình đang làm gì, sự hứng thú sẽ biến thành do dự. Nếu yếu tố giải trí làm lu mờ thông tin sản phẩm, giao dịch có thể mất đi nền tảng quan trọng nhất là sự tin tưởng. Nếu một cơ chế tạo tương tác nhưng gây khó cho vận hành hoặc không đủ rõ về điều kiện, trải nghiệm đẹp ở phía trước sẽ tạo ra áp lực ở phía sau.
Vì vậy, mỗi ý tưởng cần đi qua một bước khó nhưng cần thiết: tách “điều nghe thú vị” khỏi “giá trị thực sự người dùng nhận được”.
Bước 1: Xác định khoảnh khắc cần được cải thiện
Thiết kế trải nghiệm thương mại điện tử dễ bị cuốn vào số lượng tính năng. TIDO cố gắng quay về những khoảnh khắc cụ thể hơn.
- Khi người dùng mở ứng dụng lần đầu, họ có hiểu TIDO là gì trong vài giây không?
- Khi xem một sản phẩm, họ có đủ thông tin để đưa ra quyết định không?
- Khi tham gia một trải nghiệm tương tác, quyền lợi và điều kiện có rõ ràng không?
- Khi thanh toán, họ có cảm thấy an toàn và kiểm soát được lựa chọn của mình không?
- Khi đơn hàng gặp vấn đề, họ có biết phải làm gì tiếp theo không?
- Khi quay lại, ứng dụng có cho họ một lý do ngoài khuyến mãi để tiếp tục khám phá không?
Những câu hỏi này tạo thành “xương sống” cho trải nghiệm. Tính năng chỉ được đặt vào sau khi biết nó phục vụ khoảnh khắc nào.
Bước 2: Nhìn cùng một hành trình từ nhiều phía
Người mua nhìn thấy một đơn hàng. Nhà bán nhìn thấy tồn kho, biên lợi nhuận, thời gian xử lý và nguy cơ hoàn trả. Đơn vị vận chuyển nhìn thấy địa chỉ, khối lượng, tuyến giao. Đội ngũ chăm sóc khách hàng nhìn thấy lịch sử tương tác và bằng chứng cần thiết để giải quyết vấn đề.
Nếu thiết kế chỉ theo góc nhìn người mua, một thao tác “rất tiện” có thể tạo ra hàng loạt việc thủ công cho nhà bán hoặc vận hành. Ngược lại, nếu chỉ tối ưu quy trình nội bộ, ứng dụng sẽ bắt người dùng đi qua những bước mà họ không hiểu vì sao cần thiết.
TIDO vì vậy thiết kế trên một hành trình nối liền nhiều vai trò. Mỗi điểm chạm được đặt cạnh câu hỏi: dữ liệu đi đâu, ai chịu trách nhiệm tiếp theo và điều gì sẽ xảy ra nếu luồng chuẩn bị đứt.
Thiết kế cả “happy path” lẫn lúc có sự cố
Trong bản thiết kế đầu tiên, mọi thứ thường diễn ra đẹp: sản phẩm còn hàng, thanh toán thành công, giao đúng hẹn, người mua hài lòng. Thực tế lại nằm nhiều ở những nhánh nhỏ hơn.
Một mã ưu đãi vừa hết hiệu lực. Hai người cùng mua sản phẩm còn một đơn vị. Người dùng thoát ứng dụng giữa bước thanh toán. Nhà bán thay đổi thời gian chuẩn bị hàng. Đơn giao không thành công nhưng trạng thái cập nhật chậm.
Thiết kế những tình huống này từ sớm giúp TIDO tránh biến đội ngũ chăm sóc khách hàng thành nơi “vá” những lỗ hổng của sản phẩm sau khi ra mắt.
Bước 3: Từ luồng trải nghiệm đến wireframe
Khi hành trình đã rõ, đội ngũ mới chuyển sang wireframe – bản khung giúp kiểm tra cấu trúc trước khi đầu tư vào hình ảnh hoàn chỉnh. Ở giai đoạn này, màu sắc chưa phải điều quan trọng nhất. Thứ cần nhìn là thứ tự thông tin, vị trí quyết định và số bước người dùng phải đi qua.
Một màn hình sản phẩm, chẳng hạn, không chỉ cần đẹp. Nó phải trả lời được các câu hỏi theo đúng thứ tự người mua thường đặt ra: đây là sản phẩm gì, có phù hợp không, ai bán, nguồn gốc thế nào, giá trị mình nhận được là gì, giao khi nào và nếu có vấn đề thì được bảo vệ ra sao.
Với các trải nghiệm tương tác, wireframe còn phải làm rõ ranh giới giữa nội dung, giao dịch và phần giá trị bổ sung. Người dùng không nên phải đoán đâu là thông tin bắt buộc, đâu là lựa chọn và đâu là kết quả có điều kiện.
Bước 4: Prototype để phát hiện điều đội ngũ đã quen mắt
Khi làm một sản phẩm đủ lâu, đội ngũ phát triển sẽ hiểu ứng dụng quá rõ. Đó vừa là lợi thế, vừa là điểm mù. Một biểu tượng có thể “rất dễ hiểu” với người đã nhìn nó hàng trăm lần nhưng hoàn toàn xa lạ với người dùng mới.
Prototype giúp mô phỏng trải nghiệm trước khi hệ thống được lập trình hoàn chỉnh. Thay vì hỏi “bạn có thích thiết kế này không?”, câu hỏi hữu ích hơn là giao một nhiệm vụ: hãy tìm một sản phẩm, hiểu quyền lợi, hoàn tất một bước hoặc xử lý một vấn đề. Nơi người thử dừng lại, bấm nhầm hoặc phải hỏi chính là nơi thiết kế cần nói rõ hơn.
Phản hồi không chỉ được ghi nhận theo số đông. Có những vướng mắc chỉ xuất hiện ở nhóm người ít quen công nghệ, ở nhà bán mới hoặc ở tình huống mạng yếu. Nếu TIDO muốn phục vụ thị trường Việt Nam rộng hơn một nhóm người dùng thành thạo, những phản hồi đó không thể bị xem là ngoại lệ.
Bước 5: Câu chữ cũng là một phần của sản phẩm
Trong thương mại điện tử, một câu chữ mơ hồ có thể tạo ra nhiều vấn đề hơn một nút bấm đặt sai vị trí. “Nhận ngay”, “có cơ hội”, “đã xác nhận”, “đang xử lý” hay “hoàn tất” đều mang theo kỳ vọng khác nhau.
TIDO coi UX Writing là một phần của thiết kế. Câu chữ cần ngắn nhưng không được cắt mất điều quan trọng. Giọng điệu có thể gần gũi nhưng không được làm nhẹ đi trách nhiệm. Với những nội dung liên quan đến tiền, điều kiện tham gia, dữ liệu cá nhân, đổi trả hoặc khiếu nại, sự rõ ràng luôn quan trọng hơn việc cố viết thật hấp dẫn.
Bước 6: Thiết kế phải gặp vận hành và pháp lý trước khi gặp người dùng
Một trải nghiệm không thể được duyệt chỉ vì “đẹp” hoặc “dễ dùng”. Trước khi đi xa hơn, TIDO cần kiểm tra khả năng vận hành, dữ liệu cần thu thập, cách giải quyết tranh chấp, trách nhiệm giữa các bên và mức độ phù hợp với khung pháp lý áp dụng.
Điều này đặc biệt quan trọng với marketplace có các cơ chế tương tác. Nếu quy tắc chương trình chưa được xác định, giao diện chưa thể viết đúng. Nếu cách đối soát chưa rõ, trạng thái đơn hàng chưa thể thiết kế hoàn chỉnh. Nếu quy trình kiểm duyệt nhà bán chưa chốt, dấu hiệu xác minh trên gian hàng chưa nên xuất hiện như một lời hứa.
Thiết kế, vì thế, là điểm gặp nhau của sản phẩm, công nghệ, pháp lý và vận hành chứ không phải công đoạn trang trí sau cùng.
Bước 7: Sau khi ra mắt, trải nghiệm mới bắt đầu được kiểm chứng
Không có bản thiết kế nào thay thế được dữ liệu sử dụng thật. TIDO cần quan sát không chỉ tỷ lệ bấm hoặc tỷ lệ hoàn tất giao dịch, mà cả những tín hiệu nhỏ hơn: người dùng quay lại vì điều gì, họ dừng ở đâu, câu hỏi nào lặp lại tại chăm sóc khách hàng, nhà bán mất nhiều thời gian nhất ở bước nào và trải nghiệm tương tác có giúp họ hiểu sản phẩm tốt hơn hay chỉ tạo thêm lượt chạm.
Mỗi dữ liệu cần được đọc trong bối cảnh. Tỷ lệ bấm cao chưa chắc là tốt nếu người dùng hiểu nhầm. Thời gian ở lại lâu chưa chắc là tích cực nếu họ đang loay hoay. Một màn hình ít tương tác có thể vẫn hoàn thành tốt nhiệm vụ nếu nó giúp người dùng ra quyết định nhanh và tự tin.
2. Kết luận: Trải nghiệm tốt là khi người dùng không phải nghĩ về thiết kế
TIDO muốn tạo ra một cách mua sắm thú vị hơn, nhưng sự thú vị chỉ có giá trị khi đặt trên nền tảng của rõ ràng, tin cậy và dễ sử dụng. Đích đến không phải là để người dùng trầm trồ rằng ứng dụng có nhiều hiệu ứng. Đích đến là họ hiểu mình đang làm gì, cảm thấy được tôn trọng và muốn quay lại vì trải nghiệm đáng thời gian.
Phía sau sự đơn giản đó là rất nhiều vòng lặp: hỏi, vẽ, thử, bỏ, sửa và kiểm tra lại. Đó là cách TIDO đưa một ý tưởng đi gần hơn tới một sản phẩm có thể dùng được trong đời sống thật.
Đọc thêm:
Vì sao xây một sàn thương mại điện tử không thể chỉ bắt đầu từ việc viết ứng dụng?
Những bài toán khó nhất khi xây một sàn TMĐT từ con số 0
