Mình từng nghe qua một câu điểm giá trị nhất trong design là consult (tư vấn chuyên môn), để tư vấn là biết nên & không nên làm gì, việc này cũng rất đúng trong quá trình tackle feedback, không phải luôn gật đầu đồng ý với luận điểm đối phương, cũng không phải luôn defend cho idea của mình, mà là biết lúc nào nên & không nên nhận feedback ấy. Bài này mình sẽ cũng đi qua vài loại feedback trong design.
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: anh có nguồn nào cho em 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 được làm rõ thêm, vd: cần tốt hơn, cần joyful hơn,…nhưng trong hình dung của họ thì 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 feedback hoặc ngược lại là đồng ý ngay với solution mà họ đưa ra, 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ì, họ lựa chọn giải pháp này dựa trên tiêu chí gì, cách họ nghĩ về solution đang serve objective chung hay không.
“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 hay không, liệu có điểm mạnh nào trong đề xuất ấy mà ta có thể cân nhắc hay không. Còn nếu feedback ấy không trên tiêu chí gì cụ thể, không solve problem, hay serve objective gì cả thì đừng ngần ngại phản biện.
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.”
“Việc đổi lại ưu tiên nút này sẽ để lại trade-off gì?”
📌 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 chưa thì đó là do mình đang yếu rationale). Còn 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)/C-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 ấy thành artifact (IA/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”
“Tôi thấy nó không sang gì cả”
📌 Vì feedback này rất chủ quan, hay bị bias, cần đánh giá feedback đó đưa ra có đang dựa trên mục tiêu chung hay không, có 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, target user là ai, context of use như thế nào,
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 (vd: “tôi không thấy nó không sang, nó sang mà”, đ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.
Vì feedback khá là chủ quan, nên nó có thể đến only từ đối phương, đôi khi ta cần kiểm chứng thêm liệu những người khác có same cảm nhận hay không (lưu ý: hãy lấy feedback ẩn danh / một không gian riêng, mình sẽ muốn né trường hợp các người BCD bị bias nghe theo ý kiến của người A).
Final thought
Take design feedback cũng quan trọng không kém gì như lúc ta cần xác định rõ vấn đề trước khi bắt tay vào design. Vì nếu ta dễ dàng commit quá thì công sức vắt óc suy nghĩ về solution trước đó trở nên công cốc.
Càng lên level cao, việc master skill này lại càng quan trọng, vì ta sẽ là người cần đứng ra defend design, đảm bảo cho design value,… Việc này nên được đầu tư nghiêm túc như lúc mình ngồi phân tích problem, mò mẫm solution, như mình nói ở đầu bài, phần value nhất của design không nằm ở output, nó nằm ở tư vấn, hiện tại 50% công sức mình dùng để generate ra design solution, 50% công sức còn lại để mình tự challenge lại design solution đó & chuẩn bị các kịch bản đối ứng feedback.
Quyển sách “Articulate design solution” sẽ rất helpful đấy, các bạn có thể tìm đọc nhé. Hoặc có thể xem clip này.
Reference
Relevant Item
