TicketCo 2.0
TicketCo’s Web 1.0 to 2.0 redesign, through Cefalo. I worked on the product design for organizer and buyer flows, and managed the Figma library that design and engineering worked from.
The platform already carried years of operational depth: event setup, ticket types, memberships, season tickets, gift cards, cashless and reporting. The job was to make that depth easier to work with on any screen, without taking it away from the organizers who rely on it.
01Context
TicketCo is an event and ticketing platform used by organizers across Norway, Sweden and the UK. Web 1.0 worked, but it had grown one screen at a time.
Organizers use it to set up events, sell tickets, run memberships and season tickets, sell gift cards and click cards, handle cashless payments and read sales reports. Buyers meet the same platform through club and venue pages, seat maps and checkout.
The issues we started from were familiar ones for a long-lived SaaS product: a dated interface, dashboards that needed a lot of manual work, screens that didn’t hold up on mobile, rigid operational flows and inconsistencies between areas built at different times. Each part of the product solved its own problem, so the same action could look and behave differently from one module to the next.
The constraint that shaped everything: experienced organizers depend on that depth. A cleaner 2.0 that hid or removed operations they use every week would not have been an improvement.
02My part & the team
This was team work across three countries. The split below is how the responsibilities actually divided.
Engineering ownership, release decisions and production metrics belong to the wider team. This case describes my design contribution.
Direction, priorities, business rules, acceptance
Shared reviews of design, product and implementation questions
React implementation, engineering and performance decisions
Flows, components, states and the handoff reference everyone reviewed against
Most of this happened remotely: design critique, stakeholder reviews and Jira. Because the reviewers were spread across time zones, the Figma library and its page status had to explain a decision without me in the room.
03Discovery & discussions
Before redrawing screens, the team needed a shared picture of what Web 1.0 actually did.
Discovery meant walking through the existing workflows: how an organizer creates an event, configures ticket types and seating, follows sales and pulls a report. We collected the patterns that repeated with small differences across modules. Those inconsistencies became the shortlist for the library, and the older screens eventually went into a clearly marked “Not in use” area of the Figma file so nobody would build from them by accident.
The discussions with Norway and the developers kept coming back to a few questions. These are the working questions, not a meeting transcript or research findings:
Modernizing the layout must not bury operations people use every week.
Shared tokens and components, with navigation and input that follow each platform.
Long setup tasks need a safe draft state and specific, field-level errors.
States, responsive behavior and acceptance notes, not just a static screen.
04Flows
Two flows carried most of the redesign: an organizer creating an event, and a buyer choosing seats.
Reconstructed for this case study from the shipped interface. These are explanatory diagrams, not original project flow exports.
05Wireframe studies
Low-fidelity studies made the layout logic easy to debate before any visual detail.
Wireframe studies redrawn for this case from the delivered screens. They explain the structure; they are not original wireframe files.
06The Figma system
The core library is organized the way the product is built: from foundations up to the two page families engineers ship.
Library structure and component names verified from a read-only view of the Figma file. “Ready for dev” is a Figma page status, not a release claim. Exact token values and variant counts aren’t shown here. Open the library ↗
Public Sans is the family in the library’s Typography foundation. It has separate desktop and mobile heading styles, subtitle and body styles, and underline and line-through treatments for links and changed prices.
Aa
Add information about your event
Report summary
Section: Field-122 · Adult NOK 1,299 · Child NOK 1,00
Set in Public Sans. Sample lines come from the shipped interface; the sizes here are illustrative, not the library’s token values.
07Components & states
Most of the design-system work is in the states. A component isn’t ready for handoff until its edge cases are drawn.
| Component | States | ||||
|---|---|---|---|---|---|
| Button | Default | Hover | Focus | Disabled | Loading |
| Text field | Event titleEmpty | Spring concertFilled | Spring concertFocus | Event titleDisabled | Spring concertEvent title is requiredError |
| Quantity stepper | −0+Zero | −2+Value | −2+Focus | −0+Sold out | −8+Limit reached |
| Section status | AvailableAvailable | RecommendedRecommended | Few leftFew left | UnavailableUnavailable | ChangedChanged |
Illustrative specimen of the state coverage the library documents. Drawn for this page; not the production components.
08Prototype behavior
Prototypes were used to agree on behavior, not just appearance.
Completed steps show a check mark; the organizer can go back to any earlier step without losing input.
Save now stays in the step rail, so leaving halfway is a normal outcome, not an error.
Toggles such as “Make this event private” and “Move to top of the event list” sit next to the fields they affect.
Preview and Go to checkout are separate actions, and the recommended badge is text, so it doesn’t rely on color.
09Design decisions
A few calls shaped the rest of the system. Each is written as rationale and trade-off, not as a measured result.
Event setup has a lot of required information. Splitting it into Event information, Obligatory fields, Event place and Confirmation, with Save now on every step, lets organizers work in sessions. The trade-off is more navigation, which the step rail makes visible.
Tips for writing event titles and descriptions live beside the form. The form stays scannable for experienced organizers, while newer ones still get help where they are working.
Components were specified against the Tailwind-based guidelines and React component system the developers use, so spacing, states and variants translate directly instead of being re-interpreted per screen.
Admin Sales and Ticket Buyer serve different people, so they get separate templates and pages. They share atoms and molecules, which keeps the platform recognizably one product.
Reports summarize first and load table rows on request. Operational screens reuse existing components and avoid one-off assets. These are design considerations for the build; no speed improvement is claimed.
10Accessibility
WCAG 2.2 AA is the target for these patterns, with APCA as a supplementary readability check and EN 301 549 for European public-sector expectations.
These are the criteria the components are designed against. This page doesn’t claim a certified audit or formal conformance.
11Handoff & maintenance
The handoff had to work for engineers in another time zone, and later for AI coding tools working from the same references.
When a pattern changes, for example a validation rule, it changes once in the library and is then checked across the dashboard, the native experience and any AI-assisted implementation. Retired patterns move to Not in use instead of being deleted.
12Outcomes & scope
No usage, speed or revenue figures are shown, because I don’t have measured results to report. Agentic reservations, seat-map building and AI-assisted allocation were separate working prototypes and aren’t part of this scope.
The most useful thing a design system did here wasn’t visual consistency. It gave people in Norway, Ukraine and Dhaka one place to settle a question, and kept that answer true as the product kept changing.