1 of 38

Slide Notes

I'm going to jump right in by acknowledging one of the unfortunate effects that our present day focus on grabbing people's attention is having:

Numbered lists of things you just have to pay attention to.

So I won't be rattling off a dozen steps you need to take right away... And I promise that no more than 3 will be shocking.

Pervasive UX - 30 Amazing Weird Tricks for Understanding Your Customers

Published on Nov 18, 2015

From a presentation I gave to the Tri-State College Library Cooperative on April 25th, 2014. I talk about an approach to understanding customers I called "Pervasive UX". With an emphasis on conducting small-scale, frequent testing with customers (or, frankly, non-customers. Anyone with a pulse will do.)

PRESENTATION OUTLINE

PERVASIVE UX

30 AMAZING AND SHOCKING TECHNIQUES YOU JUST WON'T BELIEVE
I'm going to jump right in by acknowledging one of the unfortunate effects that our present day focus on grabbing people's attention is having:

Numbered lists of things you just have to pay attention to.

So I won't be rattling off a dozen steps you need to take right away... And I promise that no more than 3 will be shocking.

WHAT DO I MEAN BY "UX"?

  • The process of bringing the end user into the design process
  • The research techniques utilized in #1
  • Anyone who makes that process happen
There is a lot of discussion in and around the ux community about what the terminology should be, who can have which title, and who "owns" the process.

I'm fairly easy going about all that, mostly because I think it's just shop talk, and also because I think outcomes are more important than certifying the process.

So I stick to a definition that a pretty inclusive and open ended, but very specific about one core element: the process has to involve users, not intermediaries.

MANY SMALL STEPS

"RADICAL INCREMENTALISM"
There is a growing tendency towards short, repetitive cycles of innovation that is replacing the "big push".

Extensive, insular planning is giving way to inclusive design and development techniques that stress rapid cycles that push innovation forward
Photo by tim caynes

6 DAYS TO AIR

So here's an example of how the production cycle is compressing. An episode of Southpark is conceived, written, animated, recorded, mixed and delivered for airing in 6 days.

Regardless of what you think about the subject matter or style of humor, this is an impressive accomplishment. And their team does this for 7 straight weeks, twice each year. For comparison, the typical animated series takes about 3-10 months to create, per episode.

Let's think for a moment about what this means. It means that the writers can be incredibly topical, and react quickly to current events. That's a huge advantage for a show which relies on relevance much more than visual fidelity for its impact.

It means that the people who make this show get to feel a sense of significant accomplishment Every. Single. Week. Talk about motivation! Again and again the best places to work are those where people have a sense of purpose and can pinpoint the value of their contribution.

It means that the product is better. Trey Parker has said that more time to produce each episode wouldn't have made them any better. Instead, the deadline forces hard choices. More time just prolongs the pain, and gives the team more opportunities to second guess themselves.

So what? That's a cartoon, and a crudely drawn one at that. That's entertainment, and if an episode or two doesn't do well, what's the big deal?
Photo by DiddyOh

RESEARCH IS NOT AN EVENT

What does this have to do with ux?

That's a great question! Here are some others:

"What should we build?"
"How should it work?"
"What do we need to do first?"

These seem like really good questions to answer before you embark on any significant design or development effort.

Why commit significant resources - time, money, opportunity - without at least some idea of what you are trying to accomplish?

We talk a lot about scale in the tech world: will it scale up? Will we be able to handle the traffic, the orders, the usage.

But development costs - and this is true of services, software, hardware and design - are coming down.

The challenge for UX is in scaling the research down to the level on which the technological innovation is occurring.
Photo by kevin dooley

STARTUP COSTS HAVE COLLAPSED

In 2007, when the iPhone first came out - I want to pause for a second to let that sink in: in 2007, about 7 years ago, the first iPhone was released -

If I wanted to build, deploy and support a simple to-do list kind of application, I could have easily spent $1 million. Buying and deploying servers, designing and programming the software, putting up a website - all before a single user was on board.

All before I could really do a lot to validate that this was something people wanted, and would be willing to pay for.

Today I can create a similarly innovative application for about 1/10th as much.

LOOK AT WHAT'S MOVED TO THE BACKEND

Some costs have fallen farther and faster than others, notably those that can be outsourced -

And one of the ways you can do that is through something I'll call "back sourcing"

That's moving big, up front to after a product has launched.

Cloud computing in particular has made IT costs mostly contingent on the success of the business, rather than the other way around.

TESTING IS RISK MITIGATION

