Final Writeup


At the start of the course, Team Soul Patch wanted to create an app to people become happy and healthy through fitness. Given the difficulty in bypassing gym administration to access gym goers, we decided to interview and focus on personal trainers. Personal trainers are not only happy to meet with us but also are a way to influence many clients through one person. Having this network and domino effect positively impacts lives of many people. Furthermore, most existing apps don't help trainers, but instead work to supplant them. Few fitness apps tailor their functionality to the needs of personal trainers, so it is a prime area to target.


To help personal trainers be more effective, we developed a tool that allows them to better achieve their goals and their client's goals. As personal trainers, they want to maintain their own fitness while aiding their clients. With functions that focus on goals, our FitLog application is designed to help the trainer to define their clients’ goals in a succinct and explicit manner. The application is also designed to make tracking exercises and data visualization smooth as butter. It should be as easy as possible to enter a workout for a client, so the personal trainer can spend spend less time managing statistics, and more time training and motivating clients. With relevant data visualization, trainers can get a sense of what works and what does not work for their clients. Overall, FitLog addresses the personal trainers’ needs of time-efficiency and goal-orientation.


These are the two personas we focused on. You can read about our third persona on our website.

Mike Spiros the Life Coach

Age 41


Mike is a recently divorced single father, who devotes his life to one mission: making people healthy. He started his own business as a personal trainer because he wants control over every aspect of his training--he targets his training to fit his clients very specific goals, and gives them advice about everything from exercise routines, to diet and daily habits. He owns his own equipment, and doesn't use a gym, opting to instead make home-visits to clients. Mike feels pressure to stay fit, to set a good example for his clients. He is constantly working, either researching health facts, texting clients with reminders, or shifting around his schedule to incorporate new meeting times. He feels that all his effort has gone to waste when clients don't show up for sessions.


Mike Spiros is driven to influence and change the lives of his clients in a positive manner. He has lost control of his own life in over scheduling and through divorce so grappling for control in the lives of others is really satisfying to him. He has a lot of life experience and feels important and helpful when he is able to impart his information and advice on others who need his guidance and influence. He believes that helping people is a privilege and values the time he has with his clients. Mike makes a conscious effort to try to understand what his clients goals and aspirations because he genuinely wants the best for them.

Ben Sakai the Partner

Age 28


Ben was obese for most of his childhood, and when he attended UCSB to study astrophysics, he took the opportunity to turn over a new leaf. He committed to lose weight, and change his lifestyle. He became an avid mountain biker, and learned to love health food. After graduating, he moved to Arizona to enjoy the outdoors and work part-time at an observatory. Ben started to work part-time as a personal trainer at a local gym because it was very rewarding to offer hope to others who wanted to lose weight. In his eyes, his clients are partners, and friends. He talks with them throughout the week via email, and chats in person while doing workouts. He specializes on 1-on-1 training, and whenever he takes on a client, he never compromises his own personal life schedule to accommodate clients.


Ben Sakai’s main goal is maintaining his own fitness. As a former fat boy, he values the importance of keeping himself healthy and happy. Through his journey, he realized various tips that can help people also make the large, sometimes overwhelming, positive change in their lives. For Ben, he wants to help his clients achieve this new, healthy lifestyle through working together and making the right changes together. Ben helps people to keep himself motivated to be healthy as well because seeing his clients reminds him of how he used to be and what he needs to do to maintain how he is now. He also feels great when he knows that he has taught someone well. With this in mind, Ben constantly strives to be helpful to his clients but also steps ahead of his clients. He has to be in better shape than them. He also finds it very rewarding to work with his clients when they make the same breakthroughs and realizations as he has. He feels like a mentor and friend, which helps to continue acting as his impetus in this training profession.


We have two task scenarios: adding workouts and adding body measurements.

The first scenario prompts the personal trainer to add specific exercises and workouts to their clients profile. As the script prompts, “Your client, Hugh, just did some buns-up leg presses. He did three sets: the first set, he did 10 reps at 120 lbs. The second set was the same. The third set, he did 8 reps at 120 lbs.” In order to make sure that this process was as intuitive, we wanted to make sure that the way the workouts were listed made sense and that enough information was relayed to the trainer. Furthermore, we wanted to ensure that trainers could easily figure out how to edit workouts that they already logged and that it was clear that they “saved” workouts. We focused on finding the best way to relay to the user that a workout has been saved.

Our second scenario asks trainers to input their clients body measurements and see if they have made any progress in relation to their fitness goals. As the prompt asks, “ Your client, Hugh weighs 190lb now and his thighs are 20in can you input his new measurements? We wanted to make sure the interface was straightforward and allowed trainers to input client measurements quickly.

