By Dexter Duncan
Ever feel like you are failing to reach your target market?    Are your products too complicated for users with a slew of under utilised features?  Dread making a million dollar mistake by rolling out a white elepant?  Whether you are marketing or developing software, the cure for (avoiding) the above ailments is most likely simple.   Marketing solutions to a specific vertical (like health or retail) or focused portals to consumers usually involves setting up sample user profiles in the form of a ‘persona’.
elephant cloudMost marketing folk know the importance of consistency.   Whether it is consistent messages and branding across all materials or consistently approaching the market through channel marketing programs, “consistency” is a key ingredient for marketing.   Marketing is also very familiar with creating persona’s (or a composite of users) to represent key users and / or buyers from their target market.    These personas are used to define the approach to the market and to craft key messages.
As one of the most common failures of software projects is getting folks to use the new portal or back office, defining and adding personas early is critical before the developers jump into coding the solution.     The interface for both back-end users and field staff needs to have a design which is simple and has all the most commonly needed functions.      In short, the software interface should not make the user feel stupid.
Combining early interface design using personas with early user prototypes are key first steps before the coding of the back-end starts.    The software architect is likely to make adjustments to the software architecture depending on which functions are used and the order in which tasks are completed.    This process might remove some “edge cases” that are sometimes needed, but will increase the word of mouth marketing by making the users happy to use the system.
What is a persona?
The persona should be created in detail before you start one line of code and used consistently from interactive design phase through to marketing.  This gives the power of having a common reference point for both the software team and your marketing department.        So what is a persona?
A persona is a composite of users, representing backgrounds, goals, common tasks and abilities.
 (See info in Wikipedia for a more detailed definition of persona. http://en.wikipedia.org/wiki/Persona_(user_experience))
The most important outcome is to ensure the end-design meets the persons’ goals.
Here is a short sample*:

Physician Writing in Medical ChartRhonda Wilson, Nurse Unit Coordinator
Rhonda is a 36-year-old registered nurse who has worked at several skilled nursing facilities. She started out in acute care but moved to long-term care so she could have more autonomy.
Rhonda was promoted to Unit Coordinator four years ago because she is very competent and generally well organised. 
Rhonda is entirely overwhelmed and is drowning in paper, even more so than the average nurse. She often misses eating dinner with her boyfriend because she has 
to work late, filling out forms and reports.

Rhonda’s goals are to:

  • Spend time on patient care and staff supervision, not paperwork. 
  • Be proactive. Rhonda needs to understand trends in order to solve problems before they happen, instead of just reacting to crises. 
  • Know that things are being done right. Rhonda supervises the unit because she’s good at what she does. If nurses aren’t following procedure or documenting things, she wants to know right away.
Personas can be short and simple like this one or can be a few pages of detail.   The rules of thumb in using personas:
1) No more than one primary persona per screen.     Other profiles are okay if needed as part of the overall service/delivery,  but only one primary persona is used for design purposes.
2) Use only as much detail as needed.  The detail is useful to see the composite as a “real person”, but should not be so detailed that no one uses it.
3) Visual design not as important as usability.   Therefore minimse interface tasks to achieve goals based on what is most commonly needed.  Peripheral functions should be in tool bar or on other pages and get less design time. A pilot with fake data can help get feedback on design ideas by watching if user “gets it”.
So if you want to lower the risk of having a white elephant at the end of a large project, be sure you use personas for both your marketing and solutions design.    For more information, contact us at:
1) Credit for using personas should be give to Alan Cooper who first published the concept in The Inmates are Running the Asylum and in detail in About Face, The Essentials of Interaction Design.    

2) The sample persona comes from:

Calde, S., Goodwin, K., & Reimann, R. (2002). SHS Orcas: The first integrated information system for long-term healthcare facility management. Conference on Human Factors and Computing Systems, Case studies of the CHI2002/AIGA Experience Design Forum. New York, NY: ACM Press.

3) See this article and toolkit to ensure you are building the right persona.  http://boxesandarrows.com/making-personas-more-powerful-details-to-drive-strategic-and-tactical-design/

One thought on “Avoiding the White Elephant in Software projects

  1. Pingback: Top Three Issues for NDIS/Health Sector | Cloud Nerve Network

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s