Outline your testing protocol--a description of the steps that anyone on your team can follow to gather feedback from testing. It should include the following sections. IMPORTANT - You should not explain all the features of your product or lead your users thru a demonstration of its design features. For truly useful feedback, allow your users to interact with your prototypes and discover its features. Try to be an observer, not a tour guide. Answer any questions that come up as users interact with the prototypes, but keep in mind that asking "what do think will happen?" or "how do you think that might work?" will solicit very useful information about what's going on in the user's mind. Don't try to sell or pitch your product to your users. You're not trying to convince them that your product is good. Rather, you're hoping to learn from observing and hearing how they feel about your product. Then, after users have had a chance to explore your prototypes, you can ask about any specific issues that you'd like them to share their feedback on.
What will you share with your users to interact with?
Exterior design, scale, intuitive AI, long battery life, and demonstration of easy and comfortable reading, annotation, and note-taking.
Rudimentary description of potential prototype to be presented:
A rugged, resilient e-ink tablet sketched in a 2d concept format with battery statistics overlaid in a high-tech fashion. Positioned next to easily recognizable scale references and completed by large-scale screenshots of intuitive UI and 1:1 scaled screenshot demonstrations of reading, annotating, and note-taking on the device.
For each feature that you're testing, how will you use your prototypes?
- Easily repairable
- Simplistic and easy to understand user interface
- Modular offline functionality chip system (MOFCS)
- Built-in Touchscreen
What will you ask them to do?
What will you ask users to do with your prototypes?
- Understand and experiment with UI
- Experience Modular offline functionality chip system (MOFCS)
- Ask them to navigate UI and use MOFCS
What will you observe?
Audience’s immediate response to visual appearance, ability to understand the UI, and response to scale and font size.
What you will be observing and noting as you watch users interact with your prototypes?
- If there is any difficulty for them to understand the UI without helping and guiding them
- If they cannot figure out how to repair our product when it is suggested broken
- They might not have a town hall in an area or have a better idea for chips storage management
What will you ask them to share feedback on after the testing?
What questions will you ask your users after they've had a chance to interact with and explore your prototypes?
- If there is any feedback on how we could make the UI better?
- Console or touchscreen a better choice?
- MOFCS viability?
- Would this add value to educational systems?
Formalities exchanged—30 second context pitch given enthusiastically. The audience will be told that there is absolutely no pressure, and the truth is encouraged (or some variation of that).
The folder containing the aforementioned 2d concept design and scaled screenshots of UI and demonstrations is emailed to the audience.
The audience will be asked to look at the concept designs for a total of five seconds, minimize the window and immediately write the five words they can think of to describe it (assuming such requests are allowed). If not, the audience will be asked to look at the 2d concept design sketch and remember their thoughts.
The audience will then be asked to open scaled screenshots of the UI and asked to find the home button.
The audience will be asked to open scaled demonstrative screenshots and read the text on the page.
The audience will be asked what they thought of that reading experience and then asked about their opinions on the product as a whole, the UI ad the feedback experience.
The audience will be thanked. Results recorded, added to the shared doc.