Building Great Software: Solve For The 80/20 Case
Twice last week I was reminded that the key to building great software is to make it easy then provide depth.
It's incredibly tempting to expose a lot of advanced functionality. This is what Linux did and still does, what Drupal does (although in comparison with lots of other projects, it's better than most), and what a lot of open source projects do.
Building new features is fun. It's fun because if you're a feature junky, like I am, then you thrive on new functionality. It's fun until you spend a few hours trying to get what should be a simple feature to work. That's when you realize that you wish it would just work "out of the box" so that you could focus on what you really wanted the software to do.
If you're a software engineer, it's often more exciting to develop a new feature than to expose it to your potential users in an intuitive way. Building the user interface is detailed, painstaking work that takes hours of time for what appears to be relatively little benefit. In contrast, when you build a feature, you can immerse yourself in the development process and get what in some ways is the developer's equivalent of a "runner's high." Once you introduce users into the process, however, the process becomes reactive rather than proactive. You have to run trials on the users (usability studies), incorporate their feedback (by reacting to it), then re-run the usability studies, in a continuous and often painful cycle. If some part of the cycle slows down, you get the software equivalent of a traffic jam, which leads to frustration and a desire to go back to working on developing new features.
The best software solves for the 80/20 case. It exposes the 20% of functionality that 80% of users require. Once users become more advanced, or, for those users that are already advanced, it provides access to these more advanced features through "advanced" tabs, dialogs, pages, and so on.
Consider Blogger - a novice can get it up and running in minutes, while an expert can spend hours drilling down into the details and tricks of templates, posting, etc. This may be frustrating for the advanced user, but it's a real breakthrough for the average user. Since most of your internal users (even executives) are relatively advanced (simply by nature of using the software on a regular basis), your perception can become very out of line with the reality of the average user. You start to think your software is too simple and doesn't do enough, when in reality, the average user is still trying to figure out how to get it up and running.
It's also easy to compensate for user interface problems, to the point that you stop thinking about what you are doing to compensate. I watched this happen in real time this week when an executive I know and highly respect was giving a demo of a software package. In the middle of the demo, he alt-tabbed (in Windows) to another window to bring it to the forefront. He knew to do this without thinking... but the new user wouldn't. When I called him on it, he said, without thinking, "Oh... I just knew to do that." Then he thought about it for a second and turned to one of the company's senior engineers and said, "Hey, we should fix that!"
The solution is not only to watch new users trying to use your software or web site, but also to have new (but knowledgeable) users watch experienced users using the software. New users watching experienced users will provide an objective view into all the little bits of "compensation" that occur when experienced users use the software.
It's incredibly tempting to expose a lot of advanced functionality. This is what Linux did and still does, what Drupal does (although in comparison with lots of other projects, it's better than most), and what a lot of open source projects do.
Building new features is fun. It's fun because if you're a feature junky, like I am, then you thrive on new functionality. It's fun until you spend a few hours trying to get what should be a simple feature to work. That's when you realize that you wish it would just work "out of the box" so that you could focus on what you really wanted the software to do.
If you're a software engineer, it's often more exciting to develop a new feature than to expose it to your potential users in an intuitive way. Building the user interface is detailed, painstaking work that takes hours of time for what appears to be relatively little benefit. In contrast, when you build a feature, you can immerse yourself in the development process and get what in some ways is the developer's equivalent of a "runner's high." Once you introduce users into the process, however, the process becomes reactive rather than proactive. You have to run trials on the users (usability studies), incorporate their feedback (by reacting to it), then re-run the usability studies, in a continuous and often painful cycle. If some part of the cycle slows down, you get the software equivalent of a traffic jam, which leads to frustration and a desire to go back to working on developing new features.
The best software solves for the 80/20 case. It exposes the 20% of functionality that 80% of users require. Once users become more advanced, or, for those users that are already advanced, it provides access to these more advanced features through "advanced" tabs, dialogs, pages, and so on.
Consider Blogger - a novice can get it up and running in minutes, while an expert can spend hours drilling down into the details and tricks of templates, posting, etc. This may be frustrating for the advanced user, but it's a real breakthrough for the average user. Since most of your internal users (even executives) are relatively advanced (simply by nature of using the software on a regular basis), your perception can become very out of line with the reality of the average user. You start to think your software is too simple and doesn't do enough, when in reality, the average user is still trying to figure out how to get it up and running.
It's also easy to compensate for user interface problems, to the point that you stop thinking about what you are doing to compensate. I watched this happen in real time this week when an executive I know and highly respect was giving a demo of a software package. In the middle of the demo, he alt-tabbed (in Windows) to another window to bring it to the forefront. He knew to do this without thinking... but the new user wouldn't. When I called him on it, he said, without thinking, "Oh... I just knew to do that." Then he thought about it for a second and turned to one of the company's senior engineers and said, "Hey, we should fix that!"
The solution is not only to watch new users trying to use your software or web site, but also to have new (but knowledgeable) users watch experienced users using the software. New users watching experienced users will provide an objective view into all the little bits of "compensation" that occur when experienced users use the software.
2 Comments:
I would like to agree, but I wrestle with two points:
All too often, everyone needs a different 20%, so finding the right subset of plausible features is not at all easy.
Joel Spolsky http://www.joelonsoftware.com/articles/fog0000000020.html makes this point, but also some others, including: Moore's Law makes this generation's bloatware the next generation's core feature set; and time spent finding the optimum feature set or optimizing program size doesn't usually have any return on investment; the fewer the features, the less market differentiation (for example, there are about a zillion simple easy tools that compete with Blogger now).
I've been trying to come up with a compelling response to Spolsky for years ... can you?
Mike, thanks very much for your comment. I don't agree that the fewer the features, the less your differentation. Differentiation is not established on the basis of broad feature sets, it is established on the basis of one or two really great features. Great software products need something they can hang their hat on. Whenever I hear a pitch or a presentation that tells me about 50 really cool features, I always ask, what's the one killer feature that people will remember you for?
There are a zillion tools that compete with blogger, but blogger's differentiation was that they got one basic feature right (creating and publishing a blog), rather than a thousand little features right. There are lots of tools that are more feature-rich than blogger, but blogger still wins because of its sheer simplicity. I argue that simplicity and laser focus will always win out over diversity and breadth of features. That is why startups can still take on and beat big companies in races where the startup seems unlikley to win.
Post a Comment
<< Home