Muddy boots (Process blog #2)

Today’s session was all about interaction design, specifically on citizen science. As an intern in a firm that specializes in mobile applications, we looked into ideas that can help our client, a multi-university consortium of biologists, collect data on animals. The collection of animal census data forms the basis of our project.

We first began our discussion with an ideation session, where we gathered in small groups and threw ideas and wrote them down on the table. We looked at specific environments and animals that citizens (non-professionals) could help collect data on easily with our mobile app. Some of our ideas included:

  • mountain climbers, fishermen, hikers, park rangers, farmers (categories of users)
  • frogs in swamps, crabs on the beach, starfish in tide pools, cats in neighborhood (types of animals in different settings)
First stage of discussion for our animal census data collection mobile app prototype: ideation

From these ideas, we each chose a target audience (or user in this case) and an environment and brainstormed individually how we could help them collect data with minimum hassle.

Collection of ideas from ideation

I chose to look into hikers and wild animals that are found along conventional and/or unconventional hiking spots and trails. To create an efficient data collection tool that the biologists can use in their research, the tool had to be easy to use in terms of navigation between functions, insertion of data and knowing what kind of data — numerical or descriptive- to input.

Narrowing down results from ideation, first drafts for prototype

Hikers can help collect data on wild animals found in mountains or forests or by lakesides depending on where they choose to hike. To help our client collect refined data, I included a GPS in the app that tracks the user’s path so they can collect data on different animals’ habitats like how far away from civilization do they live in and in what kind of environment. Hikers also input the sounds they hear on their hike and can also upload a picture of the animal found, along with data on the animal’s proximity and specifically where they found the animals.

On every interface of the mobile app i had in mind, i thought i had to include a button that allowed users to navigate back to the main page with the GPS. I designed a button that iPhone users would be familiar with; it is often used in Google Maps and the built in maps app that users press to find out exactly where they are. I also included the conventional previous and next buttons to navigate between pages and a question mark for various help functions like calling the police, finding functions by searching keywords and contacting nearby hikers for help. All these buttons can be found on every page in the app at the bottom of the screen for easy navigation between functions.

Next, i looked into what would motivate hikers to partake in the collection of data. There had to be benefits for the users too for them to want to download the app and to use it. Thus, i added the following functions:

  • suggest a route for hikers based on how far they want to hike and how difficult they want their hike to be
  • find attraction spots near them
  • warning alerts when they are near areas where wild animals have been spotted in the last 2 weeks and like to appear in
Attraction spot near hiker
Information on animal spotted recently near hiker
Suggested routes based on difficulty level (Left), Drop down menu after clicking on the plus sign on the main page(Right)

I would say the primary motivation for hikers to use the app is that it tightens the hiking community; hikers use the app to help keep each other safe by inputting data on wildlife spotted in the area and this information is able to warn hikers about what animals can be found in the vicinity. Users are also able to share attraction spots they find on their trip with hikers in the vicinity as well with the “Add attraction spot” function in the app. This builds a community of hikers that are connected via the app and shared experiences.

I really enjoyed today’s low-fidelity prototyping for a number of reasons; i liked how quickly i was able to create a prototype quickly and be able to visualize it with the help of Marvel. I think being able to create a rough draft and prototype quickly is super helpful because then, designers don’t spend too much time on details to make a product look pretty when the prototype is bound to be subject to lots of changes. With a prototype and in the process of creating a low-fidelity prototype, I didn’t feel as bad when i had to scrap a page i created completely as to if i spent a lot of time making it visually appealing. I was able to focus on how well a function is delivered to the user and thus make improvements on it quickly.

I think the technique i practiced today(low-fidelity prototyping) will be applicable to almost all my future projects as a user experience designer. Most of the products i may be creating, be it mobile apps or websites or wearables, will need a prototype. I think it is beneficial to create a prototype quickly as it helps with visualizing the end-product and to be able to make changes to the prototype while minimizing time. A possible project could be on healthcare interfaces for patient service associates — the people patients communicate first with upon entering a hospital for information, scheduling, billing services. Low-fidelity prototyping is suitable here because as an intern from a user interface design firm, i do not have enough information on how healthcare systems work and what specific information is needed prior to intensive research and close interactions with the people who actually work in hospitals. I can improve the initial prototype with time.

On the other hand, low-fidelity prototyping might be not be suitable if the project was related to advanced healthcare products or products that are capable of mass destruction if handled carelessly. A specific example could be the machine for lasik treatment for patients who would like to correct their vision. It would be disastrous if a low-fidelity prototype was tested on patients. Low-fidelity prototyping is probably not suitable for developing nuclear reactors either as a hastily put-together prototype could be fatal.

Show your support

Clapping shows how much you appreciated Emma Liao’s story.