vincent.io

Recently I asked the question “Should you optimize mobile experiences based on individual handedness?” on the UX Stack Exchange board. This question came to mind while looking at this mock-up that UX.SE user abbood created:

My immediate thought was that the up-vote control was on the wrong side. Why? Because my feeling is that up-votes happen more often than down-votes — something not interesting is not worth spending a click on — and on mobile the primary action (up vote) should be on the left. But I realized this view was quite self-centric: I’m a lefty. For a right-handed person having the primary control on the right probably makes much more sense, I thought.

Applying Fitt’s Law to touch devices

Justin Smith wrote an excellent article on the application of Fitt’s Law on touch devices. In his article he argues that Fitt’s Law applicability to mobile experiences depends on the way the user is holding the device. If she doesn’t need to change the way she holds the device the law applies. For example, when using the device single-handedly in portrait mode. It also applies when holding the devices double-handedly in landscape mode (assuming you are able to reach all parts of the interface, which depends on the size of the device). However, when holding the device with the one hand and controlling it with the other Fitt’s Law doesn’t apply, as you now need to take other variables into account.

In my experience the way a user holds a device depends on how she interacts with it. When drafting an e-mail it makes sense to use two hands. However, when doing a a check-in on Foursquare it makes sense to only use one hand. The interaction time is very limited and shouldn’t require a lot of movement. On top of that we should also consider the context: the user is probably entering (or has just entered) a space and is doing multiple things at the same time. Looking around for familiair faces, grabbing a seat or shaking someone’s hand (regardless of how rude that is).

Foursquare’s primary action: the check-in

Foursquare offers a lot more functionality than merely doing a check-in, but checking in is still the primary action. What’s more: it’s also the action that usually takes place in the context I outlined above (while being in the middle of some other activity).

Therefor the most important action for a Foursquare user is to reach and tap the check-in button in the interface. In the image on the right I’ve highlighted the target area. As you can see it’s in the top-right corner.

This shouldn’t present a problem for right-handed users holding their iPhone in their primary hand. Although it’s not easiest target to reach with just a thumb, it’s certainly possible.

However, when holding the device in your left hand and using your left thumb it’s simply impossible to reach the target. Let’s take a look at the thumb reach of the left hand drawn on top of the Foursquare interface.

Left-handed thumb reach in Foursquare

In the image on the right I’ve used green to illustrate the primary thumb reach area, the area that is reachable without requiring a lot of stretching of the thumb.

I’ve highlighted the secondary thumb reach area in orange. This part is still within thumb’s reach, but it requires some stretching to cover it. Anything outside these areas is simply impossible to reach without moving the position of the device within the hand or using a second hand (or having absurdly long, flexible thumbs).

What becomes clear when looking at this illustration is that it’s impossible to reach the check-in target single-handedly with your left thumb. I can confirm this from my own experience: doing a Foursquare check-in requires me to either control the device with my right hand or use two hands: one for holding the device and one for tapping.

Note: these are just approximate illustrations, actual thumb reach may differ from person to person and also depends on the form factor of the device.

Is this a problem? Partially, yes.

Given the fact that 10% of the world population is left-handed my initial thought was that this would be a problem. Ignoring 10% of 7 billion people doesn’t seem to make sense. But that’s not necessarily the case.

In another answer to my UX.SE question adrianh linked to a very interesting article published on UXmatters: “How Do Users Really Hold Mobile Devices?“. In his article Steven Hoober shares the results of 1,333 observed interactions with mobile devices. The finding that surprised me the most? That in 33% of all single-hand interactions the left thumb was on the screen. This doesn’t match with the left-vs-right handedness distribution at all.

One other thing that stood out was that users continuously switch the way they hold their phone. This suggests that the order of an interface has less impact on lefties than I expected. However, we can only guess if the observed behaviour comes naturally or if users behave this way because they are adapting to the interface. Does the interface drive behaviour or is it the other way around?

In either case, optimizing an interface for usage in either single hand or any other configuration — regardless of handedness — should not be ignored.

Possible solutions

I initially asked my question based on the premise that most device interactions happen single-handedly and using one’s primary hand. Steven Hoober’s findings debunk this, or at least partially. But that doesn’t mean that you should accept this on face value and ignore handedness in your interface design.

Adapt to individual handedness

