What do you do if you have an mature suite of software products and a set of competitors matching you feature for feature? What do you do when trying to break into a crowded, established market with a new software product? How do you distinguish your product from the competition? What are the 'killer features' that will make your products stand out from the crowd? For example, how do you make a UML modeling tool, a HTML authoring tool, or a database report generation tool stand out from the sizeable list of commercial and open-source offerings? And how you keep it that way release after release?

Of course, the answer is very simple. You implement a continuous stream of new truly innovative features. However, the problem with that answer is just as obvious. While you might be able to identify one or two new truly innovative features, it is almost impossible to sustain that level innovation for any significant length of time.

Industry analysts continually point to new functionality that they consider is needed to remain competitive. For example, the need for a modeling tool to support BPMN and SysML notations, provide Model Driven Architecture (MDA) features, enable modeling of Service-Oriented Architecture (SOA) and Enterprise Architecture (EA), handle dynamic programming languages, and so on. However, industry analysts rarely, if ever, identify the innovative set of features that blasts the competition out of the market place. Industry analysts are geared to identifying and analysing growing trends in the industry. By definition, by the time something is a general trend, it is no longer an innovation.

Similarly, customers and end users of a product are always able to list new features that they want in the product. Sometimes these can be very insightful. However, for a significantly large, established customer-base the requests can be as diverse as the set of customers, reflect a strong personal or local bias, and be as heavily influenced by industry analysts and media trends as the average product marketing department.

A good product marketing department may do much better but, in my experience, the average software product marketing department does little better than follow the lead from analysts and the most vocal customers.

If you cannot rely on analysts, customers and product marketing to identify the next 'killer feature' for your product, where do you look?

For many mature software products and markets, the answer may be as simple as 'ease of use'.

I do not have time for this! I have work to do!

The people that use our software products as part of their job have work to do. They want the software tools to enable them to complete that work better and faster. They do not want software that makes it harder to complete that work or leaves them uncertain of the correctness of the results. In other words, they do not want overly-complex, unreliable, unpredictable, or tediously slow software. Instead, they want their software tools to be genuinely useful and easy to use.

It sounds so obvious but looking at some of the software products on the market, including some of the bestsellers, you would not think so.

For example, it makes considerable sense to automate a tedious (and, therefore, inherently error-prone) task. However, if the software automating that task only manages 90% of the task, and leaves the user with more tedious work to complete the task, the software quickly loses it's appeal. Consider a software tool that generates a report from data in a database but does not get the formatting of tables quite the way that most people need. It can take longer editing the report in a text editor or word-processor to correct the formatting than it would have taken to produce the report by cutting and pasting all the information manually.

Of course, this problem is easy to fix. The developers of this software tool work hard and release a new version with selectable options for all possible formatting variations. The software is now incredibly powerful and flexible. Unfortunately, it is also now incredibly complex. There are too many options for the user to intuitively choose and remember the ones they need, especially if they do not use the software on a daily basis. A training course is produced so users can learn all about these options but who has the time to take such a course with so much urgent work to get done?

Imagine our users finally do find time for the training course or work out how to use the software in some other way. What happens if this new incredibly powerful and flexible version occasionally encounters 'unexpected errors' half-way through generating documents from certain data sets and either crashes completely or incorrectly calculates some totals. Even though the answers are right most of the time, the users have to double-check the results manually to ensure this is not one of the exceptional times.

The end result is that frustrated users drop back to using cut and paste and the document generation tool, despite being powerful and flexible, becomes shelfware (software that is no longer used by the majority of its intended users).

While the tale above is fictitious and the combination of problems represents an extreme example, many mature software products exhibit one or more of these problems. The tale above also illustrates that, although we think of ease of use as predominantly an issue of user-interface design or human-computer interaction design (www.interaction-design.org, www.cooper.com), it is not the full story. Complicated, unreliable, unpredictable, tediously slow software is hard to use effectively to get your work done. Hiding inevitable complexity under a veil of simplicity is one of the responsibilities of good interaction design, but simple, robust, reliable, and efficient software requires more than a great user-interface.

In contrast, a straight-forward, robust, reliable, efficient software product with a well-designed user interface is easy to learn and use. To its users, it becomes a trusted friend, recommended to anyone who inquires about it, and in some cases, almost markets and sells itself. Another bonus of such software is an associated reduction in the cost of providing technical support.

Of course, if your company is adept at selling large amounts of professional services to customers who have bought your over-complicated, unreliable, unpredictable, tediously slow software then you might as well stop reading this now.

Feature-Bloat

These days, one of the major enemies of ease of use is feature-bloat. While in most non-trivial software, some level of complexity is inevitable, a considerable amount of unnecessary complexity is caused by support for rarely used features and options. Many software products today are so full of features and have so many configurable options, that their complexity ensures that users find them hard to learn and use. In addition, that complexity almost certainly guarantees that your software:

