Prototyping is a Process

A process blog for HCDE 498 - Prototyping Techniques

[protopro-blog]

2D Object “Paper” Prototype: A Sheet Music Player (Pick Up. Practice. Play.)

Scenario: The final project is intended to let you expand on a prototyping technique or techniques that you learned previously in the course, but with fewer constraints on the application domain or design. In addition, we would like your project to utilize at least two of the prototyping techniques we have explored in the course (A1 - A8). Remember that in one of our first discussions in the course, we talked about various motivations for creating a prototype. They generally fell into three categories, which can be summarized as exploring a design's desirability, feasibility, or usability.

Challenge: So the basic requirement is that, whatever you make, you must be able to evaluate this prototype and evaluate how it satisfies one of those three goals. This can be accomplished by a small user test or a demo in which you solicit feedback. You should consider this requirement as your plan your prototype and articulate how you will conduct that evaluation.

The Design

For this final project, I wanted to implement an idea that I have had for a few months now. As a musician, I have always wanted to be able to hear what a particular piece of music sounds like without having to play it on an instrument or find a recording online. When a singer is practicing for a performance or an instrumentalist has forgotten their instrument, a “sheet music player” would provide a way to play the printed notes on a page with perfect pitch!

I returned to my design notebook and found my original sketch:

The above object is designed to be small enough to fit into a user’s pocket – providing a portable way to play sheet music on the go. The handheld device features a camera to read the music and a speaker to play it. As the user moves the device across the page, the music plays according to the key marked at the top of the staff. In this project, I seek to test this device’s desirability and usability.

For this final assignment, I decided to use the following techniques for various reasons:

Paper Prototyping to quickly iterate for size and usability constraints. Using cardboard, paper and a sketched UI, the paper device can be changed frequently during pilot testing.

2D Object Prototyping to create a “hi-fidelity” prototype worthy of a real user test. This device can be cleanly cut by a laser cutter in the dimensions verified by testing the paper prototype.

In addition to these techniques, I also employed a modified “Wizard of Oz” method to simulate a functioning prototype. During a user test, I planned on telling the user that I would be “manually calibrating” the device to their position, after which the desired note would play. With the user’s view blocked by my laptop screen, I would play the notes using MuseScore – a sheet music editing and playback tool.

The Design (Paper Prototype)

I modeled my paper prototype after the sketched out design. To decide on a valuable length, I measured the width of my own hand. Before formulating the width of the device, I thought about how it would move across the page. I decided on using a pair of glue-sticks to emulate wheels – their heights decided on the width of the device.

I spent an hour or two cutting mat board into the proper dimensions and attaching the pieces with a thin layer of wood glue:

The Analysis – Part 1

I brought this version of the prototype to Lukas, our teaching assistant, and he rolled it over a piece of sheet music that I sketched out by hand. He liked the look and feel of the device but he didn’t intuitively know what to do with it. Was is supposed to roll on its own? How fast could he roll it? What would happen if he scrolled backwards?

These were excellent questions as the arrow on the top implied a variety of ways that the device could potentially be used. In some user’s mind, they could think that the arrow meant the device was self-advancing – meaning that if they set it down on the paper, it would automatically advance to read the music. Likewise, the arrow could also imply that the device could only read music in one direction. Neither of these assumptions, however, were intended in the original design.

The Re-Design (2D-Object)

In response to this feedback, I decided that a way to show the device could be operated freely by the user – no matter the direction – would be valuable. In a discussion with nearby designers, one suggested that I implement a window to show which note was being played as well as which notes came before and after it.

I attempted to modify my design to demonstrate this new feature:

Unfortunately, this modification would never be able to adjust to the variety of scores that a user may attempt to read. In response to my attempt, my classmate, Daniel (link to his process blog), suggested I use a clear window instead. Within this window, he described a smaller section in the center that would keep track of which note was currently being played.

He sketched out this design, in order to better demonstrate the idea:

The box in the middle shows the smaller section, as described above. The longer box on the side also shows how the device would actually work – using a camera on the right to read in the note so that it could be played when it reached the center of the window. This feature better promotes the various use-cases that this prototype (and eventual product) could support.

With this sketch in mind, I set out to create the next version of the prototype! This time, I used 2D modeling techniques to design a device with a window in its upper portion. In order to support a large window and a handheld size, I decided to mimic the form-factor of a smartphone.

Using the height and width of an iPhone 5 as a guide (and doubling the depth), I drew the following lines for the laser cutter:

The design can be found on my OneDrive here!

After a quick print, the new prototype was ready to assemble:

Fully assembled, the sheet music reader looks a lot like a stud-finder with a speaker on the side. Turning the device around, you can see that there is a camera located on the left of the device. This is used to read the note as it passes beneath the lens – “loading the sound in its memory” to be played when it reaches the box in the center of the window.

The Analysis – Part 2

After using the device a couple of times myself, I set out to test it on a real user. To make the “Wizard of Oz” test easy for me to operate and conduct at the same time, I used a relatively simple song whose tune I could easily follow:

I set up the test as described at the beginning of this post, using the screen of my computer to block the operation of the device. My tested user was a singer who could read music and used the piano to play notes, when necessary. I described the following scenario to the user:

You are in a place where you do not have access to a musical instrument and you are given a piece of music to learn. This device allows you to hear the sheet music by simply hovering over a note. Try to use the device to learn the song and describe whether or not it is useful.

The user immediately grasped the concept, placing the device at the top of the score and moving it across the page from left to right. When asked if there was another way he thought of using the device, he said, "No. [He would] move it from left to right across the page to hear how the song was meant to sound."

