Once You’ve Solved for the Novice, You Need to Handle the Pro

Posted on Nov 23, 2010 | 22 comments


Everybody has some portion of their life that is repetitive.  For these cases we want software that is optimized for massive iteration.  Yet often modern software is only optimized for the novice under the mantra of “simplicity.”I recently wrote a post about design simplicity where I encouraged technology design teams to think about “designing for the novice, configuring for the pro” users.  I wrote this post because I feel that too many products let features creep sink into the design under the guise of making the product more powerful but in turn they make their products less useful for the majority of users (who remain infrequent visitors and novices).

There is an error that I often see made on the other end of the spectrum.  Designing for simplicity doesn’t relieve you of the requirement to meet the needs of the power user.  These are the people, after all, who spend significant amounts of time using your product.

I have worked with several product teams over the years who have designed functionality that works really well for minimal usage – say where you do the task once or twice per day.  But there are many features that need to be used by a small portion of the user base in a super repetitive way.  To these power users often the initial use case is totally unusable.

So the opposite problem is when you over optimize a power feature for solely the novice and it becomes unusable for an iterative process (usually performed by a power user).  Let me give you an example.

At my first startup, we built a feature for creating project tasks.  We all know a thing or two about project management so they had a pretty good feel what they wanted to build.  They built in a bunch of really nice features like making the task-list embeddable in meeting notes so that you could show your output of a meeting including all of the tasks generated and if it was a “standing” meeting then it would print a list of tasks not yet completed by the next meeting.  It had the usual stuff like priorities, assignments, work effort level, etc.

And it worked brilliantly.  With one exception.  Our system was used on large scale engineering projects who had weekly or monthly meetings.  Each meeting generated hundreds of action items to be followed up on.  And it was usually one person from the meeting’s responsibility to input all of the actions into the system.  The best format for this person would have been a spreadsheet like input screen because 50 actions at a time might relate to one person or one company.  50 actions might be of a certain “type” and there may be 200 actions overall.

Our system only allowed you to create one action at a time so you had to go through an iterative process of create task, fill in details, assign task, save and then repeat.  Pretty dumb of us.

Ultimately we left the core functionality as it was.  We then added a small link that let you “create a major to-do list” or some similar wording.  That would send a more advanced user into a spreadsheet-like input screen.

I’ve seen this “error of iteration” occur many times in software designs.  One example is Quora.  I spoke in the design simplicity post about how it’s one of my favorite new products from a UX (and functionality!) perspective.  But they’re missing the design iteration concept.  They publish the “3 notifications” at a time in the top center of the screen.

This is great for the novice.  But for me it has become unusable.  For example, some days I’ll get 20-30 new followers.  Each time I need to open “items related to you” tab to see who these people are and choose which to follow.  When I click on “follow” one person the whole fracking thing closes and makes me do it all over again.  Sigh.

