Làm thế nào để thiết kế giải pháp cho vấn đề của khách hàng?

Vì vậy, thiết kế giải pháp cho khách hàng là quá trình chuyển đổi từ vấn đề đã được xác thực thành một phương án có khả năng tạo ra kết quả mong muốn trong những điều kiện thực tế của khách hàng. Quá trình này đòi hỏi phải hiểu vấn đề, tìm nguyên nhân, xác định kết quả cần đạt, thiết kế cơ chế tạo ra kết quả và kiểm chứng các giả định trước khi đầu tư lớn vào triển khai.

Điểm khó nhất thường không nằm ở việc nghĩ ra giải pháp. Điểm khó nằm ở việc bảo đảm rằng doanh nghiệp đang giải quyết đúng vấn đề, cho đúng khách hàng, bằng đúng cơ chế và với mức độ phức tạp cần thiết.

Bắt đầu bằng việc xác định đúng vấn đề của khách hàng

Sai lầm phổ biến khi thiết kế giải pháp là bắt đầu bằng câu hỏi: “Chúng ta nên làm sản phẩm gì?” hoặc “Nên bổ sung tính năng nào?”. Những câu hỏi này khiến tư duy nhanh chóng chuyển sang phía giải pháp trước khi vấn đề được hiểu đầy đủ.

Điểm xuất phát phù hợp hơn là xác định khoảng cách giữa trạng thái hiện tại của khách hàng và trạng thái họ muốn đạt được.

Có thể mô tả một vấn đề theo logic:

Trạng thái hiện tại → trở ngại → hậu quả → trạng thái mong muốn

Chẳng hạn, một doanh nghiệp có thể nói rằng họ “cần phần mềm quản lý đơn hàng”. Đây mới là yêu cầu về giải pháp, chưa phải vấn đề.

Khi đi sâu hơn, vấn đề thực tế có thể là:

·         Nhân viên đang nhập cùng một đơn hàng vào nhiều hệ thống

·         Thông tin giữa bán hàng và kho thường không đồng bộ

·         Nhân viên phải kiểm tra thủ công trước khi xác nhận đơn

·         Việc xử lý chậm khiến khách hàng phải chờ lâu

Nếu chỉ tiếp nhận yêu cầu ban đầu, doanh nghiệp có thể xây thêm một phần mềm nhưng vẫn giữ nguyên các điểm nghẽn trong quy trình. Nếu xác định đúng vấn đề, phạm vi giải pháp có thể hoàn toàn khác.

Phân biệt biểu hiện với vấn đề gốc

Khách hàng thường mô tả thứ họ nhìn thấy rõ nhất, không nhất thiết là nguyên nhân tạo ra vấn đề.

Ví dụ, “nhân viên xử lý đơn hàng chậm” là một biểu hiện. Nguyên nhân có thể nằm ở quy trình phê duyệt, dữ liệu phân tán, thiếu thông tin, hệ thống khó sử dụng hoặc nhiều bước công việc không tạo giá trị.

Do đó, khi khám phá vấn đề cần liên tục kiểm tra ba lớp:

Hiện tượng: Điều gì đang xảy ra?

Nguyên nhân: Điều gì khiến hiện tượng đó xảy ra?

Hệ quả: Nếu vấn đề tiếp tục tồn tại, khách hàng chịu ảnh hưởng như thế nào?

Một giải pháp chỉ xử lý hiện tượng thường tạo cải thiện tạm thời. Giải pháp tác động đúng nguyên nhân mới có khả năng tạo ra thay đổi bền vững.

Xác thực bằng hành vi và bằng chứng thực tế

Không nên xem một phát biểu đơn lẻ của khách hàng là bằng chứng đủ mạnh.

Cần đối chiếu lời nói với những gì đang thực sự diễn ra: quy trình hiện tại, cách khách hàng xử lý tình huống, dữ liệu vận hành, phản hồi lặp lại, giải pháp tạm thời họ đang sử dụng và hậu quả khi vấn đề xảy ra.

