I’ve been involved with technology product design in one form or another for nearly 25 years and seen one mistake consistently repeated.
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 1990′s 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 how 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 and have 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 maximized 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 world of choice 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 and 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 have on 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 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 simply. You design your product for the non-technologist. The “Normal.”
Give people fewer options, fewer choices to make. Give them the bare essentials. Design products for your mom.
Know that when you look at the data you’ll find out the overwhelming majority of your users will 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.
Said 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.
And don’t take my word for it. Do actual 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 and we turned on a camera to record the sessions and review the basics.
- Upload a file to our system
- Create a new folder
- Move your file to the new folder
- Send your file to friends
It was simply mind boggling how what we assumed were intuitive, simple, no-brainer tasks were not well understood by basic users so 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.
And in a mobile world I’m sure you know that this is even more important. People are opting for apps with less functionality and more easily adopted.
(Cross-posted @ Both Sides of the Table)