You’ve likely seen the line that says ‘Only drug dealers and software developers call their customers users’. It’s funny but also carries an important message.
You see, drug dealers don’t care about their customers. All they care about is the money. Some software developers exhibit a similar characteristic in that all they care about is the technology.
Creating really good software requires more than good technology, minimal defects, and decent performance. The software has to behave in a manner consistent with the person running it; let’s call him or her the ‘client’. The only way to achieve such a result is to get inside the head of the client.
That’s where personas fit in.
Whether you’re doing waterfall or agile software development, User Stories and Use Cases are great tools for elaborating on client activities and behaviors. They allow us to describe client actions in ways that software developers can dissect and turn into executable code. But there’s a step missing!
We need to know a few things about our clients before we dive into their behaviors. Here’s a simple example. Let’s say I have the following user story:
As a user, I want to send Twitter messages so that I can participate in its global community.
Simple right? Now what if I told you that the ‘user’ has severe arthritis and cannot type or use a touchscreen? That changes everything.
Here’s an even simpler example:
As a user, I want to generate an inventory aging report and export it to Excel so that I can manage inventory levels and costs.
You might think that this report will be run monthly by a finance staff member. What if I told you that the user is a highly-impatient, senior executive who runs this report hourly and uses it to adjust product pricing dynamically?
Get the point? It’s critically important to know your clients.
There are many aspects to knowing a client. Here are a few ideas to ponder. Determine which are important to your situation and create personas around them.
- How much on-the-job experience does the client have? Or, how savvy is she as a consumer or buyer?
- What are the client’s job responsibilities? Or, where does he fit within his household?
- What does a typical day (or evening) look like for the client?
- What is the client’s attitude toward technology and computers?
- What tasks does the client perform that are the most critical or repetitive?
- What is the client’s personality like (e.g. mellow and even-tempered versus impatient and hot-headed)?
- Does the client sit still and complete a task in one place or is the client highly mobile, starting and pausing tasks often?
- Does the client have any physical limitations affecting mobility, sight, hearing, etc.?
- Is English the preferred language of the client?
- Does the client abide by the same rules and regulations as other clients (e.g. state and national laws vary widely)?
You get the idea. Develop a small number of client personas for your next project. Give them names so the software development team can relate to them. How many you will need depends upon the nature and complexity of your software.
When you write user stories or use cases, direct them at one of the personas you’ve defined. Then go one step further. Apply a different persona and ask the team, “How does this change the client behaviors?”.