Người Kỹ Sư Có Thể “Nhìn” Được Thiết Kế

Năm 2002, chỉ vài tuần sau khi bắt đầu công việc mới, tôi đã trải qua một khoảnh khắc thay đổi hoàn toàn cách mình nhìn về nghề kỹ sư phần mềm.

Đó là công việc thứ hai của tôi sau khi tốt nghiệp đại học. Tôi làm frontend engineer tại AKQA, một creative agency ở London. Khi ấy tôi vừa hoàn thành một trong những task đầu tiên: build một trang mới cho khách hàng. Tôi nghĩ nó trông rất ổn. Vì vậy tôi báo với designer rằng mọi thứ đã xong.

Một lúc sau, tôi nghe thấy anh ấy gọi trong phòng engineering.

Den? Where’s Den?

Anh ấy bước tới bàn tôi, mở Photoshop, rồi đặt screenshot từ phần tôi build lên một layer và file thiết kế gốc lên layer khác. Sau đó anh giảm opacity xuống.

Khác biệt hiện ra ngay lập tức.

Spacing lệch nhẹ. Alignment không khớp. Typography render khác. Visual balance bị chệch đi.

Không có lỗi nào quá lớn. Nhưng tất cả cộng lại khiến cảm giác của sản phẩm hoàn toàn khác với thiết kế ban đầu.

Tôi thực sự đã nghĩ chúng giống hệt nhau.

Khoảnh khắc đó thay đổi cách tôi làm engineering mãi mãi. Nó không đơn thuần là học thêm một kỹ năng mới. Nó là học một cách nhìn khác: nhìn thứ mình build bằng con mắt của designer thay vì chỉ bằng góc nhìn của chính mình.

Kể từ ngày đó, tôi dần tin rằng khoảng cách giữa design intent và sản phẩm được ship là một trong những vấn đề lâu đời nhất nhưng cũng bị đánh giá thấp nhất trong ngành phần mềm.

---

Khoảng cách đó tồn tại ở khắp nơi

Gần đây, Brian Lovin từ Notion đã viết về việc tuyển dụng những người mà anh gọi là “design-minded frontend engineers.”

Điều anh ấy mô tả là vấn đề mà gần như cả ngành đều gặp phải.

Có những engineer biết code. Có những designer biết thiết kế. Nhưng engineer có thể giữ nguyên design intent khi biến nó thành sản phẩm thực tế? Số lượng đó cực kỳ hiếm.

Và đây không chỉ là vấn đề của frontend hay web.

Mobile app thường lệch khỏi thiết kế ban đầu. Embedded systems trong xe hơi, ATM, thiết bị y tế hay POS terminal cũng thường mất đi sự nhất quán giữa concept và implementation.

Bất kỳ nơi nào con người tương tác với phần mềm, ở đó engineer sẽ là người chịu trách nhiệm thu hẹp khoảng cách giữa thứ được thiết kế và trải nghiệm thực tế của người dùng.

Điều đáng chú ý là ngành đã nói về chuyện này rất lâu nhưng thay đổi lại rất ít.

Designer đã viết rất nhiều về:

• engineer làm sai thiết kế khi implement
• vấn đề trong quá trình handoff
• sự đổ vỡ trong collaboration giữa design và engineering

Nhưng phần lớn những cuộc thảo luận đó diễn ra trong cộng đồng design.

Thực tế là designer không thể tự giải quyết vấn đề này một mình, vì cuối cùng engineer mới là người biến ý tưởng thành sản phẩm thực tế.

Và đây cũng không phải vấn đề mới xuất hiện cùng design system hay component library. Nó đã tồn tại từ ngày đầu tiên designer đưa mockup cho engineer rồi nhận lại thứ gì đó “gần đúng” nhưng vẫn không thật sự đúng.

Điểm quan trọng là: đây không phải vấn đề vô nghiệm. Khả năng thu hẹp khoảng cách đó hoàn toàn có thể học được.

