Forgive the Fat Fingers

Even though we know that electronic devices aren't human we do like it when they exhibit human characteristics. At times we want our device to be the bossy task master to remind us of what needs done for the day, Siri adds joy to our life through it's tweet worthy translation errors, and social media apps have become the modern day barbershop where one can go and catch up on the local news and gossip.

The positive feelings quickly turn to frustration when our devices no longer do what we expect and instead take on a mind of their own, or rather, the mind of the designer. The principle of forgiveness can be leveraged in design to soften the effects of what happens after a user has fallen into unexpected consequences.

The principle of forgiveness asserts that designs should help users 1) avoid making mistakes and 2) recover from a mistake that has been made.

Let's get real about design, there are people of all different abilities, physical proportions, and technical understanding. We often times think of accessibility as creating solutions for disabled people but I like to think of accessibility as being able to allow more people to use your application through design choices. One way to satisfy the needs of more people is to build forgiveness into a system by using larger target sizes and confirming/undoing actions. Here are a few mini case studies to demonstrate.

The iPhone Music Player

After upgrading to the new iOS7 I started fat fingering the music player controls. While driving to work listening to the music on my iPhone I decide to skip to the next song but instead the volume got louder. Trying to turn the volume down just paused the song. AAAAARRRRRGGGGHHHHH!!!!!!!

A few miles further down the road and another attempt at skipping a song resulted in the volume going up again. At this point I knew what the problem was, my finger tips had tripled in size overnight!

Really the problem was much simpler. I had upgraded to iOS7 the night before. Below are screen captures from the iOS6 interface taken on my wife's iPhone 4 (with a smaller screen size even) and with my iPhone 5.

iPhone Music Player

Visually I prefer the new layout compared to the old but functionally it violated the principle of forgiveness. Specifically, the interface controls were placed too close to each other for a "normal" person to operate. In design speak the target size was now to small for me. When I would try and touch the skip forward control I would end up on the volume slider instead.

iPhone Music Player with Touch Pad Zones

The iOS6 design guidelines called for a minimum target size of 44px wide by 44px tall. In the iOS7 guidelines the references for a minimum target size were removed. In the above picture the green box represents the recommended target size by the iOS6 standard and the yellow box represents my index fingers touch pad. At least the way it looks from my eyeballs' perspective.


Endomondo is another app that I love and use frequently. I use this app on every run I go on. It records my mileage, splits, route, even calls out split times to me through my headphones. I love the data you can get from Endomondo. For most runners data about their runs is critical. You mess with my data and it's like the phone is saying I never did the miles.

On my runs I usually end up needing to stop for traffic lights or, when I'm out on a beautiful trail, to take Instagram pics. Starting the app initially is really easy but resuming it after pausing it is a whole different matter.

In the last major upgrade of Endomondo the interface changed. Instead of two big separated buttons the interface was made to look more visually pleasing by embedding the STOP button inside of the RESUME button. This design quickly becomes a problem when I'm on a run trying to tap buttons through the plastic cover of my arm band while looking at the device sideways and gasping for air. What is an easy task for a developer sitting at a desk testing the app becomes a major task in fine muscle control out on an actual run. I will hit the wrong button at least once every 10 runs terminating all future collection of data for that run instantly.

Endomondo Run Tracker

But wait, there's more. So let's just say that you happen to be a bit jittery from a hard 6 mile run up a mountain so you hit STOP accidentally instead of resume. This wouldn't be a problem if Endomondo confirmed that you wanted to end the workout. Not the case. Your work out is then finished.

Learning by Redesigning

In the case of the music player Apple should have stuck with their iOS6 target size design guidelines, maybe even increased the target size a bit.

For Endomondo the target sizes are designed well it's the overlap that is the problem. In addition, the consequence of a negative action is harsh so there are two parts to the fix. The first is to separate resume and stop buttons. The second part of the fix is just to confirm when someone does hit start that they really wanted to end the workout.

Things to Remember

When designing for mobile devices you need to really think through the context under which your user will likely use your application and account for this. If users will be moving and/or not focusing on your application as the primary task you need to account for this by increasing the target size and adding more space between controls.

In addition plan for the ability to easily undo unintended actions. For the music player undoing the wrong button pressis as simple as trying again and hitting the "other" button. For Endomondo you should be able to resume a workout even after you hit the stop button.