Share Your Prototype and Get Feedback
After completing this module, you’ll be able to:
- Collaborate with researchers to test your prototype.
- Understand when to make adjustments to your prototype.
So we have our prototype built, but before research starts, it’s important that everyone is in agreement and the script is set. We host a dry run or rehearsal of the research session with a colleague who’s unfamiliar with the prototype and would be a potential user of the new or updated features. In our dry run, we go through the entire research script as formally as possible. We want the dry run to feel real so that we catch gaps between the prototype and the research script. Gaps can be tasks that the researchers wrote into their script but are not properly implemented in the prototype.
Once these gaps are found, the UXEs work quickly to adjust the prototype before the first research session with a customer. After a final round of quality assurance, we’re ready for testing!
As prototypers at Salesforce, we love sitting in on research sessions and watching customers and users play with our prototype. Typically, the researcher and the participant are the only people talking during the session. Designers and UXEs may be welcome to sit in or dial in, but remember—we’re simply flies on the wall. We shouldn’t talk to the participant or influence their use of the prototype in any way.
Observing research sessions is helpful for multiple reasons. We can catch bugs in real time, be on standby to fix any issues, and get a first look at reactions. Since this is a prototype, it’s possible there’s a few bugs or glitches. Users are unpredictable, so if they happen to click or type something that the prototype didn’t account for and the UXEs are watching, we can go in and quickly reset or fix the application so the session can continue.
It’s also exciting to watch users interact with your prototype for the first time. As prototypers, we’ve been staring at this application for a long time, so we can tend to forget just how useful and cool it is. However, as prototypers it’s natural to be biased toward liking our own prototype. It can be hard to watch participants critique and give negative feedback about the application.
So how do we prepare for possible negative feedback?
- Don’t take feedback personally.
- Remember why we prototype and research—to better serve our customers so they get the best experience possible.
We are not our own users, so it’s important that we listen to customer feedback, no matter how hard it may be to hear. The customers and end users appreciate the time we took to incorporate their feedback into the final iteration.
Woohoo! The research is over, the data is collected, and the prototype is done! Time to forget about it forever, right?
A prototype is rarely ever done. All that research you just helped gather? It’s highly likely that will go into another round of prototyping. At Salesforce we often use RITE testing, which involves making changes in between research sessions, as soon as a problem is noticed and a potential solution is identified. RITE testing is beneficial because it allows for more rapid prototyping. Once a potential fix is identified, it can immediately be tested on the next participant, rather than waiting for a whole new set of research sessions.
So we can make changes to the prototype design and interaction in between different research sessions. Otherwise, we wait until all the sessions have completed, and then go through the whole process again.
It’s not unusual to go through the cycle of designing, prototyping, and research a few times until some clear results have been discovered. But that’s the fun! Seeing how much the designs evolved, or didn’t evolve, helps us better understand our customers and give them the best user experience, which is ultimately the goal of prototyping,
Now that you know how to go from design ideas to full, data-driven prototypes and iterate through multiple research sessions, it’s your turn to share the rapid, iterative world of prototyping.