Winning consensus on big, multi-faceted user experience projects. Tips from a UX design expert.

When Visual/UX Designer Chad Beggs accepted a lead role on a project for Microsoft he found himself in a challenging environment, with multiple business stakeholders and competing goals and demands. Working collaboratively with a variety of team members, Chad was able to bring the stakeholders together and help them focus their ideas and bring their vision to life.

I interviewed Chad to learn more about his background, and the know-how required to bring clarity and consensus to such a complex project.


Q: Please tell me about your background and how it prepared you for such a multi-faceted task.

CHAD: I’ve worked as a Visual and UX designer for a decade now. The first portion of my career I focused mostly on designing for advertising campaigns, with some web design work and have transitioned into UX over the last five years. The UX part of my career has involved work across the user experience spectrum. There have been long term foundation building projects, and times where I’ve come in the middle of a site’s life. I’ve created wireframes that vary from small changes to complete redesigns, documented down to the pixel specs for new patterns, crafted personas, and written a bit of UI copy.

My bachelor’s degree is in Graphic Design from a liberal arts university--meaning there was as much focus on non-design disciplines as on design work itself. Looking back I’m extremely happy I went this route because UX teams tend to be incredibly multi-disciplinary, and being able to “speak the language” of business stakeholders, or project managers can be incredibly useful in advocating for the user.

Q: What were the biggest challenges with this project?

CHAD: Any enterprise level UX project is going to involve a lot of voices and opinions in the room. Not all of our team was based locally, and some had schedules that competed with our regular meeting cadence. Getting buy-in and attendance was not always easy.

Also, big projects like this tend to mean working with (or at least considering) legacy systems. That alone can be a large challenge.

Q: Describe the process and how you went about finding solutions.

CHAD: In mid 2014 I began working with researchers on a project at Microsoft. We knew that there were problems with user on-boarding to the site. In fact, that was the number one reason for support calls.

We ran a study to discover where the key “broken parts” of the experience were and over the next two releases worked to solve the usability issues we found.  

Q: How did you and your team gain consensus?

CHAD: It was not an overnight process to convince people that the issues found needed to be prioritized, and it wasn’t an easy process to gain consensus on how to solve them, but with persistence the team was able to propose a solution that made internal stakeholders happy and made our users' lives better. Only by using the strength of everyone on the team—Project Managers, Software Engineers, Business Stakeholders, Researchers and Designers—was this possible.

Q: Tell me more about the specific solutions you developed.

CHAD: We saw that our customers were struggling with issues of getting into the site, so that’s where our team started as well, with the invitation mail. We streamlined the email—stripping out extra links, and simplifying the registration process post-mail. We cleaned up the taxonomy, and developed methods for the system to make recommendations to users so they wouldn’t get lost.

In addition to work on the registration flow and invitation mail, we also made it easier for users to recover their password (if they had an existing account) and gave them the ability to retrigger the invitation email in case they lost it or it expired.

Q: What kind of results did you see?

CHAD: When the work was done and data came back the project was credited with being a key factor in a significant drop in the number of support calls year over year. Our internal stakeholders were very pleased, and our users were able to access the site more easily and quickly. It was a good day in UX.

Q: What would you tell other UX Designers who find themselves in a similar situation?


    • A good UX brief is your friend. Make sure that your team has agreed with what’s in it. Use it to define your problem in a page or less so that you and your team can use it as a “true north.”  Whenever you feel like you’re starting to stray from your core experience you can use it to steer the team back.
    • Document things as well as humanly possible.  This project involved working with a team that was not always in the same place at the same time.  Because of that a lot of the communication had to happen via email or online meetings. Having deliverables that clearly say “here is what we are trying to do, and here is the specific scenario we are looking at to illustrate that” become imperative.
    • Build on your early work to create your later work. This may sound straightforward, but I’ve worked on projects where we put aside storyboards once we were done with them and worked on wireframes in a way that felt disconnected from the foundational work. Referencing and keeping storyboards, requirements, and scenarios alive helped us tell a cohesive story about what we were trying to accomplish. For some stakeholders, seeing how “Requirement X maps to Control Z” on the screen can be incredibly powerful.
    • Tell good stories. Remember that UX isn’t just about making screens for various devices. It’s about providing users with a delightful experience, even (or especially) if a task is mundane.  Because of that, UX designers and researchers have a responsibility to keep reminding their teams that users are actual people and that they need to create things they want to use. One of the most effective ways I’ve found of doing this is to always reference back to existing personas and scenarios.  Do this all the time. Whenever you present your wireframes use your persona names to drive the narrative. Talk about what their lives look like outside of the screen interactions and why they are interacting with your product.  Your non UX team members may scoff at first, but they’ll come around eventually, and you’ll find them referring to the personas by name when they talk about new scenarios.

Q: What were your key takeaways from this project?


    • Be clear about deadlines and expectations. When presenting always be clear about where you are on the project, what type of feedback you are looking for, what dates you are driving toward, and what the feedback window is.  Without saying this up front, and at the end, people will forget about the deadlines and rules and you can wind up churning on a project.
    • Understand what a win looks like. On enterprise projects especially you may not be able to solve everything in a single release. That’s okay. Know what your roadmap looks like, understand what your release solves, and execute it to the best of your ability. Understand that sometimes politics, technical debt and schedule may get in the way of what you’d consider a perfect solution.  If you can create incremental design changes that get you where you need to go you’re still doing a world of good for your user.
    • Be persistent. Change takes time.  Be prepared to stick it out for the long haul, and don’t be afraid of being a broken record.




Hire Filter

We execute digital marketing & design