Need client personas? Try these 3 steps.

By Sarah Varki

This is a summary documenting the steps we took to create client personas for our company. We’ll cover the reasons behind doing so, and walk you through our process to get there. 

Why client personas?

Once upon a time in 1998, Alan Cooper wrote a book called “The Inmates Are Running the Asylum” in which a chapter introduced the use of personas as a design tool. Since then, they have been the common thread among all design methodologies (even Lean UX). However, the focus has mostly been on customer personas — the folks using your end product. Those personas are definitely valuable, but what if there is an extra layer?  What if your product is a service, and your customers are your clients?

At Applico, the product team decided that while personas help on a project level, we needed to step back and assess our clients using a similar framework. Historically, we’ve referred to past clients by the project’s name, but this doesn’t mean much to a new employee or an employee that wasn’t involved with that project or product at the time.

We believe that client personas will help us work with our clients. One benefit will be a better working relationship, as the personas help us anticipate behaviors, and detail how to best work with new clients. Internally, we would be able to speak the same language, allowing us to support each other and adapt accordingly.*

Not your usual persona process

Normal customer personas

The usual method of customer personas requires a lot of time, research, and focus.** A team can start with assumptions or proto-personas if it needs frameworks and something quick, but those eventually require in-depth user research to validate and further flesh out. Interviews take substantial time, as do long working sessions to shift through all the data. In typical persona creation, a team gathers a spectrum of behaviors they saw exhibited in potential and/or current customers from conducted interviews. In the case of proto personas, a team will work off a baseline knowledge of the customer.

Given the efforts, teams may hire a firm externally to produce beautiful, vetted, and detailed personas.  In addition, a product/solution ideally shouldn’t serve more than 1-2 personas, since they should help a team to focus and have a shared understanding about specific user needs. Worrying about stretching functionality to handle too many different use cases can be avoided by using focused personas.

Client personas are a bit different

Client personas, on the other hand, aren’t created or used in all the same ways.

To start, we didn’t need to interview clients because we had interactions with them over the years. We also have a feedback survey we service to clients that we could use as an input. And plus, many of our team members have interacted with the same client across various engagements, so our group has a diverse and well-balanced understanding about specific clients or companies.

We didn’t want to end up with an unmanageable number of personas, but we also didn’t need to limit ourselves to 1 or 2 personas as we would do in a product scenario. We wanted to ensure we captured the spectrum of clients we’ve worked with while also accounting for future client types. In the future, we may develop very specific personas if we see that we’re attracting a particular type of client with very unique needs. Customer or client, personas are never static and should be continuously updated.

The persona development exercise we’ve outlined below shows how we documented all the client personas we’ve encountered during our company’s lifetime.

3 steps to client personas

Here’s a quick summary of the steps we took.

1) Agreeing on the same variables

To start the process, we needed to agree upon two sets of variables. One was what attributes (behaviors, tendencies, needs, etc.) we see to be common among all clients, and are important knowledge for us to better interact with them. Our second set of variables was which clients we wanted to use for the exercise, since our actual list of experiences over the history of Applico is quite long.

To note, attributes should be thought about in terms of a spectrum of high to low, or opposites. You may start with a lot of variables, but should end up refining your list. You can set aside project-level factors such as deadlines because other variables such as how a client views us as a partner or how well they understand our processes will frame their understanding of deadlines.

Just as you can’t work with every possible attribute, it can be difficult to plot every single client if you have a long company history. In addition, the companies we work with usually have different products with different stakeholders, which can further proliferate your list of potential clients to develop personas against.

2) Mapping & clustering clients along attributes

This was the fun part. We got together as a group and placed clients along the attribute spectrum, relative to one another. This would then help us see who usually ends up together and cluster them. These groups (along with grabbing or ignoring outliers) would form the basis of our personas. For sanity sake, we color coded them, then set out to define what was unique about each group. At this point you may find you’re still refining your attributes (we prioritized half, to focus on fewer cases for clusters).

3) Fleshing out archetypes

We created a template based on customer personas we found online. While there are many variables that could be considered (for instance, favorite candy may matter in a customer persona scenario), we settled on name, tagline, age, role, motivations, goals, pains/frustrations. Below is an example of one of our outputs.

Wrapping up

As a bonus step we also tried to map out how our process would potentially change per persona. We outlined the impact on every team member as a sort of quick guide, which we will continue to update.

To note, if you’re trying to figure out how long this took, the answer is a common one in software development: it depends! We’re a busy firm with product managers on multiple projects at once. While we probably could have knocked this out in a few long meetings within a week, logistically that wasn’t feasible. Calendar-wise this took us about 2 months to complete, but investment from each team member was closer to a handful of hours spread across that time frame. As the driver of the initiative, I definitely spent more hours prepping outside of our meetings, which is something to keep in mind because the process isn’t something you can complete in a two-hour session.

*As these evolve, the next goal will be to identify unique attributes that would help Business Development with their client relationships.  Then a step further, learning how best we could market to these personas regarding our website, events, etc.

** What’s not included here was the general intro/education about personas. If you haven’t used personas at your company, that’s the pre-Step 1 that needs to occur first so everyone understands and agrees to the WHY first.

---

Filed under: Product Engineering | Topics: Design, personas, UX