Roomside
The platform brings a guest’s whole stay into one connected experience. Booking details, hotel amenities, room service, nearby events, attractions and control of the room sit side by side. The room TV works with the guest’s phone as one continuous flow.
Project snapshot
Timeframe
Mar 2025
↓
Jun 2026
Goal
Grow the proof of concept into a product: address the requested changes, fix and extend its features, and support the team towards the first release.
Deliverables
↗ Information architecture
↗ Roles and permissions
↗ The guest app (PWA)
↗ The in-room TV app
↗ The hotel CMS
↗ Components and screens in Storybook
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 and had 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, and a read through the feedback that the pilot customers had already given.
The guest app came first, because it was the weakest part of the platform. I worked out the best paths through it from the user scenarios, then designed the interface. 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 corridor tests, the same screens shown with different ways of moving between them.
I built two navigation models and tested them on user scenarios, each with its own prototype link. 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.
From structure to a working product
With the structure in place I turned the scenarios into screens for the guest app, the TV app and the CMS, and handed each one over as working components and screens in Storybook.
One rule ran through all of it. A hotel is rarely fully set up, so every screen has a state for what is missing: no content yet, only part of the services, no smart controls in the room, a TV that does not answer. The guest never sees a broken screen, and a hotel can start with what it has.
In the CMS I worked through the roles with the backend developer, so each person sees and changes only what their role allows.
The guest app
The app is organised around a radial dial with the five places a guest goes: My stay, My room, Remote, Hotel and Discover. Every screen below the first level keeps the same header and the same large title, so a guest always knows where they are.
It covers the whole stay. A guest scans the code on the TV card, sees the booking, sets the room to night, picks a channel, orders dinner and watches the order arrive.
From photos to a model, from the model to images
My room needed pictures of one room from angles nobody had photographed. An image generator on its own invents a new room every time, and a picture that disagrees with the room map breaks the product.
So I built a prototype that maps a space from photographs. It started from one photo of a hotel suite found on Unsplash. Deep research found more photographs of the same suite. With a few known dimensions, I fitted every photograph to one model of the room, a method called image-based modeling.
Every image comes from that model. The isometric map of the room, by day and by night, is the control surface in My room. For a new shot I place a camera in the model, render a colour key with a labelled plan, and give it to the generator with a prompt and references. That is why the guest scanning the code on the TV and the guest ordering room service from the jacuzzi are in the same room. The code on the TV is a real one, pasted in with perspective, and it opens my portfolio.
Components in Storybook
Storybook was the single source of truth for the developers and the place of the whole component handover. I implemented the components from Figma with Claude Code, following one set of front-end instructions: a brief with rules, a project log, a decision log, motion guidelines and an asset library. Meeting transcripts and decisions went straight into the project repository, so design and code stayed in step.
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.
Working with AI
The product was tested inside the team and with a few hotels in a closed pilot, and the work continues on the structure described above. AI agents worked from a written project schema with the architecture, the decisions, the vocabulary and the rules for each task. They sped up implementation and feature work a lot, while every decision and every review of their output stayed with a person.
Reach out to me directly if you want to discuss a similar project
Need a PoC in days?
Product Designer
Michael Kulesza
Let's talk!
Pick a slot!
10
CareFlow
Proof of concept for remote pregnancy monitoring
7-day build
⬥
ai-assisted
⬥
Investor ready
09
21st.ai
Feature development for corporate governance SaaS
7+ features
⬥
9 months
⬥
ds refactor