That "Ah-ha" Moment!

Here's a simplified *before* personas and *after* personas scenario. Download the pdf.

Background:

You and your team are responsible for developing the next generation of WhizApp’s Office Management software, an established brand for office management and accounting software.  WhizApp OM is used in accounting, finance, communications, inventory, payroll and other functions. 

WhizApp OM has millions of users in diverse business environments.  WhizApp would like to be bigger than SAP, but hasn’t managed to be that successful yet. WhizApp markets themselves as offering 90% of the functionality of SAP at 20% of the cost.  In reality, they offer and plan to continue offering less functionality than that. Their goal is for the users to forgive the missing features as inessential while attributing their absence to 10% that makes the software more cost effective.

Obviously, this is a big challenge. How does one determine the “less important” functionality?  Existing users regularly request new features and ask for changes to existing features. Your current interface is old, yet you secretly fear some of your users’ ability to handle significant changes to the application.  To grab more of SAP’s market, you need to add functionality, some of it to delicate parts of the existing product. Furthermore, you have requirements to add new components – such as tracking and logging – to satisfy internal business demands, though these functions have not been requested by any user. 

Problem Summary:

Your task is to develop and deliver a major overhaul and update of the WhizApp OM system in order to keep your company vital and to deliver new, highly competitive features, as yet undefined.

How do you decide what functionality to provide and with what priority?  What features are out of scope? What is the presumed user’s skill level?  Maybe there are features you can remove?

In a nutshell: What will make your users want and be satisfied by the system?

Who Are the Users?

WhizApp OM has millions of users.  You’ve met a handful at customer visits, user conferences and their visits to your office.  They seem incredibly different, and seem to have very different demands for our system. 

Here are a few of the users you’ve recently met:

1) Amy Prott coordinates and oversees payroll, employee orientation and benefits at a large law firm. Her demands on the system can be intense and she has to know she can trust WhizApp OM to work properly.  She says she wishes WhizApp were more like SAP.

 

2) Carmen Bembaron’s work environment isn’t enviable. He handles finance data entry and some analysis.  He relies on a rather old computer for all aspects of his work. He doesn’t create or refer to paper much or work with other people.  Carmen does his job each day. He doesn’t care much about what comes of the data.

3) Sandra Nygun and James Randell work for a large office development firm in New York.  They work in the finance department and often collaborate to prepare reports for their Director. Sandra and James know they are competing with each other for the next promotion.

4) Archie Blair works for an 80-person high tech software company with offices in various parts of the US, plus sales offices in the UK, Germany and Japan. Archie works in a remote office, performing multiple roles for his company.  When he’s in his office, he mans the help-desk, writes white papers, supports sales calls and manages the accounting for his office.  On the road, he does sales supports.  Archie is upwardly mobile and is careful to make a good impression with customers yet willing to create havoc in the office.

The Conundrum:

What features do they need? Where’s the commonality?  How do we understand for whom to build what functionality?  How do we avoid building features for one user with the skills of the other?  How do we prioritize our list of features?

Has thinking about the users improved our clarity? Have they helped us define the system?

The Solution:

Take a step back and assess the problem for the standpoint of WhizApps’ goals, core strengths, the needs of its diverse user base…. Look to create a realistic archetypal user – a persona – who would lead your company to build a product that will appropriately satisfy that diverse user base.

For the WhizApp OM product, “Pauline” is that persona.

"Pauline" works for a retail franchisee.  Her bosses – a married couple who she considers friends - own several of the franchises in the state.  "Pauline" handles accounting and payroll, and ensures the businesses meets all legal and franchise requirement. Her office is modern but basic. "Pauline" is a capable computer user, but not a techie. She trained as a legal secretary, and took her job based on her friendship a friend of the owners.

"Pauline" considers her work-life to be a continuation of her social network and friendships.

"Pauline’s" goals are:

• To earn a living.
• To keep the office running smoothly.
• To help the company thrive while ensuring it survives.
• To be viewed by her bosses and the other employees as a friend and equal.

When building software for "Pauline":

• Realize that her work is:
  • Independent,
  • Non-collaborative
  • Reviewed
  • Depended upon
  • Cost conscious
• Focus on general business features, for both small and larger companies to meet, as her bosses and the company has the requirements of both.
• Build her interface to focus on data collection and analysis. While she doesn’t use reports to do her job, she creates very polished reports for her boss to provide to the franchiser.
• Plan the software for current, not cutting edge, technologies.  "Pauline" can upgrade if necessary.

Persona Benefits:

Now that you know “Pauline” represents your primary persona, you can probably see how she meeting her needs will also meet the needs of the other users in her without the distractions and confusions caused by their differences. Pauline’s environment causes her to have the demands of a big corporate environment (the franchise) and the demands of a Ma & Pa shop (the franchisees).  Her work is diverse, having collaborative components (working with her bosses/friends) as well as significant data entry and data analysis needs.  Franchisees typically watch costs carefully; yet understand that significant capital expenditures are a part of being competitive. 

The only need "Pauline" doesn’t address well is a possible need to have access to the system while traveling.  If such as need does exist – that would require further study on Archie Blair and similar users, those needs and skills could be met with a secondary persona.

This is an example case.  In the real world scenario, a company would surely require at least one secondary persona and perhaps a negative persona to help marketing, product management and development know what to build and how. The great benefit of personas is that - rather than trying to corral the demands of the millions of users – they are a simple tool that guide your team to build products that meets your users’ needs and skills, and your company’s goals.

Ah-ha!

Comments

[Steve Johnson]

Many people who are new to personas create too many. They can't see that the behavior of this persona is the same as that one. You've done a fine job of distilling the needs of the many into the persona.