Một vấn đề đáng ưu tiên thường có nhiều tín hiệu cùng xuất hiện: xảy ra thường xuyên, tạo hậu quả đáng kể, khách hàng đã tìm cách khắc phục và vẫn chưa có phương án đủ tốt.

Chuyển vấn đề thành yêu cầu thiết kế rõ ràng

Sau khi hiểu vấn đề, bước tiếp theo không phải lập tức lựa chọn giải pháp. Cần chuyển vấn đề thành một tập hợp yêu cầu cho biết giải pháp phải tạo ra điều gì.

Đây là bước quan trọng vì cùng một vấn đề có thể có nhiều cách giải quyết khác nhau.

Thay vì đặt yêu cầu dưới dạng tính năng như “phải có dashboard theo dõi đơn hàng”, hãy chuyển thành kết quả cần đạt:

“Người phụ trách phải nhận biết được trạng thái của một đơn hàng đủ nhanh để xử lý ngoại lệ trước khi ảnh hưởng tới khách hàng.”

Cách diễn đạt này mở ra nhiều phương án hơn. Dashboard chỉ là một khả năng; cảnh báo tự động, thay đổi luồng xử lý hoặc đồng bộ dữ liệu cũng có thể giải quyết cùng nhu cầu.

Xác định kết quả mà khách hàng cần đạt

Mỗi vấn đề nên được liên kết với một kết quả cụ thể.

Có thể xem xét bốn câu hỏi:

1.    Khách hàng muốn thay đổi điều gì

2.    Điều gì cần xảy ra để họ xem vấn đề là đã được giải quyết

3.    Kết quả đó được quan sát hoặc đo lường bằng cách nào

4.    Những điều kiện nào không được phép bị đánh đổi

Ví dụ, giảm thời gian xử lý sẽ không phải giải pháp tốt nếu tốc độ tăng lên nhưng tỷ lệ sai sót cũng tăng đáng kể.

Do đó, yêu cầu thiết kế cần bao gồm cả kết quả mong muốn và ràng buộc.

Phân biệt nhu cầu bắt buộc và mong muốn bổ sung

Trong quá trình trao đổi, khách hàng thường đưa ra nhiều yêu cầu với mức độ quan trọng khác nhau. Nếu mọi yêu cầu đều được đưa vào giải pháp, phạm vi sẽ nhanh chóng phình to.

Nên phân biệt:

·         Điều kiện bắt buộc để vấn đề được giải quyết

·         Điều kiện giúp giải pháp dễ sử dụng hoặc hiệu quả hơn

·         Mong muốn bổ sung nhưng không ảnh hưởng trực tiếp đến kết quả chính

Sự phân biệt này giúp tập trung nguồn lực vào phần tạo giá trị lớn nhất và tránh thiết kế một giải pháp quá phức tạp so với vấn đề.

Thiết kế cơ chế tạo ra kết quả cho khách hàng

Một giải pháp không nên được đánh giá chỉ qua danh sách tính năng. Quan trọng hơn là giải thích được tại sao giải pháp đó có thể tạo ra kết quả mong muốn.

Đó chính là cơ chế của giải pháp.

Nếu vấn đề là thời gian phản hồi khách hàng quá dài, thêm một chatbot chưa chắc giải quyết được vấn đề. Cần biết thời gian bị mất ở đâu.

Nếu phần lớn thời gian bị tiêu tốn vì nhân viên phải tìm thông tin từ nhiều nguồn, cơ chế cần tác động vào khả năng truy xuất thông tin. Nếu nguyên nhân là yêu cầu phải qua nhiều cấp phê duyệt, cơ chế lại nằm ở việc thay đổi quyền ra quyết định hoặc quy trình.

Vì vậy, logic thiết kế nên đi theo chuỗi:

Nguyên nhân → can thiệp → thay đổi hành vi hoặc quy trình → kết quả

Thiết kế từ nguyên nhân thay vì từ tính năng

Giả sử một doanh nghiệp gặp tình trạng khách hàng thường xuyên gọi để hỏi trạng thái giao hàng.

Có ít nhất ba nguyên nhân khác nhau:

