RIDETIME APP
UI/UX DEVELOPMENT


My process for developing RideTime started with this original pitch:

"I will create and develop and app that lets users know where busy areas are in an amusement park. The park will place motion sensors at the entrances of popular rides to let guests know where the foot traffic is at a given time. Information can be tracked long-term to create data visualizations of park ride stats, all available to users. The information will help users avoid 'hotspots' that spike in foot traffic, increasing the park's efficiency and the user's general experience during their visit."

Once the concept was established, I started to think about how someone might use the RideTime and how the information architecture should be organized, which led to my initial process flow diagram:



It was at this early stage where I determined heatmap and filter features to be the most efficient ways to show information across different methods of display. In addition, I decided not to include a "family feature" for ordering tickets to help keep the design streamlined. The first process flow was edited and distilled into a more concrete version:



Personas were created for potential RideTime users, all with varying personalities and goals. This allowed me to not only explore how different users all might interact with the app, but also to provide unique tests for the process flow. It's important to design UI with a multifaceted approach; a good interface should be able to be used effortlessly by anyone.



In addition to the personas, I also began outlining goals (and antigoals) that the app should accomplish (and avoid) to keep the design process focused and on track. After thinking of the app in this way, I came to the conclusion that having that "family feature" really did a lot of good for various potential users, so a revised version was brought 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 incorperating any actual design elements.



These stripped down wireframes allowed me to focus on laying out the information contained in RideTime without getting distracted by appearance. Good design is important, but a great UI is absolutely mandatory, and although the app doesn't feature many individual pages, it has a complex system of links between the pages that needs careful attention.

After a few revisions, the UI was rebuilt into a digital format and tested on an actual device. Seeing the interface on a screen size that it's meant to be displayed on for the first time is always an essential step in the UI process. Elements were resized to perfectly fit aspects of touch screen design, and all of the work and research starts to come together in a digital format.


Finally, the actual design begins to enter the process in the form of a working prototype. RideTime was created with a very dark purple color scheme to allow maximum impact of its heatmaping feature. Also, the white text on dark backgrounds is readable in bright environments, as most users of the app will be doing so outdoors at around midday.



Please feel free to interact with the original InVision prototype embedded above. Having a working model such as this one is the most dynamic way to really fine-tune the design. Here we see the UI research and framework meshed with the actual design in a medium that works and responds to users.

Ultimately, RideTime's prototype went through a series of user tests. Random users were given a copy of the prototype installed on a phone, told the app's basic function and setting (simulating an App Store bio) and given a five question scenerio-prompt. Through these users I was able to collect information and insights that would've been impossible to see doing any other method.


"Find the ride with the least amount of wait time."

User tried looking in the map... eventually moved to list view. "I guess Kiddie Boats...?"

User easily navigated to the list, but had dificulty distinguishing the target.

User moved to list and quickly located Kiddie Boats, but was unsure whether she had really found it.

User was unsatisfied with the small icons on the list. "Is it Kiddie Boats?"


"Check the exact wait time for the Sklooosh ride."

User quickly navigated from list view and determined 30min.

Clicked on the heatmap icon at first, paused, but then clicked on name to navigate to ride page.

User completed prompt easily.

User paused at first, but then completed easily.


"Find the ride that is closest to you with the least wait time."

User was confused by the icons on the map.

User moved to map view, but paused trying to distinguish the icons.

User quickly entered map view, but can't distinguish where he's located.

User accidently engaged heatmap view, but lost her icon showing her location.


"Your son Logan B is missing, locate him."

User quickly navigated to party page and used it to locate subject.

User easily navigated to destination. "Found him!"

User found subject and understood very quickly.

User navigated to party page, clicked on name before location icon, but then found the subject.


"Your friend arrived at the park unexpectedly, add him to your party list."

User noticed button location previously and completed task extremely quickly.

User navigated easily, but was unsure of destination. "I think I'm here..."

User easily navigated and completed task.

User easily found it, but paused as he was unsure of how it worked. "Oh, you scan your friend?"