The Final Interface Design



Trainers will be able to track their clients measurements or view previously tracked measurements by selecting the measure button on the bottom left. When a trainer selects a client on the homepage, he/she will immediately see an option to add a measurement. Upon selecting “add a measurement”, the trainer can select the relevant measurement category (arms, forearms, neck, chest, etc) and input the inches or lbs. The trainer will also be able to see a list of previously logged measurements and will have the option to edit them.


Using the workout button, trainers will be able to track client workouts and exercises and view previously logged workouts. When a trainer selects a client on the homepage, he/she will immediately see an option to add a workout. Upon selecting “add a workout”, the trainer can either add a workout by selecting it from the list or can search for a workout using the upper search bar. Once the trainer selects the specific exercise, he/she can input the amount of reps, weight, miles or min that the client has done and will be notified that it has been saved. When they are done inputting workouts, they will be able to see a list of previously logged workouts and will be able to edit them if necessary.


The progress page helps the trainer to see if their client’s workouts are helping them reach a fitness goal. By showing graphs that are directly related to a client’s goals, trainers can view how their workouts are advancing the clients towards achieving their specific fitness goals.


While we did not focus on the goals page, the premise of this page was to help trainers specifically define what their clients goals were. Whether a client’s goal is to “look better” or “fit into a dress”, part of a trainer’s job entails decoding exactly what a client wants to achieve. This goal functionality allows a trainer to type in what his or her client wants to achieve and offers tips on how to make it more specific and quantifiable for tracking purposes.

Interaction Flowchart

Unimplemented Features


Our vision for the app is that the trainer could type up the clients goals, and it would use natural language processing to pick out details so it could intelligently display progress towards that goal. For example, in this prototype, we can see it prompting the trainer for more information. Does Dave want to lose weight, or is the goal more specific? The trainer ends up writing that Dave wants "thinner thighs." The app recognizes this goal, and automatically remembers to put the "thigh circumference" and "weight" measurement at the top of the measurements page. If the trainer ends up recording those measurements, the app will create graphs showing the history of Dave's weight and thigh circumference, because those directly relate to his goals. Dave will, hopefully, be encouraged by these graphs, and the personal trainer can use them to gauge the effectiveness of Dave's workouts with respect to his goals. Natural language processing would have taken too long to implement, so we didn't take goals past the paper-prototype stage.


Our largest regret is that we didn't have more time to design data visualizations for the workouts. Graphs of clients progress over time is a feature that could make our app very useful for trainers. It would have taken an immense amount of usability testing and coding before we could create a good graph to represent the data we collected. We would have wanted to incorporate data such as the client's most common workouts, the clients goals, and the current date, the frequency of the client's workouts, and how workouts change over time in order to selectively display the most relevant, context-sensitive , information for the trainer. We would have attempted to reduce interaction with these graphs. They should be smart enough that the trainer only need open the app to see exactly what he wants. Graphing is such a large project, that it is almost worth another whole semester of design. For example, we would have needed to answer such questions as:

  1. How many days in the history of the clients workouts does the trainer want to see in one graph? Should we display everything? Only the most recent ones?

  2. Which measurements are most useful to the trainer? Number of reps? Weight lifted? Arm circumference?

  3. What workouts does the trainer want to see represented visually? Which does the trainer not want to see?

Prettier Graphics

We redesigned the graphics in photoshop near the end of the final design refinement, but didn't prioritize changing the look of the final prototype. We believe that prettier graphics would have made for a more enjoyable experience using the app, but it wasn't our focus because we were busy working on the unfinished interaction design details.

Predictions based on previous interaction and context

If we had more time, we could have made our app context sensitive. For example, we wanted the workouts most commonly used for a specific client to appear at the top of the "add a workout" list, so the trainer wouldn't need to search for them. Likewise, we would have liked to have the clients with the most recent appointments and the closest upcoming appointments to appear on the top of the clients list, so that the trainer rarely needs to scroll through the clients list when selecting a client. We could even go further and launch the app with client Dave's profile open if the app recognizes that the phone's clock is at the same time as Dave's typical appointment.

Context and interaction history is difficult to prototype, because our app is not being used on a real phone, and does not have access to real data from a trainer. We could only design these interactions, not implement them.

Adding a client

Although the workflow for adding a client is important, it doesn't happen nearly as often as adding a workout or a measurement. We made this a lower priority during our Balsamiq prototype, and dropped it from our final prototype in order to focus on the workout-adding mechanism.

You can walk through our initial "add a client" workflow in our Balsamiq prototype.

