I started formalizing the Settings screen first. Settings screens are typically afterthought in user’s minds, as they should be. Get the app design right and users should barely be in there. But, it’s a tough design problem and the code for the settings tends to spread its tendrils deep within the whole app; settings affect behaviour of the app, so getting most of it out of the way first helps get the app out the door faster.
So let’s breakdown the settings screen!
So, um, imagine that segmented button (the blue thing under Weigh-In Day) had all the days of the week and the day selected by default was Saturday (Sketch let me down here and I’m not going to spend the time to make it perfect in the mockup). Why is that there?
That blue thing is called a segmented button. It is for showing an exclusive choice amongst some options; only one can be selected at a time. There are other ways to show some options and make the user pick one, but the segmented button is perfect because it requires one tap to change. All others require more taps; more taps is bad. Dropdowns and pickers are UI of last resort.
The weigh-in day is the most important part of the app. The whole app is about establishing a habit of measuring progress regularly (weekly; two weeks is arguably better but not enough to complicate the UI and the app. Any more frequently than once a week is overkill and harmful long term). I’ll likely put this choice in the on boarding flow as well so users may never need to touch it again. I could force Saturday on everyone, but that’s presumptuous and too opinionated. It’s good to be opinionated: it focuses everything for the app and allows decisions to be made quickly. Too much opinion is a bad thing though.
The next section, Weigh-in Measurements, used to be entirely on the settings screen in the first drafts. But it was too unwieldy there and was better on its own screen, even if it adds another tap. You can see it on the Zeplin preview. I’ll discuss it in the next post.
Regarding “even if it adds another tap,” above. For budding app designers: I find the term User Experience contemptible (future post coming!) but, if you’re looking for a good user experience, obsess about taps, clicks or whatever steps are required to do something in the app. Obsessing over those tactical things are what makes apps easy/fun/magic to use, not fancy visuals.
The next section, Reminders, is clearly not ready yet. Reminders involves local notifications on iOS. This is another pit of snakes for usability and fun. I’ve kicked this can down the road for now. The intent is to remind our user that it’s weigh-in day tomorrow/soon, etc. I want to make reminders as simple as possible. It will likely be a toggle with an explanation below the toggle. But I’ll definitely revisit this. Don’t worry: you’re going to hear about it!
Next: Integration with Apple Health is not that important to me, but it has pretty graphs of progress of several things. Since Kapowski is collecting that data anyway, why not put it in Apple Health if the user wants it? No more UI is required other than a toggle. It’s one of those features where it’s all behind the scenes, deep in the code.
Finally, the About is the obligatory screen about the app and those who make it. I’ll likely put Submit Feedback and Review below About as well.
The goal with any settings screen should be to enable quick changes to get the user back to using the app for actual work. This requires sweating the details, making that UI grokkable at a glance. I want to change my weigh-in day, the user thinks. Tap the gear, tap a new day, tap Done. Finished. That’s what we want.
Tomorrow, we’ll go through the Measurement screen. This is one I struggled with, both in the implementation and in the design.