Unit of 1 - Do Your Features Support Your User's Goals?

eferlazzo writes "Sprez News - http://www.sprez.com
November 2001, Number 3

Last month I ended with:
So, what is the moral to the story? Add usability requirements to MRDs. Make usability a requirement and have designers, programmers, and writers work together to create software that not only meets the functional goals, but allows users to get their jobs done without fighting the software.

What do I mean by usability? I mean: “Does your product help your users accomplish their goals or hinder them?” Are they using your product because there’s no alternative or because it makes their job easier? Does it make them feel stupid while they try to figure out what to do or are they able to concentrate on getting their job done and “forget” about the software?

To quote from Alan Cooper’s “The Inmates are Running the Asylum”: “Most software vendors don’t know how to make their programs easy to use, but they sure know how to add features, so that is what they do.” As requirements documents are created, feature lists are bandied about, prioritized, added to, deleted from, reorganized, and redefined. Finally, everyone agrees “These are the features that will be added in version x.” Whoops! While you’ve been having your meetings, the calendar has changed and you now have months rather than quarters to implement, document, test, and deliver that list of features.

And let’s look at that list:

· Are these new functions things the user needs and wants or merely things that get added to your long feature list so that you look good in those checkbox feature comparisons?

· How many of the features offer some slick thing (that the programmers want to program because it’s fun or easy) that the user will never miss if it’s left out and will in fact complicate the design by being included?

· Does the schedule force the new features to be “bolted on” so that they are inherently difficult to find, clumsy to use, and typically built on a poor base that started life as a prototype?

Alternatively,

· Are the target users and their goals clearly defined in the document? You may have multiple types of users. Each needs to be defined.

· Are the new features directly tied to user goals?

· Does the requirements document include a description of how the user will use the software to complete a task?

· Does your schedule plan for designing these features prior to coding?

· Does it define what documentation is useful for your target audience?

· Does it demand a defined quantifiable level of robustness?

Your requirements document needs to focus on the user’s goals. They should not be marketing’s list of features “we’ve got to have” because the competition has these features. They should not be a list of things the programmers think ought to be included “because we can add those things for very little cost.” Feature bloat does not benefit the user.

If the feature is not required and desired by the user, it doesn’t belong on the list. If you can’t pinpoint a user’s goal that is being addressed by a feature, strike it out.

Having the appropriate targets in your functionality sights is critical. It won’t matter how slick your user interface is or how colorful your icons are if you are building the wrong software product!.

Ellen Ferlazzo

http://www.sprez.com
Copyright (c) 2001 Ellen Ferlazzo - All rights reserved.
To subscribe, send an email to SprezNews-subscribe@topica.com. "

Main Menu

Who's Online

Do Your Features Support Your User's Goals?

Related Links

Article Rating

Options