---

“Design-minded” thực sự nghĩa là gì?

Design không phải mockup.

Design là trải nghiệm người dùng có được khi sử dụng sản phẩm đã ship.

Engineer chính là người biến design intent thành trải nghiệm đó. Mockup chỉ là lời hứa. Cảm giác người dùng có khi tương tác mới là thứ thực sự tồn tại.

Một hướng tiếp cận phổ biến là vai trò Design Engineer.

Đó là người vừa thiết kế vừa build.

Matthias Ott từng viết rất thuyết phục về design engineering như giải pháp cấu trúc cho khoảng cách giữa design và implementation. Những công ty như Linear hay Vercel đã khiến vai trò này trở nên nổi tiếng.

Nhưng đó cũng là một giải pháp “xa xỉ”. Không phải công ty nào cũng có khả năng tuyển được những người như vậy.

Ngay cả ở các công ty có design engineer, vẫn cần những engineer bình thường nhưng biết implement sản phẩm một cách cẩn thận.

Ott đang nói về một role. Còn tôi đang nói về một capability.

Hãy xem nó như phiên bản “dân chủ hóa” của design engineering: thứ mà mọi engineer làm sản phẩm hướng người dùng đều có thể phát triển.

Đó là design-minded engineer.

Không phải title mới. Mà là một cách làm việc.

Một design-minded engineer không cố trở thành designer. Công việc của họ không phải tạo ra design direction mới.

Nhiệm vụ của họ là:

• áp dụng design intent hiện có,
• và extrapolate nó một cách thông minh.

Kết quả lý tưởng là:

Designer nhìn vào sản phẩm cuối cùng và không thể xác định rõ ranh giới nơi file thiết kế kết thúc và judgment của engineer bắt đầu.

Lời khen lớn nhất dành cho một design-minded engineer chính là sự im lặng từ designer.

Vì im lặng nghĩa là bạn đã làm đúng.

Đây không phải chuyện engineer trở thành designer. Designer vẫn thiết kế. Engineer vẫn build.

Nhưng engineer build với design judgment sẽ ship một sản phẩm hoàn toàn khác với engineer chỉ quan tâm nó “chạy được”.

Apply và extrapolate. Đừng originate.

Đó là design-minded engineering.

“Mockup chỉ là lời hứa. Cảm giác trải nghiệm mới là thứ thực sự được ship.”

Ba góc nhìn để đánh giá mọi thiết kế

Trong suốt sự nghiệp của mình, từ agency work tại AKQA cho Nike và Ferrari, tới hệ thống e-commerce toàn cầu tại Volvo, rồi accessibility và animation work ở Canva, tôi dần xây dựng một framework cho cách engineer nên tiếp cận design.

Mọi thứ xoay quanh ba góc nhìn.

1. User behavior

Người dùng thực sự sẽ làm gì với thứ này?

Không phải trong điều kiện lý tưởng. Không phải trong trạng thái hoàn hảo của mockup. Mà là ngoài đời thực.

Designer thường thiết kế quanh một trạng thái “happy path”. Engineer phải xử lý thế giới hỗn độn phía sau nó.

Localized strings làm layout thay đổi. Right-to-left language đảo ngược interface. Người dùng tương tác với sản phẩm trên mạng yếu, thiết bị cũ, tàu điện đông người hoặc trong những flow checkout đầy áp lực.

Design-minded engineer nhìn thấy những vấn đề đó trước khi chúng trở thành production bug.

2. Performance

Người dùng đang phải trả cái giá gì mà mockup không thể hiện ra?

Prototype có thể trông cực kỳ mượt mà, nhưng nếu sản phẩm ship thực tế có input latency 80ms thay vì 16ms, người dùng sẽ cảm nhận được ngay cả khi họ không biết diễn tả nó bằng lời.

