I have a problem in that I find it hard to do any kind of work in which I see no point in doing, and this happens a lot with UX documents. Even when I get rewarded for doing it, it’s hard for me to work on something without understanding the purpose and goal of that task in greater context.
Love/Hate Relationship with Documents
While it’s a good thing in design to think holistically and contextually about a solution, it takes up a lot of time and effort – this gets even harder without the appropriate resources to do all the work (researching, ideating, designing, testing, communicating). Spending time “figuring out” a document isn’t really a UX thing, but happens because sometimes I get to the point where I’ve worked my ideas around a design and I need to produce something for it.
So now a large part of my work now involves producing documents. In my previous life as a developer, I did very little of that – mainly because software tends to exemplify the essence of the product/goal, so I didn’t have to explain myself much – the software did all the talking for me. But now, I work in the realm of ideas – and software doesn’t always do a good job of communicating ideas.
UX Documents are Strategy: Influence Decision-Making
I’m quite happy to work with any document, but at some point in time those documents will end up being outdated because they would have served a specific purpose, audience, and time. So, I don’t want to waste a time if I can avoid it. Also, in terms of the kind of business we’re in, the document itself isn’t really the goal – it’s about strategy – a means to make decisions about the final product or service.
But what does that really mean? How do you write a document that helps someone make a decision about a product/service instead of just some mumbo-jumbo wishy-washy fancy-pants thing?
What Can a UX Document Describe?
Well, the more I started thinking about it, I realized I needed to illustrate the obvious and came up with this diagram about what can (not necessary should) go into a UX document. I think the core elements of any UX document can involve:
- users (or the empathy for)
- the product
- engineering or systems (the functioning of a product/service)
- the business
- history
- the future (ideal, goal)
- building and testing (execution)
The aim of any UX document is to influence the reader to have a mental model of this “overall picture”, so they can make decisions appropriately. Sometimes, they don’t need to see the whole picture, sometimes they do.
The reason we end up producing so many documents because no one document can successfully illustrate the “overall picture”. The problem I face, of course, is which document I should be working on and most importantly, why. So, I mapped Peter Morville’s list of UX deliverables to the diagram above, highlighted each document’s focus based on the seven elements I mentioned above, and ended up with this:
The matrix illustrates a document’s focus, not scope. The reason why I think it’s important to point this out is because of our tendency to start with a template (pre-scoped) and mindlessly “fill in the blanks” and ending up with goo. Understanding a document’s focus allows us to be flexible about what and what not to include in a document, as long as the document effectively communicates what it needs to. In fact, it allows us to be flexible about who the intended reader is – and often times we’re producing the documents for ourselves.
This then frees us to be rigorous about our approach to documentation because:
- we can see how the documentation illustrates the big picture
- focusing, not scoping, helps us avoid writing documents that don’t mean anything
This applies to any kind of fidelity – it doesn’t matter if you’re producing a sketch or a printed poster. The goal of documentation doesn’t change – communicate the big picture appropriately and avoid writing crap.
1 Comment