“This payroll was processed and paid last week.
No-one should be able to change it.”
— Payroll Officer
Background and Context
“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.
In the busy season, orchards have upwards of 300 staff working for 10-12 hour days to maximise production and minimise produce waste.
Hectre users (usually supervisors/senior and trusted members of the staff) run the QC process on the produce in the bins and log this data in the system before the bins get sent away to the packhouse.
The staff get paid depending on the number, volume and quality of bins worth of produce. Hectre iOS App creates Timesheets to store this data. Timesheets may be edited from the deice to correct errors on the fly. The data from these Timesheets is stored in Hectre’s Payroll feature which the payroll admin staff generate weekly payruns from.
Opportunity
While the sales team was in talks with a large orchard in Washington State. They had loved Hectre’s offering and were willing to sign the contract. However their payroll admin expressed concern over the lack of lock payrun feature.
In their option, and rightly so, the data was vulnerable and could be manipulated by the staff on the orchard should the iPad go in the hands of a staff member who should not have access to this data.
This feature was already on the road map but had to be reprioritised for successfully onboarding the customer.
My Role
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.
The Product Trio
I believe great products are built by missionary teams. A missionary team needs to have a say in what they are building. They need to develop a shared understanding of who their customer is; what needs, pain points, and desires (opportunities) they have; and the context in which those opportunities occur.
Given the time sensitivity associated with the discovery, design and delivery of this solution we operated in the Teressa Torres’s Continuous Discovery model to deeped our understanding, quicker.
When a product trio works together to develop a shared understanding of their customer, they are in a much better position to create products that customers love.
Findings and User Journey
After every customer interview, we mapped their journey to understand the common behaviour in their payroll export process.
Hectre data needs to be accurate and match payrun data at the time of audit.
Editing historic (more than 1-2 months old) timesheets is not a practice.
Current payrun data should remain unlocked to sync with the daily orchard data.
Transferring unpaid or to be amended timesheets from a previous pay run to the current payrun would be valued. Currently this is a workaround done as a manual practice.
Admins export multiple times throughout the week but run the final export in the payrun after all the data is verified.
Defining Scope
UX goals work best when we allow for have big audacious improvements — Jared Spool
When defining the scope of a feature I believe the design should accomodate the vision in to the probable future. Although in a VUCA environment this future may be ambiguous but it provides a direction of thought and creates new assumptions the team can validate with the customers.
I call this the Dream State Journey. It can be an organic growth to the beginning and end of the proposed future state journey. Depending on the case, the dream state can be making the journey leaner with fewer stages by removing waste placed by current constraints and user mental models.
We clearly identified the new beginning of the dream state by including prompts and requests coming from the orchard devices and versioning of payrun history. But before we could implement that journey meaningfully, we had other problems to solve—including notifications.
Why design early
When faced with large complex problems, I find it much more useful to front-load my process with conversations as opposed to more traditional desk research almost clinical, formulaic style user interviews, etc. This approach is lean and brings traction to the design project.
These conversations can be more effective when you can also show early ideas, visions & explorations to relevant stakeholders.
This works because the mere act of correctly discussing early solution-based ideas, ironically, puts a microscope on the problem itself & its root causes.
Not everyone can imagine the solution or the line of thought I have. These early designs serve as a visual aid to grow the idea.
These designs can be further developed in the double diamond framework continuing with the lean mindset.
Team will quickly respond with questions about the design.
Pitfalls and further design considerations/requirements will begin to surface.
Gives a structure to the conversations.
Creates scope for further discovery.
Constraints, suggestions emerge early.
Truly involve stakeholders early.
Iterations and Concept Fidelity
The early work on the feature was dine using the Continuous Discovery Process with The Product Owner, Tech Lead and Product Design Lead (myself).
I grew this design iteratively, working with the customer and the internal stakeholders over 3 weeks.
As the solution became clearer through the iterations, the fidelity of the design scaled from concept sketches to digital mock ups.
The intervals between the iterations varied depending on the scope of work between iterations.
We had incremental clarity on the usability, desirability and feasibility of the proposed feature design.
The Double Diamond to facilitate meaningful outcomes for all involved:
Engineering and QA are engaged early and often.
Sales and CS teams 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.
Dual track agile (Design + QA)
My practice has benefitted hugely by including the QA Lead in the discovery and design phase of the dual track agile delivery.
QA are a very important stakeholder who will finally bring the design propositions to life through the eventual release. They help you see what you do not see in the big picture planning. Equally, these conversations help define the constraints better and are an opportunity for the much needed early alignment. This is a win-win situation for the QA team as they benefit from the early agreements and it helps them spread the work load across a wider time frame.
In a start up, this is even more important as the delivery cycles are rapid and all failures have to have fast. Managing this practice through the design Kanban board helps in following ways;
Helps the teams gain visibility on the progress of the ticket just like any development board
The ticket supports the PRD or the feature wiki so the changing requirements can be managed
Facilitates cross team conversations and knowledge sharing
Strengthens the voice of the design team in an overall development driven design environment
Helps teams think user first and be more product led
At every iteration we improved our answers to Who, When, Why and How of the design outcome
Outcomes
Making decisions fast and having enough insight to base these decisions on was essential for the intended outcome of this project.
I operated with the ‘just enough research’ pragmatic mindset for a quick but meaningful solution.
In the spirit of Perfection is the enemy of done, keeping a tight watch on scope creep helped the cadence of delivery.
I had been designing and testing the solution with customers and internal stakeholders throughout the project lifecycle.
Managing stakeholders and keeping transparency on the workshop findings and design rationales helped reach an MVP that met all immediate needs—effectively.
