Why You Must Design Products for the Novice
I've been involved with technology product design in one form or another for nearly 25 years. The single biggest mistake most product teams make is building technology for what they believe the user would want, rather than what the actual end-user needs.
From the experience in my earliest days of designing products for Windows and OS2 machines in the early 1990s, I developed a product philosophy: "Design for the novice, configure for the pro."
Most technologists design for themselves and then test with uncorrelated user groups only months after product launch, if ever. If you've never sat through real user testing, where users are given simple tasks to complete with little to no instructions on how to complete said tasks, you will be shocked when you see what you assume are the simplest set of tasks create the most difficult user-experiences.
I learned the hard way.
When computers moved from "green screens" to Windows we--the educated, young, technophiles--easily grasped the concept. It was hard to imagine customer service reps who had learned every keystroke short-cut by heart on a green screen and weren't eager to embrace the obvious future. We worked evenings and weekends getting a system read for public utility employees to be able to move into the future, with more power on their desktops than the dumb terminals they were used to.
The earliest user testing proved disastrous. The CSRs wanted nothing to do with drag-and-drop, point-and-click mouse commands. Computers were a necessary evil to getting their jobs done, and frankly what they valued more than anything was maximizing their hands on the keyboard (versus lifting one to grab a mouse) and processing orders efficiently (versus having more options, more power, more choices).
We live in a world of choices, and yet paradoxically as humans we generally want fewer choices. We want less complexity.
Think about your experience at a restaurant with too many options. The owner thinks they are giving you the ability to have anything you want, yet you are thinking, "Oy vey, can't you just give me a few well-curated options?" The less you frequent the restaurant the more this is true. You're not a master of what's on the menu and you don't want to invest the time to parse through all of its complexities. So you turn to the waiter and say, "What do you recommend?" Or your order from the specials.
Yet the restaurant owners, chefs, and waiters know every item on the menu by heart and wonder, "What's the big deal? Just choose what you like!"
Perhaps this could be a metaphor to remind you that the kitchen always finds it easy to know what's on the menu, while the casual, infrequent designer could care less. They came in just to eat the best you offer from a limited menu so they can enjoy themselves--not stress out--and get back to their lives.
Bad design was further reinforced through more than a decade of building apps in a Windows-era where we technologists were trained by the ever-expanding menu options in every Microsoft product. We all created mini Cheesecake Factories.
Design for the novice, configure for the pro.
My philosophy is simple: You design your product for the non-technologist, for the "norm."
Give people fewer options, fewer choices to make. Give them the bare essentials. Design products for your mom.
When you look at the data you'll find out the overwhelming-majority of your users come to your application infrequently and so you can't assume they can easily orient themselves. If they can't, they won't return.
I know you want to build really powerful features into your product. You want to build in the capabilities that you would want. And frankly after launch you'll get a laundry list of all the things your power-users tell you needs to be in your product to get the job done.
But here's the thing: power users will always find the features they need in your product even if they're hidden away. Give them a configure button somewhere. From there, give them options to soup up the product and add the complexity that goes with newfound power. But, make sure you keep it hidden. Make sure the novice can't stumble across it and get confused.
But, don't take my word for it. Conduct usability testing and make sure to include users not from your ordinary circle of friends or similar cohort. What you assumed was "novice functionality" will likely be too hard.
We built our product at Koral in 2005 with this design philosophy in mind. After we were acquired by Salesforce, they asked us to do proper usability testing with well-designed tasks to complete. We turned on a camera to record the sessions and reviewed the basics: upload a file to our system, create a new folder, move your file to the new folder, send your file to friends, etc.
It was simply mind boggling how what we assumed were intuitive, simple, no-brainer tasks were not well-understood by basic users. Unless we were only building our product for San Francisco-based techies, we were going to struggle to scale.
I have worked with teams who fully embraced the user testing espoused in the Lean Startup movement and they often build much better products by watching feedback earlier in the design cycle.
So, when you're doing your next product review make sure to question all of your assumptions. When you're adding more menu options, ask yourself whether you should leave stuff out. Remember that often less is more.
Don't build for yourself or your friends who use your product and say, "Wouldn't it be nice if you could just…."
And certainly don't build for your VC. They often have little or no design experience.
Sure, your friends and VCs are smart so I'm not saying don't take input.
I'm simply saying, design for the novice. And no matter how often I recommend this for teams with whom I work, I still always hear the feedback, "Yeah, but, we just need to…." as an excuse to add more functionality back.
Hit the user testing. Find out for sure.
In a mobile world I'm sure you know that this is even more important. People are opting for apps with less functionality and easy adoption.
This article originally appeared on Mark Suster's blog, Both Sides of the Table