A Widget System for Agricultural Monitoring
I was the designer on this project. Implementation was handled by colleagues on the engineering team.
The problem
The old plot summary was a fixed stack. We piled sections in an order we controlled, based on whatever sensors and integrations the users added. At first, it was fine, we didn't have that many. But as the app grew, so did the complaints.
Some users had to scroll through, a lot, to reach what mattered. Let's say you wanted to reach the accumulation section, you had to scroll through every other section, paying for load times and screen real estate to display data you'd never check. And it would get even worse, with new features landing in the middle. They wanted control back on what was displayed and how, fair enough!
Talking to users
We didn't have a proper research phase. But our product owner was regularly meeting farmers for other reasons, so I used some of those meetings to ask about the plot summary: what bothered them in the list, what they scrolled past, what they were actually looking for. Two things kept coming up. They wanted control over what was displayed, and they didn't want to spend time configuring it. The second one ended up shaping most of the project.
Looking back, one of my questions wasn't great. I asked if being able to reorder and hide sections would help, and everyone said yes, which doesn't tell you much. Testing a prototype would have given better answers.
The constraints
Most Weenat users are on mobile, so we had to think mobile first, letting mobile constraints set the rules while still taking advantage of what desktop offers. We had around ten sections to work with, which we broke into roughly twenty widgets.
Those conversations confirmed that users don't want to configure. Or if they must, once, and they never want to hear about it ever again. We also had to account for different usage patterns around the same data: some users care about real-time and short-term forecasts, others use the same space for historical analysis.
The wrong path
Our first instinct was to change as little as possible. We explored adding flexibility to the existing stacked sections: let users reorder, delete sections, and call it a day!
But something was missing: comparison. In a vertical stack, you can't easily compare data across sections. The problem wasn't just about order, it was also about layout, at least on the web. That's how we ended up considering a grid, and then building widgets.
The approach
Automation over configuration
If configuration is an issue, let's try to need it as little as we can, and if it's needed let's keep it simple. To solve this, we tied adding widgets to actions users were already taking. For example, linking a sensor to a plot automatically adds its widget. Same goes for DSS integrations, adding one magically adds the corresponding widget. That way you only have one action, not two, and your dashboard builds itself!
Defaults that earn trust
Still on the “less configuration” train, we treated defaults as a hypothesis. We looked at usage data from the old stack, which sections got clicks through to details, what users praised at fairs, and used it to build default configurations that felt right without being pushy. Most users never touch settings, so defaults have to earn their spot.
That said, widgets also made customization easier. So when users did want to configure, it finally felt approachable.
Discovery where the data is
Widgets also helped with something we'd struggled with for a while: discovery. Before, if you wanted to know what else you could do with your data, you had to leave it, go to another page, find the feature, activate it there, and come back. That's a lot of steps for something you weren't even sure you needed. With widgets, what's possible shows up on the dashboard, next to the data it relates to. You see it in context, and you're one action away from using it.
Platform-specific editing
Talking about customization, let's get into it. On browser we implemented a WYSIWYG drag-and-drop on a 3-column grid, so you can see your dashboard as you build or change it. To expand it, a big button takes you to every widget you haven't added yet, which is discovery again: here's what's possible, add it and explore.
On mobile it's a different game. WYSIWYG is harder to execute, and it's more about order than spatial arrangement. So we built a simple, separate config page with a list of all the widgets you currently have, accessible from the bottom of the dashboard scroll. Didn't find what you wanted? Add it now. This avoids the classic drag-in-scroll hell and the nightmare of dragging a large widget across a small screen.
Sizing logic
Remember the mobile first constraints, that's where they really make sense. Each of our widgets has one fixed size, no variants. To create a widget, we always start thinking about 1x1: can we make this work small? If not, we escalate to 1x2 or 2x2, but only if the content demands it and the importance justifies the space. Every pixel has to defend itself.
Consistency across widgets
What makes widgets click is predictability and consistency. So every widget shares the same bones: a three-dot menu, a consistent footer, predictable states for loading, empty, and error. Learn one, and understand most, yes most, why not all? That's a conversation for another time. When you've got five or more widgets on screen, this consistency compounds: moving, removing, adding, finding actions all feel familiar.
Handing it off
The rest of the team built it, so I made sure they had more than screens. Along with the Figma frames, I wrote documentation explaining my thinking and decisions, so they could understand why things were the way they were, not just what to build. Then I tested the implementation with them and helped fill the gaps, because some widget specs had holes I hadn't caught during design.
Outcome
It worked. Users told us they liked the system, it feels easy, that they feel in control again, that they like seeing only what matters.
We also wanted to check our defaults. After launch we tracked widget additions, drag-and-drop and the order users chose, and compared it with the old usage data the defaults came from. The defaults mostly held. Users didn't reorder much, they mostly deleted the widgets they didn't use, which told us the real need was less about order than about getting rid of what they didn't care about. We kept the defaults as they were, since showing a bit more was part of the discovery idea, and removing a widget only takes a tap.
This data has a limit: it only covers users who changed their dashboard. Users who never changed anything aren't necessarily happy with the defaults, they may just not want to configure, which is what the interviews told us.
One thing we didn't anticipate: seasonal reconfiguration. Priorities shift through the year, and now dashboards can shift with them.
What's next
I'd love to explore widget-to-widget synergies, and the synergy with the rest of the application. How can one connect to another? And what about connections beyond the dashboard, to alerts, exports, other features?