Vì sao design và engineering vẫn luôn lệch khỏi nhau

Vào mùa đông năm 1898, một kỹ sư cơ khí tên là Frederick Winslow Taylor đến Bethlehem Steel với một chiếc đồng hồ bấm giờ và một giả thuyết. Trong nhiều năm, Taylor bị ám ảnh bởi một câu hỏi: tại sao lao động công nghiệp lại kém hiệu quả đến vậy? Cuối cùng, ông tin rằng mình đã tìm ra nguyên nhân cốt lõi. Theo Taylor, vấn đề nằm ở chỗ chính những người lao động cũng là người quyết định cách công việc được thực hiện. Mỗi người có nhịp độ, thói quen và cách phán đoán riêng, và với Taylor, toàn bộ sự khác biệt đó đều là lãng phí.

Giải pháp của ông vào thời điểm đó được xem là cực kỳ cấp tiến. Việc suy nghĩ và thực thi nên được tách biệt hoàn toàn. Ban quản lý sẽ quyết định quy trình tối ưu, công cụ tối ưu và tốc độ tối ưu, còn công nhân chỉ việc làm theo hướng dẫn. Ông gọi mô hình này là scientific management, và theo thời gian nó trở thành nền tảng cho cách các tổ chức công nghiệp vận hành trên khắp thế giới.

Không ai nghĩ rằng cùng một mô hình đó sau này lại ảnh hưởng mạnh tới cách các team sản phẩm số hoạt động. Nhưng khi các agency và công ty phần mềm bắt đầu tìm kiếm workflow có thể scale, họ đã mượn đúng quy trình mà thế giới công nghiệp vốn đã quen thuộc: lên kế hoạch, thiết kế, sản xuất. Mỗi giai đoạn chuyển giao công việc cho giai đoạn tiếp theo. Designer tạo ra vision, engineer triển khai nó, còn specification tiếp tục được đẩy xuống downstream cho tới khi sản phẩm xuất hiện ở đầu bên kia.

Vấn đề là việc xây dựng phần mềm gần như không có điểm chung nào với tối ưu hóa công nhân xúc gang thép ở Bethlehem Steel. Thế nhưng hơn một thế kỷ sau, phần lớn các product team vẫn đang vận hành dựa trên workflow được tạo ra cho một loại vấn đề hoàn toàn khác.

---

Hai lăng kính

Tôi đã tham gia không biết bao nhiêu cuộc họp nơi mô hình này bắt đầu rạn nứt. Tôi từng nhìn nó từ phía design, phía engineering, và cả từ vị trí ở giữa — nơi bạn hiểu chính xác cả hai người đang muốn nói gì nhưng cũng đồng thời thấy rõ vì sao họ vẫn không thể thực sự kết nối với nhau.

Một designer trình bày flow đã được thiết kế rất cẩn thận. Layout cân đối, visual hierarchy nhất quán và interaction trông hoàn toàn hợp lý. Nhưng chỉ vài màn hình sau, một engineer ngả người ra ghế và nói: “Cái này sẽ rất khó để build.” Designer hỏi tại sao.

Điều xảy ra tiếp theo gần như lúc nào cũng giống nhau. Engineer giải thích constraint. Designer diễn giải lại intent. Engineer gật đầu, nhưng không hẳn là đồng ý — giống kiểu người ta âm thầm quyết định sẽ xử lý vấn đề đó sau. Cuộc họp kết thúc, và hai tuần sau feature được ship.

Về mặt kỹ thuật, mọi thứ đều hoạt động. Nhưng có một thứ rất nhỏ đã biến mất somewhere giữa file thiết kế và implementation cuối cùng. Kết quả không hẳn sai, nhưng nó cũng không còn tạo cảm giác giống vision ban đầu nữa.

Thoạt nhìn, điều này trông giống một vấn đề giao tiếp. Trong nhiều năm tôi từng nghĩ rằng handoff document tốt hơn, annotation chi tiết hơn và specification rõ ràng hơn sẽ giải quyết được chuyện đó. Nhưng chúng không làm được. Bởi vì vấn đề sâu hơn không chỉ nằm ở communication. Nó là vấn đề về mental model.

Designer và engineer không chỉ khác nhau ở training. Họ thực sự nhìn cùng một sản phẩm qua hai lăng kính hoàn toàn khác nhau, và mỗi góc nhìn vừa có giá trị vừa không đầy đủ nếu đứng một mình.

