We were all student drivers at one point. But no one stays a beginner indefinitely.
Almost no one becomes an expert driver either.
Most of us are competent drivers. Driving skill probably even follows a bell curve distribution, with most drivers being OK, some “bad”, some “good”, and very few experts or beginners. We’ll show in this post how to apply this pattern to software requirements and design.
Most users are competent users
When we’re designing software we need to keep in mind that most of our users will be competent – neither experts nor beginners. Alan Cooper’s studies tell us that user skill levels follow a bell curve. He talks about competent users as perpetual intermediates. Some users drop out of the bell curve when they stop using our software. The rare user becomes an expert. Most users only learn enough to get their real job done.
Most requirements are written for beginners and experts
On most teams, the bulk of the requirements are written for either beginner users or expert users. This is because marketing and engineering groups can have an overweighted influence on requirements prioritization. There are good reasons to design features for both of these groups of users, but if the bulk of our users are competent, shouldn’t we prioritize the bulk of our requirements to optimize on those users?
The case for beginners
There are two good reasons to optimize on beginner users. Software that is never used frequently (like TurboTax on the web) will always have beginner users. This post doesn’t apply to those applications. Ignoring the beginners will kill us too. If users are unable to learn quickly enough to get past the suck threshold, they will never become competent with our software, they will switch to another application.
The case for experts
As differentiated features are added we increase the likelihood that all users will use our software. Many applications attempt to differentiate by doing more. When our differentiated features represent more instead of better, we end up creating a more cluttered application. Eventually we reach the point that only experts can use our system. And experts may demand these additional features.
The not-so-good reasons for both
Cooper makes an interesting assertion in The Inmates are Running the Asylum, that marketing folks overwhelmingly represent beginner users, due to their primary interactions with people who haven’t bought the software yet. Marketing people are paid to think like non-users (non-owners, technically), to help convert these potential customers into customers. Cooper also points out that engineering teams push for (or fail to push back on) expert-style features. Our technical people are software experts – they understand how software works, and are not confused by how it might appear to work. They lack the genetic resistance that normal humans have to overly complex interfaces. It may not even be concious.
When we combine legitimate reasons for beginner-user features and expert-user features with over-promotion of those features by influential team members, we end up with undersupported competent users.
How to bring balance to our requirements
We use goal-driven development, and more precisely, well-designed personas to drive our prioritization decisions. We make sure that our personas represent all of our different users, and that the primary persona is a competent user. We validate that our highest priority requirements support of this competent user.
One thought on “Competent Users and Software Requirements”