Gammalstorp Booking

A booking experience built on fairness

Eighty shareholders. Fifteen houses. One summer that everyone wants a piece of.

When Almenr's timeshare village in Gammalstorp, Skåne was taking shape in early 2023, the community needed a booking system. But a standard calendar — first come, first served — was a non-starter. The community wanted something else, something fair. My job was to figure out what that actually meant, and then design it.

I served as both UI/UX Designer and Product Owner throughout the project.

The key decision

Before I could design anything, I had to answer a question nobody had fully asked yet: what does fair actually mean?

Eighty shareholders sharing fifteen houses sounds like a logistics problem. It isn't — it's a social contract.

Equal time for everyone? Time weighted by share size? A rotation that guarantees everyone gets at least one summer week before anyone gets two? Each answer is defensible, and each one would produce a completely different booking system.

I convened a working group of shareholders and ran facilitated sessions to reach consensus. We used dot voting to surface preferences, then pressure-tested the leading model against edge cases: what happens when someone books last-minute in low season — should that count against their fairness score in high season? What if a shareholder never uses the village — do their points accumulate indefinitely?

I made sketches so that we could have something to discuss and ideate on.

Process

Paper prototype — simulating the algorithm

Before writing a single line of code, I built a paper prototype to simulate the prebooking flow. Participants received a printed "fairness score card" showing their current score, then walked through the steps of submitting a prebooking for a summer week — writing their preference on slips, handing them in, and watching me manually run the algorithm in front of them.

This was deliberately low-tech. The goal wasn't to test the interface — it was to test whether shareholders understood the logic: why they got the result they got, and whether they felt it was just.

The simulation surfaced two things early: people needed to see their score before they chose their dates (not after), and the score itself needed a plain-language explanation attached to it — not just a number.

Refining the weights

The fairness score combined several variables: previous high-season bookings, total nights booked in the past year, and share size. The first version weighted all three equally. Testing revealed this was wrong — shareholders who owned larger shares felt the share-size variable was underweighted, while first-time bookers felt previous bookings were penalising them disproportionately.

We ran two more working group sessions to recalibrate the weights, each time simulating outcomes against a dataset of fictional (but realistic) booking histories. The final model weighted previous high-season nights most heavily, with share size as a secondary factor and total nights as a tiebreaker. It wasn't elegant mathematics — it was a negotiated settlement. And that was exactly right.

From wireframes to mockups

With the logic agreed, I moved through wireframes and interactive Figma prototypes, testing each iteration with the same focus group. The most persistent friction point wasn't the fairness score — it was the booking confirmation. With multiple steps (prebooking → algorithm run → confirmation → payment), users consistently lost track of whether their stay was actually booked. I redesigned the status indicators and added a dedicated "upcoming stays" view to make booking state unambiguous at a glance.

Wireframes that were used to create the first prototype that could be tested with the focus group

Mid-fidelity mockup

The mockup in Figma, showing states and documentation

The solution

The finished application — integrated into almenr.dk — handles two booking modes: a prebooking window for high-season periods, where shareholders submit preferences simultaneously and the algorithm distributes stays fairly, and open booking for low season, where availability is first-come-first-served.

Shareholders can see their current fairness score at any time, with a breakdown of how it was calculated. An interactive map of the village serves as the primary navigation — houses aren't interchangeable, and the spatial view makes size and location immediately legible.

A community layer lets shareholders see who else is in the village during any given period, turning a booking tool into something that also serves the community's social life.

Outcome

The MVP launched in January 2024 and handled the first high-season prebooking round later that year. The process was messy — as any first run of a new algorithm with real stakes tends to be — but the community's trust in the system held, because the logic had been theirs from the start.

The most important design decision wasn't a UI pattern. It was spending weeks in facilitation before touching Figma — making sure that when the algorithm produced a result, nobody could say they hadn't agreed to the rules.