·         Khách hàng không có nơi xem trạng thái

·         Trạng thái có nhưng thông tin cập nhật chậm

·         Thông tin đầy đủ nhưng khách hàng không hiểu ý nghĩa

Ba nguyên nhân này đòi hỏi ba loại can thiệp khác nhau. Nếu mặc định rằng “cần thêm trang theo dõi đơn hàng”, giải pháp chỉ phù hợp với trường hợp thứ nhất.

Đây là lý do việc xác định cơ chế quan trọng hơn việc nhanh chóng nghĩ ra tính năng.

Tìm nhiều phương án trước khi lựa chọn

Khi đã hiểu cơ chế cần tác động, nên tạo nhiều phương án thay vì chỉ phát triển ý tưởng đầu tiên.

Các phương án có thể khác nhau về:

·         Mức độ thay đổi quy trình

·         Mức độ sử dụng công nghệ

·         Mức độ tự động hóa

·         Chi phí triển khai

·         Khả năng tích hợp với hệ thống hiện tại

·         Mức độ thay đổi hành vi của người sử dụng

Việc so sánh nhiều phương án giúp tránh hiện tượng “yêu giải pháp”, tức là đội ngũ quá gắn bó với một ý tưởng trước khi biết nó có phải lựa chọn phù hợp nhất hay không.

Đánh giá giải pháp bằng giá trị, khả thi và ràng buộc

Một ý tưởng có vẻ hấp dẫn chưa đủ để trở thành giải pháp phù hợp. Nó cần vượt qua nhiều điều kiện cùng lúc.

Trước hết là giá trị: giải pháp có tạo ra thay đổi mà khách hàng thực sự quan tâm hay không?

Tiếp theo là khả năng sử dụng: khách hàng có thể đưa giải pháp vào công việc thực tế mà không tạo thêm gánh nặng quá lớn hay không?

Sau đó là khả thi: doanh nghiệp có đủ năng lực kỹ thuật, dữ liệu, quy trình và nguồn lực để triển khai hay không?

Cuối cùng là tính bền vững: giá trị tạo ra có đủ lớn so với chi phí vận hành, bảo trì và thay đổi tổ chức hay không?

Giá trị không đồng nghĩa với nhiều chức năng

Một giải pháp nhiều chức năng hơn không mặc nhiên có giá trị cao hơn.

Mỗi chức năng mới đồng thời tạo thêm chi phí phát triển, đào tạo, vận hành và độ phức tạp cho người dùng. Nếu chức năng không đóng góp rõ ràng vào kết quả khách hàng cần đạt, nó có thể làm chất lượng tổng thể của giải pháp giảm xuống.

Một nguyên tắc hữu ích là yêu cầu mỗi thành phần của giải pháp trả lời được câu hỏi:

“Thành phần này tác động vào nguyên nhân nào và tạo ra kết quả gì?”

Nếu không thể xác lập mối liên hệ đó, cần xem lại lý do tồn tại của thành phần.

Kiểm tra các ràng buộc thực tế

Giải pháp luôn tồn tại trong một môi trường cụ thể.

Một phương án về mặt lý thuyết rất tốt vẫn có thể thất bại nếu đòi hỏi dữ liệu mà khách hàng không có, thay đổi quy trình mà tổ chức không thể thực hiện hoặc tạo thêm thao tác khiến người dùng không chấp nhận.

Vì vậy, cần đánh giá ít nhất các ràng buộc liên quan đến con người, quy trình, dữ liệu, công nghệ, thời gian và nguồn lực.

Ràng buộc không chỉ là thứ cản trở thiết kế. Chúng còn giúp xác định hình dạng thực tế của một giải pháp có thể triển khai.

Tạo phiên bản nhỏ nhất để kiểm chứng giả định quan trọng

Thiết kế trên giấy không thể chứng minh đầy đủ rằng giải pháp sẽ hoạt động trong thực tế. Sau khi có phương án, cần biến các giả định quan trọng thành những thứ có thể kiểm chứng.

Không nhất thiết phải xây dựng toàn bộ giải pháp ngay lập tức.

