Designing for Mobile
This article was originally posted at Ohio’s Very Own.
It seems recently that more and more projects I’ve had the opportunity to work on have been focusing more towards the mobile side of things. This is no doubt due to the mobile boom that has been happening recently and the push to create a seamless experience for screens of all sizes. This is great, it forces design to really enter that element of problem solving, but it can certainly be challenging at times. With such a large array of screen sizes, it’s become imperative now more than ever to establish a standard of human interaction guidelines to help designers create great experiences for users.
One of the biggest issues that doesn’t get much discussion, at least on the surface, is button sizing. Creating a clear, decisive, interactive call to action is of course a primary element when creating a highly usable experience, so it of course should be a primary focus. Great, that sounds easy enough, however with so many screen sizes in use today, it quickly becomes difficult and unclear on how to approach this problem. To exacerbate this problem further, we are now designing elements in the age of high-def, retina, and ultra-hd — who knows what the near future holds.
Recently I was able to work on a project that was for a native mobile application. The goal was for a user to be able to browse and select an event, choose seating, and finally complete payment simply though this application. Sounds simple enough, but right away the major issue of selecting seating on a mobile device was brought up. This ordinarily wouldn’t be too much of a problem if you were selecting seating for say, an airplane, or a bus, but because this project dealt with symphony halls and stadium events, the seating arrangement wasn’t straight forward (a simple rectangle shape having seats inline). Often times, it dealt with abstract seating sections and rows.
All things considered, there was still another problem: how would a user navigate a seat selection chart and be able to view/select their seat at varying sizes and scales? Would they pinch to zoom? Double tap to zoom? What about when you have an upper balcony that’s split into two sections? This was a problem because if the user is zoomed in completely and the seating section was split, there would be a “dead” space in the center, causing confusion. We tested this scenario a lot and often times users who were zoomed in had no idea that they could actually pan right for more available seating. After a lot of user research, testing, and trying to find some best practices for reference, it was clear that a simple solution like pinch to zoom would not work. If the user has a specific area to zoom, there’s a possibility they could potentially be “trapped” in this seating area and not be able to scroll up or down on the screen.
The not so obvious solution was to create seating selection without the capability to zoom in or out. In order to achieve this, it was imperative to create a larger enough “hit target” for tapping (selecting / deselecting). Searching various human interaction guidelines from Apple, Google, and Windows, I came to the conclusion that a hit target of about 44 x 44 pixels would suffice. Unfortunately, pixels are completely irrelevant now with @2x and @3x screen resolutions. The proper measurement I found was about 14–17mm^2. Almost just as important, a spacing around the target is required, roughly 2mm. I also found a pretty critical piece of information in my research: most touchscreen’s on today’s market actually sense the geometric center of a tap rather than its entire area. Because of this, a user doesn’t have to be 100% on their target. I’m not sure most designers, let alone most people, are aware of this.
Getting back to the seating chart, I decided to break the chart into sections and from there allow the user to make their pick. After the user selected what section they would want, they are presented to the next screen to pinpoint exactly what seats they want. Earlier I discussed who in testing users were “trapped” in the pinch to zoom zone. I solved this problem by allowing the user to swipe left and right to pan the entire section, but if the user were to scroll up or down, they would scroll the entire screen. Essentially the seats scroll left and right, not up and down, while the entire page works oppositely.
This was a great solution that tested positively and created a much better experience for the user overall.