History is filled with events that at the time seemed like footnotes but in hindsight revealed themselves as pivotal turning points. Such an event may have occurred Friday March 3rd, 2017. Buried in the comments section of a post on WPTavern a comment from WordPress co-creator and project lead Matt Mullenweg reads:
It might be time to retire 80/20 from the philosophy page, as it is seldom used as intended.
Below the surface of this short sentence lies a highly stressed fault line, and what Mullenweg seems to suggests is to deliberately trigger its release, causing a tectonic shift that will permanently change how WordPress is developed and as a consequence how content is published online.
For the record I do not know what Mullenweg thinks about the 80/20 rule beyond this single sentence. The following is my personal thoughts and reflections around the 80/20 rule. I am merely using his comment as a starting point for a discussion.
tl;dr: The 80/20 principle as applied in the context of current WordPress development is an ideal without a tether to reality. However much we say we develop the application for 80% of users, the reality is we know almost nothing about 99% of WordPress users. That means at best the rule is without consequence, at worst it is doing harm. The big question is how do we change our philosophy to solve this issue?
I have some thoughts, and I’d also like to hear yours. But first, a short primer:
What is the 80/20 rule, and why does it matter?
The 80/20 rule is a term you’ll hear a lot in business circles. It is called the Pareto Principle and goes as follows: “for many events, roughly 80% of the effects come from 20% of the causes” so for example “80% of your sales come from 20% of your clients.” This principle shows up everywhere. As an example Microsoft found that “fixing the top 20% of the most-reported bugs, 80% of the related errors and crashes in a given system would be eliminated.”
The Pareto Principle is also sometimes used in reverse, as is the case in the WordPress Philosophy (my highlighting):
“The rule of thumb is that the core should provide features that 80% or more of end users will actually appreciate and use. If the next version of WordPress comes with a feature that the majority of users immediately want to turn off, or think they’ll never use, then we’ve blown it. If we stick to the 80% principle then this should never happen.”
This version of the 80/20 principle is a good one, both from a development and a business standpoint: Build solutions that work for 80% of the user base, and let the remaining 20% find or build extensions to meet their needs.
As WordPress continues to grow in popularity and user base, changes made to the application and related services like the WordPress.org website are met with tighter scrutiny and critique. Many WordPress users are expressing a feeling of disconnect between themselves and the people who build the application, and changes are often criticized for being imposed in a “top-down” fashion without taking end-users into consideration. This is what the post on which Mullenweg left his comment was about. There are many reasons for this (most of which I will not get into here), including how the 80/20 principle is used when decisions are made.
For the 80/20 principle as described in the WordPress Philosophy to work, the design and development team must have a firm fact-based understanding of the entire user base so they can identify the needs and abilities of the 80% and build solutions for them. That in turn requires data. The problem for WordPress is that data does not exist. As a result, any decision made under the banner of the 80/20 principle is actually a decision made based on the educated guesses of the development team and their immediate circle of contributors. This is even stipulated in the WordPress Philosophy (my highlighting):
“while we consider it really important to listen and respond to those who post feedback and voice their opinions on forums, they only represent a tiny fraction of our end users. When making decisions on how to move forward with future versions of WordPress, we look to engage more of those users who are not so vocal online.”
When Mullenweg says the 80/20 principle “is seldom used as intended” I am fairly certain this is what he’s referring to. Put bluntly, we can’t say we’re building solutions for the 80% because we don’t have the data to back that claim.
The Fork in the Road
When Mullenweg suggests removing the 80/20 principle from the WordPress Philosophy page, I think he is really suggesting replacing the 80/20 principle with something more practically feasible that moves the project forward. Lacking any further details, I’ll extrapolate the two possible paths I think this move could lead us down: a Contributor-centric approach and a User-centric approach.
If we simply remove the 80/20 principle from the philosophy page, we will effectively end up where we are right now, with a Contributor-centric approach: WordPress is designed and developed by the people who contribute to the project, and user testing is done primarily on contributors and active community participants. This is already stipulated in the WordPress Philosophy:
“We do this (engage more of those users who are not so vocal online) by meeting and talking to users at WordCamps across the globe, this gives us a better balance of understanding and ultimately allows us to make better decisions for everyone moving forward.”
This Contributor-centric approach is common in open source communities, and has its origins in how open source projects come about: A small group of contributors build a solution for the contributors and anyone else interested. Even when the actual users outnumber the contributors, this dynamic remains because it’s what made the project successful.
It is important to understand the Contributor-centric approach is not based on a “we know what’s best for the user” attitude, rather “we know the application better than anyone, and we do what’s best for the application because we want it to grow and succeed.”
The overarching principle here is one of meritocracy: decisions are made by those who show up, and those who contribute the most have the most sway when decisions are made. This stems from the reality that open source contributors typically volunteer their time and are more likely to work on things they care deeply about. Allowing them to choose their own focus, and keeping a flat/no management structure is thought to ensure they have a continued vested interest in the project. In the background of all this there is also a real concern that limiting the autonomy of contributors may lead them to move on to other less restricted projects.
The Contributor-centric approach leaves itself open to critique that it is rooted in privilege: to have influence and “show up” requires availability of free time and a fairly high level of technical expertise, neither of which we can reasonably expect or demand from the average user. When the barrier to entry, or even constructive feedback, is high (as is the case with WordPress), the only voices heard are from the experts. The Contributor-centric approach solidifies this development model, and if that’s the path we choose to take, it needs to be explicitly stated.
If we either commit to the spirit of the 80/20 principle or replace it with a similar principle, we are adopting a User-centric approach. User-centered design is a well-established method of iterative design based on extensive user testing and data gathering. From Wikipedia:
“user-centered design tries to optimize the product around how users can, want, or need to use the product, rather than forcing the users to change their behavior to accommodate the product”
The User-centric approach is what most major software and service vendors use to develop their products. It typically involves large-scale quantitative data gathering through telemetry, surveys, and other statistical methods as well as qualitative user testing on individuals and groups. A common argument against the user-centric approach is that it’s costly and slow, but in my experience the major challenge with it is that it tends to cause cognitive dissonance in stakeholders: User research often concludes that what designers and developers think is the best solution is not what the end-user prefers. This sometimes leads back to the “we know what’s best for the user” argument which is why some development teams cycle back and forth between the two approaches.
Another common critique of the User-centric approach is that the user does not always know what they want or need, and maybe more importantly, they don’t know what’s possible. The extreme version of this argument is Steve Jobs’ famous quote “A lot of times, people don’t know what they want until you show it to them.”
The User-centric approach requires rigorous discipline and careful management to work: Research and data gathering has to be unbiased and statistically sound and significant. At the same time, too much research and data, or research and data that has little value, can cause stagnation and confusion. And to top it all off, the User-centric approach will result in contributors having to work on projects they are not passionate about or even disagree with simply because they are not building solutions for themselves but the end-users.
In many ways the User-centric approach is a walk across a tightrope: Success is only achieved with training, planning, focus, and constant corrections. For the WordPress community, this would be a whole new way of doing things requiring a radical shift in attitudes.
The Duty of Care
Before we can make a decision about where to go next, we need to consider our Duty of Care: When we add, augment, or remove a feature in a tool used by someone else, we have a duty of care to that person to ensure your actions do not negatively impact them. The Decisions, Not Options principle comes into play here. From the WordPress Philosophy:
“Every time you give a user an option, you are asking them to make a decision. When a user doesn’t care or understand the option this ultimately leads to frustration.”
On the surface, the duty of care outlined here is to protect the user from confusion and frustration. Deeper down, we find the duty of care when making a decision on behalf of the user. The reasonable expectation from a user is that the application (and by extension its designers and developers), makes decisions that are in the best interest of the user.
Which begs maybe the most important question:
How do we, the people who build WordPress, best meet our duty of care to the people who rely on WordPress in their personal lives, their communities, and their businesses?
Where do we go from here?
Whatever decision is made, it will cause a tectonic shift in how WordPress moves forward. That’s why every voice needs to be heard.
It is no secret that I land firmly on the side of the User-centric approach. From my experience user research is an integral part of any successful project, and the larger the user-base, the more important this research gets. I agree with Mullenweg that the 80/20 principle is not working, and I believe the solution is to realign the WordPress project to a more user-centric approach. This is not a quick and easy pivot, and it will require fundamental changes to how WordPress development is done on all levels. For one, we will need to gather large volumes of data on the existing user base and implement statistically sound methods for large-scale user testing of redesigns and new features. The first step in that process is to implement telemetry for the core application, a proposal that has already been shelved by Mullenweg.
Now you know what my answer is, but I’m just one of thousands of contributors, one of tens of thousands of active community participants, one of millions of WordPress users. I want to know what you think. Everyone who uses, interacts with, or contributes to WordPress has a stake in the project, and this is a decision that needs your voice. So, speak up and share your thoughts. I am listening, and I guarantee I’m not the only one.