Có thể sử dụng bản phác thảo quy trình, prototype, mô phỏng, dịch vụ thử nghiệm thủ công hoặc phiên bản giới hạn cho một nhóm khách hàng. Hình thức kiểm chứng phụ thuộc vào điều cần học.

Kiểm chứng rủi ro lớn trước

Các giả định không có mức độ rủi ro giống nhau.

Ví dụ, một giải pháp có thể dựa trên những giả định rằng:

·         Khách hàng thực sự coi vấn đề này là quan trọng

·         Người dùng sẽ thay đổi cách làm hiện tại

·         Dữ liệu cần thiết có thể thu thập

·         Cơ chế đề xuất có thể tạo ra kết quả

·         Khách hàng chấp nhận mức độ phức tạp của giải pháp

Nếu giả định đầu tiên sai, việc tối ưu giao diện gần như không có ý nghĩa.

Do đó, thứ tự thử nghiệm nên dựa trên mức độ bất định và hậu quả khi giả định sai, không dựa trên phần nào dễ xây dựng nhất.

Đo kết quả thay vì chỉ hỏi cảm nhận

Phản hồi như “tôi thích ý tưởng này” hoặc “giao diện khá đẹp” có giá trị hạn chế khi mục tiêu là xác minh khả năng giải quyết vấn đề.

Bằng chứng mạnh hơn đến từ hành vi và kết quả.

Nếu giải pháp nhằm làm quy trình nhanh hơn, hãy quan sát thời gian hoàn thành. Nếu nhằm giảm lỗi, hãy quan sát số lỗi. Nếu nhằm giúp người dùng tự xử lý, hãy quan sát họ có hoàn thành nhiệm vụ mà không cần hỗ trợ hay không.

Điều cần chứng minh không phải là khách hàng thích giải pháp, mà là giải pháp tạo ra thay đổi mong muốn trong bối cảnh sử dụng thực tế.

Hoàn thiện giải pháp bằng vòng lặp học hỏi

Thiết kế giải pháp không phải một chuỗi tuyến tính kết thúc ngay khi có prototype. Trong thực tế, mỗi lần thử nghiệm lại tạo ra thông tin mới về vấn đề, hành vi người dùng và giới hạn của phương án.

Quá trình thường diễn ra theo vòng lặp:

Hiểu vấn đề → hình thành giả định → thiết kế phương án → kiểm chứng → học hỏi → điều chỉnh

Nếu bằng chứng cho thấy phương án không đạt kết quả, cần xác định lỗi nằm ở đâu.

Có thể vấn đề đã được hiểu sai. Có thể nguyên nhân đúng nhưng cơ chế can thiệp chưa phù hợp. Cũng có thể cơ chế đúng nhưng điều kiện triển khai không đáp ứng.

Việc phân biệt những trường hợp này giúp đội ngũ tránh phản ứng bằng cách đơn giản là “thêm tính năng”.

Dùng tiêu chí quyết định trước khi thử nghiệm

Một thử nghiệm sẽ khó tạo ra quyết định nếu đội ngũ chỉ xem kết quả sau khi nó xảy ra rồi mới xác định thế nào là thành công.

Trước khi kiểm chứng, cần thống nhất:

·         Giả định nào đang được kiểm tra

·         Bằng chứng nào được xem là đủ mạnh

·         Kết quả nào khiến phương án được tiếp tục

·         Kết quả nào yêu cầu điều chỉnh

·         Kết quả nào cho thấy cần loại bỏ phương án

Cách làm này giảm nguy cơ diễn giải dữ liệu theo hướng bảo vệ ý tưởng ban đầu.

Biết khi nào không nên xây thêm

Một trong những năng lực quan trọng của thiết kế giải pháp là nhận ra khi nào giải pháp đã đủ để tạo ra kết quả.

Nếu giá trị cốt lõi đã được tạo ra, bổ sung thêm chức năng chỉ vì “có thể làm được” thường làm tăng chi phí và độ phức tạp nhanh hơn mức tăng giá trị.

