User-Centric Features Agile Design and the Power of Personas

Sarah Lawfull, Caplin Systems, www.caplin.com

Why Bother?

If you are building killer apps time after time, your user base is growing, and time spent using your app is constantly increasing then this article is not for you. However, if within your company you have observed anything similar to the points in the list below, then this article could be good food for thought:

1. The CEO has the final say on what new features should be developed
2. Your application is bulging with features and led by the loudest voice focused on the passion of getting their idea developed
3. The product backlog is a long list of faceless features
4. Developers use their own perspective because there is no other reference
5. No real users feedback to shape and form the product
6. The term "User" means different things to different people

As an experienced development lead and project manager at Caplin Systems, the one problem I see in many organisations is that teams don't put processes in place to determine who their important users are, so that they can build a product catered specifically for them.

When I first stumbled upon the concept of Personas back in March 2009, I got fairly excited as I immediately saw they could be the answer.

With vision, research and a passion to be better than we were yesterday, I facilitated a couple of workshops within Caplin to push what I call "Persona Driven Development". 18 months on, not only am I still talking about Personas, but I am also using them to design and develop better software. They are now ingrained in one of the most visible projects for my company, which is called "Motifs". A Motif is Caplin's product implementation focussed on meeting the needs of a particular Persona.

In this article I'll share with you what I've learned, along with a bit of contextual background as well as the actual step by step process of Persona Driven Development.

What is a Persona?

Personas are archetypes representing a group of users who have common goals. They are not fictional, but absolutely based on real data: this is key.

One thing that is contentious with Personas is the Personal information that is added, like a face, name, gender, background and age. This is ONLY to make them a little more real and colourful and this data should be used with caution. It has to be there because they make a bigger impact during the whole development cycle.

In the first series of Persona workshops I led, we created our first Persona and called him "Jack". Jack is a bank's senior developer who uses, configures and extends our products. Jack is invited to all our meetings and has a strong say in what and how we develop our products.

Here are a few of the benefits we realised quite quickly when using Personas:

1. A clear path on what you should be investing in next to provide maximum value for your company
2. Improve internal communication with excellent educational material
3. Clear team focus
4. Making decisions based on your user's perspective and not what you think
5. Improved project planning
6. You do build user loyalty and long-term relationships

A Persona can also be created very quickly, in fact in just a few hours if you have the right people. We have created many Personas like this and continue to refine and validate them as new information surfaces.

Personas are also very useful to identify gaps in knowledge. Finding out very early on in your project that you hold no or little real data about your users is a risk that needs to be addressed.

There is a great talk by Jeff Patton on pragmatic Personas, whereby he also advocates the speed in which Personas can be created. [2].

It's obvious what I should be doing - why use Personas?

Obvious to whom? You?

Many times I have seen the most simply instructions being interpreted differently.

I was in a Thoughtworks seminar where they outlined their UX Agile Process. The chap at the front asked us to perform a simple instruction: "Please tear out a page in the notebook given and rip it in half". We had a number of differing results all of which followed the instruction and all of which were correct, but not as the instructor intended.

The penny really dropped! Most of the time we are too embarrassed to challenge the obvious, as we don't want to look stupid, but it is in doing this we make the breakthroughs. I have found Personas helpful in this situation where you can simply verify what is being asked in the context of a particular Persona:

