“Features” are simply the "things we can do" with a given piece of software. Component design and production software now possesses an overwhelming number of them; so many in fact that rather than being excited about new ones, many software users carry around a sense of permanent guilt - fueled by that gnawing feeling that they only know about a fraction of what the software can do. New releases just add fuel to the fire.

It's fair to say that as a software community we haven't figured out yet the best way to keep up to speed on all the things that the software we use can do. Some form of continuing education is no doubt needed. The suppliers, still in transition from an era where most of the training needs were for new users, have created a lot of training content but have not figured out the best way to package that content so it is easily digestible. Software users on the other hand frequently pay lip service to learning more about the software, but when opportunities are presented, many frequently don't take the time to take advantage of those opportunities. Sounds like a good subject for a future article.

Back the features themselves. Here is a suggested method for evaluating them.

Utilitarian

A feature usually can be classified either as "I can use that," or "I have no use for that." If a feature appears to have no useful value to you, it's a good idea to ask the person showing you the feature or a representative of the supplier, "Can you think of the way that this feature might be useful to me?" This is a good double check, to make sure the feature has no practical value to you. Asking this question also tests the recipient -- their answer will demonstrate how well they understand what the feature does.

Implementation

Elegant – The feature is surprisingly easy to use. It requires no instruction, except on the finer points.

Okay - The feature is certainly usable, although there are obvious things that could've been done better.

Lacking - Perhaps the supplier had the best of intentions, but the implementation fails to hit the mark. Significant desirable functionality is missing, and/or the user interface is confusing or awkward.

Accessibility of Features

Recently I’ve realized how important this is to the true value of a feature. Evaluating the customizability of a feature is often overlooked because we generally assume when a feature is introduced that anyone will be able to use it - and customize it. It's pretty obvious that a feature is much more valuable if I can customize it, vs. having to call someone and ask them to do it for me.

Grade A - Any sharp, computer savvy user can make a feature do what he wants. Many times This is dependent on the elegance of the implementation of the feature. Did the software team really spend a lot of time thinking about how the user would configure the feature? If they did, the feature usually ends up with an “A” in this evaluation.

Grade B - Many, if not all, technical support representatives can customize the feature. Customization can usually be implemented within a day. Many powerful features such as the batch cutting routines require a considerable amount of knowledge and experience to implement them quickly. As long as the technician is readily available, these skilled at the listening the needs, and is able to turn around the request quickly, the feature will be readily embraced.

Grade C - A small number of technical support representatives can customize the feature. The feature is either so complex, so new, or so poorly implemented that only a few technical support representatives have mastered it. Reaching the right person is usually the biggest difficulty. Turnaround time to customize the feature is usually measured in days.

Grade D - Any customization must be done by a programmer. The customization is treated internally as a programming project, with all the delay in bureaucracy that that entails. The user may need to wait weeks or months in order to get the customization. The feature ultimately gets an “F” in this evaluation if, from a practical standpoint, the user can't get the customization no matter how long he waits.

In evaluating any feature make sure you think about how it’s customized. Some features appear to be very exciting, opening up rich new areas of functionality. For each of these features it's worth exploring the question, "Who does the customization?" The answer may have a tremendous impact on the usability of the feature. 

1 Comment