Optimizing for power users and edge cases is the easy part
When designing a product — be it 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 wiz-bang 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 Window XP SP1 under a full moon. While those are fun Rubix-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 — to say “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 very skewed perspective of your user base, mainly when you use it to evaluate 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 the need for 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, and thus, through pure self-selection, most problems 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, feature requests should be evaluated through the lens of “what would benefit 80% of users?” — the silent majority, to borrow a phrase from politics. I suspect, for most projects, the exact opposite is sure, 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. If a 20 %-er requests a feature that isn’t going to be used by the other 80%, there’s no harm in just making it a non-default option, right?
We have a motto at GitHub, part of the GitHub Zen, that “anything added dilutes everything else.” In reality, there is always a non-zero cost to adding that extra option. Most immediately, it’s the time you spend building feature A instead of building feature B. Beyond that, it’s the cognitive burden you’ve just added to each user’s onboarding experience as they try to understand how to use the thing you’ve added (and if they should). In the long run, it’s much more than maintenance. Complexity begets complexity, meaning each edge case you account for today creates many more.
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 to 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 to do it well, not to try to do everything, but to do it 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, forego 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 for the majority of out-of-box experience. Challenge yourself. Learn to decide.
Conclusion
The real challenge for any product lies in genuinely nailing the out-of-box experience for 80% of users. Just because something’s easy to implement doesn’t mean that you necessarily should. Every time you add a toggle, dropdown, or text box, you’re pushing complexity on your users.
If you enjoyed this post, you might also enjoy:
- Removing a feature is a feature
- How to make a product great
- Twelve tips for growing communities around your open source project
- Why open source
- Five best practices in open source: external engagement
- 15 rules for communicating at GitHub
- Everything an open source maintainer might need to know about open source licensing
- Twelve things a product manager does
- 19 reasons why technologists don't want to work at your government agency
- How not to prioritize a feature
- Why you probably shouldn't add a CLA to your open source project
Ben Balter is the Director of Hubber Enablement within the Office of the COO at GitHub, the world’s largest software development platform, ensuring all Hubbers can do their best (remote) work. Previously, he served as the Director of Technical Business Operations, and as Chief of Staff for Security, he managed the office of the Chief Security Officer, improving overall business effectiveness of the Security organization through portfolio management, strategy, planning, culture, and values. As a Staff Technical Program manager for Enterprise and Compliance, Ben managed GitHub’s on-premises and SaaS enterprise offerings, and as the Senior Product Manager overseeing the platform’s Trust and Safety efforts, Ben shipped more than 500 features in support of community management, privacy, compliance, content moderation, product security, platform health, and open source workflows to ensure the GitHub community and platform remained safe, secure, and welcoming for all software developers. Before joining GitHub’s Product team, Ben served as GitHub’s Government Evangelist, leading the efforts to encourage more than 2,000 government organizations across 75 countries to adopt open source philosophies for code, data, and policy development. More about the author →
This page is open source. Please help improve it.
Edit