He found the device useful, especially if he had never heard the piece of music before. When asked if he would use the device frequently, he said, "Yes”. These answers were satisfactory responses in regards to the Sheet Music Player’s desirability and usability! I am confident that this view would be shared among other musicians and I look forward to future feedback from the musical community in order to further develop this device.

In addition to this test, I also developed a short video describing the problem that the player seeks to solve as well as its use in-context. I also have included a short snippet of the user test itself to showcase its use in-the-wild:

< Previous Project

[protopro-blog]

Mobile Prototype: Lose Yourself (iOS Concept)

Scenario: The purpose of this assignment is for you to expand your prototyping skills from websites to mobile applications. You have a choice of three different apps to design:

Return to your paper prototype assignment and actually implement the smart phone component of the wearable app you designed.

For a new concept, you can implement The Goslometer app (thanks to Jared for this concept).

A redesign of an existing mobile app whose UX you think could stand some improvement.

Or some new concept for a mobile app you have longed for all your life.

Challenge: You will develop a working prototype (medium to high fidelity) of a mobile application. Unlike the previous assignment, in this one you should develop an app that uses more than black & white placeholder assets. You are free to create more realistic looking design elements.

The Design

For my mobile application prototype, I decided to create the companion application to the Lose Yourself smartwatch concept. This wearable prototype was designed to function with a paired iPhone to access its media player and provide additional way-finding features. With this design, I hope to create a way to not only find exciting new places but also become more aware of the world in-between. In the previous assignment, I created a video demonstrating the application’s key components:

A well-designed mobile companion app to this wearable app should act as a way to introduce the functionality of the wearable as well as include a way to access the same features without needing to pair an Apple Watch. Fortunately, this combined feature set was sketched out previously in both the original application design as well as the subsequent ideation of the Lose Yourself application. These sketches can be found in the blog post, “Lose Yourself (Smartwatch Concept)” and are also embedded below:

The above series of sketches showcases a number of important features that must be implemented to create a functional version of the mobile application:

Detect location and generate directions to local Points of Interest

Directions given by audio queues through headphone volume control

Additional way-finding through visual directions if a user looks at the device

Music choice from within the application for a more holistic experience

Apple Watch pairing functions that enable use of the wearable application

In addition, the sketch shows buttons for changing music during travel. Despite its inclusion in this preliminary design, I decided not to include them in the final prototype. Instead, it is implied that users can access media playing functions as they would normally through their Music library or via Now Playing controls.

The Process

With this feature list in mind, I set out to choose a prototyping software. The assignment recommended POP (Prototyping On Paper) with high fidelity assets, Axure for mobile, and Proto.io. Since my application required animated and location-based resources, I thought that these would be difficult to simulate with POP’s limited feature set. Both Axure and Proto.io provide advanced scripting features; but since I already have quite a bit of experience with Axure, I decided to use Proto.io instead.

To get a feel for the software and estimate the amount of time it would take to finish the assignment, I developed the first screen of the application – complete with a dynamic map that centered itself upon screen-load or a press of a button (the GPS icon in the upper left hand corner):

The start screen of the application (shown above with interaction areas highlighted) took about 2 hours to make. Adding a placeholder “splash screen” took an additional 30-45 minutes as I had to learn how to animate with the tool’s “Interactions” feature.

Although the time spent developing new components would eventually decrease as I continued to use Proto.io, I quickly realized that I would waste a lot of time reworking the product if every screen was not planned out ahead of time. With this in mind, I began to develop the functional interface – designing every screen with their essential components laid out in my sketchbook:

A day’s worth of work later, I had a functioning prototype that could route a user from their current location (a random spot in San Francisco) to a random location in a desired radius (Union Park). You can check out the functioning prototype on DESandoval.net (also embedded below):

The Analysis

Throughout the course of the prototyping process, I user-tested my application. From presenting the abstract idea to handing my half-finished prototype to nearby friends, I was able to gather valuable information on what to add or clarify in the application. Depending on the stage of the prototype, I would ask users to try to interact with a specific screen or go through the workflow in its entirety. From these task-oriented tests, I was given the following feedback:

Previously found places should be accessible through another routing application instead of the “Lose Yourself” workflow. This way people can quickly get to their favorite locations found through the application instead of being forced to navigate via audio directions only.

In addition to previously found places, Google or Apple Maps directions (via their native applications should also be available when a user gets lost so that they don’t have to depend on a static list of step-by-step directions.

There are a few bugs where buttons aren’t going to the screens that they should be, these should be fixed.

These suggestions were satisfying as they were somewhat simple and didn’t have to do with any major issues of the product. It seemed that users were understanding the design and even excited by the fact that they could use another method to follow simple walking directions. The suggestions listed above were included in the design and can be seen in the finished prototype.

All in all, users were satisfied with the application. They all commented on how the core features would free them of having to frequently look at their phones when walking to an unknown location in the city.

Some users were somewhat concerned about the phrasing and appearance of the “Someplace Old” features as these would most likely be used to get to an unknown place where only the address was known – not a familiar location where walking directions would not be needed. Unfortunately, none of my users could suggest a better term for this type of navigation but I would love to be able to modify the phrasing to make its usefulness clearer.

I am overwhelmed by the positive response to this application as I find it to be a wonderful way to interact with the city. In particular, I enjoy how Lose Yourself enables the user to be present in what they see in front of them. For a perfect example of this in the application, take a look at the “Got Lost?” screen that a user sees when they pull their phone out of their pocket while following the music to their destination:

Tapping the camera icon opens the phone’s camera to allow the user to take a picture of whatever is around them at the moment. I believe that this prompt for local interaction provides a way for users to be more present in the current moment, rather than quickly providing a solution to get to where they need to go. But don’t just take my word for it, here’s what one user had to say:

I love love love Lose Yourself! I've been playing around with the prototype and it's so cool. I just really like how it brings together technology and whimsy and feels so quintessentially modern in a sense that it knocks down all categories of "human" and "machine" and lets the two work together to make for an adventure :)

