Retiring a Paper Process at the Point of Work

Hi-fidelity prototype of the grading flow on a phone, in Spanish, the workers' language: select the greenhouse and variety, choose the cause, enter the count. Second phase, not yet in production.
Role
Product Designer
Owner
iankha
Timeline
2 weeks
Team
Lead Engineer
Date
March 2026

The Short Version

Every day, every harvested rose stem is graded at the post-harvest house, and the ones that cannot be exported are logged with a cause. That log was written on paper, then retyped into a system with no friendly interface and no mobile or tablet version. I found this while doing field research on a different project and, with our Lead Engineer, proposed a two-week fix: direct phone and tablet entry at the point of work. It has been running in production since March 2026, across two farms.

Grading at the Post-Harvest House

In rose production, every stem harvested, every day, goes through grading. Roses that are not suitable for export, which is the core of the business, are classified as non-exportable and logged with a cause: a disease such as a fungus, a malformation, damage in transit from the greenhouse to the post-harvest house, and more.

Grading happens at the post-harvest house, where flowers arrive after harvest. Workers called classifiers inspect each stem and decide whether it is good for export. When it is not, they select the cause. The method varies across companies, but the industry broadly works with four categories and more than twenty causes: diseases, pests, nutritional problems, and management problems. Separate workers annotate the non-exportable counts, and they are one of this app’s user groups.

It is a busy, time-sensitive space. People move fast, wear gloves, and inspect stems as they go.

Printed Spreadsheets

I was doing field research when I noticed a worker holding a sheet of paper, covered in rows of handwritten logs. I asked what it was, and requested to be shown the process.

Handwritten notebook and printed spreadsheet used to log non-exportable products and their causes
Handwritten notebook (left) and printed spreadsheet (right) used to log non-exportable products and their causes.

What I saw was double work. Workers recorded their grading decisions on paper, independently, at the post-harvest house. Then the post-harvest supervisor would take those sheets and retype every entry into the system, from scratch. The program they used had no friendly interface for logging, and no mobile or tablet version. I asked about the process: how long it took, what was tedious. That was enough to know there was a real problem, and that it did not need a large product to fix it.

In conversation with our Lead Engineer, I proposed a small, fast fix: replace the paper-to-system step with something workers could use directly, at the point of work. We agreed to build something simple and usable in two weeks and test it with the people who would use it. In the field test it was clear that everyone wanted it, and the farm administrators agreed to implement it.

Designing for Hands and a Busy Environment

Any app built for this space had to focus on accessibility from the start: minimum button sizes, contrast, and targets that work with gloves on. It also needed a straightforward flow. The question I designed around was: what is the easiest and fastest way, without compromising key information, for someone to correctly register non-exportable product?

Getting the categories right meant going straight to the source. Over a series of video calls, phone calls, and emails, I worked with a member of the farm’s administrative team to distill exactly what made a rose non-exportable, and how the existing paper process already organized that decision. The result was a flow of four steps:

  1. Select the greenhouse the flowers came from
  2. Select the rose variety in question
  3. Select the cause, grouped by category for easier reading
  4. Add the number of roses for that cause
The farm's taxonomy of non-exportable causes, beside the table-shaped wireframe of the end result the data had to produce
Starting from the end result: the farm’s taxonomy of causes, and the table the data had to fill.
Mobile wireframes beside the high-fidelity designs built on the same structure
Wireframes focused on getting the structure right; high-fidelity designs built on that structure, with accessibility and ease of use in mind.

I owned the research, the taxonomy, the flows, and the UI. The design came together fast: a quick whiteboard session first, then Figma wireframes and straight to the development team. I did not spend long in a design tool, because UI polish was never the priority; accessibility and usability were. The Lead Engineer and the dev team matched that on their end, with offline support for warehouse connectivity and role-based infrastructure to separate what workers, administrators, and supervisors could each see and do. During development we also added back-office functionality: Excel import and export, an analytics dashboard, and a guide for admin users.

What Shipped, What’s Next

The two-week build shipped the flow and structure above: select the greenhouse and variety, choose the cause, enter the count, at the point of work.

The live MVP in use at the point of work.

The high-fidelity designs shown here are the second phase, built on the iankha design system. Their visual refinements are not in production yet and will be implemented in that phase.

Time Recovered, Trust Earned

The paper-to-system step is gone. Workers log grading decisions directly on a phone or tablet at the point of work. The post-harvest supervisor no longer spends 30 to 40 minutes every day retyping paper logs into the system; time that used to come out of their lunch break, or after hours.

The app has been running in production since March 2026, across two farms. The time saved is the measurable result. The clearer signal is what workers asked for next: a full overhaul of the MRP system they rely on for everything else. After using something built around how they actually work, they no longer want to tolerate tools that were not.