Curate is a new web application replacing the digital infrastructure behind the Royal Academy's Summer Exhibition. I work on it as the UX and UI designer alongside the RA's own product and developer teams.
Context
An open call and everything it sets off
The Summer Exhibition is open submission. Anyone can enter work, which is what makes the system behind it large rather than simple.
Every entry has to be taken in, paid for, given an identity that survives being moved around a building, judged, catalogued, photographed, hung, sold and reported on. The exhibition is the visible part. Curate is the machinery underneath it.
Scope
Retained design, inside someone else's system
The engagement is retained UX and UI design for the Summer Exhibition infrastructure and the Curate application, working with the RA's in-house agile product and developer teams. Design artefacts are produced and maintained in RA-owned Figma spaces, structured for developer consumption and representing agreed screen states and interactions.
Three constraints shape the work more than any brief would.
The standard Blazor component library, wherever possible
The application is built on an existing component library, so design starts from what already exists rather than from a blank frame. That changes what can be proposed, not just how it is drawn.
The RA's design framework and the Curate UX Principles
New work applies the Curate UX Principles throughout. Where it has to deviate from wider RA patterns, the deviation is agreed and then handled consistently rather than decided again each time it comes up.
Someone else's Figma
Everything is delivered into RA-owned spaces with a logical page structure, naming and grouping. The file is a working tool for their developers, not a portfolio artefact, so it is organised for the person opening it next.
Surface area
Twelve domains, five jobs
The delivery focus covers twelve areas. Listed flat they read as a backlog, so it is more useful to group them by the job they do.
Getting set up
Creating and managing admins, assigning their roles, logging in and out, then creating, viewing and editing the exhibition itself.
Who is in the show
Creating, viewing and editing artist accounts, plus creating memberships and assigning them to artists.
Getting work in
Creating, reviewing, editing, paying for and submitting artwork to an exhibition, then viewing and searching everything that has been submitted.
Deciding and handling
Barcodes created, assigned and updated through the statuses a physical work moves through, labels viewed and updated, judging lists built and reviewed, catalogue contents managed and images moved in bulk.
Money and obligations
Payments, reserved artworks, waiting lists, purchases, anti-money laundering checks, HMRC status and submissions, plus the reports that have to be searched, viewed and downloaded.
The public site sits alongside all of this, reduced in scope from a full CMS to hardcoded designs covering the homepage, the contact form and the FAQs. Cutting that scope was the right call. A bespoke CMS is a product in itself, while the exhibition machinery is where the difficulty actually lives.
Where the difficulty is
A work is a physical object and a record
The tracking and judging areas are the ones that pull hardest against a standard component library. Most of Curate is recognisable admin work: create a thing, find a thing, edit a thing. Barcodes and labels are not that. They describe a physical object moving through a building, being handled by people who are not sitting at a desk. The interface has to keep the record and the object in step.
Working
How the engagement runs
The SOW is unusually specific about process. That specificity is doing real work on a project this size.
Onboarding before estimating
An onboarding period comes first and the detailed timeline is produced after it. Estimating twelve domains before understanding them would produce a number rather than a plan.
One source of truth
Work is taken from agreed source materials, the workshop requirements and Jira. Where something is ambiguous or missing, the query gets raised rather than worked around, because a designer quietly inventing an answer is how a system drifts from what was agreed.
Visible state of play
The work is progressed so that the RA can see at any point what is complete, what is in progress and what is still outstanding.
A regular risk conversation
Meetings on a bi-weekly and monthly rhythm covering risks, issues, impact and progress against deliverables and milestones.
Handover as a deliverable
A documented handover to the RA's internal resource is written into the engagement rather than left until the end, so the work outlives my involvement in it.
The engagement is live and the work is ongoing, so there is nothing to report on results yet. What exists today is the design of the system described above, produced in the RA's own Figma and structured for the team building it.
I will add an outcome here when there is one worth stating.