Small bugs

  1. Measurement editing doesn't work as well as we want. It should make all the currently added measurements editable, not just show a list of measurements to add.

  2. The screen doesn't scroll up when a workout floats to the top of the list on an iOS device.

  3. We can't add a workout for any day other than today.

Tools Used

Tools used for prototyping and implemeting the UI

We used pencils and note cards for our paper prototype, then Balsamiq, then we started writing everything using HTML, Javascript and CSS on the front end, and Python (Flask web framework) on the back end. We used the basic jQuery library, but didn't use any UI tools, or iOS frontend web frameworks because we couldn't find many that were flexible enough for our needs.

Pros and cons of using these tools

Pros and cons of not using a UI library

It took an extremely long time to prototype the frontend from scratch. If we had found a front-end iOS UI framework, we would have had a much faster time prototyping, and saved ourselves some pain. On the other hand, not using a framework gave us the flexibility to make it look exactly how we wanted. If we were to do another iOS prototype, we would probably use Ratchet , a new, lightweight iOS framework that was released the day after we finished most of the initial work on our prototype.

Pros and cons of writing a backend

On one hand, our app was reliant, more so than most, on persistent data storage. The whole premise of our app was editing and adding workouts, so if we had done our prototype using only the frontend, we would have been limited to a few pre-populated examples. On the other hand, the Django backend gave us a lot of trouble because we were trying to prototype very fast, and it was difficult to make changes without breaking something on the server-side. It would have been much easier to prototype with no backend, so we would definitely write everything on the frontend in future design projects, to give ourselves more time to devote to actual design.

Design Evolution

How the UI changed

Though we made dozens, if not hundreds, of changes to our design throughout this process, each major stage was clearly marked by major changes along a single theme. These major changes were motivated by the nature of the feedback we received between each phase, and as we improved the interface, the major changes were smaller in scope, and the feedback that motivated them less severe.

When we first drafted our paper prototype, we made two major errors in our design. The first error came from an idea we thought was novel: allowing trainers to filter workouts according to the body part the workout affected. We implemented this feature by having human body on the workout adding screen, as seen below.

Filtering workouts by selecitng a body part

Our user testing showed us that people did not realize that you could click on these figures to find workouts. Furthermore, having a split image of the body was unfamiliar to our users who have been trained to view detailed muscular systems.

Our second major error had to do with organization and visual design of icons. We had icons along the top and bottom bar of the app, but the relationship between icons located in the same containers was not clear. In fact, we had some icons that referred to all clients in the same container as icons that referred to a single client, which caused a large amount of confusion for our users during testing.

Disorganized icons without captions can be confusing

Since these icons were only pictures, our users had to rely on their interpretation of these pictures in order to translate an icon into an action. Unclear icons made users navigate to pages inadvertently, breaking their task flow.

With these errors in mind, we proceeded to porting our prototype to Balsamiq, an online tool that simulates paper prototyping, but allows us to iterate quickly and work collaboratively.

Once we’d created the prototype in Balsamiq, we fixed the major errors from our paper prototype. We removed the body parts from the screen for adding workouts, which made the available actions a lot more clear. We also created new icons, and included captions, to decrease the amount of interpretation the users have to do.

We then conducted further tests with our Balsamiq prototype, and realized we had another two major errors we had to fix. Both of these errors had to do with our lack of understanding of how users, and their fingers, interact with iPhones.

Our first error was adding individual ‘+’ buttons next to each workout. We thought adding buttons next to every workout would make the purpose of the button clear. While our users weren’t confused with the purpose of the ‘+’ button, they did find the new workout list very cluttered, and their fingers had trouble discerning between separate buttons. Simply put, the touch targets were too small, and there were too many of them.

Small touch targets are difficult to interact with, and too many of them can clutter an interface

To fix this, we simply made each list item (a workout or a measurement) a clickable "button", that triggers the adding task. This fix was implemented in our functional prototype.

When users chose to add a certain workout, the screen split and showed the users a place where they can enter the weight and number of reps that the client did for a given workout. We chose the same iPhone control that’s for entering dates to enter these numbers, which we soon realized was a mistake. We tried out the control on our own iPhones, and realized that using it is neither fast nor accurate.

Scrolling to the correct numbers on these barrel controls is time consuming

As a result, we decided to change these to small text fields, where users can enter workouts using the same number pad that is used for entering telephone numbers. This reduced the time and error rates for entering a workout.

Number pads are common, easy to understand and quick

