Alternate title: Pick-a-little, Talk-a-little

Over the last 18 months or so, I’ve logged 200+ hours of moderating, watching, and reading user research sessions. Entrepreneurs with dreams of success, bloggers who love murder mysteries, and everyone in-between. When thinking about lessons to draw from these sessions, I returned to a note I scribbled while watching someone carefully read every bit of page copy before making a decision:

“I swear, everyone I’ve watched either picks each link with care or
recklessly clicks around. There’s no middle-ground.”

It sounds silly, but it makes sense as a way to think about how people interact with us. Less like persona and more a mode of behavior that influences the interactions. When you watch a session, it’s fascinating to see how people differentiate themselves as one or the other. 

(In doing research, there’s always the observer’s paradox to deal with: by observing a situation, you can influence it. After 200+ hours of sessions, the paradox is less of an issue and more of a Wikipedia rabbit hole to go down when you should’ve gone to bed hours ago.)

So what makes a Picker or a Clicker? Why does such a behavior matter for how we design? Great questions. Let’s look at the behaviors and ways to design for them.

The Pickers

For Pickers, the phrase “measure twice, cut once” comes to mind. In interviews with Pickers, you can almost hear them take their hand off the mouse when they see a new screen. In some of the more vivid interviews, Pickers talked about previously making mistakes with a site that cost them dearly… and vowing to never let it happen again. They might seem low-tech, but they’re cautious and careful.

Things Pickers Do

• Take their time, especially with new interfaces and tasks
• Aren’t always sure if they can recover from a mistake
• More likely to abandon an interface and use browser controls
• Are looking for cues and hints before they commit to a click
• Get comfortable with patterns of clicks and paths they know
• More likely to be apprehensive of new screens and flows
• Have expectations that complex tasks take time
• THEY. READ. EVERYTHING. 

Designing for Pickers

Take time to introduce the new and complex
When showing someone a screen they’ve never seen before, lean towards explaining a bit more. Don’t produce a wall of text (see the next tip), but think about how you present a new feature or section: Is there a clear explanation of what it is, what it does, and how to use it? Are there clear links to documentation or follow-up reading? 

Read your screens
When you think you’re done with a screen stop, take your hands away from the keyboard and read the screen. Start from the top left and look at every bit of copy. How long does it take? Now imagine where someone sees themselves after reading it all. Where are they going to go next? Are there terms and words that might throw a less-than-savvy reader? Can you shift away from a technical term and find a real-world replacement? All these things help Pickers get results.

Be thoughtful with hints
Pickers are looking for all the help they can get. They know about the hints and cues the web provides.  If they’re unsure, they’ll hover and hope for a bit more information. They’ll look for the classic signs of help or more info. They’ll be happier to see “Help” and “More Info” as opposed to a question mark or an “i” in a circle. (Note: This doesn’t mean you should give every element a hover state; it means consider them for complex controls or areas.)

Re-use patterns and flows
The more Pickers recognize a flow or task the better. Can you harmonize input methods and displays in a complex flow? Think about the patterns people interact with every day. (Two-panel selectors from desktop operating systems, bread crumbs, and more.) Consistent can be boring, but for Pickers it’s a lifeline. (Read more about UI patterns here.) 

Save states and error recovery
Pickers are more likely to hit a roadblock, get jammed by new interactions, or simply run out of time. With that in mind, think of how you save work in progress. If someone gets more than halfway through a flow, can you find a way to let them save and come back? If someone leaves and comes back, how can you let them know they have a point to return to? (Think about the classic Save Point in video game design.)

The Clickers

One of the better ways to describe a Clicker is “the journey is the reward.” Every new screen is something to explore. They see a new screen and get right into it. Whatever their skill level, they use the web with gusto and no fear. They usually know how to fix their own problems, recover from errors, and get what they want. Clickers understand this approach can lead them down a wrong path or to a dead-end, but they not phased. They hit the back button or fiddle with controls and navigation to find what they need.

Things Clickers Do

• Explore an interface to see what happens
• Read very little of the copy before making a decision
• Jump from screen to screen with few issues
• Know how to recover if they make a mistake
• Have expectations that it might take a while to find what they want
• More likely to say “Oh, cool!” when they discover something new

Designing for Clickers

Watch your controls
Make sure you don’t take control of an interface or screen away from them. They like the Back button, and they know how to use it. If you present a flow or stepped process, show how to move back and forth. Even better, contemplate what will happen if they say “to heck with it!” and use the browser Back button instead of an interface control.

Scannable copy and elements
A Clicker may only take seconds before they make a decision, so the more you can do to give them cues the better. Clear hierarchies for your screens will make their scanning more effective. 

Consider state management
All this clicking around comes with a price – states can get lost as they crash in and out of flows, forms, and more. Clickers are likely to generate half-finished tasks because of false-starts and abandoned flows.

When in Doubt, Lean Towards the Pickers

People can move between the two modes as they become more comfortable. Ideally, we’ll find a way to turn every Picker into a Clicker as they learn our screens and flows. The trick is that it takes time for someone to gather that confidence. It’s a smarter long-term proposition to build for a Picker.

Clickers are likely to put the time in to find a solution for their problems. They’re going to get what they want and, in some ways, see completion of a task via hurdles as a victory to savor. (Not the sort of victory we like to see our users celebrate, but there you have it.)  Clickers are more likely to bounce back and start again. 

Pickers are the people you’re most likely to lose as they get frustrated. When a screen gets confusing or a new interaction gets thrown at them, there’s a chance of a ‘fight or flight’ reaction. There are more ways to lose a Picker, and when you lose them, you may never get them back.

Let’s face it, Clickers are fun to design for. They’ll explore and enjoy breaking things. As designers, that allows for experimentation and exploration. That same experimentation can drive Pickers out the door (or away from the browser). It may seem boring, but designing for Pickers with familiar interactions and reduced complexity is a winning strategy. Everyone benefits, and that’s the best kind of design. 

OK, let’s have fun out there. Thanks for reading, and keep on pickin’ and grinnin’.