“Lose Yourself” is meant to enhance the journey of getting from Point A to Point B by allowing users to let go of their phones and embrace the world around them.

< Previous Project

Next Project >

[protopro-blog]

Website Prototype: Wireframing the dub “Community”

Scenario: The subject of your wireframe prototype is the UW dub website. Pretty obviously, this site is quite out of date, both in form and content. There is very little useful content, and It is in serious need of a complete overhaul.

The result of your redesign effort is limited to the content inventory, information architecture, site navigation, and general screen layout.

Challenge: You are to concentrate on the interaction design, and to implement a prototype of the site in wireframe format. This could be considered a blueprint for a developer to follow to actually implement the site. The purpose of creating the prototype, as usual, is to be able to evaluate the preliminary design with user testing.

Your challenge is to analyze, redesign, and develop a wireframe prototype for a new dub website.

The Design

As stated by the assignment description, “The first phase of the assignment is to analyze an existing website, and understand its current content and functionality.”

The guidelines gave an outline of what content should be in the site. From Announcements to a Membership area, the dub site’s information architecture desperately needed to be wrangled into a practical and navigable format.

Having wireframed legacy webpages in the past, I combined my methodologies with those described in the project description to generate a simple, yet informational website.

Step 1: Content Inventory and Analysis

First, I pretended to be an interested user of the site. I navigated to the homepage and emulated a first-time interaction as a student and faculty member of the University of Washington. In both of these scenarios, the dub webspace was lacking valuable information in many of the places where it was expected. To get a sense of this deficiency, here are a couple excerpts from my complete analysis (available via Evernote):

The “People” [link is] just a list of people with their department next to them - Categorized by Faculty vs. Affiliate Faculty vs. Graduate Student vs. Undergraduate Student vs. Alumni vs. Research Collaborator. [Although] all [of the] names on one page makes it easy to CTRL-F, [there is] no way to change order or sort.

[The] “Downloads” [page contains] various applications, not sorted in any way in particular. [At the bottom there is a] More Downloads [link. These applications are] not as visible for some reason [as they are] at the bottom in a list of links instead of listed as a row.

The quotes above show that there may be an unintentional hierarchy in this community (as presented on the “People” page) that allows for the work of some to be showcased above the work of others. This ranking, along with the lack of an explanation of what the “dub” acronym actually means, gives the first-time user a somewhat negative impression of this community.

As my emulated student, the site feels like a “walled garden” that only contains the intellectual elite. As a faculty member, the space feels unwelcoming as it may be difficult for a newcomer to showcase their work.

This analysis is confirmed by the quote I found on the site’s “Get involved” page, which states:

Do you want to join one of the most vibrant HCI & Design communities in the world? Read about us on this web site!

Step 2: Layout Template and Information Architecture

Through my content analysis, I gained an understanding of the core problems that the dub website was facing. Not only was the site an out-of-date and unordered set of unrelated content, but the content that was ordered exhibited a sense of exclusivity – which is certainly not a value of the “Design, Use, Build” (“dub”) community.

In an effort to put a friendly face on the website, I first drew out a homepage that was more up to date with current web design trends:

I was hoping to create a one-page website so I added a “down arrow” on the right of the simplified navigation elements (labeled link 1-3) to give a user an easy to comprehend first impression.

Following the constraint of simplicity, I then ordered the established content into sections that could fit into three links:

Despite the site’s previously stated issue with hierarchy, I still attempted to follow the current design’s order of importance - which displayed “News” first on the front-page of the site. In the bottom of the sketch, I consolidated the People, Projects, and Publications pages into a “Community” section to allow for dynamic user interaction. I brainstormed this interaction on the following pages as I explored how users could add content to the site – “subject to admin approval” (as mentioned in the sketch, above):

In this sketch, I outlined the workflow of adding new content to the site via the user’s own profile page. On the next page, I outlined the page itself:

Despite the messing writing, this sketch remained invaluable in formulating the complete information architecture of the site. While drawing this image, I decided what information should exist on a user’s page. These decisions established the wording and ordering of the various pieces of content that were previously disconnected.

Step 3: Interactive Wireframe

With the current content organized and the new interaction method established, I delved into Balsamiq to generate an interactive wireframe. Unfortunately, due to time constraints, I was unable to implement the dynamic content workflow – worrying that the planned interaction method wouldn’t make sense without the program’s ability to update previously created webpages.

The final wireframe is available via PDF on my OneDrive (download the file to enable interactivity):

The Analysis

I brought the wireframe to a Tulane University student for a user test. I told her to imagine that this organization existed on her campus and that she wanted to “get involved.” After clicking through the site a bit, she gave the following feedback:

It would be easier if the menu was always available or at least popped up when the menu icon was clicked.

The news and events sections were clear and easy to use. These sections would most likely be the first thing she would check out so that she could attend a seminar to learn more about dub.

The community was “awesome” and easy to understand. Despite the fact that there was little to interact with, the user got a sense of what was possible with the community and how it would function, if there was real content on the site.

When I told her about the proposed content creation method (demonstrated in the “Add New Project” sketch above), she was excited to understand how the “Add New” button would actually work and suggested that I create a message on the sign up page that explained that this was a feature available to users.

