Whether you’re building an open source project or a for-profit service, it’s all too easy to optimize for power users and edge cases. While the squeaky wheel may most often get the grease, that doesn’t necessarily mean it should. The real challenge for any product lies in genuinely nailing the out-of-box experience for 80% of users’ needs.
Solving fun problems
As a geek, it’s always going to be more fun to develop the new whizbang feature that will allow the app to integrate with whatever’s currently on the top of Hacker News or to design a single method that elegantly accounts for when your program is used at the South Pole by a user running Windows XP SP1 under a full moon. While those are fun Rubik’s-cube-style engineering challenges to tackle for those of us who build software, they do little to benefit most of the people who use the software we build.
As a project maintainer, it will always feel better to ship code and mark an issue resolved than to close yet another issue as wontfix, saying “no” to a beloved user or, worse, a potential contributor. For many, wasting already-written code is a cardinal sin. But your project’s issue tracker, pull request backlog, or support queue will present a skewed perspective of your user base, especially when you use it as your primary means of evaluating feature requests and user feedback.
The silent majority of users
Think about the type of user that’s going to take the time to open an issue: they’re either going to be power users that have already invested hours in your app and have grown to need additional functionality that extends the core use case, or new and potential users with unique circumstances that you didn’t originally intend to accommodate. In either case, opening an issue takes time, commitment to a cause, and specialized knowledge. Through pure self-selection, most issues are going to be opened by the extreme edges of your user base, not by the core of your users (or potential users, for that matter).
Instead of optimizing for the most vocal, evaluate feature requests through the lens of the silent majority (to borrow a phrase from politics): “what would benefit 80% of users?” I suspect, for most projects, the exact opposite is true, that 80% of feature requests come from just 20% of users (or as few as 1%). Combined with the fact that these requests often represent the “fun” problems, this 80/20 rule means that in many cases, absent your intervention, the majority of features implemented will provide little or no benefit to the majority of users.
| Technically simple | Technically complex | |
|---|---|---|
| Solution obvious | Feature creep | Edge cases |
| Solution unclear | Core use | Power users |
Anything added dilutes everything else
No product will satisfy 100% of user needs, although it’s tempting to try.
The WordPress community has a similar philosophy, “decisions not options*.” Every time you provide a user with an option, you’re asking them to make a decision, and those decisions quickly add up, especially when the user doesn’t care or doesn’t fully understand the implications. Ultimately, many of these decisions are technical or domain-specific decisions. As a project maintainer, as the subject-matter expert, you must absorb all that complexity on behalf of your users, not kick the decision down the line.
Settings are a crutch
Adding a setting is easy. Burying that setting in the endless clutter of an “advanced” tab is even easier. Making the right decision is hard. Decisions require you to get to the cause of the user’s needs. To figure out what they’re trying to solve, even if they may not fully know it. To think through the user experience. To decide the one thing you’re trying to do and do it well, rather than trying to do everything poorly.
One of my favorite features to add to a project is the one that removes two others. And for most users, that tough decision is just that, a software feature. The next time you’re faced with a tough decision, forgo the temptation to optimize for power users or, worse yet, to inch your project one step closer to the inside of an airplane cockpit. Optimize the out-of-box experience for the majority. Challenge yourself. Learn to decide.