Limehome — App · 2025
In progressA central hub where guests organise their booking, check in, unlock their door and add services — replacing a scattered mix of emails, links and support chats with one place that always answers “what happens next?”.
Still being finished
The research, architecture and flow work is documented here in full. The final Limehome screens are still going through internal review, so the UI shots are placeholders for now.
Request the full deckProject type
Product design & design system
Role
Lead Digital Product Designer
Platform
Mobile app (iOS & Android)
Year
2025
Key outcomes
1 place
Booking, check-in, access and services unified
SparkUI
Built entirely on the in-house design system
Fewer tickets
Self-service replaces repetitive guest support requests
Cross-team
Shipped with product, engineering and operations
Context
Limehome is a fully digital hospitality operator — there is no reception desk. The app is the front door: if a guest cannot find their access code or understand their check-in status, the only fallback is support.
Before Guest Hub, the essentials were spread across confirmation emails, deep links and separate flows. Guests reread emails to find codes, and operations absorbed the confusion as repetitive tickets.
Research
I combined a ticket audit with guest interviews and on-site shadowing. The two dominant profiles were not who the old flows assumed — the app was written for a leisurely browser, while most sessions were short, stressed and arrival-driven.
Business traveller · 1–2 nights
“I land late, I just need the door code and to know the room is actually mine.”
Goals
Frustrations
Family stay · 4+ nights
“Halfway through the stay I wanted late checkout and had no idea it existed.”
Goals
Frustrations
Two primary profiles, rebuilt from ticket clustering and guest interviews.
Opportunity
Information architecture
The legacy navigation mirrored internal systems: booking engine, access system, upsell catalogue. I ran a hybrid card sort with fourteen guests over the labels they actually used, then restructured the hub into four predictable groups.
Card sort — FigJam board
My stay
Getting in
While I'm here
Admin
Hybrid card sort — the clusters guests formed from 28 content cards.
Site map
App root
Home (stay-aware)
Access
Services
Booking
Resulting information architecture for the hub.
Process
User flow
Stay journey with the friction points the hub had to absorb.
Wireframes
Low-fidelity structure for each phase of the hub.
Solution
State machine
Upcoming
Booked, check-in not yet open. Action: prepare.
Check-in ready
Verification open. Action: complete check-in.
In-house
Access granted. Action: unlock and add services.
Checked out
Stay closed. Action: invoice and rebook.
The state model the home screen renders against.
Final Limehome UI is pending internal review — placeholders for now.
Impact
Reflection
In hospitality, clarity is service. Most guest frustration was not missing features — it was not knowing the state of their own stay.
Designing the hub as phases rather than pages kept the interface small while the product kept growing.
Next project
Limehome GmbH · 2024
Read next case study →