January 7, 2013
Power users are used to pain. The pain I’m describing comes in the form of extra clicks, longer load times, or overwhelming screens filled with options. They forgive in return for function. They want to build complex search queries, customize work flows, export data for further analysis, and otherwise get deep into the nuts and bolts of things. They represent a very small portion of users, and in our case — the enterprise SaaS space — an even smaller portion.
For the pain they’re willing to endure, they are critical to the success of any app. They will derive tremendous value if you are willing to accommodate their needs. They will be early adopters, quick to recommend, a breeze to support and eager to help you improve your app. They are often involved in the sales process and can be the number one reason for getting a sale so long as you can show how they can have their way with your system. Don’t get sucked into the trap of ‘if I design for power users, I’ll get more sales.‘ This may be true in the short term, but in the SaaS business, the true value of a customer comes over their lifetime of using your application which means you need to keep your users on your app.
By the masses, I mean the huge glut of users that just want to get in, do the thing they came to do, and get out. They have no desire explore, to push the limits of the app, or otherwise spend more time than they need clicking, typing or tapping.
The web design community is filled with User Centered Design resources around building Personas, Story Boards, User Profiles, User Role Maps and more. All of these resources are critical to getting to a simple principal when designing for your average user: Hide all the crap they don’t need to use daily.
Knowing what crap to hide comes down to understanding your users and the context in which they’re working. In my case, our flagship product was a reimagining of an aging client-server app with heaps of legacy data and users offering much of the necessary data to help understand the user behavior. From this knowledge, we were able to simplify the experience of typically complicated processes such as applying filters when searching or reporting on data.
Within each report or search context, we display the most frequently used filters immediately, and tucked all other filter options away, so they were available with an additional click if needed. This dramatically improved our typical users perception of ease-of-use and helped to eliminate noise on each page.
So in this example, your power users pay a tax in the form of an extra click. This is OK, an even expected by most power users. So long as the feature exists, even if cumbersome, you’ve made their day, all while simplifying things for the masses. As someone who loves simple apps, it’s tempting to design ONLY for the masses, but this can be a huge mistake in the enterprise app space as your power user can often be the champion, leading the charge to ensure your app is successful. A careful balance is required to ensure your power users are getting their fix, and everybody else isn’t ready to stab their eyes out. Get this balance wrong, and you could have a mutiny on your hands.
It’s not uncommon for enterprise apps to fail. By fail I mean that the majority of users give up on it and go back to however they did things before. This is almost always because the majority of users view the system or workflows as too complicated and more time consuming than old methods. These systems can often be designed for, and sold to power users, then mandated upon the masses. Your application can easily fail if you don’t ‘win over’ the masses, and because the subscription model of SaaS provides a low barrier to entry and exit, it’s even easier for a customer to cancel their subscription and regress to old methods or adopt a competitor.
Here’s a great example from an application we use internally. This is a reasonably popular financial and CRM app that we’ve used for a year. Nothing in this app is designed for the typical user, in fact, it’s like every feature ever requested by a customer or prospect has been dumped into the system. Take a look at this dashboard chart widget for monitoring Closed Cases by Support Rep – pretty great right?
Obviously with any sort of chart like this you want to filter on a Date Range most of the time. It’s nice that they’ve provided that Date Range filter at the top, but when I click that I’m confronted with 175 options! Not only are there 175 options, but many of them wouldn’t even apply to this type of chart, such as a filter of ’5 Days from Now!’ Hell yeah, I’m travelling to the future to see that you won’t be closing any cases!
Now I can tell that these date range filters are a part of some reused logic from their financial application functions, but still, do you need to see 175 options? Of course not. Cut this down to 5 of the most common, then force the user to expose the rest of the options when needed.
In my case, all I wanted was a very common filter, the month up to today, or ‘Month to Date’ as many sane people might call it. This took me a few minutes searching through this list and coming up empty. Then I resorted to CTRL+F in my browser, and searching for the term ‘Month’ then scanning those 37 options for a likely candidate. That’s some serious power user shit right there and exposing every user to this tax is completely wrong. As a power user, I can cope, but when I wear my typical user hat, I’m rallying for mutiny. In the end, they named it ‘This Month to Date’, sorted alphabetically under the letter ‘T’ — of course!
© 2014 drawtheweb | Theme by Eleven Themes