UX Project Documentation: Answering Why, What and How
Recommended by elsterama on December 14, 2010 via UX Booth
Many people don’t see the importance of gathering the necessary explanatory documents that define what you did all throughout your project development. Either that, or they treat the documentation process as a simple putting-together of all the sketches and wireframes generated. We should, nonetheless, give more relevance to this final, whole-project document.
For the record, it doesn’t mean a 500 page document or something of the sort. It means something more on the lines of a compilation of the strictly necessary documentation generated by your design process, in an orderly fashion.
Why does it matter so much?
There are a number of reasons that can be mentioned to answer this particular question:
Future projects reference
Be it as good or bad example (what we did right or what we should not repeat), you have a permanent record of what happened during the detailed development of your past projects to go back to. It’ll help you constantly improve your working process and, gradually, your results.
Organizing ideas throughout the development
It’s easier to maintain order with the necessary documents at your disposition to answer questions throughout the process about previous stages, what has been done and how much has been done of it.
Introducing new members to your team
It’s easier to help a new member of your team in the understanding of your working process when you have previous documents, because then he has something to look at and you won’t have to keep reminding him of essential points afterwards. Of course, this won’t eliminate your need for a formal introduction, but later on it will make the need for further questions a lot lesser.
Selling new projects
If you want to sell new projects to future customers, your presentations can include some portraying of your design process. If your client is requesting to know how you’ll be working and which deliverables he can expect to see (also so he can understand why you take certain decisions), your previous documentation can become a very good tool in this regard.
Improving your working process
Looking back at what was previously done, do you think you’re missing a step? Are you being too unclear and messy at some point? Are there misscomunications among your team members from one stage of the process to the other? A document can help you answer all of these.
What, then, should this document include?
It actually depends on the type of project you’re working on and the steps that project includes. Considering, thought, the hipothetical scenario that you’ll be working on a project that starts from scratch (meaning to say that you already have a product/service idea, we won’t get into marketing details) and finishes with the complete development of the website, the document should ideally include the following:
Project introduction
Basically, just answering the following questions gets you all the way across:
- Who’s the main client?
- Which is the main objective?
- What’s the client’s vision of the project?
Written briefly and to-the-point, to have as the background of the whole project.
Identified users and user research
This means getting down to creating personas. And of course, the document will consist of all the created profiles after identifying the users and their needs. Having clear and complete persona profiles will support later stages in the design process.
Website content requirements
After deciding on the personas, what should the website have to offer them? Keeping in mind that we have now both, the users’ and the client’s needs documented, we can list requirements as a checklist to be later on verified and revised. There are many ways we can do this in an organized way to suit our needs at the moment.
Concepts to apply
How will these requirements be met? A great idea for this part of the process is given by the independent consultant and speaker Stephen Anderson, with his introduction of user behaviour concepts through cards that can be selected accordingly. This stage basically answers the question ‘What will we do to meet the previously established requirements?’, considering the issue in terms of user reactions and the concepts to apply in order to generate these reactions.
Information Architecture
A formal or informal diagram of the information architecture map is a must, as it’ll be an important guide throughout the later stages of the design process. A proposed method for doing it is explained by Jesse James Garrett, including the elements used to create the diagram and their relationship connections.
Interactions
This stage in the documentation process includes basic diagrams of the main interactions that will be applied in your website. Such interactions might include basic error notification, success notification, link behaviour, drag and drop interaction behaviour, among others. Make sure to have your feedback clear on each interaction diagram.
Navigation
A very interesting proposal by Hagan Rivers can help you get easily through this specific part of the design process. She brings the following idea with her:
Example of how to handle Navigation diagrams as stated by Hagan Rivers.
The navigation can be considered an application on itself. Its objective is to take you to the right screen.
Based on this premise, you can use her approach of working with application diagrams to map your whole navigation system. If you are, of course, more comfortable with site maps, you can work on something like that.
Concept designs and prototypes
It is important not just to include the final, clean wireframe, but also some of the sketchy beginning ones, the ones in lower qualities with representative elements and some of the rejected ideas to illustrate your process.
Usability testing on prototypes
Example of a heatmap generated through usability testing.
Trying to keep it as lean as possible, usability documentation can include the final results and statistics. You may include the scripts you created as guides for you and your team if you tested it through focus groups or personal interviews, too. But you may have tested using a device such as eye-tracking or mouse-tracking, in which case you could just include the resulting generated maps, like the example shown on the picture of a heatmap.
Development plan and technical specifications
With the previous documentation and research, development decisions can be made. These decisions involve the technologies that will be used to create the application that has been designed, justified by the requirements that need to be met.
Style guidelines and patterns
The final specifications about colors, indentations, images, among others. These have to be well established and justified, too, in order to serve as a guide throughout the development process to maintain the visual design standards.
To sum up
Even though you don’t need to generate a bible out of every project you work on, the right amount of documentation can help you keep some order in the messy chaos that creative work generates.