When developing a new system – software, business-process, whatever – it’s still all too common to refer to the people who will interact with that system as ‘the users’. Abstract. Faceless. A machine talking to a machine.
But our users aren’t like that at all. They’re real people, with real stories, like Alice Lewis above. Her smiling face may not show it now, leaning on a treasured table, but she’s known real hardship, an early childhood living rough, catching rabbits to stay alive. How will someone like her use your system? Don’t be fooled by her appearance: she might seem soft on the surface, but she’s as tough as teak underneath. And life is hard enough already, thank you; she doesn’t have the time or energy to tolerate the flaws and foibles and failings of a badly-designed system.
So when you design your system, or derive the requirements for its development, don’t think in terms of an abstract ‘user’: think about someone real, like Alice. Use her real story as the basis for a persona that you can use to test the functions and limits of your system
And to do that, start from the usual story-cues that we’ve seen before on this blog:
- the people – Alice, and the people she interacts with in your system
- the time – time of day, time of year, time and timing in general
- the place – where these events will happen
- the sequence of events – her touchpoints and interactions with your system
- her ‘why’ in each interaction – her aims, her intent, her criteria for satisfaction
To make this work well, we’ll typically split this ‘persona-story’ into three parts, or three layers:
- the persona-story itself: a brief ‘life-picture’ of Alice and each of our other personas – what they look like, who they are, what they can and can’t do, and so on
- the interaction-story: a summary of each overall interaction with our system, each ‘customer-journey’ to resolve a specific overall need – typically structured as an ‘epic’ in the form of “as a <type of user>, I want <some goal> so that <some reason>“
- the small user-stories: the point-by-point detail-layer interactions at each touchpoint with the system – what exactly this persona must or must not do in order to achieve their aim
Record each of these story-items in Zahmoo, with links between each of the story-items, and to the respective requirements and tests. As you go through the system-development processes, use comments in Zahmoo to keep track of ideas and implementations, and changes to the stories themselves.
So what’s the story here? How well can your system serve the needs of someone like Alice, with arthritic fingers, fading eyesight, fragile memory and a decidedly testy temperament? Because if it doesn’t work well, from her perspective, she’ll let you know exactly what she feels about it, in “language that could blister wallpaper”!