How to ask for design feedback at every stage of a project
Thinking about when, who, and why is a fast-track to getting the answers you need
When working in a UX organization, feedback is something we rely on heavily to deliver a better product. It can be hard to determine the right people or appropriate moment to make feedback work as well as it can.
When a feedback request goes wrong
Asking for feedback at the wrong time, or from the wrong people, can have disastrous implications on team morale or a project’s progress. I remember a session when one of my fellow UX designers from our team presented her close-to-finished work to a dozen colleagues.
These were people in various roles with different levels of context about the project. Some knew the project in-depth, while others just overheard something about it by the water cooler (yes, this was pre-pandemic). The designer did not think about what feedback we wanted to get out of it; it was more of a general check-in to avoid something important getting missed, as well as an attempt to align everybody.
As we started the meeting, most of the time went into explaining why we were doing this project in the first place. Another chunk went into describing how the product currently works, as a few people were not directly associated with that part of the product. There was a technical debate among a few engineers around the stack and the current state of it. And after the majority of energy and time was spent, we got to the feedback. You can probably guess: the feedback was not specific or valuable. It was diluted and it left us with more questions than answers. The engineering debate left us wondering if it was even possible to implement the solution presented.
The colleague felt overwhelmed, and for many of us, the trust in our team’s direction was shaken.
We got burned. We did not pause and think about what every feedback cycle should consider.
The timing, audience, and outcome
I think each feedback loop consists of three main factors: the timing, audience, and outcome. All three together combine into one block. For me, as a designer, the most digestible way to address this is to think about it as a block-level approach to feedback requests.
It’s best not to see this as a strict process but rather as a mental guideline.
Block 1: Pillar block
Timing: Very early. The solution presented could be just a paper sketch or low-fidelity wireframe. It could also be higher-fidelity work if the organization has a design system in place and execution is a minor effort. At this stage it’s all about ideas or paths we think our solution should follow.
Audience: Product manager and optionally an engineering lead. Within Shopify, the audience for such a block is set up organically as each team is spearheaded with a cross-functional trifecta (PM, engineer, and UXer).
Outcome: We are starting from the roots: clarifying why we think this is a problem worth solving and showing how we see it solved elsewhere. If available, we could elaborate on the data check-in we have done. The initial flow we are presenting should align us with people who have the highest context possible. For example, if the project is overhauling the way users log in, security will probably be our strongest stakeholder here.
Block 2: Partition block
Timing: Early enough so that work can be pivoted without going in too deep. Very likely things will change, so do not spend too many hours polishing bits and pieces. Hi-fidelity work is acceptable if the organization has a design system in place and execution is a minor effort. Still, presenting the solution in lo-fi can work — as long as the audience can understand the logic of the work just as well.
Audience: A designer who is close to the topic and has the context. If an engineer was not involved in the previous block, then a person who can speak to the technical issues is a must-have. The more broadly that person can address technical issues, the better (for example, front-end, back-end, and technical design issues).
Outcome: This design expertise check-in should validate if the initial idea is on track before significant time is lost. It could also show that it’s a good time for a more active UX pairing, trying to solve the problem together instead of in isolation.
If you haven’t done so at the previous stage, make sure to bring in a developer to do a technical sanity check. Some questions to ask include: is it possible to develop this? Do we have the right resources available? Is there an easier way to implement certain parts? Do we foresee any performance bottlenecks?
Block 3: Corner block
Timing: Once the whole flow is complete so that the work can be presented end-to-end. This doesn’t mean that all the details or screens need to be present. Hi-fidelity work is required here since we want to get feedback on the visual design or any content/copy adjustments.
Audience: A group of UXers who have some context on the problem and can frame the solution. This can include content experts, UX/front-end developers, and researchers. At Shopify, we regularly assemble this kind of group in UX reviews or “fresh eyes” sessions.
Outcome: Your audience should further validate if the chosen solution makes sense, as well as if something needs to be updated and polished.
Different UX disciplines are involved so that there is still time to tweak the solution before more effort is spent on it. For example, if a UX researcher recognizes something that contradicts our assumptions, we have time to react to it and pivot the solution.
Block 4: Stretcher block
Timing: The majority of the work is done. Possibly some edge cases are missing and can be covered in the last stage.
Audience: The entire product team working on the project. Backend and front-end engineers, the full design team, and other product managers and team leads for the area.
Outcome: The team can focus on the execution of the solution and can strive for buy-in from everyone involved. If an organization has a project review process in place it can be used for this purpose.
Within Shopify, we take each project through three phases of the GSD (Getting Shit Done) process (Proposal → Prototype → Build). The review moment from the Prototype to Build phase naturally creates a good setup for this block. We can use it to display prototyped flows to the appropriate, context-aware stakeholders.
By sharing it with other product people attached (designers from other adjacent teams who were involved in the previous block), we can gain departmental awareness on the project and sync with other teams. We can also get feedback on the quality of the solution. More eyes on it should seal the deal and cover the tiniest cracks in the presented work.
Block 5: Paving block
Timing: Work is sealed and polished. We have a working prototype ready to showcase so people who are farther from the topic can easily understand it.
Audience: The whole department or business unit. Operational and support disciplines included. Demos or show-and-tell events are great opportunities to gather this kind of feedback.
Outcome: Requesting feedback at such a late-stage is not for improving the quality or changing direction, but rather spreading awareness and aligning with the rest of the organization. It helps everyone understand what to expect from the project and how the solution will work once the build is complete.
It’s best not to see these blocks as a strict process but rather as a mental guideline. It’s a way to make sure we get the most out of the feedback and to minimize the chances of missing important things. In the end, there are benefits for everyone involved.
Getting it right benefits everyone
Getting the right feedback at the right time can be astonishing — and make your solutions better at a faster pace. It can make other people feel involved in the process, align with other projects more easily, and make their opinions matter. It can point you to constraints you hadn’t considered, patterns you hadn’t explored, or small tweaks with tremendous impact on the overall experience.
And those building blocks should put you on the road to success.
