Overview

When I joined Harvest Digital Planning, the timing was, let’s say, characteristically design industry. The previous designer resigned almost the week I arrived. Handover consisted mostly of a front-end developer’s perspective on how things were built, a live product to reverse-engineer, and very little in the way of actual design assets or documentation.

What I inherited was a functioning community engagement platform used by governments and councils to give communities a genuine say in decisions that affected them. Good mission. Real users. A product that worked. Just no design foundations to speak of, and a growing list of clients who expected it to keep evolving. So that’s where we started.

The Challenge

Built on Concrete5 and Bootstrap 3, the platform had grown organically, which is a polite way of saying that design decisions had been made by whoever was closest to the keyboard at the time. Patterns diverged, visual language drifted, and there was no shared system or source of truth to govern how things should look and behave as the product grew. The kind of quiet inconsistency that doesn’t break anything today but absolutely comes for you later.

The commercial complexity made this more than a cleanup job. The platform needed to support deep visual customisation across hundreds of government and council clients, each with their own branding requirements, accessibility obligations, and the expectation that the product would look like it was built specifically for them. That’s not a small ask from a design system that didn’t yet exist.

Approach

With minimal design assets to inherit, I started from the live product itself, working in Sketch to audit what existed, map the inconsistencies, and understand the shape of the problem before trying to solve it.

What made this work unusual, and, I’d argue, what made it successful, is that I wasn’t just designing the system, I was building it. Working across PHP templates, HTML/CSS with LESS, and later Vue for more interactive tools, I was largely functioning as the front-end developer at this stage, which meant every design decision was made with a direct understanding of its technical implications. There was no handoff gap, no translation layer between design intent and implementation. What I designed, I built.

From the audit I developed a theme framework on top of the Bootstrap 3 foundation that could bring the design language into alignment without requiring a ground-up rebuild of a live product with real clients depending on it. The work addressed both surface and structural levels simultaneously, typography, colour, and spacing consolidated into a coherent visual language, while the component architecture was rebuilt to support consistency and reuse as the product continued to grow.

Accessibility definitely couldn’t be an afterthought. For a platform whose entire purpose was to include communities in decision-making, WCAG compliance was the minimum, not a box to tick but a baseline commitment to the people actually using these tools.

As the product matured I moved to Figma, and that’s where the design system really found its form. Components became a living library, design and engineering started speaking the same language, and the theme framework evolved to meet an increasingly complex and customisable product without fragmenting under the weight of it.

Outcomes

The design system gave the product a foundation it could actually grow on. New features could be added consistently and efficiently, client customisation became a commercial strength rather than a source of fragmentation, and the theme framework could accommodate hundreds of distinct brand deployments while holding design integrity across all of them.

The design and technical maturity built during this period contributed directly to The HiVE’s acquisition by MySite, where it was integrated with Social Pinpoint to form what became the leading suite of community and stakeholder engagement tools in the market.

Reflection

Building the system myself, in code, not just in Figma, taught me something I’ve carried into every role since. Staying close to how things are made isn’t just about technical credibility, it’s about the quality of the relationships you can build with the people making them. When you can move beyond the transactional design-to-dev handoff and into a genuine conversation about constraints, tradeoffs, and possibilities, something shifts. You stop being the person who hands work over and start being a real collaborator. That common language, built on trust, shared craft, and a genuine investment in getting it right, is one of the most valuable things a design leader can cultivate.