I encourage all product teams to ask to speak to the customer who would use your product repetitive, all day long and understand how they work.  While it might be an edge case, it is an important one.  Your “power users” will be either your most vocal supporters or the biggest pains in your arse.

  • Dave W Baldwin

    Another good post Mark. Wouldn't the better design minimize labor performed by both types of user? IMO this is how you develop stickyness and greater product usage outward.

  • Nari Kannan

    Great Post! One of the greatest examples of good user experience design is RedBox. They have integrated the Kiosk, emails and online seamlessly and meaningfully without anything that makes you think – why did they make me do that? They had me at the first screen on the Kiosk. Did not ask me to log in, username, password, forgot password, nothing! I am there to either Rent a Movie or Return a Movie. Those are the only two options right on the first screen. They figure out the rest as wel go along. That's what should be the design approach even when you are adding complex features. Complex features should be lurking behind the scenes while the simplest ones are front and center. Then if you outgrow simple features you can explore complex ones and they should be sort of hidden. That will be good product design!

  • http://naamanetworks.com/ David Bloom

    We expect to have several use cases for our core product and so are building (or trying to build) a modular system. Generic core functionality with additional elements that can be swapped in and out depending on the deployment. We are mostly focused on enterprise sales so the modular approach should help us more easily customize (and up-sell), and test without touching all of our clients.

    This is not the same as layering in power user functionality as you describe. Not sure whether we are making our lives easier or harder. Any experience from the BST gang?

  • http://twitter.com/mikeschinkel Mike Schinkel

    I'm really glad you posted this.

    “Simplicity” has become a mantra of so many people that I frequently see it used as rationale for ignoring the legitimate needs of customers. The companies that promote this the most and get away with it are those with cult following: Apple and 37 Signals are two really clear examples both of which are guilty of making some customer's lives hell because of their mantra of simplicity and because the fringe of their cult following gives them cover.

    For example, my Human Factors in Software professor in college pointed out (in 1984, ironically) that the Mac failed in human factors because it lacked “transitionality.” (I blogged about transitionality in 2004: http://mikeschinkel.com/blog/developmenttoolsneedtransitionality/) Fast forward to today and the Mac still fails significantly in transitionality.

    The Mac is really great for beginning users, it's really great for creatives who live with a pointer, and it's really great for hardcore Unix geeks who live with the keyboard, but it is absolutely awful for power GUI users because you can't learn the advanced features by mastering the beginning features. And to add insult to injury it typically requires 2x to 10x mouse clicks to get something done when compared to Windows.

    And before I get attacked by the faithful, I'm writing this comment on a MacBook Pro that has been my main computer for 1.5 years now. Frankly I write this comment not to criticize but in the insane hope that maybe Apple will eventually listen because what's really sad is that 90% of the issues could be resolved w/o ever affecting the beginning users or the Unix geeks. But because so many people beat the “simplicity” drum, Apple has all the cover it needs to continue ignoring the power GUI user segment of the market.

    And I also write in hope people hear that “simplicity” should be in how to appears, not in what it's capable of.

  • http://yourplace.com Brian Wilson

    Exactly Nari – Redbox is a perfect example of doing one or two things best in class. I think they have the advantage of being a kiosk which puts them in the mindset of being single task oriented.

    It is kind of like designing for an app. There is less space and interface controls, so apps are by default created more simply and focused which makes them a better experience than many websites where there are so many other cool ways to do things which leads to this feature creep problem.

    I have a problem with this personally so it takes me several rounds of “cutting” to stay disciplined.

  • http://bothsidesofthetable.com msuster

    Not 100% sure what you mean. But the “minimum effort” for a power user with iterative processes is very different than the “minimum effort” for the novice. That's the main point.

  • http://bothsidesofthetable.com msuster

    modular design – especially for enterprise apps – is critical. Each enterprise then decides which features to deploy.

    This is slightly different, though, than having a feature that can be optimized in one use case for 95% of the users and in a different way for the 5%.

  • Dave W Baldwin

    Sorry, I was typing too fast. If your UI is right in the first place, then both the novice and power user should be happy. It is a matter of the unit being able to the needs of the power which will then do more than enough for the novice.

  • http://twitter.com/sarahlawfull Sarah Lawfull

    “I encourage all product teams to ask to speak to the customer who would use your product repetitive, all day long and understand how they work.”

    ABSOLUTELY Mark, and I find the use of Personas in context priceless, not only does it capture your key users but it also stops the self-referential you witness between developers and even product owners. We are using them to drive all our UX at Caplin. ( for more info: http://blog.caplin.com/2010/08/11/whats-in-a-persona/)

  • http://bothsidesofthetable.com msuster

    Nice! From the person who led our tech team when the feature I discussed was implemented! I wonder if you remember this specific instance. It always bugged me because I felt I should have known better and gotten more involved in the product designs before the coding. And before it was too late.

  • http://twitter.com/sarahlawfull Sarah Lawfull

    It's only through experience, reflection and the passion to be better than the day before we grow. (I remember the product but wasn't actively involved in the design)

    Yes I am sure we would all do things so differently now but I wouldn't change a minute I had back then, it was the best experience of my life. Thank you.

  • http://bothsidesofthetable.com msuster

    Awww. Thank you. I feel the same. And I often acknowledge the many personal mistakes I made. It's where I learned the most.

  • Troy D

    I don't think that's what he's saying. He's saying that the pro will need some features that the novice doesn't need, and you need to design where the novice can have a good experience doing the basic tasks, and the pro can still get his stuff done, without his features confusing the novice.

    http://tech.rawsignal.com

  • http://twitter.com/cfarm54 cfarm

    It goes without saying that there's a balance between simplicity and a larger feature set. I think one of the better ways to implement a larger feature set (if you need one) is to make a UI that is friendly enough to intuitively walk any user through the learning curve required.

    An example of this might be facebook. The first time it was released to the public, I could imagine the vast majority of users were flooded by a sea of questions pertaining to what facebook exactly was. The trick was to make the UI simple enough to self-teach anyone about the purpose fb had in mind.

  • http://twitter.com/OlivierRosset Olivier Rosset

    Great article thanx ! working now on a audiofile publishing platform, and as the market needs are growing very fast, we found that taking care of the professional needs first are often the novice service needs tomorow. also its good to have the pros using services to demo to the novices how/what they should do.

  • http://columbusholdinggroup.com Mark Birch

    That just sounds like poor UX design in your Quora reference.

    Anyway, having come from enterprise software, I would err on the side of simplicity even with pro use cases. I have seen the feature creep issue time and time again. It is why no enterprise software companies can successfully build market share in the SMB space, the software is just too complicated.

    You need to figure out who your customers are and what they really need. We did not understand that at Siebel and it killed the product and ultimately the company. We tried to be all things to all people. The bloatware that developed was unsustainable and a faster and easier option came along i.e. Salesforce.com to knock off Siebel as CRM king.

    If you realize you have two or three distinct user groups through the customer discovery/validation process, then decide whether you can support and sustain each of those groups. Not every group is worth pursuing if it pulls you away from your vision and the market you are seeking. I tend to be careful of simply mistaking the most vocal users and actual “pro” users. The former tend to be fickle and the latter tend to reflect more of your core market.

  • cynthia

    Have you seen examples where features have been optimized in diff. ways for diff. users?

  • ph0ust

    Now if only they can get “sort by date” working properly…

  • http://twitter.com/ScottAllen Scott Allen

    The problem that occurs all too often is that software companies get their own idea of what a “pro” user “should” be able to do, rather than talking to actual users about what THEY want. Twitter and LinkedIn are perfect examples of this. There are things that legitimate power users want to be able to do, but the founders refuse to allow it in the name of spam prevention. Let the power users do their thing and people can report it if they're so inclined. It worked for craigslist and many others.

  • Dave W Baldwin

    Thanks for the link. Yeah, that is what he is saying…so if you have the multitasking platform that has the best interface, it is not a matter of producing two products, but doing the 'free' and the 'subscription'…you just have to have the better platform to begin with.

  • http://www.w2lessons.com Michael Woloszynowicz

    Alternatively you can take the 37 Signals approach and just say no to most advanced features, provided of course that you're not targeting the enterprise. Not saying this is the right approach but it seems to work for them (for now). I generally prefer your hybrid approach coupled with modularity, as simplicity for a novice can be seen as cumbersome for the expert.

  • HistoryInAction

    I posted about this on Quora to get some discussion going: http://www.quora.com/Craig-Montuori/Quora-product/Quora-for-Power-Users

    Solid observations! Definitely food for thought for my 'email reader for lawyers' startup, which mainly involves power users, but needs equal 'casual user' features for the higher ups who are less involved with the process.

    -Craig