Design’s Fully-Baked Deliverables and Half-Baked Artifacts

Cakes exist in two states. We don’t think about this, because we’re usually focused on only one state. But that state couldn’t exist without the other one.

There are cooked cakes, which we enjoy. And there are uncooked cakes, which need to become the cooked cakes. Batter and cake. The two states of a cake.

This metaphor breaks pretty quickly, so let me get through it as fast as I can (which is typically how I tackle a cake). Without batter, there can be no cake. Yet batter is different from the cake. Batter looks and feels different from cake. It serves a different purpose.

The cake state is ready to be eaten. The batter state is about being made. Sure, you can eat some of the batter (who hasn’t licked the mixer beaters?), but baking the batter into the cake is the real objective.

Batter is about constant change. As you mix in the ingredients, the nature of the batter shifts. Cake, on the other hand, is static. Once it becomes cake, it remains cake. (Let’s not talk about drying out and becoming stale, as that is where the metaphor breaks. At least, I hope it breaks there.)

In design, we have something similar to the two states of a cake: artifacts and deliverables. If deliverables represent the fully-baked ideas in our design, artifacts represent the half-baked ones still forming.

The distinction between artifacts and deliverables is very important, yet something we never find ourselves discussing, just like the multiple states of cakes. If we create one when we think we’re creating the other, it will lead to confusion that wastes time and convolutes the team’s efforts. We need to understand how they work and what makes each one valuable.

Before and after the decision-made point

Artifacts and deliverables are very similar. In fact, they can sometimes take exactly the same form.

A wireframe, for example, can act both as an artifact or a deliverable. Same with a persona description, a user scenario, a journey map, or design sketch.

For artifacts and deliverables, the state changes when the design decisions are made. Before the decisions are made, a design sketch or user scenario is just an idea — a proposition that helps us understand the problem better.

After the decisions are made, a design sketch tells us what direction the design is taking. The user scenario informs the team on what problems the design wants to solve.

Deliverables are for communicating intention

Deliverables are how we tell the story of what the design will be. Of course, the classic deliverable is the finished product itself. Nothing tells the story of the design better than the product.

In the days of old, the finished product was the only deliverable. There were no plans or blueprints, just what the craftsman completed.

Collaboration across the organization changed all that. Others needed to know our intention — what we wanted the design to be. Thus, intermediate deliverables were born.

Deliverables have historically taken the form of descriptive specifications. Because representative prototypes have only become a reality in recent times, we relied on documents filled with descriptive prose and flat, two-dimensional sketches to communicate our intent for the final design.

Only in the last few decades have we started to understand the notion of a prototype as a deliverable. Architects started making little models of the skyscrapers they wanted to build. Car designers made clay models of the vehicles they sought to put into production.

In the online world, we use site maps and wireframes to specify what we’d like to see built. When the designer is not the person who will implement their design, we need ways to draw out what we’re doing.

The lean push to eliminate deliverables

Recently, “deliverables” has become a naughty word in the design community. We’re told we need to stop working on creating deliverables, and focus on building the product itself. The argument is deliverables can’t be shipped and anything we need to specify can be embedded in the product’s code — the ultimate specification, we’re told.

There’s a lot of logic to this argument. For example, to specify the colors of a design, the designer could code up the color values directly into the CSS. Developers on the team can use those CSS specifications directly in the code. If the designer wants to then change the color, they simply change the CSS and everything propagates in the next release. No need for the developer to check a non-shippable Photoshop file to get the color values.

But deliverables aren’t only used to communicate to the developers the specifications of what to build. They are seen by stakeholders and others in the organization, to understand the direction of the design. Sometimes it’s to show progress is happening. Other times it’s to give insight into specifics others need, like how to plan the product’s marketing messages. In an organization that has many parallel activities leading to the product’s release, deliverables communicate how the jello is being nailed to the wall.

It’s unlikely these deliverables can be eliminated. The marketing folks aren’t going to look at the code-in-progress to see what’s been decided, so they need to get the intention in another form.

Intermediate deliverables that show the designers’ intent will always have a place in large organizations. No amount of wishing will make them go away.

