Trải qua những năm tháng đầu sự nghiệp, tôi thường tự hỏi điều gì tạo nên sự khác biệt giữa các designer cấp độ Junior, Senior và Lead. Nhìn lại, tôi nhận ra sự trưởng thành của mình không chỉ nằm ở việc nâng cao tay nghề. Nó đến từ việc cải thiện cách tôi làm việc, tư duy, giao tiếp và tương tác với mọi người.
Dưới đây, tôi đã tóm tắt 7 thói quen mà theo kinh nghiệm của tôi thể hiện sự trưởng thành (seniority) trong thiết kế. Cùng với từng thói quen, tôi cũng đưa ra gợi ý “Cách thực hiện” để giúp bạn áp dụng các phương pháp này vào thực tế. Hãy xem bạn đã áp dụng được bao nhiêu thói quen rồi nhé!
1. Bắt đầu từ mục tiêu (Outcome), không phải sản phẩm bàn giao (Output)
Những năm đầu sự nghiệp, lời khen tôi nhận được nhiều nhất là giao bài nhanh. Sau này, đồng nghiệp cũng đánh giá cao kỹ năng thiết kế của tôi. Nhưng khi tôi trình bày công việc với quản lý, sếp tôi nói: “hunkydo, tôi thấy những gì bạn tạo ra rồi (output), nhưng kết quả tôi muốn đạt được (outcome) là gì?” Sau một thời gian học về business design, tôi nhận ra một thiết kế tốt không chỉ dừng lại ở giao diện — nó cải thiện chỉ số kinh doanh, nâng cao trải nghiệm người dùng hoặc giải quyết một vấn đề thực tế.
Cách thực hiện: Trước khi thiết kế, hãy thống nhất với team về các câu hỏi sau:
– Hành vi người dùng hoặc chỉ số kinh doanh cụ thể nào mà chúng ta đang cố gắng thay đổi?
– Làm sao để biết chúng ta thành công sau khi ra mắt?
– Nỗ lực tối thiểu cần có để đạt được kết quả đó là gì?
2. Hỗ trợ doanh nghiệp đưa ra quyết định — Đừng chỉ thụ động chờ đợi
Trước đây, tôi cảm thấy mọi thứ đều phụ thuộc vào quyết định của phía kinh doanh. Hiện tại, tôi đã có thể đưa ra sự đánh đổi (trade-offs) giữa các giải pháp khác nhau để giúp doanh nghiệp ra quyết định. Tôi sử dụng con số và thuật ngữ kinh doanh để củng cố luận điểm của mình, chẳng hạn như tỷ lệ bỏ dở (drop-off rate) hay tỷ suất hoàn vốn ước tính (ROI).
Cách thực hiện: Trao đổi với nhóm kinh doanh, bộ phận phân tích dữ liệu, các lập trình viên và chạy thử nghiệm với người dùng. Sau đó, tổng hợp tất cả lên một slide để hỗ trợ cho đề xuất của bạn.
3. Thống nhất với lập trình viên (Developer) từ sớm
Đôi khi chúng ta dễ bị cuốn vào thế giới thiết kế riêng và quên kết nối sớm với các lập trình viên. Khi điều đó xảy ra, phạm vi công việc có thể bị phình to hoặc giải pháp đưa ra lại không khả thi về mặt kỹ thuật. Hiện tại, chúng tôi luôn chia sẻ một vài bản nháp ban đầu với lập trình viên để hiểu giải pháp nào khả thi và mỗi phương án mất bao nhiêu công sức triển khai.
Cách thực hiện: Chia sẻ các bản thiết kế nháp sớm và thường xuyên. Sử dụng wireframe và làm rõ rằng đây mới là giai đoạn đầu. Nhờ team ước tính công sức triển khai và rủi ro kỹ thuật cho từng phương án.
4. Yêu cầu phản hồi có trọng tâm
Khi muốn xin ý kiến từ các bên liên quan (stakeholders), tôi từng hỏi: “Mọi người thấy nó thế nào?” Tôi từng nghĩ câu hỏi đó mang lại sự tự do và thể hiện sự tôn trọng ý kiến của họ. Tuy nhiên, kết quả thường là những cuộc thảo luận kéo dài vô tận, khiến dự án trễ tiến độ. Hiện tại, tôi đã học được cách đưa ra yêu cầu cụ thể hơn về phản hồi mình cần.
Cách thực hiện: Sử dụng đúng cấu trúc này khi chia sẻ công việc:
“Bản thiết kế này đang ở giai đoạn [Tên giai đoạn]. Tôi đang cần nhận phản hồi cụ thể về [X]. Hiện tại tôi chưa cần phản hồi về [Y].”
5. Thường xuyên nhìn lại mục tiêu ban đầu
Tôi rất cởi mở với phản hồi từ stakeholders — đôi khi là quá đà. Chúng tôi từng có một dự án với mục tiêu ban đầu là cải thiện tính khả dụng (accessibility). Nhưng ngay sau đó, chúng tôi nhận ra có quá nhiều thứ có thể cải thiện thêm trong luồng người dùng, tính tiện dụng, nội dung và pattern thiết kế. Một dự án nhỏ đã biến thành một “gã khổng lồ” vì chúng tôi chú ý đến từng chi tiết nhỏ có thể làm tốt hơn. Bây giờ, tôi đã học được cách luôn quay trở lại với mục tiêu ban đầu.
Cách thực hiện: Khi stakeholders đề xuất một cải tiến khác, hãy hỏi:
– “Điều này có bắt buộc để đạt được mục tiêu chính không, hay chỉ là yếu tố làm thêm thì tốt (nice-to-have)?”
– “Chúng ta có thể coi đây là cải tiến cho tương lai và tập trung vào mục tiêu chính trước được không?”
Điều này không có nghĩa là lờ đi các ý tưởng hay, mà là quyết định xem chúng có thuộc phạm vi hiện tại hay không.
6. Đóng gói thiết kế theo thứ tự ưu tiên
Chúng tôi từng làm một dự án với bản thiết kế chỉn chu cùng nhiều chi tiết nhỏ thú vị. Nhóm phát triển đã mất nhiều tháng để thực hiện, và tôi nhận ra một số lập trình viên bị mất động lực khi phải làm việc trên một công việc quá lớn. Kể từ đó, chúng tôi cố gắng bàn giao công việc theo từng gói nhỏ — Must-have (Bắt buộc phải có), Should-have (Nên có) và Nice-to-have (Có thì tốt) — thay vì chờ đợi một đợt phát hành lớn và hoàn hảo. Điều này cũng giúp cả team có nhiều cơ hội ăn mừng những cột mốc nhỏ.
Cách thực hiện: Tách bản thiết kế thành:
– Must-have: Không thể ra mắt nếu thiếu phần này.
– Should-have: Có thể ra mắt, nhưng sẽ chưa thực sự trọn vẹn nếu thiếu.
– Nice-to-have: Giá trị cộng thêm nếu còn thời gian.
Hãy thống nhất các mức độ ưu tiên này với cả team thay vì chỉ do bộ phận thiết kế tự quyết định.
7. Tài liệu hóa các quyết định và trường hợp ngoại lệ (edge cases) một cách rõ ràng
Trong một dự án phức tạp với nhiều trường hợp ngoại lệ, tất cả đều được chúng tôi ghi chú trên Figma — vốn không phải là định dạng mà lập trình viên mong muốn nhận được. Kết quả là một số kịch bản bị bỏ sót trong quá trình phát triển, dẫn đến các lỗi (bugs) và hiểu lầm giữa designer và developer.
Để tránh giao tiếp sai lệch với bộ phận phát triển, đây là 3 thói quen hữu ích:
– Trao đổi trực tiếp và kiểm tra với lập trình viên càng nhiều càng tốt.
– Đặt thiết kế cũ và mới cạnh nhau, liệt kê chính xác những gì đã thay đổi.
– Cùng lập trình viên vẽ sơ đồ tư duy (flowchart) hoặc cây quyết định (decision tree) để chốt logic.
Ngoài ra, bạn có thể ghi lại logic đã thống nhất trong một file Markdown và chia sẻ ở nơi mà toàn bộ team có thể dễ dàng cập nhật.
Tóm tắt
Dưới đây là 7 thói quen thiết kế giúp thể hiện sự trưởng thành của bạn:
1. Bắt đầu từ mục tiêu (outcome), không phải sản phẩm bàn giao (output).
2. Hỗ trợ doanh nghiệp đưa ra quyết định — Đừng chỉ thụ động chờ đợi.
3. Thống nhất với lập trình viên (developer) từ sớm.
4. Yêu cầu phản hồi có trọng tâm.
5. Thường xuyên nhìn lại mục tiêu ban đầu.
6. Đóng gói thiết kế theo thứ tự ưu tiên.
7. Tài liệu hóa các quyết định và trường hợp ngoại lệ một cách rõ ràng.