If I had the chance to create another iteration of this design, I would add the value-statement mentioned in this last comment. This change, along with an improvement of the interactivity through a login/signup page and filler content for the “more info” sections, would provide a more in-depth wireframe of a dub website. This new site aims to support a more dynamic community that eliminates the unnecessary perspective of exclusivity that plagues dub’s current web design.

< Previous Project

Next Project >

[protopro-blog]

Behavioral Prototype: “Wizard of Oz” Testing a Distraction-Free Pen

Scenario: This assignment will give you experience in using behavioral prototyping to explore a user interaction scenario. As discussed in class, this technique can be very effective in testing design assumptions for HCI applications when the actual technology is either not available or too expensive to develop during the design phase of a project.

Challenge: Build and test a behavioral prototype for one of three following possible scenarios, working in your team:

Speech to text dictation: an application for voice recognition of spoken text, targeted at creating work documents.

Wearable posture/position assistant: a wearable device that assists users with body position and alignment either to help with adopting and maintaining good posture throughout the day, or for proper position and alignment during exercise practice such as yoga, pilates, or weightlifting.

Gesture recognition platform: a gestural user interface for an Apple TV system that allows basic video function controls (play, pause, stop, fast forward, rewind, etc.). 

Regardless of which scenario you choose, you must identify a scenario or use case with a specific set of interactions that for which you want to explore different variations (i.e. creating and editing user requirements document, practicing yoga and trying to get optimal position, or pausing and rewinding a video to view a particular scene again.)

You will need to plan out your prototype, build it, and record an evaluation session with a user (preferably not someone in your class).

The Design

During the class period in which this assignment was introduced, I recalled a previous design that I had always wanted a chance to test. Thumbing through my notebook, I found the idea for a digital pen that would train blind people to sketch on paper:

The idea is that a vibration schema would tell the blind user whether or not they were drawing within the lines. Bringing this idea to my assigned group, we iterated on its use-case until we came up with something that fit into the assignment description. Upon approval from our instructor, we moved on to develop and simulate a tool to help users take legible notes without looking at the handwritten page.

The post below represents the collaborative effort of our group:

OVERVIEW

Working as a group (Will, Anu, Lisa, And Dani), we explored the idea of creating a vibrating pen that would quietly but effectively elicit feedback to users about whether or not they were writing in a straight line. Our primary use case/scenario was for a student who was trying to take quick notes with a pen in a dimmed lecture hall. In this scenario, the user may benefit from our design as it would allow them to focus their attention on the professor and slides instead of their handwritten notes. We were interested in finding out if sensing vibrations in the pen could intuitively tell users how to adjust the direction of their pen without having to look down and possibly miss an important part of the lecture.

Our simulated lecture environment (pictured above)

PROTOTYPE

To test our idea to see if it was an effective solution, we planned out how to develop a functional but "fake" prototype of our product. We didn't have the resources or time to make a vibrating pen that may have included an arduino or other more complex electronics, so we opted to use a remote controlled vibrating device attached to the pen. The device was battery-powered and operated via an infrared remote, allowing us to toggle its vibration on command. We ordered the device in-class as we planned how we would set up the scenario. We decided to use a box around the user’s writing area to ensure they couldn’t see what they were writing out of their peripheral vision. This enclosure would also be used to house a smartphone whose camera would allow us to watch the user write from afar.

The prototype pen

Dani coordinated to have a friend - who was completely foreign to the field and practices of Human Centered Design - to be our participant. On the day of our test, we gathered our materials, built our prototype and set up the testing environment. We used tape and a metal strip to attach the pen and the vibrator together, and tested the remote control.

We found that the device worked sporadically when controlled outside of a two-foot radius, so we devised a way to keep the operator in proximity to the pen. By covering the sides of the tables in sheets of paper and placing the operator beneath the table, we were able to work within this constraint. We set up the box on the top of the table, and cut out a slit in the top for the cameras, as well as windows in the sides to let in light. We then synced one of the cameras to a laptop under the table using a Facetime call. This allowed the operator to see the person writing inside the box in real time.

Testing the proximity of the device

We then set up a second camera on the box to record the participant’s writing, and another device to play music. The music was used to drown out the sound of the remote clicking as well as make the participant feel a little more comfortable. We wrote a series of sentences on a whiteboard which we placed in front of the table for the participant to copy down on the paper.

Before bringing in the participant, we pilot tested the system on ourselves. Will acted as the participant, practicing his writing, while Dani honed their skills, operating the remote under the table.

Our “Wizard of Oz” setup

Once we all got a hang of the process, we had Dani meet their friend and bring her to the entrance of Sieg hall. Upon her arrival, Lisa explained to her that - since the two already knew one another - Dani couldn’t be present during the experiment. While she waited outside, Dani took their position as the operator under the table.

Anu moderated the test, and greeted the participant as she entered the Design Lab. Anu explained that we had created a pen that could sense which direction a user was writing, and would vibrate to signal if it was incorrect. 1 buzz signalled writing too low, 2 buzzes signalled too high, and a long buzz meant that the pen had reached the end of the line. She told the participant that she was supposed to keep her eyes up except when moving to a new line, and to copy down the words off of the board.

We filmed the process and put together a video of the testing:

The participant reacted positively to the pen, having no idea that we had rigged up the system. She was shocked and found the whole process amusing when she realized how we had actually set up the study. We had completely fooled her into believing the device was a fully functioning programmed pen as she was thoroughly confused when Dani appeared from underneath the table. After we explained that they had been operating the device via a remote, she found the test was clever and stated that she would actually use a this device - if it were to actually exist. During the test, she was able to copy down all of the lines - adjusting her writing as she went. These adjustments were made in response to the vibrations with minimal confusion during the process.

