Redesigning a flexible, open-source logistics tool for food rescues

with Colab Cooperative for the Food Rescue Alliance.

Primary Responsibilities

Project planning
Participatory design research
Workshop facilitation
Product strategy and roadmapping
Wireframing and interactive prototyping
Concept testing

Overview

Led redesign strategy of a web+mobile logistics tool that helps food rescues more efficiently coordinate between food donors and recipients, communicate with their volunteer base, and see where needs arise across their communities. Responsibilities spanned from stakeholder interviews to feature prioritization, concepting, wireframing, testing, iteration, and feedback. The interactive prototype tested well with the project partners, rescue coordinators, and volunteers and is currently in development.

CONTEXT

The Food Rescue Alliance aims to create a more just and less wasteful food system through both movement building and direct support to grassroots, community-based, food recovery programs. FRA supports food rescue organizations through peer-to-peer learning, trainings, consulting, resource sharing and workshops. FRA members encompass values such as: health equity, community-driven work, participation, volunteerism, and committing to working on systems-level change. (Find out more here.)

FRA approached Co.Lab to redesign Boulder Food Rescue’s custom, open-source rescue coordination tool, the Food Rescue Robot. While core functionality worked, the interface was less-than-ideal for a common mobile volunteer use case, and many of the software quirks required odd workarounds — especially for those rescues who did not operate in the same model as BFR. A few rescues in the Alliance used the Robot; others were hesitant to adopt it given its idiosyncrasies.

CHALLENGE

Our challenge was to understand how coordinators and volunteers across various different types of food rescues would want to interact with a logistics tool that would best serve their needs. To build something that could adequately scale across the Alliance, the resulting redesign needed to be simple enough to allow a coordinator to quickly do their work, yet flexible enough to allow for the various different models of food rescue work — while remaining accessible to staff and volunteers who may vary in their levels of technology access or familiarity.

Discovery and Needfinding

Conversations with coordinators, volunteers, and donors across the Alliance helped build a picture of different food rescue models, workflows, and technology profiles.

Mapping the flow of food from creation to waste to rescue — and where rescues help meet community needs.

Ideation and Conceptualization

Facilitating a participatory design workshop with Alliance members via Miro to ideate and prioritize requirements.

Wireframing and prototyping

Several rounds of concept iteration. The prototype included a web portal for coordinators to manage rescue routes and coordinate volunteers, and a responsive web and mobile app for volunteers to see, pick up, and log their shifts.

Community feedback, testing, and iteration

Testing across the Alliance via an open-commentary interactive Invision prototype, then iterating and passing along insights and prototypes to the project partner for further development.

Coding and analyzing hundreds of comments for iteration and feature roadmap priority.

Reflection

  • Designing a multi-user tool flexible enough to adapt to dozens of rescue models and use cases was a fun challenge. No two food rescues are organized exactly alike.
  • Food rescue work is human and relies on human connections and relationships. There's a limit on how much technology 'should' do in this space — it should enhance the work of people helping others and themselves, without automating the real work of community building.
  • This was an interesting blend of ‘blue sky’ and ‘practical product evolution’ design strategy. Much of the concepting was intended to be shown to the community to gauge input and feedback, keeping in mind that developing everything at once would be unfeasible — and probably result in an over-engineered featureset and UI. It was fun to be able to go blue sky, and then filter down to an MVP afterwards.
  • It helped to have the time and space to get to know different folks across the Alliance and map out their workflows and needs. This was a project where I felt I had the time, resources, support, and engagement from my team and stakeholders, to really practice participatory design throughout. We were lucky to have a project partner committed to transparency and honest communication along the way. The process felt truly like a partnership rather than a ‘client services’ project.