Designing software for cruise lines can be extremely tricky. Cruise ships are strange beasts; they have all the amenities and systems you would expect to find in high-end hotels, and also those you would find in restaurants, amusement parks, performing arts centers, and shopping malls. On top of that, they are built to withstand the trials of intercontinental ocean travel or even arctic exploration.
Most software developers have never written code for such a broad, and yet specific, use case. Designing a calendar system for reservations is not a difficult task for most programmers. But designing a calendar system for reservations where the time zone can change up to three times a day is a different matter. Add in the fact that ship time isn’t actually related directly to a time zone, and most developers wouldn’t know where to even start.
Because this is such a strange way of thinking, I’m going to go over five mistakes that I’ve seen software designers (and all sorts of other cruise beginners) make when trying to build systems for cruise lines.
1. Overwhelming audiences
Picture an interactive TV system for passengers onboard a ship. If every available service and system had navigational guidance, it would be cumbersome and overly complicated. Now scroll to the Entertainment section. If this included dancing in the atrium, movies on demand, musicals in the theater, television shows, and streaming music options, it would probably make for a pretty confusing experience.
When it comes to deciding what to include and where to include it, context is also critical. There are only a few “states” the ship can be in:
-
Passengers move around physically on the ship,
-
The ship changes between sea days and port days,
-
The ship changes country or city,
-
And passengers change from being onboard to being out on excursions.
Knowing what these states are, and designing your information delivery around them, is key to a friendly, usable technology strategy.
2. Building in technology for the sake of having technology
Adding new technology is often seen as a competitive advantage in the cruise industry. But it’s important to consider whether that technology matches the intended audience.
Facial recognition is a useful tool for a crew member to learn about a passenger immediately before an interaction. But does this technology appeal to passengers who are 65+? Or would a cruise line targeting this group actually hurt themselves by incorporating and promoting it?
Technology should be appropriate for the passengers who will use it. An app that explores the nightlife of different ports would probably be out-of-place on a cruise tailored for families with young children. More tech is not always better, and unnecessary tech can lead to high operational costs for maintaining systems in the long term.
3. Not accounting for intermittent connectivity or high latency
As mentioned in a previous article, no matter how “connected” a ship is, it is still an island. Satellite connections are getting faster every day, connectivity is getting cheaper, and throughput is increasing. However, cruise software is still unusual in that it needs to be able to work either offline or only on a local network.
The problem is that most programmers have never really encountered this challenge unless they were developing software before 2002. Any programmer under 35 has probably never really had to worry about serious intermittent connectivity issues, offline caching systems, and locally available content.
A typical solution to this is to create a screen that says, “We’re sorry, you appear to be offline. Please try again later.” But this isn’t the experience you want for guests.
4. Building for general, not specific audiences
It is very easy for an app designer to sit down and start working on a project from a few simple “user stories.” These are small problem-statements used by developers to describe what a user should be able to do with an application.
A typical example of a user story is, “The user is able to log into the app and immediately see their itinerary for the cruise.” This helps developers by allowing them to understand how the technology needs to be used, which empowers them to make decisions about how it’s designed.
The problem here is not actually the developers, but the user story. To target very specific demographics, income brackets, and levels of technological prowess, you need to create detailed user stories. If you are ever asked to write a user story for a cruise line application, start with a very strong concept of your “avatar” or “persona” (i.e., your ideal, novice passenger) before you even get to the tasks they should be able to complete. Describe them by name, give them a background, and preferably find a picture of “them.”
5. Thinking of a cruise ship like a floating hotel
Having hired developers who came from the hospitality world, but not the cruise world specifically, I’ve learned a few lessons about assumptions that even experts make. It’s important to understand that a cruise ship is not a floating hotel. Yes, it has a hotel onboard, but it is more than the sum of its parts. The analogy I’ve heard that struck a chord with me was “a floating resort,” but even that falls slightly short of the cruise experience.
Cruises are the transportation and the destination. The ship itself is an escape for many passengers, in the same way that a resort is a destination. However, this is broken up by port days, where even the most poolside-loving passenger is usually going to head into town. This means that there are radically different contexts for the technology used by guests.
A mobile device, for example, will be connecting to different networks with completely different backend systems. These backend systems will likely be unable to communicate with each other in real time. Concepts like this are crucial when creating a cruise-related application.
If possible, it’s important to experience at least one cruise if you design technology for the industry. This is a great first step for ensuring that you don’t make the mistakes I’ve mentioned. The closer you can get to an actual product being used in the “real world,” the better you will be able to understand it. Check in, carry on your bags, book shore excursions, take in a show, book a massage, buy something from one of the concessionaires — whatever it takes to make sure you internalize the experience of a cruise ship.
If possible, try to interact with passengers. Building software avatars is extremely important, but nothing beats meeting the real life end-users of your systems. This also helps you to create even more accurate user stories. It humanizes everything you do, and it creates empathy, which is often missing in the process of engineering technology systems.