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.