These sprints were 1 week explorations into quick prototyping to test design questions and concepts without becoming too invested in them.
They are not meant to be high fidelity, but to achieve user feedback in the most efficient way possible.
Iterative Prototyping: Transform Sound into Color
What if situational impairments could be seen from a distance?
This design question drove me and my partner, Brian Orlando, in this project. We wanted to explore how we might use physical devices to alert people that an environment might be too noisy for their comfort.
Because of the short timeline for this project, we needed to commit to a product form and test it. This set of initial sketches were the first exploration we performed into what would become the SynthLight.
Committing to an icosahedron shape, we moved into determining nuances of the structure and how an Ardunio kit might work with it.
Moving into testing our low-fidelity prototype, we wanted to test a couple critical hypotheses:
▸ The icosahedron would be an aesthetically pleasing shape to use
▸ People would grasp the sound-to-color conversions without verbal or written explanation
We were able to gather three participants to test our concept. The feedback was extremely helpful in understanding where to go from this point. Some insights:
▸ Erratic light transitions
▸ Hidden affordances
▸ Pleasant physical form
After fabricating the lamp frame and refining the Arduino code, we tested SynthLight again to solicit feedback on material style and light responsiveness. Some overall feedback:
▸ Being able to see the LED ring inside the lamp was uncomfortable for people
▸ People aesthetically preferred frosted acrylic to slatted wood
▸ Light still responded too slow to sound interactions
At this point, we had run out of time to develop the product further. However, we would have loved to iterate further and make SynthLight a pleasant experience for users.
Behavioral Prototyping: Text Editor VUI
When using a Voice User Interface (VUI), would people prefer numbered lines to unnumbered lines?
This is a simple question, but difficult to answer without a functional VUI. Instead of embarking on a multi-month adventure to create a functional prototype, we instead employed "Wizard of Oz" prototyping. Instead of a functional backend, a wizard (non-magical classmate) is the backend!
We first started off by designing the architecture of our interface, and how it might look. We wanted something that was simple so that we could build it easily, and the user would find it easy to use.
The Dorothy interface would be used by the unsuspecting user to format their text through their voice, not their hands. The Oz interface would allow hidden wizards to modify the user-specified text without requiring a fully developed speech recognition engine.
After finding five participants, we moved to test a simple hypothesis for this project: users would prefer line numbers over unnumbered lines.
Our prototype was wildly successful, and we did not reject our hypothesis. Additionally, we found a couple other findings:
▸ Users would have appreciated a progress indicator to show the interface had received their command.
▸ People said that they would not use the interface in non-private environments like work or a cafe.
Mobile Prototyping: Contacting Political Representatives
I started this project wanting to test if users could navigate through a simple mobile app as I would expect them too.
As assigned, I needed to create an app that would allow people to contact their representatives about issues they cared about.
These initial, quick screen sketches are what I saw as screens that would be necessary for the app. I wanted to get a good idea of what I wanted to create before I used Sketch.
After mapping out the interaction flow I wanted users to have, I created low-fidelity wireframes to match that interaction flow.
Moving those wireframes into InVision, I could then test my hypothesis that people would be able to easily navigate through the app I had designed.
As part of user feedback, I did not reject the hypothesis I started out with, although I would have liked to have more participants to try the prototype I made. Other minor feedback included that I could have made the affordances much clearer, participants were sometimes confused on what to click on.
Physical Prototyping: Handheld Blender
It is easy to sketch something out and think it is a great idea, only to find out once it has been fabricated that it looks and feels awful.
This foray in physical prototyping tested how we thought handheld blenders should be formed and how we should move on with that feedback.
With previous experience with physical prototyping, I knew I wanted to have a very good idea of what I wanted to do before I got started. I sketched out the ergonomic features I wanted to develop, and the approximate size.
One key thing I have found with physical prototyping, despite its typical high investment, is that it is important to build something 3D as quickly as possible. Otherwise, I will spend far too long think in 2D.
Below are the prototypes I made out of Model Magic clay and wood.
I have never handled a hand-held blender before, so it was instructive to hear from participants that these prototypes were far too bulking, and seemed more appropriate for more industrial uses.
Although time had run out, I would spend time with the next prototypes making them sleeker and ergonomic to hold for expected periods of time.
These prototypes were far from perfect. In many of the instances, they were the first prototypes of their kind I had developed. However, they enabled future success, and going forward, I gained lessons I would like to implement.
▸ Be clear with design process needs from the beginning
▸ Strive for prototype believability
▸ Keep material investment as cheap as possible