Reground is a Social Enterprise based in Melbourne who turns coffee waste and soft plastics into resource, by bringing waste from cafes and local businesses back into the community. To date, they have diverted 268 tonnes of ground coffee from landfill to local farming projects.
The two founders, Kaitlin and Ninna, have quite a packed schedule and wanted to reduce the amount of time it takes to do their monthly waste reports for customers, as well as introduce new reports they can provide to local councils to help with funding grants.
Goals: Significantly reduce the amount of time it takes to generate waste reports and introduce a new type of report for local councils.
My role: I was the Product Manager and handled all the UX/UI. I also helped run BD workshops and setup some basic workflows for the tech automations.
Results: At the time, Reground was spending 40-50 hours per month on reporting, as it was all done manually. After we introduced a new system that automated the process, that time went to nearly zero — saving them up to 600 hours per year, allowing them to invest their time in more important activities.
Below is an outline of Reground’s original data-collection and reporting process, which took 30+ minutes per customer. This amounted to 40-50 hours of labor costs every month; taking away valuable time from other priorities.
Time consuming: A lot of time and labor cost doing tedious and repetitive work each month.
Opportunity cost: The manual reporting limited time spent finding new customers and rolling out new services; more importantly, fulfilling Reground waste-reduction mission.
Grant funding roadblocks: This process made council-level (area) reporting unviable, which stood in the way of Reground unlocking more grant funding due to impact reporting requirements.
Annoying for pickup drivers: Entering data directly into a Google Sheet on an iPhone is a painful experience for the drivers who pick up the ground coffee.
The process can be mostly automated: After a workshop with Reground and in breaking down the above process, it was clear the process could be mostly automated (except for data input).
Above is the final product we produced, based on the problems we identified with their previous workflow and to extend their reporting capabilities (see the visual design section for a full look).
Significant time reduction: We automated the majority of this process with the system we built: from organising and calculating data, to generating PDF reports and automatically sending them out to customers every month, we were able to help Reground free up 40+ hours of labor time per month and save a lot of headache.
New reports for councils: We rolled out a new type of report called Area Reports, which aggregates all of the other data collected into postcodes. This allows Reground to generate council-level reports, to easily quantify their waste reduction impact. This is great for many reasons: transparency, quantifiable, easy to understand reports and helps Reground to continue getting grant funding.
Far better UX: We used Typeform for data-input, which made the process much easier for drivers on a mobile device. The process was also sped up quite a lot by using pre-filled form inputs — reducing a lot of manual typing.
Built for the future: After a few initial workshops, it was clear Kaitlin and Ninna had much larger ambitions for how software can bring new opportunities to their business. Keeping this in mind, we architected their full vision between the Strategy, Discovery and Design phases. This gave them a full working prototype of what the product could become, while cutting the scope for the first build down so that they are able to meet their more immediate goals.
Though it’s nice to make things look like magic comparing A - Z, obviously there’s a lot of problem solving and hard work that goes into it. Below is the journey we went on for this project.
Technically the only step is data input, as steps #2 through to #5 were automated. The diagram below simply highlights how all of the other steps are handled with the new system.
Before we begin working with new clients, we do a fair bit of due diligence on the product and company. A key requirement is establishing that their business model is viable, and running the numbers to determine if their investment with us to build their product will generate an ROI within a reasonable timeframe.
In this case, we estimated that if we build a system that saved them 40+ hours of labor costs per month for the budget they had, they would recoup their investment within 6 months and from that point start generating additional profit and opportunity.
Furthermore, the addition of their new Area Reports for councils would position them to raise more funds from Government grants, which is a significant boost to their business.
As the solution we came up with relies on several third party services that have limitations, a risk was signing off on the project without knowing it would actually work.
To mitigate this, the lead Software Engineer and I put together a simple proof of concept to see if we could get data from Typeform, format and calculate it within Zapier then feed it into a pseudo-database, Google Sheets, then pull it out into a React dashboard and system that can generate PDFs.
It worked, give or take a few hurdles.
After the Sitemap was created, I broke down all of the individual components and functions that are needed on each screen.
This is done simply by writing out all of the User Stories per screen then generating the elements required to fulfil those JTBDs, of sort.
Note: Universal IA was cut out from these screenshots to save some space on the page (e.g. IA for the top and side navigations).
Although I will usually sketch out a series of layout concepts before doing the IA, the Reground dashboard and all the proceeding screens came out quite naturally, as I had just set up a basic Atomic Design system for Wireframes in Sketch — and given many of the components were repeated throughout the system, it was pretty straightforward.
I will say, it’s always cool seeing a document of text transformed into a visual piece; likewise, always great when wireframes are far easier to flesh out when the content has already been established.
You can flick between the screens with the arrows ⬅️ ➡️
After the wireframes were completed, they were uploaded to InVision and a simple, low-fi prototype was sent to Reground to review.
We all got together in person to go through their feedback and hash out a few obstacles.
This was followed by a round of revisions before moving on to the Visual Design.
Admittedly one of my favourite phases in a project, it was time to make things look all smick.
Much of all the former phases in the process are very problem-solving orientated or research-based, whereas the Visual Design, I like to think, is more focused on artistic expression and tinkering with new UX ideas, whilst at the same time ensuring a high degree of usability.
UI design is something that I always get excited about, because solving a problem with style is a pretty cool concept, when you think about it.
You’re not only helping people overcome an issue, you are also influencing their mind in a way that elicits certain feelings and vibes.
And naturally, I’m all about the good vibes.
In this case, Reground already had a really nice Styleguide, so much of the branding was already done — which let me focus on translating it to a very minimalist design pattern I was keen on.
All the designs were done in Sketch.
A straightforward, low-fi prototype was put together in InVision after the Visual Designs were completed, to get any final feedback from Kaitlin and Ninna before moving into Development.
In cases where Interaction Design and more immersive experiences need to be created, I use Framer.
By far one of my favourite design tools these days is Zeplin! It’s a God send, by any measure.
Once you create all your styles and Symbols in Sketch, you can import each screen into Zeplin and it will pick up all the styles and generate a dev-friendly Styleguide for you (pictured above), even a repository of components.
As I used an Atomic Design method in Sketch, this made the transition into React seamless.
But one of the even better things about Zeplin is that you can add all your documentation on top of the designs, in context, which really helps reduce the design to dev loss in translation.
A basic frontend understanding certainly helps too, as you can specify how layouts should function and work, responsively.
Well, this is where my journey ended, aside from post-dev QA.
The only insight I can provide here is the stack we used, outlined below.
As for QA, there’s an entire piece I wrote up that outlines the process we get our clients to go through when it comes to testing.
Funnily enough, I wrote this for Reground, so the documentation ties in quite nicely with this case study :)
As Reground was a simple product that is built solely for the founders using a very specific environment: MacBook Air’s @ coffee shops running Chrome, the QA process was far simpler than usual.
However, we always work with a “Go live” checklist to audit a product before launch, to ensure we have covered everything we can.
Have all breakpoints been tested across different devices?
Was the site tested on the latest two versions of the major browsers?
Is the OG data rendering properly on crawlers / SNs?
Are downtime notifications setup?
Is error logging active?
Are CRON jobs active?