1. Why and how would this help Francis (Persona #1)
2. Would it enable Francis to reach his goals?
3. How valuable is this to Francis?
4. If we didn't build this, would Francis achieve his goals?
5. Can we walkthrough how this would work for Francis?

A great metaphor for this is "a person wants a hole and not a drill" and we need to take that one step further... why do they need the hole in the first place? Exploring requirements through Personas certainly helps everyone to understand why and what we are proposing to build.

Why don't I just ask what my users want?

Persona Driven Development can also be referred to as User Centric Design. This type of approach can sometimes be interpreted as bypassing the client and talking to the users. Finding out what they want or even better getting a couple of keen users to sit with the team to help shape the product. Persona Driven development is not this and there is one quote that sums up why...

"If I'd asked my customers what they wanted, they'd have said a faster horse." Henry Ford

Although used frequently, I never tire of such a quote because it clearly enforces the need to probe further until you get to the real reason why they have asked for such a feature. I feel using Personas along with NJMs (Narrative Journey Maps - more on this further down) is a better starting point to initiate a conversation with your clients and users to explore their needs. At least this way you are observing what they are trying to achieve their end point and then having a conversation about how they meet their goal.

There is also an approach that sees users and developers sat together in a development team, determining what and how things should be built. I am sure lots of successful projects have been delivered in such a way. Even in this case, I would still advocate Persona Driven Development every time.

With this approach each Persona represents the goals of a large group of your user base. The keen users that join a development team represent themselves only and therefore following this approach you could be in danger of delivering something that suits just the two or three users that have been involved in the project.

A good example of this came to light when I was recently speaking to a senior architect working for a large global investment bank who had just implementing a system that was over featured and complicated for their end users. It turned out that the users they had working with them were super-admin types which represented less than 1% of the user base, thereby ignoring 1000s of users of the system that needed to achieve simpler goals.

In my experience this is generally the case because the users that volunteer for such an assignment are those that are immersed in the process and are seen as gaining the most from the changes.

This is where it's so important to understand the value being added and if this is not clear then drill, drill, drill - until it is. For further reading on this see a recent blog written by Demetrius Madrigal and Bryan McClain.[3].

"Drop the Feature Check List" Mark Zuckerberg 2010

Although I was looking for a particle improvement in using Personas (more user clarity), I wasn't ready for the subsequent benefits that this clarity brings. It was like when Robin Williams in Dead Poets Society insisting on each one of his pupils to stand on top of his desk and see things from another perspective.

When I introduced Personas I wanted to shout and actually sometimes do... "Everything we should be doing should add value to this Persona's life".

It is easy to say we deliver products with the user in mind, but when we explore that a little more and go a little deeper I have to wonder: do we really? Are our actions showing that we do, or do we end up with an over featured product because the product backlog is made up of requirements/wish list from several big paying clients and senior management? Or is the sales team chasing the biggest deal in the history of the company which could be won "if only the product did this"... sound familiar?

In Mark Zuckerberg's interview at the 2010 Web2.0 Summit [7], he talks about dropping the feature list and going out talking to his users. He says he was once the user, but now he's older things has changed so he goes out and chats and observes college kids and finds out what they are using, their thoughts, issues and pains.

Through this collaboration, Zuckerberg understood that people don't care about the carrier of communication (IM, email, sms) enforcing again the technical logical convergence around electronic communication. A powerful insight through observing your users in their own environment.

I am not sure if Facebook are using Personas, but what Zuckerberg basically states here is a Persona, and if the information was brought all together into such a form then that in itself would be a very powerful communication tool for the Facebook Team to decide on "what's next".

Product backlogs should be driven ONLY from strategy and Personas that support that strategy, otherwise it becomes this tactical, jumbled mess of a wish list made up of requests from clients, sales, product owners, developers, senior management, with little clarity on direction and vision. I am positive that we have all seen this for one or more companies we have worked for, where the vision gets trumped by the next client requirement.

Creating Personas... Hard Work?

Back in 2009 when I was first hunting around for someone who had successfully worked with Personas, there was very little on the web.

I found the first reference to Personas was made in "The Inmates are Running the Asylum" by Alan Cooper, 1985 with a whole chapter dedicated to Personas in his updated book "About Face 3". I also "read" "The Persona Lifecyle" by John Pruitt and Tamara Adlin but found this too large with information scattered throughout the book on creating a Persona (I think since then they have published an abridge version).

I wanted an easy, high-level bullet point list that I could follow without investing too much time in the exercise before knowing if it was going to make any difference - the failing fast approach. So in the end I used my brain and common sense. And for your ease I've compiled this step-by-step guide below.

Creating Personas - The Steps

Step One - Collate Information: 1-3 days

Pull together all the information you have on your users. It will amaze you on how much tacit knowledge your company holds on your users along with the information gained from being out in the field. You don't have to run arduous or laborious deep research for valuable information to surface. It will also expedite the process if you run workshops and help facilitate the data being generated.

I found that it helps when you ask the group to jot one point about the users on a post-it note with prompts around goals, motivations, Personality, skills, work habits, frustrations and behaviours and to start grouping this data under common goals.

At this stage, some people are concerned that the information we are collecting is wrong and therefore if decisions are made on the project based on this information then it's dangerous. You should remember that the Personas are a starting point and will evolve as you collate more data by user wireframe walkthroughs, context user studies and constant feedback from your iterative releases. I really don't think the alternative in our case of using "User" would be any more accurate and in my view would be worst. For me it's a reason to put anything you want in the product.

Step Two - Find the Patterns: 1 day

This is the fun bit and best achieved in a small group (2-3). Remember that you are not looking for data that supports your view. Keep your judgements and assumptions to yourself and let the data do the talking. You are looking for repeated data and data that communicates a common message. These should jump out at you with a little probing and discussion.

Step Three - Construct the Persona 1/2 day

The format of a Persona can vary and is really determined by three things: the data collated; type of project and your preferences. This format has worked for us so far at Caplin. We broke the Persona elements into five main sections:

1. Background - qualifications, skills, company, age
2. Behaviour - e.g. competitive, avoids risk, methodical, media hungry
3. Goal & Motivations - e.g. Improve client relationship
4. Frustrations - e.g. Multiple logins, disjointed research, high latency
5. Scene Setting - Paragraph bringing into context the four points above

Your will find more details in [1]. I also like the format of Jeff Patton's Personas, in particular for each Persona there is a bullet point list of the design implications for this Persona. [2]

The key reason why Personas work is that they represent a bunch of users that have the same goals. The whole project team's sole focus is then to make it as easy as possible for each Persona to achieve their goals. Not all literature on the subject of Personas makes this "goal" statement clear, which can be very confusing when you try and apply them to your project.

It is also important to think about the design of your Personas. If they are presented well and look professional then they will have more credibility, providing the information is correct of course.

Step Four - Add Some Context

During the first few months of creating our first Persona, we shouted about it lots at company meetings, during user story writing, planning sessions, Scrum sign-up, etc., but they had little impact.

We knew they were important and they gave the whole organisation an unambiguous view on who our most important Persona is but nothing was changing. Then, something happened. We were not getting support from our product by this particular Persona during our product sales process. So we thought it would be a good idea to "walk in the shoes" of this Persona and watch him try and achieve one particular goal.

It then became absolutely obvious this was extremely painful for him and he failed miserably at achieving this small goal. That was when we saw the power of Personas when they are put into context. We use Narrative Journey Maps (NJMs) and Context Maps to do this. [5]

Step Four Continued - The Impact of Mobile Computing

At this point we can no longer ignore the fact that mobile technology is involved in every part of our lives from waking up, the journey to work and connecting with people 24/7, which has significantly impacted on how we develop products. We have seen a phenomenal rise in smart mobile devices in the last two years and how they have become integrated into our everyday lives.

If we want to maximise the full potential of a product, we can no longer develop a software product in isolation to the way people live. Using Personas and NJMs forces us to think more about the people and their lives and focuses the team to provide a product that reduces/removes any pain or barriers that is stopping them achieving their goals.

I have found that placing a Persona in context as well as understanding how their day is constructed has helped us make better decisions on what and how we should develop software products. After mapping the Persona's journey/scenario to achieve a particular goal using a NJM, we have found that many ideas and concepts are generated and evolved further into User Stories that can be taken forwards into your development cycle.

It is important to point out that ideas and concepts are something that falls out of a collaborated environment and not something that is left to the Designer/UX Team. There is some great material out there on innovation and why involving people from many different disciplines achieves better results.

Who decides what you should do next?

Set the strategy and let your Personas determine what's important. Remove the conversations based around "What I think" or anyone playing the seniority card and start getting real data to determine what's next. Don't get me wrong: we need discussions, but we need to have them in relation to Personas and how we can deliver value to them.

Another concept to think about here is to "fail fast" - this is what we have been doing for years in Agile - building a product iteratively with feedback at regular periods. What is the Minimum Marketable Feature (MMFs) that can be delivered for a Persona? This will achieve early feedback from your users, validate your Personas, provide value early and a steer on what to do next. Something the UK Government really could do with and even more so with the cut backs.

A report [8] released by the government on the 1st March 2011 sets out the case for a new approach to IT in the public sector. It recommends tackling two important aspects simultaneously, Agile being one of those two: "agile - facilitating rapid response and innovation at the front line". Agile is definitely not a silver bullet to put things right, but if they act on the rapid response in terms of feedback it may help.

Extreme Persona Driven Development

I have no experience in taking Persona Driven Development a step further into the area of Acceptance Tests. Once the User Stories are produced along with the wireframes it kind of ends there with the occasional check from the UX team that the vision and interactive designs are being developed correctly.

Tim Anderson has taken this one step further: Personas are driving his Acceptance Tests making them more clear and meaningful. He's hoping to run a session about this at AGILE 2011 Conference early August at Salt Lake City. [9]

In Summary

Personas were a solution to a very specific problem we had. We began to understand our users, and in doing this we understood our user's goals. Most people start something with a goal in mind and it is common sense that if you understand what that goal is, and provide an easy way for those people to achieve it, you are going to deliver applications that will be used time after time.

Further Reading

1. Sarah Lawfull, What's in a Persona: http://blog.caplin.com/2010/08/11/whats-in-a-Persona/
2. Jeff Patton, Pragmatic Personas: http://www.infoq.com/presentations/pragmatic-Personas
3. UXmatters, The Dangers of Design by User: http://uxmatters.com/mt/archives/2011/03/the-dangers-of-design-by-user.php
4. Sarah Lawfull, Collaboration = Innovation: http://blog.caplin.com/2010/10/05/collaborative-culture-innovative-thinking/
5. Duncan Brown, NJMs: http://blog.caplin.com/2010/03/04/narrative-journey-maps/
6. Indi Young, Mental Models: http://rosenfeldmedia.com/books/mental-models/
7. Mark Zuckerberg Interview Web 2.0 Summit: http://techcrunch.com/2010/11/18/mark-zuckerberg/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+Techcrunch+(TechCrunch)
8. UK Government IT System Error Report: http://www.instituteforgovernment.org.uk/publications/23/system-error
9. Tim Anderson Personas Driving ATs: http://submit2011.agilealliance.org/node/9890

---

Related Agile and Requirements Articles

Agile, Multidisciplinary Teamwork

Popular Collaborative Software Specifications Models

Related Resources

Agile & Scrum Portal

Agile Tutorials Videos

Software Requirements Management Tools, News and Resources

Software Requirements Tools

---

Click here to view the complete list of archived articles

This article was originally published in the Spring 2011 issue of Methods & Tools