Vì sao designer và developer vẫn khó làm việc cùng nhau — và cách những sản phẩm tốt thực sự được tạo ra

Product designer và developer thực ra đều đang theo đuổi cùng một mục tiêu: tạo ra những sản phẩm mà người dùng thật sự thích sử dụng. Cả hai phía đều muốn giải quyết vấn đề thực tế, cải thiện trải nghiệm và xây dựng thứ gì đó hoạt động mượt mà với người dùng cuối.

Vậy tại sao việc cộng tác giữa design và engineering vẫn thường xuyên tạo cảm giác khó chịu?

Và quan trọng hơn: làm sao để cải thiện điều đó?

Với tinh thần collaboration, bài viết này ban đầu được đồng viết cùng người bạn của tôi — Lisa Jacquiot, một Product Designer cực kỳ tài năng.

---

Nếu quy trình phát triển sản phẩm của bạn hoạt động như dây chuyền lắp ráp, mọi thứ sớm muộn cũng sẽ rối

Assembly line rất hiệu quả khi công việc mang tính lặp lại.

Product development thì không.

Research, design, engineering hay product decisions đều cần suy nghĩ, phân tích, tradeoff và diễn giải liên tục. Những thứ đó không vận hành tốt theo kiểu pipeline tuyến tính như nhà máy.

Nhưng rất nhiều team vẫn đang làm đúng như vậy.

Researcher chuyển insight cho product manager. Product manager chuyển spec cho designer. Designer chuyển file Figma cho developer.

Tới lúc đó, workflow của bạn bắt đầu giống trò chơi Telephone.

Vấn đề lớn hơn là team thường không tận dụng đúng thế mạnh của từng nhóm.

Product manager, designer và engineer đều là những người giải quyết vấn đề chuyên nghiệp — nhưng mỗi nhóm lại nhìn vấn đề theo cách khác nhau.

Khoảnh khắc bất kỳ bên nào nghĩ rằng mình đã có toàn bộ câu trả lời cũng là lúc blind spot bắt đầu xuất hiện.

Giải pháp thì nghe rất quen thuộc: collaboration nhiều hơn và sớm hơn.

Không cần tất cả mọi người phải ra quyết định ở mọi giai đoạn. Nhưng mọi người nên tham gia đủ để đóng góp context, constraint và feedback.

Điều này nghe đơn giản trên lý thuyết. Nhưng trên thực tế, xin feedback khá khó chịu.

Nó tốn thời gian. Nó tạo thêm uncertainty. Và nếu thành thật, phần lớn chúng ta đều nghĩ giải pháp của mình vốn đã đúng rồi.

Nhưng feedback sớm giúp team tránh đi sai hướng quá lâu.

Nó cũng giúp lộ ra technical limitation, user concern hay implementation detail — những thứ thường dẫn tới ý tưởng tốt hơn rất nhiều.

Khi bắt đầu project mới, hãy để designer, developer và những người có context liên quan cùng tham gia discussion từ sớm.

Trao đổi về thứ gì thực tế trước khi mọi thứ trở nên quá chi tiết.

Và với designer, đừng biến quá trình design thành một “creative cave” hoàn toàn tách biệt rồi vài tuần sau quay lại với những màn hình đã hoàn thành. Hãy tổ chức các buổi sync ngắn trong suốt quá trình làm việc.

Giải thích reasoning phía sau các quyết định design. Hỏi engineer xem đâu là phần implementation dễ vỡ hoặc khó maintain.

Ngược lại, developer cũng cần chủ động nói ra khi một thiết kế tạo ra complexity ngoài dự kiến, state chưa rõ ràng hoặc technical risk lớn hơn tưởng tượng.

Rất nhiều lần, chỉ cần thay đổi nhỏ trong design là đã giải quyết được toàn bộ vấn đề.

Càng cộng tác liên tục, khoảng cách giữa file design và sản phẩm thực tế càng nhỏ đi.

Và theo thời gian, team sẽ xây dựng được thứ quan trọng hơn rất nhiều: sự tôn trọng với chuyên môn của nhau.

---

Designer và developer đều theo đuổi “pixel perfection” — nhưng theo hai cách hoàn toàn khác nhau

Vấn đề không chỉ nằm ở việc designer và developer suy nghĩ khác nhau.

Công cụ của họ cũng ép họ nhìn sản phẩm theo hai mental model hoàn toàn khác.

Lấy ví dụ một màn hình login đơn giản.

Với designer, đó là một interface hoàn chỉnh.

Với engineer, đó là tập hợp của nhiều component, state, spacing system, validation logic và layout rule khác nhau.

