Riding the biggest, baddest ride in an amusement park is always a thrill, but waiting 45 minutes to do it? Not so much. Amusement parks are infamous for their crowds and chaos, so the RideTime app imagines a blueprint for the park of the future: one in which parkgoers scan an individual code to get in line and then again to get onto a ride. From those two points, an average wait time is calculated and displayed live within the app, ensuring the smoothest day possible at some of the wildest places around.
My process for creating RideTime started with this original pitch:
"I will create and develop an app that lets users know where busy areas are within an amusement park. The park will track attendance at the entrances of its rides to inform guests on the levels of foot traffic at a given time. This data could be tracked long-term to create visualizations of park ride statistics, all available to users. The information will help users avoid 'hotspots' that spike in foot traffic, increasing the park's efficiency and the visitor's positive experience during their visit."
Once the concept was established, I started to think about how someone might use the RideTime app and how the information architecture should be organized, leading to my initial process flow diagram.
It was at this early stage when I realized that including a heatmap and a filter would be the most efficient ways to show consistent information across different methods of display. I also decided not to include a "family feature" for ordering tickets to help keep the design streamlined and focused. The first process flow was edited and distilled into a more concrete version:
Next a series of personas were created for potential RideTime users, all with varying personalities and goals. This allowed me to explore how different users might interact with the app, providing unique tests for the process flow's design. A proper user interface should be able to be used as effortlessly as possible by as many different people as possible.
In addition to the personas, I also began outlining goals (and antigoals) that the app should accomplish (and avoid) to keep the design focused and on track. After testing the app using the personas, I realized that having a family feature was very useful to potential users, so a revised version was introduced back into the design.
The actual UI began with paper wireframes. I wanted to show each page of the app on a separate piece, the goal being to view a general overview of the UI without incorporating any actual design elements. These stripped-down wireframes allowed me to focus on laying out the RideTime information without getting distracted by visuals. Looking good is important, but a great UI is essential; although the app doesn't feature many individual pages, it has a complex system of links between these pages that requires careful attention.
After a few revisions, the paper wireframes were rebuilt in a digital format and tested on an actual device, mainly to see our interface at the size that it's meant to be displayed on. Elements were resized to best fit a handheld touchscreen, and all of the work and research began to come together.
Finally, design-work enters the process: a dark purple and black color scheme allows for maximum impact of the data shown using traditional heatmap colors. Also, a darker UI is more legible and requires less power when viewed in bright environments; an important detail considering most users will be doing so while outdoors at around midday.