ANALYSIS

Overall, we were pleased with the outcome of our Wizard of Oz prototype as the participant believed it to be real and effective in keeping her writing straight. Our group is proud of this accomplishment, especially since we attempted an idea that was different from those suggested by the assignment. The participant claimed that she would use the device and found the vibrations to be an effective way to keep her pen on the line.

Since we planned the majority of the scenario beforehand - having a story and process scripted outright - the test ran smoothly with the participant. The user was sometimes misled by the vibration. She stated that the double vibration was occasionally confusing as she sometimes mistook it for a single vibration. Since we had practiced giving the vibrating feedback multiple times if the pen continued to move off the line, our participant was able to eventually understand which direction the pen was warning against. Had we not worked out some of the kinks before bringing in our participant, the test would not be nearly as convincing.

If we were to do this project again, we would have set up a more convincing “work station.” We were working with the materials we had on-hand, but it would have been much better to have had our operator in a different room with a longer range remote. We could all hear Dani clicking the remote, but due to the needed proximity of the device we couldn’t hide them anywhere else. A different room for our “wizard” would have certainly prevented the loud clicking and the possible reveal of our trick. In the next iteration of our design, we would like to simulate a longer lecture-like environment that includes dimmed lights and a talking lecturer. Since this test confirmed that the device’s interaction model works well, a test more like the real world would confirm if it held up in a dynamic lecture environment.

It also would have been nice to have a smaller vibrating device that felt more natural when attached to the pen. We were forced to tape our large vibrating mechanism to the pen, which made it heavier than normal and misshapen. It would have been nice to have a smaller device as it would have created a better illusion. Fortunately, since the user knew that the device was an early prototype, the largeness of the device went discounted by the user.

< Previous Project

Next Project >

[protopro-blog]

Video Prototype: Lyft (Fund Your Next Great Adventure)

The subject of this assignment is a video prototype that demonstrates clearly and effectively (and creatively) the functionality of a product. Think of this as a concise product pitch that you might use in seeking an investor for your design, which does not yet exist in more than concept or rough mockup. So you have to fake it!

Scenario: For the subject of the video prototype, you have a choice, but all on the theme of transportation. You will not be designing your own product or service, but your task is to explain to a customer of a transportation service why and (more importantly) how he or she would use this service. Select one of the services from the list below, create a scenario-based use case, and create the video prototype for it.

Challenge: The challenge is to create a video, maximum 60 seconds in length, that comprehensively and concisely communicates the motivation, usage, and functionality of a product or service. You should use the principles and techniques discussed in studio to develop a scenario for this demonstration, sketch out a storyboard for the video, shoot, edit and package it.

The Design

Since I was only given a week to produce this video (as I continued to finish up my 3D Object prototype), I searched for a way to display a product in a timely fashion. The spec suggested a plethora of transportation services:

OneBusAway: onebusaway.org

car2go: car2go.com

Zipcar: zipcar.com

Pronto!: prontocycleshare.com

Uber: uber.com

Lyft: lyft.com

I chose the last product, Lyft, as it bridges the gap between drivers and their customers. Unlike Uber, this product is advertised heavily to both college-aged car owners and their (usually similarly-aged) clients in the U District. Given its ubiquity and my friends’ experiences with the application, I felt that I knew enough to make a strong product demo.

First, I asked a few close friends who have driven for Lyft in the past what their experience was like as a driver. I chose to focus on the driver’s user experience as I felt it was an avenue that is rarely explored by advertising videos in this consumer-driven market. Through these informal interviews, I came up with a few core features that stood out:

Driving is easy and can be a great way to make money in-between classes

Most of my friends used it to supplement their budget, not as their sole income

With this extra cash, many spent it on food, parties and traveling around Washington

I chose to focus on the last point in my prototype and sketched out a use-case that is relevant to a large Washington-based event (happening this month), Sasquatch!

With the scenario in mind of “making money to go to a festival,” I sketched out a few scenes in my notebook in the form of a storyboard:

After recruiting a few friends to drive around my neighborhood, I set off to make the video! With the story in place, I was able to film the shots quickly and spend most of my time editing to fit within the 60 second time constraint. The edited video has been embedded below:

The Feedback

When I presented this video to my small group in class, they all found it easy to follow. I blamed this on the fact that they all knew about Sasquatch! and Lyft as well as the various mechanisms that made them unique.

As my instructor pointed out in class, what happened at the end was hard to follow, if you didn’t know what was coming in the mail. The driver was receiving a wristband that he had purchased with the money from driving. This was not very clear as many who have never heard of Sasquatch! would not know that the wristband is the ticket.

Along with this critique, a few other aspects of the video were noted as points were additional clarity could have been helpful:

Adding another way of communicating that the driver had no money would have made the shot of the wallet more compelling. My peer group suggested an icon or thought bubble that depicted a money symbol.

A scene of the driver getting paid would have been useful as well. I thought of him checking his bank balance online during our peer group discussion. They seemed to like this idea as it showed off the modernness of the application.

Some scenes were too long and others were too short. In particular, the shot of the application when it asked, “Would you like to drive?” could have been longer to give the viewer more time to read.

In response to these critiques, I went back to my storyboard and found that, in the rush of filming, I had forgotten the capture the various close-ups that made my storyboard so powerful!

The shot of the driver’s face being sad after seeing his wallet as well as the close-up of the wristband which said “Sasquatch!” on the ribbon both would have been useful to guide the viewer into understanding what meaning each object had in the story. These additions, as well as those mentioned above, would have made this succinct product video even better!

< Previous Project