My first idea was to detect the handedness of the user and dynamically adapt the interface to this. Detecting handedness is probably very hard to do, so maybe it should be a manual setting (no pun intended) within the app’s or platform’s configuration. However, if we look at Steven Hoober’s findings that would hardly be necessary: users continually switch the way they hold their device and a lot of the single-handed interaction isn’t performed with the primary hand. On top of that this method would present all kinds of difficulties like interface recognition problems.

Choose a neutral interface order

UX.SE user Benjamin Malley presented a different suggestion. Instead of choosing between optimization for either left-handed or right-handed usage you could also choose for a neutral solution. Compare the following two interfaces:

The interface on the left shows the iPhone’s Lock screen. In this interface the user needs to slide the bar from left to right to execute the unlock.

The interface on the right shows the “Power down” screen on Windows Phone. The user needs to slide the bar downwards to confirm powering down.

In both situations a slide action is required to confirm the action and to prevent accidentally executing the action. However, Apple’s interface seems to have a bias towards right-handed usage. Sliding from left to right is harder to do when holding the phone in the left hand than it is when holding the phone in the right hand.

Microsoft decided on a neutral solution: the slide down isn’t harder when executed with the left hand instead of the right.

Prototype, test and refine your interface

There’s one recommendation that can safely be given: prototype, test and refine your interface. This advice applies to almost all UX challenges that we confront, and this one is no stranger.

There are various ways to test your interface. User-testing in a controlled setting by recording the mobile interaction is an obvious way to do it. But you could also consider quantitatively A/B testing your interface. Design an alternate version of the interface and serve it to a sample of your user base. You could consider KPIs like how long it takes for users to reach and tap the moved button, or how often mis-clicks happen, etc. Doing A/B testing of interface lay-out maybe hard when you’re doing native apps, but when you’re doing web apps it’s certainly possible (another win for the web :).

Regardless of the used testing method, one thing is clear: you can’t replace testing on actual devices. It’s impossible to reliably test element reachability on paper sketches. And apart from the reachability of the controls in your interface there’s also the issue of fingers overlapping the screen. You want to make sure that users don’t hide essential information on the screen just because they are interacting with your interface (especially in interaction-rich contexts). So, you absolutely need to prototype and test on real devices.

Conclusion

We’ve learnt that the hand in which users hold their devices doesn’t need to match with their individual handedness. But, interfaces can definitely be much harder to control when using the left hand instead of the right (or vice versa). You should not ignore this. Aim for neutral solutions and make sure to prototype, test and refine your interfaces.

Many thanks to the fantastic people at UX.SE who share their knowledge and experience with the UX community for nothing but reputation and badges. Special thanks to abbood, adrianh and Benjamin Malley for sharing their insights.

A very common UX myth — one that clients will “remind” me of in about every project — is that everything should be accessible within 3 clicks. Numerous research studies and practical implementations have debunked this. It has been discovered that the number of click doesn’t negatively contribute to the user experience or even improve it! As part of Adaptive Path’s advice to improve Twitter’s user engagement an extra step was introduced in the sign-up process. The result? 29% more first-time tweeps completed the on-boarding process than before the re-design.

What’s become apparent that users don’t mind clicking, as long as every clicks brings them closer to their goal. Having a good navigation that’s clear to the user at every point is what matters. Of course, if every page takes 5 seconds to load an extra click is bad for the overall experience, but that has much more to do with your website’s performance than with the number of clicks. It’s simply the by-product of the click.

Save clicks where you can

However, if you can save a click you should. Your users don’t mind clicking if it leads to what they want, but if you can remove intermediary steps you should go for it. Making things easier for your users improves the user experience. You should always A/B test modifications like these of course, especially in e-commerce websites. But generally removing unnecessary clicks, particularly in web apps with repetitive tasks, works.

A real-world example: Toggl

Let’s look at a real-world example: Toggl’s time-tracking control. Toggl is great time tracking application (well, as “great” as a time tracking app can get, it still sucks to do time tracking of course) that puts a lot of focus on improving the usability of the app. They need to of course: time tracking is annoying as it’s basically a meta-action. So making using their app as simple as possible directly improves their competitiveness (and thereby their bottom-line).

Now, let’s take a look at how Toggl can save a click. In Toggl there are two different time entry modes: manual time entry and automatic time tracking. The first mode let’s you enter a specific start and stop time and the second tracks your time automatically, starting now. Because doing time tracking perfectly is impossible if you work on more than one task you’re bound to leave the timer running for too long or forgot to start it. Because of this I switch between the two modes about 10 times a day. And this is where Toggl can drop a click.

