Designer trong product team: không chỉ thiết kế, mà là giải quyết vấn đề

Trong những năm đầu làm design, nhiều người – trong đó có cả tôi – thường nghĩ rằng giá trị của designer nằm ở việc tạo ra những file design thật đẹp.

• Wireframe rõ ràng.
• UI gọn gàng.
• Prototype mượt.

Nếu developer implement đúng theo design, công việc của designer gần như đã hoàn thành. Nhưng sau một thời gian làm việc trong product team, tôi nhận ra một điều khá bất ngờ: impact lớn nhất của designer thường không nằm trong file design. Nó nằm trong những cuộc discussion trước khi design được tạo ra. Trong nhiều trường hợp, decision quan trọng nhất của design đã được đưa ra trước khi bất kỳ màn hình nào được vẽ. Và những decision đó chỉ xuất hiện khi designer thực sự collaborate với team để hiểu problem.

Trong product development, design không đơn giản là làm UI. Nó là quá trình cùng nhau giải quyết problem.

Mỗi vai trò nhìn product từ một góc độ khác nhau

Trong một product team, mỗi vai trò đều mang đến một góc nhìn riêng. 

• Product Manager thường tập trung vào business goal và định hướng của sản phẩm. 
• Developer quan tâm nhiều đến technical feasibility và cách hệ thống có thể được xây dựng. 
• Designer thì tập trung vào trải nghiệm của người dùng. 

Không có góc nhìn nào là đủ nếu đứng một mình. Chỉ khi những góc nhìn này được kết hợp lại, team mới có thể tạo ra một solution thực sự hiệu quả. Đó cũng là lý do vì sao designer không thể chỉ đứng ngoài nhận requirement rồi thiết kế UI dựa trên requirement đó. Khi làm như vậy, designer chỉ đang thực hiện một phần rất nhỏ trong vai trò của mình.

Designer tạo ra giá trị lớn nhất khi họ hiểu được problem thực sự cần giải quyết là gì, user đang gặp khó khăn ở đâu, và solution nào có thể cân bằng giữa nhu cầu của user, mục tiêu của business và các constraint kỹ thuật. Để đạt được điều đó, collaboration là yếu tố không thể thiếu.

Requirement không phải lúc nào cũng là solution

Trong product development, requirement thường được xem như điểm bắt đầu của solution. Nhưng trên thực tế, requirement đôi khi chỉ là giả định đầu tiên của team về problem.

Ví dụ, một requirement có thể rất đơn giản: thêm dropdown để chọn category. Nghe có vẻ hợp lý. Và solution cũng rất rõ ràng: thiết kế một dropdown.

Nhưng khi team bắt đầu thảo luận sâu hơn, câu chuyện có thể thay đổi. Có thể user thực tế luôn làm việc trong một category cố định. Có thể họ cần chuyển nhanh giữa các category. Hoặc thậm chí category hoàn toàn có thể được tự động chọn dựa trên context. Lúc này, team nhận ra một điều khá thú vị: problem thực sự không phải là “thiếu dropdown”. Problem nằm ở cách user làm việc với category. Khi hiểu đúng problem, solution có thể thay đổi hoàn toàn. Dropdown có thể được thay bằng segmented control để chuyển nhanh hơn, category có thể được tự động chọn dựa trên context, hoặc trong một số trường hợp bước chọn category thậm chí có thể bị loại bỏ hoàn toàn.

Khoảnh khắc đó thường khiến team nhận ra rằng design tốt không đến từ việc implement requirement tốt hơn, mà từ việc hiểu problem đúng hơn.

Collaboration với developer giúp solution thực tế hơn

ollaboration cũng đặc biệt quan trọng khi designer làm việc với developer. Không phải solution nào cũng khả thi về mặt kỹ thuật, và một design tốt luôn cần cân bằng giữa trải nghiệm người dùng và các constraint của hệ thống.

Nhiều ý tưởng ban đầu có thể trông rất hợp lý từ góc nhìn UX. Nhưng khi bắt đầu trao đổi với developer, chúng ta có thể nhận ra rằng việc triển khai sẽ phức tạp hơn nhiều so với tưởng tượng vì có thể nó sẽ liên quan đến logic hệ thống, validation dữ liệu, hoặc là khả năng maintain lâu dài.

Chính trong quá trình thảo luận đó, solution thường được điều chỉnh để thực tế hơn. Trải nghiệm có thể cần đơn giản lại một chút, workflow có thể thay đổi một chút, nhưng đổi lại hệ thống ổn định và dễ phát triển hơn.

Và đây cũng là một khoảnh khắc quan trọng mà nhiều designer nhận ra: Solution tốt nhất không phải lúc nào cũng là solution “đẹp nhất”, mà là solution phù hợp nhất với product và hệ thống.

Collaboration không kết thúc sau khi design hoàn thành

Một hiểu lầm khá phổ biến là collaboration kết thúc khi designer handoff file design cho developer. Nhưng trong thực tế, collaboration vẫn tiếp tục trong suốt quá trình development. Designer cần giải thích intent đằng sau design để developer hiểu được lý do của từng decision. Khi có những constraint kỹ thuật mới xuất hiện, designer cũng cần cùng developer điều chỉnh solution. Ngoài ra, việc review implementation cũng rất quan trọng để đảm bảo trải nghiệm cuối cùng đúng với mong muốn ban đầu.

Design vì vậy không phải là một deliverable tĩnh. Nó là một phần của quá trình phát triển product, và sẽ tiếp tục được điều chỉnh khi team hiểu rõ hơn về user và hệ thống.

Từ “làm UI” đến “làm product”

Nhiều designer đo impact của mình bằng số lượng màn hình họ thiết kế.

Nhưng trong product development, những decision ảnh hưởng lớn nhất đến trải nghiệm người dùng thường không nằm trong layer UI. Chúng nằm ở những câu hỏi được đặt ra trong các cuộc discussion.

• Có nên thêm bước này không?
• User có thực sự cần lựa chọn này không?
• Hay toàn bộ workflow có thể đơn giản hơn?

Khi designer bắt đầu tham gia vào những câu hỏi như vậy, vai trò của họ cũng bắt đầu thay đổi. Họ không còn chỉ là người thiết kế giao diện nữa. Họ trở thành người giúp team định hình solution cho product.

Kết luận

Design không phải là công việc của một cá nhân. Nó là kết quả của sự collaboration giữa nhiều vai trò trong product team.

UI chỉ là phần dễ nhìn thấy nhất của sản phẩm. Nhưng chính collaboration mới là yếu tố định hình trải nghiệm thực sự.

Designer tạo ra impact lớn nhất không phải khi họ thiết kế đẹp nhất, mà khi họ collaboration hiệu quả nhất với team.

Và khi designer chuyển từ việc “làm UI” sang “giải quyết problem cùng team”, đó là lúc họ thực sự trở thành product designer.