Mình hay thắc mắc sao đọc nhiều process, case study… nó nói về câu chuyện đi qua nghiên cứu người dùng, nghiên cứu đối thủ, xây persona, phân tích problem, form giải pháp, lên design, test…,gần như là end-to-end process, mọi thứ đều dường như nằm trong tầm kiểm soát của designer. Nhưng trải qua thực tế thì lại khác, designer không phải là người cần hay được làm hết tất cả những thứ ấy, đặc biệt trong môi trường big corp.

Một hôm mình tìm được bài viết nói về khái niệm 3 diamond product process , mình thấy nó cung cấp cái hiểu rõ ràng, tổng quát hơn cho việc hiểu quy trình phát triển sản phẩm cho một công ty, từ đó hiểu công việc ux/ui thường ngày đang thực sự đang nằm ở đâu trong đó.

Hãy tưởng tượng nhiệm vụ công việc của UX/UI sẽ là một cái hộp nhỏ nằm trong vài cái hộp lớn sau.

Trước khi bàn đến process product development, ta cần hiểu sơ sơ về business, vì business có thể xem như là một cái hộp đóng khung các vấn đề mà product cần phải giải quyết, nó được đóng gói dựa trên việc ta nhắm đến thị trường nào, đang phục vụ cho tệp khách hàng nào, advantage của chúng ta là gì, value proposition, business model...

Điều này đồng nghĩa với việc không phải problem nào ta cũng giải quyết, mà phải qua một lớp filter của phía business.

Các khía cạnh tác động đến việc ta lựa chọn problem có thể kể đến như:

P/s: nhưng làm sao để tìm kiếm các cơ hội này, đó là công việc của các cấp trên, của bộ phận R&D, công ty mình có hẳn 1 team quan sát từng thay đổi ngoài thị trường, theo sát từng động tĩnh của đối thủ, đã hen 😀.

Khi đã nghiên cứu đủ nhiều bể problem ta sẽ phát hiện ra các cơ hội (giá trị của việc giải quyết problem ấy), nhưng dựa trên resource, tình hình kinh doanh, giai đoạn sản phẩm, chiến lược cạnh tranh hiện tại, các problem sẽ được filter lại, để quyết định xem đâu là cái ta phải làm, đâu là cái ta nên & không nên làm, đâu là cái đáng để đầu tư nhiều, đâu là cái “vừa đủ xài” là được…(kiếm vấn đề để giải quyết không khó, nhưng chọn cái nào để giải quyết mới khó 🤣).

Ngoài kia có nhiều framework để hỗ trợ giúp mình ra quyết định cho việc này, ví dụ như: Opportunity Scoring, Opportunity Cost, ICE Scoring, Jobs To Be Done (JTBD), Kano model,…( xem thêm bài này )

Tất cả những gì liên quan đến strategy là sự lựa chọn , mà mọi sự lựa chọn đều có trade-off nhất định. Mà lựa chọn không hề dễ nhe, mỗi bước đi đều là một ván cược ( tham khảo thêm ở bài này về câu chuyện nhức nhối nên chọn idea nào).

Dựa theo ERRC grid, thành quả của sự cân nhắc này là trả lời được các câu hỏi sau:

Sau khi đã có một danh sách ưu tiên các vấn đề cần giải quyết, việc tiếp theo là lên một danh sách các solution idea để giải quyết chúng (method: Opportunity Solution Tree), solution có thể là feature hoặc có thể không, miễn chúng giải quyết được problem (ví dụ: có thể solution nằm ở các department khác như customer support, marketing, operation, hoặc có thể là sự hợp tác, hoặc tận dụng một giải pháp nào đó có sẵn ngoài kia…). Và bộ phận product development sẽ tập trung giải pháp nào build được trên product.

Tương tự solution cũng cần đến sự lựa chọn & ưu tiên, đánh giá xem đâu là giải pháp tối ưu nhất cho thời điểm hiện tại, các framework hỗ trợ ví dụ như: SWOT, Impact/Effort matrix, RICE, Pugh Matrix, Weighted Scoring Model, Cost-Benefit Analysis,…

Cùng tuỳ theo mức độ tự tin về problem statement, về solution, mà ta linh hoạt xem có nên test, research thêm hay không.

Đây là cái hộp có chứa công việc của UX/UI.

Với kinh nghiệm hiện tại của mình, thì mình thấy gần như tất cả công việc nằm ở stage Feature development, điều này có nghĩa là mình không phải người được đi lựa chọn problem nào để giải quyết, mình không phải là người được contribute vào khâu form solution, tất cả những gì mình làm là transform solution ấy (nghe hơi buồn 😢 mà với mình thực tế đang là vậy).

Nếu nhìn theo hình tháp ở dưới, mình sẽ nằm đâu đó từ feature project đổ xuống. Nên nếu gói gọn công việc ở box này, những gì liên can đến problem hay solution, điều ta có thể làm là hiểu rõ nó để thiết kế sao cho đúng yêu cầu, hoặc cao hơn chút là đóng góp ý kiến cho solution concept, chứ mình không phải decision maker cho việc ấy (mình hay nhầm điều này mà qua khoá học, học đọc case study, tưởng rằng mình được đóng góp cho việc đó… hay level hiện tại mình chưa được 🫢).

Bài biết này chỉ mang tính chất cho vài cái nhìn cơ bản, tổng quan, tất nhiên mình cũng không có kinh nghiệm gì để có thể nói sâu tất cả các thứ trên (vì mình chưa được tiếp cận hay trải nghiệm qua các nấc thang đó mà, chắc khi mình là founder hay PM thì mới có cơ hội làm hết các việc đó). Nhưng tìm hiểu nó giúp mình nhận ra vài ý sau:

Bonus : video này nói về một sản phẩm MVP thực tế, qua đó mình nghĩ sẽ giúp hiểu rõ hơn về việc build product là như thế nào.