Step 1: Manual time input mode

When you are in manual time input mode, the time tracking widget looks like this:

You can enter the task, pick a project, enter a start and stop time and log it using the “Save”-button. In this case I already wrote down the name of the task, when I realized that I should use the automatic time tracker. To access the automatic mode I need to click the “Use timer”-link above the “Save”-button.

Step 2: Switching to timer mode

Now that I’ve switched to automatic time tracking the widget looks like this:

The most visible change is the background color. It’s a very great way to indicate to the user that the mode has changed, and at all times it makes it clear to the user which mode he’s in. Two other changes in the widget: the button’s label has changed from “Save” to “Start” and the label of the link to switch to the other mode is now “Add manually”.

However, the time is not tracking yet.

Step 3: Starting the timer

Now to actually start the timer I need to press the “Start”-button.

Again the background color has changed, this time to green to indicate that the timer is running. Also the primary button color and label has changed to provide a clear visual clue to the user where to click to stop tracking time.

This is all great, but why didn’t the timer start immediately when I clicked “Use timer”? Most of the times I’ve written the titel of the task down already and if not: I would consider the actions related to time tracking to be part of the task itself.

Should I complain about a click? Yes!

Now you may interject that I’m complaining about nothing. What’s the impact of saving a single click on all the clicks you do in a day? The answer is simple: it depends. If tracking time was something I did maybe once or twice a day (or even less) it would be no biggy. But I track about 20 tasks daily and on top of that: time tracking sucks, remember? The annoyance of having to do an unnecessary click when you’re already doing something that you don’t really like can have a significant impact on your mood while using the app.

When doing a repetitive task such as time tracking, every click counts. So make sure that you remove unnecessary steps where you can.

Over the past year me and my colleagues have been working hard on a fantastic project: SalesChamp. SalesChamp is a sales application running on tablets. It’s not purely an iPad application. As all the magic is happening in HTML5 this baby is cross-platform. As we are closing in on our TTM deadline we are readying all the important marketing stuff, like a kick-ass website and of course, business cards.

Play your cards right

I’ll write more on SalesChamp — all the cool stuff you can do with it and all the cool stuff that make it do what it does — soon, but for now I want to talk about the business cards. As we are positioning SalesChamp as a ‘service with a personality’ (‘swap’ — I just made that up) we have a mascotte of course. Meet Simon! Simon is a true sales champ, our very own hero.

So, with such a great guy as the face of our app we wouldn’t get away with boring business cards. So, instead of the default boilerplate stuff I tried to put some fun in them by adding famous sales and marketing quotes on the back side of the cards. In total we designed 14 different backs, each of them with a few words of clever business wisdom.

Here’s one such example, with a quote from my favourite cognitive scientist:

Pretty cool, right?

Delivering an experience

After finalizing the designs we had to get them printed of course. I ordered them from Moo, and this week the cards were delivered. Not only did Moo deliver the cards, they delivered an experience! What a stellar job they do at going the extra mile. When I opened the (nicely designed) box I found 5 really cool (and solid) card holders containing our cards:

The card holders had two tabs in them labelled ‘mine’ and ‘theirs’. Quite handy to organize received cards on conferences and such. It’s all in such details, like the little “buzzword challenge”-card, a game to fit as much terms like ‘viralize’ or ‘socialocomotion’ in your next meeting and see how long you can get away with it. Or the encouraging “Quick, schedule a meeting! Your Business Cards have arrived.”-message.

Piggybacking Moo’s new product: NFC business cards

A very cool product that Moo is working on are their NFC business cards. And of course they were smart enough to include a sample directly in my order. Scanning the card directed my web browser to a digital version of my freshly printed business card. A very clever move, as this is a great way to introduce a new product in a very friendly and cost-efficient way. I’m not sure if they are doing this, but if I were Moo I would keep track of who scans the NFC cards and target them for specialized offers later on.

A little disappointment

After ooh’ing and ah’ing about the packaging it was time to check out what it was all about: our cards. Unfortunately, my buzz was killed when I saw them. Due to some mishap the text on the front was very grainy. Not the crispness I saw one week earlier in the vector PDF on my retina screen. Fortunately, Moo is not only known for its great print service, they are also known for their great support. I am currently talking to their support to get this issue fixed and to get the cards re-printed. So hopefully I will have the final cards very soon.