• is unreliable because it is hard to comprehensively test so many combinations of features and options, and
• is slow because it is hard to optimise performance for so many combinations of features and options

Word-processors like Microsoft Word are probably the most obvious example of feature-bloat. The vast majority of office workers do not need the incredible amount of sophisticated page-layout and formatting features found in these products. Most need only a little more than the formatting options provided by the HTML 2.0 standard used to produce web pages in the 1990's (headings, paragraphs, basic font support, tables, lists, including an image, etc). With these options plus page-related features such as page breaks, headers and footers, table of contents, and indexing, etc, most office workers can produce all the memos, agendas, minutes, and run-of-the-mill documents required by their job. Even professional writers need little more to produce the copy they need to supply their editors and publishers. At best, most of the other features do little more than get in the way. At worst, hours can be lost battling a strange formatting inconsistency, reworking content that has been 'intelligently corrected' automatically, or recovering from a catastrophic program crash.

Similarly, why do most commercial UML modeling products insist on not only providing all the UML 2.x diagram types but BPMN and SysML modeling as well. The vast majority of UML modeling tool users use no more than seven or eight of the thirteen UML 2.0 diagrams: class, sequence, use case, activity, component, package, object and state chart? Yes, some teams regularly use all thirteen types of UML 2.x diagram but in my experience, they are a small fraction of the customer-base. The fraction of the customer-base that use both UML and BPMN is much smaller again and the fraction that uses UML, BPMN and SysML is vanishingly small. Despite this, all users of such modeling tools have to cope with the extra complexity of support for rarely used diagram and model types.

It may be a radical idea, but removing some of the rarely used features from your mature software product or product-suite could make it a significantly better product. Find out what features the vast majority of your customer base use. Then decide whether or not to drop rarely-used sets of features, simplifying the product for users, and reducing the amount of regression testing needed and the cost of providing technical support for those features.

Alternatively, consider introducing a compatible, lower-cost edition of the product containing only the most used features in the product. While this will not reduce the amount of regression testing, etc, the cheaper, simpler, easier to use product might appeal to potential customers previously put-off by the price, complexity or both.

If you are entering a market with a new product, resist the temptation to match competitors on a feature-by-feature basis. Instead, concentrate on making the core things the product needs to easy to learn and use.

Another strategy for identifying the core set of features to support examines the ability and experience levels of the customer-base. For example, the vast majority of UML modeling tool users still fall into two basic categories:

1. Those that need to quickly create a set of consistent, related UML diagrams to copy and paste into web pages or traditional specification documents, or print out and pin on a development team meeting room wall.
   
   
2. Developers who want to use a subset of UML diagrams to visualise and help understand the structure of some source code. Typically the developer wants to produce class and sequence diagrams from the source code to help them explore and understand the high-level structure of the code. The source code could be their own, or something delivered by or inherited from another development team.
   

Next there is the much smaller subset of more able and experienced modelers and developers that want their UML modeling tool to enable them to:

1. Produce UML models containing both diagrams and related text descriptions, and then generate web page content or sections of traditional specification documents for different audiences according to some set of user-defined templates.
   
   
2. Create models of software components built to specific rules and guidelines so that they can be combined and reused to form designs for larger component-based or service-oriented applications.
   
   
3. Directly manipulate source code represented as UML diagrams in a similar way to Together's LiveSource technology.
   

After this, only a few potential customers remain unsatisfied. These are the users that want to-the-letter compliance with the UML 2.x specification and either full model-driven-architecture support, or the frameworks and toolkits to create their own code generators.

An UML modeling product that has features that satisfies the two basic categories of user but is significantly easier to use (simpler, more robust, faster, etc) than its competitors is likely to be a successful product. Even in such a mature market (UML tools have been around for well over a decade), a truly easy-to-use product that supports the five categories above would blow away most of the current competition.

Interaction Design

After tackling unnecessary complexity caused by feature-bloat, and assuming the development organisation is able to produce robust, reliable, efficient software, ease of use does become mainly an issue of user-interface and interaction design.

Interaction design is a large topic on which whole books have been written and it remains the subject of considerable study and research. Surprisingly, only two of the major software development projects I have worked on have had a dedicated user interface or human interaction designer role. Usually, the user interface is either designed by analysts when working with the client to produce an agreed requirements specification, or it is left to developers who know how to use the latest graphical user interface toolkit or technology. While many of these have some appreciation of what makes a good user interface and some have considerable natural flare, few if any have had any formal training in user interface or human interaction design.

Therefore, one obvious strategy to increase ease of use in a piece of software is hiring someone with proven ability and experience in this area.

If hiring someone is not feasible, then it is worth understanding of some of the basic principles of good user-interface/human interaction design. The internet has a significant number of lists, articles and reports on the subject, but a few of the important ones are:

