The test went pretty well. Our goal was to revisit those who had originally completed our survey and ask them how we’d addressed their observations and experiences to improve the service dining experience. Our intention was to express our efforts on empathy and make them feel like their needs were addressed and that they were at the foundation of our innovation. We encouraged our testers to activate the test from their phones or tablets as they would if using in real practice.
We received strong feedback from our first survey as to the extended length of the questions (which may have lead to reduced feedback to the testing phase). Therefore we limited the explanation and simply asked our users to play. We then presented a feedback grid with four simple questions: what did you like, question, want to change and what was a bigger idea? While the responses weren’t overwhelmingly large in numbers the quality of feedback gave us enough insight to understand the application of our project. From questions such as “how much overhead will be required to provide such details of the process” and ” how can you be sure the information is correct” to suggestions of a refill button and a suggestions box or user review forum/link, I think we accomplished our goal of testing for refinement. What we were really seeking to understand is the reaction to our ideas to address their problems with restaurant service.
This step, in my opinion, is not done enough in the workplace. When an idea is generally brought to light, developed, and is developer approved, it is pushed through the system as a generally accepted application to a process. Many times I think people generalize that the developer who realized a need and who has worked to address that need is in a better situation to judge the viability and practicality of putting the product or process in place. This is clearly a mistake. In my experience, it is a mistake because even if the developer is 100% correct, the end user is much more likely to accept the new product or process where they feel as thought they have had an influence. Many times I’ve used this “test” to my advantage. When I think I have a solution, I approach the situation with “beginner’s mindset” just to allow the user to be more in control and feel less threatened by any influence I may have had on the project. At times, this method has worked not only to get acceptance, but has led to further refinement by being open (or at least appearing so) to suggestions. So it is not as if I’m fooling the user, but maybe even fooling myself toward refinement. Either way the goal of improvement to the ultimate end user is applied through a test.