Right fruit —
for the right order
“Orchards get one chance to make money every year”—said one customer to me on an ethnography trip. This statement made a lasting impact on my practice at Hectre.
I joined Hectre as a Principal Product Designer. This was a hybrid role that brought my product management and UX skills together.
It involved shipping some large features and making constant improvements to Hectre’s product offerings (Orchard Management and Spectre, a Computer Vision apps that detect and assess fruit size and colour with one click on an iPad or iPhone. By making this data available in seconds, the product can be sorted and stored in locations so as to fulfil sales orders efficiently.
Opportunity and Scope
After three months of picking fruit on the orchard, produce is sent away in the pack houses where it is sorted by size and colour before being stored in climate controlled rooms for up to 9 months. It is important that the rooms are only opened when an order is received by the sales desk so as to ensure the fruit is at its highest quality at the time of dispatch.
While Hectre’s Orchard Management App (OMS) replaced the manual and paper based practices on the orchard, it did little to meet the order fulfilment needs of the sales desk in the pack houses.
We had the data but not the means to make it relevant and readily available for its best consumption in the user journey.
Empathy—what’s that?
Nothing brings more insight to a project plan than meeting the customers doing what they do.
Over 5 days, I visited twelve orchards in NZ’s south island and scheduled three interviews with sales desk office members of some of the largest pack houses in the Washington State area.
"We have minutes to make these decisions, currently t=it takes far too many people to get an answer from"
"If I can't find the folder, I have to wait for the shift manager"
"It works because she has been doing it for years. Not sure how it will go once she retires"
"We have minutes to make these decisions, currently t=it takes far too many people to get an answer from" "If I can't find the folder, I have to wait for the shift manager" "It works because she has been doing it for years. Not sure how it will go once she retires"
"There is a significant learning curve"
"When we cant sell, the lot has to go to juice or cattle"
"There is a significant learning curve" "When we cant sell, the lot has to go to juice or cattle"
Research Outcomes
For NDA reasons, I am unable to share the outcomes of the project in its entirety, I have mentioned some findings that proved to be the factors for some design decisions.
Sales order requirements vary depending on variety of apples, range or specific value of the size and colour of the fruit.
Orders need to be processed quickly as retailers are often considering multiple packhouses at the same time.
Older the produce lesser the selling price.
Sales desk officers search data by Groups scanned or Lots. (A Group is an individual Spectre Scan of a produce bin. Lot is a physical space on an orchard. One Lot growing one variety is standard practice in the industry. One variety may be grown in more than one lots).
Produce is stored by lot numbers and performance of a lot is closely monitored (Currently a manual, paper based practice).
Data needs to be easily readable—visual representation preferred.
Count size is standard terminology used across the industry to represent size of an apple. Count sizes are measured in millimetres in most parts of the world. In the US however, count sizes are measured by number of apples that could fit in a standard shipping box. Therefore, lesser the count size, bigger the apple.
Produce colour is graded by the percentage of colour saturation across the industry.
How Might We
One of the simplest ways to democratically find harmony between stakeholders is to write is the How Might We statements together.
In this session however, I made a start by interpreting the research findings in to these statements. This encouraged the other stakeholders to interpret their understanding and requirements in to this structure.
This brings a common understanding of the direction we are heading in as a team. This is empathy in action.
We chose to prioritise the statements on the basis of our individual understanding of needs and constraints.
User Journey + User story + JTBD
I combined the findings from the online and in-person generative research in to a standardised user journey that demonstrated the MS Excel and paper-based process of a sales desk office when fulfilling an order.
Together with the Product Owner, CTO and Customer Success Team, we defined the Epic in to a story.
As a manager I want to search through groups or lots scanned on specific dates so I can decide what needs to be sent for packing and fulfil the order received quickly.
This was a turning point for the project. It brought a common understanding and quick agreements between all stakeholders.
This also helped us list the specific jobs the user will perform so as to fulfil the sales order.
I compiled the jobs in to functional user stories. Working with the PO, Engineering and CS teams, we prioritised the stories for V1 and V2 of the solution.
In a dual track agile environment, I created six iterations of the designs in the double diamond framework.
I tested the early outcomes with specific tasks assigned to the user by setting up an unmoderated evaluative practice. The CS team was also very enthusiastic about testing these solutions with the customers.
I implement the Double Diamond to facilitate meaningful outcomes for all.
— Engineering and QA are engaged early and often.
— CS team could make verifiable promises to the customers.
— Design team gets traction and direction throughout the project lifecycle.
— Senior leadership has access to insights and design development between the iterations.
Design Process
Double Diamond Process: Iterative convergent conversations with stockholders
Listing assumptions ahead of a generative research workshop provides structure to the process and can be validated with the stakeholders early.
More importantly, Double Diamond framework helps validate assumptions and fill knowledge gaps, naturally.
In some cases the differences in our individual understanding become test cases. Evaluative tests provide us with qualitative data we could base our decisions on between iterations.
Meaningful Development
Double diamond can also be used to keep development lean and user centric, by removing potential over design.
UI Components
Having defined the scope of the jobs the Sales Desk Officer would perform on the proposed dashboard, we begin auditing the existing design system to review, table styles, date pickers, sliders and other UI components that can be repurposed to meet the defined requirements.
This exercise brings standardisation and leverages the mental model considerations made when these components were first built.
The Frontend team took this opportunity to update the code from JS to TS for some of the existing components. The early visibility provided through the framework helps the teams plan their workflow and use such opportunities for updates.
I, as the designer on this project, developed new components to match the requirements better:
— New table component to accomodate the ‘peek into the top three sizes
— Double sliders that the user could drag from both sides so as to define the range of selection for the size and colour requirement matching the sales order received.
— Individual pills with use cases in the searchbar (variety, groups, lots)
When you do it well!
Through six iterations we grew the design from early concepts to final designs of the user journey.
We kept the customer at the centre of all activities.
We remained calm through patches of ambiguity.
We considered other journeys the user would need to go through in order to use the dashboard (on boarding, account activation) as intended.
We considered technical constraints early.
We kept faith in the Double Diamond framework and tested pragmatically as the scenarios presented themselves as against testing after designs were completed.
We kept scale and dream state flows in the periphery of our vision. i.e we knew what we needed to do in V2 of the dashboard.
This project contributed significantly to the UX roadmap and strengthened the designed practice of the business.
