Global AgTech Company

Regulatory teams were spending time managing templates rather than studies

Global AgTech Company is one of the world's leading agricultural technology businesses, developing crop protection solutions, seed technologies, and digital platforms that support agricultural production worldwide.

We partnered with the client to design a self-service Template Management System built around a standardised vocabulary and an Excel-like sheet builder that lets Data Managers create and configure templates without relying on IT.

The work presented represents the discovery and proof-of-concept phase delivered for the client and demonstrates our product design approach to solving complex operational challenges.

What we did:

Discovery · Product Design · Prototyping · Proof of Concept

What we achieved:

A validated path to self-service template management and a scalable data taxonomy spanning every study type.

The Reality

Every team had built its own version of the same system, and none of them matched.

The client came to us with extensive documentation, complex requirements, and a tight timeline. Underneath the paperwork was an operational problem that had been building for years.

Picture a global agrochemical company running safety and regulatory studies at once, each one generating its own Excel templates, and each one built by hand. Each team had developed its own approach to templates, naming conventions, and data structures.

Every team had its own version of the same problem:

• A vocabulary left open to interpretation, so the same term could mean something different depending on who entered the data
• Templates rebuilt from scratch for every study
• Every small change routed through IT

The Shift

Before Data Managers could configure anything themselves, the data itself needed a name everyone agreed on.

The priority was creating a shared vocabulary that every team could build from.

The real constraint wasn’t Excel, and it wasn’t IT capacity either. It was that the data itself had no consistent name across study types, so no interface, however well-designed, could let Data Managers self-serve without first addressing that underlying structure. Standardising the taxonomy had to come before configuration, and configuration had to come before automation. That ordering became our design principle, not an afterthought.

Every scalable system begins with a shared structure.

The Build

A shared vocabulary and a familiar interface, working together, made self- service possible.

Working through Miro and Figma, we moved from mapping the existing template landscape, to testing structured naming conventions against real study types, to a proof of concept that let Data Managers configure and generate their own templates directly.

The proof of concept brought together two connected parts:

• a standardised vocabulary, including synonyms for each term to keep usage consistent across teams,
• and an Excel-like sheet builder that allows Data Managers to assemble templates using an interface familiar from their existing workflows.

Frequently repeated sections of a sheet live in a shared library, so Data Managers assemble templates from pre-approved building blocks rather than starting from a blank page, another layer of standardisation that reduces the chance of error.

The system also organises information by relevance, so Data Managers can reuse data from previous studies rather than re-entering it each time, reducing duplication and manual error across studies.

Access is role-based. Alongside Data Managers, Subject Matter Experts collaborate during template creation and later use the completed sheets to review study results. To support that collaboration, we added inline commenting, similar to Google Sheets, so reviewers can flag a specific cell and leave feedback without leaving the document.

Under the hood, this meant designing a data-naming standard that could hold across all current and future study types, not just those in scope for launch. That structure was invisible to the end user, but critical for technical validation and long-term scalability, and it had to work in lockstep with the engine built on top of it.

We also designed with the next phase already in view. The naming standard we built isn’t just cleanup; it’s the foundation that automated validation will eventually run on, which means every decision has to hold up under scrutiny from people who understand regulatory data far better than any of us do.

Related work

The Shipowners’ Club’s P&I Online service Turning an operational portal into an app that brokers actually use.

HMS Networks Designing inside real constraints, not around them.

Impact

A working proof of concept turned a complex operational challenge into a validated product direction the organisation could evaluate.

The proof of concept demonstrated how Data Managers could create, configure, and generate templates on their own, without waiting on IT for every adjustment. It gave the organisation a clear, tested path toward removing one of the slowest, most repeated bottlenecks in the data collection process.

What the proof of concept delivered:

• A tested path to self-service template configuration
• A naming standard that scales across current and future study types
• A foundation for future automated data validation
• A role-based workflow that lets Data Managers and Subject Matter Experts collaborate directly inside the tool
• Something concrete stakeholders could evaluate before committing to implementation

The Reality Check

The hardest part of the project was invisible.

We were briefed to design a template management tool. During discovery, we realised the real challenge was creating the structure that would allow that tool to work across different study types and teams. Standardising how data was named had to come before any interface could work at scale.

Template management shouldn’t depend on a queue.