8.8 Presenting Designs 🎯🤙
This section includes an Activity 🎯 and a reminder to have a mentor call 🤙
As you already know, a big part of the PM role is communicating the decisions you've made about the product and the designs. You'll communicate this to various audiences and for various purposes. Your developers need to understand these designs on a different level than your boss or executive team will.
The way you present designs will differ based on the audience, your goals, and the phase of the design process you're in. In this checkpoint, you'll dig into what makes a great presentation for a design.
By the end of this checkpoint, you should be able to do the following:
- Effectively present an interactive prototype and tell a story about the user experience
Why present designs?
When you're working on a product or feature, everyone will want to see what you're working on. It's up to you to inform your stakeholders about what's happening and to get their feedback. The most important reason to present designs is to communicate the way a product or feature is intended to work so you can confirm if you're on the right track.
There are other benefits to presenting designs in all its phases. Reviewing designs gives you an opportunity to explain the why of what you're doing. Every product and feature should be a solution to a problem that your users have. A design is a way to present a specific solution to that problem. When you present the designs, it gives you an opportunity to review the problem, to defend why this is the best solution for it, and to make sure that your designs are really addressing that problem.
You'll want to share your designs with other stakeholders and coworkers so you can get their feedback. Your coworkers will appreciate being informed about what's coming up next, and they'll be able to give you critical feedback on whether or not the designs will address the problems you're trying to solve. For example, the sales team may inform you of a market problem for prospective clients that won't be solved by your current design. These conversations are useful to have before the product has been created so you can address them before it's too late.
Designs are also a key deliverable from the product and UX team to the engineering team. Your developers need to understand how the designs work so that they can decide how to turn the designs into a real product. You'll explain the designs to your developers so they can inform you if what you are planning is feasible or if the designs need to be changed due to technical complexity or other issues. Many times a design works well as a prototype or wireframe, but technical issues arise on the way to the final product because of developer skill set, priorities, and other considerations. It's best to solicit feedback from your developers early on in the process to ensure your designs make sense from a tech standpoint.
Finally, design presentations are useful when discussing the trade-offs that you had to make. Maybe you had an idea for a feature that was too difficult for your developers to build in a timely fashion. Similarly, you could have gotten feedback from stakeholders that you must include a specific feature for this to be successful. These tough decisions are important to share, and discussing them with the designs in front of you is a very effective way to do so.
A general method for presenting designs
When you present your designs, here's a quick checklist of what you'll want to do.
Share the context
Most of the people who encounter your designs for the first time will have no idea what problem you're addressing and why you're addressing it. It's important to give context before diving into your proposed solution. Share the problem first. Which users have it? What is the problem? How do you know this? Then, present the general approach you're taking to solve it, and explain why your solution solves the problem. Always bring evidence to justify your decisions—data, observations, and feedback.
Walk through the happy path
You may recall the happy path discussed when you learned about user flows. It is a general term for the primary path that leads users to a desired interaction. When you present your design, tell the story of a user going through the interactions via the happy path. Whether you're using sketches or an interactive prototype, you can act out how the user will go through the flow and how the product will respond.
For example, the happy path for an Amazon's "Buy Now" feature is:
- The user searches for an item.
- The user clicks on the item they want.
- The user clicks on the "Buy Now" button.
- A modal appears that details the date of arrival, the payment method, the shipping location, and the order total.
- The user clicks on "Place Order Now," and an email or text confirmation is sent to the user.
- The user receives their package.
There are many variations and exceptions to this path (explored below), but you can already see how describing the intended happy path allows your stakeholders to understand the intended best-case scenario for your product solution.
Exceptions and detours
If users stray from the happy path, there will usually be additional steps. Make sure your presentation shows what that will be like. For example, an error, additional option, and other choice could take the user toward another interaction.
In the Amazon example above, a user may not want to use the stored payment method. Or they may want to change the stored shipping address. This deviates from the happy path but is still a viable solution to the user's problem.
Constraints and cuts
Often there are great ideas that you'd love to address but that aren't feasible. Maybe they're too difficult or would take too long to develop right now. Make sure to identify these in your presentations and explain why you're not going to address them now. Acknowledging the things you are not doing is a good way to let your stakeholders know that you've heard their feedback and have good reasons for your priorities.
Steps to done
Design presentations are a chance for you to explain how you'll get the work shipped in bits and pieces. Sometimes the designs represent the entire product, and the plan is to ship all at once. Other times the designs are for the final state of the product, but you will be delivering it in small pieces along the way so that you can iterate or get certain features out faster. Make it clear how you intend to deliver this, and show designs for how it will evolve step by step.
For example, if your product's first version is going to be a very simplistic version of your final product, show the designs you are envisioning and the steps you'll release along the way.
Take questions
Always make sure to leave time at the end of your presentation so that others can ask questions or offer feedback. Some people may not want to interrupt your presentation, so it's up to you to create space so they can ask what's on their mind. The conversations you'll have with people who have a different perspective than you are always beneficial. They'll either reinforce your decisions or help you identify gaps that you couldn't have thought up yourself.
Below, click through a design presentation for an app called Hello Caregiver, published with the authors' permission. Notice how the presentation begins with the problem and ends with a mockup of intended features to solve it.
The fidelity question
Should you present hi-fi, near-perfect prototypes and mockups or early-on, rough sketches? The answer, as always, is it depends—on your audience, your goal, and your stage in the process.
Presenting sketches
Sketches and other low-fi designs are great to present when you need early feedback from your most important stakeholders. In particular, you should share sketches with your developers and other product team members so they can give feedback about constraints, technical problems, or other issues you may encounter while developing this.
Other close coworkers, like key people in your sales and customer-facing teams, should also be consulted. In particular, you want their feedback on two things—whether or not you have a thorough understanding of the problem to solve and whether or not these designs really solve it. The people who interact with your customers day to day are the best ones to give this kind of advice.
You will not, however, want to share sketches with executive management, customers, or other coworkers. Sketches are too vague to enable most people to give you effective feedback. There's a huge gap in imagination between viewing a sketch and viewing a hi-fi design that looks very similar to the final product. You'll discover that most people can't make that imaginative leap. Executives may approve sketches but later have lots of feedback on hi-fi prototypes that are essentially the same. And customers may have negative feedback on a design not because it's actually wrong but because it doesn't look like it eventually would. In these cases, you'll be better off waiting until you have a more detailed design to share.
Presenting mockups and prototypes
High-fidelity mockups, wireframes, or pixel-perfect designs are the most ideal versions of your work to present to coworkers and stakeholders outside of the product, design, or tech teams. Hi-fi mockups are the closest to the actual product, so viewers don't have to use their imagination very much to understand them. Also, your design team is likely to produce hi-fi mockups or wireframes as their most common output when designing new features.
Even better, you could share an interactive prototype that will allow stakeholders to click through the product themselves. Keep in mind, though, that if you share them without being present (such as through email), you need to provide enough context so that the viewers can understand how to get through it. If you just share out the prototype without explanation, viewers may get lost, especially if the users aren't familiar with the prototype tool you used. Prototypes may be best presented with you there to walk everyone through the process and answer questions on the spot.
Handling design feedback
When you give your presentation on your designs, you'll get lots of feedback and questions, many of which may seem like an attack on your designs or decisions. Keep these tips in mind so that you can keep your cool and respond in a professional and effective manner.
It's about the designs, not you
Much of the feedback you'll get will be criticism about your designs. It's easy to fall into the trap of believing that stakeholders' feedback is about you and your decisions. Make sure to put up a healthy separation between feedback about your performance and feedback about your designs. It's most likely not about you. Don't make the mistake of misinterpreting feedback or getting defensive. Listen to their feedback, explain your decisions, and trust that if your trade-offs are logical, your stakeholders will be able to see that too.
Five whys
You'll get a lot of feedback asking why you did or didn't do something or why you chose to do it one way when you could have done it another way. Make sure to address this feedback, and then ask your own why questions in return. The initial questions and feedback are usually a veil over a deeper truth.
For example, if someone asks you why you placed a button in a certain position, ask what they think the button should do or where it should go. Then, ask why. Continue probing; use the Five whys technique discussed in an earlier checkpoint to dig deeper and really understand the feedback. It is said that after about five whys, a deeper understanding of the root cause of a problem emerges.
Acknowledge it and take it offline
Sometimes the best way to handle feedback is to agree and defer action until another time. For example, maybe your button placement was really bad, and you should address it. Just say, "That's a good idea," and let them know you'll come back with a tweaked design in a couple of days. Agreeing is a fast way to end a discussion, but remember that you need to follow through on whatever you agreed to. If the changes need to be done by your UX team, make sure that they agree and will follow up with the changes.
Defer to testing and MVPs
Sometimes you'll have genuine disagreements about the effectiveness of your designs you won't be able to solve during one presentation. A good way to move past these arguments is to test your designs. For example, let's say you and another stakeholder are in strong disagreement about the button placement issue. Sometimes, the best way to come to a decision is to conduct feedback sessions with other stakeholders or customers or find an MVP of the designs to ship so you can confirm the direction of your designs. You can also run tests or MVPs for several competing design ideas to see which one is received better. You will learn more about methods to do this (such as A/B testing) in a few modules. Once you finish your tests, you can return to your discussions with the stakeholder better informed and be able to plan your next steps.
Common questions
Here are a few of the most common questions you'll get when you present designs. You should be prepared to answer these whenever you are showing your designs.
Why are we doing this now? or Why aren’t we working on X instead?
You might get a variety of questions about your choice in prioritizing this feature over others. The best mitigation for this is twofold. First, always make sure to present the context behind the feature. Bring data, interviews, or any other evidence to justify why this is an issue that needs fixing now. Second, you can share your roadmap—your timeline for future features—to show how this work fits into bigger goals and other product changes that are coming up. The next module will focus on roadmaps.
Why does it look (or work) like this?
Many people will have a visceral reaction to seeing your designs, and their feedback will be focused on nitpicking the design details. This usually happens for one of two reasons. First, they might imagine it's supposed to work another way. In this case, make sure to ask follow-up questions about how they expect it to work—it could give you valuable information on the mental models users may be coming in with. Second, stakeholders might disagree with the feature altogether and are expressing it via nitpicking the details. In that case, you need to ask why until you understand what their real objection is, then address it.
Where is feature X?
Sometimes you'll get feedback from people who want more from your designs than what you have to show them. Maybe they are expecting additional filtering options for your search feature or more buttons that do more things. There are a few different ways of handling this. If what they are asking about is something you intend to add, you can defer this by mentioning it's coming in a later version or release. If it's not something you intend to add anytime soon, you can ask your Five whys to understand why they believe it's important to include now. And if it's a good idea and you should add it, you can always agree and change your plans.
Activity 🎯
Go back to the designs you prototyped in the last checkpoint. Think about the problem you are trying to solve, and add any additional pages or page states needed to round out a complete story. For example, you could show a blank search page (no searches started), a search results page with many results, and a search results page with no results.
Record yourself presenting your designs. Keep the total length under 15 minutes. Use Camtasia or a similar screen-casting application for recording this. Make sure both you and the slides and your prototype are visible (preferably at all times, but it's okay to switch between speaker and prototype as long as we see enough to evaluate both).
Remember, bring your enthusiasm for the product to life, and tell a story about how you would expect a user to work their way through the site. Demonstrate your story as you follow the same steps in your interactive prototype. Describe the decisions you made regarding specific design choices or UI look and feel, and answer expected follow-up questions.
Upload your recorded video online and paste the liink on the first slide of your Slide deck.
Ensure you meet the below rubrics for your activity. You do not need to submit this activity to us but do try it to improve your presentation skills.
| Criteria | Exemplary | Proficient | Developing |
|---|---|---|---|
| Presentation | The student is concise and confident and tells a clear narrative about using the site. The student knows the material and has rehearsed and does not mumble or fumble over words. The presentation is under 15 minutes. | The student is somewhat confident and seems nervous or agitated. The student's speech is, at times, unclear but is overall easy to understand, and they tell a mostly clear story about using the site. They have rehearsed but have some trouble conveying the message. Their presentation is under 15 minutes. | The student is nervous and not easily understood and tells an unclear story about what this site is for. They fumble over various parts of the presentation, mumble, and are not always easy to understand. The student does not seem to have rehearsed. Their presentation goes over 15 minutes. |
| Prototype | The student uses best practices in design and shows multiple states (logged-in and logged-out, errors for forms). It is easy to navigate their prototype. | The student mostly adheres to best design practices but makes some small mistakes. They have one or two pages of multiple states. There are one or two mistakes in links or navigation in the prototype. | The student does not adhere to best design practices and does not include multiple page states. There are errors or missing links in navigating the prototype. |
Mentor Call 3 🤙
Time for your third mentor call. Although you could get mentored from any free platform online, we recommend ADPList as it's free and boasts a huge community of product experts. You might have to signup to it's platform (which is again free) and schedule a mentor call from the ADPList platform itself.
Schedule a mentor call with an ADPList product mentor. ADPList provides free mentorships for everyone and is an amazing platform to learn and meet experts. Please ensure you take mentor calls with importance. Mentors play a crucial role in your career. Do not ask mentors to review assignments. They are only meant to guide you and give you tips on your growth. These are optional calls as well.
Let the mentors know beforehand what the call is about. Share you questions and let them know you are a bootcamp student. Again refrain from asking assignment related questions. They aren't meant to review your assignments.
Below are the list of mentors that we have collaborated with at PMcademy.
Looking for more mentors ?
You can choose to get mentored from any other mentor as well. Visit this link to find more product mentors from ADPList. However note that not everyone is aware of PMcademy, it that case let them know beforehand about PMcademy.com and about your meeting agenda.