Design for the customer you will actually have. Not the beginner on day one. Not the expert you wish you had. Beginners do not stay beginners for long. Very few become experts. Most settle in the middle and stay there. That middle is where I design first.
Then I give them more than one path, because no two customers move through a task the same way. I learned both halves of this the hard way. Once at Lycos. Once at Vivox.
Lycos Clubs: built for the expert we wished we had.
In 1997 and 1998, when online communities were just being invented, we launched Lycos Clubs. We were early. We had the audience. We built it for innovators. It had every option and every feature a power user could want. It was impressive, and it was very, very complicated. It did not get much traction.
About six months later, Yahoo launched Yahoo Clubs. It did less. It was simple enough that an ordinary customer could understand it in one look, and it took off like wildfire. We had designed for the expert we wished we had. Yahoo designed for the customer who actually showed up.
Most of your customers, most of the time, will be intermediates: past the first day, nowhere near expert. Design for them first.
When people achieve an adequate level of experience and ability, they generally stay there forever.
Alan Cooper made that argument years ago, and it holds. He called these users perpetual intermediates. They do the same tasks over and over. They want neither the help screens nor every expert option.
Vivox: one path, and what it cost.
The second half of the idea is paths. No two customers move through a task the same way. I learned that at Vivox, where I served as chief product officer. Our spatial voice platform was powerful, and monolithic. You took the whole system or nothing.
Twilio offered many of the same functions as small building blocks. A developer who needed only two-factor authentication took that one block. Need conference calling? Another block. Vivox was sold to Unity, a good outcome. I would call it a base hit, maybe a double. Twilio was a home run. The difference was not the technology. It was the shape. I lost that round once. The trust infrastructure we are building now starts as small blocks a developer can pick up and use in an afternoon.
Think of the first iPod. Anyone could pick one up and find a song in seconds. Then it rewarded you for using it more. Jakob Nielsen calls one way to build that shape progressive disclosure: show the few features most people need, and keep the rest a step away. Easy on the first day, better on the hundredth.
Design for the middle.
- Find your intermediatesLook at what your regular customers do in their second month, not their first hour. Those repeated tasks are your core.
- Make the common path fastestPut the three most repeated tasks one step away. Move everything else back a layer.
- Break the monolithList what your product does. Ask whether a customer could take one piece alone. If not, you have one path.
- Test day one and day one hundredA good design passes both. Easy to start, and better the more you use it.
Quick answers.
Who should a product be designed for, beginners or experts?
Rob Frasca says neither comes first. Most customers, most of the time, are intermediates: past the first day and nowhere near expert. He learned it at Lycos, where Lycos Clubs was built for power users and lost to the simpler Yahoo Clubs. He designs for intermediates first, following Alan Cooper’s idea of perpetual intermediates.
What does designing multiple pathways mean?
Rob Frasca’s principle is that no two customers move through a task the same way, so a product should offer more than one route to the same result. At Vivox the platform was monolithic, while Twilio offered the same functions as building blocks a developer could take one at a time. He calls the difference shape, not technology.
Sources.
- Rob Frasca, The Creator’s Journey (forthcoming), Chapter XI, Building What Lasts.
- Alan Cooper, The Inmates Are Running the Asylum (Sams, 1999). Wording checked against the passage as quoted by Jeff Atwood, “Defending Perpetual Intermediacy,” Coding Horror. Source
- Jakob Nielsen, “Progressive Disclosure,” Nielsen Norman Group, 2006. Source