1. Intuitivity

I do not think this is actually a word but hopefully it conveys the idea. As Joel Spolsky says, "A user interface is well-designed when the program behaves exactly how the user thought it would." A user interface that is intuitive saves a user hours in trial and error learning, hunting through user manuals, or searching the internet for information on how to do something.

Unfortunately, one person's intuitive interface is another's nightmare. Generally this is because of learned behaviour. If you have used a particular brand of software for years, you tend to expect other software to work in a similar way. Sometimes this is counter-intuitive to others. Millions of Microsoft Office users have learnt that they need to press the save button frequently to avoid the frustration of losing work when the programs crash. For these users, programs like Micro Focus Together that save your work automatically feel unintuitive and even uncomfortable to use even though auto-saving is a much better user experience and what those new to computers often intuitively expect.

2. Consistency

Consistency is the most important contributing factor when creating intuitive user interfaces. It is why companies like Microsoft, IBM and Apple produce user interface design standards and guidelines for developers. Performing similar tasks in similar ways throughout a user interface makes it easier to learn and remember how to use. For example:

• on my iMac, the first menu item after the apple symbol on the main menu bar is the name of the currently selected application, and under this is the menu option for adjusting the preferences for the application and the menu option to exit the application.
  
  
• F1 on a Microsoft Windows machine always opens the online help for an application.
  
  
• if you implement drag and drop in one place to copy or move something, then it is a good idea to implement wherever copying and moving of items can take place.
  
  
• if a name property appears at the top of a property list for one type of item, ensure it appears at the top of the property list for all other types of item. On older versions of Eclipse, properties in the Inspector view were listed in alphabetical order by default. This meant similarly named properties for different types of object could appear in different locations in the list. You could not rely on the name property being the first item in the list. You had to scan down the list past those properties whose names began with letters that come before n in the alphabet.
  
  
• if one view has a drop down menu listing options to filter the content, then any other view with filtering capabilities should also provide these via a similar drop down menu.

3. Making the ordinary easy and the extraordinary possible

Require minimal mouse movements, clicks, and key presses to complete frequently-performed tasks.

Controls for less frequently used actions and tasks can be placed where advanced users can find them but where average users are not distracted by them.

For example, in most applications on my iMac, the frequently performed actions are available on a tool bar at the top of the current window. Less frequently used actions are in the menu bar at the top left of the screen. Not only are the common items grouped together, they are only a short move of the mouse away. Less frequently used stuff is in a well-recognised place but is out of the way and further to move the mouse.

Tool bars are a fantastic way of providing commonly used options just one mouse-click away. However, as much in life, moderation is the key. Four rows of window-wide tool bars undermines the benefits of the a tool bar because users end up searching for the right tool bar button amidst a sea of similar looking icons. A number of developer tools have fallen into this trap including recent editions of Eclipse, where things are even worse because sections of the tool bars appear and disappear as the user selects different types of resource. The result is that frequently used sections of the tool bars change position depending on what a user has currently selected in one of the view or editor panels.

4. Concurrency and Modality

Software should not unnecessarily block a user from doing something else while a lengthy operation is being performed. For example:

• an integrated development environment should not prevent a developer from editing the source code of one project while it is checking out from source control the files belonging to another project.
  
  
• a word-processor should not prevent a user from displaying online help content while reformatting a very long document.
  
  

Use of modal dialogs should be kept to an absolute minimum. It is especially frustrating when modal dialogs are nested and the information needed to answer a nested dialog is hidden under a parent dialog that cannot be moved without dismissing the child dialog. A complex model dialog is very rarely the only answer to a user interface design problem. Very often it is simply the dumb, lazy option causing other UI design headaches and considerable end-user frustration.

Do not restrict a user to working with only one of the thing unnecessarily. For example, Eclipse only allows one instance of a view to be opened. Many of these views contain complex contents that can be filtered in numerous ways and to be able to display two instances of a view with different filter settings would sometimes be useful. Again, UML modeling tools provide another example of how not to do things. Many of these monstrosities only allow one diagram to be visible at once. On many occasions it is useful to have two or more diagrams visible, having a related class diagram visible when working on a sequence diagram being one of the most obvious cases.

5. Providing User Assistance where most needed

For a system with a web front end or more traditional graphical user interface, the types of help mechanisms that should be considered include:

Embedded help

Where space allows, displaying help information within a spare user interface panel or section on a web page provides immediate, unavoidable access to assistance. This sort of help is so easy to use that there are almost no excuses not to read it. Early versions of Micro Focus Together did this very well and some examples are shown in A Practical Guide to FDD. Unfortunately, much of this was lost when the product was moved to the Eclipse platform. More recently, Apple have taken this a step further in including not only static text and images, but a video snippet demonstrating the effect of selecting a particular option. Figure 1 is a screenshot of the new Magic Trackpad settings panel. Highlighting one of the options on the left causes a few seconds of video to be shown on the right demonstrating the feature turned on by that option.

