Case study / Interaction design / Viirus Theatre

The hard part was not the homepage. It was the state between “what's on?” and “I have a ticket.”

Viirus is a theatre, but its website behaves like a time-sensitive public service. A visitor has to discover a production, choose a date, understand language and accessibility context, resolve whether that performance is actually available, and then cross into an external ticket system without losing confidence.

Client
Viirus Theatre
Role
Product strategy, interaction design, frontend implementation
Primary surface
Mobile repertoire, calendar, search, ticket paths
Constraint
Multilingual cultural content plus external ticketing
Visit Viirus
Viirus Theatre website homepage
The finished surface. The case study below is about the behavior underneath it.

Interaction model

A theatre visit begins as a chain of uncertainty.

The useful unit was not a page. It was the transition from vague interest to one actionable performance. Each step had to answer a different question without making the visitor reconstruct the theatre's internal content structure.

1

Discover

What is on?

2

Choose

Which performance?

3

Resolve state

Available, selected, sold out, focused

4

Understand

Date, language, access context

5

Handoff

Continue to external ticketing

Decision 01 / State

Make the performance state explicit before asking for a ticket decision.

A date is not enough. The same calendar has to communicate which performance is available, which one is selected, which one is sold out, and where keyboard focus currently sits. Those states are part of the information architecture because they change what the visitor can do next.

Design rule: do not make hover carry information that touch and keyboard users also need.

  • Touch has no persistent hover state.
  • Keyboard focus has to remain visible through dense calendar navigation.
  • Sold-out performances still need context instead of becoming dead ends.
  • The external ticket handoff should happen only after the date and state are clear.
Viirus calendar showing performance interaction states
Calendar interaction capture: the design distinguishes performance states instead of treating every date as the same object.

Decision 02 / Control

Turn accessibility requirements into controls and feedback people can actually use.

Accessibility was treated as behavior, not a compliance paragraph. Text size, spacing, contrast, motion, focus styling, target size, readable links, status messages, and keyboard-safe overlays all change the way the interface responds to a person.

Design rule: accessibility settings should alter the interface immediately and predictably.

  • Search needs loading, empty, and result feedback that is perceivable beyond the screen.
  • Overlays need a complete keyboard path, including a reliable way out.
  • Reduced motion should change transitions rather than merely hide animation after it starts.
  • Reading preferences belong in the product surface, not in a hidden help page.
Viirus accessibility controls for reading, contrast, motion, and links
Accessibility interaction capture: visitors can change how the interface behaves rather than only read an accessibility statement.

Decision 03 / Latency

Performance is interaction design when every next action waits for the page.

Large cultural imagery was kept, but the critical path was made lighter with modern image delivery, responsive sizing, caching, and less blocking work. The point was not a better benchmark screenshot by itself. Faster rendering shortens the gap between intention and feedback, especially on phones and slower connections.

62 → 99Lighthouse mobile performance
8.8s → 2.0sLargest Contentful Paint
130ms → 40msTotal Blocking Time
F → BWebsite Carbon rating
Viirus performance improvement capture
Performance capture used in the project archive.
PageSpeed evidence before the rebuild
Before
PageSpeed evidence after the rebuild
After

Decision 04 / Trust

Third-party media should not silently become part of the interaction contract.

Expensive external embeds were replaced or held behind consent. A custom social gallery preserved the theatre's visual presence while reducing third-party loading. Privacy, performance, and sustainability became the same interaction question: what should the system do before the visitor has asked for it?

Design rule: defer external work until it is necessary or explicitly permitted.

Viirus privacy-first social gallery
Privacy interaction capture: social content can remain visible without loading the default third-party experience immediately.

Receipts

Evidence trail, not vibes.

This version separates observation, design decision, implementation evidence, and measured result. The finished screenshot is still here, but it is no longer doing all the work.

RECEIPT 01

The live service exposes the real journey

Repertoire, Calendar, Tickets, language switching, search, and the external Fienta ticket handoff are all visible in the public site. The interaction problem is not a hypothetical portfolio exercise; it sits in the everyday service structure.

RECEIPT 02

The project record names the friction

The internal evidence trail records mobile performance audits, accessibility requirements, repertoire and calendar tasks, ticket journeys, privacy constraints, and daily editorial use as the material that shaped the redesign.

RECEIPT 03

The interaction states were captured

The project archive contains dedicated captures for calendar interactions, search, accessibility controls, performance, privacy, and before/after PageSpeed evidence. The case study can show behavior instead of asking the reader to trust a sentence about it.

How we learned

Research

Service + accessibility research

The real product was a time-sensitive theatre visit, not a homepage.

Research combined mobile performance audits, accessibility requirements, repertoire and calendar tasks, ticket journeys, privacy constraints, and the theatre's daily editorial work. Looking at the public and operational sides together exposed the friction that visual redesign alone would miss.

  • Performance audits
  • Accessibility review
  • Task analysis
  • Editorial workflow

Evidence trail

Why the interface is this way.

PERFORMANCE + ACCESSIBILITY

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

Mobile performance audits, accessibility requirements, repertoire and calendar tasks, ticket journeys, privacy constraints, and daily editorial use exposed the main friction.

02

Interpretation

A theatre visitor is usually answering a time-sensitive question on a phone, so loading, programme state, language, accessibility, and tickets carry the most weight.

03

Design decision

Unify search and calendar discovery, make states explicit, keep accessibility controls practical, gate expensive media, and lighten the critical path.

04

Result

The rebuilt experience is faster and more accessible while repertoire, dates, and ticket actions have a clearer hierarchy.

Help improve this website?

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