Từ UI Designer trở thành Product Designer

Communication

Communication by zara magumyan

Tìm “What is a Product Designer” hay “How to become a Product Designer”, bạn sẽ thấy hàng triệu bài viết và video liên quan. Mình cũng từng làm vậy khi được đổi title thành Product Designer. Tự nhận xét thì mình đang ở giai đoạn quá độ từ UI Designer lên Product Designer. Bài viết này hoàn toàn dựa trên kinh nghiệm bản thân sau hơn 1 năm làm việc ở #be, được làm nhiều sản phẩm khác nhau, nên sẽ giống hoặc không giống với nhiều người.

Bài viết gồm 3 phần:
1. Giới thiệu qua sự khác nhau giữa UI Designer và Product Designer
2. Bạn cần làm việc với những ai?
3. Một số kĩ năng cần thiết

1. UI Designer vs. Product Designer

Định nghĩa thì có quá nhiều trên GG. Ở đây, mình tóm gọn theo cách hiểu của mình

UI Design vs. Product Design
  • UI Designer: Quan tâm nhiều tới giao diện của sản phẩm. Các yếu tố visual: font chữ, màu sắc, icons, spacing...
  • Product Designer: Quan tâm tới cả sản phẩm - cụ thể hơn là quá trình build, develop và vận hành của sản phẩm đó. Sản phẩm được tạo ra để giải quyết một vấn đề hay đáp ứng nhu cầu nào đó của con người. Ở đây mình không nói "người dùng" bởi vấn đề hay nhu cầu có thể đến từ những người không dùng sản phẩm đó. Nhiệm vụ của Product Designer là tìm hiểu, xác định vấn đề và tìm cách giải quyết vấn đề đó. Nếu không hiểu cách build, develop và vận hành của sản phẩm thì làm sao đề xuất giải pháp ?!
    Để làm được vậy, trước tiên bạn phải biết cần làm việc với những ai.

2. Làm việc với ai?

  • Internal team: Ở #be thì đó là UIUX team. Team chịu trách nhiệm về outlook cũng như trải nghiệm của người dùng với sản phẩm. Thường sau khi chốt yêu cầu, mình sẽ lên concept, sketch idea sau đó discuss với team. Làm vậy giúp mình và cả những team member khác có cái nhìn đa chiều hơn về vấn đề, đưa ra nhiều cách tiếp cận để qiải quyết hơn để từ đó chọn ra giải pháp tốt nhất.  Sau khi chốt solution và design với internal team, mình ship design cho product team.
  • Product team (product managers, product owners): Là những người chịu trách nhiệm cao nhất trong việc tạo ra và phát triển sản phẩm. Nói chung sản phẩm khi ra thị trường có đem lại kết quả như mong muốn hay không, họ sẽ là team chịu trách nhiệm cao nhất. Vì vậy, họ là người nắm rõ nhất quá trình xây dựng cũng như phát triển sản phẩm. Họ là người đi connect các team lại với nhau để build sản phẩm nên mọi người hay tìm đến họ khi có vấn đề. Do nhận request trực tiếp từ product team nên mình làm việc nhiều và sát nhất với team này. Điều đó giúp mình hiểu rõ hơn cách tạo ra sản phẩm (từ việc đưa yêu cầu, theo dõi tiến độ, testing, release sản phẩm…). Trước khi vào #be, mình chỉ dừng lại ở việc nghĩ tới design interface, quan tâm tới "xấu đẹp" là chính.
  • Tech team: Ở be, teach team chia làm 2 nhóm là ‘Dev team’ và ‘QA team’. Làm việc với các developers giúp bạn hiểu hơn về cách họ code, design như thế nào để vừa đảm bảo được yêu cầu mà lại không gây khó khăn khi dev. Bạn sẽ biết hiện tại có những hạn chế gì về mặt kỹ thuật. Không phải muốn design như thế nào cũng được. Các bạn QA là những người sẽ test sản phẩm xem sản phẩm đã cover hết các case có thể xảy ra chưa, đã chạy đúng theo yêu cầu chưa. Chính team dev và QA là những người hay đưa ra nhiều câu hỏi mà khi design mình không nghĩ tới.
  • Business team: Hiện tại, đây team chính đưa ra yêu cầu đối với sản phẩm. Product team sẽ là người làm việc chính với business để lấy yêu cầu sau đó phân tích yêu cầu đó, cân đối resource để chốt yêu cầu cuối cùng cho sản phẩm. Mình thường join meeting giữa product team và business ở những giai đoạn đầu của dự án hoặc khi có những yêu cầu thay đổi lớn, để nắm rõ hơn yêu cầu và có cái nhìn tổng quát về những gì business muốn.
  • Những team hay tiếp xúc với user: Customer support, Community, Customer Insight. Làm việc với những team này là một trong những cách nhanh nhất giúp bạn có được insight của người dùng.

