We had a conversation with one of my designer friends, Maria, a while ago. We talked about the usefulness of engineers’ feedback on designs and how to make it helpful. I pondered the topic after our discussion.
My friend was doing user research and experimenting with different flows to design a new feature with the best user experience. After a few ideas were shaped and passed the usability testing, they prepared some wireframes for different flows to talk to software engineers and get some early feedback. They walked through the ideas and were ready to take notes. The feedback they received varied, ranging from “I like it” to challenging users’ behavior. That’s where we started our conversation and realized that many engineers approach design-walkthroughs incorrectly.
Engineers should approach the designs with two fundamentals in mind, in this order:
- Understanding the users and their problems
- Evaluating the designs’ feasibility
When it comes to understanding users’ needs, there is no distinction between the two groups. Many engineers can argue that it’s the product designers’ job and they should build solutions to solve users’ problems. As engineers are responsible for building that solution, they also must understand the user before giving any feedback on feasibility.
In my experience, engineers lack this part the most. It’s impossible to decide how to build a system correctly without knowing the user’s needs. Yes, it’s possible to implement a UI design without understanding the user. Yes, it’s also possible to give feasibility feedback. I have done both in my career. However, when it comes to making the feedback useful, it’s very difficult to offer an alternative solution to the design team.
Once engineers understand users’ needs, the focus shouldn’t be on “liking the design” or “finding it makes sense” (I heard these words from engineers many times) but rather on feasibility—thinking about how difficult it is to implement the solution. This is where the debate should be between design and engineering, bringing out the real value of collaboration.
Designers get early engineering feedback to measure feasibility without wasting too much time on small details. While considering implementation details, engineers should be able to offer solutions like, “Implementing this design is complex and will require a lot of time to get it right; how about we do this section a bit differently?” or “How about adjusting the flow in ‘X’ way and that can help us to resolve a few complex bugs too?” These comments have great value for both designers and engineers and focus on finding the best possible solution.
After that, giving overall feedback on designs is still useful and helpful. Any feedback can give insights and spark new ideas for designs. However, the main focus should always be understanding the user and then giving feedback on feasibility.
*P.S. I didn’t focus why design teams hold these feedback sessions on this post but Maria later pointed out that they use the sessions to invite everyone to ideation and ensure the team is up to date throughout the intire process. I think it’s a great addition to collecting feedback; aligning and involving everyone is always a good way to foster culture of innovation.*
