Creating tomorrow’s livestock provenance / supply chain

In late-2020, the Hello Human team set off on an adventure to digitise Meat & Livestock Australia’s livestock traceability platform.

This 8-stage process, innovating and designing how livestock farmers track and manage the livestock lifecycle on their farms, challenged our problem-solving abilities and took us around the country. You can gallop over case studySupporting livestock farmers with innovative platforms to get ‘it’ donehere to read Part 1 of this Case Study. 

In any case, that brings us here — Part 2 — after these original efforts were not received well by the end-users. On reflection, this was due to a focus on designing ‘happy’ journeys and a lack of focus on fundamental parts of the process and platform, such as validation.

Feedback from livestock groups and farmers was so negative that their preference was to revert to the manual, paper-based tracking process. Awkward…

So, Hello Human was asked to get back on the horse and produce a better solution.

Reigniting the flame

Having already worked with this client on user research, we had gained an understanding of their users — the needs and pain points of livestock farmers when digitising farming platforms. It wasn’t necessary for our team to spend additional time on user research, as we had established a considerable amount of knowledge in this area. 

Drilling down into the problem, we found the client’s platform required a substantial amount of extra validation to ensure some form of traceability as it was relying heavily on paper. Engaging production developers may have been the obvious solution, but this approach would entail estimations, time and money. The project wasn’t at that stage yet, so things needed to progress while being done 'off the books', so to speak. 

So, how do we visualise a logic-based system without relying extensively on developers?

Building a halfway house with a design system

It was decided to build a new experience from the ground up. This also meant the opportunity presented itself to integrate a new design system within the client’s workflow.

The client’s existing design system was set-up similar to a component library in Storybook, meaning the product developers had a ‘sticker sheet’ of pre-made components to build experiences. It was apparent that developers had previously built components using inline CSS and outdated technology such as jQuery. This limited what could be produced by the system and resulted in inconsistent, sometimes ‘messy’ code.

We were seeking a new, modern framework that is adaptable and easy to use. The new design system selected was Tailwind, due to its simplicity, ability to have more clean and consistent code, as well as being able to keep the client’s internal maintenance and contribution to a minimum. 

Due to the complex logic and flow of this new experience, it was decided to build a coded prototype. We needed to be able to build the prototype without actually building it (bear with us.) Commonly used tools such as Figma, Axure or Sketch would be impractical in this case, as they typically focus on only a few paths and we needed to have more flexibility than these would allow.

A comprehensive library of coded components enabled us to build experiences that were decoupled from the main codebase. The look and feel would be the same as the new experience, but there wouldn’t be a requirement for any back-end logic.

An added selling point to this approach was being able to simulate all our logic without having to write any Jira tickets. This made the developer handover very clear as we had ironed out kinks at the prototype stage.

Outcomes from the prototype

Create React App, a get started package created by ReactJS, was used for the new experience prototype. This tool made it simple to get started and it was straightforward to publish online previews for the client in order to obtain feedback. 

Since the prototype was in Javascript, we were able to hook up business APIs to make the prototype feel more realistic (ie. alongside mock data.) Previously, we had to encourage participants to imagine scenarios based on the static designs and it would always create a friction point. By using business APIs, we removed that common friction point and enabled the participant to focus on the experience at hand.

Overall, including APIs in the experience improved our usability testing with participants, because their journey felt specific to them and their profile.

We’re glad we prototyped in this unconventional way, as the project lifecycle took us on a complete redesign of our initial idea and many logic changes. We got to thoroughly test the nuances within the system and while it was more work, the quality of testing as well as the end product, was greater than any static design could ever achieve. 

We tested concepts for features that wouldn’t be in the product roadmap for some time, like a QR code scanner allowing users to transfer data offline. We have to admit this was a little trickier to prototype, so we added a QR code scanner and people could test from their phone ‘for real.’ It even read the data — winning!

Preparing for production

Thorough testing of all the logic and flows of the new design system meant that working with the product owner and writing the Jira stories was plain sailing. We were confident that what was tested was achievable in production because the discovery stage of the project was in the prototype. Jira became a task list, rather than a bunch of spikes and stories, as developers and business analysts had the prototype as a strong, useful reference point.

Final thoughts

Even though it’s more upfront work to build a real, coded, prototype vs static design flows, the quality of user testing and developer handover is worth it — especially with complex flow-based products.

We acknowledge in this scenario that not every design team has front-end skills, but projects like this show how crucial it is for the client to have a resource available with the ability to code. We see this as an evolution of design teams, with their own front-end development team that are dedicated to servicing more detailed prototypes. 

The quality of everything in the workflow is improved, as more questions have been answered at an earlier stage. This is an approach that ultimately reduces back-and-forth, saves time and of course, money!