Track That

A versatile solution for all your tracking needs.

Goals and Research

Goals

Our goal as a team for this project was to create a general tracking app from start to finish. We needed our app to be versatile and be able to meet all different kinds of tracking needs.

Target Audience

We identified three (3) target users for this app:

  1. Students who want to reach strength goals through exercise.
  2. Students who want to reduce everyday finance spending and meet specific budgeting goals.
  3. Students who want to reduce their time spent on social media to be productive.

We chose these target users because they are easily accessible on a college campus, represent a diverse set of needs, and we hypothesize that the users’ target desires are common problems among students.

Research

We conducted user interviews with students who want to reach strength goals and reduce everyday finances. Interview-style data collection allowed us to learn about the users’ personal experiences and perspectives with these intentional and measurable activities.

On the other hand, we conducted field studies with our users who wanted to reduce time spent on social media. We chose this method rather than an interview because users often do not measure and are unaware of time they spend on social media.

From those wanting to track strength/fitness progress, we learned:

  1. Users follow pre-made workout plans throughout their workouts and log progress during and after sessions.
  2. Users mainly use text to record data through basic apps such as Notes or Excel.
  3. Users have the following issues with fitness apps: Have too many steps – Are not customizable – Lack visuals (diagrams, photos, etc).

 

From those wanting to track everyday finances, we learned:

  1. Users do want to reduce spending, but many fail to do so because tracking finances takes time and effort.
  2. To check spending, users look at their bank statements.
  3. Users’ overall goal is to gain financial independence.

 

From watching users use social media, we learned:

  1. When studying, users keep social media and academic tabs open at the same time on their laptop browswers.
  2. If somebody near the user opened social media or checked their phone, the user would do the same.
  3. Users check social media for a few minutes at a time, many times throughout the session.

Prototyping and User Testing

Paper Prototype
paperprototypett

We tested our paper prototype with five people from our target group. After testing, we found we needed to:

  1. Improve the language of our app.
    • Our language of “categories” and “items” were ambiguous and our users were not sure what to input.
    • The conversational style of our application was too robotic/formal.
  2. Add more navigational buttons, like “back” and “edit” buttons.
  3. Make the flow less heavy.
    • Users felt it took too many clicks to input tracking. They had to create a category, create an item, and then an entry.

We also learned that users did not care that much about creating goals. They were satisfied with tracking progress and inputting data, but creating goals to meet were not as important.

Wireframes

 

wireframestt

After user research and interface iterations, we decided on a flow that both utilizes friendly human language and reduces the number of steps necessary for functionaltiy. Specifically, we:

  1. Put all primary components visible at once on a dashboard, reducing the number of clicks/taps necessary to start tracking.
    • We came to this format by paralleling the tracking to Google Drive, where “Collections” are folders and “Trackers” are files.
    • Initially, a user would be required to create a “category” in order to create an “item”. For example, they would have to create a larger category of “Fitness” to track “weight.” We de-coupled this so that user can create “Trackers” without necessarily creating a “Collection,” but can add to a collection if they choose.
  2. Created a conversation between the user and interface.
    • Instead of generic and robotic labels that would confuse the user, we ask the user questions to create trackers and input information.
    • We tried to ask questions in our language, like “What do you want to track?” instead of just telling the user what to do to enforce that conversational tone.
  3. Simplified the information display.
    • Throughout the planning process, we found ourselves straying away from the MVP and adding unnecessary features. We were trying to figure out how to add a “goals” feature, but when thinking back to our users, none of our users specified that they wanted to track goals. They wanted to focus on progress. To meet our value propositions, we changed the “goals” feature from a numerical calculation to a simple notification with text that they could modify themselves and look at for moral support.
High Fidelity Prototype
homepage
createtracker1
createtracker2

 

Implementation and Deployment

Track That is a progressive web app. As a team, we used the Vue framework to build our app, and Github for version control. All members of our team were involved in both the technical and design aspects of the code. 

You can test out the app yourself and start tracking today: https://track-dat.herokuapp.com/

After deploying Track That, we conducted our final rounds of user testing. Overall, we had positive responses to our application design and a lot of design decisions were validated through user testing. None of the users from our target audiences had major issues with the flow of our application, but there were small fixes that we recognized could help increase the user experience. We made the following final improvements: 

  1. Fixing delete entry: we found a small bug during testing, in which our entries would not accurately delete and fixed the bug.
  2. Reduce header size: Feedback included reducing header size. We also noticed in testing that the text took a lot of space on the screen and would prevent users from seeing content at the bottom.
  3. Indicate required fields: in user testing, some users did not know which fields were required or optional. Our application does require some fields and so we indicated those with a *.
  4. Placeholder fields: for users that might not be sure what value to enter in certain fields, adding placeholder text will help them understand the purpose of the input without being intrusive.
  5. Make graph functionality more clear: for successful graph functionality, our application requires that at least two entries are made on two separate dates. We did not make this direction clear and as a result, users were getting confused when the graph did not show.
  6. Add “create collection” button: by adding a create collection button in the ‘create tracker flow,’ users use less clicks to organize their data.
  7. Clarify deleting a collection: previously, users were confused how their trackers would be affected by deleting a collection. We added wording on the ‘delete collection popup’ to clarify trackers would not be affected.

Takeaways

Completing this project was a huge step for me because it was the first time that I was fully involved in every step of the process of creating a product. From researching, to prototyping, to user testing, to implementation, this project tested and improved all of my User Experience and technical skills. One thing that I was particularly proud of was that I got to use and improve my coding skills. Creating an app from the bottom-up without any assistance was a really daunting task, but upon completion I realized that it was not as difficult as I expected and that I should have more confidence in my technical abilities. A final plus from this project was that I now have a tracking app of my own that I will be using constantly!