This is a great summary, Peter. I am delighted to see a great number of non-traditional deliverables in here (proverbs!), and I hope this makes a lot of designers think really hard before simply diving in and doing the same old deliverables and methodologies they've always done, and instead start trying or even making up new processes that work with the particular problem at hand (as I advocate in my Holy Grail article you so graciously link to on the right).

And the treasure map is a gem. I just hope nobody sees it as a linear process. You should add some short cuts and such to jumble it up a little bit! :-)

Thanks Chris! I too hope folks don't take the linear path literally. Your shortcut suggestion is an excellent one. We could also add a mystery spot or two to encourage the invention of new methods and deliverables. Keep those ideas coming!

Excellent document, thanks so much for sharing.

I think this is an excellent way of helping non-designer folks understand the design landscape. Thanks for making this and sharing!

Hi Peter, thank you for the great document!
Now I'd like to translate it into Japanese. May I publish it on my own website, or should I send you the translated doc?

Excellent post, thanks very much. This has clarified a great deal for me; I think that deliverables are vital to a project, especially when we're dealing with such intangible stuff. It gives us something to aim for, to plan our projects around, and something that we can all agree (or disagree) on, but most importantly discuss. Really important for client facing work, and also when you're bridging teams, like design and development.

Noriyo, please feel free to publish the translated version on your own site, though if you create a translated version of the treasure map, please let me know so I can add the image to our Flickr collection. Thanks!

Thank you Peter (and Jeffery) for this list!
It comes in handy as I am gathering more examples of structured lists of deliverables to inspire my UX department to document our own. Now we *must* have icons for them too :-)

Dankeschön. Since there are too many discussions every day you never can get enough arguments.

Great stuff! I like how each step has a number of examples to view. Great for non-designers and those just starting out :)

Peter and Jeffery, thanks for another enlightening article for the verbally impaired (us visual thinkers ;-).

I encourage, no implore, everyone to read Roam's Back of Napkin and *share* it with your non-visual thinking friends. Also, Dave Gray and the folks from are fantastic visual thinkers/explainers.
Made to Stick is great so far too, but I haven't finished it yet.

I second Fahey's sentiment about short-cutting some of these steps and adhering to the Map in a legalistic, formal sense. There should at least be some consideration to each of these aspects throughout the design process, though.

Thanks for all the links and research put into this article as well, guys. This page provides a great springboard to many excellent practitioners.

Nice stuff indeed! I just hate the word "deliverables" -- so document and not activity focused.

Very well done and organized. I'm a HUGE fan of Indi Young, author of Mental Models. If there were a sketch icon for a mental model (affinity diagram) as a UX diagram, what might that look like?

Do you think mental model diagrams are an essential (real) or optional (imagined) UX deliverable?

Brilliant, simple, helpful, relevant! Thanks!

Thanks for all the positive feedback! And yes, I agree there's a danger of folks focusing too much on the destination and ignoring the learning opportunity presented by the journey.

To borrow from Ambient Findability, what we find (and learn) along the way may change where we (want to) go.

This is an invaluable overview and bibliography--concise, insightful, and relevant. Thanks for your contributions to our field!

Can I carry your books? :)
Wow, I loved your post.
Great job!

I'm also a HUGE fan of Indi Young :-)

I actually did a draft sketch of a Mental Model. It looked like this...

...but then we included those within the Concept Maps category.

And, now you see why Jeff does the drawing :-)

Very nice overview - very nice. Much appreciated.

I've read both the books that you mentioned (Made to Stick and The Back of the Napkin).

Definitely found Made to Stick more *actionable.* I've tried to implement some of the things I learned about visual thinking from the Napkin book, but it's challenging!

Wouldn't "design comps" be another deliverable to include? A visual that shows all of the design details in context (a page, a screen).

Great list and a great resource. Good on you for doing the Back of the Napkin job with the images too - made it much clearer.

We had "design comps" as a standalone at first, but then lumped them under "concept designs." I'm sure the splitters...

...will disagree with this classification decision :-)

BTW, Michael Angeles has already created a new poster based on the article and map...

Very cool!

Great list Peter and I like the examples and additional info links. Here are a few deliverables that come to mind:

Rich pictures (stakeholders, boundaries, and concerns)


Metaphor deconstruction diagrams

User Experience/Usability Specifications

Affinity diagrams

GOMS models.


The irony of the title grabbed me instantly. “User Experience” comes from architecture and the arts whereas “deliverables” comes right out of the corporate world of profits, deadlines and bottom lines. Merging these two was skillful and helpful to my efforts to educate Fresnans about design anthropology.

I look forward to the book!!

We could add multi-media items like videos (Utests, interviews, CI), screen shots, etc.

wow! thank you for sharing!

I can see already we need a faceted classification scheme. One facet is the part of the lifecycle. Another is how you deliver the information (presentation, video, ...). Another could be the viewpoint of the experience (user's view vs. a system map). I bet a good IA could come up with something overly complex. (^:

I began to flesh out the facets, but then decided to crowdsource...

...start tagging Keith! :-)

