Why use personas in software and web development?

Why Personas?

user experienceIn user experience (UX) and interactive design (IxD), personas give a baseline to determine how a specific user base will use any given site. Originally, they were developed and used only by large marketing firms to help them better understand the demographics of their clients so they could specifically market products and achieve higher profits. There is a science to personas. Some people do nothing else except research and create personas for big business marketing focus groups. Though lucrative, it can be very tedious as the number of hours that go into any given campaign can rack up quickly given the amount of data that is collected, poured over, refined and utilized in building out even a small set of two-to-four personas. But consider a fully robust set that a megalithic corporation like Nike™, Coke-a-Cola™ or Target™ may need to represent nearly every demographic possible. This can take months, with the rewards to the company being returned many times over when an advertising campaign is successful.
But why use personas in software design and defining UX? To answer that, we need to better understand the need that they fill.

Before Personas

Before personas, IxD and UX were common concepts in the development world. We were engineers, not UX designers. We relied heavily on “the gut check” to gauge what made the most sense when determining flow and getting things done on a website or designing software. This skill came simply from past experience building applications and websites, performing countless usability tests or even simply being aware of one’s own usage of just about anything involving human interaction. Being aware and observing is something we are all capable of. This can be refined into a well-honed blade that gives us a powerful tool for understanding how people think, react and interact with just about anything.
I am not suggesting that UX and IxD professionals have a superpower, but they are well trained by their craft and past experience, making “the gut check” and accomplishing day-to-day UX goodness. But again, before there were personas and UX or IxD in the software and website world, the amazing powers of observation were what engineers used to determine how best to design an application.
Using this method without data led to ego clashes. An engineer perceived a button better placed to the right and a project sponsor believed it better placed on the left, as an example. Or if two engineers had a similar discussion, it easily turned into a battle of wills or, most often, egos. Who was right? In the case of the engineer and project sponsor, it was whoever was paying the bill, and that was the business sponsor. In the case of engineer vs. engineer, it was the louder voice. The end user ultimately suffered without anyone knowing any better.
It wasn’t until Alan Cooper realized something was missing in the early 1990’s in the world of software development that the concept of personas was born. The idea that designing for specific users over general users would make an impact led him to develop the interactive design methodology and the persona for software development. Alan honed Goal-Directed design and the methodology that removed designing for the “elastic user”, or rather design decisions based on convenience by business stakeholders or possibly through ego centric reasoning.
Over the years, personas in software development have attracted criticism that they are too generalizing and fictional. Overall, the important takeaway is that there was an increased awareness around thinking about the individual user and using that knowledge and awareness to enhance the UX.

Keeping It Real

In order to avoid the trap of simply creating generalizations for an application or website’s user base, it became necessary to interact with end users often through usability testing.  This gave us the ability to not only record and see a user interacting with our interfaces, but it became an opportunity to know the user, to talk to them, find out what is important to them and hear quite candidly why they do or do not like something we’re having them interact with on a regular basis.
We began carefully crafting questionnaires for testers to fill out, followed by conversational interview questions to not only put them at ease for a relaxed and more insightful test but to gain a better idea of who the individual really is, what motivates them in their day-to-day, what they do every day for a living and why and how they use a site or application.
Each tester becomes a persona and a profile is documented and fleshed out to tell a story about who this person is, their needs and how those needs are fulfilled and met using what we have built.  While we do categorize them, what we end up having are real people to reference and identify with.

Usability Outside of the Lab

Originally we had expensive usability labs with cameras, screen recording, eye tracking and one-way mirrors.  These were great experiences and are still in wide use by those who can afford it.  But they are labs, and labs can be off-putting, uneasy and can skew unfavorable results depending on the individual tester… not to mention expensive.  This tends to have the effect of many companies not performing testing at all.
A growing preferred way of “testing on the cheap” is producing more holistic results and capturing people as they really are.  Armed with tools and methodology made prominent by the father of usability Jakob Nielson and common sense usability guru Steve Krug, virtually anyone can conduct a usability test with next to zero budget.  With a pen and a simple script, an individual can test your application or website for you.  Ask a friend, neighbor, co-worker or family member to do a test with you just to try it out.  It is surprising how many people are willing to just give it a shot for fun.
At Isos Technology, we develop a test script based on the needs of a client, the application and a basic understanding of the user base.  We use an inexpensive Mac application called Silverback to record our test sessions, and then document a list of tasks or recommendations that we observe during these sessions.  This is reviewed with our client every time the application or site is improved through this process.
While the video and documentation is made available to our client, we have found that inviting a stakeholder, developer and/or designer to sit in on individual sessions to see firsthand how a real user is interacting with their site or application is invaluable, insightful and occasionally humbling.  Nearly every time, an observer says, “I had no idea”, or “It never occurred to me that someone would try to do that.”
Testing often and routinely before a big release of new functionality and in small groups will maximize your time and efforts with documentation and identifying areas of improvement before going live.  It will also keep you in contact with your individual users who are evolving just like your company and your application or website.

Conclusion

Through simple usability testing, you can keep in touch with your end users.  Your client/observer will have interacted with a real user and made a connection.  When they go back to their desk to write code, design screens, write requirements or make decisions, they will have an understanding of who and how they are impacting with their decisions.  This will ultimately deliver a better product and result in greater profits due to happier users.