The problem with power users
‘Power user’: the very term evokes a sense of authority and prowess. Your power users are the prodigious class of your user base with deep product knowledge; the most active, expressive and influential members of your product’s community.
In other words, you need power users to power-up your product. But you also need to tread carefully around the power user pedestal. For all the advantages they offer, power users can prove problematic for the direction of your product.
Power users want input. They want clout. They want to be in control of the software they use. While all this often leads to invaluable feedback, it can quickly become an onus in terms of usability and ongoing product development.
What makes for a power user?
The first problem with power users is a problem of definition. That is, there is no single, cohesive answer regarding who qualifies as a power user.
The most common understanding is that power users are your invested, long-term users who pack the most product expertise. You might find them as a top contributor in forums, providing ample feedback in the form of feature requests and bug reports, or signing up for betas.
Either way, a power user will know their way around the various corners of your product. Plus, they will be only too confident in communicating this knowledge and vocalising both their expectations and advocacy.
This is in broad accordance with the official dictionary definition of a power user: “A user of a computer system or program whose skills and expertise are more advanced than most other users.”
So, the general consensus surrounding power users is clear and uniform enough. Unfortunately, this consensus does not quite stand up to scrutiny.
Deconstructing the definition
The most serious issue with using a ‘power user’ label is that it fails to provide a fleshed-out persona. This should go without saying: simply slapping a shared label on a broad and likely diverse group of users without defining their motivations is a terrible idea.
The power user label acts as a catch-all for competent existing users. These users are in no way guaranteed (or even likely) to have the same goals and behaviours. How, then, do we narrow the requirements of the near-mythical power user role?
A common power user metric is active product usage. But daily active use does not necessarily translate into in-depth product expertise. The user might only use a small subset of features, to complete a specific or unexpected need.
Likewise, early adoption does not signify top-performance – if indeed top-performance can be quantified. To borrow the words of another: “How do you define productivity? What if the ‘top end users’ are only ‘top end’ because they have been using [your product] longer and are used to the idiosyncrasies of your system?”
So, power users present an instant problem upon the mere utterance of their label. Worse, this hasty label confers a value to the indeterminate ‘power user’; a currency that you later obligate yourself to honour.
Bending to the will of power users
This leads us to the next problem: power users are demanding. Their devotion has a flipside. Of all your users, power users are the most likely to push for inessential features; to request the extension of existing functionality to provide more options and control.
As Nick Bradbury argues, this can make power users the enemy of simplicity. The 1% want the extras and the fine-tuning power that the 99% simply do not care about. The desire to keep your power users happy can then lead to overengineered software, with feature bloating and a messy, complex interface that does not work for the average user.
Plus, if their requests have historically been acquiesced, power users can develop an undue sense of authority. The implementation of their product input lends them an oblique level of ownership. In the words of Ken Yarmosh: “[Power users] will always somehow feel entitled to dictate what a product should be even if they are not tied to the company or didn’t originate and build the idea themselves.”
This long-standing power play, then, can make it difficult to push back against power users. You might feel pressured to support legacy features that no longer match your goals and your mainstream user needs. Perhaps you spend time developing functionality for a single customer, or ruling out updates based on what “power users won’t like”.
Whichever angle you look at it, power users can be a complicating factor. For all their advocacy and useful insights, bending to the will of power users is often bad news for your product.
The personal interest problem
Now, it is important to emphasise that this is not a warning against listening to your loyal, active and skilled users. Engaged users are a fantastic source of information; a real-life knowledge database on your product in everyday application.
Rather, the danger lies in granting a special status to a vague and divergent user group. Your so-called “power users” may know your product, but they almost certainly do not know what is best for it. Using a product does not make you a usability consultant. Nor does it transfer in-depth market knowledge, or seasoned design and development skills.
Remember: your users want the features that suit their own personal use cases. They will not be approaching product planning from a strategic industry perspective, or considering what is best for the majority of users. Why would they? It is the software vendor’s job to cover these bases – not the job of the user.
So, active users are not objective judges. Their feedback is undoubtedly important, but it should not be the final word. To apply Don Norman’s quote about designers to power users: “The features they have come to love and prefer may not be understood or preferred by future customers.”
Reverse objectivity
The issue of objectivity also works in reverse. That is, software vendors often fail to look at their user base objectively, in favour of the power user.
Power users are the top trump card in a dimly defined user ranking system. When a user has a venerated rank – a literal power rating – it becomes that bit more difficult to weigh their words impartially. This begs the question: are your power users more deserving of attention than any other class of user?
Certainly, they may have a stronger understanding of a product if they have spent more time inside it. They may have access to more areas of your product, or have heightened account privileges. But this does not mean that power users have a demonstrably more useful class of insight to offer. Their insight is different, yes, but not necessarily more worthwhile than that of lower-level users.
For example, a power user will prove unhelpful when trying to ascertain your product’s ease of onboarding. They are not the best resource for seeing how casual users navigate your product and its features. Nor do power users exemplify the type of mainstream user that you typically need to develop your use cases against.
In other words: it is short-sighted to prioritise your product decisions based on power user deference. Failing to support a more unified product vision – one that considers your target users, the use cases you would like to support, and the future direction you want to head in – can only lead to poor decisions.
Power users are not the problem
Power users are not the problem. The purpose of this article is not to slight loyal and invested users. As a rule, these users are a blessing; the lifeblood of your product’s success. As such, you should not flippantly discard their views.
The real problem – and this is the takeaway – is lazy thinking. Loosely pigeon-holing groups of users and assigning an ill-considered value system to their import is not a great way to direct a product. It’s time to move past “power user” thinking, and get more specific about personas and use cases in UX design.
Please note: we originally published this article here.
