Bad Design Be Gone
I made some UX decisions during design that I thought would work out. They didn't.
Back to the drawing board.
While testing the app over the past few days (walking the dog, running, driving) and I realized some things did not flow well. So I took Tuesday night to reevaluate the design and work out how to solve some of the flow problems.
Two things I did:
- I reviewed multiple fitness apps to understand how they handle some of the UX I was having problems with.
- I showed the app to more people to gather feedback about the UX.
Both of those things brought to light multiple areas that could be improved.
So, I redesigned a couple views, added some missing views, and jotted down some great feature ideas I received. The features I captured for a post V1 release.
In particular, a problem area I had was the Paddling/Workout workflow. Here is what I had:
At first, I left the CONTINUE in but realized I needed to remove it since the decision to CONTINUE/UNPAUSE is on the interstitial view. Now, I think I have a cleaner UX for ending the workout.
Then, on Wednesday night I completed the integration of Microsoft Band data, CoreLocation data, and workout metrics into my Realm backend. This is cool since I had implemented the code to load the DOCK view, the main view you land on when launching the app, previously when I designed the data model.
Now I have a lot of workouts showing up on the main view as I test the PADDLE workflow.
Then I released I needed a way to delete a workout on the PADDLE_End view when a user (me) wants to delete a session they do not want to track. So, for this I added a DELETE button to the PADDLE_End view.
I do not think this adds to much to the cognitive load since a review of multiple fitness apps those that many use this concept on their end workout view. I also think it fits to have the DELETE | DONE on the top so the user can choose if they want to keep/delete this workout.
They are along the same line visually and hence they are giving you two options along the same line of vision.
Now it's time to retest and see how this new design's UX feels after repeated use.
Missing Interstitial View
In particular, a problem area I had was the Paddling/Workout workflow. Here is what I had:
- User taps PADDLE on the main view.
- Transition to Prepare To Launch view.
- User chooses if they want to track location and use a paired Microsoft Band.
- User taps Play button to start paddling workout.
- Transition to PADDLE view, the main workout view.
- User decides to stop workout, they tap Pause button.
- Transition to Paddle End view.
It was steps 6-7 that had a problem. Here are what the views looked like.
Missing a Pause/Stop Confirmation View |
The main problem with the above design is that I am trying to do too much in the PADDLE_End view. I am trying to cover several tasks:
- CONTINUE: You paused by mistake, did you want to go back?
- DONE: End the workout.
- Upload to Strava: Did you want to upload the workout?
- Send to the Health App: Did you want to store your workout in the iOS Health App?
- SEND SESSION TO PADDLE MATE: (Too long) Are you a tester and want to submit samples?
Here is what I have done so far to fix a major flaw.
I added an interstitial view between 6&7 which is a Pause view. This will let me move the CONTINUE from PADDLE_End back to the main view.
I think this offloads the decision to end the workout to this new PADDLE_Pause interstitial view. Now the user is not thinking about should they continue or end on the next screen, lower the cognitive work on the PADDLE_End view.
New Paddle Pause with interstitial Pause/Stop Confirmation view added before Paddle End view |
At first, I left the CONTINUE in but realized I needed to remove it since the decision to CONTINUE/UNPAUSE is on the interstitial view. Now, I think I have a cleaner UX for ending the workout.
Change Design, Test, Repeat
Then, on Wednesday night I completed the integration of Microsoft Band data, CoreLocation data, and workout metrics into my Realm backend. This is cool since I had implemented the code to load the DOCK view, the main view you land on when launching the app, previously when I designed the data model.
Now I have a lot of workouts showing up on the main view as I test the PADDLE workflow.
Then I released I needed a way to delete a workout on the PADDLE_End view when a user (me) wants to delete a session they do not want to track. So, for this I added a DELETE button to the PADDLE_End view.
I do not think this adds to much to the cognitive load since a review of multiple fitness apps those that many use this concept on their end workout view. I also think it fits to have the DELETE | DONE on the top so the user can choose if they want to keep/delete this workout.
They are along the same line visually and hence they are giving you two options along the same line of vision.
Now with Pause interstitial and Delete option |
No comments:
Post a Comment