RehearseHQ

✧

RehearseHQ ✧

Designing the digital presence of an autonomous AI-powered bartender

Yanu is a robotics start-up building a fully autonomous bartender that prepares and serves drinks, processes payments, and interacts with users in real time. This project was developed during my time at Havas, where I collaborated closely with a Lead Designer and a team of developers.

The project focused on designing the main landing page and ICO fundraising experience, translating a highly innovative product into a clear, engaging, and visually compelling digital interface. The approach centered on crafting a strong product narrative—showcasing the technology, its real-world applications, and its value for both users and investors through a cohesive and forward-looking design system.

Role: UI/UX Designer

Team: 1 Lead Designer

Client: Robotics start-up in Estonia

AI tools used: Claude, Perplexity

Website

Concept & Challenge framing

Problem statement

Living abroad, that experience had become frictionless. Most studios I used had online booking systems where you'd check availability in real time, pick your room, pay, get a confirmation, done. It may wasn't glamorous, but it worked flawlessly.

Then I came back to Spain. The contrast was jarring.

Here, the vast majority of rehearsal and recording studios still operate the way they did fifteen years ago (a WhatsApp message to ask if Saturday afternoon is free or a phone call to confirm, a note in someone's diary…). No real-time availability, no online booking, no paper trail beyond a chat thread. If you want to modify or cancel, you start the conversation over again.
At first I thought it was a local quirk. But the more I looked into it, the more I realised this wasn't just an inconvenience for the musician, it was a symptom of something deeper on the business side. Studio owners and managers are running operationally complex small businesses with surprisingly primitive tools. They're fielding the same repetitive enquiries all day, manually juggling bookings across phone calls and chat apps with no reliable way to anticipate no-shows or understand which rooms and time slots are actually driving their revenue. The patchwork works, until it doesn't. A no-show on a Friday evening with no waitlist to fall back on, a double booking from a missed message, or a month-end with no clear picture of where the money came from for example.

AI has changed what's possible here. Booking data, session history, cancellation patterns, demand by day and room type or client behaviour is exactly the kind of structured, repetitive dataset that predictive models handle well. The opportunity here isn't to replace the studio manager; it's instead to give them the kind of operational intelligence that, until now, only large-scale venue businesses could afford.

This project explores what a smart, AI-powered studio operations dashboard could look like. Designed for the independent studio owner who is, more often than not, a fellow musician first and a business operator second.

Opportunity Framing

The music rehearsal and recording studio sector is largely made up of independent, owner-operated businesses. Unlike hotels, coworking spaces, or sports facilities (all of which have seen significant investment in booking and operations software) studios have been largely overlooked by the SaaS industry. The few tools that exist are either generic booking platforms not tailored to studio workflows or overly complex venue management systems built for a different scale and budget.

This leaves a clear gap: a purpose-built operations tool designed around the specific rhythms of a music studio.

The operational data that studio owners already generate (booking history, cancellation rates, room occupancy by time slot, repeat client behaviour) is exactly the kind of structured, recurring dataset that AI prediction models are most effective with. Until recently, the cost and complexity of building on top of ML infrastructure made this inaccessible to small businesses. That barrier no longer exists.

This creates a specific opportunity: not to automate the studio manager out of the picture, but to surface the patterns hidden in their own data and turn reactive decision-making into proactive operations. For example, knowing a Friday evening slot has a 40% no-show rate is actionable, knowing that Room B consistently underperforms on weekday mornings is actionable. Today, most studio owners don't know either.

The studio owner persona presents a distinct design challenge: they are domain experts in music and sound, not in data or business operations. A dashboard that surfaces AI-driven insights needs to earn trust quickly and never make the owner feel like the tool is smarter than they are. This project explores that intersection.

Market landscape snapshot

The studio booking software market is more active than it might appear but almost entirely concentrated in the Anglo-Saxon market. GDPR support, cross-border payment handling, and country-specific operational details are factors that can meaningfully affect how well scheduling software works in markets like Spain, and most of these platforms offer minimal localisation.

The tools that currently exist fall into three distinct categories, each with its own limitations when viewed through the lens of this project:

Platforms like Skedda, CozyCal, Acuity Scheduling and Koalendar were built as horizontal scheduling solutions and have been stretched to cover studio use cases. Skedda's standout feature is its customisable booking rules, minimum and maximum time blocks, buffer times, and access permissions based on user roles. But it was designed for shared spaces broadly, not music studios specifically. CozyCal positions itself as a straightforward solution focused on getting clients to self-book, with calendar sync, Stripe payments and intake forms, but offers nothing tailored to the context of a rehearsal or recording environment. These tools solve the booking problem adequately but they don't touch operations or intelligence

A handful of tools have been designed specifically for music studios. Jammed is built for independent rehearsal studios and creative spaces, it handles real-time room availability, automatic reminders, cancellation and refund policies and even equipment hire inventory. AllBooked similarly allows studios to configure individual rooms, define availability and minimum session lengths and manage reservations in real time with over 4,000 customers on the platform. StudioHero goes further, targeting professional recording facilities with engineer scheduling, project tracking, and financial oversight in one workspace. These are credible products but they are operationally focused, not intelligence-driven and their market penetration outside the UK and US appears minimal.

Anolla markets itself as an AI-powered platform, claiming a contextual AI assistant that can resolve up to 79.3% of repetitive booking enquiries in real time. However, the AI layer here is essentially a customer-facing chatbot that handles FAQ automation, not operational prediction. No tool in the current market appears to surface demand forecasting, no-show risk, or revenue optimisation as core features.

Mapping the competitive landscape reveals a clear white space: there is no tool that combines purpose-built studio operations with AI-driven intelligence designed specifically for the independent owner-operator who is not a business analyst. The products that come closest to this vision either lack the AI layer entirely, or (like Anolla) apply AI only at the customer communication layer rather than the operational core.

Research phase & Direction

User interviews

With a clear picture of the competitive landscape (a market largely untouched by meaningful AI integration) the next step was to get out and talk to the people this tool would actually serve to get first-hand information about how people operate regarding music studios.

I conducted three interviews across two distinct user profiles: the owner of a local rehearsal studio in Málaga where I regularly go myself to practice, and two of its habitual users (one a musician who books the space for band rehearsals, and one a drums teacher who uses the studio on a recurring weekly basis).

The fact that I already had a relationship with this studio as a client myself shaped the approach from the start. I wasn't walking into an unfamiliar business to ask cold questions, I was talking to people I knew in a space that I understood. That familiarity made the conversations more candid and sincere than a formal research setting typically allows, and it also meant I could read the room in a way that's harder to do as an outside observer.

All three sessions were conducted in person at the studio, which proved as informative as the conversations themselves. Seeing the booking system in its natural habitat (a Google sheet, WhatsApp conversations, a price list taped to the wall…) grounded every answer in a reality that no remote interview could have captured with the same texture. Sessions ran between twenty and thirty minutes. With consent from all participants, interviews were recorded and later transcribed using Dovetail, which allowed me to tag key moments, surface recurring themes, and identify shared pain points across profiles without losing the nuance of individual responses. Working this way meant I could stay fully present during the conversations rather than splitting attention between listening and note-taking.

The interviews were structured loosely around three areas: understanding the current booking workflow end to end, identifying the moments of highest friction and exploring attitudes toward technology and automation, without steering participants toward any particular solution. The goal at this stage was to listen, not to validate.

What emerged challenged some of my initial assumptions and sharpened others considerably.

User personas

After interviews completed and the findings transcribed in Dovetail, clear patterns began to emerge in how users had quietly adapted their behaviour to work around a system that wasn't reliable. These workarounds were the real signal and pointed to unmet needs that became the foundation for translating raw research into something the design process could actually use.

From the interviews I distilled three personas, one primary and two secondary. Carlos, the studio owner, is the primary user of the tool being designed: every decision needs to serve his mental model, level of technical confidence and the reality of running such business. Lucía and Miguel represent the two distinct and most common type of client profiles. Understanding them is not incidental to the design, it is the reason the AI layer has anything meaningful to say.

Rather than treating these personas as static profiles, the goal was to capture the tension each person lives with: the gap between what they need the experience to be and what it currently is. That tension is what the product exists to resolve.

Jobs to be done (JBTD) & How Might We

Personas tell us who the users are. Jobs to be done tell us what they are actually trying to accomplish and why. Rather than focusing on features or demographics, the JTBD framework reframes each user need as a job with a specific trigger, a motivation, and a desired outcome. This shift in perspective is particularly useful when designing AI-powered tools, because it keeps the focus on the human intent behind the data rather than the data itself. Each statement follows the same structure: when a specific situation arises, I want to take a particular action, so I can achieve a meaningful result.

HMW statements are the bridge between what the research revealed and what the design will solve. Each one reframes a pain point or unmet job as an open design opportunity, specific enough to be actionable, broad enough to allow more than one solution.

Empathy Maps

Empathy maps capture the full texture of how each person experiences the problem: not just what they say and do, but what they think and feel when no one is asking them a direct question.

For this project, building empathy maps from the interview findings was a deliberate exercise in reading between the lines. The most revealing moments rarely came from the answers themselves, but from the behaviour that surrounded them. These are not complaints. They are adaptations. And adaptations are the clearest signal a designer can have that a system has failed the people using it.

The maps reveal a pattern that no single interview surfaced on its own: every person in this ecosystem has quietly built a workaround to compensate for the absence of a reliable system. The product being designed exists to make those workarounds unnecessary.

Competitive Audit & Mind Maps

The market landscape snapshot established where existing tools sit relative to each other. The competitive audit goes one level deeper. It examines how they actually work, where the experience breaks down, and what each product does well enough to learn from. The goal is not to catalogue features exhaustively, but to build a clear-eyed picture of the space our design is entering and to ground every decision that follows in something more rigorous than intuition.
Four products were selected for the audit, each representing a distinct position in the competitive landscape.

Each tool was evaluated against eight criteria drawn directly from the research findings and the jobs to be done. These are not generic audit dimensions, each one maps to a specific pain point surfaced in the interviews or a design opportunity identified in the HMW statements.

Two findings from the audit are worth foregrounding before the detail. First, no existing tool combines studio-specific functionality with any meaningful layer of operational intelligence. Second, the only product attempting AI (Anolla) applies it entirely toward the client-facing side of the experience, leaving the owner's decision-making completely unsupported. Both gaps point in the same direction, and both inform the design that follows.

User Journey Maps

Journey maps show what actually happens as each person moves through a specific scenario. And it is in that sequence, more than anywhere else, that the real shape of a design problem reveals itself. Three journey maps were produced, one per persona, each covering a scenario chosen to surface the highest concentration of friction and unmet need.

Each map is structured across five layers: what the user does, think, feel at each stage, where the experience breaks down and where the design has an opportunity to intervene. The emotion curve makes visible the moments where the experience drops, and more importantly it shows whether those drops are recoverable within the same journey or whether they leave a residue that carries into the next one. These are not isolated pain points. They are connected, recurring, systemic and the product being designed needs to address them as such.

Synthesizing insights & project scope

Insight → Opportunity mapping

The insight → opportunity mapping is the critical bridge between the research phase and the design phase. Each insight is a distilled truth extracted from the research (specific, evidence-based) and stated as a fact about the users or the problem. Each opportunity is what that insight makes possible from a design perspective. Together they create a transparent, auditable chain of reasoning that shows every design decision in the UI phase has a root in something real.

Feature Prioritisation (MoSCoW)

With the insights mapped to design opportunities and the full solution space explored through the mind map, the next step was to make deliberate decisions about what to build, and equally importantly, what not to. The MoSCoW framework was applied to bring structure to that process, sorting every identified feature into one of four categories: must have, should have, could have, and won't have in this release. The prioritisation was driven by three criteria working in combination: research grounding, dependency logic and trust & adoption risk.

Scope definition (Roadmap)

With the MoSCoW prioritisation complete, the final step before moving into design was to translate those decisions into a clear, phased product roadmap, a document that defines not just what will be built, but when, and in what order, and how success at each stage will be measured before the next one begins.

The roadmap is structured across three phases. Phase 1, the MVP, establishes the foundation. Phase 2 builds on that foundation by enriching the data layer and introducing automation features that compound in value the longer the product is in use. Phase 3 represents the long-term vision (deeper intelligence, multi-operator support, and a client-facing booking product that extends the platform beyond the owner's dashboard entirely).

The sequencing is not arbitrary. Phase 1 must do two things simultaneously: solve a real operational problem from day one, and build enough trust with a sceptical, low-tech user that he is willing to act on AI recommendations. If either of those conditions fails (if the product is useful but not trusted, or trusted but not useful) Phase 2 never gets a chance to prove its value. Every design decision in the MVP phase is therefore shaped by that constraint: the product must be intelligent, but it must feel like an assistant, not an authority.

It is also worth being explicit about what this project covers. The design work that follows focuses exclusively on Phase 1, the MVP layer. Phases 2 and 3 are included in the roadmap because a product without a forward trajectory is not a product, it is a prototype. But the wireframes, the design system, and the prototype that follow are all scoped to the seven features that make up the foundation. That is the right scope for an MVP, and it is the right scope for a case study that aims to do one thing thoroughly rather than three things superficially.

Design principles

Research tells you what the problem is. Prioritisation tells you what to build. Design principles tell you how to build it and more importantly, how to make consistent decisions when the answers aren't obvious.

Six principles were defined for this product, each one derived directly from the research and the specific constraints of designing an AI-powered tool. They are not aspirational statements about simplicity or delight. They are working beliefs that carry real implications for every design decision in the UI phase.

Two principles deserve particular attention because they shape the product's relationship with AI more specifically than the others. The first is about time: earn trust before you ask for it. The design response to that finding is a deliberate strategy of progressive capability and only introducing automated actions once the accuracy of those observations has been felt, not just explained.

The second is about control: AI suggests, user decides. This is not a concession to a difficult user. It is the correct design position for any AI product where the stakes of a wrong decision are personal and financial, and where the user's sense of professional identity is bound up in their ability to manage their own business.

Taken together, these six principles form a brief that the visual design and interaction design must answer.

Information Architecture

Before a single screen is designed, the product needs a skeleton, a clear map of every section, every screen, and every state that the design will need to account for. Information architecture is that map. It defines how the product is organised, how a user moves through it, and where every piece of functionality lives relative to everything else.

For a product like this one, getting the IA right carries particular weight. The architecture needs to feel immediately intuitive and organised around the categories that make sense to an engineer or a product manager. The IA is structured across six primary sections. Overview is the entry point. Bookings is the operational core, housing the calendar, the booking management tools, and the recurring booking system. Intelligence is the product's defining section (the AI layer made visible). Revenue houses the business intelligence layer: occupancy data, revenue trends, and the weekly and monthly summaries. Clients brings together the client profiles and booking histories that enrich the AI predictions over time. And Settings provides the controls that make the product the user’s own.

Two structural decisions are worth making explicit. The first is that Intelligence sits as a primary navigation item, not as a sub-section of Bookings or Revenue. This is intentional as it signals from the architecture outward that AI is not a feature added on top of a booking tool, but a first-class capability that shapes how the entire product operates. The second is that AI behaviour lives in Settings, not buried in a help menu or an onboarding flow.

UI Design & Prototype

Low-fi wireframes

With the information architecture defined and the scope locked to seven MVP features, the next step was to translate structure into layout to move from what the product contains to how it actually looks and behaves on screen.

The wireframes were produced digitally using Uizard, an AI-assisted design tool that generates screen layouts from natural language prompts. Uizard was chosen deliberately at this stage for two reasons. First, it accelerates the low-fidelity phase significantly, allowing multiple layout directions to be explored in parallel rather than sequentially. Second, using an AI tool to design an AI product creates a productive tension that sharpens the design thinking, when a generated layout handles a prediction or a recommendation poorly, it becomes immediately obvious what a human-centred design would do differently.

Each screen was generated from a detailed prompt describing the context, the key UI components, and the specific interaction logic required. The outputs were then reviewed critically and annotated with the reasoning behind each structural decision. The wireframes are the result of a deliberate dialogue between AI generation and human design judgment, which is precisely the working relationship this product is designed to enable for users.

Design system

A design system is not a deliverable that comes after the design. It is the foundation that makes consistent, scalable design possible in the first place. Before a single high-fidelity screen was produced, the visual language of the product needed to be defined: the colour palette, the type scale, the spacing logic, the component behaviour, and the visual grammar that would make AI-generated content immediately distinguishable from manually entered data. Getting these decisions right at the system level means every screen that follows is coherent by default, not by accident.

The visual direction for this system was developed through a deliberate process of AI-assisted exploration, one that is itself worth describing, because the how is as relevant to this case study as the what.

Two AI tools were used in combination to develop and stress-test the visual concept. Claude was used to define the strategic rationale behind each design decision, i.e. generating the colour scale, articulating the token structure, establishing the AI visual language rules, and documenting the reasoning that connects each visual choice back to the research. Lovable was used to render visual concepts quickly and explore how the same design system behaved across different UI contexts, making the outputs tangible and comparable rather than purely theoretical.

The reason for using both tools rather than just one was intentional. Different AI tools produce different kinds of output. Claude reasons through decisions and produces structured documentation. Lovable generates rendered interfaces and visual explorations. Using them in combination meant the system could be interrogated at two levels simultaneously: does it make sense conceptually, and does it actually look and feel right in practice?

Component Library

The component library for this project was developed in Figma, following the visual direction established through the AI-assisted exploration phase. Rather than generating components automatically or accepting any single tool's output wholesale, the approach was deliberately synthesising: taking the most coherent extracts from what Claude and Lovable had each produced (where one reasoned clearly about component logic and the other rendered it convincingly in context) and using those as raw material to craft something more considered and internally consistent than either tool had produced alone.

This distinction matters and is worth being explicit about in a project where AI tools play a visible role. Claude produced structured documentation (token hierarchies, component behaviour rules, usage guidance, the reasoning behind decisions). Lovable produced rendered interfaces (visual explorations that made abstract system decisions tangible and comparable). Neither output was a finished component library. What both outputs provided was a high-quality starting point and a set of creative constraints to react to. The actual library, (the one with properly structured variants, auto-layout behaviour, connected token references, and the interaction states that only become visible when you try to use a component in a real screen) was built by hand in Figma, through the kind of considered iteration that no generative tool currently replaces.

The AI-specific components are the most original contribution of the library and the ones that required the most iteration. No existing kit ships a confidence indicator that communicates both certainty and uncertainty honestly, or a suggestion card that makes the AI's reasoning legible without overwhelming the primary action. These had to be designed from first principles, informed by the research and the design principles. The component library is where those principles stopped being words and became structure.

High-fi mockups

High-fidelity mockups answer the question of what the product actually feels like to use, whether the visual language earns trust, whether the hierarchy guides attention to the right place, whether the AI-generated content reads as intelligent and legible rather than intrusive or opaque.

Uizard's AI-generated screens had served their purpose in the wireframing phase: producing layout explorations quickly, forcing early decisions about screen structure, and giving a concrete visual reference to react to rather than starting from a blank canvas. But those outputs were starting points, not destinations. They lacked the precision, the component consistency, and the design logic that a product of this ambition required. Moving them directly into a prototype would have been like submitting a rough sketch as a finished illustration.

The intermediate step (building the component library in Figma) was what made high fidelity possible at scale. Because every element of the visual system had already been defined and structured as a reusable component with properly connected tokens, moving from wireframe layout to finished screen was largely a process of substitution and refinement rather than reinvention.

The screens designed at high fidelity cover every primary section of the MVP and include the key interaction states that a static mockup alone would miss. Together they form a complete, navigable picture of the product that was used directly as the basis for the interactive prototype that follows.

Interactive Prototype

The interactive prototype brings together the twelve high-fidelity screens into a navigable experience, one where the design decisions made over the course of the research, synthesis, and UI phases can finally be felt in sequence rather than evaluated in isolation. Clicking through a prototype reveals things that even the most carefully considered static screen cannot: whether a flow feels intuitive or hesitant, whether the transition between an AI alert and the action it requests feels natural or abrupt, whether Carlos would actually know what to do next at every step.

The prototype was built in Figma, connecting the high-fidelity screens through interaction triggers and transitions designed to approximate the real product experience as closely as possible within the constraints of a prototyping tool. It is not a fully functional build but it is sufficient to demonstrate the core value proposition of the product and to invite meaningful feedback on the experience rather than just the visuals.

AI feature UI patterns

When a product has AI at its core, there are certain recurring design challenges that appear again and again across different screens — challenges that standard UI component libraries don't have pre-built answers for, because they are specific to the experience of interacting with machine intelligence rather than static data or manual inputs.

AI feature UI patterns are the design solutions to those recurring challenges. They're not full screens — they're the smaller, repeatable UI moments that govern how the AI communicates with the user throughout the product. Think of them as micro-patterns that live inside your screens and define the character of the AI layer.