Next Project >

[protopro-blog]

3D Object Prototype: Headphone-Ready Phone Case

Scenario: The purpose of this assignment is to develop your ability to create 3D models for prototyping physical objects at medium fidelity.You have a free choice of what to model, but your design must use at least one of all of the following primitive operations:

Extrusion

Revolution

Boolean (adding or subtracting one object from another)

You may use any other capability you like in Rhino, but at least those 3.

Challenge: Create the model, convert it to a MakerBot STL file, and get it printed. Keep the size and resolution reasonable -- there are 50 of you who have to get access to the machines, which are not the speediest of rendering devices. Remember, this is just a prototype.

The Design

Like most of my prototypes in this class, I decided to flip through my years of design notebooks to find something that could stand up to this challenge. The goal was to find something that I could design and iterate on with limited access to 3D printers. This meant that the 3D model had to be rendered quickly enough to start printing early, and be modifiable to an extent that iterations didn’t take days to complete.

A sketch from March met this challenge:

In the image above, I detail the three main features of the device:

Tabs stick out of the back of a phone case the allow the user to coil a pair of headphones

Tabs can be pushed to lock the cord in place, keeping the headphones from uncoiling

Tabs do not intrude on the user’s ability to fit the phone (with its case) into their pocket

The sketch seeks to meet the need of users who frequently require access to their headphones. Dealing with this mess of cables is difficult when there is nothing for them to coil around. On the other hand, simply coiling the cables around the phone does not allow the user to access the screen:

With this design in mind, I set out to create the first iteration in Rhino3D:

This relatively simple shape was designed by drawing a series of 2D shapes and using the ExtrudeSurface command in Rhino to draw out a thin layer of 3D material. Given this design, however, I noticed that the device would remain rigid and my second feature would not be feasible. Due to the limited time I gave myself to create the first iteration, I accepted the tabs lack of mobility.

With this constraint in mind, I decided to take advantage of the fact that the assignment called for a boolean subtraction, if warranted. I decided to make a small incision on the ends of the device on which to “clip” the cord after it has been wrapped (the slot is shown within the red square):

After finishing a first iteration, I wanted to test if the third feature - the ability for the device to fit within a user’s pocket - would work in the real world.

Test Print 1 & 2

The first time I attempted to print, the shape was not watertight. This led to a few complications:

By the time the printer began to add the layer which included the cutout surface, a stringy mess ensued and the print was cancelled:

After returning to Rhino and remodeling the surfaces, I was able to print a functioning prototype:

Upon attaching the device to the back of an iPhone, I was able to test the strength of the clip and its form factor:

The form factor was slim and fit neatly into my men’s pants pocket. Unfortunately, I do not think I could print a small enough form for the average women’s pants pockets - but the same could be said for most pocket-sized products.

A Second Iteration

With the form factor in mind, I moved on to a more functional design for my headphone coiling mechanism. Since I normally use an HTC Windows Phone 8, I decided to combine my coiling mechanism with a windows phone case on Thingiverse:

The design turned out great, although I couldn’t manage to get the case to fit onto my phone. After a bit of sticky-tac and a lot of scraping (the supports don’t break themselves), I had a functional case for my device:

The case did not obscure the day-to-day usability of the phone as I wrapped my headphones around the backside:

After researching the proper ways to store headphones, it turned out that a figure-8 style wrapping was the easiest way to keep the cord in order. The inset sections of the case acted as a resting place for the earbuds while the rest of the cord could be wrapped around the device.

Unfortunately, the mechanism itself got in the way of the camera and the low print-quality that I chose allowed the clip to break in just a couple of days:

The Final Iteration

With these adjustments in mind, I set out to further improve the prototype. I went about adding another slot to the device, allowing the cable to be stored in a more secure fashion as it managed to slip out of the small clips during day-to-day use.

To address the image and strength issues, I simply moved the mechanism further down the device and deeper into the case; this provided a more sturdy (and out of the way) coiling mechanism:

After I double-checked that the model’s dimensions would allow for the full range of the camera, I went about printing the device:

The modifications worked perfectly! Not only could this new design coil headphones as efficiently as the last, the new clip solution allowed for a smaller everyday form factor due to less unravelling over time:

As an added bonus, the mechanism also acts as a great phone stand to use while viewing images and videos in landscape mode:

This bonus feature, along with the Spider-man aesthetic proved to be a great surprise as I set out to show off my case to my colleagues and classmates!

The design is hosted on thingiverse, if you’d like to print it yourself!

< Previous Project

Next Project >

[protopro-blog]

2D Object Prototype: Phone Camera Carrying Concept

Scenario: We're leaving this assignment highly unspecified, so you have a lot of flexibility in this. You can come up with your own design, or you can find something online and customize it (as long as your give credit). Be resourceful and creative. All you have to do is make a phone stand that you can actually use with your own phone to shoot a video.

Challenge: Build a stand that will firmly support your smartphone for the purpose of shooting a video. The idea is to be able to use this stand for making your user test or product demo videos of something you want to get a locked down camera point of view on. This could be used for documenting a paper prototype, or interacting with a mobile app running on a phone, or almost any small product demo.

The Design

To come up with an original design, I decided to evaluate all of the times I had used my phone as a camera. I then narrowed down these situations to think of times when I especially needed my hands free. Thinking back to the first week of this course, I recalled how difficult it was to record my smartwatch prototype from a first-person point of view.

With this scenario in mind, I came up with the following sketches:

In the image above, I showcase a few key features of my design. The top of the sketch shows the form of a phone case that has adjustable height and width controls. The middle set of sketches shows how the device would be used while worn around the neck - pointing out how the attached rod would allow for an adjustable height. Finally, the bottom set of sketches shows other uses of the rod as the device is hung off of various other objects.

