Turned monolithic compliance into a modular interface that absorbs each new market without re-architecture
- Engineering performance
- API calls saved on idle checks
- Design system scalability
- Components designed in Checks and adopted across the platform
- Information communication
- Tooltips consolidated into a single glossary page
100%
+2
24
- Role
- UX/UI Designer · led the design work, sole designer
- Timeline
- Q2 2025 · Q3 2025
- Team
- 1 PM · 3 engineers (1 BE / 1 Flutter / 1 FE)
- Environments involved
- Web farmer platform (Angular) · Mobile farmer app (Flutter)
- Status
- W1 Shipped · W2 (Q3 2026)See live
Context
A module built for one farmer, asked to serve a thousand fields.
Checks is where an agronomist proves a field is compliant — the right treatment, on the right parcel, recorded at the right time. The first version was shaped around a single cooperative, so every assumption was baked into the layout.
The second client needed a fork; the third needed another. We were maintaining variations, not a product — and the next market was always one bespoke build away.
Challenge
Make the next client easier than this one.
The template was built for UK rules on the field-module side. That would have meant maintaining a tree per market, and bending the next regulation into a shape it didn't fit. The real question wasn't visual — it was structural: what does one interface need so the next client is configuration, not construction?
The question
How do we make Checks a management interface that mutates with the client, instead of one that has to be rewritten for each one?
Business complexity
Every country adds rules; none can be a one-off. The original module was structured and built for the UK's agricultural system.
Engineering performance
The legacy module loaded every check on every field, even ones the user hadn't subscribed to and wasn't using.
User continuity
The original module surfaced complexity unprompted, hidden navigation, dependencies between inputs instead of resolving it. We aligned the flows around the user's mental model.
Process
Snapshots from the process
Solution
A modular spine that absorbs new clients without re-architecture.
Opt-in activation as a performance lever.
Modular component over monolith.
Each check renders from the same frame, driven by configuration.
A knowledge layer, not a tooltip cemetery.
Filters as a shared container, not a per-module reinvention.
One filter system every module inherits.
Outcomes
Outcomes
How might we simplify enterprise complexity without removing power-user capabilities? The platform served both technical administrators and non-technical stakeholders. Any redesign had to respect both mental models without creating separate experiences.
Decrease in load time
Fields the user hasn't subscribed to no longer load weight on the platform. We changed our team mindset to: how can we design for technical performance? This was a game-changer in our approach and relationship with the tech team.
A B2B client became a co-author.
The Dyson Farms workshop turned the brief from “translate UK rules” into “design for the next client we don't have yet.”
Scalability proposal became a product requirement in the project brief
We created specific touchpoint moments between the product owners and the technical (tech and design) team to review and evaluate the proposals before any major decision on the technical structure or usability flows was made.
Other projects