UX Case Study
Building Bridges between UX and Devs:
A Valuable Investment Toward Better Apps
8 key strategies I developed to improve relationships between Developers and UX Designers
Developers and UX Designers often seem to be at odds over many things including their approach to problems and how much UX/UI to include in stories to be developed.
Developers or Devs are often focused on the “How” of stories such as “How can a problem be fixed?” They may be focused on efficiency of the code and whether a given complex feature can be maintained if additional functionality is added. UX Designers or UXers are often focused on the “Why” and “What” of a story. “Why are users having trouble now with the UX or UI?” and “What can be done to make the user experience better?”
The work that Developers and UXers do can sometimes be at odds. Each group can become isolated in its work, making collaboration more difficult.
I Developed 8 Steps or Best Practices for Addressing these Problems by Building Bridges between UX and Devs:
- Memorize Developers (Devs) names and learn how to pronounce them.
- Embrace the “golden 15 minutes” after stand-ups for having chats and building work relationships.
- Engage Devs in problem solving about the UX/UI as a way to find common ground.
- Educate as a way of advocating for UX/UI solutions and the Design System.
- Reach out to Devs when researching specific stories to learn options and avoid overly complex UX.
- Meet with Dev teams to dialogue about the user’s perspective and other topics.
- Take advantage of opportunities to teach about UX and the UX process via “Developer Trends” or similar sessions.
- Be patient and flexible in giving Devs time to consider a possible UX solution. The Dev might be more open to a UX feature after review and analysis.
Implementing the 8 “bridge building” steps listed above takes time and commitment. However, this work is worth the effort. Once there is a good, trusting relationship between UX Designers and Developers, the software development can move at a more efficient pace. This leads to better UX implementation and better products.
I’ve also learned that sometimes developers need more time to come around to a new idea I am proposing.
Story – Building Bridges with the Data Architect
Recently, the Data Architect of one of my teams and I were in a series of grooming sessions. We were reviewing possible solutions to problems with a complicated data grid for users. The grid needed a way to show more information including a side panel that could open and close.
Initially, she said my UX was too complicated and she had a good point. I was not offended by our different opinions either because I know that give and take is normal in a collaborative relationship. I believed my solution, though complicated to develop, was actually simpler for users and was worth the extra story points it would take. Several days later, we presented options about this same story to our Product Owner. The Data Architect actually brought up my solution and defended it during this presentation. She was able to see the benefits of my idea after taking some time to process it. This was a pleasant outcome but I would have been fine with the Data Architect’s simpler approach as well.
Story – How My “Dev Brain Trust” Saved the Day
Here is another example of how my bridge building supports the success of product teams. One day during story grooming, when the Data Architect needed to be at another meeting, the product team was grooming some stories that had to get ready for the Sprint starting the next day. There were many questions on 2 of the stories that needed a Developer to answer them. I told the Product Owner and Business Analyst, “Wait right here, I’m going to consult my “Dev Brain Trust” and find out what they know that can help us.”
I rushed over to the Dev cubicles to consult with the 4 Devs on my team. Dan, one of four Devs, said to me as I approached, “Ed, how can we help you today?” I was grateful that my bridge building paid off at a critical time.
Dan and his fellow teammates spent 15 minutes with me answering my questions and helping brainstorm solutions. I rushed back to the conference room and confidently shared what I had learned with the Product Owner and Business Analyst. I was able to provide UX for the stories that had been “pre approved” by the Devs. Fortunately, both the stories were ready for the Sprint the next day.
On my teams, I discovered huge benefits to quick chats with Devs after standups to find common ground.