Hello everyone, and welcome to this week’s episode of Front End Center!

There are a lot of tools available for planning design and development projects. Some have been around for ages, and some are brand new and trending on Twitter as of yesterday. Some are widely accepted, and some are a little more… divisive. The rather subjective area of User Experience is filled with particularly powerful, but also constantly contested, methods and ideas.

User Personas are one of the leaders for being equally useful, misunderstood, and starting intra-office Cold Wars between teammates.

So what is a Persona?

Usability.gov defines a Persona as a reliable and realistic representation of key members of your specific audience. They must be based on both qualitative and quantitative research, to ensure that they accurately reflect the users they claim to.

When you boil it down, the goal of a Persona is to singularly represent a major group of users for your project. Rather than refer to “the 60% of users who use only mobile phones”, we consider the needs of “Mark, our user who doesn’t have desktop access”.

A Persona distills and expresses the major needs and expectations of the most important user groups in our work. You don’t need, and should actively avoid having ten, twenty, or a hundred different Personas to represent every little user quirk. If you end up with as many Personas as actual users, you’ve just gone and wasted your time.

Because one given Persona only represents certain needs and expectations, we can use it as a reference for how that specific user would interact with elements of design and development. We can get in that headspace and see what opportunities or unexpected challenges we need to account for, with that user in mind.

So why are Personas often maligned in the world of web? Like Dreamweaver and countless other casualties of creative warfare, Personas do not have an inherent mechanism that ensures they’re used well.

There are many places Persona use can quickly go off the rails. Like before, just having too many of them is a big problem in and of itself. Discovering the usefulness of a robust Persona can be a little intoxicating, so it’s no wonder why less experienced designers or researchers might go overboard.

Often compounding that is the issue of how the Persona is constructed in the first place. I was immensely guilty of this myself as I learned how Personas functioned. Many people who leap headfirst into the idea of Personas are very creatively inclined, sometimes at the cost of functionality or actionable content.

It is indescribably satisfying to read about how complex user Personas shaped an international business’ successful rebrand… and then just go imitate their fancy, shiny, finished product. You walk away with a bio-sheet filled with a pretty-looking stock photo actor, their imaginary name, and the interesting and very important life details you came up with for them.

There’s even a data point for their favorite cereal, because that’s a good reference point for their brand and design preferences!

Now, if only you had a project worth applying them too… that also happened to be suited to this particular Persona. Oops.

The best laid plans mean nothing if your final product is fluff. It sounds mean, but I’ve begun constantly checking my own processes and ideas for pointless fluff. It’s seriously way too easy to get excited and go from a good start to three weeks’ worth of fluff without realizing it.

Personas are one of those tools that have immense potential, but have to be constantly lint-rolled to prevent a fluff build up. Their polarizing reputation comes from this fact, and that many designers and developers have only ever seen poorly made and used Personas. In worst case scenarios, they just become arbitrary gate keepers that stifle genuine creativity and good ideas, all for their own pointless sake.

So how is a good Persona constructed? Accurate information. Trends, user analytics, and quantifiable data. How is a great Persona made? All those quantitative details, with just a sprinkle of qualitative input.

While you don’t want a house built on a foundation of fluff, you’d be amazed at how perfect fluff is for finishing decorative touches! Whether you’ve asked a user about their general experience in a coffee shop, or your spouse made a passing comment as they walked by your office, that information can supplement your organized data in the most amazing of ways.

Persona construction also differs depending on what your project is. An app start-up is going to have Personas focused on their customers. They want to identify the differences between their power users and their casual users. They’ll be using Personas to balance the needs and goals of entirely external users on a customer-style basis.

Leveraging Personas in a business role, especially at enterprise grade, means using the same tools to construct a different end product.

Business Personas are particularly prone to becoming too numerous or complicated. Let’s take an example of a re-brand for a big electronics re-saler. What Personas should you include?

First, we have to consider the employees of the company. How many dedicated Personas do we employ? Can everyone above manager fairly represented in one Persona? Or will we need a manager Persona, regional supervisor Persona, Director Persona, and more?

What about the standard employees? Those on the sales floor, working security, and running the back stock room are definitely not going to have the same needs.

Next, we get to move on to the customers! These Personas could be every bit as complex and numerous as the customers of the app startup we talked about previously. Does that mean our project requires a minimum of two times as many Personas, by default?

The real trick with Persona creation is being attentive and organized. Consider the scale of your project, and what you can departmentalize. Perhaps the public website of our electronics store does only need a single Persona to represent employees, and it should mostly focus on the sales employees’ needs. The CEO probably doesn’t have a lot of special user demands on a daily basis.

The we can consider the internal company software separately, and have more complex business Personas while leaving customers out of it completely.

While this example is overly broad and should be pretty obvious, it makes a good example. Every project that seems to demand more than a couple Personas is probably actually being tackled at too high of a level. See if you can, even just internally on your team, break the functions and purposes down to a smaller level.

Try to reach a point where you can effectively identify specific user Persona needs and goals, and you’ll be able to better meet them and ensure a high quality end product. Your final results will be vastly improved if you pay attention to the details, rather than try to herd a crowd of pretty-looking Personas into convenient corrals.

So next time someone brings up Personas for a project, give them a consideration. Be ready to help de-fluff and refocus the conversation, and make a contribution that everyone can benefit from. Remember: anything worth doing is worth doing right.

Thanks for listening, everyone. This has been Chris Landtiser, and Front End Center.