The design Paradigm for LiteFarm is all about accessibility. We are striving at every point to create the easiest interaction possible for farmers using the app. A big part of this is limiting the amount of information we ask users to input to exactly what they are hoping to get out of the system. This also applies to the number of input fields that are required.
For every single required input field, there needs to be a reason it is required.
However, many of the strongest incentives to use LiteFarm come from what the user can do with the data they generate in LiteFarm. For example, being able to manage my farm in LiteFarm and use the data I input to get an organic certification is a huge draw. In this situation, we need to be able to gather this additional data (over a farmer not interested in getting an organic certification). Supporting both of these users is a big part of our Mission Statement to meet farmers where they are. One example, is the amount of information needed to add a new type of fertilizer to inventory:
We can see from the highlighted fields, that there are modifications to both the fields that are visible and those that are required for input based on whether a user has opted to use “vanilla” LiteFarm or is seeking an organic certification through COABC. That is, the inputs to this flow are dynamically generated based on the choices a farmer has made during on-boarding. These choices may influence every single flow a user interacts with.
Architectural Considerations
It’s important to note that this pattern will repeat, and must be extensible. For example, 10 different organic certifying bodies will likely have 10 different schemes for the data they collect. In the case of organic certifications, it’s unlikely a farmer will require two certifications that will dynamically update a form. Instead, the right certification will be inferred based on their geolocation. However, it is perfectly likely a farmer will have several different “modules” that modify the inputs and required inputs for flows. For example, they may be interested in “seed-to-sale”, “planning”, and “workforce management” modules - each of which could introduce new visible and required inputs to vanilla flows. The system needs to be able to handle these potentially overlapping influences and generate a form that is a superset of the visible and required inputs.
Use Case (WIP)
LiteFarm is currently creating a data push to COABC's (Certified Organic Associations of British Columbia) iCertify system. iCertify accepts somewhere between 3 and 50 csv's from an organic or would-be organic farmer in order to verify they meet the provincial standards to be considered organic. The number of csv's the farmer needs to populate depends on the complexity of their farming operation. Our process for mapping data has roughly taken the following pathway (and is definitely still a work in progress!):
Understand the forms and data fields for each iCertify form, as well as the criteria to determine if an organic farmer needs to fill out a specific form.
Map each form or group of forms to a question or action that can either be asked to users during on-boarding, e.g. "Do you want to certify livestock?" or which can be determined in app based on user inputs.
Based on inputs and correct jurisdiction, determine which records LiteFarm needs to generate, e.g. "Do you want to certify livestock? Yes" -> LiteFarm must gather inputs for records LS, LF, LA, & LI.
When generating an input field, choose to dynamically display or dynamically require inputs for specific fields based on what the user needs to get out of LiteFarm.
For fields that don't currently exist - or don't exist in the right format - in LiteFarm, either augment an existing flow with the additional / updated data field(s) or add a new flow to capture the requisite inputs.