Interaction Design Sprint
In this sprint, I produced a low-fidelity prototype for an app called MALI & DI. The name is an abbreviation for “marine life and diving”. This app can help scientists collect marine life census data. It enables divers to document and upload types of animals, the number of each type, and the locations where they encounter the animals.
After the brainstorming in studio, I determined my user as divers, subject animals as marine life. Then, to link my subject group of users, subject animals, and my app together, and to develop a clearer view about how my user will use my app and the context in which my app will be used, I set up a scenario in which the diver, while diving, uses MALI & DI to count how deep he has dived from his previous location to his current location, which is an motivational feature I designed for this app, then he encounters a group of jelly fish, so he selects the location, takes a photo of the jelly fish and submits the number of the jelly fish along with the name, picture, and location after carefully examining the correctness if all the data.
As you can see in the picture above, after determining the user, the subjected animal, and setting up the scenario, I drew out the interaction flow to help myself figure out this app’s basic structure, features and the approximate number of interfaces needed. The interaction flow, in my perspective, serves as my first draft for MALI & DI. It is very general, and lots of the ideas in it will need to be improved or replaced later during the process of designing interfaces.
These are all the interfaces I designed for MALI & DI. There are seven of them in total. Although they have quite low fidelity, they work very well as the illustration of most of my design decisions. For example, in the lower picture of the middle column and the picture upper-left corner, I have the app’s interfaces for documenting the animals divers encounter by taking pictures and texting. I put a small arrow sign at the lower-right bottom of both screens. I got the idea of using the arrow from the “send” button of text message on iphone, because I want my users to be able to submit the data they collect to the repository, and I want them to able to find the place for submission as quickly as possible. Another example, in the middle picture of the right column, I have the screen for the prompt for successful submission. I put the camera sign and text sign at the bottom so that my users may go back to either the screen of taking photos or the screen for texting, and continue collecting data. These two signs are same as the signs I put in the interface of the app’s homepage, which is in the picture at the bottom-left corner, and the reason why I make them the same is that if a feature on the app appears two or more interfaces, by using the same icon for the feature on all the involving interfaces my users will directly understand the meaning and function of the icon when they switch between different screens.
What’s more, I designed a “wild card” for my app. After my user take a photo of the animals, the app will automatically read the photo and circles out all the possible animals on the photo, and shows the name and number of the animal. If the app misses (does not circle out) an animal, or shows the wrong name or the wrong number of the animal, the user gets to modify it. He/She can add or delete circles on the photo, and can move the circles abound to place them at whatever places they want. The number of animal showing beneath the photo is exactly the same as the number of circles in the photo, and as the number of circles changes, the number of animals automatically changes.
I really like the technique, low-fidelity prototyping to figure out the interaction design, I used this week. The reasons are below.
- This technique allows me to get a quick grasp of designing app prototype, because it requires no coding skills, and no use of professional software like Photoshop. I only need to draw very basic scratch with my pencil, which is very simple and easy to understand.
- Since the prototype is low-fidelity, I can easily erase and change anything that I don’t want or needs to be modified, simply with my eraser and pencil. Therefore, I can reflect my thoughts directly on paper in a fast and straightforward way.
- This technique is very efficient, because by using this technique, I produced a prototype without focusing on the details of the design of the interfaces. In other words, the technique allows me to use the least amount of time and the least effort to produce a prototype that not only visualizes all my basic design ideas about the app, but also works like an actual app when I put it on Marvel.
Due to the characteristics of this technique, such as efficient, easy to master, convenient, etc, it is a very common technique for developers of a company to use. If there are more projects that involve developing new applications, I can see myself applying this technique more often in order to figure out the basic features, basic designs, and interaction flows of apps, with the least time and efforts. However, this technique is limited within the early stages of developing apps, because the prototype is presented on paper, and is static and way too simple in the aspect of aesthetic. There is still a long way to go to move it from paper to electronics, and to make it beautiful and user-friendly.