Building Design from the Ground Up at Hornbill

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.

With one designer and five products, the risk was spreading myself too thin and changing nothing that mattered. So instead of redesigning everything at once, I built a plan around what would have the biggest effect: fix the things holding back the most value, and put a system in place so future work built on itself instead of repeating old mistakes.

That plan became four pillars, ordered so each one made 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.

That meant putting habits in place, like discovery, testing and iteration, that keep the team building the right things and give the wider business a shared way of talking about design decisions.

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.

The early UX fixes are landing, the design system is taking shape across the products, and a real process is starting to run. For the first time, Hornbill has a design function, not just a designer.

Just as important, the business has started to see design as a way to keep clients and grow, rather than just a coat of paint.

To put the whole process to the test, we picked one of the main products, Knowledge, and rebuilt it from scratch. We used the design system, and we started where the process says to start: with the people. We talked to users and stakeholders, which, to everyone's surprise, had never been done from a UX point of view before. That alone was a shock to the team, and it reshaped how we thought the product should work.

We also started bringing AI into the work itself: using it for analysis, for ideation, and wiring our design system into it so we could spin up fast prototypes. It doesn't always behave, and some of those prototypes fall over, but it's getting there, and even the rough version is changing how quickly we can move.

We came out of the Knowledge rebuild genuinely optimistic. The process held up under real conditions, and for the first time the team could feel what design-led actually means rather than just hear about 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.