Làm trong nghề UX/UI ta nói rất nhiều đến user-friendly, nhưng mình có lãng quên very first user xem design của bạn là các stakeholder không, nếu bạn làm việc với business sẽ là cách bạn trình bày problem solving, design proposal, còn phía dev sẽ là file hand-off & design spec.

"Engineer-friendly" trong design là một khái niệm đề cập đến việc thiết kế giao diện và sản phẩm theo cách giúp đội ngũ kỹ sư (developers) dễ dàng hiểu, triển khai, và phát triển sản phẩm. Một thiết kế được coi là engineer-friendly khi nó giảm thiểu sự mơ hồ, tối ưu quy trình làm việc giữa designer và developer, và đảm bảo rằng các giải pháp thiết kế có thể được thực thi hiệu quả về mặt kỹ thuật.

Khi thiết kế UI chia các thành phần theo từng block một, sử dụng auto layout như cách thức box model đã khiến dev đỡ mệt mỏi phần nào rồi đó.

Chắc bạn sẽ quen thuộc với user flow, screen flow khi design UX/UI, nó là một phần trong việc bạn transfer lại logic sử dụng cho dev hình dung, ngoài ra nếu tìm hiểu sâu hơn, mình sẽ có use case để mô tả kĩ hơn như Preconditions, Postconditions, Workflow… (còn muốn nhức nhói hơn nữa, mò thử UML qua bài này nhé)

Note: có khi các edge case mình sẽ không thể cover hết, nếu ngay khi có wireframe bạn có thể gửi ngay cho dev để họ hình dung & giúp bạn aware sớm các edge case cũng như các constraints có thể xảy ra.

Ngoài ra mình còn cần lưu ý note thêm các rule hiển thị / interaction như min-max width, motion, min-max characters / lines, auto dismiss, time out,… Càng rõ ràng càng tốt, không thì phía dev phải đoán già đoán non & dẫn đến bản build khác xa với design expectation.

Mình đã từng gặp qua vài trường hợp, nghĩ là nên có thông tin này, thông tin kia nhưng khi bàn giao cho dev, thì gặp phải tình huống phía database đang không hề có dữ liệu đó hoặc để có dữ liệu đó cần phải tốn effort chạy thêm sẽ ảnh hưởng đến app performance… Nên keep in mind, từng dòng chữ, từng hình, từng status, nếu mình không sure đều nên check với dev sớm.

Mặt khác phải luôn hình dung trong đầu các tình huống thực tế liên quan đến data, ví dụ: nếu không có dữ liệu thì sẽ hiển thị ra sao, nếu không lấy được data từ sever thì sao, nếu text quá dài hay hình không phù hợp thì xử lý hiển thị ra sao,…?

Tips: learn python, SQL, Notion database 😃

Chắc ai cũng như mình, khá là ngán ngẫm phải đi đặt tên cho từng layer 😐. Nhưng nếu bạn đã trải qua cảm giác đi xem một file design cũ của ai đó hand over lại, bạn sẽ hiểu được tầm quan trọng của việc đặt tên HOẶC khi bạn build design system thì mới thấy tính cần thiết của nó.

Nói riêng việc naming này chắc dong dài lắm, nên mình share vài hint để bạn explore thêm nếu thấy cần nhé:

Phía dev luôn muốn tối ưu tái sử dụng nhiều nhất có thể, và phía design mình cũng có concept giống vậy, đó là design system.

Design system không những giúp tiết kiệm thời gian để build mà còn giúp thiết kế có tính consistent, một tính chất rất quan trọng trong UX.

So cố gắng suy nghĩ UI của bạn as a system, tái sử dụng nhiều nhất có thể.

Nhiều khi mình tham khảo các reference hoặc các app khác, mình sẽ tìm được đâu đó các idea để muốn apply vào design của mình, có thể là animation, là một interaction hoặc một function nào đó, nhưng khi đem ra hỏi dev thì bảo frameworks mình không support, cần time để mò thêm…

Nên để tiết kiệm thời gian cho đôi bên, mình cần trước tiên hiểu họ đang build trên framework nào & tìm reference cho phù hợp.

Ví dụ: Tailwind CSS, Bootstrap, React, Next JS, Swift,…

Về asset, bạn có thể hỏi dev cung cấp cho bạn để xuất cho phù hợp, hoặc khoẻ hơn thì hướng dẫn họ cách export trên Figma.

Mình có thể lưu ý cài điểm sau: