Measuring Up: How to Preview User Satisfaction before Your Release


Here's what a simple survey might look like:


How do you rate the WidgetMaster system at this time?











Difficult to Use


Easy to Use




Low Availability


High Availability




What pleases you about the system at this time?

What displeases you about the system?


Then approach the cross-section of people you've chosen to fill in the survey with their opinions, and ask them about the version of the system under development. Be sure to leave plenty of room for comments at the bottom of the survey.

You won't obtain scientifically precise data from your survey. However, you can find out how people feel about the project, and that ties directly to their expectations for the system.

When you first start using a survey, the comments section will provide the best clues. You may also want to investigate if the ratings vary widely. Big variations may be a sign that one stakeholder or group is unhappy with the direction the system is going. Follow up. You may learn something valuable.

Jodi used a survey as a window on satisfaction for an application she was building for customer service reps. Jodi was surprised when the average ratings on "ease of use" took a dive, and she decided to investigate. It turned out that the customers had recently reviewed the screen and dialogue designs for the customer record retrieval function.

Supervisors were happy with the screen navigation because it was directive—helpful for new employees who weren't familiar with the system. For them, it meant fewer questions and fewer errors from new customer service reps.

Experienced customer service reps weren't as happy. They were forced to respond to prompts that they no longer needed. For them the detailed navigation was a burden. They wanted to be able to take shortcuts and skip through prompts for functions that were second nature to them.

Armed with this information, Jodi was able to implement an alternate navigation scheme that better met the needs of experienced customer service agents. On the next survey, satisfaction was back up.

Best of all, Jodi was able to discover the dissatisfaction long before the system went into beta testing, when it would have been difficult to make the changes the agents wanted.

You can't always "fix" the cause of dissatisfaction, but you can begin to manage expectations so that neither you nor the customer has an unpleasant surprise on release day.

Why wait to discover how your customers will react to the system? Finding out how they are reacting to the work of building the system can give you valuable clues to help steer your project toward meeting expectations. This simple tool can help develop visibility into customer satisfaction.

To learn more about uncovering customer expectations, check out the book Exploring Requirements: Quality Before Design by Donald Gause and Gerald M. Weinberg.

About the author

Esther Derby's picture Esther Derby

A regular and Better Software magazine contributor, Esther Derby is one of the rare breed of consultants who blends the technical issues and managerial issues with the people-side issues. She is well known for helping teams grow to new levels of productivity. Project retrospectives and project assessments are two of Esther's key practices that serve as effective tools to start a team's transformation. Recognized as one of the world's leaders in retrospective facilitation, she often receives requests asking her to work with struggling teams. Esther is one of the founders of the AYE Conference. She co-author of Agile Retrospectives: Making Good Teams Great. She has presented at STAREAST, STARWEST and the Better Software Conference & EXPO. You can read more of Esther's musings on the wonderful world of software at and on her weblog at Her email is

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!