My Role
“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.
Background + Context
A user with admin privileges could add one staff at a time on Hectre’s Orchard Management WebApp. The product was not equipped with a Bulk Import feature that allowed the user to import several staff members at once.
An orchard in NZ has four to five permanent full time staff that manage most of the orchard activities in the quiet season (all activities except apple picking). These numbers soar several times as the size of the average orchard in the US is about 4 to 10 times larger than NZ orchards.
Can I add them all at once?
A user with admin privileges could add one staff at a time on Hectre’s Orchard Management WebApp. The product was not equipped with a Bulk Import feature that allowed the user to import several staff members at once.
An orchard in NZ has four to five permanent full time staff that manage most of the orchard activities in the quiet season (all activities except apple picking). These numbers soar several times as the size of the average orchard in the US is about 4 to 10 times larger than NZ orchards.
In the picking season however the number of staff actively working on the orchard is between 90-300 in NZ. In the US this number runs in thousands depending on the size of the orchard and their eligibility to hire Recognised Seasonal Workers (REC).
In NZ, REC workers are usually hired from the Pacific Islands and are eligible to stay in the country for up to 7 months of the year. The Orchard authorities (employers) are required to provide additional services, such as, pastoral care, accomodation, medical access to these staff.
It is observed that a significant number of the REC staff could be working on the same orchard year on year. Therefore preserving their data on the system was essential.
Yes—You can.
Therefore, Bulk Import feature with a deep understanding of the payroll staff’s peripheral actions would provide much value ahead of the picking season for the year.
Feature Discovery
Product/Feature Discovery is often a messy process. It is non-linear and unpredictable and the size and type of work may vary tremendously at every step of the process. This is even more true when operating in a start up environment.
The process can be intensive on people’s time and demands the ability to accept and live with ambiguity for significant amounts of time through the discovery process.
We navigate constantly between both, Problem and Solution phases before we test and later ship these solutions. I see this as a scaled up adaptation of the double diamond process commonly used for UX needs.
For the purpose of this exercise, we gathered the following stakeholders:
Product Owner, UX Principal + facilitator (myself), 2 members of CS team (US+NZ), technical lead and five early adopter customers (US+NZ).
Since we were all located in different parts of the world, we facilitated all workshops remotely.
In a very VUCA environment, we want to be able to mitigate risk by understanding
Value, Usability, Feasibility and the Business Viability of the feature.
Findings
A standard bulk import flow is simple to design and implement with next to no research.
But when we met with three customers (two in US and one in NZ) to understand their workflow and the cadence at which they would operate.
Where would the data come from?
What does their standard csv look like?
Where would be their Source of Truth for all the staff data?
How often do they update data of an individual staff member?
Consider usecases of bulk edit after import session. i.e updating two or more fields of two or more staff members (limiting to the common properties between these staff members).
How do they manage staff that repeats every year? Active/Deactive?
How Might We
I interpreted some early findings from the from the workshops as How Might We statements. This encouraged the other stakeholders to interpret their understanding and requirements in to this structure.
It is one of the simplest ways to democratically find harmony between stakeholders is to write is the How Might We statements together. 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. These then make their way into the Product Requirement Document and UX early ideas.
How Might We technique creatively identifies key milestones, risks and collaborative interdependencies that exist across various teams.
Early Ideas — user flow
We considered two simultaneous flows;
First Import : When there is no existing data in the system.
Subsequent Import : When there is existing data in the system.
I analysed the needs and the specific jobs the user would perform in each of these flows.
This surfaced the specific UI requirements for both flows.
We used this intel to build specific UI components needed.
Consider activation and deactivation of existing staff.
Fostered better conversations across all stakeholders.
Incrementally test designs with customers.
Gain momentum and clarity at each increment.
Epic Vertical Slicing
Simultaneously, I helped the tech lead slice the Epic vertically. This helps document requirements for all teams in Jira stories. Vertically sliced stories can be centered around the specific, granular user tasks.
Sometimes design and engineering speak different languages. For a successful project outcome, it becomes important to bear empathy for our internal stakeholders.
Over the years, my design practice has gained a product management flair. Defining epics and the stories within, understanding dependencies and switching between being product or user centered when required.
Working with constraints
UX works best when there is an upfront understanding of technical constraints and how they can be managed. Understanding validations and the delays thereof, limits of API, simultaneous validations, data set organisation, etc helps design or adapt the deliverable to match the user expectation.
The Double Diamond framework merged with Dual Track agile (usually a Kanban board) provides this visibility to the team, early and often. I work closely with QA and the Project Tech lead through the lifecycle of the design and development process. This inturn helps mitigates risk and allows the teams to work well, together.
