There is currently no easy way for farmers within the United Kingdom to clearly, and in one place, get access to information about all available, grants, government schemes, loans and funding available to them.
While some of these are available on the UK .Gov website there is no clear platform that a user, in this case a farmer, can collate all of the information as well as know what they are actually eligible for.
Sources, such as the users bank, are not well known to them and have made the wider agriculture industry sceptical of certain regenerative practises for fear of losing income as well as the fear of financial gain practising more "untested" methods.
At SA Exchange the goal was to not only provide the user with a Dimension based scoring list of their whole farm but also to inform the user of financial incentives that they may eligible for.

The Exchange platform serves as a central hub for farmers. The product comprises multiple components, and hence, farmers would begin by onboarding their farms and fields onto the map. They would then be required to answer an array of questions about their farming practices. Next, they would arrange for a physical visit to the farm by an Exchange Advisor/Technician, who would sample multiple points of interest on the farm. Subsequently, the farmer would receive a report generated from all the data gathered during the visit. The report would detail areas where the farmer had room for improvement. After that, farmers could use the Exchange platform to view recommendations on farming practices and funding that is available to them or that they are close to being eligible for.
The report would break the users farm down into 6 main dimensions, these dimensions being;
- Animal Welfare
- Biodiversity
- Climate Change
- Healthy Soils
- People and Society
- Water
Contained within each dimension would be a number of more detailed data points and break the users over all score into a numerical value ranging between 0 and 10.
These number can then be benchmarked against the UK average as well as their surrounding area so that the user can gauge their performance and, if need be, adapt their farm practises to obtain a higher score.

Role + Responsibilities.
Senior Product Designer
- Generating the company design roadmap.
- Breaking down current interface to a series of MoSCoW requirements.
- Redesign of the interface in accordance to user feedback.
- Engaged and responsible for the agile design sprint planning.
- Testing ideation with internal stakeholders
- Responsible for the full end to end product delivery
Project Types.
New Product Development
- Ideation workshops
- Data gathering / breakdown
- User testing
Product Redesign
- High/Low fidelity wireframing
- Product “Happy path” & user journey generation
- Usability revamps
Product Maintenance
- Short sprint feature ideation & implementation

Original interface visual Style

Farmers are extremely busy people. So much so that they are notoriously difficult to get a hold of for calls and especially testing. Feedback came into the company periodically and usually via the farm advisors that were performing on site visits as they were more customer facing.
Due to the users availability, most of the time, only at weekends or late nights, surveys were used a lot to give the users the comfort of completing these in their own time and give them an opportunity to write how they felt about their experiences, the platform and the whole end to end process.
With the combination of email feedback, verbal feedback (with notes from advisors) and surveys, the team was able to formulate a traffic lighted list of the most imperative actions to take as we worked through our sprints.
While there was plans in motion to overhaul the user interface and incorporate much of the feedback into the new version of the platform it was also important that any feedback that was deemed as a blocker for the user was fixed there and then.
This may have been slight tweaks to the design however more often than not a lot of the feedback was about data display (their report) or a disagreement on things they did not believe were true that advisors were recommending the user do to aid their farm.

Like the majority of SaaS products there are a multitude of different aspects, whether user facing or internal, that can contribute to the overall success of the final product.
At Exchange I created a full product user journey map to confidently visualise, to the team, every point in which a user will interact with the software, how it will affect their flow and what our celebratory moments to the user should be.
From the image (below) you can see the parts that will effect the company as well as the user and what the final objective we are aiming for is.
The users path fluctuates through multiple aspects from their initial onboarding process all the way to obtaining their report and then giving additional features/options that the user can perform after that.
One key aspect of this that was pushed was the "magic moments", these sections were meant to be real causes for celebration within the platform and leave the users with a sense of achievement and fulfilment on getting this far through the product.
The four main magic moments were.
- The user being able to visualise their whole farm on the software
- Their first request to the software
- The published results sent to them
- Achieving a goal that they had written as an action for their farm.
However, the top most important goal for the user, and for the company, was to get the user their results. This would in turn allow the users to visually understand their scores, what they could do to achieve a better result for their farm next season as well as understand and obtain any monetary funding available to them to help in succeeding in this goal.

As the only member of the product team it was up to me to define the user requirements given we had our happy path, a current V1 design, the user feedback obtained and additionally taking into account our current timeline/deadline, resources available and sprint planning sessions.
This list of requirements was collated into an Excel sheet and was traffic lighted to highlight;
- Our current capabilities
- Capabilities that are part way there
- Capabilities that had not been started yet
Many workshops were carried out to finalise these requirements and were captured, initially, on a large shared Miro board that the whole team could access while I ran the workshops.

Given that the premise was to completely overhaul the design and interactions with the users it stood to reason, mainly because this didn't currently exist in any shape or form, to map out every interaction for all of the sections within the platform.
The process took a few weeks/sprints to finalise and helped to expose weaknesses in the user flow as well as retire any redundant features within the platform.
The categories that were bucketed were;
- Dimensions and scoring
- Funding
- Action and recommendations
- The map
- Surveys
- Sampling
- Lab results
- Additional settings
- Knowledge and sharing centre
- Onboarding
Each category was then given an overview look for the full end to end process, where the users journey could depart from the intended path, as well as any feature requests from stakeholders that could make it into the re-design.
This also began to help establish repetition and allowed for the product and dev teams to determine where CTA's would be integrated to increase productivity in the users workflow given their feedback about the application.

After identifying the key areas that the users struggled with within the user interface the next stages were to iterate on some visuals that could be retested with users. This was a fairly straight forward and easy process as I have an underlying knowledge and understanding of many map based interfaces.

The main problem with designing for screens, while also implementing a map, is screen real-estate.
- How will the user use the interface?
- When will the user want to view the map?
- Will the map save states between screens?
- Can we streamline the journey to be very linear?
A combination of the (below) screens was eventually agreed upon, by internal and external stakeholders, for the final version.

SA - Exchange

The problem

How it works

My contributions

User feedback and painpoints

Happy pathing

User requirements (MoSCoW)

User flows

High fidelity mock-ups and concepts