Live — 2026
Bad Brain
From wireframe prototype to full rebrand and launch

- Role
- UX design, prototyping, front-end engineering and interaction design
- Built with
- Next.js 15, React 19, TypeScript, CSS-native animations
The fully interactive wireframe
We'd built v1 of the site some time ago so now was the time to take it up a notch. The full rebrand was in progress and we wanted to move fast, so I created a fully interactive prototype. It was a moving wireframe - no colours or typography but full of interest, animation, visual hierarchy.
Sometimes it can be hard to get a sense of how a site feels when it's just a static wireframe so why not throw 'static' away completely?
From guidelines to interface
The Bad Brain v2 identity arrived with a proper brand system already done — two typefaces, five colours, image frames, halftones, a folder of motion references. What a document like that gives you is the brand standing still. It has nothing to say about hover, or what happens halfway down a scroll, or how any of it holds together on a phone with limited time to make an impact before the next Instagram notification.
Filling in those gaps was the job. Keep what the document pins down, make the call on everything it doesn't and don't sand off the edge that made it recognisable in the first place.
Four services, one business
Blueprint, Connect, Studio and Resonate sell to different people — brands and networks, creators, artists and labels. Someone who lands looking to buy one of them shouldn't have to care about the other three, and it still has to read as one company rather than four.
Each service is clearly Bad Brain but has its own distinct identity, with its own unique visual devices that represent the value proposition of each one.
Scroll animations... CSS-natively
Almost everything on the site arrives on scroll: service cards sliding in from off-screen and video reels appearing. The reflex is to reach for an animation library, which means measuring elements in JavaScript on every frame of every scroll. On pages already playing half a dozen video reels at once, that is exactly what makes a phone stutter. So the motion is written as ordinary CSS keyframes tied straight to scroll position with animation-timeline, and the browser runs it. No animation library, nothing added to the bundle.
Chrome, Edge and Safari all handle that themselves now. Firefox is the last one that does not, so there it needs a hand. Every animated element carries a small marker that Firefox keeps even though it ignores the scrolling part, so a short script can find all 39 of them across the site without me maintaining a separate list. It then holds each animation at whatever point the scroll has reached. Nothing gets rewritten along the way: the animation stays exactly as written in the CSS, and the script only decides how far through it should be.