In a tasty follow-up to her article about keyboard accessibility for mobile devices, Devon walks us through a pizza-themed tutorial, bringing keyboard support life in the most delicious way.
Back in the oven
Previously in Supporting the keyboard for mobile, we talked about how considering keyboard-only interactions in your mobile web thinking is a great way to guide design and development choices that are intuitive, inclusive, and easy to iterate upon. Breaking down interactions into microtasks helps you see all the nooks and crannies of your design and implementation, and makes a huge impact on a wide variety of users accessing your content under a myriad of circumstances. With some practice, you can integrate this way of thinking into your existing mobile web design workflow.
Learning new techniques for UX and code design is often easier said than done, so let’s walk through an example together. To demonstrate, we’re going to build part of a pizza order form. Forms are sometimes a pain on the best of days and devices—and they can be particularly challenging on mobile, especially when we’re in a hurry. Or hungry.
What’ll it be today?
The scenario: Your local pizzeria’s favorite customer, Toni Pizza, is at a party, and wants to order some pizza on her phone. Your challenge: let her order with minimal fuss, with an assistive technology (or one thumb or with a low battery or in bad light or with attention that’s scattered by background noise—it’s a party after all).
We’ll focus on the pizza part of the ordering process, where users get to design the pizza of their dreams.
Every form is designed to get information from users to help them meet their goals, so every form is basically a series of questions.
Our first step is to break down the larger task into the smallest pieces, the smallest questions, we can. But, let’s not get bogged down in order or process yet (putting the sauce before the crust, as it were). Simply jot down the list of questions we need to ask our users.
You might do this as a bullet list, a set of Post-It notes, or whatever tools you prefer for brainstorming or note-taking:
- How many pizzas does the customer need?
- Does she want a predesigned pizza from the menu, or to create a custom one?
- What size pizza(s)?
- Is cheese optional?
- What toppings?
- Should the toppings be on a specific side, so the party host who likes olives and the guest who likes anchovies can continue to speak to each other?
As we design our form, we might come back to this list and rework it, combining or separating items, but this is a start. The questions yield specific-enough answers that we can start on the next step of our workflow: designing the order for our form.
Although the order of a form is always important, it’s especially crucial on mobile for a few reasons. Mobile users typically have a smaller screen size and don’t want to have to scroll up and down (or worse, side to side) to make sense of the form. Mobile users also typically also have their attention divided between their phone and other things going on around them; that’s kind of the point of mobile computing, after all.
For users with disabilities—especially those with motor and mobility issues, users with low vision, and those who rely on assistive technologies like screen readers or speech recognition software—the order of a form also has a huge impact on ease of use. Every time a user needs to scroll up or down to make sense of what they need to do is time they’ve lost to the interaction, and time they’re not eating their pizza.
The most important thing to consider when determining your question order is how to prevent users from going backward.
Typically, you want your questions to work like a funnel, going from most general to most specific, to help users get context for simple and complex forms alike. If your form has conditions, where some fields might appear or disappear based on user inputs, starting general and getting more specific also prevents you from doing gymnastics with code that might cause users to miss what’s happened, lose their place, or get confused. A user’s next step should always be the next one, not one or two steps back in the workflow.
With that in mind, let’s take a crack at ordering our form. There’s no right way to do this, but if we think about our party use case, we’ll figure out an order that seems to make the most sense.
- A pre-designed pizza, or a custom one? Whether your menu includes a list of pre-designed options or just custom ones, the first step to ordering a pizza is starting with the very concept of the pizza.
- Is cheese a topping? A default? While diligently researching pizza ordering websites for this article, I found some that treated cheese as a default, some as a yes or no option, and some as a topping. For our purposes, let’s say that users who want a custom pizza can order cheese or not.
- What toppings? The toppings make the pizza, and are going to be impacted by all of the user’s previous choices. They represent the make or break question in our workflow.
- Where do the toppings go? If our service allows users to split toppings, we need to consider whether users should pick a topping and then a location, or vice versa. To start, let’s try the first way, where users will pick a topping and then decide where it goes.
- What size? Size may be a general question, but it may also be impacted by all the other factors that come into play as customers figure out an order that best fits their current situation. For our use case, our customer might start ordering a small but find out a couple of other people are interested in the same pizza, and might readjust the size accordingly.
- How many pizzas? If your typical customers are ordering pizza in bulk, they may know they need ten right up front. However, for most users, they may not know how many they want until they’ve decided on the type and size of the first one (and until half the party decides to join in).
Into the kitchen
Now comes the tricky part: deciding how our questions are represented in the form. Each type of form element (radio buttons, checkboxes, select elements, buttons, text fields) is designed to display and collect data in a particular way, so it’s important to consider the element you use for each type of question.
Using native form fields means that mobile users will already be able to use your form, without any custom programming to support touch or keyboard interactions on your part, and form fields will be displayed with a size and appearance that they’ll be accustomed to in their mobile browser.
Since we’re picking one pizza at a time, and users need to see all options together, I think the recipe calls for radio buttons. These guys get a bad rap, but they’re perfect for situations where you need users to pick one of several options and you want them to see all the options at once.
Next, users who selected a custom pizza need to make a decision about cheese, if the select a custom pizza. Since most users will want cheese, we can make this option selected by default. And since it’s a binary choice, a checkbox is probably the way to go.
Next, toppings. We have two questions for each topping: whether a customer wants a given topping, and where they want it to go. Again, a checkbox makes sense for toppings since users can pick as many as they like, and will either want green peppers or not. Each topping can only be in one place, so we need a field that lets users make one choice from several.
Pizza size is straightforward—we’ll only offer a specific set of choices, which our users will be familiar with—so we can use a select dropdown. And finally, we need to let users order multiple pizzas for the type they’ve built. For our use case, defaulting to a value of one makes sense. Since the total number of pizzas will be a number (and probably not a big one; we’re a small shop after all!), let’s go with another select element.
To finish out our form, we also need a way to add another kind of pizza, and also allow users to get to the next set of questions to finish their delivery request. Both controls should be links, since they’ll navigate users to new content—they won’t submit the form yet.
Don’t take your apron off just yet! To make sure our form still makes sense with our elements assigned, let’s review our workflow and see if it’s as straightforward as we hope.
Now that we’ve got elements mapped to questions, we might want to rethink our stance on cheese, since we’ve split our topping interactions into sides, and customers might want cheese on one side or the other. So, let’s add it to our toppings list after all!
To make sure we don’t miss anything, we also might want to add a “freeform” text area for users to include any concerns or special instructions they might have. This can go at the end of the form, since many users likely won’t use it, and for users who do, it will represent a specific need based on all of the other information provided.
So, here’s our complete, revised form, with our customer’s input:
The final step for our form is to put it in front of actual users, either in usability testing or live on the site. We can see how people respond and test different methods for the finer data collection points, like topping locations. If you’re starting out with usability testing for the first time, interactions you talked about a lot internally will often be good candidates for testing. Some things you thought were hard will be easy, and some things you thought were easy will be hard. There’s only one way to find out. Buon appetito!