Roomside
The platform brings a guest’s whole stay into one connected experience. Stay details, hotel amenities, room service, nearby events, attractions and room controls sit side by side. The TV and the guest’s phone work together as one continuous flow.
Project snapshot
Timeframe
Goal
Grow the proof of concept into a product. Refine and extend its features, and support the team towards the first release.
Deliverables
- Information architecture
- Roles and permissions
- Guest app (PWA)
- In-room TV app
- CMS for hotel managers
- AI-ready design system in Storybook
- Photo-based room model that guides image generation
Toolchain
- Notion
- Adobe Illustrator
- Figma
- Storybook
- Gemini
- Claude Code
My role
- Product designer for all three platforms, from the proof of concept towards the first release, working closely with the team and designing straight into the product’s code.
Where I started
Roomside was at the pilot stage with two layers. The CMS was the B2B layer, where a hotel manages its content. The TV app and the progressive web app were the B2C layer, used by the hotel’s guests.
I started with an audit of both layers, a list of quick wins which could be effortlessly implemented. There was also some feedback that the pilot customers had already given.
The guest app came first. It is the part of the platform a guest actually holds, with every hotel service in one place. I wrote user scenarios from guest feedback, then prepared the interface together with the design system. The CMS followed. It had to keep up with the features the guest app gained and take in what the pilot customers asked for. The TV app came last, because the platform set it the tightest limits.
Information architecture first
Structure came before any visual work. I mapped the information architecture and checked it with the team in quick hallway tests.
I built two navigation models and tested them on user scenarios, each with its own prototype. The tests showed that the remote belongs in the main menu as a fourth item and that the navigation has to work for a hotel that has set up only part of its services. That shaped the navigation the product uses today.
For the CMS I prepared and led workshops with the whole team. We worked through the roles, the critical scenarios for a reseller and the first priorities for the MVP. The result was ten roles on five levels, where each level creates the one below.
Execution
With the structure in place I turned the scenarios into screens for all three surfaces and handed each one over in Storybook as working components and pages.
A hotel is rarely fully set up, so every screen has a state for what is missing. No content yet, part of the services, no smart controls, a TV that does not answer. Even when a hotel skips content in the CMS, the guest never lands on a broken screen or a dead end.
In the guest’s hand
After check-in, the first thing in the room is a code on the TV screen. One scan opens the app in the browser and signs the guest in to their stay. There is nothing to download and no account to create.
From there the phone is the guest’s way into the room and the hotel. They check the stay, switch the lights and the air conditioning, send a channel to the TV, order dinner to the room bill and see what is on nearby.
Image-based room modeling
Hotels rarely have photos of a room from every angle, and an image generator on its own draws a different room each time. So I built a prototype that turns a few photos of a room into one model of that room. From the model I can make any image that is missing.
I tested it on a hotel suite. It started from one photo on Unsplash, and deep research found more of the same suite. With a few known dimensions I fitted every photo to the model.
For a new image I place a camera in the model, render a colour key with a labelled plan and give it to the generator with a prompt. Every view, by day or by night, with or without people, shows the same room.
Handover in code
With Claude Code, the single source of truth moved from Figma to code. Every component, change and decision reached the developers in Storybook, as a working component or a story that shows part of a flow.
Figma stayed my playground, where I still explore ideas and build new views from the design system. A dedicated agent with design instructions could do this part as well.
I implemented the components following one set of front-end instructions: working rules for the agent, a project log, a decision log, motion guidelines and an asset library. Meeting transcripts and decisions went straight into the project repository. A lint run caught any drift before it reached the code.
The TV app
The TV app runs on a Full HD screen on a limited platform, so some features needed compromises. It uses dark mode by default, which tested best in a dim room and keeps reflections on the screen low.
The hotel CMS
The CMS is the hotel’s management tool, with many roles and levels of access. Separating those roles was the biggest challenge. Most of them came from what we learned with the clients during the closed pilot.
Deciding what counts
AI gave this project a memory and a pair of hands. It turned meetings into notes, rules into components and a few photos into any view of a room. What it could not do was tell which of those things mattered.
The decision log showed it first. AI gave a joke from a meeting the same weight as a real decision, so I checked every new entry against the transcript it came from.
The design system and the images taught me the same. One sharpened rule in the instructions broke something I had not touched, and the generator drew the right room only with a model to follow. Hotel rooms are predictable, so one photo or a building blueprint is enough to build one.
My role moved towards engineering, deciding what goes into the sources AI works from. The product was tested inside the team and with a few hotels in a closed pilot, and the design is in Storybook, ready for the team to take further.