YOU'LL TEST WITH CUSTOMERS... EITHER BEFORE LAUNCH, OR AFTER
So, what do we do with that advantage? If it's ten times cheaper to build a product, do we build it ten times faster? Do we build it ten time better?

We in the ux field have talked for a long time about the need for testing, with the mantra of "test early and often".

But this was often working against a headwind of development budgets that could only accommodate one or two rounds of usability testing, because building the thing was so time consuming and expensive.

And so the mantra became, "test early, so we don't find out about a problem after we launch."

WAITING TO REACT

THE LAST RESORT BECOMES THE ONLY LINE OF DEFENSE
But that puts an enormous amount of pressure on testing, with the result being that people look to testing as a way of validating what you've already decided.

That's like saying "we are so sure the goalie is going to stop the puck, that we're gonna take everyone else off the ice."

The goalie's job is not to stop the puck

The goalie's job is to be there when everyone else fails to stop the puck.

When testing gets backloaded, no one is ready for failure. No one is ready to hear, once the product is done,
Photo by mhaithaca

"THIS DOESN'T WORK FOR ME"

Photo by anieto2k

"I'D NEVER PAY FOR THIS"

"WE ALREADY HAVE SOMETHING THAT WORKS"

People are remarkably willing to make do with what works for them.

"Good enough" is the enemy of innovation.

There's a common saying in the tech field that if there's any kind of switching cost, your product has to be 10 times better than what the user is already using.

Hey, 10 times?
Photo by NatBat

FAST, CHEAP AND...

Development costs have compacted, and that generally means that it's easier to build something people can actually lay hands on and use.


But that by itself doesn't get you a better experience.
Photo by Chris_Parfitt

FAIL FAST, AND OFTEN

THE PRODUCT THAT FAILS FIRST, GETS BETTER FIRST
Cheap development means that you can get real product in the hands of your audience faster, so they can tell you what's wrong with it.

BUILD LIKE A STARTUP

"A STARTUP EXISTS TO FIGURE OUT HOW TO MAKE A BUSINESS"
"Fail fast" is the mantra of the most successful startups and innovative companies of our day: iterate, try new things, figure out what works and what people want and love

Photo by kdinuraj

NOW IT IS THE PROCESS

USER CENTERED DESIGN USED TO BE A PART OF THE PROCESS
UX professionals used to have a hard time fitting their contribution into the development process; there was never enough time to include research or user feedback into the development timeline, except in maybe a few key "gateway" points.

Again, testing as validation.

But now, the startup process, and the process of innovation in general, is almost exclusively user-centered: testing with real people throughout the development process is now expected, and demanded.
Photo by azwaldo

WE'RE GOING TO NEED A LOT MORE CLIPBOARDS

So now there's this embarrassment of riches, where UX as a practice has become an accepted and central theme in innovation...

And the number of people who are really experienced at doing good research, and helping to drive fast paced projects through many rounds of innovation, is still relatively tiny compared to the need.

Everyone is subjecting their work to the rigors of real world testing...
Photo by pennstatenews

UX RESEARCH 101

Fortunately, good ux research is easy to learn, and the tools are inexpensive and widely available.

I'm going to spend the next few minutes giving you all the pieces you need to do great UX research.
Photo by Michael Blann

WHAT DO YOU THINK?

AND WHY ARE YOU WRONG?
The first, and most important tool, is your hypothesis.

Whether you're talking about Design Thinking, or Lean Startup, or Agile or whatever design and development methodology you're following, they all have one thing in common: the team is building something they think will solve a problem.

The purpose of testing is to figure out why and where the team went wrong.

You're testing for what's below the surface, for what you don't know about.

You're looking for the unknown unknowns.
Photo by horslips5

YOU'RE NOT LOOKING FOR "YES"

YOU'RE LOOKING FOR AN ABSENCE OF "NO"
This is one of the most essential inversions of the development and design process, that of applying a scientific method to what most people think of as a subjective judgement.

Great design isn't an accident; it's not a thunderbolt from the sky or a revaluation in the middle of the night, it's the result of a long string of tiny, incremental failures.

It's almost universally the result of coming to the end of "not right"

WATCH WHAT THEY DO

So once you've figured out what question you're asking, your hypothesis, it's time to watch.

This is probably the hardest thing to learn and to do well, so I'll be a bit more specific about what this means.

When you are testing your work with people, it is not your job to guide.

It is not your job to explain.

It is not your job to answer.

It is your job to put a problem in front of a person, and watch them suffer as they try to figure it out.
Photo by madpai

LISTEN. AND THEN VERIFY.

ASK THEM TO SHOW YOU HOW...
Next, because you're building a product, or a service or an app... Something that people use... You want to understand how they'd use it.