Great experience

All-in-all this was a great experience. The cards are very well designed and align perfectly with our positioning. Except for the printing issue I am very impressed with Moo. And if you can get people to photograph and blog about their unboxing experience you’re doing something very well. I trust things will be sorted out with the re-print soon and we can start handing-out our cards. In the meantime, check out our (temporary) end result:

Update 13 november 2012: and as expected the newly re-printed cards look terrific! One very great delighter was the fact that Moo sent the cards via express shipping again. Because of this I received the cards exactly one day before an important SalesChamp demonstration meeting :)

My colleague Martin Kačmar from Brno recently visited our Haarlem office. Apart from attending the terrific PhoneGap Day we couldn’t let this opportunity go by to show him some examples of what Holland is really like. Hence, a visit to the Zaanse Schans was arranged. During our tour through the outdoor museum we visited “Specerijenmolen De Huisman“, a mill which was used for grinding herbs and spices in the good old days (no, not that kind of herbs…).

Wooden barrels with screens in them

Inside the mill we stumbled across some wooden barrels with screens in them. I instantly recognized these barrels: they were created by Tekst & Uitleg, the neighbours from our previous office. While clicking through the wooden barrel-enclosed interface I spotted a very clever detail on the screen: a fingerprint affordance.

Three reasons why I loved them:

1. The fingerprints made it clear that it was a touch screen

The fingerprints made it immediately clear that the screen was a touch screen. Especially in this situation, where you have a screen in an unfamiliar setting (a wooden barrel) this is needed. More so when you take into account that the screen might still be playing a video started by a previous visitor.

2. The placing made clear what was clickable

The fingerprints were placed on key navigation items, making it immediately clear that they could be clicked. This was very useful, as it wasn’t really clear what was clickable and what wasn’t if you would take away the fingerprints. This does not give you permission to serve mystery meat for navigation of course, but in this case it really helped the designers of Tekst & Uitleg to come up with a navigation that is really embedded in the content.

3. The fingerprints were done very subtly

The fingerprints were done subtly, without taking away attention from what was shown on the screen. At first I thought the screen was dirty with fingerprints from other visitors. These were not natural affordances like real fingerprints, but they really looked like it. It was as if the previous users showed me where I should click to see things happening on the screen.

All-in-all I really liked this solution. Compliments to Tekst & Uitleg for designing these fantastically fake fingerprints!

Two weeks ago I lost my fantastic Nexus S at Awakenings Festival. Five years back this wouldn’t be such a big problem. But nowadays that small device contains my entire (personal and business) life. I had a track-my-device app installed, but as the network was overloaded by 30.000 people asking each other “Where are you?” on WhatsApp, it didn’t work.

So, the first thing I did was to call Vodafone to block my SIM card. The good news was I could pick up a new SIM card the next day, even though it was a Sunday. But I still had that annoying feeling of having lost all my personal belongings. It felt a bit as if I was walking the festival terrain naked.

Passwords suck

Passwords suck. They are insecure, inconvenient bastards. But they are the best we have in 99% of the situation. I was concerned about the possibility of passwords (e.g.: my e-mail password) being extracted from the device. Even though the chances of someone being skilled enough to do that are very low, I wanted to be safe rather than sorry. So I immediately hurried to the office. My Saturday night was going to be awesome: changing all my passwords.

So, after 3.5 hours the clock hit 1.30am and I had finally changed all my passwords. But that’s not where the inconvenience ends. In the weeks to come you need to enter your new passwords everywhere you re-login. And of course it takes three tries before you realize that you’ve reset your passwords.

Google’s big detail

That’s when I found Google’s great reminder function. After entering my old password Google kindly reminded me that my password has been changed.

Apart from this nice reminder, it has another big benefit: if you didn’t change your password you can alert Google Support immediately to get your account re-instated.

The 1%

This is absolutely a delightful UX detail. It may seem obvious, but mind you that probably about 1% of all the thinking, designing and building of an app is spent on ‘preconditions’ like login, logout and lost password functionality.

If you want to delight your users, make sure to spend a reasonable amount of time on these preconditions. And watch your logs. With the huge amount of users Google has it shouldn’t take long to recognize the pattern of failed logins after a password change.

Passwords suck, but they are probably going to stick around for quite some time. The least we can do is make using them easier.

