We all make software that works beautifully, but how many put a high priority on making software with a beautiful look?
All our testing efforts are concentrated on functional enhancements and corrections so as to make the product work better. But how many of us really think about making it look better? Probably, in our terminology, beautiful software is software that is bug free and stable. But what does the end user understand and expect in terms of beautiful software?
For me, software is beautiful when it works effortlessly with the person sitting at the terminal. And the program has an appearance defect if something that you reasonably expect to appear is missing, awkward, or confusing. The user should find it painless and fun to use the software. Effective onscreen instructions, adequate information, and interactive dialogs can make the software look and function better.
Testers may argue here that they already perform usability testing on every application that is driven with a user interface. If you get a little deeper into the concept, you will see how Usability and Beauty are two independent and yet inseparable entities. Usability is all about the ease, speed, and pleasantness with which the user can use the application. And during usability testing, ease and speed are still given importance, but pleasantness often remains in question. If the “pleasantness factor” is well taken care of, we will certainly succeed in creating beautiful software with high-end functionality. Beauty actually serves toward acquiring better usability.
The major drawback of a technically competent team developing and testing software is that the look of the software often takes a back seat to functional mechanics. Perhaps that is because everyone on the team is so preoccupied with proving their technical skills and making the product tech-rich that they tend to forget the comforts and ease of the intended user. But paying a small amount of attention to the application’s serviceability toward the user can dramatically improve the software’s quality and the user’s overall productivity.
Nine out of the ten applications that I get to test are not really good-looking. To be more blunt, these applications are downright ugly. Now, don’t mistake them for being technically poor. They are rich with features. But they can be awarded, at max, two points on a scale of ten for their visual merits. When it comes to captions, font color and styles, meaningful and appropriate dialog boxes and error messages, I often feel like redoing the whole thing. For such products, my bug list actually starts with appearance and communication issues.
In my personal experience, developers love to ignore such issues. “It’s not a bug as long as the window has some caption,” they are apt to say. “Throwing an error dialog in there is enough. Users at least get to know there is something wrong with their input.” Developers suggest that I keep these types of issues in my bug list as lower priority ones. “If time permits,” they say, “we may think of looking into those. After all, the application runs fine without them.” This attitude on the part of developers probably discourages testers from reporting cosmetic bugs. Testers may feel reluctant, fearing that they might be misunderstanding the functionality or reporting “trivial” bugs. But I always practice and preach that a tester should approach the developer with every issue that pinches him. It’s never offending to clarify doubts. What if you are actually seeing something that makes the developer take note? Maybe it was not ignorance on the developer’s part but a mistake that he would like to rectify. It is even better if the tester succeeds in convincing the developer that these issues are targeted toward reducing the software’s complexity.