Giving good feedback to designers
At Redivis, we’re working to build intuitive interfaces that make data science accessible and easily communicated. This is a big challenge, and we’re a small company, but one of our best resources is that everyone here has a lot of ideas and cares deeply about our product. A key role I play as head of design is to elicit and capture design feedback from non-designers, and I’m excited to share my insights into this process.
If you’re someone who interacts with designers during their creation process, no matter what your job title is, you have valuable information and insight to contribute. Your designer can appreciate and utilize your contribution even more if you contextualize your feedback with an understanding of where they are and what they’re seeking. And trust me, better designs will come of it!
Context
Why do I ask for feedback?
Building designs is a big process with a lot of pieces in the air at any given point. Our ultimate goal is to make a set of resources that change as little as possible once they get into the hands of engineering, marketing, and support. As the person in charge of these designs, I need to understand what’s working, and what’s not, so that I can change them as early as possible.
When do I ask for feedback?
I generally ask for feedback when I’ve reached one of two points in my process:
- I think there are some key high level decisions to be made and don’t think it’s worth spending more time on details without more information or input. (Usually early on in the sprint.)
- I think these design resources are getting to a complete state without the need for further changes and want to validate that this is the case for everyone involved. (Usually later on in the sprint.)
What am I going to do with this feedback?
Once I have an understanding of how the system is landing at a high level and any additional information that hasn’t previously come up, I make a list of things to work on in the next pass. This is usually framed as problems to solve in different places. I then draw on research and brainstorming to inform what changes I’ll make to the system, and then we will probably get to do this feedback part again.
1. Scope of feedback
Your area of expertise
I asked you for feedback for a reason! What elements of our company or product do you know better than anyone else? What insights can you bring to this process that only you can represent? Can you speak to feasibility of implementing these designs (engineering)? Do you have insights into its value and whether people will choose or buy it (product)? Is there some aspect of these designs that is missing the mark for supporting our viability (business)? Is it out of alignment for our broader company (executive)? Let me know!
Your impressions of the designs
Design is responsible for ensuring usability and representing the user. I probably have prioritized this in the designs I’m sharing with you, but it helps to have another set of eyes sanity checking it. Are you a user of our product? How might you be feeling at different steps? What might users you have interacted with be feeling that you can speak to? As a user of the internet, what doesn’t feel right to you and why?
Timing of high level comments vs details
The most helpful feedback to receive depends on what stage the system is at. Early on, high level information and broad usability impressions of fit, feel, and flow are most important. Comments about a specific UI element is probably not as helpful yet, and more importantly we want to get those high level comments as early as possible. Once we are a bit further in the process, feedback on more specific elements or asks for missing pieces become more important.
2. Framing high impact feedback
When possible, ask questions! By framing a question you get the opportunity to hear more about the context for this design so we can both understand the situation better. Maybe you’re misunderstanding something. Or maybe I am missing some information and made a bad call and your question will help me see that. Either way, your point will be better engaged with if you make the effort to frame your thoughts as a discussion.
- “This should be green” -> “Why is this blue?”
- “This header doesn’t make sense” -> “What does this section represent?”
- “The next step entry point is confusing” -> “What are you thinking for this broader UI flow?”
It can also be helpful to follow up with your perspective afterwards, or weave it into the question if you think that impression is valuable.
3. What information to convey
Information I might not be aware of or hasn’t come up yet
What hats do you wear and what perspective can you offer? Being explicit about where you’re coming from is helpful!
- “From a feasibility perspective I’m not sure if the membership form display will work here. We currently aren’t storing this information in the database and it’d take 1–2 months to change that.”
Parts of the designs that are working well and are exciting to you
Just as important as what’s not working! I can be equally blind to both sometimes and it helps to have some anchors.
- “The signup form UI here really resonated with me, the icon made it really clear what I needed to do next”
Parts of the design that aren’t working or you don’t like and why
This is so important! It’s helpful for me to understand what areas still need work or are confusing. The why can be hard and not always important for small things, but super critical for higher level feedback.
- “The three tab system was confusing, I felt like I was supposed to click on the right tab first, maybe bc of the arrow icon? Which makes me think of directionality? Also visually there’s a lot going on and I wasn’t sure where to start.”
4. Describing solutions
Sharing ideas for solutions as part of feedback can be helpful but first I need to understand the problem!
Suggestions for change
I love hearing how you think the designs could or should be changed as part of feedback! But these can get de-prioritized if I don’t first understand what they are trying to fix. The solution isn’t helpful if I don’t know what the problem is.
Lost in translation
When I see a solution without a problem, my first step is to try to back out the problem. This leaves a lot of room for error, especially with written, asynchronous feedback. “This header should be bigger” could mean that the structure of the page is feeling overwhelming to you. Or that you are confused what your next steps are. Or that you think from a business perspective we need to emphasize this feature more. Or that from an engineering perspective it would be very time consuming to make the header in this unique size. If you don’t speak to the cause of the issue, I’ll do my best to back it out but we might miss the real problem.
Problems without solutions are always welcome!
When sharing an issue or problem, don’t feel pressured to have an answer or suggestion for change. If you have one I’d love to hear it! But sometimes just flagging the problem and sharing insight into it is exactly what I need to move forward. Feedback for me is about understanding the state of the designs, how things are landing, and what work still needs to be done. Feel free to leave a “this module feels out of place here, I feel like the information is confusing at this step in the process” comment and trust me to run with it (or follow up with you later for more details if I need them).
Thank you — your feedback is crucial!
Thank you for your time and participation in the feedback process! We designers really couldn’t do it without you. Hopefully we can work together to make the most out of the time we all spend together.
The team at Redivis is building a platform for academic organizations to easily distribute rich datasets and empower researchers to undertake groundbreaking research. If you are also committed to democratizing data and making data science accessible we’d love to hear from you and share our experiences.
We’re hiring! See our open job postings, and learn more about how we are creating a company we all want to work at. 💁♀️✨