I love those talks where you are first blown away by the sheer brilliance of the subject (and the speaker), then get that feeling “it’s so obvious, how could I not have seen that?“. Those are the best. It’s the only occassion where you walk out feeling so incredibly dumb, yet with a big smile on your face.

Last night at UX Cocktail Hour I attended a presentation by Karl Fast, professor User Experience Design at Kent State University. His talk on the opportunity of information overload (io) was such an experience.

Extensive research in people playing Tetris showed that players make extra moves for every block they need to fit. Why do people make extra rotations and movements in Tetris? To check their next move before sticking to it.

The same goes for chess, where even especially the best players move their piece to a new position but don’t release it before checking whether it’s a good move. They change the world to determine if they should change the world.

Apart from the fact that it was refreshing for a change not to hear someone talk about how bad io is but instead embracing it, it also hit home within the local UX community. At least it did with me. We spend so much time assisting people to make the perfect move, while they make all kinds of other -seemingly random- moves. Even just to check if they are right.

Value in making the wrong move

There is value in making the wrong move. Just as there is value in having a board cluttered with sticky notes. There is value in touch. Which makes me wonder, can an online project management tool ever beat three people standing around a whiteboard? Of course it has additional benefits, such as keeping track forever and sharing with people who are not in the same room. But at its essential task, sorting information and providing overview, nothing beats the good old whiteboard.

The ever increasing blur between virtual and actual

It’s an interesting time. On the one hand we have apps mimicking the real world, look at the sticky notes in Trello for example. Yet at the same time we have the real world mimicking the virtual world, look at digital whiteboards for example. Entire walls are being converted into touch screens.

Somewhere in between is the sweet spot, the place where the line between what’s real and what’s virtual has become so incredibly thin that the virtual world is a full extension to the real world, and vice versa.

I love contingency design: the very important details of handling errors and turning a negative user experience into a positive one. Usually when working on form interaction I design four things:

1. A default field value to guide the user;
2. The error message, and where it is located;
3. The styling of the field when on-error;
4. What happens when the error is corrected (usually the same as when the field was filled correctly).

Let’s take a closer look at this.

Prevent errors and give immediate feedback

Rule #1 requires us to prevent errors as much as possible. A default value can help a lot, as it shows the user how to enter their data. Also providing immediate feedback is of great help. Getting the user back on track right away greatly improves the user experience and speeds up the whole process. Having to submit the form before seeing your mistake is really un-cool.

Make sure however, that you give the immediate feedback where it makes sense: when the user enters an illegal character it makes sense to alert her right away. However, when she’s still inside the field (typing or idling) it doesn’t make sense to check whether a minimum input length has been met.

Show what went wrong, and where

Rule #2 tells us that we can’t absolutely stop errors from happening, but we can handle (and should) them gracefully. The error message should be as clear as possible and explain what went wrong, not just telling something went wrong. Avoid generic messages like “Invalid input”. Use something helpful like: “Your telephone number should at least contain 10 digits.”.

Also show which field is on error. This should be immediately clear to the user. Do this by highlighting the field and by placing the error close to the field. But don’t put it too close. This error message tooltip on 99designs.com overlaps the invalid field, which makes it very hard for the user to correct the problem:

Notify the user that he corrected the error

When the user fixes the incorrect value make sure that the error message disappears instantly and the form field returns to its regular completed-state. Preferably this completed-state makes it absolutely clear to the user that he entered the required data correctly. The best forms leverage this completed-state to tell the user that he’s well on his way to completing his goal (the complete form fill). Cheer on the user!

Allow for international input

One very important thing to always keep in mind is that people may have valid input that doesn’t match your validation rule. If you target an international audience you need to take care that you accept all different address notations. Even something so seemingly simple as a name may collide with your validation rules.

Read more about international form input in the excellent “Personal names around the world” post in the Q&A section of W3C’s website.

Track your errors

Then finally, as rule #3 tells us, track your errors. Make sure that you detect that errors happen and log everything you can. Use web analytics solutions like Google Analytics and Mouseflow, use application and server level logging. Reveal why users are struggling with your application, so you know what to do to fix it.

Conclusion

We’ve looked at how to avoid errors from happening, handle them gracefully when they do occur and how to track them. But above all: we’ve looked at what we can do to salvage a negative user experience.

Error handling is usually the most overlooked aspect of any interaction design. Wrongly so. It is the moment where your application can make all the difference and delight your users.

Don’t underestimate error handling and start designing beautiful errors.