Dream Cruise
Finding a final capstone project for DesignLab’s UX Academy proved difficult, but after much deliberation I decided that for my Responsive Web Design project I would go outside of my comfort zone and explore a market I wasn’t at all familiar with. I was tasked with creating a responsive booking website for a theoretical cruise booking service. To bring Dream Cruise to life, I would need to expand my design skills beyond the comfortable region I was familiar with.
Finding A Place To Start
When I first approached this project, it was difficult for me to wrap my head around what exactly I wanted to design Dream Cruise to be. I was given a straightforward prompt. I needed to create a mobile design handoff for a travel booking website. Among the options suggested, I chose to design a cruise booking website because it was something I was completely unfamiliar with. I’ve flown many times and understood the basics behind booking a train, but I’d never been out at sea before in my life. It was an interesting problem.
Who Am I Designing For?
I began gathering background information for Dream Cruise by finding as many cruise sites as I could. At first, I looked beyond cruise-only sites and looked to more generalized travel sites in order to determine if there was any commonality between booking a cruise and booking more common means of travel. After that I began to focus on cruise sites specifically, making a list of websites and comparing their booking processes side-by-side.
I discovered that almost every site I visited followed the same general steps for booking a cruise, and some sites even allowed me to directly compare competitors. While this wasn’t a feature I planned on designing, it helped direct my research and revealed that I didn’t need to create a new booking flow. Instead, I needed to examine the existing flow used among almost every site and decide how to make it more user-friendly.
Another discovery I made was that many of the websites I visited had poor or outdated layouts on mobile. This meant that I had found a good niche to focus on by choosing cruises, but it also meant I would need to adapt clunkier, desktop-oriented site structures into a more streamlined process.
When creating personas to orient myself, I tried to keep in mind that the typical cruise booker was older than the demographics I was used to designing for. It wouldn’t be a large concern, but it was important nonetheless. I guessed that a big reason many of the sites I visited hadn’t ‘modernized’ was because they already worked well for their intended user base. I needed to take care that no usability was sacrificed while making a reactive web flow.
A Narrow Path
One of the biggest initial hurdles I faced when trying to figure out how to begin my design for Dream Cruise was the inflexibility of the booking process. My research showed that cruises were booked by following a very uniform, very routine process. After finding a cruise, a user of my design would be guided down a four- or five-step process of selecting a cruise line, selecting a room type, booking a room on their chosen ship, entering their information, method of payment, and then providing an email to confirm their booking. Aside from site-specific extras or deals, this process didn’t change much between sites.
Because I was focusing solely on booking rather than searching for cruises, I didn’t have many options on how to design my booking process. Many of the sites I tried out during my research were unreactive, or difficult to navigate if I wanted to alter my options halfway through my booking. Often the information provided was too much at once, and pages that appeared cramped on desktops were much worse to navigate on a mobile device.
While I had plenty of opportunity to create a reactive design, implementing that reactivity in a way that wouldn’t break the established ‘steps’ of cruise booking became a core challenge while creating Dream Cruise. I decided to focus on interconnectivity, and to ensure that no matter where a user was in the booking process they would always be able both understand their position and make adjustments if necessary.
Site Focus
Many of the sites I visited had sprawling pages for deals, cruise lines, destinations, vacation packages, loyalty programs, and many other features that would not be feasible within the project’s design scope. I kept my scope for Dream Cruise small, narrowing in on the steps it took for a user to go from a site’s home page to a fully-booked cruise. I also wanted to consider the post-booking user, or the user that might change their mind and need a quick path toward revision. Once I moved into wireframing, I began to form a better understanding of the site I was creating.
Design Basics
Before I laid out all of the pages for Dream Cruise, I took some time to decide on the presentation of my hypothetical site. Many of the websites I visited during my research were very simple aesthetically, and they needed to be in order to quickly connect their users with late bookings, site discounts, and other advertisements. I realized very early on that there was a risk of overwhelming a user with too much information. Therefore, when designing Dream Cruise I decided to lean into a more calm palette than I’m used to working with. I chose the name ‘Dream Cruise’ at this point in the design process to better focus my hypothetical branding. I wanted to create a user flow that was relaxed and methodical, so I chose aesthetics to match.
I chose colors I’d seen during my research that appeared tropical, but toned down. It was a careful balance between capturing the exotic, carefree appeal that attracts people to cruise lines with the comfort and assurance I wanted my design flow to have. To meet my project deadlines I tried to incorporate work I’d used in other projects that would fit Dream Cruise. I needed my assets to be direct and instantly communicative, but not enough that having too many on-screen at once would be overstimulating.
Wireframing
Dream Cruise became one of my most complex projects to plan out, and I began to find design flaws in my initial plans up until the completion of my prototype. I realized quickly that in order to be truly reactive, my design flow would need to account for more user actions than I anticipated. Even in just a five-step booking process, allowing a user to change their mind at any step meant that each step needed to convincingly react to the user’s choices. Since I was only making a mockup and not an actual booking website, I had to make hard decisions about what I could and could not include. Like my other Capstone projects, I only had 80 hours total to create Dream Cruise with, and as time began to run short I had to make sacrifices.
Much of the interconnectivity I initially planned to include was not feasible to complete within my allotted time, so as I approached the deadline for my first prototype I had to narrow down the amount of options allowed to the user to a limited, very linear few. While my design has the skeleton of an interconnected system, I do not think I managed to fully capture the amount of reactivity I initially set out to implement.
Putting Everything Together
When deciding what to include in Dream Cruise and what to discard, I knew I needed to make sure the core user flow of finding, booking and adjusting a cruise was fully fleshed out and easy to follow. One of the initial hurdles I faced while fleshing out my low-fidelity wireframes was deciding on filler content for pages such as cruise listings and the home page. While I wanted to lessen the amount of information on-screen at once, I also needed to ensure that all the typical bonuses (deals, user reviews, recommendations, etc.) were included. Even just including them in a barebones manner was important to create the illusion of a fully-featured booking website.
After selecting a cruise to book users are taken to a booking screen broken down into seven categories, intended to be filled in consecutive order but accessible at any time during the booking process. At the top of the page is a summary of the user’s selected cruise along with a dynamically-changing cost breakdown. As features are added and removed to the cruise booking, the price changes in real-time to ensure the user has a clear idea of what their final booking cost may look like.
I originally intended for each category to be completable independently, so that they could be filled out in any order. However, as I began making the high-fidelity screens in Figma I realized that the level of interconnectivity I desired was infeasible to create for a simple prototype. Instead, I made sure that each step flowed easily into the next and that no information was repeated between steps. Initially, I also implemented a crude ‘autofill’ for repeated information such as emails and names but after receiving feedback on my layout decided to remove it.
Once all categories on the booking page are completely filled out, the user is given a final breakdown of all their chosen options and associated costs. They are given the option to confirm and book their cruise, or to go back and make alterations to their selections before locking in their decision. Once a cruise is booked, the user can see their booking information either from an account page or by looking up their cruise booking number. From this page the user can re-send their confirmation email, print baggage tags, or make other adjustments as necessary.
A Troubled Solution
I presented my prototype for Dream Cruise to some colleagues for feedback, focusing on how useable the booking process felt and how easy it was to complete a full booking process. Each booking step is accessible from a single page, and as my testers shifted through the various room options and deal packages offered I wanted to ensure that changes to the final booking were easy to keep track of mid-booking.
My testers found that the prototype was straightforward to use, but the limited functional options made navigating the mockup difficult. In addition, larger elements like ship maps or ship itineraries were hard to parse on a mobile screen and testers sometimes lost their place when expanding or collapsing certain features within the mockup.
Conclusion
Overall, Dream Cruise became a much bigger challenge than I anticipated when I set out to create the mockup of a simple booking process. Despite these challenges, I was able to deliver on my initial goal of creating a reactive cruise booking flow with only minor sacrifices in usability and presentation of information. Though it was disheartening to fall short, the creation of this mockup led me to multiple new solutions I believe I could implement much more easily if I am able to reiterate on this project. Dream Cruise taught me a lot about how far I’ve come as a designer since I first enrolled in the UX Academy, but it also made me realize that there is still opportunity for me to learn.
All images of the images used for this project were sourced from the Pexels.com website under the Creative Commons liscence.