Personas as a means for mapping user experience for information delivery
What is personas all about?
You can begin by compiling everything you know about your customers and grouping your findings in a spreadsheet. You could use headings relevant to your areas of study, such as industry, device, time, and goals. Or you could create affinity diagrams by organising your findings on post-it notes. You might start to see patterns—the industries in which customers work, and what devices they use, at what time of day, and where. From here, you can form questions about your customers and work out what they have in common and also how they differ. From:http://uxmastery.com/create-ux-personas/
There is already a lot written about personas; Let’s not get scared yet. As far as we are concerned we just need to keep it simple. Above all, we’re not going to want to have to deal with a multitude of personas with different needs.
Most of the trend in writing about personas is either marketing oriented or aimed at understanding what users will experience as they become onboarded into products. What we’re interested in goes beyond that. Personas change as they evolve through the life-cycle and their experience changes. Our job is identifying when to deliver and for which type of persona.
How can we deal with what a persona is and define them?
In our case, producing content around software, user personas can be considered being beginner, literate, proficient or expert. If we deal with these cases we will cover a broad range of sufficiently different fields of experience. In simple products, this is more or less a linear evolution from one to the next. In complex products, a user can be an expert in a field and a beginner in another.
Unless we are proficient users ourselves and involved with the entire user base, it is hard for anyone writing for users to define this matrix alone, and even then there is the risk of getting it wrong.
So, how do we determine personas? Who knows the users? A product doesn’t generally appear out the blue. Specifications are, in theory, based on user requirements. In agile methods, the method is to write stories based on a user role in a lot of cases. So, in theory, software companies know their users. Well, that subject is one for another article, so in this case, let’s presume the specs are right and the users and the use cases are roughly known.
If the product isn’t new, support knows the users, and so do Product Owners and Product Managers. So they can help clarify the definitions at this level. If the product is new, then personas are hypotheses, even if they are based on previous knowledge.
The major risk comes from not having all stakeholders involved in this process. It’s better to have them participate a minima rather than have only those involved in content production deal with this subject. This is why our position on this subject is to include at least minimalist definitions into a content strategy.
Persona definition can be part of a bigger content strategy management process. Why is it bigger? Well, it goes a bit beyond the software to encompass support and training. In future information systems around software, it merges these.
So what is persona experience?
So users can be divided into persona. What each persona will experience can be seen as a journey. Persona experience is that journey. So, to cater for it properly in our information delivery, we have to map out the big picture of the journey, the major steps and define what needs we can cater for.The idea is to have an ambition that is just good enough. At least in this way, realistic objectives will be set.
Where does this lead us?
Ideally, we could think of building a persona matrix. But let’s keep it simple once again.
Everett Sizemore, at inflow, has a good article on this in Persona Topic Matrix Template for Content Gap Analysis, but in our case, we can even try to keep it a bit simpler to start out and try to map it to content we can provide.
Persona & content matrix
It’s all about mapping a simple analysis of the type of content we can deliver.
|Beginners||Literate users||Proficient users||Expert users|
This is an example and not a method. It is aimed at helping us see how we can keep it simple.
This matrix is part of a content strategy based on knowledge of the user audience. The guarantor is not the writer but the product manager / owner.
Note that the same matrix can apply to how stories are written in the software development in agile methods. If they are not written in the same way, then time will be lost and stories will never be content candidates.