4

Are there any guidelines for determining whether an audience type are "power users" and if their usage warrants more powerful features? For instance, could a user who orders products from a b2b application 5 times per week be considered a "power user" if the average order is 1 order per week?

1
  • Define 'power' for your users and define 'powerful' for your features and make sure that they match is probably the best guideline you can find. – Michael Lai Dec 21 '19 at 22:09
3

You are approaching the problem from the wrong side. If you try to find out which users can be stuck into a labelled category, you end up with categories mostly useless for UX.

The right thing to do is to find out how people interact with your site. If there is a strong difference between the way of interaction, or the user needs, you classify your users according to these differences. Starting from there, you can give convenient labels to your groups which help you communicate about them with other stakeholders.

For example, you could find out that people who have 3 orders in their ordering history are happy with a simple list view, while people with more than 15 orders have trouble finding a specific order in their history. Or that your straightforward billing system is good enough for most users, but that customers who bring in more than $xxx in revenue per year get personalized conditions from the sales team and the system is not equipped to deal with these creative pricing structures. Maybe even both is the case in the same system, and if it is, it is very likely that the second group (revenue over $xxx) overlaps with the first (many orders). In this case, it can make sense to call this group of people "power users", but you can also choose whatever other label is useful.

On the other hand, you can have useful classifications completely independent of any order volume considerations. Maybe you have the kind of customer who knows how much he can spend, but doesn't care about brands; this customer needs a way to compare similar items by price. Another kind of customer is brand loyal and needs to filter by brand. The third one cares about a technical spec of the product, and faced with a database of 100 000 types of paper, wants to filter out the CO2-neutral papers in thickness between 90 and 130 gm/m^2 ones and hates you for categorizing your shop by brand. None of these is more "power" than another one, but all of these require a different functionality.


There is a different separation which was a somewhat popular research topic in the early 90's academic research on usability. It is about the difference between people who create mental models when working with a computer and people who don't. This difference is noticeable in all other areas of life, but the consequences are very visible in computer usage. People who create a mental model intuitively know how to do what they want to do. People who don't either click around wildly, usually ending their task in frustrating failure, or follow a script (a step-by-step tutorial) they got from someone or developed in a long and painful trial-and-error process. They are helpless when faced with the tiniest deviation from the expected path. The first group is frequently called "power users" in the context of many applications.

There is rarely a need to make this distinction in practice. The second group (no mental model) is prevalent. Even people generally capable of making one just don't have the cognitive capacity or the motivation to do it for every piece of software they encounter. Besides, creating a mental model takes time, and at the beginning, the people creating the mental model (which is the fast track to becoming an expert) are still, well, beginners. These first encounters also happen to be the ones when a person decides whether to use your application more frequently. So, in practice, you design for the helpless people, by giving them a clear path to success with minimal intervention. The power users are generally happy with this too, because they don't have to squander much precious mental resources in learning the application. Just pay attention to not dumb it down so much that they can't do what they wanted to.

There is a place where the power users matter more. When you are writing software which is a tool for creation, you have many more experts who use it on a daily basis and have the time, motivation and capacity to learn it. For example, in a CAD system, you can assume that many of your users will be from the "mental model building" kind, and that they need a high degree of flexibility and also know what they are doing. It is quite a challenge to design this kind of software, because you want to make their job efficient without losing the beginners. But if you are writing a web shop, this is not what you have to worry about.

2

Power user is not a relational entity rather it is an absolute factor because it is completely based on the individual's mental mapping of your site and his rememberance and domain knowledge. It can be relational to you under factors of 'Average order' etc. This is wrong notion to decide power user. You can decide power user by having adabtable design. Example: user who knows (you assume he knows) a particular icon stands for the Action-A and if you find the bounce off (from server logs) is too high then introduce label to the icon and not just icon. User learns and forgets things over time. So the assumption of power user is variable with respect to time.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.