Ngược lại, nếu kết quả cốt lõi chưa được chứng minh, mở rộng phạm vi cũng không giải quyết được điểm yếu cơ bản.

Giải pháp tốt vì vậy không phải phương án chứa nhiều thứ nhất, mà là phương án sử dụng một tập hợp can thiệp đủ để tạo ra thay đổi cần thiết với mức độ phức tạp hợp lý.

Một quy trình thực hành để thiết kế giải pháp cho khách hàng

Toàn bộ quá trình có thể được vận hành như một chuỗi quyết định liên kết với nhau.

Bước 1: Mô tả vấn đề bằng trạng thái hiện tại và trạng thái mong muốn

Không bắt đầu bằng tên sản phẩm hoặc tính năng.

Hãy mô tả khách hàng đang cố hoàn thành việc gì, điều gì đang ngăn cản họ và kết quả nào họ muốn đạt được.

Một mô tả vấn đề tốt phải đủ cụ thể để có thể kiểm chứng bằng quan sát hoặc dữ liệu.

Bước 2: Tìm nguyên nhân tạo ra vấn đề

Đi sâu vào quy trình, hành vi, dữ liệu và điều kiện thực tế.

Không coi biểu hiện đầu tiên là nguyên nhân cuối cùng. Tìm bằng chứng cho thấy yếu tố được xác định thực sự có quan hệ với vấn đề.

Bước 3: Xác định tiêu chí thành công

Chuyển nhu cầu thành kết quả quan sát được.

Xác định cả điều phải cải thiện và những thứ không được phép xấu đi. Đây sẽ là cơ sở để đánh giá các phương án sau này.

Bước 4: Xác định cơ chế cần tác động

Trả lời rõ giải pháp phải thay đổi điều gì để tạo ra kết quả.

Nếu chưa giải thích được chuỗi nguyên nhân → can thiệp → kết quả, chưa nên đi quá sâu vào thiết kế tính năng.

Bước 5: Tạo và so sánh nhiều phương án

Đánh giá từng phương án theo giá trị, khả năng sử dụng, khả thi và ràng buộc.

Ưu tiên phương án giải quyết được phần quan trọng nhất của vấn đề với mức độ phức tạp thấp nhất có thể.

Bước 6: Kiểm chứng giả định quan trọng

Tạo phiên bản đủ nhỏ để kiểm tra rủi ro lớn nhất.

Đo hành vi và kết quả thực tế thay vì chỉ dựa vào mức độ yêu thích của người tham gia thử nghiệm.

Bước 7: Học hỏi và điều chỉnh

So sánh bằng chứng thu được với tiêu chí đã đặt trước.

Giữ lại phần được chứng minh, điều chỉnh phần chưa đạt và loại bỏ các thành phần không tạo giá trị.

Chu trình được lặp lại cho đến khi có đủ bằng chứng cho thấy giải pháp tạo ra kết quả mong muốn trong điều kiện sử dụng thực tế.

Thiết kế giải pháp cho khách hàng về bản chất là một quá trình giảm dần sự bất định. Ban đầu, doanh nghiệp chưa chắc mình đã hiểu đúng vấn đề. Sau đó chưa chắc đã hiểu đúng nguyên nhân, chưa chắc cơ chế đề xuất sẽ hoạt động và cũng chưa chắc khách hàng có thể sử dụng giải pháp trong môi trường thực tế.

Một quy trình tốt không cố gắng loại bỏ sự bất định bằng suy đoán. Nó biến từng giả định quan trọng thành câu hỏi có thể kiểm chứng.

Vì thế, điểm xuất phát không nên là “chúng ta có thể xây gì?”, mà là “khách hàng cần thay đổi kết quả nào, điều gì đang ngăn họ đạt được kết quả đó và bằng chứng nào cho thấy phương án của chúng ta thực sự giải quyết được nguyên nhân?”

Khi ba câu hỏi này được trả lời bằng dữ liệu, hành vi và thử nghiệm thực tế, giải pháp sẽ có cơ sở vững chắc hơn để tạo ra giá trị thay vì chỉ trở thành một tập hợp tính năng.