What to consider when presenting your designs to different stakeholders.

Executives, Product Owners, BAs, Developers, etc. will all look at your UX designs and prototypes through a different lens.

• Product Owners are closest to their users. They want to know if the feature being designed satisfies user needs and fixes any negative feedback, but also results in a sense that the customers were part of the design process. They want to demonstrate that they heard what the users wanted and are they delivering on it.

• Developers will be coding the UI or the back end, and will look at mockups differently. Front End Developers will look at the components that make up the UI layout and be mostly concerned if there is something they’ve not seen before from the design system. However, they will trust that the designer has been responsible and used approved components. They will look at the designs to find similarities to something they’ve coded in the past, and then determine how long it will take to code. This will inform the next Development sprint.

• Business Analysts are often closest to requirements and the Developers. They will be looking to see if the data being presented makes logical sense and meets the requirements of the use case. Has the acceptance criteria been met?

• Executives are interested in how the designs fit in with the overall strategy and priorities. They will often rely on mockups to convey to their peers and/or other leadership that the new initiatives fit into and support a prioritized product roadmap, and how it will be funded.

So how do you satisfy all these audiences? Here are some more tips when presenting your designs:

• Briefly summarize the UX effort, to-date. Explain the intent, and state what kind of feedback you are hoping to get and how this will move the process forward.

  • Example: “After reviewing the requirements with the Product Owner and understanding the user’s needs, we wanted to offer an intuitive way to create notes that can also be easily found, so they can be quickly reviewed and cleared. You are about to see a first draft and we are looking forward to your feedback. Be as specific as you can, so we can make any needed changes, because the next sprint starts in 2 weeks”

• Restate the reason a user is there, what they are trying to accomplish and why the default view is what it is. This answers the user’s questions “What can you do here?” and “What do you want me to do first?”, which demonstrates empathy for the user and coveys you understood the use case.

  • Example: “The Preparer has come here to review and clear a note about a report. They can take up to a half hour to conduct analysis. Clearing the note moves it to the next step.”

• Remember, you don’t need a lot of time. A typical review can be just 15-20 minutes. If you can keep it brief and impactful, you can show your client the value of a quick UX review; they will appreciate the conciseness of the presentation.