When brand guidelines
weren't enough

Maguro Group had not previously had a careers site. The Head of People was introducing Talent Tunnel as the company's first dedicated recruitment platform, and part of the project had already begun before I joined.

I had joined as maternity cover for the Design Manager, a role that would normally suggest maintaining an existing design function. In this case, there was no established careers-site experience to maintain. The new platform still had to be made to feel like a natural extension of the existing company website.

That also meant the visual direction was not a blank canvas. The colours and overall identity already existed on the main site, so the work was not about introducing my own aesthetic. It was about deciding how that existing language should behave in a new platform.

Initially, I assumed the existing brand assets would be enough. The developer had access to the same logos, colours and supporting materials that I did. From a technical perspective, nothing was missing.

However, the first implementation revealed something unexpected. The design followed the guidelines, yet it didn't feel like the existing Maguro website.

That was the moment I realised brand guidelines do not remove interpretation. They simply provide a common reference, leaving countless visual decisions to the people applying them.

The inconsistency wasn't caused by missing assets. It came from different people visualising the same guidelines in different ways.

Rather than explaining individual adjustments through emails, I stopped describing the design and started showing it.

I recreated the homepage directly in Figma using the visual language already established across the company's existing website. The palette and identity were fixed, but spacing, hierarchy, background use, content structure and component relationships still had to be interpreted for the new platform.

Instead of communicating these decisions through hexadecimal values or written instructions, the prototype became the shared visual reference. The design files were packaged and sent directly to the developer, allowing implementation to continue with almost no further discussion.

The prototype wasn't simply a design file. It became a common language.

The project itself was relatively small, but it captured a recurring condition in the role. Even as maternity cover, some work could not simply be maintained because the thing being maintained did not yet exist.

The prototype was not an attempt to redesign the brand. It was the shortest way to make the first implementation usable and consistent, while keeping the developer aligned with an identity that already existed.

That experience also changed how I approached later handovers. Whenever possible, I used visual references to make the intended result visible before interpretation created unnecessary back-and-forth.