{"id":17359,"date":"2024-06-14T13:36:53","date_gmt":"2024-06-14T12:36:53","guid":{"rendered":"https:\/\/uxstudioteam.com\/ux-blog\/?p=17359"},"modified":"2024-06-14T13:36:53","modified_gmt":"2024-06-14T12:36:53","slug":"feedback-designer-communication","status":"publish","type":"post","link":"https:\/\/timemachine.uxstudioteam.com\/ux-blog\/feedback-designer-communication\/","title":{"rendered":"Feedback: The Foundation of the Designer Communication Toolset"},"content":{"rendered":"

If you are interested in DIY woodworking projects, you might have heard of professional Japanese tools like the Ryoba saw. It is a seemingly uncomplicated wood crafting tool that feels almost primitive in the best possible way. This simplicity, however, is just the facade, giving you the confidence of being a master woodworker the first time you pick it up.\u00a0\u00a0<\/strong><\/p>\n

<\/p>\n

 <\/p>\n

\"Feedback<\/p>\n

Reality hits as soon as you cut into a piece of wood. First, you might blame the quality of the wood. After countless trials and errors, you slowly begin to realize that using a Ryoba requires practice, patience, and technique.\u00a0<\/span><\/p>\n

Based on my experience and after a series of internal mentoring at UX studio, I observed a lot of similarities between Ryoba and how designers use feedback. It starts with overconfidence and underestimation of communication efforts. It continues with seeing the collaboration as suboptimal. Then, it ends with realizing that expanding communication skills will make the designer’s growth meaningful.<\/span><\/p>\n

I must acknowledge that there’s no miracle snake oil for solving the struggles of feedback. Improvement comes almost exclusively with experience and self-reflection. Navigating communication across a diverse set of clients and peers will bring you a more personal perspective on solving your struggles surrounding feedback. This article aims to raise awareness and possible next steps in this evolution.<\/span><\/p>\n

The designer works in the epicenter of feedback<\/span><\/h2>\n

Many designers start their careers with the motivation to become creators, inventors, and problem solvers rather than being great communicators. This might give the designer a skewed idea about realistic tasks on a daily basis in product design. Yes, you’ll discuss requirements with some stakeholders, open up Figma, design, and deliver before a deadline. Still, a decent amount of soft-skill effort is neglected in this superficial assessment.<\/span>
\n<\/span>
\n<\/span>As a designer, you receive a lot of feedback every day. It comes from individuals via user signals, tests, and clients representing business requirements. It can also come from experts in your professional environment and developers after a round of handovers. That can be a lot to take in. Thus, the preparation and anticipation of becoming the feedback aggregator should be elemental for a designer.<\/span><\/p>\n

\"Designer<\/span>It doesn’t matter where critique comes from; it shapes your work. As feedback kickstarts iteration loops, bringing competence in dialogue to the same level of importance as hard design abilities. A designer must anticipate and own the effort of shaping the communication for the better.<\/span>
\n<\/span><\/p>\n

\"Comunication<\/p>\n

So what is feedback exactly?<\/span><\/h2>\n

Simply put, it is<\/span> a concise, constructive criticism with the goal of improvement<\/b>. It is hard to argue with this definition, as it instantly covers much of our understanding of feedback. Yet, unpacking it a bit more will provide some guidelines for giving or receiving feedback.<\/span>
\n<\/span>
\n<\/span>Concise: <\/b>It is on point, clearly communicated, easy to digest, and formulated in a common language.<\/span>
\n<\/span>
\n<\/span>Constructive: <\/b>Useful and actionable for the receiver, supports the goal, and nothing else.<\/span>
\n<\/span>
\n<\/span>Criticism: <\/b>Opinion-driven, honest, highlighting the good and bad without hyperfocusing on the negatives.<\/span><\/p>\n

Goal of improvement: <\/b>Refinement and enhancement are the main motivations behind feedback. Improvement means aiming for better, while aiming for the best should be a distant but clear goal.<\/span>
\n<\/span>
\n<\/span>Yes, being this detailed about an already clear definition feels very hacky. Still, a comprehensive explanation and clear highlight of goals lays the groundwork for effective communication. This ensures everyone is on the same page about the purpose of feedback sessions. Keep bringing up this definition in <\/span>critique meetings<\/span><\/a> and workshops with the risk of sounding like a broken record.<\/span><\/p>\n

The Good, the Bad and the Ugly<\/span><\/h2>\n

We can be more analytical towards it as soon as we have clarity on what feedback means. Creating a productive ambiance for feedback with the definite guidelines mentioned above will bring insightful and rich feedback. Still, the designer’s ability to identify defective comments must also be sharp. Generally, there are three types of comments designers can gather: <\/span><\/p>\n

Good feedback:<\/b> d<\/span>oes not mean it’s positive feedback. It can be positive, negative, or neutral. However, it has to be a group of clear, diverse, and actionable observations based on the presented work. It should build trust between the designer and the participant, inspiring further collaboration.<\/span>
\n<\/span><\/p>\n

Bad feedback:<\/b> d<\/span>oes not mean it’s negative feedback, either. It’s typically a confusing set of shallow insights, hardly focusing on the relevant priorities. These mainly come from detached assumptions leading up to repeating rounds of communication. This can make the progression of the design sluggish.<\/span>
\n<\/span><\/p>\n

Ugly feedback:<\/b> is noisy and not relevant to the designs and the goals of feedback. These are generally making communication sour, damaging inspiration and collaboration. Motivated by emotions and ego, destructive and careless comments can also weaponize responsibilities.<\/span><\/p>\n

What you present is important<\/span><\/h2>\n

It’s unimaginable to achieve actionable feedback without an organized, focused, and planned presentation of your work. A basic structure for presenting your work as a designer requires sharing your endeavor. Also, it is important to vocalize things that are usually absent or prominent on your actual screen flows.\u00a0 <\/span>
\n<\/span>
\n<\/span>Explain why your flow presents the best possible user experience. Also, talk about the user’s mental model and motivation. Describe your reasoning for making specific design decisions. Don’t focus your presentation on explaining what people already see when you share your Figma project. Instead, talk about the user events, reasons, and consequences.<\/span><\/p>\n

\"Screen<\/p>\n

Using proper screen flow indication with low-effort documentation has multiple benefits. When sharing your work, you can use them as presentation cues to ensure you’re presenting the entire flow logic without missing elemental events and beats.<\/span>
\n<\/span>
\n<\/span>Try to minimize UX-specific lingo. Create an inclusive, accessible language for your participants. You can do it by showing everything from the user’s perspective. Bringing the user benefits into your explanation will create a clearer understanding of your UX decisions. “I designed ABC to enable the user to achieve XYZ.”<\/span><\/p>\n

How you present is even more critical<\/span><\/h2>\n

When feedback is simply conversational, it will also be more ad-hoc. Impromptu transmission of opinions might work to validate specific ideas quickly. Yet, it’s not building proper expectations for the next recurring sessions. A general and simple structure can make these sessions more on-point and clear on the next possible steps for designers.<\/span>
\n<\/span>
\n<\/span>Stage 1 – Designer gives context:<\/b>
\n<\/span>The designer communicates the contextual details required to understand the user’s relevant problem. They also show how they see those issues in a UX context. This information assists the participants in decoding what they’ll see during your presentation.<\/span>
\n<\/span>
\n<\/span>Stage 2 – The designer presents the problem-solving efforts:<\/b>
\n<\/span>The designer presents the work and explains the focus of the feedback session. Again, focusing on logic and user benefits without using too much UX jargon. They discuss what makes the design functional, avoiding what makes it nice and shiny.<\/span>
\n<\/span>
\n<\/span>Stage 3 – Questions<\/b>:<\/span>
\n<\/span>No matter how well the designer attempts to provide all the details, there will be questions. These can come from participants that the designer needs to set straight. Missing this stage might result in unconfident, hesitant, or unfocused comments and insights.\u00a0 <\/span>
\n<\/span>
\n<\/span>Stage 4 – The response<\/b>:<\/span>
\n<\/span>The designer opens the feedback floodgate, and participants will leave feedback on the designer’s work. If there are commands instead of comments, the designer has to interrogate the participant to find the motivation behind the instructions. This stage ends when everyone has the chance to deliver all their observations.<\/span><\/p>\n

Stage 5 – Consolidation:<\/b>
\n<\/span>This is a very critical step, missed by many. The worst feeling after a feedback session is the lack of confidence in what to do next as a designer. It can happen even after a high-yielding response stage. You might have assumptions on what to do after stage four. You should immediately discuss and validate them with the participants. Also, create a set of prioritized design tasks based on the entire session. This will also set the expectation for recurring participants on what you’ll work on and present for the next meeting.<\/span><\/p>\n

\"Feedback<\/p>\n

Be the owner of the conversation<\/span><\/h2>\n

The designer’s analytical mentality should continue beyond their craft. It should also extend into collaboration and communication with other experts. Identifying feedback struggles and planning for improvements will fall into the designer’s lap. Stakeholders and peers justifiably won’t allocate time to unblock designer-connected communication struggles.<\/span>
\n<\/span>
\n<\/span>Hold frequent retro sessions around the communication with everyone you regularly connect with. Don’t expect a small startup’s CEO or a giant organization’s team lead to unblock your issues with feedback. Instead, be open and proactive toward experimenting. Find and plan methods that best suit the circumstances. Change how to take and manage incoming insights.<\/span>
\n<\/span><\/p>\n

Turn squawks into SQUACKs<\/span><\/h2>\n

As a designer, you generally want to avoid compromising the time you can spend on designing. Thus, finding low-effort, high-impact methods to yield quality feedback is a priority. One method I recommend experimenting with is the <\/span>SQUACK<\/span><\/a> critique formula.<\/span>
\n<\/span>
\n<\/span>As a low-hanging fruit, it impacts the quality and diversity of insights. It is simple to explain, apply, and use. The silly but fun-sounding name is an acronym. It holds all the important angles of a diverse feedback session. This formula attempts to solve a lot of typical problems around ad-hoc feedback. <\/span>Below, you can see the different types of feedback through examples.<\/span><\/p>\n


\n<\/span>Suggestion:<\/strong>
\n<\/span>Comment, idea, or inspiration based on professional experience and opinion. It’s not backed by data or research; it’s mainly a preference.<\/span><\/p>\n

\"Example<\/p>\n

Question:<\/strong>
\n<\/span>This is an area that needs more explanation from the designer. Used for clarification to boost the validity and confidence of the upcoming insights.<\/span><\/p>\n

\"Asking<\/p>\n

User signal:<\/strong>
\n<\/span>A session participant can have reliable data, user feedback, or research insight. These can act as compelling and authentic suggestions. It’s objective feedback rather than subjective.<\/span><\/p>\n

\"User<\/p>\n

Accident:<\/strong>
\n<\/span>Indicating mistakes like typos, bugs, conflicts, paste errors, and logical errors in the design. These are typically mild errors but can cause confusion or frustration.<\/span><\/p>\n

\"ExampleCritical:<\/strong>
\n<\/span>Highlighting significant, high-priority issues with possible business risks, user and customer pains, or engineering conflicts. These issues must be resolved as soon as possible or, in some cases, channeled back to research.<\/span><\/p>\n

\"Communicating<\/p>\n

Kudos:<\/strong>
\n<\/span>Praise or gratitude, acknowledgment of the great aspects of the presented design. It highlights positive design efforts and provides a moral boost for the designer.<\/span><\/p>\n

\"Give<\/p>\n

As you can see, SQUACK avoids misinterpretation of insights. It promotes clarity and a more comprehensive feedback vocabulary. This can be useful for people less involved with giving feedback. With its flexibility, you can incorporate it into already existing feedback structures and agendas. Also, participants can use it in synchronous or asynchronous communication. It also creates a sense of prioritization for the designer. For example, out of 100 comments, you’ll start to focus on the 15 critical ones. This makes a terrifying amount of comments actionable right away.<\/span>
\n<\/span><\/p>\n

Main takeaways<\/span><\/h2>\n