Scott làm hình này — đừng trách Lisa.

Sau khi implementation hoàn tất, designer thường nhìn ra ngay:

• spacing lệch,
• màu chưa đúng,
• alignment không khớp,
• typography render khác.

Và trong đầu họ thường nghĩ:

“Sao không align text đúng như design luôn được nhỉ? Nó ở ngay đó mà.”

Trong khi đó, developer lại đang giải quyết một tập vấn đề hoàn toàn khác.

Designer nghĩ bằng pixel distance. Developer nghĩ bằng margin, padding, responsive layout và component behavior.

Một phần lớn là vì tool của mỗi bên buộc họ phải suy nghĩ theo cách đó.

Designer thấy text được căn giữa. Developer thấy hàng loạt edge case:

• chuyện gì xảy ra trên màn hình siêu rộng?
• split screen thì sao?
• nếu validation error xuất hiện thì layout thế nào?
• nếu localization khiến text dài gấp đôi thì sao?

Ngay cả responsiveness trong design tool đôi khi cũng gây hiểu nhầm.

Responsive grid trong Figma có thể khiến layout trông rất linh hoạt nhưng thực tế lại cực kỳ khó hoặc gần như không thể implement sạch bằng code.

Sự khác biệt còn rõ hơn ở component level.

Ví dụ một component UserAvatar viết bằng React.

Component này có thể nhận:

• firstName
• lastName
• image

Sau đó tự tạo initials hoặc hiển thị avatar bên trong một vòng tròn.

Trong mắt designer, avatar đó nằm gọn trong login layout.

Nhưng với developer, đó là reusable component độc lập và hoàn toàn không biết parent layout grid hoạt động ra sao.

Tool của hai bên vô tình tạo ra những assumption khác nhau.

---

Giải pháp không phải thêm nhiều handoff document hơn

Giải pháp là shared understanding tốt hơn.

Điều đó bao gồm:

• user flow rõ ràng hơn,
• prototype có thể tương tác,
• edge case được document,
• và feedback hai chiều liên tục.

Hãy design cho nhiều screen size và orientation khác nhau ngay từ đầu.

Xác định các breakpoint phổ biến dựa trên user thật thay vì chỉ phụ thuộc vào grid mặc định của tool.

Và đừng bắt developer tự nối các static screen lại trong đầu. Điều đó vừa tốn thời gian vừa dễ tạo bug.

Hãy cung cấp flow diagram mô tả cách các màn hình kết nối với nhau.

Với interaction, hãy tạo prototype đơn giản thể hiện:

• loading behavior,
• transition,
• animation,
• gesture,
• navigation flow.

Quan trọng nhất: design cả những state mà mọi người thường quên.

• loading state,
• empty state,
• first-time experience,
• authentication failure,
• partial content,
• offline behavior,
• error handling.

Với rất nhiều người dùng, những state “phụ” này mới là trải nghiệm sản phẩm thật sự.

Và trong toàn bộ quá trình, hãy giữ feedback loop hoạt động liên tục.

---

Design system chỉ thực sự hiệu quả khi nó tồn tại trong code

Design system nghe giống giải pháp hoàn hảo.

Và thật ra nó có thể là như vậy.

Nhưng chỉ khi nó tồn tại vượt ra ngoài document tĩnh.

Giá trị thực sự của design system chỉ xuất hiện khi nó trở thành shared language được implement trực tiếp trong code.

Đó là lý do component library quan trọng đến vậy.

Một design system được code hóa giúp designer và developer làm việc với cùng một tập building block, constraint và behavior.

Designer hiểu component thực tế hoạt động thế nào. Developer reuse được pattern đã được kiểm chứng thay vì build lại từ đầu.

Sự đồng bộ đó giúp giảm đáng kể khoảng cách giữa mockup và sản phẩm cuối cùng.

Dĩ nhiên, vẫn có tradeoff.

Build và maintain design system là khối lượng công việc khổng lồ cho cả design lẫn engineering.

Nhiều hơn hầu hết công ty tưởng tượng lúc bắt đầu.

May mắn là không phải team nào cũng cần custom design system hoàn toàn riêng.

Các hệ thống open-source như Material Design hay Bumbag đã cung cấp sẵn UI library và accessibility practice rất tốt cho nhiều trường hợp.

Và với phần lớn team, như vậy đã là quá đủ.

Cuối cùng, designer và developer không phải hai phe đối lập.

Những sản phẩm tốt nhất xuất hiện khi cả hai ngừng xem collaboration là “handoff” — và bắt đầu xem nó là quá trình cùng nhau giải quyết vấn đề.