Maestro is a ticketing and patron-CRM platform for performing-arts organisations, sitting on top of Tessitura. This prototype covers the member-facing mobile app — the surface a subscriber uses between buying a ticket and walking into the hall.

It answers one question ahead of build: what does a member do here, and in what order.

Prototype — eight screens: splash, home, events, event detail, choose access, member pass, benefits, account. Four bottom-nav destinations.

Navigation map — the target IA, every node marked built or not. Exports as Markdown.

Identity system — type, colour, photography, spacing, shape, icons, components, voice.

The IA runs well ahead of the build. Against the five-section spec, 17 nodes exist and 30 do not, counting the three shared screens.

Events is thinnest — no calendar, purchase, seat detail or exchange. Profile is the larger gap, and almost all of it is history and statistics. That is not a design problem: attendance history, contribution history and season journey are data surfaces, and they need a source before they need a screen.

Settings sits under Profile, not in the tab bar. Four destinations, not five.

Profile is the patron record — stats, journey, attendance, contribution, household. Account controls moved out.

Past events belong to Profile as statistics, not to Events.

Three of the five Settings controls already exist. They were in the wrong destination, so that work is a move, not a build.

Six flat colours, squared corners, two typefaces. Burgundy #390C0C marks the primary action. Lemon #E1EFA3 is the only accent and is legal on burgundy or off-black — on white it measures 1.23:1.

Radii are zero by direction. The Figma source carries 0, 2, 4 and 8 with no rule; the build resolves that to square.

Photography is the one place colour beyond the six enters the system, which is why six values are enough everywhere else.