Bài 1: Mình từng nghĩ designer là người vẽ đẹp — sai hoàn toàn

Hồi mới vào nghề, mình cũng hiểu sai

Bạn có từng nghĩ designer là người ngồi vẽ đẹp, chọn màu, canh font — rồi giao cho dev code?

Mình cũng vậy. Hồi mới ra trường, mình nghĩ công việc designer là mở Photoshop lên, kéo thả cho đẹp mắt, export file rồi gửi. Xong. Hết việc.

Rồi mình vào team product đầu tiên. Tuần đầu, PM hỏi: "Flow onboarding này bạn test với user chưa?". Mình đứng hình. Test gì? Mình chỉ vẽ UI thôi mà?

Đó là lúc mình nhận ra: designer trong team product không chỉ vẽ — mà phải hiểu người dùng, hiểu business, và nói cùng ngôn ngữ với dev.

Nếu bạn đang chuẩn bị vào nghề, hoặc đang làm nhưng cảm thấy mình chỉ là "thợ vẽ" — bài này sẽ giúp bạn nhìn lại toàn bộ.

5 công việc thật sự của designer trong team product

Nhiều bạn nghĩ designer chỉ làm 1 việc: vẽ giao diện. Thực tế, trong một team product chạy Agile, designer đảm nhận ít nhất 5 vai trò:

1. Nghiên cứu người dùng (User Research)

Trước khi mở Figma, designer cần biết ai dùng sản phẩm và họ đang gặp vấn đề gì. Không phải đoán — mà phỏng vấn, quan sát, đọc data.

Mình từng nhận brief: "Thiết kế trang pricing". Thay vì vẽ ngay, mình hỏi: "User nào đang rời trang pricing nhiều nhất? Tại sao?" — câu hỏi đó thay đổi hoàn toàn hướng thiết kế.

2. Định nghĩa vấn đề (Problem Framing)

Designer giỏi không phải người vẽ nhanh — mà là người hỏi đúng câu hỏi. PM nói "cần thêm tính năng X", designer hỏi lại: "User thật sự cần giải quyết vấn đề gì? Có cách nào đơn giản hơn không?"

3. Thiết kế flow và wireframe

Đây mới là phần "vẽ" — nhưng không phải vẽ đẹp, mà vẽ logic. User vào trang → bấm nút nào → thấy gì → kết thúc ở đâu?

Wireframe xấu hoàn toàn OK. Quan trọng là flow có logic và không bỏ lỡ edge case (trường hợp ngoại lệ).

4. Thiết kế giao diện (UI Design)

Phần này ai cũng biết: chọn màu, canh spacing, dùng đúng component. Nhưng có 1 thứ mà ít ai nói tới — UI tốt là UI mà dev nhìn vào biết code ngay, không cần hỏi lại 10 lần.

Mình từng giao file Figma mà dev phải DM hỏi: "Cái spacing này bao nhiêu? Hover state đâu? Responsive thế nào?". Sau đó mình học được: giao diện rõ ràng cho dev = ship nhanh gấp đôi.

5. Kiểm tra và cải thiện (Testing & Iteration)

Design không bao giờ "xong" sau 1 lần. Giao cho dev → test lại trên thiết bị thật → nhận feedback từ user → sửa. Vòng lặp này chạy liên tục.

Tại sao dev hiểu design thì ship nhanh gấp đôi?

Đây là điều mình nhận ra sau vài năm làm việc với nhiều team khác nhau.

Team mà dev không hiểu design:

• Designer giao file → dev code khác hoàn toàn → designer chỉnh lại → dev sửa → vòng lặp 3-4 lần

• Spacing sai, responsive vỡ, hover state thiếu — toàn bug nhỏ nhưng tốn thời gian

• PM stress vì deadline trễ, không ai hiểu tại sao

Team mà dev hiểu design:

• Dev nhìn file Figma → hiểu ngay logic spacing, hiểu tại sao button ở đó, biết edge case nào cần xử lý

• Ít phải qua lại sửa — first pass đã gần đúng 90%

• Designer có thời gian nghiên cứu sâu thay vì chữa cháy

Nếu bạn là dev đang đọc bài này: chỉ cần hiểu 3 thứ — spacing system, color token, và component state — bạn đã khác biệt rồi.

Nếu bạn là designer: hãy tập giải thích design choice cho dev bằng ngôn ngữ kỹ thuật. Không cần biết code — chỉ cần nói được "cái này 8px vì nằm trong cùng group", "cái này dùng primary color vì là CTA chính".

Vậy bạn đang ở đâu trên bản đồ này?

Tự hỏi thật lòng:

• Bạn chỉ đang vẽ giao diện, hay bạn đang giải quyết vấn đề?

• Bạn có hỏi "tại sao" trước khi mở Figma, hay bạn nhận brief rồi vẽ ngay?

• Dev trong team bạn có hiểu file design của bạn không — hay phải hỏi đi hỏi lại?

Nếu bạn trả lời "chưa" cho bất kỳ câu nào — không sao cả. Mình cũng từng vậy. Cả series này mình viết để giúp bạn chuyển từ "thợ vẽ" sang designer thật sự — từng bước một.

Takeaway

• Designer trong team product có 5 công việc chính — vẽ giao diện chỉ là 1 trong 5

• Trước khi mở Figma, luôn hỏi: "User đang gặp vấn đề gì?"

• Dev hiểu design = team ship nhanh hơn, ít bug UI, ít qua lại sửa

• 3 thứ dev nên hiểu: spacing system, color token, component state

• Design không bao giờ "xong" — test, nhận feedback, sửa, lặp lại

→ Đọc thêm: Tư duy UX — Tập 01 — nếu bạn muốn hiểu sâu hơn về cách designer nghiên cứu người dùng.

👉 Tập tiếp theo: Bạn không cần talent — bạn cần 15 phút "tập nhìn" mỗi ngày — 3 bài tập quan sát UI mà dân senior đều làm, không cần học trường, không cần talent bẩm sinh.