Designer nhìn vào interface và thấy composition, hierarchy, rhythm và emotional flow. Họ nghĩ về việc người dùng nên chú ý điều gì, hiểu điều gì và cảm thấy điều gì ở từng khoảnh khắc cụ thể. Trải nghiệm trong đầu họ vận hành gần giống một narrative: người dùng đến đây, nhìn thấy thứ này, thực hiện hành động đó và lý tưởng nhất là cảm thấy mình được sản phẩm thấu hiểu.

Engineer nhìn vào cùng interface đó và thấy systems, state, logic, constraints cùng dependencies. Họ nghĩ về chuyện gì xảy ra khi data không load được, khi user hành xử bất ngờ hoặc khi component phải hoạt động trong hàng chục context khác nhau cùng lúc. Engineering về bản chất luôn là việc quản lý complexity trong điều kiện thực tế.

Không có lăng kính nào sai. Cả hai đều cần thiết. Nhưng mỗi bên sẽ hình thành instinct, priority và thậm chí cả định nghĩa về “good” rất khác nhau.

Khi designer nói “Can we make this feel lighter?”, họ thường đang ám chỉ điều gì đó cực kỳ cụ thể: giảm visual weight, tăng spacing, làm motion mềm hơn hoặc thay đổi pacing của interaction. Nhưng khi engineer nghe cùng câu nói đó, thứ họ nghe thấy thường là một request không có acceptance criteria rõ ràng. Chính xác thì “done” trông như thế nào?

Designer không hề vague, và engineer cũng không cố gây khó dễ. Họ chỉ đang nói hai ngôn ngữ khác nhau trong khi đều nghĩ rằng mình đang dùng cùng một ngôn ngữ.

---

Friction mang lại giá trị

Điều thú vị là tension này không phải vấn đề thực sự. Trong điều kiện phù hợp, nó lại là một trong những thứ có giá trị nhất mà product team sở hữu.

Designer và engineer không có cùng blind spot. Một designer tối ưu cho perception và narrative có thể bỏ qua structural fragility. Một interaction có thể trông tuyệt vời trong prototype nhưng sụp đổ hoàn toàn dưới real-world data. Trong khi đó, engineer tối ưu tuyệt đối cho robustness lại có thể tạo ra thứ technically flawless nhưng khiến người dùng cảm thấy disconnected về mặt cảm xúc.

Khi hai góc nhìn này gặp nhau đủ sớm, mỗi discipline sẽ phát hiện thứ mà bên còn lại bỏ sót. Và sự collaboration còn trở nên mạnh hơn khi constraint bắt đầu ảnh hưởng tới creativity.

Ví dụ, designer có thể muốn component tạo cảm giác “nhẹ” hơn về mặt thị giác. Engineer có thể giải thích rằng việc thay đổi structure sẽ phá vỡ nhiều layout khác trong hệ thống. Nhưng trong quá trình trao đổi, cả hai có thể nhận ra rằng chỉ cần điều chỉnh transition timing là đã tạo ra trải nghiệm tốt hơn mà không làm hỏng architecture. Constraint không giết chết ý tưởng; nó chỉ redirect ý tưởng sang một hướng mạnh hơn.

Đó chính là cảm giác khi làm việc với một material thực sự. Material sẽ phản kháng, và chính sự phản kháng đó làm cho sản phẩm tốt hơn. Ngay cả quá trình negotiation cũng có giá trị riêng của nó.

Khi designer buộc phải giải thích vì sao một interaction quan trọng, cách suy nghĩ của họ trở nên sắc bén hơn. Khi engineer buộc phải giải thích vì sao thứ gì đó khó thực hiện bằng ngôn ngữ thực tế thay vì jargon, architecture cũng trở nên rõ ràng hơn. Friction tạo ra clarity.

Như Dave Rupert từng viết, bản thân con người không phải friction. Và như Matthias Ott mô tả, friction thường chính là nơi những sản phẩm tốt bắt đầu có hình dạng.

Nếu có đủ thời gian làm việc cùng nhau và đủ feedback loop, hai góc nhìn này không chỉ coexist. Chúng bắt đầu dạy lẫn nhau.

---

Đường nứt trong workflow

Trong phần lớn tổ chức, workflow lại không cho sự collaboration đó đủ không gian để diễn ra.

Đây chính là nơi di sản của Taylor vẫn âm thầm ảnh hưởng tới product development hiện đại. Một sequential workflow — nơi design kết thúc trước khi engineering bắt đầu — biến một khác biệt nhận thức vốn có thể kiểm soát được thành một vấn đề lớn hơn nhiều.

