Câu chuyện nhận feedback là chuyện hàng ngày trong công việc và đặc biệt là trong design nữa, vậy làm sao để tránh bị tổn thương và tiếp nhận nó một cách hiệu quả. Thử cùng mình ngồi ngẫm nghĩ nghiên cứu xem có những tình huống feedback nào & nên xử lý nó ra sao nhé.
Thấy nó sao sao (Vague Feedback)
Ví dụ:
Anh A: khi dùng hoặc nhìn qua bản thiết kế, anh cho hay: “a thấy này sao sao”.
Designer: dạ anh có thể làm rõ hơn không?
Anh A: anh thấy cái card này lạ lạ
Designer: anh thấy nó lạ như thế nào?
Anh A: anh thấy nó như một cái hình hay banner, không biết là nó có thể click được
Designer: vậy thông thường điểm gì khiến anh nhận diện nó là một cái card?
Anh A: chắc là nó hay đóng khung
Designer: anh có nguồn nào mà em có thể tham khảo không? Hay mình sẽ tự kiếm các ref để clarify ý đó của ảnh. (“Show don’t tell” là một cách trực quan hơn, để tránh hiểu nhầm ý của nhau).
📌 Nhiệm vụ của mình trong tình huống này là cố gắng tìm hiểu xem họ thấy nó sao sao là ở khía cạnh nào, cụ thể là gì, điều gì khiến họ cảm thấy thế, lí do đằng sau của sự cảm nhận ấy là gì.
Tip: thông thường các feedback có “tính từ” là khả năng cao cần phải làm rõ thêm, vd: cần tốt hơn, cần joyful hơn,…như thế nào là “tốt hơn”, như thế nào là “joyful hơn”.
>> Designer: lúc này bạn có thêm thông tin đủ rõ để xem xét lại bản design & cân nhắc xem có cần thiết để cải thiện không, vd trong trường hợp trên mình sẽ có 2 problem:
vậy bạn nên làm rõ nó như một cái card hay chỉ cần thêm indicator để tăng tính affordance.
Nên theo hướng A (Solution-Oriented Feedback)
Trong buổi họp nếu ai đó propose cho bạn một solution A, ví dụ như:
“Hãy đổi màu nút này thành đỏ cho nổi bật.”
“Màn hình trông trống trải quá, có thể thêm thông tin không?”
“Có cách nào làm cho thiết kế giống như [tên ứng dụng trên thị trường] không?”
📌 Việc trước tiên là khoan hãy phán xét ngay độ hiệu quả của nó hoặc ngược lại là đồng ý với solution đó ngay, bạn cần thời gian để cân nhắc thêm, có thể là ngay trong hoặc sau cuộc họp đó. Điều mình có thể làm ở đây trước là
đào sâu hơn cách mà họ form lên solution
ấy.
Để đào sâu, mình phải hỏi. Mình hỏi để làm rõ lại tính intention của họ là gì, objective ở đây là gì, họ lựa chọn giải pháp này dựa trên tiêu chí gì, cách họ đặt vấn đề như thế nào.
“So what? & why that?”
là câu hỏi tốt nhất cho trường hợp này.
Khi có thêm những thông tin trên bạn sẽ đủ dữ kiện hơn để đánh giá solution ấy, đánh giá xem liệu solution họ đưa ra có mapping tốt với problem đó không, có điểm mạnh nào trong đề xuất ấy, maybe mình có thể come up một hướng tiếp nhận khác mà combine được các điểm lợi của cả 2 solution giữa mình và họ.
Nghi ngờ, không đồng ý với hướng propose của bạn (Doubtful feedback)
Sẽ có tình huống, các stakeholder cảm thấy solution bạn đưa ra chưa hiệu quả, thiếu niềm tin vào nó. Ví dụ:
“Bạn có chắc người dùng sẽ hiểu tính năng này không?”
“Tôi không nghĩ cách này sẽ phù hợp với người dùng của chúng ta.”
📌 Lúc này, điều cần làm trước tiên là xem liệu mình đã có đủ
rationale, reference, research, best practice, case study, principle…
để back up cho design solution mình chưa. Nếu mình thấy đã có đủ thì liệu nó có liên quan đến
cách truyền đạt
không, đã rõ ý, đã đủ thuyết phục, đã make sense hay chưa. Nhiệm vụ ở trường hợp này là cung cấp thêm thông tin để giúp nó trở nên
thuyết phục
hơn.
Thử tưởng tượng cách bạn ra solution như một phép tính:
(A+B)xC+D=Solution
, thì mình phải dẫn họ đi qua từng cái A,B,C,D có những gì và mối liên hệ giữa chúng (các phép tinh +,-,x,/) ở đây là gì.
Show ra cách bạn đặt vấn đề (problem statement) & cách mapping solution với problem đó, cách mà mình transform solution thành artifact (UI/Flow/Interaction patten) như thế nào.
Cảm nhận chủ quan (Personal Preference Feedback)
Đôi khi mình cũng sẽ gặp phải những feedback rất mang tính chất cá nhân, đây là cái mình ghét nhất 😡. Ví dụ:
“Tôi thích giao diện này sáng hơn”
“Tôi nghĩ hình ảnh nên to hơn.
📌 Vì feedback này rất chủ quan, hay bị bias, feedback đó đưa ra không dựa trên mục tiêu chung hoặc không dưới góc nhìn khách quan (không có data/research gì cả).
Nên điều mình cần làm ở đây là phải đặt ra những câu hỏi để kéo họ
quay về align với objective, với problem
, yêu cầu họ cung cấp những rationale, lí luận rõ ràng cho feedback ấy.
Mình cần tránh là phản biện lại bằng những ý cũng mang tính cá nhân, điều này chỉ khiến 2 bên conflict thêm, hãy cố gắng dùng
các lí lẽ khách quan
hơn để bàn luận.
Yêu cầu làm lại toàn bộ (Major Overhaul Feedback)
Chắc đây sẽ là feedback tụi mình sẽ không muốn gặp nhất. Vì nó sẽ rất tốn effort để làm lại từ đầu. Feedback này xuất phát từ việc, đề xuất của bạn không hợp lý, gặp quá nhiều vấn đề.
📌 Thay vì ngay lập tức đồng ý và chỉnh sửa nó. Điều mình cần làm ở đây là thử
bóc tách
nó ra, xem đang gặp vấn đề ở đâu, làm rõ các phần không hài lòng & những thiếu sót. Cân nhắc xem
effort, resource
hiện tại có xứng đáng cho giữa việc thay đổi toàn bộ không, xem liệu
trade off
này có xứng đáng hay không.
Nếu được hãy thử xử lý nó theo hướng nhỏ hơn, thử nghiệm độ hiệu quả các cải thiện nhỏ ấy trước xem thế nào. Nếu thực sự đã hết cách thì mới chuyển sang hướng tiếp cận khác hẳn (pivot).
Lưu ý!!! Vấn nạn, lưu ý!!!
Mình tự đánh giá mình là người khá dễ chịu, nhưng khuyết điểm của tính cách này đó chính là chính kiến yếu, dễ đồng thuận với người khác. Nói dân dã hơn là “dễ tin người”.
Vậy nên lưu ý này dành riêng cho những ai như mình.
Làm thế nào để tránh cam kết quá dễ dàng?
Có khi mình gặp vấn đề dễ commit vì feedback của họ đưa ra có lý, thuyết phục… NHƯNG bạn phải là người hiểu rõ việc bạn đang làm, bạn phải vừa hiểu sâu, hiểu rộng, có khi 1 điểm họ nói đúng nhưng chưa chắc là đúng trong
tổng thể
.
Chậm lại:
đừng vội đồng ý ngay, thay vào nó hãy nhấn mạnh là bạn sẽ cân nhắc thêm. Nếu nhận diện được có gì đó cấn cấn hoặc bạn tự đánh giá bản thân là người dễ committed thì không cần phải đồng ý ngay đâu, hãy xin họ cho thời gian để cân nhắc thêm.
Tập nghi hoặc
: thông thường mình dễ đồng ý vì mình nhìn dưới góc độ mà người kia feedback, nếu họ nói nó tệ > ta sẽ nhìn theo hướng nó tệ, nếu họ nói nó tốt > ta sẽ nhìn theo hướng nó tốt. Như vậy không phải là không tốt, điều này chứng minh bạn biết lắng nghe & nhìn nhận vấn đề dưới góc nhìn của họ, nhưng mình cần nhìn thêm dưới những góc độ khác, đánh giá các edge case & trade off / risk. Ví dụ: nó có tác dụng phụ gì không, nếu ở tình huống khác thì như thế nào, nếu apply cho một tệp user khác (new user, frustrated user chẳng hạn thì nó sẽ như thế nào, liệu có còn hợp lý…). Hãy áp dụng
6 hat thinking.
Reference
Relevant Item
