I built Hornbill's entire design function from zero

Hornbill is an established business with a strong backend, but it had never had a designer. Five products had grown over the years through engineering alone, each one shaped by whoever happened to build it. There was no design system, no shared patterns, and no consistency between any of them.

I came in as the first ever designer, a team of one sitting next to dozens of developers. My job wasn't one screen or one product. It was to build a design function from scratch: the process and tools that would keep the work consistent long after each project shipped.

Before changing anything, I spent time mapping things out. I went through all five products and wrote down every inconsistency: different components doing the same job, patterns that clashed, and flows that no one person fully understood.

I sat with developers, account managers and support to find out where users were struggling, and I worked through the products as a user would. The backend was strong and the business ran on it. The front-end was a different story.

The backend carried the business, but the front-end was quietly pushing clients away.

The instinct across the business was to redesign everything, all five products, all at once. With one designer, that was the fastest route to changing nothing that mattered. I pushed back and argued for the opposite: sequence the work so each step earns the next, fix the highest-value problems first, and stand up a system so future work compounds instead of repeating old mistakes.

I had to defend that prioritisation to stakeholders who wanted visible change everywhere immediately. My case was simple: a team of one only scales through leverage, and leverage comes from a system and a process, not from touching every screen. That decision became four pillars, deliberately ordered so each one makes the next easier.

The first job was to stop the bleeding. I went through the products and found the usability problems that were frustrating users and quietly losing clients.

I sorted them by how much they mattered and how hard they were to fix, then started with the high-impact, low-effort ones. Users felt the difference quickly, and the business saw early proof that design was worth investing in.

Once the worst friction was gone, I started rebuilding the interface on a proper foundation. Instead of reskinning screens one by one, I built a blueprint: a single design system of shared components, patterns and rules that all five products could use.

This is what makes a one-designer team work at scale. Developers get reusable building blocks, the products start to feel like one family, and every new screen starts from good decisions by default.

A design system is only as good as the process behind it. Hornbill had never had a way to make product decisions with users in the room, so I set one up: a simple, repeatable process with research at the start, not bolted on at the end.

I paired it with a short set of design principles, the rules we hold each other to, so that decisions get made against a shared standard instead of whoever is loudest in the room. That gives developers, account managers and leadership one language for talking about design, and it means the quality bar doesn't live only in my head.

The point of all of this is leverage. Principles and process are how a team of one scales: they let other people make good design calls without me in every meeting.

With the foundations forming, I started bringing AI into how the design work happens, using it to speed up research, explore ideas faster, and help one designer do more across five products.

It isn't about novelty. It's about letting a small team move at the pace the business needs while keeping the quality high.

A year in, the design function exists where there was none: a system adopted across products, research running as routine, and a process the team uses without me driving every step. The business now treats design as a way to keep clients and grow, not a coat of paint.

To prove the process held up under real conditions, I chose one of the main products, Knowledge, and led a full rebuild on it. We ran it the way the process says to: system-first, and starting with the people. I pushed the team to talk to users and stakeholders before touching a screen, something that, to everyone's surprise, had never been done on this product from a UX point of view. That alone reshaped how we thought it should work.

I also wired our design system into AI tooling so the team could spin up fast prototypes and use it for analysis and ideation. It doesn't always behave, and some prototypes fall over, but even the rough version changed how quickly we could move from idea to something testable.

The rebuild is the clearest proof point I have that this is a function, not a person: the system, the research habit and the principles held up without me holding each one in place. For the first time the team could feel what design-led actually means rather than just hear me say it.

This is a long game. The two-year plan takes the four pillars from a foundation to something mature: a design system used across all five products, a research-led process the team does without thinking, AI built into the workflow, and, most importantly, products that are clearly easier and better for users.

A year in, a lot of that is already moving. The system is being adopted across products, research is becoming routine, the process is up and running, and AI is starting to sit inside the workflow rather than off to the side. Year two is about turning all of that into the thing that actually matters: better products for users.