Research lúc nào và như thế nào trong quá trình thiết kế sản phẩm? (Phần 2)
Như vậy ở phần 1
Mình đã có nói về các cách đặt câu hỏi cũng như lựa chọn phương pháp research phù hợp, vậy thì câu hỏi cuối cùng chúng ta cần đặt ra là:
Liệu đã có giải pháp nào trên thị trường? Giải pháp đó đủ tốt chưa? Tại sao chúng ta phải thiết kế lại?
Tại sao câu hỏi này lại quan trọng?
Việc áp dụng đúng câu hỏi trên đôi khi sẽ giúp chúng ta tiết kiệm được rất nhiều thời gian lẫn chi phí khi thực hiện 1 dự án. Việc tìm hiểu các dự án đang có trên thị trường sẽ giúp chúng ta có được các thông tin rất có ích như sau:
Tại sao đối thủ lại làm theo cách A, B, hay C? Có nguyên nhân nào đằng sau?
Người dùng của sản phẩm đối thủ đang mong chờ (expect) gì từ các sản phẩm tương tự?
Có điểm nào đối thủ làm chưa tốt mà chúng ta có thể làm tốt hơn? → từ đó thu hút người dùng hơn
Đôi khi, chỉ bằng việc trả lời các câu hỏi này cũng đã phần nào đưa ra giải pháp và hướng đi cho thiết kế mà không cần phải thực hiện User Research. Vì vậy, mặc dù mình đặt câu hỏi này ở dưới cùng của tiến trình suy nghĩ, trong thực tế, đôi khi chúng ta sẽ thực hiện bước này trước cả User Research
Tất cả những việc trên được gọi là Secondary Research hay thông dụng hơn là Desk Research
Desk Research mang lại lợi ích gì?
Giảm bớt áp lực và khối lượng của UX Research (bottle neck)
Tuỳ vào môi trường sản phẩm mà bạn đang làm việc, tuy nhiên ở Việt Nam có thể thấy đa số là môi trường các sản phẩm cần tốc độ hoàn thiện cao, cần được đưa ra thị trường sớm, thì việc áp dụng một cách máy móc các bước User Research xong rồi mới design sẽ tạo nên nút thắt cổ chai trong toàn bộ quy trình phát triển sản phẩm. Ở đây vì số lượng research quá nhiều, mà designer hay PM phải chờ đợi kết quả rồi mới tiến hành các bước kế tiếp được, sẽ dẫn đến các mâu thuẫn giữa UX và PM. Các PM hay PO sẽ có tâm lý bỏ qua UX research để đẩy tốc độ nhanh hơn, mà thậm chí các UXR trong hoàn cảnh bị ép tiến độ cũng sẽ khó deliver được report có chất lượng cao.
Vì vậy, như đã nói ở bên trên, desk research có thể giúp chúng ta giảm tải quy trình research, trả lời một số câu hỏi quan trọng mà vẫn đảm bảo chất lượng của design, miễn là chúng ta thực hiện desk research một cách đúng đắn.
Dễ dàng hơn trọng việc “manage expectation” của stakeholders
Desk research là một công cụ cực kỳ hữu ích để đưa ra design solution theo ý muốn của designer. Khi bắt đầu công việc UX Design, bạn sẽ thấy mình dễ rơi vào rất nhiều tình huống mà trong đó bạn phải đấu tranh, tranh luận về một giải pháp nào đó. Thông thường xoay quanh chuyện thế nào là tốt cho người dùng, có thuộc design pattern không? Và hàng trăm ngàn lý do khác. Điều đáng lưu ý là, chưa chắc các giải pháp bạn đưa ra là hợp lý, đủ thuyết phục với người nghe. Vì vậy mà họ sẽ phản bác lại các giải pháp của bạn.
Để giúp việc đưa ra giải pháp hợp lý và “make sense” hơn. Bạn cần phải có desk research. Mục đích chính là tư duy phân tích đối thủ phải dựa trên các tiêu chí sau:
Tại sao họ làm thế? Họ muốn gì?
Pros and Cons; Risks and Opportunities: Lợi và hại, rủi ro cũng như cơ hội từ các giải pháp của đối thủ
Chúng ta có thể làm gì?
Khi trình bày câu chuyện thiết kế của bạn bằng việc diễn giải 3 ý trên từ đầu, thì các giải pháp kế tiếp thông thường sẽ rất hợp lý, thuyết phục hơn đối với người nghe, từ đây họ có thể đưa thêm nhiều ý kiến bổ sung, bạn sẽ thấy rằng buổi thuyết trình design trở nên rất vui và thú vị.
Wait...
Ah, thế nhưng mà desk research không chỉ đơn thuần là Competitor Research, tìm hiểu đối thủ. Để phục vụ cho việc manage expectation của stakeholders. Thì bạn cần phải hiểu, stakeholder họ expect cái gì mới được. Vì vậy desk research còn bao gồm cả internal interview. Tìm hiểu xem business cần gì, muốn gì. Marketing cần gì? Sale cần gì? Tại sao họ muốn thực hiện dự án này? Họ có phải là Business sponsor cho dự án này không? Các câu hỏi này bổ sung thêm cho background mà objectives của dự án mà mình đã nói ở phần 1
GIẢI NGHĨA:
Business Sponsor: thông thường bất cứ dự án, tính năng nào dù là được thực hiện bởi team product, nhưng vẫn luôn gắn kết với một số chỉ số kinh doanh nhất định. Cuối cùng thì, mỗi tính năng phải đóng góp vào sự phát triển của sản phẩm, và nó được hiện thực hoá bởi một KPI cho 1 department nào đó, không chỉ là product. Department đó chính là Business sponsor của dự án. Đôi khi các chi phí research sẽ được trả bởi chính business sponsor này. Hiểu Business Sponsor của bạn chính là hiểu vì sao bạn phải làm dự án này.
Thực hiện desk research
Stakeholder Interview
Lưu ý: tuỳ vào từng dự án cụ thể, vào từng tình huống cụ thể mà bạn có thể thực hiện hoặc không thực hiện bước này. Chi tiết mình sẽ giải thích bên dưới:
Bạn nên tìm hiểu đúng những người đang tham gia dự án, ngoài team sản phẩm, thì còn team nào đang chịu KPI của dự án. Xác định những người đó và lên một danh sách các câu hỏi mà bạn cảm thấy còn mập mờ chưa rõ. Có thể follow theo một số câu hỏi sau đây, lưu ý là thông thường luôn có một buổi Project Kickoff hoặc là có 1 chuỗi các meeting trước đó đã từng thảo luận về dự án mà có thể bạn chưa được tham gia hoặc đã tham gia mà chưa được dịp đặt câu hỏi, thì đây chính là lúc để thực hiện.
Anh chị có thể miêu tả cụ thể mục tiêu cuối cùng của dự án? (tăng giảm chỉ số gì? Đạt được gì?)
Người dùng mà anh chị nghĩ nên nhắm đến? (nếu có)
Các đối thủ cạnh tranh mà anh chị nghĩ đáng quan tâm trên thị trường?
Có những việc, dự án gì đã thực hiện rồi mà tôi cần tham khảo trước? Có những việc gì cần phải làm từ đầu?
Có những e ngại gì khác không?
Ngoài ra, bạn cũng nên tìm hiểu thêm một số khía cạnh sau đây:
Mọi người có hoàn toàn đồng ý với mục tiêu của dự án không? Liệu có mâu thuẫn về KPI giữa các department không? Lưu ý rằng điều này rất hay xảy ra, và một khi đã xảy ra thì vai trò UX và Product Design của bạn lúc này sẽ khác đi rất nhiều và bạn cần phải làm rất nhiều công việc khó khăn hơn khi rơi vào tình huống này. Mình sẽ chia sẻ cụ thể hơn ở các bài viết sau
Các stakeholder nhìn nhận vai trò của họ trong dự án này như thế nào? (có tiếng nói cực kỳ quan trọng hay đóng góp thực hiện dự án?)
Sau khi đã có đủ thông tin, bạn có thể book meeting 1-1 hoặc meeting toàn bộ stakeholder, tuỳ thuộc vào khả năng thực hiện interview cũng như tính nhạy cảm của các department. Nếu bạn chưa có đủ kỹ năng hay tiếng nói cần thiết để thực hiện meeting như vậy (đôi khi cần phải interview những level cao trong cty), bạn có thể nhờ sự giúp đỡ của leader, hoặc PM.
Competitor Analysis
Đây mới là phần quan trọng nhất mà mình muốn nhắc đến, Competitor Analysis: nghiên cứu đối thủ trên thị trường
Đối với dự án có Quy mô lớn
Quy mô của Competitor Analysis lớn hay nhỏ, phụ thuộc vào vấn đề bạn đang giải quyết, thời điểm bạn thực hiện design.
Ví dụ khi bạn bắt đầu 1 dự án từ đầu, thì quy mô của competitor analysis bạn cần thực hiện là khá lớn. Đầu tiên bạn cần phải tìm hiểu thật kỹ từng đối thủ, dựa trên các yếu tố sau:
Liệt kê cụ thể từng tính năng mà họ đang có
USP: unique selling point, tìm ra điểm mấu chốt làm cho sản phẩm của họ thành công, tức là mang tới giá trị lớn nhất cho user
Đối tượng sử dụng chính (user) của đối thủ là ai, hãy cố gắng profiling user của đối thủ theo giới tính, độ tuổi, nơi sinh sống làm việc, nghề nghiệp, thu nhập...
Khi đã tìm hiểu 1 loạt các competitor, bạn hãy cố gắng liệt kê các tính năng quan trọng mà các đối thủ có, lập thành 1 bảng như sau:
Sau khi liệt kê, hãy nhóm các nhóm tính năng đại diện cho 1 value mà sản phẩm đang deliver và lập thành bảng đồ thị Quadrant Diagram, trong đó bạn lựa chọn 2 cặp nhóm tính năng có 2 tính chất hoặc giá trị với người dùng đối lập nhau, và vẽ thành đồ thị như ví dụ bên dưới
Đây là 1 bảng đơn giản phân tích về các đối thủ trong lĩnh vực ...bán pizza
Qua đó bạn có thể thấy rằng chúng ta sẽ nhóm ra 2 nhóm giá trị là “giá cả” và “đế bánh dày hay mỏng”. Trong đó bạn đặt vào các cửa hàng pizza có những giá trị tương ứng, cuối cùng, chúng ta chỉ cần tìm hiểu xem liệu sản phẩm của công ty chúng ta có thể nằm ở đâu trong diagram này?
Việc sản phẩm hay tính năng chúng ta sắp thiết kế nằm ở đâu so với đối thủ phụ thuộc rất nhiều vào mục đích, mong muốn cuối cùng của business. Các stakeholder muốn tạo nên 1 sản phẩm đột phá khác hẳn với các đối thủ, hay muốn target 1 nhóm người dùng cụ thể thuộc nhóm sản phẩm của đối thủ nào.
Bằng cách phân tích sử dụng quadrant diagram, bạn và stakeholder sẽ có cái nhìn rất cụ thể về vị trí mong muốn của sản phẩm mà mình sắp design so với các đối thủ hiện tại. Từ đó giúp bạn tập trung vào vấn đề và mong muốn mình muốn giải quyết. Hơn là chạy theo rất nhiều đối thủ mà ko rõ đâu là tốt cho sản phẩm của mình
Tìm hiểu thêm về quadrant diagram tại đây nhé:
http://www.howtomakesenseofanymess.com/chapter/3/page/52/4-quadrant-diagram/
Phân tính theo user flow hoặc UI của từng tính năng
Một cách làm cực kỳ phổ biến và dễ làm, đó là phân tích chính UI, design của competitor, step by step và tìm ra điều mình nên cũng như ko nên làm. Cách làm này đòi hỏi bạn nên dùng 2 bước phân tính
so sánh
và chỉ ra Risk (Cons) và Opportunity (Pros)
Ví dụ bên dưới là khi mình làm desk research về cách apply voucher của 1 số ứng dụng giao đồ ăn:
Lưu ý với cách làm này là chúng ta nên tìm hiểu cả những competitor ở thị trường chính mà sản phẩm chúng ta đang hoạt động và competitor ở những thị trường khác để thấy rõ sự khác biệt giữa các thị trường, qua đó rút ra được tại sao các competitor lại làm như thế này hoặc khác.
Trend research
Cách làm phổ biến thứ 3 phục vụ cho việc tìm idea, new product đó là tìm hiểu trend của các sản phẩm ở các thị trường láng giềng, thị trường có đặc thù giống thị trường chính của chúng ta.
Một ví dụ về Trend research mà team UXR ở Zalo thực hiện nghiên cứu một số ứng dụng ở Trung Quốc:
Tìm các report có sẵn về market
Cách làm phổ biến thứ 3 đó là đi tìm các report đã có về market, việc này đòi hỏi sự may mắn và chịu khó, tuy nhiên thỉnh thoảng bạn sẽ có được một vài insight hữu ích về thị trường mà không cần phải thực hiện Market research, việc này giúp tiết kiệm chi phí cũng như kickstart dự án nhanh hơn
Trải nghiệm và thực tế từ desk research
Dĩ nhiên là, nếu có thực tế thì sẽ giúp các bạn hình dung rõ hơn về vai trò của desk research, mình xin chia sẻ một case study về cách mình dùng desk research để hoàn thành 1 dự án nhỏ ở BAEMIN. Dĩ nhiên là đây chỉ là 1 ví dụ trong 1 trường hợp cụ thể để giúp các bạn hình dung rằng đôi khi chỉ cần thực hiện desk research sẽ giúp các bạn hoàn thành dự án nhanh mà vẫn đạt được 1 số hiệu quả mong muốn. Dĩ nhiên bạn vẫn cần phải theo dõi sát sao các chỉ số của dự án sau khi release, kiểm tra xem có vấn đề bất thường gì cần phải interview hoặc test lại sau khi đã hoàn thành hay không. Lúc này bạn có thể dùng các phương pháp Research như ở phần một.