3. Một số kĩ năng cần thiết

  • Giao tiếp: Bạn cần làm việc với nhiều team khác nhau. Kĩ năng giao tiếp theo mình là quan trọng số 1.
    Làm thế nào để người khác hiểu và chấp nhận giải pháp bạn đưa ra?
    Để phát triển kĩ năng, nhiều lúc bạn sẽ cần hỏi những thứ có thể không liên quan tới công việc, trách nhiệm của mình. Vậy làm thế nào để người khác đồng ý trả lời, hỗ trợ bạn?
    Hãy cố gắng hòa đồng, nói chuyện với mọi người dù ít hay nhiều. Thỉnh thoảng tham gia hoặc đề xuất các buổi ăn nhậu, đi chơi nhóm… Đây là cách khá hiệu quả để giữ quan hệ với mọi người chứ không chỉ riêng đồng nghiệp.
  • User empathy: Sẽ không ít lần bạn design mà quên đi user. Có thể vì khi đó bạn quá tập trung vào việc triển khai yêu cầu nhận được mà không nghĩ xem yêu cầu đó có đúng với những gì người dùng thực sự cần? Hay đó đã là cách tốt nhất chưa. Bạn có thể luyện kĩ năng này bằng cách tự nhiên như quan sát, nói chuyện (đặc biệt với user) hay cách formal hơn như phỏng vấn, theo dõi số liệu...
Empathy
  • Nghĩ sâu và xa: 'Sâu' tức là nghĩ tới việc sản phẩm đó sẽ được build, vận hành và sử dụng như thế nào. Những trường hợp nào có thể xảy ra trong quá trình sử dụng? 'Xa' tức là sản phẩm đó trong tương lai sẽ như thế nào, bởi nó sẽ phát triển chứ ko chỉ dừng lại ở những gì bạn tạo ra ngày hôm nay. Luyện suy nghĩ như vậy sẽ giúp bạn đưa ra những giải pháp toàn diện hơn. Tuy nhiên, không phải lúc nào bạn cũng có thời gian để làm được vậy. Hãy chịu khó tự tìm hiểu, học hỏi từ người khác để dần suy nghĩ nhanh hơn. Và đôi khi cũng cần chấp nhận những giải pháp tạm thời vì đơn giản lúc đó chưa có thời gian để nghĩ nhiều hơn hoặc có nhiều hạn chế mà bạn không thể thay đổi.

    Thường khi nhận yêu cầu, cách suy nghĩ của mình là:
    - Tính năng đó có thực sự cần thiết không?
    - User sẽ interact với tính năng đó như thế nào?
    - Những trường hợp nào có thể xảy ra khi sử dụng tính năng đó
    - Tính năng mới sẽ ảnh hưởng tới sản phẩm hiện tại như thế nào?
    - Có những hạn chế gì khi xây dựng và chạy tính năng đó ko?
    - Trong tương lai liệu có tính năng gì có thể ảnh hưởng tới tính năng này? Hay tính năng này liệu sau có thay đổi / phát triển lên thành tính năng khác?
    - ...
    - Cuối cùng, mình sẽ hỏi lại người đưa ra yêu cầu để chốt

  • Data-driven: Những gì bạn đề xuất, nếu không có số liệu chứng minh sẽ khó thuyết phục những người khác. Nói như vậy không có nghĩa bạn cần số liệu để đưa ra mọi quyết định. Bởi ở những giai đoạn đầu tiên khi build sản phẩm, data có được là khá hạn chế, thậm chí là ko có. Việc đưa ra quyết định khi đó sẽ thể dựa trên kinh nghiệm, case studies, tham khảo ý kiến người khác… Tuy nhiên, data vẫn là thứ thuyết phục nhất, hiển nhiên nhất. Hãy nghĩ dần tới những số liệu bạn cần và cách thu thập số liệu đó (hỏi product team, ux researcher, thực hiện survey, user interview…).
  • Testing: Để củng cố, kiểm chứng giải pháp bạn đưa ra có hiệu quả không, bạn cần thực hiện test. Như mình nói ở trên, test là 1 trong những cách để bạn lấy số liệu. Nếu trong nhóm có bạn chuyên về UX, thường bạn đó sẽ làm những việc này. Tuy nhiên bạn vẫn nên trực tiếp làm (ít nhất những lần đầu tiên) hoặc hỗ trợ thực hiện để hiểu hơn về người dùng, về sản phẩm. Có nhiều cách: làm survey, thực hiện usability testing, focus group interview...

  • UI/Visual: Cấu trúc, bố cục, look & feel của design tất nhiên vẫn là thứ bạn phải quan tâm tới. Với mình, giờ đã qua cái thời 'sản phẩm chạy được đã, design tính sau'. UI cũng ảnh hưởng tới UX mà.

  • Làm quen với các hạn chế: Sản phẩm được tạo ra dựa trên nhiều người / team nên chắc chắn gặp nhiều vấn đề, hạn chế. Những gì bạn muốn chưa chắc đã là thứ người khác cần hay có thể không thực hiện được trong thời điểm hiện tại.

Còn tiếp...