Main menu

These past few months I have had the opportunity to do freelance work with a few different agencies and have had wildly different experiences. One thing that becomes clear is that, while UX is a buzzword and many clients seem to want it, many agency heads (account executives) don’t really understand what it is. And now the buzzword has changed again: “Lean UX.” This makes it more complicated, because UX itself is so poorly understood that adding a modification complicates communication all the more. I’ll attempt here to clarify a bit.

“You do wireframes, right? Because our clients expect wireframes.”

One of the main obstacles facing many agencies incorporating UX into their process is the idea that design deliverables are the only evidence of billable time. I can’t tell you how many times I’ve been on a team of designers who worked hard to making an initial iteration of a comp pixel perfect; it’s the industry standard and clients rightfully expect it, especially with deliverables destined for print. When we apply this expectation to web work it makes less sense (browser and device differences being among the chief factors), and when applied to UX tools such as wireframes it makes none whatsoever. Since UX has popped onto the client radar, the expectation is that wireframes comply to the same exacting strictures as design deliverables.

This somewhat defeats the point of using wireframes at all, since if one is going to wireframe in Illustrator or Fireworks then one may as well be designing instead. Clients see these documents and focus on visual specifics rather than functionality. This also holds true to a lesser degree for personas and taskmaps, other crucial tools for a user experience designer. This is not to say that aesthetics are not a very important part of UX; they are, but they don’t apply to wireframes.

Wireframes function as a point of reference that will allow quick collaboration between the business strategist, the interaction designer, the developer and the graphic designer. they can come in different flavors from napkin sketches to fully interactive simulated sites. The idea is that you can test the way the interaction actually functions.

The great thing about using a tool such as Axure is that you can do a pretty good of showing how the site will actually function and be able to demonstrate and test it… all without needing to involve your development team. A wireframe interface is easily modifiable, too. If something doesn’t work, it is easy to change it.

So what exactly ARE we delivering?

My experience has shown me that user experience design benefits from using a programmer’s mentality of asking first what it is we’re trying to do. As a UX designer, my questions are simple:

1. Who is the user and what are her priorities?
2. What does the user want when she uses this tool, website, or app?
3. What does the business want her to do?
4. What is the best way to address of these needs simultaneously?

Where do personas fit into this?

Right at the beginning, because personas are the tool that we use to keep us on track. But what are they?

First, what they’re not:

Personas are not a demographic. They aren’t a segment or a group, though that’s where they start. Really, a persona is a fictional, yet accurate, depiction of an actual user. The goal of a persona is to humanize the target audience so we can better understand their motivations and behaviors and how they will interact with the interface. We need to know who these people are and what they want.

In reality, personas should be the locus of the entire development process because they ensure that we are designing for the user, not themselves. Personas will create alignment on this key point.

That’s all well and good, but how do we know? Often, businesses think they know their customer through and through. Often, they are wrong. They forget the all-important fact that they are not their customer.

Ideally, the process of creating personas typically begins with baseline demographic information that provides known demographic data with quantitative insights to identify core similarities and differences. This will divide the audience into segments.

Then, that information is sifted further by using third-party research tools to start identifying individual characteristics based on demographic and other factors.

Once the differentiating factors between the various individuals are fully identified, we are in the position to form some hypotheses about our users. We might find that certain of them only interact with the site at night and draw some conclusions from that. These conclusions need to be confirmed of dis-proven by actually talking to real users. This can be done with surveys, emails or face-to-face interviews.

The final validation is achieved by conducting more extensive interviews with subjects who closely match the personas. Such individuals can also be used for user tests on existing interfaces for the purposes of auditing websites and competitor analysis as it affects the core of the target market.

The end result is typically three to five individual personas that I humanize. Each persona contains a name and picture along with an extensive background (including city, job title & salary, marital status, age, race, family, etc.), prime motivators, expectations, buying patterns, technology patterns, pain points, favorite brands…in short, a well- rounded look into the specific factors that may come into play when the user engages the product.

Realistically, this can’t always happen. In fact, I’d go so far as to say that only a tiny portion of personas are grounded in the kind of research that’s really required. It’s expensive and time-consuming and usually the client doesn’t want to spend for it because they believe that the research is enough.

It’s not, for one key reason:

Research is not a design tool. Personas are, and by using them in every case we ensure that we are not designing for ourselves.

So what’s usually done are proto-personas. These start with some quantitative research by marketing firms such as Forrester and are essentially fleshed-out versions of the demographic. In-house subject matter experts and business owners can help confirm hypotheses and help personalize the personas. I have found LinkedIn and my own personal network to be a great use in confirming a hypothesis that is shown in the big-picture research. Quick emails to people I know who match the target can help, as can a phone or face-to-face conversation. Most recently I was working on personas for a pool table manufacturer and talked about the tables with my barber, a pool enthusiast. There are ways to do that don’t involve the sticker shock of full-on process.

And getting 80% of the way there is a lot better than having nothing, or worse: a bunch of wholly fabricated stuff.

Personas do work to prevent us from designing for ourselves. The problem is that all too often they eventually come in to conflict with actual users…and the users generally lose that battle too, because by that point the designers are too invested in the personas.

If they’re validated properly, they won’t usually do that. But it’s a good policy to review them every few years, especially if user testing is showing some big discrepancies. Enterprise personas are a necessity for any sustained development project.