Redesigning the BAFTA Events Admin Interface with Claude Code

The BAFTA Events Admin interface is the fourth major product redesign I have undertaken in my consultancy work with BAFTA over the past four years, following the Nucleus front end, the Events booking interface and the Nucleus Admin interface. It was probably the easiest of the four to implement, partly because both the development team and I have learnt a lot from the previous projects, but also because this was the first time I had Claude Code available throughout the design and implementation process.

I had already led the redesign of the customer-facing side of BAFTA Events in 2024, creating a responsive and accessible interface that could support white-labelling. The admin interface had not received the same treatment and had continued to grow as BAFTA added new functionality for ticketing, awards ceremonies, invoicing, guest management, accessibility and event communications. It was a strong product that could handle a huge range of workflows, but the interface was dated, inconsistent and increasingly difficult to navigate.

The original decision was to reuse as much of the Nucleus Admin design as possible. Both products had many components in common and after reviewing them I realised that most of the required components already existed. The front-end developer had been very strict about how the Nucleus CSS was built, meaning it was all properly held in a repository and could be reused. This gave the project a much better starting position than on previous projects, where a design company would create a limited number of pages, the front-end developer would convert them into HTML and CSS and the PHP developers would then apply them to the live system. The problems usually appeared during that final stage because the design budget could never cover every page, variation or empty state, leaving me to decide how the supplied components should work across the rest of the product.

Getting started

When I first discussed the project with the front-end developer his suggestion was that I give him some key Events pages, let him apply the Nucleus design and then build out from there. I could see the logic, but I felt it would lead to a lot of back and forth because I would not really know what I wanted until I saw it, particularly where Events needed UI that did not exist in Nucleus.

Instead, I went back to basics and followed the same planning process I had used for the previous redesigns. I created a current site map, mapped the Events pages against the available Nucleus templates and defined the proposed primary and secondary menus. During December 2025, I held scoping sessions with users from different BAFTA teams and regional branches. Their use of the platform varied considerably. Some teams mainly needed an Events list and straightforward booking management, while the awards teams relied on ticket types, invoices, email templates, guest lists, ticket distribution and other more complex functionality. Those conversations quickly confirmed that the Nucleus design language could be reused, but the Nucleus interface could not simply be reproduced.

To help stakeholders understand the proposed menu structure, I asked Claude to create a quick clickable prototype. I have already covered that part of the process in How Claude AI Prototyping Changed My Product Workflow, so I will not repeat it in detail here, but the initial version took around an hour to produce and was enough for stakeholders to move through the menus and understand the approach.

That prototype also showed me one of the risks of making something look too real. Claude had introduced a branch switch into the navigation before I had decided whether one was needed or how it should work and a stakeholder quite reasonably started asking how it would filter the Events list. I had to explain that this was something the AI had created rather than a proposed requirement. Even so, the feedback was far more useful than I would have received from asking people to review the structure in writing. Stakeholders identified missing search functionality, questioned how ticket totals would be displayed and highlighted the need to keep waitlists, alert lists, dates and venue information easy to find. The discussion was about the actual product rather than an attempt to imagine it from a document.

Designing the interface with Claude Code

Once the structure had been agreed, I needed to give the front-end developer something more substantial to build. I returned to Claude Code and gave it the Nucleus CSS, the HTML from the existing Events page and a full-page screenshot, starting with the Events List because it is one of the most important and frequently used pages in the product. Claude went away and built a first version that was not an exact match for Nucleus and needed some work, but it was surprisingly close. It had understood the broad layout, applied the existing design language and even created the page in dark mode.

I then worked back and forth with Claude to build out the page and make sure all the existing functionality was covered. This was particularly useful for UI that did not exist in Nucleus, where I could ask for several possible approaches, choose parts from different versions and keep refining until I had something that worked. I could also populate the page with realistic data, remove all the data to see the empty state and test what happened when tables or content became much larger than the original example. These are all things that can get missed when working from a limited set of static designs, only to become a problem once the design is applied to live pages.

What surprised me, even as someone already using AI heavily, was the speed at which I could explore ideas. I could ask Claude to create five versions of a component, decide that none of them were right and then combine aspects from three of them. I could change the position of information, test different table layouts and ask questions about responsiveness or accessibility while looking at the actual result. I am quite visual and usually need to see something before I can properly decide how it should work, so being able to produce and discard ideas this quickly suited the way I work.

