One of our first sprints in HCDE210 in Winter 2016 was one where we were asked to create a low-fidelity prototype for a “citizen science” app for a smartphone. This prototype was sketched out quickly on paper, inserted into the “Prototyping on Paper” app, and then the interactions were mapped and a video demonstrating its use was produced. [link] This in itself was an interesting project, and so I decided to take turn it into a high-fidelity mockup as to fully demonstrate the interaction design that takes place within such an app.
Using this prototype as a base, I digitized and re-designed each of the screens prototyped. Keeping in mind that the target audience is very broad — a ‘citizen science’ app that can be used by older individuals and younger individuals alike across the spectrum of smartphone ‘literacy’, the interface was kept extremely simple and focused purely on the task at hand: documenting stray dogs in the community. I focused on three guiding principles:
- Interface should be read like a book — from top left corner to the bottom right. Too often we have circular designs (sometimes it is designed in such a way), that loop the user back to the beginning. In this case, this is entirely unnecessary, and so any ‘looping’ designs should be discarded.
- Provide feedback at every stage to guide the user. Users have become so used to programs ‘freezing up’ that any design that involves a user waiting needs to have some sort of visual feedback so they know/think that something is going on behind the scenes, lest they shut down the app. Assume that the user knows absolutely nothing about dogs, and accomodate for that.
- If it has no functional use, get rid of it. “Good design is as little design as possible,” as Dieter Rams says.
Keeping these guiding principles in mind, I re-designed the screens involved within the application. As I went through them, I found an immense amount of flaws in my initial design. For example:
- Interfaces were not consistent. Sometimes the ‘next’ button was at the top of the screen, which throws users off or confuses them when it’s not consistent. — solved by keeping screens consistent, with information flowing from top-left corner to the bottom-right.
- Feedback during loading screens was not adequate, being met by a static ‘loading’ screen is unnerving and gives the impression that the app has stopped. — solved by using a ‘loading’ animation and giving the user constant feed back like ‘Medium size dog: golden retriever’ to guide the user
- The ‘I lost a dog’ function of the app didn’t need a separate mechanism to collect the data and check it against the database of found dogs. Rather than create a new page pertaining to the collection of this data, we could just re-use the UI of the “I found a dog” functionality of the app. — solved by using the ‘I found a dog’ UI for both “finding” and “lost” dog functionalities, thus increasing consistency.
- The “identify the breed of dog” functionality was severely lacking. In the initial prototype on paper, the app assumed that the user knew what type of dog they found. — solved by allowing the user to compare the picture they took, side-by-side, to existing photos of a given breed so they can ‘flip through’ and compare on the fly so we can have the most accurate information possible.
I took a lot of inspiration for this UI from Instagram’s image upload interface, as there are significant parallels between its functionality and Poundprint’s. The thing I found the most helpful in designing Poundprint was Instagram’s use of text instead of icons in certain environment. I feel that often, a lot of designers try to over-design stuff and they end up making things confusing — for example, in the editing panes of the VSCO app on iOS/Android, functionality is signified by icons rather than text, which makes using the app overly confusing because now the user has to decipher what the ‘minimalist’ icon is signifying. I found this refreshing and decided to use that, or at least use text labels near the icons to ensure that the inferface is streamlined and easy to understand.
In the future, I think it would be interesting to build this app out, and test it with some users to see what their responses are to the suggestions that I’ve made in this piece.