Very interesting Peter, there's a lot of good ideas here to ponder.

My first and biggest reaction though, is that while it's common to call these artifacts "deliverables" I prefer to call them documents. I deliver software and systems, just as an architect delivers a building or similar. I don't mean to play semantics, it actually has a lot of ramifications for our field. If, in the future, better tools make those documents mostly unnecessary, IAs who define their value by their documents will face a difficult adaptation (or not). Imagine an architect who says, "Here's your blueprints and renderings, my work is done here."

Also, my spell checker wags its finger at me when I type "deliverables" and I tend to agree with her.


Thanks Victor! You make some good points. I agree we need to be careful about defining our value by the artifacts we produce.

Our contributions to the process and the product and the customer experience and the business results are all important.

I see it as a matter of context. When I consult with large organizations, there's more emphasis on deliverables. I will never meet some of the people who build upon my work.

When I consult with smaller organizations, learning through collaboration is more important, and I have a larger role in shaping the software or system.

And, if you're an innie (rather than an outie) that presents yet another kind of context.

I personally think "deliverables" works better than "documents" because it's more specific and is well-understood and much-used within the broader business community.

Either way, you'll never convince me to change my ways with the old spell-checker argument.

Remember, I'm the "findability" guy :-)

Good stuff, Peter. Personally, I think of these items as spices in my kitchen. All are good, but not all at the same time.

Good designers use each individual technique when they deem it appropriate. Bad designers use too many, too few, or abuse them through incompetence.

As to the semantic discussion regarding "deliverables" and "documents," well, if your napkin sketch shows a suggested method, a concept, or an actual solution, then it's a deliverable. If it simply records a range of ideas, it is a document. The difference lies in whether the artifact represents an actual decision/recommendation.

Thanks Eric! I love the spice analogy :-)

Coming from another design area, this is really great to see as a list of tools to learn about for producing designs. And I do use some of these, just many aren't appropriate.

One area that you touch on that makes up a large chunk of what I do is writing. It is a critical component and I see it mangled so often on the web and in desktop products. So I write this with the purest intent. I *implore* you to remove the Strunk and White reference and replace it with the book referred to here: S&W is not truly a valid writing reference. It has a few good things to say about style, but there are much better resources.

This is not a plug nor even a criticism. Just trying to help.

I like the list, but am intrigued that "presentation" features as a separate deliverable. Surely it is often just the means by which we convey a deliverable, and its meaning, to a client/stakeholder?

I also see that you don't include heuristic evaluatio/site review as a deliverable. Maybe you see this as an activity rather than a deliverable? Certainly the way the results are delivered is often through a presentation, and most successfully conveyed using personas and scenarios. Maybe quite a few of these deliverables work best in combination rather than on their own?


Yes. A heuristic evaluation is a useful deliverable. We just couldn't include them all. We included presentations to encourage people to think in advance about how they'll deliver the deliverables. And yes, most of them work best in combination with others. Your challenge is to figure out the best mix for a given project.


Thanks for your imploration. Out with Strunk. In with Style!

This is an extremely comprehensive and very helpful post on user experience/deliverables.

The "Personas" thing is spot on.

PS: There are so much links within the article itself though that makes it a bit hard to read.

This is an excellent article that not only serves as a reminder for those of us in the field, but can be useful to others who are not in our field and would like to learn more about the value we can bring to the table.

Thanks for the article. I will be sharing it with my friends and colleagues.


In order to get my brain back into the groove of thinking about how to classify these things (thanks for the challenge, Peter), I went back to a CHI 2002 workshop I helped organize.

There are a few things there that jog my memory and should help me. Maybe others will find that "blast from the past" interesting, too.


Brian Salzman sent me his adaptation...

...of the fabulous Fulcher, Glass, Leacock diagram showing relationships between deliverables...

Both are worth a look!

As much as I love the visual presentation, it is great to see stories and proverbs included here. Since moving to a charity for blind people I've realised how visual traditional IA deliverables are.

Many of the other deliverables mentioned (in their usual form) are no use to me as a number of the project board and team are blind. Pretty much anything sketched or produced in Visio/Illustrator is out. I particularly miss concept maps. Of course, the techniques don't have to be executed visually but then the challenge is convey the information as elegantly.

"Everything looks different when we can hear it all at once," conveys quite a different outcome!

LOVED this post, and downloaded the treasure map!

I will never waste my time on barely-scrutible UX articles again.

Surprised to see there was no URL on the map! Whether or not you want to self-promote, I would appreciate more ways to re-find you and this post as I consider those lovely icons weeks or months from now.

Thanks Penina! We did discuss whether or not to include a URL on the map, and then (with disdain for clutter and a healthy helping of hubris) decided it would be findable enough via Google.

If we're wrong, it will disappear and become hidden treasure.

But, for now, it's doing fairly well :-)

This is great! I appreciate the different stages in which experience goes through a process.

Right now I'm doing the Experience Design track at Herron in Indianapolis, and it's great to see the terminologies and methods used on one page!

Great job!