Getting Users Past the Suck Threshold

🧑‍🎨 Creator(s)
🗓️ Publish Date
October 25, 2005
📚 Publisher(s)
🍿 Media Type(s)

🗃️ Archival copy:


How long do your users spend in the "I suck" (or "this product sucks") zone? Once they've crossed the suck threshold, how long does it take before they start to feel like they kick ass? Both of those thresholds are key milestones on a users path to passion, and it's often the case that he-who-gets-his-users-there-first wins.

Our O'Reilly editor Mike Loukides says our goal -- whether it's for product design or writing a tech book -- should be to focus on answering this question:

What is the minimum threshold at which the user can be creative?

Followed by:

Do whatever it takes to help them get there quickly.

And by "creative", he doesn't mean "be artistic". He means, "be able to apply the tool or knowledge or skill to do something useful or fun that they find meaningful or interesting." A long learning curve before true mastery is achieved is not the problem. The real problem is when there's a long learning curve just to get past the "I suck" (or, "this product sucks") zone, and a long curve before crossing the "Hey, I'm actually starting to kick ass at this!" threshold.

For most of us, our user wants to use our tools (software, books, sermons, screwdrivers, saddle, music) to do something else (collaborate electronically, learn, find inspiration, build a deck, ride a horse, dance). So we try to think about the thing they want to do, and how quickly we can get them through those two thresholds:

1) The suck thresholdThe point at which they stop hating you (your company), the activity itself, or their complete inability to do anything useful.

2) The passion thresholdThe point at which they start feeling like they kick ass. While passion is not a guarantee at this point, the chances of someone becoming passionate before this are slim.

And it's not always about the product--sometimes it's all about framing, documentation, and learning. It's about [straps self into buzzword appreciation chair] attenuation. Turning down the gain. Narrowing. Focusing.

Or as O'Reilly's Rael Dornfest puts it:

"...bandwidth continues to broaden, cycles are going spare, storage grows ever larger and cheaper, and content keeps pouring from the fire hose. No longer constrained by any virtual limits, we're feeling the effects of this flood of digital assets."

It's no longer about generating digital data--we have more than enough already. The challenge is now: How do we visualize the data, filter it, remix it, and access it in ways meaningful to us?

In many subtle and not-so-subtle ways we're seeing user experience and design returning to software.

What developments in UI and HCI design promise to empower users rather than confuse and overwhelm them?"

There are so many opportunities. Raise your hand if you've been feeling overwhelmed with the pressure to keep up. Nod knowingly if you've ever said or thought anything like:

"They released a new rev again? Oh. Great. I guess I know how I'm spending my next few weekends..."

"Is there NO FRICKIN' LIMIT to what they'll add to these APIs?"

"Don't you DARE throw out that stack of journals, magazine articles, web printouts, partly-read books, and blogs. I really am going to get to them."

"All I did was take a single wifi-free week's vacation, and now I have 19,343 emails and at least 600 posts in my RSS reader I have to catch up on..."

"Why oh why didn't I become a plumber? Not scalable, sure, but also not outsourceable. And the domain knowledge is fairly stable... unlike my CS degree... [begins to laugh hysterically and inappropriately]".

"I realize this product went through beta, but seriously, did they watch any real humans to try to use this interface?"

Yes, there are so many opportunities. Anyone who can help attentuate the firehose in some way is a hero to those who are drowning.

And we can do it in so many different ways.

We can do it with "less is less" products (championed valiantly by the 37 Signals folks).

We can do it with better tutorials, reference materials, and learning experiences.

We can do it with better design.

We can do it with filters. Or maybe lenses.

Remember, this is not about how long it takes to truly become an expert. In fact, where there is real passion there is always continuous learning and challenges in whatever it is the person is passionate about whether it's conversational Klingon or digital video editing or snowboarding or meditation or being a wine snob/expert. This is not about dumbing down to give users a nice (albeit false) sense of self-esteem. This is about getting them to where they can actually do something.

Here are a few possibilities, but of course it depends greatly on the context of the tool (including expertise and expectations of the user):

1) Consider making different user profiles within the product itself, and allowing the user to choose a configuration for the interface that matches the user's goal and current level of skill and knowledge. Yes, that could mean having things like "advanced modes", and while that's a somewhat controversial usability practice, it definitely has a place, and can be done brilliantly for many (not all) products. But yes, it's about attenuating what a particular user is exposed to in the interface -- not hiding capabilities from them without their knowledge.

2) If you can't change the product, change the documentation. I've been working on and off on an intro to movie-making book to teach Final Cut Express and Final Cut Pro to mortals. The Final Cut interface is beyond overwhelming:


We could spend the first three chapters describing what each component of the interface is for. But that just keeps them in the suck zone longer, produces cognitive overload, and completely violates the "give them the minimum needed to start being creative." In other words, trying to explain the Final Cut interface only delays their ability to start doing the cool thing--editing video!

But we can attenuate the interface by postponing the "here's what every single one of the 230 things in the interface does..." (and that's just the part of the interface you can see...) and instead focus their attention just on the six or less things they need to get in there and start editing video.


3) Use a spiral user experience model:


4) Create context-dependent FAQs and/or context-dependent "FDTs" (Frequently Done Things). At any given point in the use of a tool, what the user is most likely to do next is rarely random. By having some kind of reference or learning or embedded help that focuses on those can be a big help. Too many reference or training materials are organized by topic, when the user often has no idea what the topic IS. They want to do something, but they have no idea which part of the interface they're supposed to be looking up in the help file, because they don't know what comes next...

5) In training materials for the product, focus on getting the user doing something cool as early as possible! Don't bog them down with tons of theory before letting them apply what they've learned in some meaningful, interesting, and/or useful way. I've seen Java instructors make their students wait---forever before they students can actually write code, because the instructor believed they shouldn't be constructing code until they have a complete understanding.

That's not how humans work, and no, this is not a matter of "learning preferences" either. There may be some people who believe they are more comfortable learning the theory first, but that doesn't make it better learning -- even for those who believe they prefer it.God knows that if we had to understand physics before we could ever start to walk... most of us would still not be walking.

6) Make sure there's a way for the user to know when they've crossed the thresholds. Sometimes the user is capable of doing more than they realize. Find a way to prove to them that they really can kick ass (or at least that they no longer suck). This must not be faked! This must be real, and again--not some attempt to dumb it down to make the user feel good. It may be that the user is doing something meaningful, that applies directly to what they really want to do, but the materials/instructor/app haven't made it clear enough how this seemingly simple thing relates or bridges to something that matters.

So remember...

The "time to stop sucking" and "time to first kick-ass" quotients are among the biggest advantages we have in a world where the competition is both fierce and plentiful. (And that's both market competition as well as competition for our scarce and precious brain/cognitive/attention bandwidth.) More importantly, it's a way in which we can make a positive impact on the lives of users.

And for more motivation, don't forget to read Information Anxiety.

Now where the hell did I put my GTD next action list...