Vấn đề không nằm ở việc tension tồn tại. Vấn đề nằm ở chỗ workflow loại bỏ toàn bộ những thứ có thể khiến tension trở nên hữu ích. Không có shared material để cả team cùng nhìn vào, không có feedback ngay lập tức khi design decision va chạm với technical constraint, và cũng không có cơ hội để cả hai discipline cùng reshape ý tưởng khi nó vẫn còn linh hoạt.

Thay vào đó, team phụ thuộc vào translation. Và translation lúc nào cũng làm mất thông tin.

Mỗi khi một quyết định rơi vào khoảng trống giữa design và engineering, nó sẽ được xử lý bởi người đứng gần vấn đề đó nhất ở thời điểm hiện tại. Engineer quyết định spacing vì specification không đủ rõ. Designer override behavior của component mà không hiểu dependency của hệ thống. Product manager giải quyết tranh luận bằng cách chọn phương án ship nhanh hơn.

Nếu nhìn riêng lẻ, những quyết định này có vẻ vô hại. Nhưng khi cộng dồn lại, chúng tạo ra drift.

Sản phẩm dần lệch khỏi design intent ban đầu. Codebase dần lệch khỏi design system. Và cuối cùng team ship ra thứ technically hoạt động nhưng tạo cảm giác disconnected, như thể các phần khác nhau chưa bao giờ được thiết kế để hoạt động cùng nhau.

Vấn đề không hẳn là mọi người đưa ra quyết định tệ. Vấn đề là các quyết định đang được đưa ra mà không có shared context.

Và dù tooling tốt hơn chắc chắn có ích, chúng hiếm khi giải quyết được root issue. Những nền tảng như:

• Zeplin
• Storybook
• Figma developer mode
• design tokens
• component libraries

đều cải thiện handoff efficiency. Nhưng chúng vẫn mặc định rằng handoff là mô hình đúng.

Những thứ engineer hiểu rất sâu — browser behavior, viewport unpredictability, layout degradation, độ dài content thực tế hoặc khả năng mới của modern CSS — thường không bao giờ flow ngược upstream cho tới khi việc thay đổi trở nên quá đắt đỏ.

Điều mà team thực sự cần không phải handoff process tốt hơn. Họ cần ít handoff hơn.

---

Làm việc trực tiếp với material

Structural gap cần một structural solution, và một trong những cách tốt nhất tôi từng thấy là đưa design decision tiếp xúc với medium thực tế càng sớm càng tốt.

Năm 2015, Frank Chimero có một talk tên là The Web’s Grain và đặt ra một câu hỏi rất quan trọng:

“What would happen if we stopped treating the Web like a blank canvas to paint on, and started treating it like a material to build with?”

Sự khác biệt này quan trọng hơn nhiều team nghĩ.

Khi interface được thiết kế hoàn toàn trong các công cụ không có khái niệm về state, responsiveness, timing, viewport behavior hay unpredictable content, team sẽ ngừng thiết kế cho web thật. Thay vào đó, họ bắt đầu thiết kế một phiên bản hư cấu của web.

Cuối cùng engineer phải inherit toàn bộ fiction đó và hấp thụ mọi compromise ẩn bên trong.

Đó là lý do browser prototyping quan trọng đến vậy. Như Matthias Ott từng viết, browser không chỉ là nơi sản phẩm kết thúc. Nó còn là nơi ý tưởng nên được khám phá.

Làm việc trực tiếp trong browser cho phép team phát hiện edge case sớm hơn, hiểu platform behavior nhanh hơn và test interaction thực tế hơn. Điều này cũng rất gần với thứ Jeremy Keith gọi là declarative design: thiết kế dựa trên grain của platform thay vì liên tục chống lại nó.

Những sản phẩm được hình thành theo cách này thường resilient hơn, accessible hơn, performant hơn và dễ evolve theo thời gian hơn. Nhưng browser prototyping vẫn chưa hoàn toàn giải quyết perception gap.

Ngay cả khi designer và engineer cùng nhìn vào một browser window, họ vẫn chú ý tới những thứ khác nhau. Medium đã shared, nhưng mental model thì chưa.

---

Người nghệ sĩ biết build

Năm 1919, tức hai mươi mốt năm sau khi Taylor tới Bethlehem Steel, một kiến trúc sư tên là Walter Gropius thành lập trường Bauhaus ở Đức.

Triết lý của Bauhaus gần như đối lập hoàn toàn với sự tách biệt mà Taylor cổ vũ. Tại Bauhaus, artist và craftspeople học cùng nhau. Người định hình vision cũng đồng thời hiểu material mình đang làm việc với.

Không tồn tại ranh giới cứng giữa design và execution. Như Gropius từng viết:

“The ultimate goal of all art is the building!”

