Nếu team bạn đang gặp các vấn đề sau:
👉 Đội nhóm không thống nhất user stories, ảnh hưởng tới output
👉 Designer làm đi làm lại design để đưa ra giải pháp vừa hợp tình stakeholder, vừa hợp ý user.
👉 JtbD đã thống nhất nhưng cả team thực thi bị off-track sau 1 thời gian.
👉 Tính năng ra mắt rồi mới phát hiện ra nhiều vấn đề tồn đọng chưa được mọi người để ý.
Thì hi vọng bài viết này có thể giúp bạn xử lý vấn đề đó 😀
Nó tên là Design Thinking.
Đúng, design thinking hoặc bất kì quy trình đưa ra giải pháp đều để hướng tới việc giúp tập thể đi tới đích nhanh và hiệu quả hơn.
Có điều Design thinking phổ biến tại Việt Nam bởi nó dễ áp dụng và dễ tùy biến. Dù team đang chạy theo waterfall, lean UX hay agile thì mô hình đều có thể dùng ngay.
Tuy quy trình “kiểu mẫu” có thể không giúp ta đi nhanh hơn mấy, nhưng chắc chắn việc đoàn kết và chia sẻ chung góc nhìn sẽ giúp tập thể đi xa hơn cùng nhau. Sự phổ biến của quy trình này chính là mình chứng cho việc đây nền tảng tốt để ra phân tích.
Tại Việt Nam có không ít team sản phẩm thuần Việt cho ra mắt cập nhật, tính năng đều đặn một cách chỉn chu. Thậm chí có những team không ngừng làm người dùng của họ thích thú trong 1 thời gian dài.
Vậy bí quyết của họ là gì? OLabs đã có cơ hội trò chuyện cùng nhiều team sản phẩm khác nhau, để cố gắng tìm ra 1 pattern cho 1 process thành công. Mình có thể tóm gọn quan sát của mình (tới thời điểm hiện tại) dưới đây:
✅ Ideate và đưa ra giải pháp: talent tại Việt Nam là 1 nguồn lực dồi dào với sức sáng tạo vô hạn, mọi người đều có thể đưa ra giải pháp rất ấn tượng. Vì thế mạnh này mà đây cũng là bước mọi người muốn nhảy vào nhanh nhất.
✅ Quá trình test hay quản trị rủi ro cũng không gặp nhiều vấn đề, mình nhận định đây là việc hầu như tất cả các team đều coi trọng. Hoặc nếu không test cẩn thận thì hậu quả cũng đến khá sớm.
Stakeholder có nhiều cơ hội để thực hành “đồng cảm” hơn đa số đội ngũ phát triển sản phẩm. Họ được tiếp xúc với khách hàng thường xuyên, cũng như lắng nghe vấn đề cũng là 1 phần trong công việc của họ. Nhưng điều này vô tình lại là hạn chế đối với đội ngũ thực thi. Bởi chuyên môn của họ thường không đòi hỏi phải đồng cảm với khách hàng.
Tất nhiên bước này có làm sai thì team vẫn có thể về đích, nhưng đi đường dài thì vấn đề sẽ chất đống. Ngoài ra việc áp đặt sự đồng cảm/góc nhìn của sếp lên người thực thi không đúng cách càng khiến cho team product trở nên bất mãn. Hậu quả việc tập thể không thống nhất cách đồng cảm sẽ kéo theo define sai ở phần sau.
Nếu bước trên đã là do stakeholder “thầu chính”, thì bước này cũng sẽ khó làm hiệu quả. Một số dấu hiệu phổ biến là user-stories thiếu thống nhất, nội bộ đặt nhiều nghi vấn về sự đúng đắn của vấn đề này. Hay bài toán không liên quan gì đến nhu cầu của khách hàng, chỉ nói về giải pháp và chiến lược kinh doanh. Hoặc dashboard giữ insight, data thì chỉ có mình PM đọc và xây dựng chiến lược, giải pháp.
Bản thân mình cũng từng mắc kẹt trong bước này, bởi mình thường quên một sự thật đơn giản là: phát triển sản phẩm là làm việc nhóm. Nhiều anh chị em bạn bè làm Quản lý sản phẩm mà mình có cơ hội trò chuyện cũng thường tự đặt toàn bộ gánh nặng này lên vai.
Nếu bạn đang gặp 2 vấn đề trên, chúng ta có thể chuyển sang phần tiếp theo nhé! (Thực ra nếu không thì hi vọng mọi người cố đọc nốt để xem qua mô hình của mình cho vui.)
Mình và OLabs đã may mắn có cơ hội được hợp tác cùng nhiều team product tài năng trong các lĩnh vực khác nhau. Với đặc thù phải dính vào bước empathy và define, OLabs luôn tìm cách để bước này thích nghi tốt với các team khác nhau. Sau đây là một vài cách giúp 2 bước này hiệu quả hơn trong một số trường hợp.
Data inform hay Data driven – thì nhìn chung team sản phẩm cũng cần lưu ý một vài con số quan trọng. Đây là việc không cần nhắc lại nhiều.
Nhưng việc tất cả mọi người cùng nhận thức được tác động của giải pháp của mình là một ý tưởng không tệ. Đối với 1 số vai trò đặc thù như UX, họ có thể sẽ có metric đặc thù của riêng họ.
“Là một user nên tôi muốn [tính năng]…” – Không, user không MUỐN tính năng đó, họ muốn giải quyết vấn đề của họ. Vì áp lực thời gian hoàn thành tính năng, người xây dựng giải pháp dễ bị cuốn vào việc đưa ra nhiều giải pháp thay vì định vị bài toán đúng. Và người đưa giải pháp cũng thường vô thức “lái” vấn đề của người dùng theo mục tiêu của sản phẩm.
Một tập thể có chung góc nhìn về insight sẽ giúp giảm bớt mẫu thuẫn hoặc bias cho giai đoạn sau. Designer hiểu hơn giải pháp giúp giải quyết bức tranh toàn cảnh thế nào, trong khi PM sẽ tránh tốn sức giải thích lại khách hàng mục tiêu.
“Hình như mọi người đang dẫm vào chân nhau trong việc đưa ra giải pháp!”
Nếu team bạn đang tiêu tốn nhiều nguồn lực để ideate giải pháp hơn dự kiến, có lẽ đã đến lúc dừng lại để điều phối ai đó cùng bạn làm việc đồng cảm và xác định đúng vấn đề.
Nếu là PM, hãy giúp team hiểu hơn những lựa chọn mà cả team phải ưu tiên. Dựa trên khả năng của người làm UX, họ có thể đưa ra lựa chọn giúp cover nhiều cơ hội bằng 1 giải pháp.
Nếu là người làm UX, hãy yêu cầu cơ hội được lắng nghe người dùng. Điều này sẽ giúp bạn cân đối kỳ vọng của stakeholder và hiểu hơn bức tranh về thị trường, người dùng. Từ đó đưa ra giải pháp phù hợp với cả nhu cầu người dùng và mục tiêu được đặt ra.
Nhìn chung, bước này sẽ giúp tập thể có chung một góc nhìn để đồng cảm và xác định vấn đề.
Nếu đã tăng sức nặng của bước empathy, thì rủi ro sẽ nằm ở việc “Đồng cảm” sai. Từ đó dẫn tới define sai.
Để khắc phục rủi ro này, OLabs đã ứng dụng Phương pháp thu thập và trình bày dữ liệu trung lập.
Nói đơn giản thì đây là việc mà ta thường gọi là UX Research. Giúp cân bằng tính trung lập của mọi yếu tố – từ đó giảm thiểu cái sai do bias của người làm giải pháp.
Cụ thể, các phương pháp luận có cơ sở khoa học sẽ được điều chỉnh để phù hợp với từng hoàn cảnh, từ đó tránh việc áp dụng một cách máy móc, giảm thiểu rủi ro sai sót.
Về các phương pháp luận này, bạn có thể tìm đọc trong kho tài liệu của NN/g hoặc các phương pháp đã được “việt-hóa” để phù hợp với môi trường Việt Nam hơn tại đường dẫn này.
Điều này còn đảm bảo nếu có lỡ define không đúng, thì trong sprint sau, team vẫn có thể tận dụng cơ hội học hỏi từ sai sót phía trước thay vì xây dựng một user-stories mới toanh.
Làm sản phẩm cũng là một hình thức kinh doanh – bán hàng. OLabs đã sẵn sàng tinh thần thay đổi, cập nhật mô hình này dựa trên điều kiện ứng dụng thực tế. Bản thân process này cũng cần nội tại của doanh nghiệp để phát triển quy trình riêng phù hợp với đặc thù kinh doanh.
Với thế mạnh là một doanh nghiệp tập trung khai thác Research và Define, OLabs không ngừng cập nhật và tìm cách tinh chỉnh quy trình phát triển UX sao cho phù hợp với thị trường.
Còn bạn, liệu bạn có phương pháp nào để giúp quá trình phối hợp giữa người làm UX và PM trở nên hiệu quả hơn hay không? Đừng ngại chia sẻ với fanpage của OLabs nhé!
Cập nhật những thông tin mới nhất về UX mỗi ngày.
