How to do a Perfect Internal Design Presentation
Jacob Neilsen famously said: “there are no mysteries of usability, no more than there are secrets of astronomy.” I always encourage designers to present designs internally as much as possible, precisely to remove the air of mystery and confusion that frequently surrounds the design process. Although the actual breakthrough “aha” step in many designs is often messy and hard to define, the rest of the team must see design as a craft, a job, much like any other. Design is something real. It’s not voodoo — it takes effort and time and brings tangible value to the enterprise.
Thus, in addition to presenting the information at hand, internal design presentations have a secondary goal in mind. Here then is the anatomy of a perfect internal presentation:
0) Your name and role
This is essential — and it’s not tooting your own horn. It’s a stamp of ownership. Including everyone else on the team and all of the people who helped you along the way makes you look like a team player. But having a “buck stops here” name, the owner, the one ultimately accountable for the outcomes shown in the presentation, is non-negotiable.
1) Include Jira number.
It’s key that the rest of the team sees that design tasks as no different than coding or QA tasks — that is why we use the same ticketing system as coders and QA engineers. They have Jira numbers, and so do we. (For the same reasons, the tickets must be aligned under dev epics and follow the typical Sprint cadence — more on this in future posts)
2) Include the larger goal of the project.
Goals should be presented as the overall idea behind the undertaking (e.g. “to enable our customers to do e-commerce checkout”) and show how they fit into the overall Product strategy (e.g. “so they can find a product and pay for it, so we can collect the payment”)
3) List the specific use-cases that your design covers (and indicate which will be covered by your presentation.)
High-level goals are all fine and good, but nothing says you mean business like stating goals in standard agile parlance: “as a new customer, I can enter my credit card information and address so that I can complete the checkout.” Include personas or at least a use-case-based persona skeletons: Is this a new customer or an existing one? Support Person, Manager, or an Administrator?
4) Cast your initial design idea as a “villain.”
It’s important to convey a sense of struggle and progress toward a design goal without overloading or boring your audience. One of the best ways to do that is to include a kind of “before and after” as part of your story. You did not just ship the first thing that came to mind because it was crap (that was your “before” state, the villain.) You had to talk to X number of customers to do a thorough bit of testing. Customers’ behavior during the X number of tests informed you to make certain changes; this is the final design that is being built (that is the “after” state, the hero of the story.) “Before” can also be the existing design you are fixing. Customer feedback can be complaints your team received via Twitter — use your imagination and the materials at hand. In either case, be clear why the “before” plays the role of a villain in your story. (And for God’s sake, don’t show the process as a circle of bubbles. Everyone has seen that diagram. It’s boring. Instead of telling your audience about the story, tell them the story!)
5) Present the final design as a customer journey.
Use the use cases as a guide to walk the audience through how a user would utilize your new UI. Include any “aha” moments that led you to the design of a specific element here and there to spice things up. Keep it interesting — no one wants the geographic tour — ” In the top left, I put a logo… Then I added navigation below that…” that’s boring! People can see what you did. Instead, direct their precious attention to how a customer would move through the flow. What were the sticky points identified in your research? How did you solve them? What’s the final state?
6) Include the benefit!
This last bit is where most internal design presentations fall woefully short. As a designer, you must always be aware of why you are doing something. This is not art — it’s design, which means it’s a prototype of a thing intentionally targeted toward a specific outcome. That outcome is some kind of a benefit for your enterprise, usually monetary in nature. But don’t limit yourself to mere money earned. The benefits of a good design often extend beyond the initial encounter. Would a better design of a checkout process, for instance, increase customer satisfaction, customer loyalty, lifetime customer value? You bet. Increase trust? Absolutely. Would a guest checkout also increase the number of customer registrations? Count on it.
Make an effort to show benefits as ROI numbers and include customer quotes that demonstrate how much they prefer the new design. In short, do everything you can to show that the management was right in trusting you to take care of this problem and that the solution you presented is the best combination of bang for the buck that could have been produced in the allotted time.
The final slide of your presentation should, as Warren Buffett says, “make them tremble with greed.”
(I always think about Eustace Bagge from Courage the Cowardly Dog shouting “Money! Money! SO MUCH MONEY!” but feel free to pick whatever visual you like and build from there.)
7) Conclude with the Release Date and Next Steps
Nothing frustrates an awesome presentation as much as breaking the hand-off and just “letting it hang there” — remember, everything you do is in the context of everything else that is going on in the enterprise. Design and user testing are part of the release process—every time. Thus including the next steps, such as when this awesome thing you just showed us will get released, is essential. Also include any future research inquiries, additional use cases you are planning to work on, and the timeline for their delivery and release.
Finally,
8) Remember the Appendix.
The Appendix is another important part of the presentation that many designers forget to include. This is a mistake. One of the most popular questions after the design presentation is, “have you thought of doing X?” Most likely, you did! However, digging through 4 months' worth of designs is usually not possible in 30 seconds you have to answer the question, making you look disorganized and lame at the exact moment of maximum glory. (That’s bad.) For this reason, I always make an effort to include in the Appendix all of the designs we’ve tried and rejected for various reasons. Preferably annotated with customer or developer quotes remarking on the solutions’ potential fitness for the goal at hand. Thus, having the Appendix full of old designs makes it laughably easy to answer these “have you thought of” questions and makes you look highly competent into the bargain — “yes, Mrs. Manager, we did think of this and tested it thoroughly, and we know from our research with N customers that our final solution performs better for reasons X, Y, and Z.” Don’t think doing this makes people feel bad — quite the opposite! It makes them confident you are a design expert, a professional, and that you did your homework and covered all of the key angles.
In short, it makes them confident that they are in good hands.
And that they are about to make Money! So Much Money!
