Giving the Human Touch to Software

Yogita works as a QA/testing professional with Mindfire Solutions, and has written a number of articles on QA and testing strategies. Yogita is currently exploring thoughts of beauty as an area of testing and its relation to usability. Her role at Mindfire has been to implement Quality processes throughout the organization and build a dedicated testing team. The team recently published a White Paper “Porting projects: Test techniques,” downloadable from Yogita can be reached at [email protected].

Usability—we talk about it seriously and some of us implement it religiously. But usually, we don’t think about how the user expects the software to behave, and most of us abandon the actual users while designing usability. As you might guess, a user’s most excruciating experience with software starts with usability issues. Even when software organizations commit substantial resources to usability testing, they often fail to impress their target users, as the usability provided doesn’t match the users’ expectations. Later, they unintentionally degrade the software quality when they are forced to cobble unforeseen changes onto the existing framework, which is ill-suited to support it.

Knowing the target customers’ expectations when implementing usability has proven fruitful for me. I’ll start with my own story.

My first assignment as a responsible tester was for an application we developed for a famous five-star hotel. The application was to be used in hotel restaurants, to make the order-taking job easy, efficient, and automated. It was an exciting project. Having worked as a hotel hospitality desk clerk in the past, I was comfortable and familiar with the industry. I had two reasons to celebrate. It was my first independent assignment, and more important, it was in the service industry, which was my first love. I thought it would come very easily, as I knew the ins and outs of hotel operations.

The testing experience was fun, but not easy. I suggested a few enhancement features and my client agreed. When all was said and done, we delivered the project on time and, we hoped, bug free. The application was introduced to their operation and I was waiting to hear congratulatory emails from my client, saying how they loved the application and how it made their life easy. I did receive some mail from my client a week later, forwarded from my manager.

The operation staff found the application difficult to use. Almost every other transaction got messed up, because they didn’t know what to input where. The on-screen instructions were not understandable. Even with a simple order, the steward had to go through five screens to reach the end. In no time, they all went back to using pen and paper to take orders.

I was startled—this was the simplest application I had tested so far. With five screens total, and only text boxes and command buttons to handle, how could anyone find it difficult? I had even checked the user’s manual and included a help menu. What was causing the problem? The program looked simple and beautiful every time I ran it.

I decided to speak with the individuals rather than worrying over it. The feedback was really surprising, as they told me what an unfriendly application it was. What looked simple to our team actually looked difficult to the users. So I spent some hours with them, getting an understanding of their expectations of the software and then redesigning the GUI and the application flow all over again. They have been using it painlessly for two years now.

Connecting Users’ Expectations with Usability

Before proceeding with the usability testing, you should try to determine the requirements of your target customer along with other usability needs. Knowing the user’s mindset helps immensely in designing a product suitable for users at different levels of sophistication.

In our initial application, the last screen used to pop up a message when the user clicked on “Finish.” It read, “To save the order, choose ‘Save’ from the File menu. To print the order, choose ‘print’ from the file menu. To exit the application, close this dialog box.” All the terms used in the above message looked very obvious and simple to my team and me. We took for granted that the rest of the world also knows what a file menu is and that clicking on the top “X” button will close a dialog box. But unfortunately, the hotel employees didn’t know about these conventions. Had we understood that a steward would not be familiar with computer terminology, the product could have been designed to suit a layman’s needs. The corrected version had “Save” and “Print” buttons on the last screen and a “close” button to dismiss the dialog box.

User Comments

1 comment
Alexandra Belousova's picture
Alexandra Belousova

It's obviously very important to be able to look at the project by your customer's eyes. Something that seems perfect for you can be seen absolutely unacceptable for them. All trusted software development companies develop projects according to their customers' needs, and Belitsoft ( also does the same.

March 4, 2013 - 6:16am

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.