How to Avoid a Common Product Mistake Many Teams Make

Posted on Oct 14, 2013 | 57 comments

How to Avoid a Common Product Mistake Many Teams Make

I’ve been involved with technology product design in one form or another for nearly 25 years and seen one mistake consistently repeated.

Design for the Novice Configure of the Pro

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
  • etc.

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.

  • Silverborn

    HI Mark, Another great post. More powerful does not automatically equal more efficient. I witnessed two similar events in my career. In the first our organization transitioned from dedicated Nixdorf data entry stations to PC based data entry workstations. Keystrokes per Hour dropped by 30% for the experienced operators and NEVER recovered. Later the company moved the main application from Deskview (early competitor to MS Windows – no mouse) to a true Windows based mouse driven app with significant drops in productivity. Mice are slow. On another note the best two books I know of that teach your “design for the novice, configure for the Pro” philosophy are Designing the Obvious and Designing the Moment by Robert Hoekman, Jr. Example: Right Tools Right Time – “..our hope was to make the application, which was overloaded with features, appear very simple. By showing only, the relevant tools at the appropriate moment, each task would seem easy…” Then Robert walks the reader through the actual design process which I found really helpful.

  • CareerAddict

    This is an excellent article that I found very informative and to the point! It is important to receive live feedback on a potential creation before you fold out the creases and create a final product. As no two people are the same, it is difficult for one person or even a team to come up with an idea without a solid understanding of what exactly your target market is looking for. You need to ignore your professional, experienced opinion and allow yourself to think through the minds of your audience.

  • Chris Neumann

    My advice and practice these days is to take this one step further – it’s possible to mock up a nearly pixel perfect prototype using tools like Axure, and user test those. This can be done without any engineering, and you can iterate really quickly to get the product where it needs to be BEFORE spending expensive engineering time building. This is actually my advice to VCs, CEOs and VPs of product – just ask for a user testing video of the design passing before you’ll approve development. Anyone can see if something passes user testing by watching a short video, and it keeps the product team honest.

  • Vincente

    It should be “couldn’t care less”.

  • jhon doe

    good article

  • Sofia Fenichell

    Great article. Design FOR your Mom is a solid approach. But an even better one is a Mom (somewhat techie) designing for Mom’s. :-). Why settle for a second derivative on inspiration? Data gathering which I am massively a fan of still rests on interpretation and lacks an important ingredient – deep insight into the user psyche. Takes one to know one, as the saying goes. Real apps created by real people with love marks the beginning of a new era in app design.

  • Matthew Rayfield

    Thanks Mark! Gonna go hide a couple of features better now…