Tools in the Toolbox – Personas

“Tools in the Toolbox” is a series of posts on development and design tools I use on a daily basis.

I am a huge fan of Alan Cooper and personas…huge fan.  I have written at length about him and his techniques here, http://benjaminhysell.com/archive/2009/02/alan-cooper/.  My goal in this article is not to cover the basics; other blogs and books cover the basics of personas.  Rather, I hope to cover why I use personas, and why I have embraced them.

So, why do I love talking about personas and using them for quoting, specifications, and development work?

Fear.

::No wait, I’ve used ‘Fear’ already as a motivator for using Test Driven Development here: http://benjaminhysell.com/archive/2009/08/tools-in-the-toolbox-test-driven-development/.   I can’t just keep throwing around the same emotions…I had better come up with something different…::

Take two.

One reason.

I hate designing software for the person named “user”.

Think back to the last meeting you were in with your developers.

I have a great new idea for your blog website!  I think some of the users who use your website get lost in the technical jargon you use.  Let’s add a whole section that explains all of the technical terms that appear in your blog entries on the right hand side of each page.  That way when people come up against a new word they don’t know they can just glance to the right side and see a definition!

This actually isn’t a bad idea on the surface.  When my non-technical friends read my blog they may walk away with something more than just saying, “Wow, you write a lot of words!”

Then another developer chimes in…

Let’s build an iPhone app that links back to this blog!  Every time you publish a new article it’s automatically sent to the user’s iPhone, they get a notification that a new article is up and their phone will “ding” with a new article notification!

Again, not a bad idea…technically possible, would be kind of fun to implement, figure out the whole push notification framework.  Yes, that is a project I could lose myself in for a while, and in the end it would be sort of neat to have figured out all of that technology and to get something working.

Here is the rub, although each idea is fun, interesting, and very technically possible, neither one does anything for the core function of my blog.  Neither idea helps me write about managing people, software, and projects.  Nor is either idea squarely aimed at my core audience, other developers, project leads, and managers.

By using personas I can quickly and easily figure out if either idea is worth while exploring and implementing.

How you may ask?  Simple, I can quickly take every idea I have for my blog and ask myself,

If I had an iPhone app that notified John that I had published a new article would he use it?  Would it be worth the effort to publish such an app, and would John tell his friends about it?  Would John pay for an app like this?

Who is this John?  Good question…

Before going any further let me introduce you to John.

Name

Age

Personality

Skills

Goals

Attitudes

John seems like a pretty good guy.  The sad part is he doesn’t exist except for me to test my blog topics, design decisions, and possible iPhone apps against to see if he would like them.

John is my sounding board.  John replaces all instances where I might go, “Would the user like this?”  Now all I ask is “Would John find this useful?  If I spend time on this would John tell his friends to check this out?”

Designing my blog towards a someone, a real defined someone, helps me figure out what I should do and keeps me focused on my core audience.  Remember that iPhone app?  John wouldn’t need it, John would be using RSS to keep up to date with my blog.

What about the jargon pane on the right hand side of the site?  John probably knows the jargon already, and if he doesn’t, i.e. its something new to him, he is going to be motivated enough to go look it up himself using Google.

I love writing for my wife,

::Thanks for proofing this for me!::

but if she comes across a term she doesn’t know she will likely use the surrounding paragraphs to figure it out or skip it all together.  I don’t care if she doesn’t get the whole article because she isn’t my core audience.

John just saved me hours of time implementing ideas for a “user” who isn’t going to read my blog.

For every project I sit down and define who my end users are for that project before I start.  Each one gets a name, age, personality, skills, goals, and attitudes creating a vivid image of the person I hope will be using my software.  Every decision I make, be it user interface or back end operation I ask,

Will John like this new feature?  Can he even use this new feature given his skills?  With his attitudes would he want to use this new feature?

I instantly know which features I should implement and which ones should go back to the drawing board.  Personas have become my strongest tool for designing software that people actually want to use.

Next time you get in an argument about an implementation detail or presentation issue ask out loud, “will our main user Steve actually like what I am creating for him?”

When a developer asks to implement this crazy new login procedure ask them, “Will Sally, our 75 year old grandmother who is our main user be able to figure this out?”

Bring real people into your development and you won’t be disappointed with what they tell you about your software or new idea.