To test my design and determine the proper height and width, I created a paper prototype:

Using construction paper and an iPhone 5c as a guide, I cut various components that would become the physical versions of what I had previously sketched. With this iteration, I was able to test how small I could make the case without hindering its usefulness. Due to the light weight of the material, however, I was not able to test if this size would remain sturdy upon use.

In order to test the strength of the prototype, I would have to make it with the same materials that would be used in the final iteration. To prepare my design for the laser cutter - which must be used to accurately cut the final mat board - I drew up my previously prototyped design:

The image above shows the prototype after its first test print (detailed below). The circular region that takes up most of the screen is the case itself - the slots on either side are cut out to allow for a string to loop through them. The four blocks below are the adjustable components that slide along the rails in the center. The long stick at the bottom is the stabilizing rod that can be attached to the notch at the bottom.

The Test Print

Before altering the design to have a thicker rod and larger rails, the first test print came out looking like this:

In this design, the rails were only 1.2cm thick and the adjustable components could barely fit within them. The rod was also thinner and became easy to bend in a little amount of time. The components only took a few minutes to fully assemble - allowing me to have a better understanding of how to alter my design:

Adjusting for the noticeable issues, I enlarged the rails to be the same thickness as the interior of the adjustable components. To combat the flimsy material of the stabilizing bar, I also created another set of notches and an additional, thicker bar.

The Final Print

The final design was printed from the following schematic:

As noted above, I intended to use the dual stabilizing bars to act as a third and fourth point of contact when walking around or attached to a stable object. On a stable surface, this worked perfectly! However, due to the fact that the human body is not as stable as I had hoped, the bars did little to keep the device in the correct position while moving.

Here is what the final print looked like:

In place of the bars, I decided to use another strand of string as a third point of contact. I utilized the cut out semi-circles to keep this string attached to the device, allowing me to discard of the stabilizing bars entirely:

Despite its simple demeanor, this prototype works exactly as expected - hanging around my neck without a problem:

As you can see, the iPhone sits in the adjustable cradle perfectly, the two sets of strings stabilizing its movements against my body. The camera appears off to the side of the device - allowing for the flash to work as needed. 

With all of the pieces in place, this iteration was as final of a design as I could develop out of the materials I chose to use. I would love to see how this continues to develop as I continue to design for more complicated scenarios and introduce stronger materials to my process!

The final schematic is available below:

https://onedrive.live.com/redir?resid=a7dc0acf39d74449%21120188

< Previous Project

Next Project >

[protopro-blog]

3D Model Prototype - Quick-Access Shower (Controller Concept)

Scenario: The OXO brand is known for applying universal design to deliver well-designed, comfortable and easy to use tools for cooking and food preparation. They are exploring opportunities to expand their business into new areas that start to incorporate sensors and digital UIs for precision results (think Good Grips meets modernist cuisine tools), as well as expanding into new types of product lines.

Challenge: This assignment is a 3-D lo-fi prototyping exercise for a couple of quick designs to demonstrate how they might apply their core competency in new ways. [Create] a shower control interface for a high-end, multi-feature valve and temperature control. Features include:

product controls and interface/display must fit within the dimensions of approximately 4 x 4 x 2 in volume

product weight is approximately .75 pounds, and should be able to be mounted on a wall

digital display will show settings such as temperature, volume, valves (this could be used to control whether water comes out of the tub spout, the shower head, a handheld wand)

Physical affordances and controls must be easy to use when visibility and dexterity are challenged by soapy hands, steamy showers, and absence of corrective lenses

The Design

Like last week, I had previously designed a shower controller in an earlier notebook:

The above sketch details how a shower controller could be tailored to a user and integrated into an Internet of Things (IoT) configuration. The drawing shows the current ubiquitous designs - a twist-knob that moves from hot to cold and a handle-based shape. In the small box below these figures, I play with the idea of having the shower automatically start at a certain time. In the bottom area, I show how a network-connected device may be used to track water usage, connect to a phone or computer and become programmable via an IoT setup.

Although these may be novel ideas, they were simply too complex for the given scenario. Despite this complexity, however, one aspect of this preliminary design remained helpful as I began to ideate on this particular concept. The ability to tap the device in order to start it as well as read the temperature on a large display became the basis for my future sketches: 

In the images above, I expanded the set of features to be built into the system. In addition to the large-text temperature read-out, I decided to associate a color spectrum with the various levels of hot versus cold. The temperature of 106 degrees Fahrenheit was chosen to be the default display in this image as this is the average temperature of an American shower.

On the right side of the first sketch, I detail how the device works after its first time use. At this stage of the design, I decided that the temperature would be set to the user’s average temperature, rather than the most frequented or last-used temperature. Since seeing my user test the device, the final design automatically sets the temperature to the last-used temperature.

In my final sketch, I show how the rod itself can be used to change the water output from shower to tub (or vice-versa, as I note). This set of features, along with the requirements outlined above, provided me with a strong idea on the look and feel for the first prototype.

The Prototype

In order to satisfy the size and weight requirements, I started my building process with a 4x4x2 (inches) grid:

I marked the 2″ depth on the tube that would become the base of the device - cutting along the mark with a sharp pair of scissors. I then added a circular piece of poster board to the front of the device - covering it with tape so that it could be used as a whiteboard for dry-erase markers. After adding two more particle board components (the handle) and a circular paper ring (the handle’s moving track), the first iteration was complete!

Here’s what it looks like with the default UI elements drawn-on:

The Analysis

