BAE Systems
A global corporate site serving millions of visitors across 40+ countries — rebuilt from discovery and wireframes through to production, on a design system the editorial teams now build pages from themselves.
HOMEPAGE — FULL-BLEED BANNER, OVERLAID HEADLINE, SINGLE RED CTA
One site, six audiences, and no shared language between them.
The site has to serve governments evaluating defence capability, investors reading financial results, and graduates looking for a first job — simultaneously, in every market the business operates in. Years of regional and campaign pages had left each of those journeys with its own components, its own type sizes and its own idea of what a primary button looked like.
An audit before a single new screen.
I inventoried what was live, grouped it by job rather than by page, and worked with stakeholders from each business area to agree which journeys the homepage actually owes an entry point to. Sitemap and low-fidelity wireframes came out of that — signed off before any visual design started.
Audit what exists
Full inventory of live components and templates, grouped by the job they do rather than the page they sit on. Duplicates made the case for a system on their own.
Align the stakeholders
Sessions with each business area — defence, investor relations, careers, communications — to agree which journeys the homepage owes an entry point to.
Sitemap and wireframes
Low-fidelity structure signed off before any visual design, so the argument about hierarchy happened in grey boxes rather than in finished UI.
Foundations, then pages
Logo, colour, type, grid, icons and interaction states specified first; templates assembled from those foundations rather than drawn independently.
Foundations first: logo, colour, type, grid, icons, states.
Every sheet below is a real deliverable from the project. They exist because "make it match the brand" is not an instruction a distributed editorial team can follow — a specified token is.
Twelve columns down to four, without redrawing anything.
Desktop runs a 1280px grid on a 1400px canvas: 12 columns, 28px gutters, 80px margins. Mobile holds the same proportional logic at 4 columns, 17px gutters, 20px margins — so a card that spans 3 desktop columns has one obvious mobile equivalent and the CMS mapping is mechanical rather than a judgement call.
The banner carousel was the hardest component to bring down: a full-bleed image, a headline, a CTA and a link list all have to survive a 375px viewport with text still legible over photography.
Where the constraint was the reason.
Red reserved for action and brand only
A documented scale, not a Figma text style list
Full-bleed imagery, text on solid ground
Built for CMS authors, not for designers
One refactor for speed and accessibility
AA compliance and a 35% faster site were the same piece of work.
A defence prime is held to a genuinely high bar on both. Accessibility was specified into the components — contrast, focus order, hit areas, semantics — rather than audited at the end, and the same refactor that removed duplicated markup is what moved the Core Web Vitals.
The system, in production.
The client's own write-up on launch.
BAE Systems' Digital Marketing Manager posted publicly about the launch: two years of work, thousands of pages audited, systems re-engineered and UX optimised — with Infomentum, the team I delivered the design system and front-end through, credited by name.
Worth including because it corroborates the scale from the client side rather than mine: a 1.1M-follower brand describing the result as a reflection of the business, not just a refresh.
Outcome
A component library and site-wide design system live on baesystems.com, WCAG 2.1 AA across the board, and a 35% reduction in load times. Editorial teams in multiple regions now assemble pages from the system without a designer in the loop.
My role
Led UI design and front-end delivery end to end — discovery, wireframes, the design system, and the production build in Magnolia CMS with Tailwind and JavaScript. Also ran design QA and front-end code review for the wider team.
What I'd do differently
The system documentation came together alongside the build. Writing the usage rules first — especially for the banner and card components — would have prevented a handful of off-pattern pages I later had to unpick.