When you ask questions, they should always be directed towards getting people to show you something, not tell you about it.

The reason is simple: people are notoriously unreliable narrators of their own thoughts and motivations. You'll always get misdirected by a story.

But it's nearly impossible to fake the competent use of something that isn't intuitive.

GET OUT OF THE BUILDING

Lastly, the most important perspective comes from the people who have no stake in the outcome. Outside of your office, out in the wild, there are a little over 6 billion potential research participants.

More to the point, with few exceptions you are creating something for people who don't work with you everyday. So you need the perspective of people who don't understand your office politics, your strategic plan, your department structure - all the things that can end up influencing the creative process, but which mean nothing to the people who ultimately pay for the product.

FOCUS IS OVERRATED

Getting out of the building gets you out of a controlled environment. Having designed and built a number of usability testing labs over the years, I can tell you that the one thing they're not very good for is simulating the real world.

Normally, people are distracted any number of times from their normal routine. This isn't an error that you want to eliminate in your testing; it's a condition you need to figure out how to work with.

QUALIFIED = DOES NOT WORK WITH YOU

So, you're getting out of the building, but where to?

I'm going to show you three places where you can always find willing, helpful qualified research participants.

Untitled Slide

Laundromats - this one is a bit more upscale than most, but you'd be hard pressed to find a better place full of people who've got some spare time but who can't go very far.

Untitled Slide

There are about 11,000 of these in the US, and another 13,000 independent coffee shops to boot.

Make friends with someone who owns one. Firstly, you're going to need their permission if you want to camp out all day, but second: many of them will even be helpful directing potential participants your way. If you say, "I'm looking for half a dozen doctors," they'll know which customers to ask.
Photo by garryknight

Untitled Slide

PEOPLE WANT TO HELP

By and large you're going to find a lot of people willing to give you their opinion.

But by and large, they're not going to want to hurt your feelings. And in a structured testing environment, they may be reluctant to criticize your work. So next, let me talk about a few key phrases you can use make testing really successful.

Because , again, you're trying to get people to tell you what's wrong with your work.

Untitled Slide

  • I'm testing a competitor's site
  • I didn't have anything to do with designing this
  • Can you help me try to break this?
  • If you had to get rid of something, what would it be?
  • How much would you pay to use this?
The key here is always to make sure your participant knows that you are interested in the most brutal feedback they can offer.

But remember, you're looking at what they do, more than listening to what they say.

WRITE WHAT YOU SEE

Finally, there are a lot of tools you can use to capture what's going on in your testing, but these are the only two that really matter.

Often I put together a little form that I just make lots of copies of, and it looks a bit like this
Photo by steakpinball

DESIGN HYPOTHESES FOR [PROJECT]

  • Participant understands that the purpose is to [blank] (YES | NO)
  • Participant can compete the task without asking for help (YES | NO)
  • Participant can identify an alternative solution that's better (YES | NO)
  • Participant is willing to pay [amount/month] for this (YES | NO)
These are the four basic questions I try to answer in every test.

I'm looking for three yeses and a no.

GOODNESS IS ITS OWN REWARD

BUT IT DOESN'T HURT TO GREASE THE WHEELS
Finally, there's the matter of incentives. Many people will be willing to offer their opinion for free, but providing a tangible incentive does a few things:

It can overcome a slight reluctance to participate.

It gives the research an air of formality and legitimacy

It signals that you are serious about wanting serious feedback.

Having said that, cash isn't always the best incentive, so I also like to use:

Untitled Slide

The obvious and least-awkward choice when you're testing in a coffee shop. Go ahead and open a tab with the barista.

People will generally be restrained about what they ask for, just point them over to the counter and say, "let John there know what you want, and tell him it's on me."

Untitled Slide

Candy is usually effective, particularly when you are intercepting folks in transit

Use the full size candy bars not the "fun" size.
Photo by cobalt123

Untitled Slide

Gift cards, which are now even easier to buy in bulk than candy.

If you do feel the need to go the quasi-cash route, about $1/minute tends to be a good estimate of acceptable value.
Photo by 401(K) 2013

EVERY MEETING SHOULD END WITH AN ACTION PLAN

Here's my challenge for you:

When you leave here, go home, and make a plan.

Schedule a field test of something you're working on for next Friday. That's May 2nd. Figure out one thing you want to learn, one question you want to answer, and form a hypothesis around it. Pick something to test: your website, your competitors', a sketch you draw on a piece of paper.

And then go test it.
Photo by jaubele1

YOU HAVE 6 DAYS

Photo by jaubele1