Samsung từng tái tạo gần như hoàn hảo về mặt hình ảnh hiệu ứng pinch-to-zoom của Apple. Nhưng interaction vẫn tạo cảm giác “sai” vì engineering phía dưới không giữ được trải nghiệm mà thiết kế hứa hẹn.

Performance cũng là một quyết định thiết kế. Và engineer là người duy nhất có thể biến nó thành thật.

3. Accessibility

Ai đang bị loại khỏi trải nghiệm này?

Accessibility thường bị xem như compliance work, trong khi nó thực sự là tín hiệu cho chất lượng engineering và mức độ quan tâm tới người dùng.

Pass WCAG không có nhiều ý nghĩa nếu trải nghiệm screen reader thực tế vẫn tệ.

Bật VoiceOver lên và tự điều hướng sản phẩm của mình mới là thứ quan trọng.

Ba góc nhìn này không phải công cụ để phản đối designer. Ngược lại, chúng là cách engineer có được vị trí trong các cuộc thảo luận về design.

Chúng cho thấy engineer thực sự quan tâm tới trải nghiệm cuối cùng của người dùng.

---

Engineer cũng là người đóng góp sáng tạo

Design-minded engineering không chỉ mang tính phân tích. Nó còn liên quan tới đóng góp sáng tạo.

Engineer thường nhìn thấy những khả năng mà designer chưa nhìn thấy.

Khi CSS container queries xuất hiện, khi view transitions trở nên stable, hay khi animation APIs của SwiftUI mở ra những interaction mới trên iOS, đó không chỉ là milestone kỹ thuật.

Chúng mở rộng khả năng sáng tạo của interface.

Tại AKQA, không lâu sau khi CSS có cubic-bezier() cho easing curve tùy chỉnh, tôi từng làm một project cho Ferrari nơi nhóm build animation timing dựa trên telemetry data thật từ xe đua.

Những ý tưởng kiểu đó chỉ xuất hiện khi engineer tham gia trực tiếp vào quá trình sáng tạo thay vì ngồi đợi handoff.

Designer bị giới hạn bởi những gì họ nghĩ platform có thể làm. Design-minded engineer hiểu platform thực sự có thể làm gì.

Việc liên tục cập nhật platform capability sẽ thay đổi “creative ceiling” của cả team.

---

Những trạng thái không ai thiết kế

Một trong những ý tưởng thực tế nhất trong framework này là gap states.

Mockup thường chỉ hiển thị happy path.

Trang load thành công. Data tới đúng lúc. Người dùng đã đăng nhập. Mọi thứ vừa khít hoàn hảo.

Nhưng sản phẩm thực tế không tồn tại trong trạng thái lý tưởng.

Chúng cần:

• loading states,
• error states,
• empty states,
• offline fallback,
• optimistic updates,
• expired sessions,
• permission failures,
• localization edge cases,
• skeleton screens.

Đây không phải những chi tiết phụ. Với rất nhiều người dùng, những trạng thái này chính là trải nghiệm sản phẩm thực tế.

Engineer đặt câu hỏi “màn hình này sẽ trông thế nào nếu không có data?” trước khi rời design review chính là người đang làm design-minded engineering.

Mức độ chăm chút dành cho những khoảnh khắc chuyển tiếp này thường quyết định sản phẩm tạo cảm giác polished hay unfinished.

“Lời khen lớn nhất dành cho một design-minded engineer là sự im lặng từ designer.”

Đôi khi chẳng có thiết kế nào cả

Mọi thứ ở trên đều giả định rằng đã tồn tại một thiết kế.

Nhưng sớm hay muộn, engineer nào cũng gặp những tình huống mà design direction gần như không tồn tại:

• feature phải ship trước khi designer kịp tham gia,
• prototype phải build từ business requirement thô,
• hoặc cả team tạm thời không có designer.

Tôi đã trải qua cả hai thái cực đó.

