Company
Guesty
Guesty
Guesty · Booking Engine Setup
Redesigning a complex setup flow for self-onboarding
Guesty's Booking Engine Setup lets property owners publish a direct-booking experience, but the configuration flow was driven more by business and technical considerations than by user understanding. I redesigned the setup to reduce friction, support both beginner and expert users, and enable self-configuration without relying on support.
Project overview
A focused redesign inside a cross-functional product team
Period
Jul – Aug 2023
Role
Research · Information architecture · Visual design · Prototyping & testing
Team
Domain Lead · Design Lead · 2 Product Managers · Product Designer · 2 Developers
The Booking Engine Setup lets a property owner create a B2C booking experience within a third-party environment or a Guesty website. The redesign combined a visual refresh with a usability goal: remove obstacles that prevented owners from completing setup and publishing properties for direct reservations.
The challenge
60% of users did not complete the setup
The existing system lacked a self-explanatory interface and had usability problems alongside technical limitations. Many users abandoned configuration, so the final setup required support. Dashboard data revealed the problem and provided a measurable starting point for the redesign.
60%
of users did not complete the setup
Support
was needed to finish configuration
B2C
publishing was blocked when setup failed
Design opportunity
Design challenges
Objectives & constraints
The redesign had to work for both new and experienced operators
Reduce friction
Remove unnecessary decisions and clarify what is required at each step.
One flow, two skill levels
Support beginner and expert users without creating separate experiences.
Self-explanatory onboarding
Make the interface understandable without depending on support.
Save and continue later
Allow work to be preserved across a longer setup process.
Prepare premium conversion
Keep the flow ready for the future Premium website + Booking Engine plan.
Respect technical reality
Design within PMS, channel-manager and implementation constraints.
Process
A four-phase Double Diamond adapted to a short delivery window
The project progressed from requirements and problem definition to validation, prototyping, and delivery. Research hypotheses were checked with the team and internal stakeholders. Regular conversations with developers kept the proposed flow aligned with technical feasibility.
01 · Discover
Requirements analysis · problem understanding · usability review · hypothesis generation
02 · Define
Research · interviews · hypothesis validation · brainstorming · content organization
03 · Validate
Lo-fi prototypes · iterative developer alignment · task tests with internal users
04 · Deliver
Hi-fi prototypes · design-system application · materials prepared for implementation
Working principle
Research & definition
Define the user first, then restructure the setup
Early in the project, I needed a clearer picture of who was configuring the Booking Engine. I combined dashboard information with knowledge from designers who had worked longer with the product. Then I used brainstorming and card sorting with stakeholders to reorganize the content and validate the main architecture.
Property owners & operators
People responsible for configuring and publishing accommodation for direct booking.
Revenue managers
Hospitality professionals responsible for pricing, inventory and commercial performance.
Sales managers
Users with a sales or marketing background who need the booking experience to support conversion.
Marketing managers
Users focused on presentation, content and how the booking experience connects to the brand.
Architecture validation
Lo-fi & validation
Test the architecture before investing in the final interface
Once I defined the architecture and information hierarchy, I created low-fidelity prototypes to test the assumptions. Developer reviews were part of this phase because the proposal to save progress at every step revealed technical constraints that needed to be solved before visual refinement.
Validate with tasks
Use prototypes to check whether users and internal stakeholders understand the setup sequence.
Align with development
Review feasibility continuously instead of waiting for a final handoff.
Preserve progress
Treat save-and-continue-later as a core behavior, not a secondary enhancement.
Content status protocol
Green · Finished
Content reviewed and ready to move forward.
Yellow · In progress
Content still being defined or reviewed.
Black · Not reviewed
Content not yet validated by the team.
Final UI
Apply the Guesty design system to a validated flow
The high-fidelity phase translated the validated architecture and interaction rules into the Guesty design system. The goal was to ensure visual consistency and make the sequence, current state, and available actions easier to understand throughout the setup.
Guided progression
Each step makes the next action and required information easier to identify.
Clear system state
Users can understand where they are and what is already complete.
Save & resume
Longer configuration can be interrupted without forcing a restart.
Preview & control
Configuration choices are connected more clearly to the resulting booking experience.
Developer handoff
Document the system, not only the screens
Technical alignment happened during prototyping. The handoff focused on making implementation decisions explicit: component behavior, states, variants, and constraints imposed by the channel manager and property management system.
Components
Reusable elements and their intended behavior were documented for implementation.
States & variants
The team could see how inputs, selections and actions changed across the flow.
Technical constraints
Feasibility was documented alongside the design instead of being discovered after delivery.
Results & impact
The redesign reduced abandonment and made self-setup more viable
The new flow addressed the main friction points in the original setup and created a single experience for different expertise levels. The project also reduced dependency on support and improved the path to future premium adoption.
40% ↓
dropout from the setup process
30% ↑
efficiency during setup
25% ↑
successful self-setup
20% ↓
need for customer support
15% ↑
adoption of premium plans
Product outcomes
Unified setup flow
One process supports both beginner and expert users without splitting the experience.
Self-onboarding
The interface provides more context and guidance so owners can configure the product themselves.
Save and continue
Progress can be preserved, reducing the cost of longer or interrupted setup sessions.
Business connection
Learnings & next steps
What this project changed in my design practice
Understand technical constraints
Knowing the limitations of the channel manager and PMS was essential to designing a flow that could actually be implemented.
Use data to guide decisions
Dashboard evidence helped frame the problem, prioritize friction and create measurable product goals.
Design for accessibility
The setup has to remain usable for people with different abilities, expertise levels and working contexts.
Next steps
- Monitor the setup flow after implementation and connect completion to business outcomes such as published properties, bookings and revenue.
- Use the implemented analytics events to collect quantitative behavior data and identify remaining friction.
- Continue optimizing the experience from real usage while preserving the technical alignment established during the redesign.
Key takeaway