Design
Login page
The Login page is the first page the trainer sees. We wanted a simple user interface that allowed both the athlete and trainers to login.
Trainer - Home page
Logging in as a trainer takes them to the Trainer Homepage. The trainer's home page presents the trainer with athletes that he or she has been working with, giving them a snapshot of the health and injury status of the athletes they work with. The user can view the profile page for an athlete by clicking on their thumbnail if it appears, or using the auto-completing search bar if it does not. If the trainer wants to add a new athlete, clicking on the "add a new athlete" button brings up a form to enter a new athlete into the system. The look and feel of this page has changed very little since the original paper prototype. One important difference is the way new athletes are created; rather than having a "+" button next to the search bar, the button now explicitly states that it is for adding a new athlete. This helped with usability for first time users, who did not understand what the plus button represented.
Trainer - Individual Athlete
The trainer can view an individual athlete's program. The trainer can see his personal info (name, hometown, sport) as well as information about his health, injury history, and workout plan. In the upper right corenr of the screen is the athletes status; a short summary of his current health and buttons that allow the user to change that status. Below are three tabs: workout program, injury history, and notes. The workout program is the most interesting of these. On the left, the user can find exercises that can be added to the current program by dragging and dropping into the current workout. The sets and reps of exercises can be changed by clicking on the values, and exercises can be removed by clicking on the "x" button on the right.
Clicking on the injury history tab will bring up a list of the athlete's previous injuries and clicking on the player notes tab brings up a list of notes, which can be added to by typing in the box and clicking the add note button. This page changed significantly from the paper prototype. We removed images of the exercise to make the page aesthetically simpler, and changed the way dates worked. Based on the feedback we received, we decided that rather than having "Day 1", "Day 2", etc. it was better to organize the workout by weeks. Also, since many users seemed confused by the ambiguity, we changed the interface to give concrete dates as well. Finally, many users, in all of our user tests, struggled with adding exercises to the workout. Most didn't intuitively guess that exercises needed to be dragged and dropped, so we added a help message that told them this.
Adding a new athlete
The user sees this page when they want to add a new athlete to the database. This page allows them to enter vital information about the athlete. It has changed very little since our paper prototyping sessions.
Adding a new injury
Adding an injury to a student takes the user to this page, where he or she adds the basic information needed to update the athlete's profile page. We originally had the user enter a custom date, which caused formatting problems once we began implementation. We changed the date field to three separate input boxes for day, month, and year. Unfortunately, this added another level of confusion because users were unaware if January was 1 or 0.
Implementation
We used Ruby on Rails with Twitter Bootstrap as the main components of our implementation.
One workout per athlete - We chose to give each athlete one workout. We felt that an athlete can only be completing one workout at a time, so it seemed superfluous to assign them multiple workouts in the database. This design choice simplified the back end of our system, but limited some of the features we could add. For example, with only one workout per athlete, we could not show the workouts they completed for previous injuries.
Athletes belong to one trainer - We modeled the system to have each athlete belong to one trainer. MIT trainers say that each athlete works with a single trainer, but this limited other trainers from editing the workouts. Although it reduced the flexibility of the system, it provided a level of safety that only allowed the specified trainer to edit the workouts.
Two Way Notes Communication - Both an athlete and a trainer could add notes to the athlete's log. Originally, we built the system to only allow the trainer to store notes about the athlete. However, allowing both groups to write notes back and forth offered a more interactive communication between the student and trainer. We also added colors to the notes. We intentionally did not specify what the colors represent, giving the trainer the freedom to use the colors as they pleased.
Reordering of exercises - In our original decision, we wanted to add the ability to reorder exercises within a workout. However, implementations problems prevented us from being able to include this feature. (The feature actually worked, but it broke the drag and drop functionality. We felt the drag and drop functionality was more important to the overall usability for the trainer).
Evaluation
Users:
We conducted our user test with two MIT athletic trainers and one MIT student who has had a lot of encounters with athletic trainers. Since the site is a tool for athletic trainers, the athletic trainer is the core of our target population. We also needed one MIT student because they were the target user for the athlete side of Easy Trainer.
Briefing:
The users were given basic information about the class and the goals of our website. They were told that we would give them a set of tasks, observe them while they completed the tasks, and discuss any suggestions afterwards.
Tasks:
1. Create a new athlete, Josh Smith, and update his injury status to reflect a broken ankle.
2. Mark Kobe as healthy.
3. Remove lunges from his workout and add Clean and jerk (3x15) and add rows (3x10) for all 5 weeks.
4. Add a note to his profile saying that he’s recovered from his injury.
Usability Problems
Trainer 1
The trainer didn’t recognize a body area in the ‘create a workout’ tab and tried clicking ‘select a different body area’ label to search for it. This is not very severe. We should just make the label a search bar for body areas not being displayed. This is also a function of the fact that we did not have a complete set of exercises any every body part available.
The trainer was confused about how the alphanumeric translation of dates to numbers. It took much longer than needed for them to enter the date. Additionally, they suggested that she records injuries on the day they occur, so pre-populating the date as today would be a big efficiency improvement.
The drag and drop functionality in ‘create a workout’ wasn’t obvious at first. This problem was originally discovered in our first computer prototype. To mitigate the confusion, we added text in the workout chart that said 'Select a Body Part', and then 'Drag Exercises Here'. This made the drag and drop more apparent, but the trainer still clicked on an exercise twice before dragging it into the chart. The drag exercises here message should also be displayed on click and not just drag.
The trainer missed the significance of the colors in the note section.This is not very severe. Perhaps we could make selecting a color change the background of the input text box also to indicate the message will have that background. The trainer submitted a note without choosing a color
She felt like we should be able to edit multiple days of reps for a single exercise at once. This would be a minor change, and definitely a good suggestion.
She also said it would be nice to have a way to contact the athlete when updates to his profile are performed.
He thinks the dashboard player boxes should have more information such as the most recent note. He also suggested that a sort of news feed for recent injuries and notes could be nice to have on the dashboard also. Also, we could have minimized the time spent to find an athlete by having the cards on the trainer homepage change based on the text entered into the search bar. For example, if you start to search 'Ko..", then only athlete's names that have 'Ko' in their name cards visible. This feature would also provide visual feedback.
Trainer 2
When told the update a player’s injury status, this user was confused by the ‘select a body area’ list in the ‘create a workout’ tab. This is somewhat severe. Perhaps the create a workout area should be grayed out when the player is healthy. This would take attention away from the sidebar. On the contrary, a trainer may still want to prescribe exercises to a healthy athlete, so we are caught between design flexibility and learnability.
This trainer understood the significance of and used the colors for athlete notes.
This trainer had no problem at all creating a workout.
The trainer suggested that there be a way to batch upload all of the athletes into the system. The trainer commented that they have the same athletes all year long, and it would be very time consuming to enter all the athletes by hand through the 'Create An Athlete' form. To solve this problem, we could potentially create a table layout where a trainer can upload multiple athletes at once.
The trainer mentioned the ankle sprained exercises are pretty similar so it would be helpful to have all the ankle exercises in the workout already. This is a great suggestion and would be implemented in the next iteration.
Student 1
The student effectively logged in to the athlete page
The athlete understood the athlete's workout chart, and injury history. The student was also confused about the colors for the athlete notes.
The athlete commented that the workouts would be on a mobile phone, so this desktop interface was not useful to athletes. In order to address this, we could add a mobile design for the athletes to view on their smartphones.
With paper, the athlete mentioned they can write down the number of sets and reps they were able to complete, which you can't currently do with Easy Trainer. Our interface does not allow notes next to the exercises. We can add a way for athletes to check off exercises as they complete them.
Reflection
There were two big things we took away from this course that we think we had all undervalued prior to the course: prototyping, and user testing. Most of us thought that going into this class we would learn more about what makes a good UI rather than the process of creating one. Even when presented with these ideas, some of us thought the idea of creating a paper prototype wasn't worth the time. It seemed nearly as easy to make the website in html and then later change whatever small things needed to be changed. I don't think any of us realized that getting a good UI on the first try just isn't going to happen, and the paper prototypes definitely allowed us to see problems with our UI before we created it. It was pretty surprising how some of the elements in our UI that we considered intuitive were anything but to the users we tested.
We also learned about the design decisions you take for granted. When you are the designer, it is easy to assume that your users will have the same understanding of the system. You cannot simply pretend to be a new user. You must actually go out and have users play with your prototypes. It's amazing how a new user can identify a problem in seconds that our entire team missed all semester.