Bạn tưởng tượng thế nào về một người làm product?
Có phải là một người làm việc độc lập, chỉ cần hoàn thành wireframe/ mockup của sản phẩm, hoàn thành một tài liệu kỹ thuật với đầy đủ yêu cầu chi tiết, sau đó giao hết tất cả các nguyên liệu cho những team khác và ngồi chờ kết quả?
Khi mới bắt đầu công việc là một Product Owner, mình đã ngây thơ và vô tư nghĩ vậy.
Chỉ đến khi đã chính thức bắt tay vào làm, trải qua nhiều khoảng thời gian học hỏi, mình mới phát hiện ra, làm Product Owner chính là bạn sẽ giống như chiếc cầu, nối chỗ này chỗ kia, làm việc với rất nhiều team từ Design đến HTML, Dev FE/ Dev BE, QA/ QC, partner, marketing, content, kế toán, chăm sóc khách hàng và nhiều bộ phận khác nữa.
Nếu mình chỉ cắm đầu vào một mình cặm cụi vẽ vời tính toán rồi sau đó phó mặc cho các team thực hiện những giai đoạn còn lại, mình sẽ chẳng thể nào khiến sản phẩm thành hình, bởi đơn giản, xây dựng một sản phẩm hoàn chỉnh không phải là việc có thể thực hiện được từ kế hoạch của chỉ một cá nhân.
Một mình người Product Owner không thể là người tạo nên sản phẩm, và lại càng không thể chỉ giao wireframe/prototype/product specifications cho các đồng nghiệp thì tức là ta đã hoàn toàn xong phần việc của mình.
Mọi thứ còn tiếp diễn, cứ thế kéo dài cho đến khi sản phẩm lên, sản phẩm chạy, rồi thì sản phẩm cần duy trì, phát triển, cải tiến liên tục.
Thế nhưng, suy cho cùng thì, đây cũng chính là điều tuyệt vời nhất của việc làm product.
Mình đã học hỏi được vô vàn những kiến thức quý giá từ các bộ phận khác mà có lẽ không sách vở lý thuyết nào dạy mình được. Không chỉ thuật ngữ chuyên môn, cách làm việc, quy trình làm việc hay những kiến thức nền, mà quý hơn cả là các tình huống sai lầm thực tế, những thứ rất thật qua từng case-study phát sinh trong quá trình làm.
Chúng khiến mình dần trưởng thành hơn theo thời gian.
Tuy nhiên, trước khi tiếp cận được với những thứ ấy, có một thứ mà mình đã phải học: nói chuyện với đồng nghiệp bằng “ngôn ngữ” của họ.
Mục đích của việc này? Dĩ nhiên là để họ hiểu mình. Chỉ khi họ hiểu mình cần gì, muốn gì, họ mới có thể cùng mình tạo nên một dream-team biến sản phẩm mà mình vẽ từ giấy thành một thứ có thật và sử dụng được.
Trong bài viết hôm nay, mình sẽ chia sẻ lại vài kinh nghiệm cá nhân trong việc làm việc với các team khác, mà đầu tiên chính là team design – một trong những team mà Product Owner sẽ cần làm việc cùng nhiều nhất và theo sát nhất.
1- Chia sẻ mục tiêu dưới góc độ người dùng
Vì sao? Vì đó là cái mà designer quan tâm khi thiết kế sản phẩm.
Với việc thiết kế sản phẩm theo hướng user-centered design, designer sẽ cần đặt trải nghiệm người dùng vào trung tâm và vì thế, khi làm việc cùng họ, bạn hãy biến những yêu cầu dưới góc độ kinh doanh/ marketing v.v… thành những yêu cầu gắn liền với người dùng.
Ví dụ 1:
- Công ty đang cần tăng đơn hàng trong tháng này gấp hai lần tháng trước. Chúng ta cần sửa lại trang ‘Chi tiết sản phẩm’ để tăng số lượng đơn hàng và đạt số.
Có thể phiên dịch lại thành:
- Chúng ta nên thiết kế lại trang ‘Chi tiết sản phẩm’ như thế nào để cung cấp đủ thông tin về sản phẩm một cách rõ ràng, thân thiện và tạo ra nhiều động lực hơn khiến cho người dùng muốn mua sản phẩm ngay? Có cách nào để khiến người dùng muốn click vào nút “Đặt hàng” nhiều hơn không?
Ví dụ 2:
- Mình cần phải tăng lượng người điền vào form thông tin này. Target là có 1000 người điền form trong vòng một tuần.
Có thể phiên dịch lại thành:
- Chúng ta cần thiết kế lại form thông tin này với mục tiêu giúp cho người dùng thấy được ngay lợi ích sau khi hoàn thành việc điền vào form thông tin, từ đó kích thích họ thực hiện điền form càng sớm càng tốt. Ngoài ra, cách thiết kế các cột nội dung cần phải đơn giản, dễ hiểu để người dùng có thể hoàn thành việc điền form một cách dễ dàng nhất và nhanh nhất.
Ví dụ 3:
- Mình muốn đưa tính năng mới X vào trang này mà không làm ảnh hưởng đến lượt click vào tính năng Y.
Có thể phiên dịch lại thành:
- Chúng ta cần đưa tính năng X vào trang, nhưng vẫn phải đảm bảo rằng người dùng có thể tìm thấy tính năng Y và sử dụng nó dễ dàng, không gặp khó khăn gì. Vì thế, hãy cùng nghĩ xem nên sắp xếp bố cục thế nào thì hợp lý và việc thêm tính năng X vào trang không làm ảnh hưởng tới trải nghiệm của người dùng với tính năng Y nói riêng và với toàn bộ trang này nói chung.
2- Đừng bắt designer vẽ layout giống wireframe nhất có thể
Đây là tình huống mình hay gặp phải nhất. Đó là khi bạn cảm thấy designer can thiệp quá nhiều vào bản vẽ ban đầu của bạn – cụ thể là thay đổi quá nhiều bố cục, cấu trúc trên wireframe, trong khi bạn nghĩ rằng họ không được làm điều đó.
Bản thân mình đã từng gặp sai lầm và có góc nhìn sai lệch trong những tình huống này. Khi mới làm Product Owner, mình coi designer chỉ đơn thuần là người tô màu, tạo hình, làm cho bản vẽ từ đen trắng trở thành những thứ lấp lánh và thế là hết. Do vậy, mình vừa chăm chút cho wireframe của mình, vừa đinh ninh rằng các bạn designer sẽ không được thay đổi cấu trúc hay bố cục của wireframe này.
Khi đã làm một thời gian dài hơn, mình bắt đầu hiểu rằng:
- Wireframe chỉ là khung sườn của sản phẩm, cũng chỉ là công cụ mà Product Owner sử dụng để diễn đạt yêu cầu của mình về sản phẩm & tính năng với các team liên quan, chứ không phải tiêu chuẩn tuyệt đối để thiết kế sản phẩm phải đi theo 100%.
- Việc của Product Owner là cần thể hiện đủ thông tin, các thành phần cần có trên wireframe, chứ không phải vẽ wireframe một cách đẹp nhất có thể.
- Việc thiết kế giao diện cuối như thế nào còn phụ thuộc vào việc làm sao để tối ưu UX/UI – đây là thứ mà Product Owner có thể bàn bạc với Product Design để tìm giải pháp phù hợp nhất. Giải pháp này có thể đến từ việc đi theo các tiêu chuẩn thiết kế của những công ty product lớn trên thế giới như Google/ Apple, đi theo chuẩn thiết kế chung đã được xây dựng từ trước của sản phẩm, thậm chí cũng có thể đến từ việc đóng vai là một end-user (người dùng cuối) để hình dung xem mình sẽ tương tác và sử dụng tính năng như thế nào.
- Điều quan trọng là chia sẻ thông tin với designer sớm nhất có thể, để họ cùng nắm được user requirement, hiểu thêm về user working flow và lý do tại sao mình lại có một flow như vậy, hiểu về using context (ngữ cảnh sử dụng tính năng) để từ đó có được sự trao đổi hiệu quả hơn khi chính thức bắt tay vào thiết kế.
Và từ đó, thay vào việc quăng một câu đầy độc đoán xuống đầu designer bắt họ đi theo cái “tiêu chuẩn” wireframe của mình, mình đã ngồi xuống và cùng thảo luận với các bạn nhiều hơn, sớm hơn.
Nói thế nào nhỉ? Khi Product Owner và Product Designer bắt đầu hiểu nhau và nói cùng một hệ ngôn ngữ, các giải pháp sáng sủa sẽ tự thế mà đến.
3- Đừng kỳ vọng quá nhiều vào designer
Nghe có vẻ trái ngược với những thứ mình vừa viết ở trên. Nhưng không. Đây lại cũng là một tình huống thường xuyên dễ gặp. Đó là khi bạn nghĩ designer là một cái chi đó rất đa năng và làm được tất cả các thể loại design bạn cần.
Dưới đây là vài ví dụ về những yêu cầu kỳ cục mình từng đưa cho designer.
Ví dụ 1:
- Product Owner: Mình cần phần X của bản app này hiển thị như thế này, vân vân và mây mây. Bạn thấy sao?
- Designer: Ok để mình xem.
- Product Owner: Bạn không có góp ý gì à? Kiểu hiển thị như thế, animation như thế ok hết rồi à?
- Designer: Thật ra mình phải suy nghĩ thêm. Mình là Graphic Designer, có phải Interactive Designer đâu?
Ví dụ 2:
- Product Owner: Mình cần thiết kế một Media Kit giới thiệu sản phẩm dưới dạng ảnh động hoặc video gì cũng được. Làm kiểu như thế này này, chuyển động hoành tráng như này này, hiệu ứng các thứ (đưa vài mẫu ra).
- Designer: Mình làm được một nửa thôi nhé (sau này mình mới biết mình bị troll ở đoạn này)
- Product Owner: Gì? Một nửa là thế nào?
- Designer: Mình chỉ làm thành graphic được thôi, ra ảnh tĩnh thôi, chứ không cho nó động đậy được đâu. Mình là Graphic Designer chứ không phải Motion Graphic Designer.
Đấy chính là một vài ví dụ khi mình đã mong chờ hoặc kỳ vọng sai chỗ. Thực tế là, designer có rất nhiều dạng/nhóm, và mỗi dạng/nhóm designer lại có một thế mạnh khác nhau, chịu trách nhiệm về những phần công việc khác nhau. Nếu may mắn, bạn sẽ được làm cùng một designer biết tuốt, mảng nào cũng có thể chiến đấu. Còn nếu không, bạn hãy ghi nhớ: đúng việc, đúng người.
Để cho bạn dễ hình dung về các nhóm/dạng designer và những kỹ năng mà mỗi nhóm này có được, bạn có thể research thêm với keyword “types of designers”. Đọc xong, chắc chắn mỗi khi gặp vấn đề, bạn sẽ biết tìm đến chính xác nơi mà bạn cần tìm đến.
4- Dừng việc nhận xét và yêu cầu dựa trên cảm tính
Đây cũng là một vấn đề muôn thuở khác. Rất may là mình biết thân biết phận nên luôn ý thức được điều này, nhưng xung quanh thì thấy mọi người rất hay mắc phải và mấy người bạn là designer của mình cũng hay than vãn lắm nên mình đưa vào đây luôn thể.
Ví dụ 1:
- Product Owner: Sao mình thấy cái landing page này nó không được đẹp (chán/ không hấp dẫn/ nhạt nhẽo v.v…)
- Designer: Bạn nói rõ hơn được không?
- Product Owner: Thì mình là người dùng mà mình nhìn vào thì thấy thế. Bạn sửa lại cho nó đỡ hơn được không?
- Designer: …
Ví dụ 2:
- Product Owner: Bạn ơi, cái tone màu của toàn bộ header trên trang, bạn đổi hết cho mình sang màu x nhìn cho nổi bật sang xịn nhé.
- Designer: Background màu này không đổi tone chữ sang màu x được đâu bạn ơi. Chưa kể là không hợp vibe với sản phẩm của mình.
- Product Owner: Mình thấy màu đó mới đẹp. Bạn nghiên cứu trend trên thế giới thử đi. Mấy trang high end fashion họ cho mẫu phối đồ các màu như vậy đó.
- Designer: Nhưng đây là website về thương mại điện tử mà…
Đấy, nói chung là muôn hình vạn trạng lắm. Nhưng tóm lại thì thế này: nếu đã là những gì liên quan đến chuyên môn của họ, thì mình tin họ. Nếu góp ý, mình cũng chỉ nói dưới quan điểm cá nhân, nếu họ thấy hợp lý thì họ có thể làm theo, còn nếu không, mình luôn tôn trọng. Theo mình, mỗi người đều có chuyên môn riêng. Bởi thế, dưới góc nhìn cá nhân có thể bạn thấy mình đúng, nhưng dưới góc độ chuyên môn thì bạn không thể nào chắc chắn được bạn không sai. Cùng tôn trọng và tin tưởng nhau, lúc ấy bạn có thể phối hợp được với designer dễ vô cùng.
—
Chỉ có 04 điều ngắn gọn thế thôi nhưng chính là những kinh nghiệm bản thân mình đúc kết được, thấy tâm đắc và muốn chia sẻ. Hy vọng mối quan hệ giữa chúng ta, những người làm product và các bạn designer luôn tốt đẹp. Tất cả vì một tương lai tươi sáng cho một sản phẩm hoàn hảo nhất có thể.
Cuối bài, mình tặng các bạn một tấm hình để coi cho vui.
Xem thêm: Khóa học Product Management – Quản lý sản phẩm cho người mới bắt đầu