The Secret to Better Design Deliverables
Use these principles to improve the quality of your design deliverables in any work situation.
You’re in a meeting with your senior stakeholders for an important design project. Everyone has cleared their calendars, eagerly anticipating what’s about to be shared on screen. It’s a big milestone. The lead designer pulls up their presentation and… well… no, wait, it’s not a presentation at all. It’s just a bunch of screens thrown together in their design program. The designer zooms into one of the screens and starts talking about their proposed solution. There are a few clicks to another screen, a little mishap with an animation, a few more mismatched screens in another program. And then there’s you. You’re watching everyone’s faces rearrange themselves into different combinations of confused and concerned.
And as you probably already know, things do not get better from here.
We wish this situation were uncommon. But no matter how we’ve arranged our teams, pre-Covid and now, the question remains: How can you increase the impact of your deliverables with stakeholders?
We’ve coached hundreds of designers and teams in how to best document and present their design work. There are a few principles we use that’ll help you improve the quality of your design deliverables* across any work situation.
Just remember this one simple mnemonic: Pizza Pie.
Use the Pizza Principle when creating design deliverables
A good deliverable is like a sliced pizza you’ve ordered from your favorite pizzeria.
Imagine you’ve got one of those pies being delivered right to your door. (Mmm, pizza.) The delivery person puts the box into your hands, you bring it to the table, and pop open the box. You see three things right away: The pizza is self-contained. The pizza has a limited number of ingredients on top. It’s only fresh for a certain amount of time.
Think about those things in relationship to your project deliverables:
Good design deliverables are self-contained. They have a clear start and a finish. It’s easy for multiple people to put their hands on the pizza and take the slices that they want. This becomes especially important if you need specific combinations of deliverable slices, such as an executive summary.
Good design deliverables have a limited number of ingredients. Pizzas taste best when there are just the right amount of ingredients on top—no more, no less. How many ingredients have you included in your deliverable? If you overload the deliverable, you will overload your audience. And, it should go without saying, but make sure you give people the toppings they ordered.
Good design deliverables are freshest at the moment that they’re advancing project goals. If your pizza is delivered half-baked or too late, it isn’t going to help the team the way that it should. User data, insights from research, competitive analyses, all of this information ages quickly. Your deliverable is sinking into lukewarm the moment it hits the screen. (There’s a single exception to this: cold pizza. That’s a specific deliverable that requires a later date in order to be most effective. The deliverable is designed for this purpose; let’s be honest, most pizza isn’t good cold.)
Once you’ve got this analogy, it can be easier to give feedback on any design deliverable that’s moving through your team. Is this the pizza with the ingredients that were expected? Can I see at a glance that the slices are from the same pie? (It shouldn’t be eight slices of different pizzas. It should visually read as one pizza.) Are there any errors or mechanical issues that we can catch while we’re baking and packaging up the pizza? Is it clear how your stakeholders will use what’s included to make decisions and advance your project goals?
Don’t assume your stakeholders can make sense of a spaghetti of design screens. Whenever formally presenting design deliverables, step outside of your design program and logically organize what you’re sharing with “Pizza Pie”.
Deliver the pizza to your audience at just the right time
Okay, you’ve made a great pizza. Now it’s time to deliver it. When figuring out how to distribute your deliverable, plan how you’ll Prioritize, Inform, and Expedite its delivery. (This is the PIE part of the pizza analogy, if you were wondering.)
Prioritize what content is critical for your audience. Take another look through what’s in your deliverable. If there are one or two slices that are more important than the rest, ensure that everyone consumes that portion first. You can visually tell the difference between the pepperoni half and the green pepper half; your deliverable should be the same way. Reinforce visual systems in the deliverable to guide people.
Inform your partners where to focus their attention. If you’re presenting your deliverable, tell everyone what you want them to pay close attention to and the kind of feedback that’ll be most helpful. If you’re sharing a deliverable asynchronously, tell your stakeholders what they should review first. If lots of people are reviewing the deliverable hours or days after you’ve presented, consider editing or supplementing the deliverable accordingly. That’s a deliverable that’s moving into Cold Pizza territory.
Expedite who gets their slice of the deliverable first. Is a portion of your deliverable important to share as a pre-read to specific stakeholders? Do they need more time to prepare if they are contributing to major decisions as a result of that deliverable? Do you have a stakeholder who can only give you a few minutes of their time? Factor this into how you socialize the deliverable, before you’re in the rush of delivering what you’ve prepared.
Maintain the quality of each pizza
Making a good pizza requires good ingredients, from sauce and cheese to various spices. And once you’ve had a taste of a really good pizza, you’ll expect that level of quality every time that you order one.** The same logic applies for design deliverables. If you’re delivering a series of deliverables, we always make sure each deliverable includes the 4Ds:
Did: What activities did you do? This can be as simple as a single slide or summary that lets everyone know what happened most recently on your project. If you’re like most product teams, you eat a lot of pizza.
Discovered: What did you learn along the way? These are big takeaways from your activities. They inform the detailed work that you may need to walk people through.
Decided: What decisions did you make? These may be design decisions that you’re advocating to the group, with appropriate framing if alternatives were considered through your process.
Do Next: What actions does the team suggest? Good deliverables leave pathways for your stakeholders to make decisions. For less complex projects, don’t narrow options too soon. For more complex projects, give your partners criteria they can use to collaborate in prioritizing the options.
Without this information, it can be difficult for your stakeholders to see how each deliverable is part of a coherent story. This applies equally to deliverables from in-house teams and agencies. Agencies often have to deliver their work through presentations that are delivered synchronously, so evaluate slide decks and design assets to ensure they are self-contained and can be socialized easily after each meeting. If you work on an in-house team, many of your deliverables are built around standard collaborative documents that get created and delivered through your design workflow. Covering the 4Ds can get everyone up to speed quickly, so they’re ready to contribute to important business decisions. And the “formality” of the pizza doesn’t really matter: you can cover the 4Ds in an email with a PDF attachment, a bunch of content organized in a collaboration canvas, or a product brief with links to a click-through prototype.
Bring pizza to your next meeting
Let’s go back to the beginning, but place a “Pizza Pie” in that meeting. Senior stakeholders, cleared calendars, anticipation and excitement. The lead designer starts sharing, and pulls up their well-considered deliverable. It’s clear within a matter of minutes that the project is going swimmingly. Decisions are made, actions are prioritized, all the wheels are turning. When was the last time your team had a meal like this?
Footnotes
* Documentation and deliverables are commonly confused on design teams. Documentation is the tangible output of your design work. It’s also the process of helping other people better access and use what you’ve created for their own work. You should always be documenting! But just because you have documentation of your work doesn’t mean it will stand alone as a deliverable. Deliverables are tangible outputs that summarize what happened through your project, and indicate possible use in the processes that follow it. Deliverables should only contain what is relevant to advance project goals.
** Pro tip: Know the taste level of your stakeholders regarding your deliverables. This is something you need to know about your stakeholders and what they’re expecting from your work. Will they be fussy about what ingredients are in the pizza? Giving feedback on the quality of the crust? Or will the pizza that you’re serving them—er, design deliverable—be the best they’ve ever had?