I put the practical choices before the ticket.

An outing starts before a ticket

The search says Wrocław, yet a few of the results are in nearby towns. One performance runs at more than one time. The ticket price isn't on the list at all; it sits a step further in.

So before anyone picks a seat, there's a smaller decision to make: which of these evenings is worth bringing up with the person you're going with?

I took that moment as the starting point for an independent concept study. My question was how the interface could help someone carry a plan from browsing to ticket selection without losing the details that made the plan possible. In the working prototype further down, you can change those details and watch what happens when a seat stops being available.

Everything here comes from a review of the public site and the design work that followed it. KupBilecik didn't commission the study. I had no platform analytics, organiser data or access to customer research; the personas and the scenario critique are synthetic, and every performance in the prototype is fictional. There are no interview findings or sales results to report.

What I could actually see

I followed the public Wrocław results into one event and its seat map, with no seats selected, and stopped there: before choosing live seats, creating a reservation or entering personal details. Whatever happens later in checkout is outside what I saw.

On the pages I inspected, four things stood out:

• The event cards showed dates, venues and availability, but no ticket price.
• The Wrocław list included surrounding towns.
• On mobile, the radius slider reported a value of 50 to the accessibility tree but showed no number and no endpoints on screen.
• On desktop, the booking progress named seven stages; the mobile seat overview numbered them instead.

I treated each one as a question. A missing price on the card might make comparison harder, though it might also reflect a difficult inventory contract. A wide search area could surprise someone who only wanted the city and help someone with a car. The design had to show those choices without pretending I already knew which one mattered most.

Finding a useful research question

My audience hypothesis is an occasional planner arranging an outing with another adult, someone who may start from a date or a spending limit and only find the event later.

A regular searching for a named performer is the useful counterexample: a guided questionnaire would only put work in their way before a simple search.

I framed the research around a recent outing: what was already fixed before the event was chosen? An interview would reconstruct one real attempt, including an abandoned one, with the participant's own links or calendar if they want to share them. Asking whether a budget filter sounds useful would only invite agreement with my solution and tell me little about the actual decision.

The approach follows GOV.UK guidance on research in discovery. I'd recruit beyond designers and friends, include people with different transport and access needs, and keep what someone remembers apart from what they do during a session. None of these sessions has happened yet.

The original brief also sets a stopping rule for the guided planner: continue only if date or place organizes at least three of six reconstructed core episodes before an event is chosen. That's an investment decision made on a small recruited sample, so it can't estimate what the wider population prefers, and synthetic scenarios can't count towards it.

A synthetic objection changed the brief

Before treating these controls as a complete answer, I tested them against an AI-generated scenario: a shift worker planning an evening with an older cousin, getting around by bus and using a small phone with enlarged text. No real person took part and no behaviour was observed. The scenario was there to raise objections.

The sharpest one was about distance. A venue close by with an awkward late journey home could be a worse choice than a farther one on a direct bus route.

The same critique asked whether a budget for two includes fees and transport, and whether “available” means two seats together. Both are worth checking, although a simulation can't tell me how real people would rank them.

Three structures and what each one costs

I considered three structures, and each supports a different kind of work:

• a clearer local catalogue, which helps someone scan;
• an optional evening planner, which asks for constraints first;
• a persistent shortlist, which carries a comparison between options.

Building all three would bury the unresolved research question inside a bigger product.

Whichever structure survives, the content model matters. A production can have several performances. Each performance belongs to a venue and has its own ticket inventory, and a price band doesn't guarantee an adjacent pair. Spelling those relationships out helped me decide what a search result could promise and what had to be checked again once someone picked seats.

If real discovery turns up conflicting ways of grouping events, card sorting could help find the vocabulary. A tree test could then check the routes to another performance, a venue's access information or ticket help. Card sorting and tree testing answer different questions, and neither would show whether a seat map is readable or a total is understood.

Try the proposed decision

The working slice covers a small catalogue and seat selection. A few things to try:

• change the distance and the budget independently;
• include events that have no adjacent pair;
• choose a performance and compare the seat map with the list.

The interface is in Polish on purpose. A proposal should expose the language people would actually have to interpret when they decide.

Each card's total is the cheapest available adjacent pair in the fixture plus one order fee, so two cheap seats that aren't next to each other can't produce it. Once you pick seats, the summary names both and adds up their amount. Review needs adjacent seats inside the saved budget and search area. Go outside either limit and the interface shows the conflict and waits for a deliberate change.

The list is part of the same choice

The seat map and the list share one selection. Switch views and the chosen seats and the amount stay where they were.

• Each control names the section, row, number and price.
• The list states availability in words. On the map, an unavailable seat has its number crossed out.
• Every seat is a native button, so the whole selection works without dragging the map.
• The radius has a numeric field as well as a slider. W3C guidance on dragging movements treats an alternative to dragging and keyboard access as separate needs: the field covers the first, and the slider also works from the keyboard.
• Changes to the selection and the results get a brief visual confirmation, and meaningful updates are announced. Reduced motion removes the movement.

These choices sit inside a bounded simulation and make no claim about the whole checkout. Screen-reader use, enlarged text and the labels still need testing with the people who rely on them.

What would justify taking it further

Taking it further would mean three stages of work.

1. Before anyone sees this proposal, I'd ask people to reconstruct a recent outing. I'd look for the constraints that were already fixed, the events they rejected and the point where the companion joined in. The synthetic critique gives me questions to bring; it can't decide the scope or supply the answers.
2. A later session with the prototype would ask someone to find an evening for two, explain the search area and the total, then recover from a lost seat. I'd record the chosen performance and seats, misunderstandings, any help given and the reason for a changed choice. Timing during think-aloud would be diagnostic. A small moderated sample would support specific revisions without establishing a sales effect.
3. Production would need organiser-backed venue information, an inventory and pricing contract, and the service's real hold and expiry rules. Transport stays a separate dependency.

I left those promises out of the working slice on purpose, because a plausible-looking answer is harder to challenge than an explicit unknown.

The prototype ends with two seat numbers and a total that can still change. Press the unavailable-seat control and one number disappears while the original budget stays beside it. That's the moment I want a real participant to look at next: whether the plan they kept and the choice that changed are both clear enough to carry on.