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.

Repsal Busholmen website showing the rehearsal space and booking service.

total space

93 m²

About 60 m² is dedicated to rehearsal work.

people maximum

50

Capacity and safety are product information, not fine print.

daily time blocks

2

Day and evening slots make the booking unit explicit.

languages

3

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.

  1. 01Decide if the space fits

    Dimensions, capacity, equipment, facilities, access, and imagery answer the first practical questions.

  2. 02Find a viable slot

    The calendar exposes real availability before the user invests time in a request.

  3. 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

How we learned

Research

Service research

The useful research was hidden in the recurring questions around the room.

Room dimensions, equipment, booking blocks, availability, terms, billing needs, and incomplete requests revealed where coordination repeatedly broke down. Research focused on the actual transaction between artist and coordinator, not just the public page.

  • Service observation
  • Request analysis
  • Operations mapping
  • Content audit

Evidence trail

Why the interface is this way.

OPERATIONS DATA

Good interaction design should be traceable upstream. Depending on the project, that upstream work might be interviews, co-design, fieldwork, archive work, testing, analytics, or operations. Here is the shortest version of the chain from evidence to decision.

01

Evidence

Room dimensions, capacity, equipment, availability, booking blocks, terms, billing needs, and recurring gaps in requests formed the service data.

02

Interpretation

Avoidable coordination starts with uncertainty about fit, free times, rules, and whether a request contains enough information to approve.

03

Design decision

Put specifications and availability before the form, carry the chosen slot into the request, and bring key terms into the journey.

04

Result

The interface is designed to reduce unnecessary follow-up while preserving human approval for exceptions.

Help improve this website?

Optional analytics. Google Analytics and Clarity load only if allowed; form, email, and chat content are excluded.