How iterations lead to great design
When I was in college, I had a computer science teacher, Nelson, who enjoyed renaming words. Sometime he would make a joke out of it. He would rename dating’ to ‘friends++.’ Some helped us students remember crucial concepts; he renamed ‘coding’ to ‘Incremental Code Development’ because he wanted us to understand that writing valid code is an iterative process. You develop a small chunk, test, gain insights, and then develop some more.
Recently I traveled to Barcelona to participate in a UX Design Bootcamp. There, I was tasked with designing a business travel app. The User Persona is Matthew, who is a 34-year-old, Digital Nomad. He is independent, ambitious, and outgoing. He would like to make the most of his business travel by spending some free time seeing the tourist attractions though he gets stressed when his trips are organized last minute.
My User Research began with interviewing four recent travelers aged 29, 31, 35, and 52. The insight from these interviews led to the Problem Statement: People who travel for work need a way to experience attractions that fit their schedule because it can be challenging to combine work and travel.
I had five days to submit a design and decided that the best use of my time was to test how my teacher’s Incremental Code Development theory applied to design. I call the process ‘Incremental Design Development.’
The result is an app concept that allows you to sync your phone’s calendar with the schedule of attractions around you.
The iterative process began by sketching a paper prototype in the method of Crazy 8’s. In the prototype below, you can scroll through attractions, choosing the ones you’d like to visit on your trip. Once selected, the app suggests times to go that fit your schedule.
I took my first design to the streets, speaking to eight different people. I approached a group relaxing outside a coffee shop, another smoking a cigarette, and a couple sitting in the park eating lunch. I asked them to imagine their company was flying them to San Francisco, and they were in search of a genuine San Franciscan experience that fits their availability. I quickly discovered that users didn’t understand that the selection box added attractions to their calendar or where they should navigate once an attraction was selected. The icons, such as the filter on the top right were also ambiguous.
I replaced each selection box with two buttons. One allowed the user to sync the attraction with their calendar, and the other allowed a user to buy tickets to that attraction. I also removed the filter icon and instead showed the user the filter options right away. Lastly, I added a bottom bar to help users navigate.
I approached another five potential users to test the updated design. People were able to form a mental model of the app with the help of bottom navigation. However, users hesitated before choosing which of the two buttons next to each attraction to click.
I removed one of the buttons, the one that allows users to buy tickets, simplifying the experience to one call to action. I updated the fidelity by adding pictures and style.
When I tested this version with eight additional potential users, I understood that reducing to one call to action button successfully decreased the time it took to complete a task. What wasn’t clear was the functionality of the call to action. What does the button do? I also found that users were not able to justify how the attractions were sorted.
I replaced the icon on the call to action button with the text ‘Sync with Calendar’ to give the user a clear call to action. I also added a ‘Sort by’ filter so people can decide which type of attractions they’d like to see first. Lastly, I solidified the color palette, typography, and grid.
If you view the app from the beginning, you’ll notice I stumbled upon a typical onboarding dilemma: When should an app ask the user to access their location, camera, or in my case calendar? As of iOS 13, if a user doesn’t allow the app permission, then the app is never able to ask them again. The user must go to their settings and change the permission manually. Therefore it’s essential to ask at the right time.
I incorrectly ask for calendar access when the user first opens the app. The problem here is that I haven’t yet demonstrated value to the user. A better solution would be to ask for permission once the user selected their desired attraction. At this point, it’s obvious that if the app could only access their calendar, they can be recommended times to go that fit their schedule. We are hesitant to give an app access to our data until the app demonstrates it’s value — then we have no problem sharing our data.
Each iteration incrementally brought me closer to understanding the essential needs of a business traveler.
Designing a business travel app using Incremental Design Development was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.