For all but the smallest of projects, software development will typically involve several interested parties. Whilst up-front planning, shared understanding and a common goal can ensure pats on the back all-round, requirements-by-committee can plant a very undesirable seed in your project: too much choice.

You can never have too much choice

Walking into a restaurant and being presented with a single-page, four option menu will likely soon have you grabbing your coat. Conversely however, trawling through a menu of encyclopaedic proportions will soon take its toll on diners patience, enjoyment and enthusiasm for an establishment and the task at hand. Of course there is no ‘right’ size for a restaurant menu, consider the many different types of restaurant: fast-food, cafe, village pub all the way through to  Michelin-star-celebrity-chef-invite-only-exclusive venues. A restaurant has to choose its menu very carefully and not just offer all the dishes the chef has in their repertoire, the bosses favourite, cheapest or fanciest dish but deliver the menu that is most appropriate to the customers.  Your software should have the same focus. It’s quite feasible to deliver a software project with any number of requirements and features however this does not qualify it as a success when none of those features get used because your users are lost in a sea of optionality.

Take Cover! Feature Explosion

One of the best and worst things in software development is that almost anything is possible. As ideas evolve into discussion, discussion into meetings, meetings into objectives, into plans, into projects, the initial idea can easily fade into just a small part of the evolving vision. As one option gets explored new ideas are brought to the table that offer new and unexpected benefits. All of a sudden these new ideas jump straight to the top of the wish-list and begin involving other departments and new stakeholders and subsequently new ideas and input.

For a business funding a project it is understandably very tempting to try and squeeze as much out of an investment as possible. However, as more and more gets thrown into the mix, existing requirements and related benefits become watered down, budgets and time scales get stretched and overall quality is reduced. Direction of the project can meander and falter as an increased number of stakeholders ensures an increased number of opinions on the way things should be done which wont necessarily align or at the very least will require compromise to the detriment of the best solution to the original problem. It is vital to keep an eye on what the actual main objectives are for the project and not slip into trying to create an all-encompassing uncontrollable behemoth. There are already plenty of those available.

User Choice

From a business perspective, when we refer to ‘choice’ we are referring to the choice a user has of what to do. As discussed above it’s easy to see how the number of choices of what to do can rapidly increment. For the user this means more training, more time to familiarise, more to remember and more to get wrong. This is especially so with new software or users approaching software for the first time.

From a usability perspective we have another choice issue affecting users, the choice of how to do something. Even the web browser you are using now most probably offers at least four ways to bookmark/favourite this page (the menubar at the top of the window, the toolbar icon buttons, right click context menu and some form of keyboard short-cut). The key with this presentation of choice is to provide the required functionality in the expected manner. Multiple routes to an action such as bookmarking are needed where there is a common and accepted approach because users are conditioned to doing that action one way or another. For custom tasks specific to your software however, this extension of choice could again cause confusion and more demand on users memory (as in brain power as opposed to computer hardware).

Cake and Eating it

A common reference for simplicity is Google Search. Given a text box and button titled ‘Search’ even the newest novice user will figure out what to do. Unfortunately most applications have slightly more inherent complexity and a certain amount of choice will be necessary in order to get the job at hand done. There are however a few approaches which can be used to give the comfortable boundary of limited choice whilst still delivering on business requirements and not restricting advanced users.

• Simplicity through obscurity – sometimes it may be appropriate to sacrifice the intuitiveness of less common features to increase the simplicity of the main functionality. Hiding advanced options that can be accessed through some less obvious means allows the common features to stand out more. The majority of users that won’t need those features can remain blissfully unaware of their existence rather than confused and hindered by their presence. For example, such ‘hiding’ can be achieved by using rollovers, right click context menus or keyboard short-cuts.
• Modular applications – application modules or plug-ins can be used to deliver a bare-bones base application which can be easily extended to suit different users requirements. For example sales staff might not need access to the invoicing system whereas accounts staff need not be able to track new leads, separating these two different features into their own modules allows the same application to be setup to perform different roles.
• Configuration and Preferences – An application can be initially bare bones and only offer the most common feature set but with a facility for users to enable/disable the features they wish to use. This can be managed through a user-specific configuration file or managed remotely by a higher level administration user. Having a single area which lists the available functionality will allow users to switch on / off features as needed one at a time which will be much more digestible than viewing everything at once.

To get in touch with your software requirements or to even just run some questions by us
call 01202 398 380 or email us at info@moov2.com

Tags: Bespoke Software, Requirements Analysis, Usability