Targeting Documentation Using Personas

Personas are imaginary users that fulfils a specific role in the use of a software product, and they are used by usability and user experience designers to infer what a real person might need.  For example, for a Financial application there may be personas for Accounts Payable clerks, Accounts Receivable clerks, Financial Controllers, Finance Directors, and so on.  The personas will include key information about levels of knowledge (of both the product and the domain) and common tasks that are undertaken by the persona at regular intervals (e.g. entering invoices, scheduling batch payments, producing reports, etc) to allow the designers to produce designs which are more user-centric, rather than being driven by the designer's own understanding of the requirements which might be inaccurate or incomplete.

As a secondary benefit, these personas can be used during grooming and planning to help the scrum team understand why the requirements are what they are, e.g. it's important that certain fields are grouped together because the persona that most often uses this form will always have to fill those fields in and grouping the fields together will make them more efficient.  Using personas to help the scrum members stand in the shoes of a real (statistically-averaged) user means that the scrum members are more likely to immediately "see" why certain design aspects will make things easier for the users, and thus they are more likely to produce an increment that meets those needs.

This brings us to the role of personas in targeting documentation.  Writers are no more immune from the fallacy of "me-centred design" than designers or developers are: making decisions based on what we would want or we think our users would want.  Documentation is often created and maintained by a smaller team, proportionally, than the team that creates and maintains the product; it is (unfortunately) not unusual for there to be software designers and UX/usability specialists working on the artifacts for a sprint, but for there to be no corresponding documentation designers or UX specialists.  Writers themselves are often expected to fulfil these roles, either singularly or as a team.  Just think about that for a moment.  On a large piece of software the help file is likely to be amongst the most accessed pieces of the functionality, and yet a lot of companies do the equivalent of expecting the developers to make all of the software design decisions.  That's both worrying and depressing!

If this situation is familiar to you and you are not a documentation UX specialist, the personas that are used by the software UX/usability experts in your company can help you avoid making the basic mistakes that prevent your readers from easily accessing the information they need from your documentation. If you don't have access to UX/usability personas, or you want to learn more about creating and using them specifically for documentation, I recommend Communicating the User Experience: A Practical Guide for Creating Useful UX Documentation by Richard Caddick.  As well as personas this book covers other useful tools and practises for designing user-centric documentation and will help you when you are maximising documentation ROI.