Ryan G. Wilson Product Designer

Toggle main menu
Work Examples

MobiCog

Role: Product Designer

Client

Student Project, 2011

Created for: Iowa State University

Project Phases

Discovery Phase, Product Refinement Phase, Development

Tools

Paper/Pencil, Illustrator

Overview

In 2011, I had rediscovered an interest in running for exercise - an inexpensive and accessible activity with a large user base. While running, I often think about how fast I’m traveling and how many calories I’m burning. Thinking about those things, I developed my concept for a mobile application that tracks your GPS location and applies other variables (time, weight, age and height) to return after run results of average speed, distance, and calories burnt.

Problem Statement

The highest rated category in the survey about what people are concerned most about when being active was Enjoyment. Ultimately, the app should be fun and easy to use – able to start using in a few clicks. The results need to be easy to read and easy to access. Other apps have a subscription base to view results remotely. I’m considering the ability to email results to a user-entered email address for them to review at a later date as well as on-screen.

Users

I created a survey to gather information about people’s personal fitness routine (including biking, running and any other ground-based distance activity) and what information they are interested in while being active (stakeholders). I sent out a ten-question survey to 37 people in the age range of 23 – 65, in a variety of markets across the United States. 23 people responded, 22 people completed the survey.

Process

Users will interact with MobiCog before and after working out, so the interface will have to be simple and easy to use. Using Nielsen’s Heuristics, the following should be included in the final design:

Visibility of System Status – the application should visibly be functioning (e.g., results propagating the main text area when the ‘Start’ button is pressed, on a set time frequency and when the ‘Stop’ button is pressed. ‘Start’ and ‘Stop’ buttons should not exist on the screen at the same time.

Match Between System And The Real World – The data shown should be in everyday language/concepts, not GPS coordinates.

User Control And Freedom – Stopping the application and starting again are just a few button clicks.

Consistency And Standards – Button placement and coloring will be standardized.

Error Prevention – There will be limited room for error. The only potential for error would cause the app to crash and restart.

Recognition Rather Than Recall – All interaction will take place visibly. The user will understand the feedback because it will be in a common language.

Accelerators – The final design will incorporate a First-Time-Use Screen, so the user won’t have to enter the same information for each use, leaving the simple ‘Start/Stop’ interaction.

Aesthetic And Minimalist Design – Screen interaction will be simplistic, based on one or two buttons. Data given will be clean and easy to read and formatted for the layman to understand.

Outcome

Looking back on the issues I intended to address with this product, I think that with some additional work, additions (see below), and promotion, MobiCog could be a potential competitor with MapMyRun.com, by offering users the freedom from an interconnected tracking website and providing an email (or other delivery options) or possibly integrating somehow into GoogleDocs to allow for personal tracking.

As for Google MyTracks, the only way to compete would be to make MobiCog available for all SmartPhone users, not just for Android, after the addition of route tracking.

I feel that I achieved most of my primary features: Distance Tracking, Time Tracking, and added in my personal interest that wasn’t as popular in the survey, Speed Tracking. Route Tracking was too difficult to add to the App Inventor prototype.

From a prototype standpoint, App Inventor was ok to use. In the next version, I would want to program the app using a different method that would allow more freedom to integrate other options (maps, route tracking, and such). The next version (mobiCog2.0) has to have route tracking without question, seeing as it was an interest in the survey and from the user testing.

I would also like to be able to layout and skin the next version of the application to match the proposed graphics before the next round of user testing. I think that the users who commented that they wouldn’t use the application regularly might have felt differently if the application looked like it was ready for distribution rather than the wire-frame look it currently has.

Process Document

Process Document