The pages were not only visual references. I asked Claude to wire up menus, filters and controls so I could interact with them rather than looking at a flat page. On the attendance page, for example, I could demonstrate how clicking a status should move someone between unknown, attended and unattended and add the relevant date. Elsewhere, filters expanded, action menus opened and table cells demonstrated how inline editing could work. This meant the developers could see some of the intended behaviour rather than trying to interpret it from a written ticket or screenshot.

Once I was happy with the Events List, I identified the other page types needed to cover the product and spent the next few days building them out around my other work. I eventually produced 17 reference pages, page layouts, a component library and a written design system. At that point, I recommended creating the Events interface around the Claude prototype instead of applying the exact Nucleus design. The development team agreed, while retaining the proven Nucleus components and CSS wherever they made sense.

Claude did not get everything right. It sometimes produced inconsistent HTML between pages, introduced blue hyperlink styling on buttons where I did not want a new button type and missed action menus or important information. Some interactions looked convincing but did not match how the real Events workflows operated, while other elements could be demonstrated in HTML but needed to be implemented properly in PHP before they would work with live data. I fixed some of these problems directly and recorded others for the front-end developer.

This was still much faster than the previous process. If a component did not exist, I could explore it immediately rather than trying to explain it in writing and waiting for someone else to interpret the requirement. If something looked wrong, I could take a screenshot, give it back to Claude and work through alternatives. The quality still depended on me understanding the product, spotting inconsistencies and rejecting things that did not make sense, but I could do all of that while looking at working pages rather than waiting until the design had reached development.

From prototype to production

I provided the front-end developer with the functioning pages alongside the component library and design system. The front-end developer and I agreed that the Claude output would inform the approach, but that its code would not automatically be used in production. Existing Nucleus code was reused where it worked and the front-end developer could decide whether to adapt or rebuild the new UI created for Events. This allowed the project to benefit from the prototype without introducing unnecessary inconsistency into a design system that had already been carefully built and tested.

The initial front-end task was estimated at ten development days but the recorded implementation time was two days and four hours. I would not attribute that entire difference to Claude because the project was reusing mature Nucleus components and the developer knew the design system extremely well, but the quality of the handover clearly helped. Rather than interpreting a handful of static designs and then filling in the gaps, he had working examples, page layouts and a documented component library to follow.

There was also less refinement at this stage than on previous projects. With a design agency, the supplied pages are usually composites showing how the design could work, whereas I had built these pages around the actual Events content and functionality. Most of my feedback was therefore about making the CSS implementation match the references, correcting components that had moved too far back towards Nucleus or fixing mistakes that had originated in Claude. The prototype had already allowed me to work through many of the design questions that would normally have appeared after the front-end build.

The PHP implementation remained the most labour-intensive part of the project. Events is a feature-heavy legacy product and the developers had to apply the design to each live page without breaking the existing workflows. The work was divided across five epics and close to 100 page-level tickets covering site configuration, event settings, communications, event pages and event configuration. This was not simply a case of replacing colours and styles, because each page could contain conditional functionality, messages, menus and controls that only appeared in particular situations.

This is where Claude became particularly useful again. On previous redesigns, if implementation exposed a missing feature or a page that did not fit the available templates, I had to decide what it should look like, explain it to the front-end developer, wait for a new example and then send it back to the PHP developer. This time I could take a screenshot, explore the problem with Claude and produce an updated reference before asking the front-end developer to add it to the production design system. It created a much quicker refinement pipeline and made it possible to produce more appropriate layouts for pages that would previously have been forced into a generic template.

The process still followed the same stages as the other redesigns: scoping, design, review, CSS build, implementation, testing and release. Claude did not remove any of those stages, but it brought them much closer together and made changes much quicker to explore. I could identify a problem during implementation, visualise a solution and give the developers something concrete without needing to commission another round of design work.

The result

The redesigned Events Admin interface launched in July 2026 and the initial feedback has been positive. I am collecting feedback through support tickets, with a broader stakeholder review planned once the interface has been in use for longer.

I probably spent more of my own time directly designing and refining pages than I would have if an agency had provided the initial designs. However, I already spend a considerable amount of time briefing designers, reviewing their work and making the decisions required when static designs meet a live, feature-heavy product. This time that effort produced working pages, realistic states and much clearer implementation references while removing the cost and delay of repeated external design rounds.

Claude Code shortened the gap between identifying a problem, testing possible approaches and producing something the development team could use. The product knowledge, design decisions and testing remained with me, while the production implementation remained with the development team. For a legacy system with years of accumulated functionality, bringing those activities closer together made the project quicker to deliver and much easier to refine.