Problems with personas in iterative development
When designing software, Allan Cooper suggests designing the entire user interface before development starts with basis in comprehensive field work. The comprehensive field work results in data about the target users in the market segment(s) that the software is intended for. This data is turned into persona decscriptions and scenarios, so that it is possible for the interface designers to engage in the minds of the target users. It is the personas and scenarios that are the most important tool of the Cooper way of designing software.
Cooper provides good tools for collecting multiple viewpoints about an interface. It is often expensive to use real users througout the sometimes lengthy design phase to provide feedback, which is why written persona descriptions come in handy. Furthermore the designeres can engage in the persona descriptions to discover things that the real-life-users can’t explain themselves. They have access to tacit knowledge that the real-life-users can’t make explicit themselves. These are just some of the positive aspects that personas provide.
A less positive aspect of the way Cooper designs software interfaces are conducting the whole design phase before development starts. New aspects of the problem domain emerges after coding starts. This requires new decision making, that will only cause harm if postponed to the end of the coding phase. No matter how much time and effort is used in the preliminary analysis and design phase, new aspects will always emerge. In some projects more than others (explorative vs. routine projects). Some problem domains require change. This is old news. In such problem domains that require change, more agile development approaches are preferred.
Can personas give frequent feedback on changing requirements? Aren’t the persona descriptions just an extract from the requirements of a given point in time? So if the persona descriptions were created in the beginning of the project, they represent the requirements of the beginning of the project?
If this is true, then in a problem domain with changing requirements, the persona descriptions needs to be constantly updated to represent the requirements from a recent point in time. Constantly updating the persona descriptions can be an expensive cost just as using real-life-users is an expensive cost.
Some tricks to help this are:
- Create general persona descriptions that are not requirement specific, but a general description of the character that the developers and designers can engage in. If the designers and developers can engage in the persona descriptions, then act of engaging in the descriptions represent the updated requirements.
- Let the scenarios be feature specific instead of the personas.
- The personas themselves should only serve the purpose of letting the designers and developers engage in the mind of the archetype of user the persona represents.
The most frequent critique of persona descriptions is that they are not inspiring. The developers can’t take them for something serious. On top of that, engaging in the personas take time – a scarce resource.
Any suggestions in solving this problem? How can we truly engage in the personas – and without too much effort and time?