Tôi từng được giao raw business requirement và phải build thứ gì đó có chủ đích mà không có bất kỳ design input nào.

Ở Volvo, trước khi có design system chính thức, tôi từng dành sáu tháng build trải nghiệm cho hơn 70 thị trường gần như không có sự hỗ trợ trực tiếp từ designer.

Những tuần đầu tiên cực kỳ khó khăn.

Khi không còn design reference, mọi quyết định nhỏ đều suddenly trở nên nặng nề.

Font size này có đúng không? Spacing như vậy đã hợp lý chưa? Hierarchy này thực sự rõ ràng hay chỉ quen mắt vì mình nhìn quá lâu?

Không có mockup để đối chiếu. Không có designer để hỏi. Chỉ còn lại judgment tích lũy qua nhiều năm.

Lúc đó, ba góc nhìn trở thành chiếc neo của tôi.

User behavior trước tiên. Người dùng ở những thị trường khác nhau thực sự sẽ trải nghiệm điều này ra sao?

Tiếng Đức làm layout dài thêm. Tiếng Ả Rập đảo hướng đọc. Checkout flow trên desktop sẽ hoạt động rất khác khi dùng bằng điện thoại tại Saudi Arabia.

Performance đứng thứ hai. Người dùng thật đang cầm thiết bị gì? Không phải chiếc MacBook Pro mạnh mẽ trên bàn tôi, mà là chiếc Android tầm trung với kết nối mạng chập chờn.

Accessibility đứng thứ ba. Ai sẽ bị loại khỏi trải nghiệm nếu implementation này thất bại?

Ba góc nhìn đó không thay thế designer. Nhưng chúng tạo ra cấu trúc để đưa ra quyết định có nguyên tắc.

Khi một visual choice không thể giải thích hợp lý, tôi chọn hướng an toàn. Reuse pattern cũ. Extrapolate từ những gì designer từng thiết lập thay vì phát minh thứ hoàn toàn mới.

Sự kiềm chế đó là một trong những phần khó nhất.

Khi design guidance biến mất, engineer thường muốn lấp đầy khoảng trống sáng tạo để chứng minh mình có thể làm cả hai vai trò.

Nhưng đó thường là instinct sai.

Mục tiêu là continuity. Không phải reinvent.

Mỗi lần định đưa ra quyết định quá táo bạo, tôi lại tự hỏi:

“Nếu designer ở đây, quyết định này có khiến họ bất ngờ không?”

Nếu câu trả lời là có, tôi lùi lại.

Khi designer quay lại review, feedback nhận được chỉ là những chỉnh sửa nhỏ. Không phải “anh đang làm cái gì vậy?”. Chỉ là refinement.

Trải nghiệm đó củng cố toàn bộ framework này với tôi.

Đồng thời nó cũng cho thấy nơi design instinct khó replicate nhất: những quyết định cực nhỏ về spacing, proportion, weight và balance mà designer thường nhìn ra ngay lập tức.

Design-minded engineering có thể đưa bạn tới rất gần. Hiểu được nơi “rất gần” vẫn chưa đủ gần cũng là một phần của kỹ năng.

---

Những anti-pattern quen thuộc của ngành

Một phần của việc phát triển design fluency là học cách nhận ra nơi mọi thứ bắt đầu sai.

Ngành phần mềm không thiếu ví dụ:

• redesign của Snapchat năm 2018,
• thời kỳ hamburger menu ở khắp nơi,
• dark patterns tối ưu conversion nhưng phá hỏng trust,
• UI do AI tạo ra nhìn hợp lý nhưng hoạt động vô cùng incoherent.

Hamburger menu là ví dụ rất thú vị.

Ở thời điểm đó, nó trông như một giải pháp engineering cực kỳ thông minh. Màn hình mobile nhỏ. Navigation chiếm chỗ. Vậy thì ẩn hết sau một icon.

Vấn đề được giải quyết.

