under three minutes
Ruby GmbH · Self Check-in · 2025
A full redesign of the Ruby self check-in kiosk, built to close one gap: the original made guests adapt to how the system stored data, instead of how they actually think about their own information. Three friction points surfaced in testing. The sharpest was guest list management, where only 26.7% of guests completed the task successfully. The most complex was data collection, where guests from nine countries each face different legal requirements. All validated through comparative testing across 180 tests.
Year
2025 — 2026
Role
End-to-end UX · Research · Interaction Design
Team
Product Manager · Engineers
Platform
Web Kiosk
The problem
One interface. Nine countries. Guests couldn't see where they were, what came next or how long it would take.
Every friction point traced back to the same root: the interface was built for the database, and the person using it had to adapt to it. One field per screen, no progress indicator, uncertainty from the first screen. Three surfaced in testing: a data collection flow structured the way the system stores information rather than the way guests think about their own; a business invoice flow that caused guests to enter personal home addresses where company addresses were required; and guest list controls buried so far below the primary action they were effectively invisible.
What I owned
End to end UX for the redesign: research, information architecture, interaction design, and the functional prototype used for testing. I ran all 180 moderated sessions and analysed the results.
I worked with a Product Manager and the engineering team, and stayed with the work through implementation rather than handing it off once the design was validated.
How I tested it
I built a functional prototype using AI-assisted tooling, close enough to the real product that guests could complete the full flow without assistance. I then ran 180 moderated usability tests, split evenly between the current version and the redesign, across three check-in scenarios — 30 per version each — including business guests and groups.
The flow presented one field per screen with no way to gauge scope. Business guests entering company address details would frequently enter their personal address instead. The field structure gave no cue that a different address was expected.
Fields grouped by type (personal info, ID, address), with conditional logic per nationality and legal requirement. Only the relevant fields appear for each guest.
Before
After
Results
The decision and trade-offs
The obvious fix for a flow guests found confusing is to explain it better. Add a progress indicator, label the steps, show what is coming next. That would have moved the numbers and left the structure intact.
I restructured it instead. The flow was ordered the way the system stored data, and no amount of labelling makes a database schema feel like a conversation. Fields are now grouped by what they mean to the guest: who you are, your ID, where you live, with conditional logic so each guest only sees what their nationality legally requires.
No one pushed back on this. I presented the current kiosk against the test data before proposing anything, and the numbers made the argument before I had to. A guest list flow that only 26.7% of people could complete is not a finding anyone wants to defend.
What I could not change was the legal requirement itself. Nine countries, nine sets of mandatory fields. The redesign hides that complexity from each guest. It does not remove it.
AI in the process
I integrated AI tools into both the research and design phases. For research: synthesising guest feedback and support data faster than manual analysis allows. For prototyping: generating a functional, testable version of the redesign in a fraction of the time a coded prototype would take. The design decisions were mine, and none of them shipped on that basis alone as the AI-built prototype had to clear the same 180-test validation as the rest of this redesign before anything was finalised. AI accelerated the work. It didn't replace the check.
Outcome
Measured on real Ruby Hotel guests, full check-in from first screen to confirmation. Solo guests: 3m36s (v2.0) to 2m53s (v3.0). Groups of two: 5m02s to 3m56s. Across 180 tests with real hotel guests.
Solo check-in time
Group check-in time
Planned rollout · Q3 2026