Once we’d fixed these major errors in our Balsamiq prototype, it came time to build the real thing. So, we built in, and then we went through the process of receiving feedback from our fellow designers. These designers conducted a heuristic evaluation of our prototype, and then gave us detailed feedback (along with severity scores). A large amount of this feedback centered around the theme of, well, feedback. Our fellow designers found that when entering a workout or measurement, they had no clue whether the information was saved, which made them want to repeat the action continuously. They also found the functionality of the view/edit workout page very sparse, and informed us that this page should be more rich to facilitate trainers fixing their mistakes.

We proceeded to then insert a huge amount of feedback into the prototype. Now, when a workout is added, there are several different textual and visual indicators that the workout has been saved. In addition, we improved the prototype to make the separation between different dates for workouts more clear, on both the adding and editing workouts page.

Before a workout is added After a workout is added After a workout is added

Major Changes

Icons Images and Grouping

Through our various stages of design refinement, we changed with the icon images and the grouping of them. Originally, the group of icons mismatched icons that were unrelated and/or had no real relevant function. We eventually changed the icons to address the immediate needs of the user on each page, giving them standard tools on the top and bottom bar. Furthermore, we refined the actual images of the icons and accompanied them with a caption to make sure the icons’ functions were explicit to avoid confusion and misunderstanding.

From scrolling to a number pad

Through our various stages of design refinement, we changed with the icon images and the grouping of them. Originally, the group of icons mismatched icons that were unrelated and/or had no real relevant function. We eventually changed the icons to address the immediate needs of the user on each page, giving them standard tools on the top and bottom bar. Furthermore, we refined the actual images of the icons and accompanied them with a caption to make sure the icons’ functions were explicit to avoid confusion and misunderstanding.

Touch Targets

To explicitly signal to the user that they could enter an exercise, we placed plus sign buttons next to each and every exercise. In later refinements, we switched to allowing the user to tap anywhere on that horizontal bar to include that specific exercise. Although this version may not be as explicit, it is still very clear as about the functionality. Having the entire row be tappable, it allows for more accurate and speedier entry.

Providing Feedback

Watch this video comparing our early prototype, with no feedback, to our later prototype, with feedback

Feedback helps to make our app faster and gives the user confidence in the app’s efficiency. To save a workout, preliminary prototypes required the user to press “edit” and then two “done” buttons. This workflow requires many steps and users can easily miss one. In the final design refinement, text appears next to the workout name alerting the trainer that it has been saved.

Valuable Evalulation Techniques

The low-fi prototype was the most valuable to our prototypes usability because it focused our attention select/input workouts issues and on our icons. In terms of icons, we found that our icon groupings and images were not clear to the user. For example, our measure icon was not clear to users because they were not sure what a tape measure icon indicated and had trouble pinpointed exactly what it was. The graph icon, while recognizable, did not intuitively register as a progress tracking icon either. Furthermore, we had grouped an “all clients” button with the graph and trophy button which did not make sense because these icons usually were not related to a user’s immediate task. As a result, we re-designed four icons (measure, workout, progress and goals) and labeled them so users would be aware of their purpose.

When it came to searching for and inputting exercises, we originally had two bodies cut in half on both sides of the screen and trainers could select relevant body parts and find the exercises they wanted to track. We thought this way of finding workouts would be new and innovative, but it turns out that the bodies were confusing and adding an extra step for the users to find an icon. For example, people did not even know you could select the leg of the body to see a list of pre-populated leg exercises and also thought the image of the body was unfamiliar because they were trained to view detailed muscular systems. Furthermore, personal trainers generally know the exact name and workout they want to use for a client so we eliminated the idea in favor of a quicker two method search/selection system.

The heuristic evaluation resulted in us making changes to the redundancy in our done buttons, called attention importance of our system giving feedback to the trainers to let them know their workouts have been saved and adding workout glitches. In terms of the done buttons, we had them in each expanded entry on the measurements/edit and workouts/edit screen which suggested to the user that the done buttons had to be pressed in order to record an entry. Users expressed that this was confusing because they were not sure which done button they should press. Furthermore, in terms of feedback from the system, the done button in each entry collapsed it and did not indicate whether the entry was saved. One major adding workout glitch that was spotted was the fact that the search functionality required the users first word to exactly match the exercise in the workout list. If the search term did not exactly match, then zero results would be displayed and the user would be shown a blank screen that wouldn’t give the user any indication of what went wrong and how they could fix it. As a result, we created an experiment using different forms of feedback (checkmarks, pop-up notifications) to see what combination of saved notifications users best responded too when recording workouts.

Final Class Presentation

Divison of Labor

Cypress Dana Noam Sharon
Experimental Design 25 25 25 25
Prototype Redesign30203020
Prototype Code500500