The dirty secret that your UX engineers are not telling you
Every decade, the Internet startup community latches onto “the thing” that will make them successful. In the ’90s the focus was all on marketing and biz folks. Come up with an idea, raise tons of cash, market the hell out of it and grow fast. Come the first decade of the millennium and the focus shifted to the developers. The philosophy was to get some great hackers, put them in a room and allow them to create something great.
This decade, the in-thing is design. Everywhere you look, the mantra is about using design as the differentiator that will catapult the startup to greatness. Nothing wrong with that – design really does make a difference. Unfortunately, far too many people are confusing simplicity with good design. Sure, there are way too many bloated products out there, but there are now increasingly many products that are extremely shallow, in the name of good design.
Onboarding a user is not a band aid for a bad design
The trigger for this post was a comment on Techcrunch where the person said (to paraphrase) that having an onboarding process for new users is a band aid for bad design, and if the user didn’t intuitively use your product, then the product is too complex. In this person’s opinion, the developer should reduce features and improve the UX to the point where no onboarding would be necessary.
I can understand where the commenter is coming from, but its a dangerous idea to assume that fewer features and improved design is the answer to everything.
A lot of software developers are seduced by the old “80/20″ rule. It seems to make a lot of sense: 80% of the people use 20% of the features. So you convince yourself that you only need to implement 20% of the features, and you can still sell 80% as many copies.
– Joel Spolsky, Bloatware and the 80/20 Myth
Imagine you are designing a piano. Your good friend, the UX engineer, comes by and looks at the monstrosity.
“Jim, there are too many keys here. It’s intimidating and its going to take them years to figure out how to use this. They may need to enroll in classes. Do you really expect to sell this? Say, lucky I’m here. Why don’t we make a piano with just one key, and colour it red. That way, a new customer will know exactly what to press. What do you say?”
The exchange above might sound absurd, but the equivalent is playing out in many places right now.
Good design is not about more features or less features. It is about helping users achieve their goals. Sometimes it just takes one button for the user to do that. At other times, it really does take a fair amount of complexity to get there. Scratching out features and building a shallow product in the name of good design isn’t good design at all.
We are faced with an apparent paradox, but don’t worry: good design will see us through. People want the extra power that increased features bring to a product, but they intensely dislike the complexity that results. Is this a paradox? Not necessarily. Complexity can be managed.
– Don Norman, Simplicity is not the answer
The Dirty Secret: Most useful products have some level of complexity
However much UX folks like to deny it, most products that users use again and again have a certain amount of complexity and a learning curve. Your operating system, a word processor, even GMail can be fairly complex beasts. The challenge for UX folks isn’t in simply discarding every feature until you are left with just one, but to effectively manage the learning curve as smoothly as possible.
Managing the learning curve can take many forms across UX design, onboarding, guided tours, lifecycle drip marketing, in-application notifications and user activity analytics. To discard everything else and focus only on UX design is a mistake.
Using In-Application tours to help users
When we created Tour My App, a lot of people asked us if this was the appearance of Clippy 2.0. I can understand where they come from, but in-application guided tours are vastly different from Clippy. Clippy would randomly pop out and interfere with whatever task you were trying to accomplish and give some useless help, which made it very annoying and frustrating for the user. By contrast, in-application tours can be a great tool to onboard users, show a demo or highlight features.
To get beginners to a state of intermediacy requires extra help from the program, but this extra help will get in their way as soon as they become intermediates. This means that whatever extra help you provide, it must not be fixed into the interface. It must know how to go away when it’s services are no longer required. Standard online help is a poor tool for providing such beginner assistance. […] beginners don’t need reference information; they need overview information, such as a guided tour.
– Alan Cooper, About Face 2.0