Ideas from Developers on Handling UX Feedback
Taylor Palmer ·
Communication
I recently wrote about what I learned from interviews with software engineers about their needs from UX research. In those same interviews, I uncovered several insights about managing feedback from engineers.
Designers and developers have much in common. We’re two of the most creative groups in software development. We’re both constantly creating new things.
In that way, both teams compose an important partnership worth nurturing. Read on for highlights from my interviews of actionable takeaways for your team.
The design and development partnership
Designers have to juggle feedback from several different inputs and stakeholders. One key stakeholder is the development team—the talented folks who will actually make the designs a reality.
I asked several developers what circumstances create friction in the design process. When do they feel to need to back on designs? The responses were broad but also unified under a common theme. Take a look:
- “When designs are not platform-specific” (referring to Android and iOS, specifically)
- When the engineering effort (time-to-build) “outweighs the benefits of getting the design exactly as it is”
- When the design might harm the system architecture
- When the designs are a “development time pit”
- When the developer has historical knowledge or data that “invalidates” a decision ( maybe one that you shared with them!—because developers deserve to understand UX research)
Great engineers value the quality and integrity of the solutions they build. They lookout for the good of their craft—just as designers do when thinking about our own systems and processes.
Designers should expect feedback
Take a second to think about the impact your design work has on your team (or on your whole company). Your designs dictate how engineers spend their time for the next several days, weeks, or even months. How that solution reaches a customer dictates the success of the business or organization. That’s a big responsibility!
It makes sense that the people and teams responsible for building an idea would have feedback on how it’s planned and executed.
As one engineer explained, when they offer a suggestion it may “not even [be] a better solution, but instead, a way to reach the same outcome but have it be half the effort from the engineering team.”
Feedback should be constant, not singular
Recently in Jess Eddy’s UX Chat she mentioned that she doesn’t think of the developer relationship as a “handoff.” Instead she considers it a “continuous stream of communication.” Involvement from designers and engineers doesn’t start and end but instead fluctuates and changes roles as the project evolves.
As a project transitions from abstract to concrete, think about some of the different touchpoints on your team. Where can you inform others and invite feedback? Some examples:
- After a shift in the company or team strategy
- When a new plan is added to a roadmap
- In a project kickoff
- After a research report
- During UI exploration
- After A/B test results
- When receiving Sales feedback
If you’re interested in learning why developers take interest in these touchpoints, consider reading my previous post on what developers need from UX research.
Why designers should want feedback from developers
I can’t be more clear than this engineer was:
“If you can share the full context, data, and research behind a design decision, developers will understand and help you make things happen.”
Developers are powerful allies. Some of the most skilled developers I’ve worked with were also fiercely defensive of their work and deadlines. Building a relationship of trust invites those developers to defend the things you care about too.
Imagine a development team that strives for accessibility, design system integrity, component architecture, and usability. That dream is only realized through mutual respect.
One engineer, when asked about pushing back on design, said, “I tend to move forward with the solution given—trusting that it’s been well thought through and with the assumption that getting something built, learning from it, and iterating is usually the best way to create a product.”
Did you catch that they “trust[ed] it’s been well thought through”? That it not an easy achievement. How do you earn that trust?
Build trust by fostering feedback
One of the easiest and fastest ways I’ve found to build trust on a team is to invite feedback and then immediately act on it.
Feedback is an opportunity to build loyalty
Some engineers gave great advice for designers who may be handling a lot of incoming feedback:
“Show the developers that you are actually hearing feedback and if necessary meet with them one on one to talk about things further.”
Some designers may read that and and feel the panic of a very crowded meeting schedule. It’s up to you to determine when a meeting is necessary. Don’t forget that a meeting can be as little as 5 minutes.
Another engineer gave a great tip: “If designer[s] have future plans to address the issue, then let the team know.”
Both of these responses share a common and important truth: handling feedback well means knowing where to direct it. Here are some responses you might consider using when handling feedback:
- I hadn’t considered that—do you mind if I get back to you about that? (Then actually do it)
- I can see where you’re coming from. I’m not sure that’s something we’ll be able to get around to, but I’d love to pick that up with you after this meeting.
- Thanks for bringing that up. Right now we’re not planning to do that because of (roadmap/timing/research/etc) but I’m happy to chat more about that if you’re interested.
Responding to feedback is an art form by itself. These are a few examples to show you listened, the feedback is reasonable, and you’re willing to do the work to respond.
Respect craft and time
Designers are often clawing for a seat at the table and demanding respect for design. What about development?
Because design and development affect each other’s time commitments so much, mutual respect is important. Some engineers want to work together on this:
“If it’s a concern about development time, then work with the team to figure out what other options are available.”
Remember that responses about development time are about the good of the team, not just someone being contrary. If you feel push back, try to find where that’s coming from.
Another way to respect the development process is by understanding and appropriately utilizing correct conventions (such as platform-specific patterns):
“So far the biggest reasons for my pushbacks are when designs are not platform-specific.”
It’s one thing for a team to make a unified choice to stray from convention. It’s another thing entirely for an engineer to be surprised by unexpected design choices. Even if ignoring convention is the right choice, how can you share the context and knowledge that helps the engineer become an ally?
As you go down that path you may discover something—designers aren’t always right.
It’s okay to be wrong
Designers don’t have to be flawless, creative geniuses to find success. Instead, they can rely on input and ideas from others to create something greater. Consider how these engineers prefer to work together:
“I know my domain is technical and at times there are moments when I can use my knowledge of the architecture of the system to provide a better solution.”
I read this as a very respectful way of saying “sometimes designers are in over their heads and I’m happy to help.” So let them!
Another engineer rightly pointed out, “if the objection is genuine and [a] designer missed some[thing] then accommodate the changes.” This one is pretty straightforward. If the feedback is right, just do it!
Repeated displays of being willing to work together can gradually improve each interaction the team has. If the rest of the team returns that same favor to you, you’re probably going to have a good time on that team.
Wrapping up
Not every team strikes a perfect, harmonious balance of design and development unity (I’ve had my fair share of difficult teams). For whatever reason, developers and designers often—and unnecessarily—antagonize each other.
These insights reveal another side of the story. I think these two teams have the same goal and deserve to support each other in reaching those outcomes.
If you found these insights useful, I hope you’ll consider showing some love or sharing on Twitter:
