Creating Buy-In For Your User Experience Designs
“There’s a healthy middle ground between designing from your ivory tower and falling into the trap of people-pleasing with your designs. Reaching that middle ground is necessary in order to deliver quality experiences, especially on a project where the number of stakeholders is high.”
Years ago I learned the hard way that designing interfaces at my desk, on the opposite end of the floor from the development team, and adding my designs to a JIRA ticket wouldn’t result in experiences that were remotely like what I had designed. It didn’t matter that I was proposing basic changes that made obvious sense. Of course all the primary buttons should be the same height, the main content area should be the same width from page to page, and each page should have—get this—a title. Who would even bother to question those decisions?
Unfortunately the result I got from the development team was not a consistent, more usable experience of the software I was trying to improve. More often, I got snide comments in JIRA tickets, excuses about why the changes would be difficult or impossible to implement, or interfaces that had been loosely “inspired” by the prototypes I’d spent days or weeks perfecting.
It would have been easy to assume that the development team was hostile, untalented, or even stupid. But that wasn’t the case—the problem was that they’d had ownership over the product for years, and I came in as a new employee and told them how to do their jobs better, without having an understanding of the obstacles they’d overcome to get to where they already were. And worse, I hadn’t bothered to get their feedback on my designs while they were in progress, making it clear to them that their perspectives were irrelevant. Naturally, they were resistant to helping me achieve my goals.
Design is a tricky field because most people have some ability to assess its quality, and therefore many feel compelled to weigh in on it. Swing too far in the direction of collaboration, and you may run into the dreaded “design by committee” situation where design decisions are made based on the personal preferences of the dozen stakeholders involved in the project, leading to a frankenstein interface. But there’s a healthy middle ground between designing from your ivory tower and falling into the trap of people-pleasing with your designs. Reaching that middle ground is necessary in order to deliver quality experiences, especially on a project where the number of stakeholders is high.
Once I started establishing buy-in earlier in the design process, I got more respect, and because I got more respect, my designs were executed on. Some behaviors that helped me create buy-in for my designs included:
Co-locating with the team - Many agile training courses don’t effectively discuss the role UX plays in agile software development. That’s another topic altogether, but one thing that works for all members of an agile dev team is face-to-face interaction. Being within close proximity to your developers allows for more effective, immediate, and balanced conversations than a back-and-forth email thread, in which tone can be misinterpreted. Once I moved my desk and became part of the team, I built relationships and gained empathy for the technical obstacles developers would need to overcome to implement my designs.
Hosting cross-functional design reviews - At least one design review per sprint is essential in helping your team of developers, product owners and test engineers get insight into your plans for the user experience and provide feedback. You should plan to review your in-progress designs and allow the team to weigh in—they can help you think through other parts of the workflow (the unhappy paths), clarify missed requirements, present technical challenges that may deem the design impractical to implement, and uncover unexpected reactions that people may have to your designs. For tips on giving and receiving design feedback in a healthy way, check out the book Discussing Design.
Sharing low-fidelity designs - Don’t wait to share your designs with your team until they’re high-fidelity. This makes your team feel as though the designs are already finished and it’s too late to provide feedback that may dramatically alter the workflow. It’s also a waste of your time to perfect your first idea without gathering other perspectives throughout the process. If you put too much time into the alignment of the elements on the screen and the fancy interactions, you’re naturally going to be more resistant to re-working your idea and starting from scratch. Start by sharing wireframes and low-fidelity designs to get feedback on your early concepts before polishing the details.
Inviting the team to user testing - User testing your prototypes is crucial to understanding whether the experience you’ve designed meets the needs of and can be easily navigated by users. When you invite your product development team to user testing sessions, they develop empathy for users and can better understand how the design does or doesn’t support user needs. Oftentimes, firsthand feedback from users holds more weight with the team than your professional opinion as a designer, and that’s how it should be. User testing is a great way to remind the whole team that user experience is not about internal opinions and egos—it’s about the higher purpose of serving the people actually using your software. Done correctly, it should help your team get on the same page and arrive at an experience that serves your users’ needs.
One last point about generating buy-in: you may be surprised to find that it’s less important to adhere to the feedback your team has given than it is to genuinely consider their feedback in the first place. If your team suggests changes that simply won’t work (as proven in user testing or based on your professional understanding of UX best practices), you don’t have to adjust your design accordingly and degrade the experience. Your team just wants to be heard and respected in the same way that you do—they are also professionals with software development experience, and they have valuable insights. So consider their input with an open mind, but know that as a UX professional, your primary responsibility is not to please everyone in the room, but to ensure that the user has a great experience.
Photo by Amy Hirschi on Unsplash