With the designed elements in place, the shower controller was ready for its user test. In the video below, I ask a target user to make his way through a series of scenarios:

While interacting with the interface that I designed, the user was able to make it through the desired tasks without any confusion or discomfort. Despite this ease of use, however, I made sure to probe him for feedback - in hopes that he would be able to come up with some critiques for me to consider.

My user, along with another design student in the room, came up with the following points of feedback:

There is no pressure gauge or control on the device

The arrows on the dial are confusing, especially the “shower” arrow

There was too much text on the dial and it felt cluttered

The affordance for the “shower” toggle is confusing, it should be flipped

To keep the device simple, I decided not to implement a solution to the first point - deciding that other methods for controlling the pressure (such as on the shower head itself) were adequate in the average shower.

The second and third point were a difficult challenge to face as they required I work within a small amount of physical real-estate to show multiple affordances. Once I flipped the shower toggle (as noted in the fourth point), redesigning the arrows became much easier!

In the end, I decided to remove as much text as possible - even forgoing the text “Tap to Start” on the front of the device to replace it with a single word, “START”. Removing the “shower” text and rearranging the arrows led to the final prototype:

< Previous Project

Next Project >

[protopro-blog]

Paper Prototype: Lose Yourself (Smartwatch Concept)

Scenario: You are working at a design strategy consultancy (think IDEO or frog) and you have been asked by management to come up with some new concepts for wearable tech products.

Challenge: [Create] a system that combines a smart watch and a smart phone, and... develop a product concept that involves synchronization of data between the two smart devices.

The Design

For this assignment, I decided to iterate on the idea of a smartphone application that enabled local location discovery through music-based walking directions. This concept was generated in January as I searched for new ways to present visual information. You can see the original sketch below:

The image above outlines the basic concept of the application: Music plays and gets louder when you are going in the right direction. In hindsight, the workflow is similar to playing the Hot and Cold game used frequently by parents and educators of young children. The goal of the workflow is to bring users to a previously unknown destination without needing to look at their phone for directions (as well as enjoy their favorite music).

To respond to the challenge presented by this scenario, I thought of how the audio-only directions fell short of providing valuable information while attempting to reach an unknown destination. In particular, I came up with the following questions:

How can the user continue their walk if they are forced to stop listening to the music?

What happens if the user cannot tell where the music is coming from? Do they have to check their phone?

How can I enable a trustworthy user experience that keeps the user comfortable while being guided to an unknown location?

These questions formed the basis for my smartwatch-smartphone paired design. I began to investigate solutions to these questions through additional sketches:

In the image above is separated into two sections (split by the spine of the notebook), “App Overview” (left) and “Screens” (right).

The app overview reiterates the concept of the application, the bottom right sketch showing a mock-up display of how the smartwatch can visually present the same directions being conveyed through the headphones (reiterated on the bottom left portion of the page).

The right side of the page continues to iterate on how the smartwatch should display the paired directions. It also demonstrates how the tapping interaction can be used to bring up music controls (which change the music on the phone) as well as a way to change the color of what my future user called, “the direction orb.”

The Prototype

After reviewing the sketches and considering other workflows, I decided to start making my prototype. To do this, I cut index cards into various sizes and shapes in order to create a paper smartwatch that could easily be manipulated during user testing and demos. I was able to find a spare calculator-watch in the design lab, around which I formed the “viewing window” - which would be used to highlight the current state of the application - and the strips which contained the various screens (image below).

Despite the lack of fidelity in this rough draft of the prototype, a series of steps were made to prepare for the pencil-only design:

Each screen was sketched out individually to determine the necessary length of the final strip:

The necessary number of screens were scored, cut, and painted with white-out to create a mistake-ready surface.

The mocked-up screens (shown above with the prototype watch) were transferred to the single strip of mobile paper:

The single strip of paper allows for the prototype to move fluidly through any screen the user wishes to access. Due to a linear workflow, it made sense to utilize a single strip with animations and context-based events appearing on transparencies or generated with a dry-erase marker.

The image below shows how the screen appears in the watch posture:

The Analysis

After adding color to the screens, the prototyped application was ready for its first user test! My participant was tasked with “walking” to a previously unknown location. She navigated through my screens with ease until pausing when she reached her point of interest.

“What do you do now?” I asked as she stared the exclamation point on the screen (shown above - modified with additional text). “I’m not sure...” she responded, “there’s no instructions.”

I let her know that she could tap the device at any time and she did so to bring up details about her new location. “Oh, I get it!” she exclaimed before continuing with her critique.

When I first presented the “Let’s Get Started” page (shown above), I drew four direction orbs on all sides of the device. The user was not pleased with this presentation as the orbs did not represent any useful information. “It would be helpful,” she stated, “if the meaning of the orbs were displayed somehow. Maybe with a short message saying what direction each orb means.”

Her other critiques focused on a screen that she did not use during the task I assigned to her. She asked how one would get to the media controls screen (shown above - color controls modified to represent volume). I responded by asking her to tap the device while she was walking.

The user stated that this made sense, but would have liked to known that this option was available in the first place. She suggested that I implement something like the iPhone’s lock screen media control (shown below).

My user’s final critique concerned the gradient control which was featured at the bottom of the media controls. She stated that the control was unclear and maybe even unnecessary and that a volume control would be more useful. In response, I decided to combine the two controls - the direction orb’s color instead determined by the volume level itself.

The response to these critiques changed my final prototype to have a more viable user interface - displaying the available controls and relevant directions effectively and clearly. 

The following demo video demonstrates the product’s various features and usability “in the wild” (all the screens are also shown in the images below):

Next Project >