Pareto Principle

…or the 80-20 rule as it is also known. I am not fully convinced that it holds true; that 80% of your profits come from 20% of your clients, that 80% of the work is done by 20% of the staff, and that 80% of the peas come from just 20% of the pods. But when designing software, I think you need to keep the Pareto principle in mind.

As we add features to our product, we usually sit down and have a meeting about how to create the UI to enable a user to accomplish some task. As we wireframe the UI, people around the table will come up with additional ideas, and point out weaknesses in the design. But quite often, the longest discussions are about what I call “fringe use”. The reality is that people tend to imagine that they are going to use a lot more functionality than they actually do. Since the feature is not in the product, we really don’t know if they are going to use it, and there really isn’t any scientific way of knowing if people will actually use a function. Merely Asking people simply doesn’t work, and we can’t really do A/B testing on software such as ours.

We might not spend 80% of our time discussing and designing UIs for the 20% (or less) that will actually use the feature, but we certainly spend a lot more time designing for the minority, than the expected revenue from these border cases seems to justify.

While the 20% might be getting a good deal, there are more serious consequences. The 80% that really don’t care about the 20%’ers special needs, are getting a shittier deal. Time is a limited resource, and every minute we spend on fringe, is a minute stolen from normal users experience. At times it also means that the interface for Mr. Normal becomes cluttered with a lot of irrelevant options. More options means that the UI is more taxing on the old brain.

I think we need to get back to spending 80% of the design time on the 80% of the users. Am I wrong?


Author: prescienta

Prescientas ruler

2 thoughts on “Pareto Principle”

  1. Those fringe features are often deciding factors for particular market segments or major customers.

    Take something like dynamically locking out PTZ control by an admin. 90% don’t care and will never need this but a handful of mega customers will see this as a critical differentiator.

  2. True, and sometimes you just have to leave that customer to someone else, and instead focus on your own strengths instead of trying to make a sale to everyone that enters your shop (didn’t we discuss this type of customer-promiscuity before?)

    Now, PTZ lockout is a good example of something that is not used by a lot of customers, yet I don’t really consider it fringe, so perhaps I should be more descriptive in what I mean by “fringe”; Let’s say that we are discussing the implementation of the PTZ lockout – does it lock out ALL users (i.e. granting the Admin exclusive rights to PTZ controls). Does it lock out ONE camera, a group of cameras or all cameras. How long does the admin have exclusivity on the PTZ? What if there are multiple users with admin rights and so on.

    So, usually, the request is “PTZ lockout”, but then when you start designing how that should work, you foul up the (useful) feature by adding embellishments and functionality that are only ever used by a small subset of users. Usually this happens when you ask the customers to design the UI for you – you end up with the car that Homer designs in the “Oh Brother, where art thou” episode of the Simpsons.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s