Granular Overview
Granular is a SaaS enterprise software company building management software for farmers. The product covers everything from operations, financials, inventory, reporting and insights.
This is necessary because a majority of American farms are family-owned businesses and, as the next generation are migrating towards cities, other family farms in the area are farming this land - transforming small farms into large farms. As farms are growing, farmers need tools like Granular to be able to manage efficiently. Additionally, the world’s population is growing and farmers need to be able to get more yield off their fields to meet the increasing needs. Granular provides farmers with tools to find opportunities to meet these needs.
While I was at Granular, Granular was very much a start-up. This was an excellent opportunity for me as I was able to learn a lot and have a lot of ownership of my work. However, one limitation of B2B startups is that you have limited data to measure the success of your solutions due to lack of processes and less users.
MY ROLE
Design lead - own Operations at Granular end-to-end including user research, interaction and visual design
PERSONAS OF OPERATIONS
The different personas create a type of data engine for operations at Granular:
The operations manager creates the plan for the year (what to plant on what field, when to fertilize, when to harvest) and delegates work to the operator. The operator works daily on the field (plants corn, fertilizes and harvests the corn) and records what he did (how much corn he planted, how many acres and how much time it took). The bookkeeper, on web, reviews the data the operator records and ensures that it is accurate and resolves any issues or adds any missing data. The CEO uses this data to gather insights that then affect next year’s plan.
Granular Operations: Resolving Data Accuracy
Define Why
So what is the problem? Data accuracy.
The product manager and I found that only 25% of hours and acres recorded are believable. This is not high enough to be able to gain valuable insights which is one of Granular’s key value propositions. Capturing accurate acres covered and hours worked is critical to uncover several valuable insights farmers can use to improve their operations. These data points can uncover inefficiencies in operations that can be improved and help identify when more workers or equipment are needed. This problem affects both the operator and bookkeeper and this case study will walk through the solution for both separately.
SUCCESS METRICS
Generally, the product team and I wanted to increase data accuracy and reduce the difficulty to capture this data accurately.
Key Insight
The product team and I did not set specific KPI (Key Performance Indicator) thresholds which is something I would have done looking back. I would have based the threshold on what we determined necessary to provide valuable insights and the likelihood of success based on the solution provided. In example:
“Increase data accuracy of hours and acres by 10%.”
OPERATORS - MOBILE
CURRENT EXPERIENCE
An operator receives his list of work to do for the day and he will pick out the Work Order he will start on first. Once he gets to the field, he will start the Work Order. There is a list of instructions and more information about the field, location and equipment. Once he is done, he completes the Work Order, looks at his monitor and records the information he sees on his Granular app. Then he moves to the next Work Order and field.
Identified problems include:
Operators are working on many fields a day and the fields are typically right next to each other. This makes it hard for operators to remember to start and stop a Work Order.
Operators enter the data incorrectly. They are typically driving in harsh conditions, in a hurry and have to record what they see on their monitor; this results in “fat-fingering” the data. (This is why the input fields on the Add Actuals screen are custom, to create a larger target for the operator).
A limitation in how Granular records the data results in loss of data. If an operator starts a Work Order again or changes equipment this overrides any data that was previously recorded.
Operators see value in the Work Orders that Granular provides because it helps streamline communication with their managers; however, data gathering for them is tedious and extra work.
Operators are not very tech savvy. For some, this is their first smart phone. Because of this, I could not use elegant iOS or Android interactions such as swiping the card to start a work order.
PROPOSED DIRECTION - GPS TRACKING
The product manager and I discussed leveraging GPS tracking to solve this problem. Granular can utilize operator’s smart phones to track where they are, how long they are there and the area they covered. This takes all responsibility away from the operator to track this data by utilizing the technology of their devices.
After talking to engineering, the product manager and I found that one major constraint with this solution was connectivity. To unlock this solution, users need good internet connection which is not a guarantee for some of the more rural fields. The product manager and I discussed this problem and the proposal of leveraging GPS tracking with eight operations managers and found that managers understood if connectivity is an issue on their field and felt comfortable with opting-out of this solution if so. Because of this information, I included an option in Settings for operations managers to turn on or off GPS tracking to track hours and acres. This way, the team and I could still provide this elegant solution for the majority of clients that do not have an issue with connectivity.
OUTLINE USE CASES
To kick off this project, I created a Google document to outline and document all of the use cases. This helped me have a better understanding of the needs for this project and ensure that the lead product manager, lead engineer and I were all on the same page. There are many edge cases to consider within this project and I considered all of them to ensure that the final solution was well thought out.
Research
I looked at both analogous and competitive software to get inspiration for exploration. FarmLogs was doing something similar and I watched many videos to get an understanding of what they provided. I also drew a lot of inspiration from mobile applications that were solving similar problems including running applications that track how long users are running and their run path.
RunKeeper application
Ideation
I knew I wanted to send the user a notification once they entered a field with a Work Order assigned to them but had an open question on what should happen after the user says “Yes” to this notification:
USER FLOWS
I explored two user flows when the app is in the foreground: “Hand Holding” and “You Got it.”
”Hand Holding” Within this flow, Granular pushes the Work Order to the operator once the operator enters the field.
”You Got It” The user is not pushed the Work Order which gives the user the freedom to pan to the Work Order when they see fit. This is considered a more “magical” flow for the user; however, I was worried that this flow may not be as straightforward and helpful.
User Flow “Hand Holding”
User Flow “You Got It”
User flow when the app is in the background
The same notifications would be sent to the user if the app is in the background:
1. Pinging them that they have entered a field and the work order has been started
2. Pinging them once the user left the field to record data
If the user ignores the in-app notification for two or more Work Orders, the user enters a “Triage” experience once they re-enter the application.
User Flow “Triage”
WORK ORDER DETAIL REDESIGN
I worked on a revised Work Order Detail screen for this project because:
The new workflow made the start and stop button redundant.
I wanted users to understand clearly that Granular was actively recording hours and acres which would not be evident in the existing design.
Current Work Order Detail screen
Exploration 1
Exploration 2
Exploration 3
Exploration 1
I drew inspiration by the simplicity of RunKeeper. I explored distilling the UI and content of a Work Order as far as I could; however, this option did not present Instructions or other functionally easily or intuitively for operators and I quickly gave up.
Exploration 2
The map did not feel impactful enough. I explored moving Notes and Photos below as they are the least important. I explored moving away from the concept of Planned and Actuals towards a more intuitive nomenclature; Instruction and Record.
Exploration 3
I finally landed on a revision I felt confident with. It’s easier for users to understand how to add Notes and Photos than the existing UI and has more appropriate placement. The map is more substantial, indicating to the user that Granular is actively tracking location and time.
I reviewed the revised designs (exploration 3) with the product team and customer success managers (a team that worked extremely closely with our users) and agreed to move forward. As next steps, I stress tested these designs by applying them to all task types to see how it would adapt.
The designs passed the stress-test and worked well as a system across all task types. Next, I explored designs for edge-cases and the remaining steps within the flow.
Test and Iterate
I created a research proposal and two InVision Prototypes to review the two user flows:
“Hand Holding”
“You Got it”
The goals of the test were to:
Determine the correct user flow for the project and revise if necessary
Gather feedback on a revised Work Order detail screen.
Understand what the user expected when the app is in the background. I showed some images of my proposal after hearing their thoughts.
I interviewed five customer service representatives (an internal group that works with our customers daily and have a lot of insights into their business and daily hurdles) and five operations managers.
After the test, I found that operations managers and customer support were concerned that operators may miss their work if it is not directly pushed to them in the “You Got This” flow. Because of this information and the fact that the new flow is a more streamlined experience than the existing one, I felt confident that “Hand Holding” was the correct direction to move forward with. When I asked about the experience when the app is in the background, all interviewees described an experience similar to the triage one I explored. Once shown the mockup, they felt it was a strong direction and delightful experience. Interviewees liked the updates to the Work Order detail screen and felt it simplified what the operator needed to learn and that it appropriately reflected the updates for GPS tracking.
Implement
Revised experience:
Operators no longer need to remember to start and stop a Work Order.
Operators no longer need to record acres covered.
Reduced excess work for the operator and so they can focus on getting their work done.
The data is captured in “Records” to track data more granularly. For example, if an operator changes equipment, the previous data will not be deleted but instead, a new record will open up.
Revised and simplified Work Order Details screen.
“Fat fingering” not solved in the scope of this project.
BOOKKEEPER - WEB
Define Why
Records allow Granular to track data more accurately on the field. Before records, every time a user changed equipment or re-started a work order, previously entered information was lost. The technical solution for this is called Records. Now, if a user changes equipment or restarts a work order, a new record is opened and tracks the extra data.
The concept of Records had not been introduced on the web application and the bookkeeper needed to be able to edit or enter this data if incorrect or missing.
Research
There are eight different task types that Granular captures and they all record different types of information. I created a spreadsheet to document what type of data Granular tracks per task. This allowed me to think of a systematic solution across all records and allowed engineering to create components for each type of data which could be swapped in or out of the Record template.
The first task type to be implemented across web and mobile was Input Application because it could be completed before planting season started; planting is an input application task.
Spreadsheet to organize task types and data.
Each component was documented and organized by different states within the Design System.
Ideation
USER FLOWS
For this project, the Granular web application needed to surface Task Records so that they could be entered or edited and Granular could begin to surface data throughout the web application more accurately. To understand how the data flowed through Granular, I created a couple of flow charts:
High level flow chart explaining how records inform data throughout entire system.
Specific example of a Planting record entered by a bookkeeper via web with data distribution.
DESIGN EXPLORATION
I explored a number of different designs for each data component and reviewed how they looked when pieced together.
Exploration 1: Reusing Existing UI exploration
Exploration 2: Simplified
Exploration 3: Simplified
The existing UI of modals in the Granular app surfaces a lot of information and uses a lot of overlapping color. In exploration 1, I reuse the design patterns established; however, I felt it was a good opportunity to explore new patterns because the team was building this modal from scratch. My goal was to use more white space and lighten the amount of information overload so that the user could easily navigate this modal and complete it in less time. You can see this in explorations 2 and 3.
Test and Iterate
I created a research proposal and discussed the designs for an Input Application task to gather feedback and revise the designs. I reviewed these explorations with the product and design teams as well as customer success. This helped me to validate the simplified approach and gather invaluable feedback which I used to refine the UI and UX.
Based on the feedback I:
Moved forward with the simplified explorations
Cleaned up the design of duration, start and end time
Updated the edit mix button
Separated the date, production cycle, task name and the person who last updated the record to surface this information as a title
Explored auto-calculating for [area] x [rate] = [total] interaction within the Input component
Implement
The final solution introduced a refined UI and seamless UX. The componentization of data made it easy for engineering to build and update the modal for all task types.
Introducing Records
Uncluttered UI Introducing new design patterns and stepping away from the legacy design patterns and code.
Smart relationships & auto-populating For example, within the Inputs component, [area] x [rate] = [total]. If the user enters area and total, rate will calculate automatically.
Keyboard shortcuts I found that bookkeepers want to be as efficient as possible and that they prefer to enter data without having to take their hands off of their keyboard. Within records, they never have to use their mouse.
V2 Flag work with unbelievable data
Post-Release Monitoring
So was the solution for data accuracy successful for the operator on mobile and the bookkeeper on web? The truth is, I don’t know and this was a valuable insight for me upon leaving Granular.
Key Insight
The product team and I did not have a process for following up on solutions to measure if they were successful or not.
I took this to heart and began to read books and articles, attended an AB testing workshop and studied ways to utilize data within my process. I tried to figure out how to measure the success of my solutions with limited data and applied what I learned to my next role at Clarity (another, primarily B2B, startup).