Nhưng user behavior liên tục cho thấy điều ngược lại: người dùng hiếm khi tương tác với thứ họ không nhìn thấy.

Những feature nằm trong hamburger menu thường có engagement thấp hơn đáng kể.

Logic engineering phía sau giải pháp hoàn toàn hợp lý. Nhưng nó thất bại trước hành vi con người.

Vai trò của design-minded engineer trong tình huống như vậy không phải tranh cãi cảm tính về aesthetic. Mà là nhận ra khi một quyết định hợp lý về mặt kỹ thuật lại đi ngược với cách người dùng thực sự tương tác.

“Apply và extrapolate. Đừng originate.”

AI khiến điều này càng trở nên quan trọng

AI đang khiến việc generate UI code trở nên dễ hơn bao giờ hết. Một interface hoạt động được có thể xuất hiện chỉ sau vài phút.

Và đó chính là lý do design judgment quan trọng hơn bao giờ hết.

AI là công cụ cực kỳ mạnh với design-minded engineer. Nó có thể:

• generate localization variants,
• simulate gap states,
• tạo prototype nhanh,
• phát hiện accessibility issues trước design review.

Nhưng AI không thể đánh giá đáng tin cậy xem thứ gì thực sự “feel right”.

Nó không biết animation đang cải thiện interaction hay chỉ đơn thuần trang trí.

Nó không hiểu rằng loading state kéo dài 200ms trên mạng mạnh có thể trở nên khó chịu trên một chuyến tàu với sóng yếu.

Rủi ro lớn hơn không phải chuyện AI thay thế designer.

Rủi ro thực sự là engineer bắt đầu outsource cả design judgment.

Cần error state? Hỏi AI. Cần loading copy? Generate tự động. Cần mobile behavior? Prompt vài phương án rồi chọn cái có vẻ hợp lý.

Từng quyết định riêng lẻ có thể trông ổn. Nhưng cộng dồn lại, chúng tạo ra sản phẩm không có coherence, không có perspective và không cho thấy bất kỳ ai thật sự suy nghĩ sâu về trải nghiệm người dùng.

Design-minded engineer trở thành đối trọng cho xu hướng đó.

Họ là người đặt câu hỏi:

• Điều này có phản ánh user behavior thật không?
• Performance cost là gì?
• Ai đang bị loại khỏi trải nghiệm?

Đó là những câu hỏi cần judgment. Không phải prompt tốt hơn.

Execution có thể tăng tốc. Judgment thì không.

---

Design fluency là thứ có thể học được

Sau hơn 25 năm làm việc trong những môi trường engineering cực kỳ chú trọng design, tôi nhận ra một điều:

Design fluency không phải năng khiếu bẩm sinh.

Nó là kỹ năng.

Một kỹ năng có thể luyện tập, phát triển và cải thiện theo thời gian.

Engineer bắt đầu chú ý tới spacing inconsistency ở những năm đầu sự nghiệp rồi dần nhận ra hierarchy problem. Sau đó họ bắt đầu phát hiện interaction pattern sai trước cả designer. Cuối cùng họ trở thành kiểu engineer mà designer muốn có mặt trong những quyết định sản phẩm khó nhất.

Không điều nào xảy ra trong một đêm.

Mọi thứ bắt đầu từ một quyết định rất đơn giản:

Quan tâm tới thứ mình build vượt ra ngoài việc nó “chạy được”.

Những lỗi tôi phát hiện được trong code review hôm nay sẽ hoàn toàn vô hình với phiên bản của tôi năm 2002.

Designer ở AKQA, người từng overlay hai layer Photoshop lên nhau ngày đó, đã dạy tôi cách thực sự nhìn.

Khả năng đó không phải talent. Nó là perception được rèn luyện.

Và những engineer phát triển được khả năng đó cuối cùng sẽ trở thành kiểu engineer mà designer không còn phải chạy theo nữa.