However, we can always ask ourselves if a non-code deliverable is the best way to communicate to our audience. We can design deliverables specifically to the needs of the audience. This means we need to be fully versed in all the different techniques and flavors deliverables can take.

Artifacts form a common understanding

Artifacts represent our current thinking about upcoming design decisions.

Sometimes, we produce a ton of artifacts very quickly. Take a design studio, for example. In the process of a few hours, the team will produce dozens, if not hundreds, of sketches. Each sketch explores an idea or two about potential solutions.

What’s interesting about the design studio artifacts, like all good artifacts, is the discussion they encourage. The team can look critically at each artifact and develop a vocabulary about the problem.

Most artifacts are thrown away, having the ideas in them deemed ‘not worthy of further contemplation.’ But, the process of creating them, critiquing them, and discussing their implications lives on. They become the basis to the teams common understanding of the problem.

The disorientation of hunkering

Artifacts are most useful when working amongst a cross-disciplinary team. Creating the artifact gets the creator’s ideas out into a common place where it can be inspected and discussed.

This is a form of hunkering, where we take an idea and put it into the world, to see how it works when it’s not just in our own imagination. Seeing a design like this is disorienting for the creator, because the reality of seeing it is very different from just imagining it. It points out flaws in the idea, but it also can spawn inspiration.

When people with different perspectives hunker around a design idea, the discussion creates a useful vocabulary about what the team is trying to do. It can lead to new directions. Repeating this frequently can generate whole new approaches to the problem that wouldn’t be considered otherwise.

Artifacts and deliverables each tell the story differently

Not all artifacts should be discarded once the team has milked it for all they can learn. They provide a rich history of the thinking process.

A design’s story isn’t just its final outcome. The story also needs to include the journey the team took to arrive at that outcome.

Artifacts are useful for communicating that journey. In fact, it can make for a very powerful presentation to stakeholders to show some of the artifacts that demonstrate the constraints, challenges, and thinking behind the final design.

Surfacing the effort can be both enlightening and entertaining. (After all, who doesn’t like the behind-the-scenes footage found in the DVD extras?)

Deliverables tell the story of what we think the design should be. Artifacts tell the story of how we got there. Each are powerful storytelling tools.

Serving different purposes

Just understanding the difference between artifacts and deliverables can make a team more productive. Knowing which they are working with, at any given point in the design process, is critical to getting the most out of them.

Artifacts are often best in a rough form, when many are produced quickly. Deliverables often want more refinement and are iterated over to accurately represent the team’s thinking.

Deliverables are often horrible tools for debating options. The team really wants to have settled on their decisions before they construct their deliverables.

Artifacts, on the other hand, are perfect for debate and discussion. Their lightweight and short-term view makes them the perfect straw man proposal to test ideas and explore the problems. It doesn’t make sense to refine most artifacts. Instead, you just throw them aside and start anew.

The challenges of being clear about malleability

We can’t tell which we’re looking at by just looking at the artifact or deliverable we’ve made. It’s easy for a wireframe to be a deliverable, showing the developers what we want the page to look like. But a wireframe can also be the starting point of a discussion about the design, with no intention it’ll be implemented as is.

It’s the context of where the wireframe is being used that determines what it is. Is it before decisions have been made or after?

As a practice, we’re not very good about being clear on this. And when there’s a lack of clarity, confusion sets in.

We’ve played with the fidelity of our tools as a convention. For example, making a rough design mockup with a tool like Balsamiq gives the impression the design is still under consideration, versus something that can look photo-realistic like an HTML prototype. Lower fidelity says artifact, while higher fidelity suggests deliverable. But not all types of artifacts and deliverables have a fidelity dimension to play with.

What makes this even more complex is, in a project of any reasonable size, design decisions aren’t made all at once. They are distributed throughout the project timeline, with some decisions cast into stone while others are still awaiting exploration.

Showing which decisions have been made, when some are still pending, can lead to challenges. We need to develop tools and processes to communicate where we are in the decision making process for a given design.

There’s still plenty of thinking we need to do around artifacts and deliverables. I’m looking forward to more discussion and examples of how teams are solving these important challenges.

We need to embrace our half-baked artifacts and understand better how to utilize our fully-baked deliverables. This kind of introspective approach to our design process will make us better designers and produce great designs.