Trong khi đó, phần lớn tổ chức phần mềm hiện đại lại thừa hưởng mô hình của Taylor. Nhưng Gropius hiểu một điều cực kỳ quan trọng: những sản phẩm mạnh nhất xuất hiện khi thinking và making vẫn được kết nối chặt chẽ.

Tôi đã trải nghiệm điều này rất nhiều lần trong công việc của mình. Khi thiết kế layout, tôi đã đồng thời nghĩ tới cách CSS hoạt động ở nhiều viewport size khác nhau và chuyện gì xảy ra khi placeholder text được thay bằng content thật. Khi viết CSS, tôi vẫn đang đưa ra design decision về spacing, rhythm, proportion và timing.

Đây không phải hai hoạt động tách biệt. Chúng chỉ là cùng một quá trình được nhìn từ hai góc khác nhau.

Và khi cả hai perspective cùng tồn tại, những khả năng hoàn toàn mới bắt đầu xuất hiện. Một designer hiểu CSS Grid, container queries và browser behavior sẽ tưởng tượng ra interface khác hoàn toàn so với người chỉ làm việc trong design tool tĩnh. Một engineer hiểu compositional intent cũng sẽ bắt đầu ưu tiên motion, hierarchy và interaction quality theo cách khác.

Đó mới là sức mạnh thật sự của design engineer role. Không đơn giản là “designer biết code” hay “engineer có gu thẩm mỹ”, mà là người có thể suy nghĩ về composition và structure cùng một lúc.

Khi team có những người như vậy, khoảng cách giữa design intent và shipped reality thu hẹp lại đáng kể. Không phải vì communication suddenly trở nên hoàn hảo, mà vì ít decision bị rơi vào khoảng trống giữa các discipline hơn.

Design engineer trở thành người giữ cả hai perspective cùng lúc.

Theo nhiều cách, đây chính là ý tưởng của Gropius được áp dụng cho web hiện đại: artist biết build, builder hiểu design và người xem design với engineering như một quá trình judgment liên tục thay vì hai phase riêng biệt.

Và judgment hiện tại quan trọng hơn bao giờ hết.

AI ngày càng có thể automate execution. Nó có thể generate boilerplate, scaffold component, tạo layout và tăng tốc implementation. Nhưng thứ AI vẫn cực kỳ khó replicate là cross-disciplinary judgment.

Khả năng đồng thời hiểu composition, structure, aesthetics, constraints, accessibility và human behavior đang trở nên giá trị hơn chính vì nó rất khó để tự động hóa.

---

Ai sở hữu khoảng trống giữa design và reality?

Vấn đề này không có giải pháp đơn giản. Tổ chức luôn messy. Team luôn có history. Và mối quan hệ giữa design với engineering thường mang theo nhiều năm frustration tích lũy.

Nhưng điều quan trọng là phải nhìn thẳng vào nguồn gốc của tension.

Một phần đến từ structure: giả định rằng design kết thúc trước khi engineering bắt đầu. Phần còn lại đến từ cognition: designer và engineer thực sự perceive sản phẩm theo cách khác nhau.

Structural problem cần structural fix. Team cần prototype trong browser, giảm handoff và thiết kế trực tiếp trong medium thực tế.

Cognitive problem lại cần thứ khác: shared vocabulary, shared context, shared ownership và những người có khả năng bridge cả hai thế giới.

Lý tưởng nhất là team mạnh sẽ đầu tư vào cả hai.

Và câu hỏi quan trọng nhất là: ai đang sở hữu khoảng trống giữa design intent và shipped reality?

Ai là người đảm bảo rằng thứ được build vẫn tôn trọng platform, real constraints, real users và vision ban đầu?

Khi một team thực sự có câu trả lời cho câu hỏi đó, sự khác biệt sẽ rất rõ ràng. Sản phẩm polished hơn, accessible hơn, maintainable hơn và ít tốn chi phí rework hơn rất nhiều.

Taylor tách thinking khỏi execution vì ông tin rằng điều đó làm công việc hiệu quả hơn. Gropius đưa chúng trở lại cùng nhau vì ông tin rằng điều đó khiến sản phẩm trở nên trọn vẹn hơn. Và web cho chúng ta quyền lựa chọn giữa hai mô hình đó.

Ngày nay, khoảng cách giữa một ý tưởng và một sản phẩm hoạt động được chưa bao giờ nhỏ đến vậy. Người tưởng tượng ra layout cũng có thể cảm nhận resistance của material, còn người thiết kế interaction cũng có thể hiểu system đang vận hành phía dưới.

Có lẽ đó vốn luôn là cách việc xây dựng cho web nên hoạt động.

Design và engineering, là một.

❦