📌 Disclaimer:
The process is not a fixed recipe; it always adapts to the specific objectives and situations at hand.
Processes are designed to minimize errors and optimize effort, but they can sometimes hinder creativity.
0. Problem gathering
Chúng ta đã nghe rất nhiều về việc design là problem solving, nhưng problem ở đâu mà ra?
Theo mình thấy thì problem xuất phát từ 2 nguồn:
Từ những gì sản phẩm chưa có (đàng ngoài):
1. Quan sát user + những sáng kiến mới… Nếu công ty nhìn thấy giá trị của việc giải quyết problem đó >> nó sẽ biến thành
cơ hội
kinh doanh.
2. Quan sát đối thủ & thấy cần bắt kịp thị trường >> đảm bảo tính cạnh tranh. Note: một sai lầm hay thấy là mình quan sát đối thủ có gì & muốn làm theo nhưng lại không phân tích sâu, đừng quên mọi problem ta lựa chọn để giải quyết đều cần align với strategy, với value proposition (
xem thêm ở bài này)
.
Từ những gì sản phẩm đang có (đàng trong):
1. Qua quá trình tracking và quan sát, nhận phản hồi từ user >> ta sẽ phát hiện thêm được những problem mới, nó có thể liên quan đến việc improve hay enhance một khía cạnh nào đó.
2. Hoặc đôi khi chỉ nhầm phục vụ cho nội bộ doanh nghiệp như để đảm bảo về mặt security, privacy, legal… hoặc giảm tải sever, thay đổi resource, thay đổi strategy…
Note: khi gather một đóng các problem, ta sẽ cần một bước filter - đánh giá xem đâu là cái mình sẽ lựa chọn để giải quyết, ta gọi việc này là strategy - lựa chọn (
xem thêm bài này
).
1. Problem investigate
Sau khi đã chọn được vấn đề để giải quyết. Ở phase này, ta sẽ đi đào sâu thêm, collect thêm thông tin xoay quanh vấn đề đó
càng nhiều càng tốt,
các thông tin này nên được quan sát dưới góc độ rất raw (fact), là những gì mình thuần tuý quan sát được, chưa cần phải phân tích quá sâu.
Thông tin này giúp xác định rõ vấn đề để giải quyết ở bước 2.
Cách để investigate thêm thì sẽ có 2 nguồn: quantitative & qualitative data.
2. Problem definition (framing)
Là quá trình xác định và làm rõ bản chất của một vấn đề cụ thể nhằm hiểu sâu và toàn diện về nó. Sự xác định này nên cover được các khía cạnh sau:
bối cảnh, vấn đề, ảnh hưởng đến ai, ảnh hưởng ra sao & mục tiêu sau khi giải quyết vấn đề này là gì.
🤨 Lưu ý: khi định nghĩa vấn đề tránh đề cập đến giải pháp, định nghĩa
càng cụ thể càng tốt
, nếu được thì nên đi kèm dữ liệu hoặc minh chứng.
Ví dụ:
❌ Sai: "Chúng ta cần xây dựng một chatbot để cải thiện dịch vụ khách hàng."
✅ Đúng: "Thời gian phản hồi của đội ngũ hỗ trợ khách hàng hiện tại quá chậm (trung bình 48 giờ), dẫn đến giảm mức độ hài lòng của khách hàng xuống dưới 70%."
❌ Sai: "Hệ thống của chúng ta không hoạt động tốt."
✅ Đúng: "Hệ thống hiện gặp lỗi ở bước thanh toán, khiến 20% giao dịch bị hủy bỏ trong tháng qua."
❌ Sai: "Người dùng không thích ứng dụng của chúng ta."
✅ Đúng: "Tỷ lệ gỡ cài đặt ứng dụng tăng 30% trong vòng 1 tháng sau khi phát hành phiên bản mới."
Tactics để đào & phân tích vấn đề:
5whys:
để bạn hiểu sâu, tìm gốc rễ vấn đề.
Fishbone:
để bạn hiểu các yếu tố xung quanh tác động đến vấn đề.
Problem statement canvas:
để
có cái nhìn hệ thống xoay quanh vấn đề.
📌 Nhiệm vụ quan trọng là phân biệt “triệu chứng & căn bệnh”.
Vì có khi vấn đề đang gặp chỉ là do tác động hoặc là hệ quả của một vấn đề khác.
🤡
Độ rõ ràng vs assumption
Tuy nhiên trong quá trình define problem, sẽ có những lúc thông tin xoay quanh problem không rõ ràng, thiếu dẫn chứng, tồn tại nhiều
assumption
. Vậy mình research thêm như thế nào & bao nhiêu là đủ? Bạn có thể tham khảo matrix này của bên Dovetail.
3. Solution discovery & concept validation
Sau khi đã xác định được vấn đề, đây là lúc bạn sẽ phải làm buổi project kick-off để các bên cùng ngồi xuống thảo luận về problem, tìm ra các hướng solution mapping cho vấn đề đó, align với nhau về objective, expectation của project này là gì. (điều này cùng tuỳ tổ chức, có khi mọi solution đã được định hình thì mới có buổi kick-off).
Value first, solution later
Keep in mind, bản chất product là trao giá trị (
value & benefit
) cho người dùng, nên mọi sự suy nghĩ nên bắt đầu từ nó, đừng để mình bị rơi vô cái trap là chưa gì đã nhảy ngay đến solution.
📌 Tip: khi nghĩ về solution ta nên hình dung nó ở dạng “verb” trước, sau đó mới nghĩ đến “noun”.
Ví dụ: “User cần nội dung ngắn hơn” vs “User cần đọc sách một cách nhanh hơn”.
Thử nhìn xem 2 câu đó, một câu mô tả solution dưới dạng “noun” - “User cần nội dung ngắn hơn”, vô tình khiến cho idea bị giới hạn và đóng gói solution xoay quanh chữ “nội dung ngắn”. Còn câu dưới dạng “verb” - “user đọc một cách nhanh hơn” giúp ta focus hơn vào user need, vào JTBD của user, nên solution có thể là [nội dung ngắn bằng việc có summary] hoặc [dùng voice đọc dùm >> kèm tuỳ chỉnh speed],…
>> Dùng verb mở ra nhiều hướng tiếp cận hơn vì lúc đó chúng ta đang tập trung vào value.
Ideate
Khi đã có đủ thông tin về problem, hiểu mình đang cố trao đi value gì >> lúc này mới đẻ solution idea, mapping problems & solution. (cách gì? >>
xem thêm bài này về brainstorm
).
Risk evaluation
Khi đã brainstorm được một vài idea, ta rất hay tích cực hoá nó lên - thấy một bầu trời sáng lạn, nhưng đừng quên mình sẽ cần cân nhắc thêm các
risk
có thể xảy ra (trong sách “Inspire” của Marty Cagan có nhắc đến 4 loại risk sau):
1. Value risk
(whether customers will buy it or users will choose to use it) - Product Manager chịu trách nhiệm chính
2. Business viability risk
(whether this solution also works for the various aspects of our business) - Product Manager chịu trách nhiệm chính
3. Usability risk
(whether users can figure out how to use it) - Product Designer chịu trách nhiệm chính
4. Feasibility risk
(whether our engineers can build what we need with the time, skills and technology we have) - Product Lead Engineer chịu trách nhiệm chính
Có thể tham khảo thêm
bài này
để hình dung thêm.
Hypothesis
Một solution idea được form lên căn bản cũng
chỉ là những
phỏng đoán
, dù có apply bao nhiêu principle, research hay rationale rõ ràng thế nào đi nữa,… kết quả thực sự chỉ bắt đầu khi mình quăng nó ra thị trường, xem user thực tế trải nghiệm nó & tiếp nhận nó ra sao. Đây là một mindset cực kì quan trọng,
design is just an experiment
.
Để có thể đánh giá được độ hiệu quả của solution đó, ta cũng cần phải rõ ràng ý định / chủ đích solution mình đưa ra là gì >> có nghĩa là hiểu mình đang cố kiểm chứng điều gì, càng cụ thể càng tốt, ví dụ solution giúp giảm số lỗi xảy ra đi 10%, time on task giảm 20%, độ happiness tăng 15%…Đây là quá trình mình cần form lên hypothesis, thông qua những tín hiệu của user > ta biết được outcome của project này có đạt hay chưa.
Tuy nhiên phải biết các tiêu chí này có thể conflict với nhau, ví dụ: bạn muốn time on task nhanh hơn thì có khi việc để user tuỳ chỉnh nhiều sẽ không được đáp ứng >> hình dung được các trade off để lựa chọn solution.
4. Development
Sau khi đã form được solution, tiếp đến là quá trình design & build solution ấy, đây là lúc bắt đầu cần đến công việc của UX/UI…
Thường khi đã hòm hòm có được design concept nên involve thêm Dev/Engineer vào để check về độ khả thi, có technical constraints, có edge case hay dependencies nào cần aware trước không. (
xem thêm bài này
để nắm được chiếc hộp của một designer là gì)
Khi đã xong design & hand-off, nhiệm vụ của designer là tiếp tục follow up để support các bên ấy, đôi khi trong xuyên suốt quá trình build & UAT sẽ phát sinh thêm các edge case hoặc vướng thêm vài technical constraint, lúc này designer cần cân nhắc & adapt theo (các constraint nên minor, không ảnh hưởng đến solution concept hay main flow).
5. Validation & Roll out program
Khi bản build đã ready, đây là lúc mình sẽ release cho internal hoặc test xem có đúng với expectation chưa, liệu có phát sinh thêm vấn đề gì như: usability, độ tương thích, độ tải sever,... (để hiểu thêm, mình có thể tìm hiểu các term: alpha, closed beta, open beta).
Khi đã tự tin về chất lượng sau khi thử nghiệm thực tế, lúc này ta sẽ phải lên roll-out plan tiếp cận đến với user như thế nào, ví dụ ta có thể release cho 10% user (early access program) hoặc cho 1 user segment cụ thể trước, khi đạt được các tín hiệu mong muốn mới release rộng ra thêm.
Note: luôn cần chuẩn bị trước các kịch bản khi release để ứng phó kịp thời, ví dụ: lỡ traffic tăng đột biến thì sao, lỡ có lỗi xảy ra thì sao, lỡ có một tính hiệu xấu ảnh hưởng đến branding thì sao,…
Trong quá trình này mình cũng cần định hình những data cần tracking để có thêm thông tin, dữ kiện phục vụ cho việc measure tính năng, trả lời các hypothesis trước đó, hoặc làm cơ sở cho đợt improve ở các phase sau.
6. Retro
Đây là phase mình hào hứng nhất.
Sau khi feature đã ra mắt được 1 thời gian, dựa theo những feedback & data log, mình sẽ đánh giá được outcome của dự án, từ đó cả team xem learn được các bài học gì, liệu nó có đúng như những expectation mình đã đề ra, liệu có những issue/incident nào mình cần aware thêm, liệu có một insight gì đó thú vị…
Những thông tin này không những giúp ích cho việc cải thiện feature này mà còn là các insight/bài học phục vụ cho các feature khác ở tương lai.
So what
Mình biết bài này khá là dàiiiiiii. Đọc đến đây rồi mong bạn rút ra được gì đó, còn riêng mình thì rút ra được vài điểm sau quá trình tìm hiểu về process này.
1. Mặc dù đây là tổng quan process chung và gần như hoàn chỉnh của product development, nhưng mình có thể linh hoạt cắt bớt giai đoạn tuỳ thuộc vào bối cảnh thời điểm đó. Ví dụ: có khi ta không cần phải đánh giá nghiên cứu problem quá sâu, nếu đối thủ ngoài kia đã có một solution chứng minh được giá trị của nó, ta có thể tham khảo & điều chỉnh cho phù hợp với product của mình (nói nôm na là clone giải pháp đó); hoặc đôi khi ta chỉ cần làm ra một solution ít tốn effort (no code, low code, hoặc prototype, fake door…) để test xem hiệu ứng thị trường thế nào, từ đó bổ sung nhanh cho việc đánh giá vấn đề.
2. Việc hiểu được bức tranh lớn cũng giúp ta có sự đánh giá khách quan hơn, để khi có bắt gặp issue gì đó bạn có thể phân tích xem vấn đề nó nằm ở đâu, ví dụ: nó có thể nằm ở mặt development (UX, usability không tốt) hay nằm ở mặt solution (no value), hay nằm ở mặt tiếp cận thị trường chưa phù hợp (roll-out program). Biết ở đây không phải để quy trách nhiệm cho nhau, mà để biết đường đào ra đúng vấn đề và tìm giải pháp ứng phó phù hợp.
Reference
Related Item
