It’s no secret that software sucks. You know that from personal experience, whether you use computers for work or for personal tasks.
Computers make users feel dumb. Literate, educated people can’t make the PC do what they want it to do, and instead of blaming Microsoft , they blame themselves and say, “ “Gee, I must be dumb.”
Why do programmers design applications that make people feel this way, and why do people accept this abuse from their computers?
The piece of a computer program that deals with the human user getting commands and input data from him, displaying messages and output data to him is known as the user interface. As with many areas of computing, user interface design is a highly specialized skill, of which most programmers know nothing. They became programmers because they’re good at communicating with a microprocessor, the silicon chip at the heart of the machine. But the user interface, by definition, exists to communicate with an entirely different piece of hardware and software: a live human being. It should not surprise anyone that the skill of talking with the logical, error-free, stupid chip is completely different from the skill of talking with the irrational, error-prone, intelligent human.
The second mistake programmers make when they design user interfaces is to force users to understand the internal workings of their programs. Instead of the programmer adjusting her user interface to the user’s thought processes she forces the user to adjust to hers. Furthermore, she’ll usually see nothing wrong with that approach. “That’s how my program works,” she’ll say, puzzled that anyone would even ask why her user interface works the way it does.
A programmer would never ship a product without testing its internal operation (OK, he shouldn’t). Why would he think she could get away without testing a user interface, to find out whether users really can use it? Because he knows he likes it and finds it usable, so how could anyone else fail to do so? As we’ve already seen, this unconscious assumption is almost always wrong. Computers that users can’t figure out how to use are very expensive paperweights. Testing the user interface, called usability testing, is difficult and expensive, but necessary.
Unfortunately, usability testing often gets left until late in the development process, just before the product ships. Schedules invariably slip, so usability testing is often omitted completely. When it actually does turn up useful information, the schedule often doesn’t allow time for changing the program in response. Usability testing needs to be done early, ideally before any programming takes place.
What to do ?
User interfaces could be made much better by involving usability specialists from the beginning of every software project. General programmers are normally not usability experts, someone has to speak for the silent majority of users who do give a shit about the technology for its own sake, who just want to get their work done so that they can get back to living their lives. Normally involving the user from the very beginning of the project and test out the user interface or the UI in general will be an approach that saves you a great amount of hours when roll out.
Normally developers hate to bring in users in a early stage of the projects because often the focus are on UI and on performance, something that developers already hate to discuss. The default answer when you ask a develpoper, “why does the view take so long time to open and show “Please wait” all the time?“, the answer will be something like this “Because the DotNetFramework take so long time to start up and the SQL server connection is so slow due to latency to server“. The user that before used an old application with crappy UI now get a totally new application with crappy UI and crappy performance.
Involving the user from day 1 and create accurate performance requirements are crucial for the project success. Normal users does not care about DotNetFramework versions or latency but they care about how much time it takes to open their application and enter their information.
This leads to the next issue, to involve users you will also need interpreter or a “bridge” between developer and the users. This person has to be a technical person that still can talk the “normal” language to normal people, but can translate this into developer language and back again. Sometimes organisations calls this a System architect and System engineering but also many companies skip this resource to save money and time.
So the minimum team should at least be :
1 developer, 1 System architect and 1 user, then the odds for making a good application is better. It cost more in the project phase but less in the roll out phase, Also can the user be a “super user” when your product is released. Then you already can save Training and support time in your R&D department.
– Why Software Sucks by David S. Platt, 2007