Agricorp Design System

When Agricorp’s CEO called for organization-wide design standards, I saw an opportunity to create something more useful than a static document. I recommended a design system: a living foundation connecting principles and standards to reusable patterns, implementation guidance, and future products.

My manager and I had anticipated this need and had been preparing for the work for approximately 18 months. Once the initiative formally began, I served as product owner and UX lead. A technical writer helped develop the documentation, while my manager and a project manager reviewed content, guided internal positioning, and kept the work moving through planning and delivery.

From repeated decisions to a shared system

Before the formal request, I had been collecting patterns and interface elements that appeared repeatedly across our products. Maintained alongside my regular work, this informal library preserved useful decisions but lacked the documentation and governance required for broader adoption.

We began by identifying the components our products needed. For each one, we set out to document when and how it should be used, how it should behave, and how it should appear. This would give designers, developers, writers, and testers a shared reference for making and evaluating product decisions consistently.

From reusable components to a maintainable system

Yield Report became the first product to use components from the emerging design system. I built and tested the components while our technical writer helped document how they should be used.

For the initial prototype, we copied components into the project individually. This validated the patterns in a real product, but it also exposed a maintainability problem: the copies became disconnected from their source and increasingly difficult to update.

Before extending the system more broadly, I created a repeatable workflow for packaging the shared assets and pulling them into individual projects. OCS and later product work could use a consistent foundation without relying on manual copying.

Distribution solved only part of the maintenance problem. Developers also needed to identify changes that might affect their products. We standardized how affected components were identified in each commit, turning the commit history into structured, searchable documentation. I then used that convention to create a searchable changelog alongside indexes organized by component status, type, and name.

Together, these changes made the system easier to adopt, maintain, and evolve across products.

Making the documentation live up to the system

The initial release was produced within a compressed timeframe. Although we established the components and guidance needed to support more consistent products, the documentation itself did not yet provide the coherent experience we wanted the design system to represent.

I treated that inconsistency as a product problem rather than a cosmetic cleanup. I developed a set of contracts defining the expected structure, tone, content, and code examples for each pattern. These contracts created a repeatable workflow for regenerating the documentation and made its quality less dependent on individual interpretation.

The documentation is built with DS2-core, a coded design-system framework I designed and developed.

We are now rebuilding the content through that model, creating a more consistent experience for both the people using the guidance and those responsible for maintaining it.

Extending the system across products and practices

The design system now provides the foundation for new product development within our team’s control. Its patterns have been applied to Yield Report and OCS, have influenced parts of the intranet, and are expected to guide the updated Acreage Report and Agricorp’s future public website.

Not every product consumes the same component code. Some development teams work in Blazor and rebuild components within that framework. In those cases, the design system provides a common specification for appearance, behaviour, content, and accessibility. During the development of Yield Report, the team used Copilot to help translate several documented components into Blazor implementations.

The system also supports work beyond development. Testers use the enhanced documentation as a source of truth when evaluating implementation and accessibility. The Communications team increasingly treats it as complementary to Agricorp’s brand standards, and we have worked together to strengthen alignment between brand expression and product experience.

Adoption is still developing, but we are beginning to see a more consistent look and feel across platforms. That convergence will become more visible as additional products are modernized, particularly with the planned replacement of Agricorp’s main website.