Enes Gundogdu
Product Designer
ENTERPRISE SOFTWARE / HOSPITALITY & TRAVEL
A complete screen redesign for Otalio SPMS, a ship property management platform, from guest information and dining reservations to POS setup and system settings.
MY ROLE
Lead UX/UI Designer
UI design, design system, components and prototypes
CLIENT
Otalio GmbH
Otalio SPMS (Shipboard Property Management System)
SCOPE
9 supplied screens, 5 operational areas
* SPMS: Shipboard Property Management System
Selected screens from my redesign of Otalio’s onboard operations platform.
01 The Context
Many onboard tasks. One enterprise platform.
Otalio SPMS is a ship property management system. Its current product overview brings together onboard services and revenue operations, with coordination between ship and shore teams. The original brief framed the design challenge around a multi-brand cruise corporation.
My redesign focused on nine supplied screens. The challenge was to give complex operational information a clearer structure while keeping the detail staff needed to do their work.
Drivers need to make that decision quickly. A missed condition can mean a fine, while uncertainty can send them looking for another space. ParkAid was designed around a practical question: can I park here, under these conditions?
Rules overlap
01
Hours, permits and vehicle restrictions can appear together on the same sign.
Time is limited
02
Drivers need useful guidance without spending several minutes decoding the wording.
Mistakes have a cost
03
A confident answer is only helpful if the driver can understand the conditions behind it.
02 Understanding the Product
Behind each screen, a connected operation.
A guest record connects several onboard services. A reservation, a purchase and an account are parts of the same passenger experience. This makes the redesign relevant to how departments work together, as well as how individual screens look.
The current product also describes fleet-wide configuration, ship-to-shore synchronisation and role-based access. These establish the wider enterprise context; they are not additional features I claim to have designed.
Rules overlap
01
Hours, permits and vehicle restrictions can appear together on the same sign.
Time is limited
02
Drivers need useful guidance without spending several minutes decoding the wording.
Mistakes have a cost
03
A confident answer is only helpful if the driver can understand the conditions behind it.
03 The Problem
Important information competed for attention
Passenger records combined personal details, cruise information, onboard accounts, documents and relationships. Other screens included large tables, configuration fields and lists of settings.
The brief asked for information that users could understand quickly. Each screen needed to help staff recognise where they were, find information relevant to their task and understand the available actions.
The starting point: original passenger search and guest profile screens supplied in the brief.
Rules overlap
01
Hours, permits and vehicle restrictions can appear together on the same sign.
Time is limited
02
Drivers need useful guidance without spending several minutes decoding the wording.
Mistakes have a cost
03
A confident answer is only helpful if the driver can understand the conditions behind it.
My Contribution
A complete redesign. Accross nine screens.
The research described in the project covered interviews, surveys and observations of drivers reading parking signs.
The findings pointed to three connected needs: a quick answer, guidance that considers the driver's situation, and a way to understand how the app reached its answer. Interest in AI did not remove concerns about its accuracy.
Otalio’s current guest services page describes centralised profiles containing preferences, history and loyalty details. This helps explain the importance of locating the right guest record before handling a request.
ParkAid research overview
Interviews
Explore how drivers interpret restrictions and what makes them hesitate.
Surveys
Understand reported confusion, time pressure and concerns about parking fines.
Contextual inquiry
Observe the task where it happens, with real signs and competing demands.
WHAT THIS MEANT FOR THE DESIGN
A short answer needed an explanation behind it. Drivers should be able to check the rule, not just accept the result.
ParkAid research articaft 01
ParkAid research articaft 02
03 The Solution
Scan. Check. Understand.
A focused journey from the parking sign to guidance the driver can inspect.
Early design exploration
ParkAid wireframes and prototype screens
Capture the sign
01
Start with a photo of the parking restrictions.
Check the image
02
Confirm the text is clear before interpreting it.
Read the result
03
See the parking status and explore the relevant conditions.
Original ParkAid high-fidelity designs
03 Design Decisions
Making the answer easier to trust.
Check the photo before processing
A blurred image can affect everything that follows. The captured photo is shown back to the driver with a prompt to check whether it is clear.
The aim: catch a poor scan before it becomes misleading guidance.
Keep the answer short, make the details available
The result gives drivers a clear starting point. Expandable conditions let them inspect restrictions without reading everything at once.
The aim: support a quick decision while keeping the reasoning visible.
Use the driver's context
Guidance considers the time and vehicle type. A general reading of a sign is not enough when a condition changes the answer.
Context-aware guidance
Give failed scans a clear next step
When the sign cannot be interpreted, the recovery path asks the driver to retake the photo rather than leaving them with an unexplained failure.
Unreadable sign recovery
Make the parking status easy to find
The result screen gives the parking status visual priority, with the conditions available below.
Unreadable sign recovery
04 Testing & Iteration
A fast result still needed an explanation.
The testing described in the original case study surfaced issues beyond the basic scan-and-result flow.
FEEDBACK
DESIGN RESPONSE
Drivers wanted to understand the interpretation.
Added plain-language explanations to the results, especially for rules with exceptions.
Low-light images could be misread.
Identified low-light capture as an area for further work. Improved capture and interpretation needed additional validation.
Some drivers needed other languages.
Identified multilingual support as a future development area.
The original write-up also describes a planned wider beta. Planned testing is kept separate from completed design changes here.
05 High-Fidelity Designs
The mobile experience
ParkAid mobile user flow
06 The Visual System
A design system build with custom components
I created a design system with custom components for ParkAid’s mobile experience.
Reusable components helped keep the screens consistent and made it easier to update the interface as the design developed. Figma variables supported shared colour choices, including light and dark modes.
ParkAid design system
ParkAid design system
06 Branding
The ParkAid identity
ParkAid research overview
06 Project Impact
From complex rules to a focused mobile flow.
The design brings sign capture, image confirmation, parking guidance and conditions into one journey.
A clearer decision path
The experience gives drivers a result first, with the relevant restrictions available to inspect.
A way to check the input
Photo confirmation and retake guidance make recovery part of the flow.
A foundation for further development
The branding and variable-based design system support consistent screens and theme changes.
Designing an AI-assisted experience means designing the moments around the answer too. The input needs to be clear, the explanation needs to be understandable, and users need a useful next step when something goes wrong.
Test recognition in low light, check complex combinations of restrictions, and validate language support before expanding the experience.
WALGREENS / VELOCITY