
I’m going to go a bit off topic here, but still very much design related…
One of my favorite articles of this past year was the wonderful (manifesto?) “The only thing that matters” by Josh Clark. I found it via the UX Design Weekly newsletter from Kenny Chen.
The basic idea he argued for was that highly polished design artifacts — wireframes, user journeys, etc, — aren’t as valuable as they may seem. The only thing that matters is the deliverable itself, the product. Those things still matter, he says, however, the place to spend your time is on the product itself, not creating a bunch of pretty design artifacts.
I found myself nodding my head in agreement continuously as I was reading the article. I think he is spot on in so many ways.
There is much to love about the sentiment here. The artifacts are a means, not an end. We get paid for the product! We get paid for shipping something! SO true! The goal is to make the right thing, not produce a bunch of stuff that no one will ever look at again…
As much as I agree with Josh and nearly everything he outlined, I still think there are a number of reasons why some highly polished design deliverables still matter. This isn’t a rebuttal to what he outlined, it’s more to advocate for an “AND“… to say that there are indeed some reasons for producing some of those design highly polished deliverables…
1.) Synthesis

I still recall the very first Experience Map that I created, I’m not sure that any one of my stakeholders spent more than a few moments looking at it, however, creating it helped me synthesize my understanding of the problem domain. One could argue that you don’t need a highly polished artifact for this, and that’s true, however, the “picture” enabled me to quickly zoom into an area that I wanted to focus on. If I was trying to understand part of the “plan” part of the experience, I knew exactly where to focus my attention.
As I was writing this, the thing that kept running through my head was:
Creative design seems more to be a matter of developing and refining together both the formulation of a problem and ideas for a solution, with constant iteration of analysis, synthesis and evaluation processes between the two notional design ‘spaces’ – problem space and solution space. In creative design, the designer is seeking to generate a matching problem-solution pair, through a ‘co-evolution’ of the problem and the solution.
Or, to simplify that, how does one ensure that they’re “making the right thing”?
The following picture illustrates what I consider to be a very basic design process.

What I want to call out here is the Discovery, Synthesis, Problem Framing Loop. The reason that I call that out so explicitly is that I think we often get pushed into design too quickly, and I’m a big fan of making sure we’re solving the right problem. There is a line I heard once that I really love: we teach people how to solve problems, but not how to find the right problem to be solved. I love that. Synthesis, for me, is where that work begins.
2.) Thoroughness
Taking the time to create these helps ensure that I don’t miss anything. If I’m creating a Persona, as an example, the template causes me to spend time considering each of the sections, and ensures I don’t miss anything. Yeah, I get that this doesn’t mean that the output has to be polished, however, why not spend the extra few minutes. I’m sure I’m not the only one that has a template for persona’s and the delta between creating one in a spreadsheet and creating one that looks nice is about 15 minutes… well worth the time if you ask me… which leads me to the next one…
3.) Evidence
We did the work, we explored the problem space and here is the proof. Chances are that there are some people on the team whose contribution would be invisible without these “highly polished artifacts”, and if you’re selling services to a client or trying to convince your boss you need to hire another design researcher, why would anyone believe that they are necessary? I get I’m being a bit hyperbolic here, and at the end of the day the thing that matters is the working software (or whatever it is), however, unless the organization you’re working for has a high degree of design maturity, I think some of these highly polished artifacts are extremely valuable as evidence of the work that was done.
Dan Brown has written some of the best stuff out there on design deliverables… including a really great book, Communicating Design.
4.) Validation
They say that a picture is worth a thousand words, and along those lines, showing someone a nice journey map or providing a quick, interactive prototype, instead of making them read through a spreadsheet or word doc is a better experience and helps validate direction. There is an old saying that I really love here:
- Tell me, and I may hear you.
- Show me, and I may see it.
- Involve me, and I’ll completely understand.
Giving someone a prototype and letting them click through can yield some great insights. I’m sure we can all recall some design idea we’ve fallen in love with that didn’t quite hit the mark once people saw it. For me, I want to learn about these types of things as cheaply as possible.
I’m really a huge fan of what Josh proposes, in terms of writing code early and by favoring working software over prototypes, we really cut down on the back & forth between design and engineering when we throw designs over the wall (if we’re still doing that).
Interestingly, I recently read ‘Creative Selection: Inside Apple’s Design Process’ and one of the main ideas of the book was that the most important thing you can do is demo your stuff, let people see it and try it — early & often! There is no substitute for feedback!.
5.) Portfolio
As funny as this may sound, I think these design deliverables are an important part of a design portfolio. It’s great to see the finished product, but showing the process someone went through to come up with the idea and the deliverables that were generated are, to me, just as interesting… they are a way to get an understanding of how someone thinks, how they approach a problem.
Again, I really love and agree with the ideas Josh proposed, and think we need to move much closer to just-in-time, collaborative design process! I recently did this on a project, where we brought in a UI Engineer to start building the design as they were emerging, and it worked out beautifly! Instead of handing off wireframes, we handed off working front-end code, and our usability testing was much more effective because we could code in some conditional logic…
What do you think? Have you changed your design process to be more collaborative? I’d love to hear your thoughts!