Figure 1: Apple's Magic Trackpad Settings Dialog

Obviously, this sort of help needs to be considered as an intrinsic part of the user interface design process.

While, there is little concern about the performance impact of loading this sort of online help om most modern workstation and laptop computers, an online applications that may need to pull this sort of help across a sluggish network connection should offer the user the option to turn it off, or display a short text-based alternative.

Tool tips

Having help text pop up as a mouse is moved around a user interface or panel is probably the second most widely read help mechanism. Tool tips can:

• explain the function of graphically depicted buttons,
  
• display the full name or description where space restrictions have required the user interface to truncate a name or description,
• and generally provide more details of any item in a user interface panel or page.
  

Figure 2: Tool tip example in Safari

Most GUI toolkits and web page editors make the addition of tool tips very easy. The hard part is supplying concise, useful text to display. A tool tip that only repeats the text of a label that the user is pointing at is a complete waste of everyone's time and energy.

Error and warning messages

There is nothing worse than receiving a cryptic error or warning message and having to trudge through large amounts of user documentation to try and find out what the message is trying to communicate. Error and warning messages should be considered part of the help documentation. They should be standardized, edited, and reviewed for usability and understandability.

An error or message dialog can also serve as an entry point into context sensitive help documentation that expands upon the meaning and implications of the error or warning message.

An error message should always indicate where in the document or data the problem occurred. It can be enormously frustrating for a user if they have to spend hours working out what part of a document or which piece of data is causing a problem. The documentation generator in Micro Focus Together used to be guilty of doing this. If generation failed, it informed the user of what had gone wrong but not where in the document template the problem had occured, or which element in the model had caused the problem.

Context sensitive help

Normally accessed by pressing F1 on a standard PC keyboard or a help button (typically depicted as button with a ? label) on a user interface panel, this type of help is normally displayed in its own panel or page. This often little more than an online users guide ‘opened’ at the most relevant page for the task being performed.

In many systems users are put off from using this type of help because it often displays very slowly and is not as helpful as it should be; either not specific enough (i.e. the context is set as the whole user interface panel rather than one particular control or field in that panel that the user is struggling with) or too specific omitting the overall purpose and results of using the panel.

Interactive Online Tutorials

One other kind of interactive user aids I have found useful the cheat sheets in Eclipse. These short, specific, interactive tutorials step you through an example of a particular task, perfroming some of the steps automatically or allowing the user to do so manually. Being able to create your own cheat sheets and add them to the list of those available enables developers to create examples specific to a particular team or organisation's needs.

Figure 3: Example of an Eclipse Cheat Sheet

Intrusive Help

Nobody likes a smart ass! Intrusive help features are those that monitor a users action and unsolicited, suggest better ways to do things, auto-correct mistakes, or offer to perform some extra action on behalf of the user. These are frequently more a hindrance than help. Customizable, animated figures (e.g. Microsoft Office animated help figures) that can initiate interactive help sessions are a nice flashy feature in product demonstrations but are very soon tiresome to work with. Most competent users will turn them off as soon as possible. The time spent developing these would probably be better spent developing a more intuitive user interface.

Syntax completion in programming editors and real-time spell checkers that indicate an unrecognized word and offer suggested replacements (instead of silently changing the word to what it thinks is the correct spelling) are a couple of exceptions to the rule.

Online manuals

Consisting of tutorials and reference volumes, the main body of online help often seems to be read by users only as a last resort. This is usually because the documentation is hard to read and poorly organized, making it hard to find the relevant information when it is needed. This type of documentation requires good planning, a clear structure, and most importantly, someone skilled in technical writing and fluent in the appropriate language to write it. Otherwise, it ends up adding little of value to the system. Poorly planned, inaccurate, out of date, user guides and manuals written by someone whose first language is clearly not that in which the help is written, can damage a system or product's reputation more than most people realize.

Figure 4: Examples of Online Help Manuals

Generally, online help manuals these days are written in HTML, XML or some mixture of the two. Typically, an online manual provides three means of navigating its content:

• a hierarchical table of contents listing the topics available
• an index listing all the signifcant terms in alphabetical order
• a search facility
  

While the search faciltity would seem likely to be the most useful, it is too often very slow and poor at finding what you want. With refined internet search technology in place now, hopefully this situation will change in the not too distant future.

Others to Consider

Tips of the day, slide presentations, annotated and animated screen shot sequences, streaming video, examples and samples, regular tips and tricks newsletters are all other ways of helping users learn to use a system without resorting to reading large documents.

Conclusion

If you are struggling to decide how to distinguish your software product in a crowded market place, consider striving to make your product the easiest to use including make it the most straight-forward, the most robust, the most reliable, and the most efficient.