Why do many software applications fail to launch or die after a short blitz? What causes these software applications, often well designed with break through functions, to fail?
Many application developers are so busy creating software that they forget to document what they are creating. Documentation may focus on the history of the software, its intended purpose and praise the designers but give little practical advice on how to use the application. IT developers often design software to be easy to use but fail to determine the most common problems or solutions to them. Documentation written by coders is often indecipherable to general users. An understated problem with software documentation is the outsourcing of documentation creation to those who do not speak the language of the users. While the technical documents may be in English, difficult wording or impenetrable translations will leave users frustrated, often abandoning the product for something with fewer functions but better instructions on how to use it.
When users have problems with a new application and cannot get good help, they will quickly consider reverting to the software tools they used to use. Software application designers often create documentation on the idea that it will eliminate the need for any support, which is rarely the case.
Lack of documentation on the most common problems or their solutions means that what technical support does exist is left struggling to help users. The opposite problem occurs when there is help available, but only in the form of expensive service contracts or hiring the developers themselves at exorbitant rates. If a small business cannot get help without paying as much for support as they did for the software, then the support model is impractical from the customer’s standpoint.
Another area in which support fails is keeping up with related software. If your software doesn’t keep up with security threats, it is like an animal species that loses the ability to fight off parasites or disease. Eventually, it dies while those species that continue evolving resistance to parasites and viruses survive. If your software is dependent upon web browsers or database software and fails to keep up with the changes in those apps, users will migrate to something that can keep up with the software ecosystem.
Other applications have so many features that users cannot make sense of them. Pareto’s Law applies to software as it does to any other project. About 15-20% of the functions will be used 80% of the time. Software that is missing these key features will fail. Software that has beautiful modules for the lesser used functions but is difficult to use for the most commonly used functions will be dropped in favor of software that makes the most commonly used functions better.
Another problem developers fail to appreciate is the creation of applications that are simple for them to create but complex for users to use. Users prefer as few steps as possible to complete a transaction, run a report or check the status of an item. Adding multiple steps or moving functions to third and fourth menu levels adds unnecessary complexity.
Not Really Better Than the Competition
Some software applications are created to suit one esoteric niche. It isn’t widely adopted because there isn’t a wide-spread need. Software that creates more attractive reports does not necessarily offer better data mining or granularity than other reports. Interfaces with little used applications do not add benefit for most users. Software that mimics an existing application but reveals a breakthrough or killer app will often see its major competitor adopting that missing function. Now users choose the familiar old application with the missing function instead of learning a whole new software suite.