Flokk Harvest Extended
Within eight weeks, we researched, designed, and implemented a web-based application which reduced the time to produce an EPD from three weeks to less than three days.
Summary
Flokk, a rapidly scaling international office furniture company, is a leader in sustainable production and recently embarked on a digital transformation journey. Aigonix (formerly Dolittle) partnered with Flokk on product and development efforts, including the Harvest Extended project, which built on earlier work before my involvement.
Harvest is an internal application used by Flokk's sustainability team to centralize critical data shared across sustainability, supplier, and design departments. Previously, much of this information resided on personal computers or relied on the expertise of long-tenured employees, creating risks of data loss or knowledge gaps.
Producing Environmental Product Declarations (EPDs)—which detail the carbon footprint of each component and the total environmental impact of a product—was an time consuming, Excel-based process requiring weeks of manual effort and deep institutional knowledge. As a result, EPDs were only created when absolutely necessary.
With just eight weeks from kickoff to delivery, our small team (a UX designer, product owner, and back- and front-end developers) set out to streamline this process. Midway through, I assumed many product owner responsibilities, including client communication and prioritization, after the product owner fell ill.
Initially designed for one employee, the application's efficiency improvements enabled its adoption by three sustainability team members, with plans to expand to the design team for proactive sustainability decisions. The app reduced the time to create an EPD from three weeks to under three days, a significant improvement given that even minor changes, like altering a component’s color, require a new EPD.
Disclaimer: Many of the images below were screenshots from the Miro board that was used throughout the sprint. Due to budget constraints, my seat is currently view only so no edits or extractions are possible. Some images may appear as poor quality but I can provide a link to the miroboard upon request.
A walk through an early prototype of harvest extended
The Problem
Flokk relied on a single employee’s institutional knowledge to create EPDs, a process that was legally required (in certain cases) but extremely time-consuming and repetitive. This bottleneck limited their ability to scale, forcing them to decline smaller or diverse orders when EPDs were requested, as the time investment couldn’t be justified. Automating the process and making EPD data more accessible would allow more employees to produce EPDs and leverage this information for sustainability-focused decisions. It also protects the business if the employee were to be suddenly unavailable.
What the process looked like
The diagram below outlines the steps to generate an EPD. The most time-intensive task was identifying relevant data and assigning materials to each component. This often required reviewing past EPDs, consulting suppliers, or relying on personal knowledge gained from previous work. A key risk was inefficiency: if two similar EPDs (e.g., differing only by seat cover color) were created months apart, critical details might be forgotten, forcing the process to start from scratch.
The Proposed Flow
Wireframing and Prioritisation
We began with a “quick and dirty” approach to capture initial design ideas, followed by low-fidelity wireframes for user testing. These helped us identify non-negotiables, feasible solutions, and opportunities for a “wow factor.” The strong trust within our team made this iterative process smooth and effective. Below are examples of our approach.
Initial idea storming and identifying key tasks
Adding materials to a component was the most critical and time-intensive step. We invested significant effort in refining this process, iterating extensively and questioning each detail. The challenge lay in balancing simplicity with the flexibility to innovate and be willing to reorganise the process if that’s what it took.
Wireframes and how we captured feedback
Given time constraints and the technical limitations of integrating the app into an existing system, design work happened asynchronously with development. Wireframes served as a vital tool for documenting areas requiring feedback or collaboration.
Collaboration with the Developers
Our team’s strong trust and communication enabled an iterative, non-linear process, which was essential given the tight time and cost constraints. To meet the deadline, we decided to use standard React components and minimize customization, prioritizing function over visual appeal for an MVP. In the final weeks, I worked closely with the front-end developer, making live adjustments during calls. When we couldn’t do this because he was working on a particularly challenging part of the build, screenshots from the application in the test environment and comments proved invaluable for clear communication and to avoid losing time. I am sharing these because they highlight how collaborative the process was, but also because they are images that capture some of my favorite moments. It was a fast-paced time where everyone had to bring the best of their problemsolving abilities in their disciplines and we all rose to the challenge.
Feedback
After testing the MVP with the key user and a few other employees, we shared some feedback with other stakeholders in the business. The purpose of that was to communicate the value we had already brought in, what the new status quo was, and where we could be if more was invested into this project. Below are some excerpts from that discussion.
The users said:
The adding a Material screen:
Based on this feedback and what we observed the users experiencing, we made some design changes
The components list screen:
In the components list, the users could not see all the information they needed at first glance. They also were overwhelmed by the volume of rows and that they could edit them all. This increased the risk of adding materials to the wrong component.
To improve this, we adjusted the size of the component ID column, rearranged the columns so the most relevant information was shown, combined the column indicating if a component needs work with the details column. We also introduced some icons for the material type.
We also increased the ‘clickable area’ to access the add materials screen.
Tackling the issue of knowing whether all the materials have been added to a component requires more exploration. We considered building an events log so the user can quickly remember what they were previously working on, and return to the relevant component or having the user indicate the expected number of materials to be added to a component or allowing the user to mark a component as complete.
Originally, the component name and number was not on this screen. However, it was important to me that we add it, as it drastically reduced the mental load on the user, especially if they were interrupted or needed to consult with someone else on what material should be added to a component. (and I was lucky that it was easy to do for the developer!)
Not all materials are listed in Kg or g, so this should be more flexible. However, the users said the conversion was very easy for them, so not to prioritise it.
A further improvement that is needed is to add to this screen any materials that have already been added in order to help the user keep track of where they are.
How we decided which icons to use:
The raw materials used in the components are very technical and were foreign for all of us in the team. However, they are very familiar to our users. As a designer, I take the opportunities that I can to include users in designing parts of a system that they will use, as I find it significantly boosts feedback and engagement overall.
Deciding on what icons to use to represent the material types was a perfect opportunity to do that and was also quite novel for the users.
Here you will see the results of a card sort that we did with the users where they could allocate an icon to the category they felt it looked the most relevant to. And below is what we decided to implement.
What I would love to see implemented
Improve usability by adding tooltips to the table to guide the user on where to 'click' to add or view materials
Allowing the user to enter the percentage of recycled material rather than requiring the user to add two materials
Allowing the user to set an 'expected number of materials' to the component to be able to confirm a component is complete from the component list
Allowing users to add materials in other units as well as g or Kg
Using the icons in more places for memorability
Once the EPD has been generated, allow it to be attached to the project so it is accessible to all users
By importing the data from LCA.no back to the component level, other areas of the business would be able to use it to make more sustainable decisions. This could be in purchasing or product design
By making this data more accessible:
New Product Development could test out the environmental impact in design decisions before building products
Sales could easily attach this information to tenders/proposals which was one of the problems experienced before
customers could use environmental impact as a decision criteria when configuring a product which allows for the customers to be more strategic in the impact of what they purchase