Repsal Busholmen / Performing arts service / 2025-Present

A rehearsal room should be easier to book than to explain.

Repsal gives independent artists an affordable place to work. I turned the practical reality around that room—space, equipment, availability, terms, requests, approval, and billing details—into one service people can understand before another email chain begins.

Visit Repsal All case studies

Repsal Busholmen website showing the rehearsal space and booking service.

total space

93 m²

About 60 m² is dedicated to rehearsal work.

people maximum

Capacity and safety are product information, not fine print.

daily time blocks

Day and evening slots make the booking unit explicit.

languages

Swedish, Finnish, and English support the actual user base.

The service problem

The room was simple. The transaction around it was not.

A freelancer deciding whether to book needs concrete answers: Is the room large enough? Is it equipped? Is my date available? What does it cost? Which rules will affect the work? A beautiful landing page that postpones those answers is just a decorative delay.

The coordinator has the opposite problem. An incomplete request creates follow-up work: missing dates, vague group details, absent billing information, or a booking made before anyone has read the conditions. I designed the public interface and the operational handoff as the same product.

The booking journey

Understand the room. Check the time. Send a usable request.

01Decide if the space fits
Dimensions, capacity, equipment, facilities, access, and imagery answer the first practical questions.
02Find a viable slot
The calendar exposes real availability before the user invests time in a request.
03Hand over complete information
The booking flow collects the selected time, contact details, billing data, and acceptance of the terms.

Decision support

Put practical evidence before persuasion.

Artists do not need lifestyle copy about creativity. They need to know whether the floor, schedule, price, and equipment can support the work. I made the room legible as a working resource, then let its character come through the images.

Room specifications stay close to the visual tour
Capacity and facilities remain easy to verify
Contact details appear where a real exception may begin

Calendar

Show availability without pretending every booking is automatic.

The calendar reduces guesswork, but the service still has approval, contracts, keys, cancellations, and human exceptions. The interface makes availability visible while preserving the coordinator’s role in confirming the arrangement.

Clear day and evening booking units
Availability before the form, not after it
A provisional request remains visibly different from a confirmed booking

Request quality

Make the form produce a decision, not another question.

A weak form moves ambiguity from the website into somebody’s inbox. I kept the chosen time attached to the request and collected the operational details the coordinator needs to confirm, invoice, and prepare access.

Selected dates and slots travel with the request
Contact and billing information arrive together
The summary gives the applicant one final chance to spot a mistake

Terms

Rules belong inside the journey.

Cleaning, keys, cancellations, insurance, capacity, and shared use are not legal decoration. They determine whether the space can keep serving multiple groups. I brought the rules forward and tied acceptance to the request.

Conditions are readable before commitment
High-impact rules are expressed in plain language
The agreement stays connected to the exact booking

After the interface

Automate the repetition. Keep a human for the exceptions.

The useful outcome is not a clever calendar. It is less avoidable coordination: fewer requests for already occupied times, fewer missing billing details, and fewer surprises about how the room works.

I did not design the coordinator out of the service. I gave that person better inputs. Approval, unusual production needs, access arrangements, and last-minute changes still need judgment. Routine information does not.

One public source for availability, room facts, and conditions
Structured requests that can move into confirmation and invoicing
Explicit exception paths instead of a fake fully automated promise

HAAM’s role

I connected the public page to the work behind it.

Product, interface, and operations

HAAM’s role covered product structure, interaction design, booking logic, content clarity, responsive implementation, and the operational handoff. Graphic design by Otto Donner.

Next case study

One hundred objects. One continuous century.

View 100 Objects