In Spring 2015, I took CS160, UC Berkeley's User Interface Design course. Throughout the semester, I and three other team members worked on developing a mobile companion application for an IOT (internet of things) smart laundry machine system.

These sketches helped our team clarify the app's features and what information it would display. They also provided a rough feel for the flow of the app's various screens.

We planned for the app to allow users to

• Find nearby laundromats and their prices
• Check for free laundry machines
• Reserve machines
• Adjust machine settings
• Securely lock and unlock machines
• View progress and remaining time for different laundry jobs
• Receive alerts for finished laundry
• Pay for laundry

We observed and interviewed users at various local laundromats.

Time and convenience was of the essence for our interviewees. Their most major problems lay in wasting time waiting for machines, forgetting to pick up their laundry in time, and being forced to wait at the laundromat for fear of their laundry being stolen.

Thus, our application's main value would be in streamlining the public-laundry process by reducing wait times. Features such as locating nearby free machines and reserving them in advance, being able to lock and unlock machines from the app, and receiving alerts when laundry was completed were essential.

We tested our low-fidelity mockups at local laundromats. For each participant, we explained the purpose behind our application before asking him or her to complete our three tasks: unlocking the machine (easy), finding a nearby laundromat and reserving a washer (medium), and scanning a clothing item to create and save a laundry preset (hard).

Major insights from these interviews were that

• Various interface elements were confusing (numbers on the home screen, plus-button on the laundromat screen)
• On some screens it was possible for the user to become trapped and unable to backtrack to the home screen
• Users were hesitant to create their own settings, and were more comfortable with using and modifying presets
• An onboarding process or help documentation would be useful

I created hi-fidelity mockups for all the different portions of our app, and generated icons and other assets as needed.

We deployed our app successfully using the Kinoma Create platform.

Ultimately we ended up scrapping the feature that allowed users to scan a clothing tag and receive an automatically-generated preset. User testing showed that this feature confused many users, and in interviews they said that they would most likely not make use of this feature. Fine-grained control over one's laundry was not a feature many people cared about.

CS160 provided a great introduction to the iterative design cycle. Here are some of the major lessons I learned:

• Don't assume anything about the user. Not everyone is a tech-fluent millenial, and not everyone interacts with technology in the same way. A great app should accomodate all kinds of users.
• Build, but not too quickly. Our app changed course several times throughout the semester. A good design has room for change; don't obsess over building features that you haven't tested with users.
• Communication is key. Features that seem great from the engineer's perspective may not be useful to users, and features users would like don't always occur immediately to engineers. The only way to know for sure is for engineers to go out and talk to users.
• Don't be nervous. We assumed that we would have a very difficult time finding people who were willing to sit down and go through a user test with us. We were wrong. People are kind, curious, and oftentimes very eager to give their opinions. Approach them with a smile, and they'll often respond in kind!