Be like the lawn mower
This case study outlining the process I went through as students at RED Academy working on my first individual project. The assignment handed to us was to interview a classmate and develop an app in which could help them in their problem or frustration.
Hi my name is Jason Ng, an inspiring student at Red Academy to become a UX Designer. As our first week of class just passes, we have already race though the basics of user experience design process.
Opportunity:
Our first project was to produce an app to help with a classmate’s problem/frustration we discover during a quick interview with them. My partner for the project was Gabriel, a mid aged stand up guy that has been happy married for a year and a half. He had a interest in listening to music and reading books. Enjoyed and wished to improve on family relations as most of his family is out of country. He is educated in English at University of Toronto and continued on to teacher college.
Problem:
So there were two problems I singled out. One being his wanting of more communication with his family members afar and the other being organizing his collection of records for him to be accessible at any time. I went with the family communication route as it seemed more interesting to me.
Reflection:
It had been 2 days since we started this project and we needed to present our findings and our answer by the end of the week (2 days later). The snag in the back of my head was still looming. The activities that Gabriel were already kinda addressing the issue he had. The app wasn’t really solving or adding the the solution much. The problem at end hadn’t been solved to the degree I wanted it, it wasn’t clear cut the problem had been solved after the use of the app. I went back to the notes and slides to see if anything could help out with the development of the app.
I came back to the example of the lawnmower. The product was simple and had a sole purpose. The use of the product solved your problem right after you used it. My app didn’t have that, it was failing.
I was in a dilemma. I literally had a day and a half to solve this problem.
Revisit:
I went back to Gabriel about the second problem which was about his collection. I got to know the reason why he would like like to index his collection and have it with him. The example of having a chance to buy a record but not fully knowing if they had it already out of the many records he already was a problem that had a clear cut problem and end goal. I had found my new project.
Research:
So I was to make a list or archive of records. Asking about how people would make such a list, many of them would go about as of writing a list down. A very practical but not very efficient way of cataloging a large about of items, especially when that list will be growing.
Apps that made list all had the common trait that you would type in your list of items or check mark them off a pre existing grouping. Again with typing, and checking off a list that maybe in this case over thousands if not millions of listing is not a practical scenario.
Like a ray of sunshine Gabriel did blurt out an idea to me randomly. He said “Would be great to have a index of inventory like stores do.” My mind flashed to the cash register scanner.
Solution:
Retail stores don’t write down what they own, this isn’t the 18th century. Retail stores have an inventory system built on scanning. Incoming and outgoing goods are put through the system in which records what they have or just sold. Putting that back to our case. What if we were a store, as most collectors are just like a warehouse. Scanning items to record our list of collectibles is just super effective (if not it wouldn’t be used today in retail).
An app that creates list by scanning objects! I know the retail world uses UPC codes, but for fun I expanded the idea to visual covers because visual scanning is kinda a thing and not everything in this world has a UPC code. No more typing and a quick way to report back to you whether you have an item or not without searching for the item in your list yourself.
Designing:
The idea was a simple one with three steps:
- the ability to scan an item and pull up what it was
- to put the item in a list if it is not exist in the list yet
- to report back to the user if the item already existed in the list
The flow of the app was very straight forward. It almost made me think I did it wrong because it was so simple. Fully flushing out the idea would complicate the flow, but not by a lot.
Prototyping:
The version first prototype was set up very quickly the following day. The usability was limited as we were performing the simulation though POP but it would give a good idea of how the app would perform. I gave the product to several other classmates to try. They mostly gave me a positive reaction, without much direction most of them knew it was an app to make a list and it used visual scanning to do so.
Snags that came along where ideas of the app being a photo album app or it was just a list simple list maker. The core function was clear but enforcement of what it truly was for may have been needed. Insights of other classmates about this app’s true target and flow of how they navigated the app initially helped focus the direction of the final product. The difference between a collection and a list needed to be made clear. Making a few more screens about collections gave a bit more context of what the app was doing.
After some redesign and detail to some elements I received a more stable reaction from users.
Summary:
I am happy that I have a somewhat of a product I can called finished. It has been a rush to bring an idea to actual developing stage in such a short time but a very positive experience in my mind. The many suggestions and pointers out of my first prototype helped me push and enforce the idea of what app was for, but it was the clear cut goal of what needed to be done that lead me here.
