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.
xFarm started in Italy, designing for the smallholder who runs a few hectares and one phone in their pocket. The Checks module — which tracks when a field exceeds the legal threshold for fertilizer, water, or chemicals — was built around that user. It worked because the constraints were narrow: one country's rules, one user per field, one phone per user.
When Dyson Farms came on, the constraints inverted. Hundreds of fields under one operator. UK regulation. Compliance components Italian agronomy had never tracked. The module didn't bend — it broke.
Scalability had not been considered during product initial conception. This was impacting 3 company strategic pillars: business, engineering and product usability.
Challenge
Make the next client easier than this one.
The temptation was to bolt UK rules onto the Italian module and ship. That would have worked once — and broken again when the next country, the next regulator, or the next fertilizer component arrived. Change isn't a one-time event in a scaling product; it's the operating condition. So the real question wasn't how do we add UK rules. It was:
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 · Compliance integrity
Every country adds rules; none can be approximated. The original module was structured and built for Italy's agricultural system.
Engineering performance
The legacy module loaded every check on every field; API costs scaled with users, not with usage.
User clarity
The original module surfaced complexity (repeated tooltips, hidden dependencies between inputs) instead of resolving it. We aligned the flows around linear thinking.
Process
Snapshots from the process
Solution
A modular spine that absorbs new clients without re-architecture.
We rebuilt Checks as a layered component. Macrosettings — the inputs that define what the field is (crop, region, regulatory zone, farm operator) — were lifted to a top tier. Microsettings — the per-Check details that depend on those macro choices — became state-dependent, surfacing only when the macro tier made them relevant.
Underneath, four design moves did most of the work:
Opt-in activation as a performance lever.
Every Check used to load by default and call its API even if the user never touched it. We let the user activate Checks deliberately; the rest stay quiet. Performance wasn't an engineering optimisation — it was a design decision.
Modular component over monolith.
Each Check is its own building block, plugged into the macro layer's state. Adding the next country's ruleset means adding blocks, not rewriting the module.
A knowledge layer, not a tooltip cemetery.
The dozens of repeated i-tooltips collapsed into one full-overlay rules panel — country-aware, deep, scannable. Users see the rule in context, not a fragment of it on hover.
Filters as a shared container, not a per-module reinvention.
Each xFarm module used to render filters differently — filled buttons here, ghost icons there, sometimes nothing at all. We designed a single container that differentiates from the background without adding noise on a platform full of data. Four modules use it today; the rest are migrating.
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