ruumi Case Study 1:
Platemeter Integration
UX Design & Product Management
Q2-Q3 2024
iOS Native App with backend logic implementation
Project Overview
My Role
Primary: Product Manager
Secondary: UX Designer
Timeline
Q2-Q3 2023
(this is a real job, not a case study)
Tools
Notion, GitHub, Mixpanel, Metabase, Google Sheets
Figma
Process
(Product & Design)
1- Define
To train our grass-prediction ML model effectively, we need reliable ground-truth measurements to complement satellite data.
Today, farmers can “correct” predictions using their own estimates or platemeter readings, but these inputs can be biased (device differences, measurement technique) and rely on farmers remembering to enter data - resulting in inconsistent labels.
The Challenge
The Goal / Objective
Deliver a seamless platemeter workflow in ruumi’s iOS/Android apps: when the farmer powers on the device and starts farmwalking, the app auto-detects the current field, records each biomass reading with a timestamp, and - after at least X valid reading - calculates and saves the field average. Farmers can review readings and delete outliers before finalizing.
Constraint:
Have a working MVP prototype (pair → capture → simple summary) ready to demo to farmers at Groundswell 2023 in a few weeks, prioritizing reliability and clarity over advanced analytics.
We know this MVP will be a success when:
Performance & reliability: ≥95% success for device pairing, reading capture, and field-average calculation (no blocking errors).
Usability: Farmers can complete a farmwalk and save readings to the correct field without significant issues (unaided task success target ≥80%).
Demand signal: ≥30 qualified sign-ups on the website to receive a trial platemeter (10 units available), indicating willingness to help collect ground-truth data.
Success Criteria
2- Research
ruumi is designing their own platemeter with a 3rd party partner (Elobau). There is not a big selection of platematers out there in the market anyway, but there is one that keeps coming up in the conversation with farmers. It is called Grasshopper.
We ran a quick competitive review of Grasshopper - its capabilities and workflows - to inform our farmer interviews. That context helped us pinpoint where ruumi’s platemeter could deliver a more compelling, end-to-end experience.
Platemeter Express Research
User Research - Interviews
Purpose
To understand farmer’s pain points and needs when it comes to platemeter usage.
12 farmers, existing users of ruumi app
1 hour call via Google meet, recorded
1 main interviewer + 1 shadower (note taker)
Setup
In summary, our farmers have the following pain points when it comes to platemeters
1
Each platemeter comes with its own app, forcing farmers to calculate an average there and then re-enter it across multiple apps/websites: time-consuming and error-prone.
Manual reading entry in many apps
2
Platemeters are costly. A Grasshopper unit typically exceeds £1,000. Since grass measurement is essential yet often unaffordable, giving farmers free or significantly lower-cost access would be a game changer.
Cost
3
Platemeters are generally accurate on ryegrass but less reliable on herbal leys (taller, mixed-species swards). Able to specify the field composition - and calibrating accordingly would improve accuracy.
Not accurate for some grass type
4
Ideally, the platemeter would be needed only periodically, not every week. It’s a time-consuming task especially on larger farms. So occasional spot checks are preferable.
Time-consuming to use
3- MVP Definition
To meet the goals and address the researched pain points, we drafted a set of user stories. Each was estimated and run through a strict MVP filter - only must-haves ship in the first release; nice-to-haves are deferred to later iterations.
Platform scope (iOS-only MVP, backend calculations)
To simplify testing and hit the deadline, we’ll launch the MVP on iOS only, with all calculations handled in the backend.
Why:
This use case is for farmers in the field (“farmwalking”), so web isn’t in scope in the foreseeable future.
The team predominantly uses iOS, giving us more test devices at Groundswell. Our iOS app is more mature than Android, with a fuller feature set - which means our team could also showcase to farmers more capabilities in addition to this specific features.
Shipping one platform first enables faster implementation and clearer learnings.
Effort Estimation
Next, these must-haves are then estimated together with engineers to understand if it is feasible or we need to do further scope reduction.
User Stories & Effort Estimation
Now that the MVP scope and estimation is available, this project is then put into the proritization workflow.
Prioritization & Roadmapping
Then, the delivery roadmap is updated to reflect the scope, with next iteration planned in subsequent quarters.
4- Prototype
Using the agreed scope, I drafted a FigJam prototype mapping the end-to-end steps and key error states, then invited the product team to collaborate and comment.
After a few tight feedback loops and small iterations, we converged on the final flow.
User Flow & Low-fi Prototype
MVP - Final Screens (iOS only)
5- Development
Now, we’re ready for development to begin!
Relevant user stories were decomposed into technical tickets with event instrumentation and analytics requirements.
Each ticket includes clear, testable acceptance criteria and was refined and sized by the engineering team.
Refinement
All tickets are then put into sprint planning, considering as well the tasks dependencies and tasks that could be done in parallel.
The backlog is prioritized so developers can pull the highest-value items first.
Sprint Planning
The sprint begins and engineers pull tickets in priority order. They sync with me (PM/Designer) for any clarifications, and we make minor, documented adjustments to the acceptance criteria as needed - without changing the overall goal or scope.
During Sprint
Testing
ngineers publish a staging build for me (PM/Design) to validate against all acceptance criteria.
Since this is a demo for now, we keep it to internal distribution (staging/TestFlight) and don’t submit to the app stores.
Based on the staging build, I prepare a feature brief and testing guidelines complete with video walk-through and FAQs, so the whole team can run consistent usability tests at Groundswell.
Ready for Usability Test
6- Usability Test
Taking advantage of this event (Groundswell), we decided to do usability testing by demo-ing the integration and ask farmers what they think over the two days exhibition.
Everyone in the team who has an iPhone will have access to the staging app
A write up of step-by-step demo process and FAQs are provided ahead of time, so everyone can get familiar
Preparation
We consolidated all farmer feedback into themes and a prioritized backlog (with quotes and counts). Overall sentiment was strong: farmers see clear value in the workflow, with a handful of actionable improvements. The signal is clear - we’re addressing a real need; proceed to the next iterations.
Learnings from the Usability Testing
“Can I delete some readings? Sometimes I think I position it rather weirdly so the number looks odd.”
Post-event synthesis
“Why do I need to select the field? Shouldnt the app know where I am and just assign the value to the right field?”
“This is fantastic! Free app and free platemeters! Where do I sign up? I need one of these asap.”
7- Learnings & Next Steps
Reflecting on the success criteria…
Performance & reliability: ≥95% success for device pairing, reading capture, and field-average calculation (no blocking errors). >> Achieved 100% success for pairing
Usability: Farmers can complete a farmwalk and save readings to the correct field without significant issues (unaided task success target ≥80%). >> Achieved 70% success due to internet connection problem at Groundswell. We added a backlog item to investigate offline feature discovery
Demand signal: ≥30 qualified sign-ups on the website to receive a trial platemeter (10 units available), indicating willingness to help collect ground-truth data. >> We received an overwhelming 48 sign-ups on the website.
This concludes, that the MVP was a success.
Future Iterations
CEO: Work with Elobau (3rd party partner) to get the 10 units of platemeter ready
GTM: Select the 10 farmers to receive those platemeters
GTM: Communicate to farmer, and send the platemeters to them
PM to provide guidelines, documentation and support to farmer if requested
Operations Side
Application Side (Product, Design & Engineering)
Add “delete reading” feature in case farmer places the platemeter awkwardly (done, as planned in Q3 2023)
Add handling for unable to connect platemeter (done, as planned in Q3 2023)
Add handling for unable to save reading (done, as planned in Q3 2023)
Make sure web app readings get updated too when a new reading is saved ((done, as planned in Q3 2023)
Immediately before publish to app store (Q3 2023):
Iteration 2 (Q3 2023)
Save individual reading instead of average (done, as planned in Q4 2023)
Read grass type data and adjust the readings accordingly (not done - deprioritized due to change of business strategy)
Iteration 3 (Q4 2023)
Roll out to Android (done in Q4 2023)
Personal Note
This was my first end-to-end project at ruumi. I stepped into UX research and design with no prior experience - on top of learning a new industry and unfamiliar hardware. The process was a crash course that led to many subsequent flows and new features in the app.
My biggest takeaway: some use cases only surface in the field. At Groundswell we hit real connectivity issues—something lab tests didn’t expose - so the next iterations prioritized offline-first design (queued sync, clear status, graceful retries) to match farmers’ real conditions. This experience reinforced my commitment to rigorous user research and the critical role of usability testing.
I field-tested the app on a patch of grass near my home using the platemeter (without the handle) with first staging release of the app - with my dog, Paco, as my enthusiastic assistant.