Designing For Invisible Hands

A mobile experience helping the vulnerable in the pandemic

Hopefully you are reading this case study in a brighter post-pandemic future in your self-driving Tesla rocket ships.

TLDR

Along with sheltering-in-place, social distancing, and attending Zoom meetings without pants, New Yorkers did their part during the CoVID-19 pandemic by volunteering with Invisible Hands — an organization connecting volunteers to provide food and medical aid for those in need.

I came on board to the project initially as another delivery “runner” before realizing the experience required some heavy quality-of-life improvements. After connecting with the right folks and taking on the role of design lead, in just a few months all of our efforts were fully fleshed out in the mobile app launch.

As we continue our battle against the pandemic, to this day I am glad I lent a hand. I promise this is the only pun in this article.

Discovery

From Runner to Lead Designer

The organization had to scramble to be up and running within days of the first case in New York, in order to provide as much help as quickly as possible. However, having all forms of communication on Slack was possibly not the most ideal long-term solution for the entirety of the service.

Yes, the platform of choice that arranged a complex web of assigning delivery requests, providing users a changing list of supplies, and confirming recipient-volunteer reimbursement is the same platform that you use to send your coworkers cat gifs.

After only two successful deliveries, I myself already felt the compounding awkwardness of the platform, and subsequently thought how this might affect their user retention. Just peeking into channels, I could tell that the answer was not good: only a marginal amount of new users ever actually took up an order request. These were potential missed opportunities to provide for those in need.

I connected to the founders Simone and Liam, and the talented team of engineers, to lend my expertise. The skeleton crew was already working on a bare bones mobile app but lacked the design adherence they sorely needed. I would like to think I faired better as their lead designer than I did as a “runner” (my cardio is terrible).

Discovery and Strategy

As the platform was expanding its reach outside of New York, we had to address some core issues first. I treated all our weekly stand-ups and occasional stakeholder interviews as I did with my day-to-day clients by asking ample questions to uncover any goals or struggles behind the curtain.

The three main pain points that needed to be addressed were:

1. Communications from the delivery center to volunteers — heroically named “Captain Delivery” — were often fractured and lacked urgency. A message telling you that “Meryl Smith is 2 days late on receiving her medication” can easily be buried under 15 “new user has been added” notifications.
2. Users would also have to manually search for channels that are relevant to them (e.g. nearby neighborhoods, language translations, vehicle availability) and simply await new requests. This posed obvious problems such as intersectional neighborhoods not clarifying their borders and not notifying users in time of new requests before they are taken.
3. Keeping a community aspect was a major factor that needed to be retained. An understandable brand-feel of Invisible Hands was its neighborhood camaraderie and being aware of local politics and news — anything that may affect the runner’s delivery experience.

Not pictured above: 4 rounds of alterations to suit feedback and shifting priorities. Much better than “Accept Request ➔ Deliver ➔ ??? ➔ Profit”.

The proto-persona for the runner could loosely be defined as a younger, healthier individual who could vary on tech-savviness using a mobile device to manage all steps of the order process. After recreating the general experience journey of said user, I went about finding the kinks in the process and went to work on tackling those pain areas.

Wires, Iterations, and Designs (oh my)

Part of being a mindful designer isn’t just designing anything that checks all the requirements boxes: it involves careful collaboration with developers and project managers to ensure features are feasible within time and budget. So asking Boston Dynamics for robot runners was out of the question.

Onboarding

New users are required to provide photo identification to be verified, which could take upwards of two days. Internally, it was suggested we guide prospective runners during this wait period with training materials to acclimate themselves to upcoming delivery protocols.

The command center did opine the desire to easily scan a database to find users that match an order’s specific’s time slots, second languages or vehicle options. However we understood the tradeoff to streamline onboarding and made these fields optional, only requiring basic contact information upfront. After all, no one likes to be bombarded with a bunch of extra fields. Unless you’re a farmer.

The full link to the clickable prototype is here.

News Feed + Messages + Calendar

When we realized that the bulk of social media platforms have already captured that community element that IH was striving for, the obvious strategy we landed on was “just do that.” Using design patterns that are proven to work allowed for us to focus on bigger ticket items while solving for specific organization and runner needs.

One myth that pervades this line of work is that “design has to be original”. There’s that old saying “don’t break what isn’t broken.” I think Shakespeare said it.

The full link to the clickable prototype is here.

Individual Deliveries

Now we get to the meat and potatoes of the app: the volunteer flow from accepting a request to delivering groceries to recipients (like meat and potatoes).

My touch points with the engineering team ensured that we weren’t biting off more than we can chew. Interactive item checklists, delivery contact information, and in-app navigation luckily made it past the chopping block, given our development resources.

The full link to the clickable prototype is here.

Launch and Onwards

And then there was silence. For weeks, I had thought that the entirety of the project had went up in smoke while I heard nothing from the staff. Little did I know that the development team went completely dark to work their magic on making this all a reality.

Suddenly all volunteers were successfully off-boarded from Slack and moved to the Android and iOS apps where orders were being taken up and completed with simpler ease. Mission accomplished, right?

We all know the pitfalls of this kind of waterfall methodology and with it came the bane of my existence as a designer: a whole bunch of design debt. As is expected with any project, there are typically some discrepancies between design and implementation that either remediation or compromise.

Fortunately, a good old-fashioned design audit session ultimately got us back on track.

It was a learning lesson for all of us in retrospect, pushing for us all to have regular check-ins in a more concurrent agile format and myself to document all proper details in a style guide for implementation.

Although I had adhered to a design system in the first phase of the work, a more traditional documentation would have been more accessible for the engineers and any future designers who may come on board.

Now that we were back on track, it was time to tackle the next challenge that the service was facing. What would a design project be without a future phase of work that would require major retooling of previous work?

Multi-Stop Delivery Requests

Multi-stop delivery requests are special orders just for vehicle owners to deliver pantry items to multiple locations within a very specific time window.

I would be lying if I said that this was a cakewalk as requirements fluctuated frequently during this time. Ultimately team collaboration with our concerned parties, project management and myself helped solidify what were must-haves versus nice-to-haves. The following were our priority requirements:

1. Delivery details could not be divulged until after accepting the order.
2. VolunteerHub, a legacy third-party sign up platform needed to be included in the process in fear that users may abandon the entirety of the app out of lack of familiarity.
3. Users would be highly encouraged to commit to being regular recurring drivers for these pantry orders, in hopes to diminish the desperate search for a new volunteer each time.
4. The ability for drivers to choose their own route or not was dependent on the city chapter of Invisible Hands (e.g. New York did not allow for custom routes while Philadelphia did).

We iterated to capture the above needs, while accounting for overall impact on the prior phase work. With some retooling of the overall user flow, we were able to meet most of these criteria with some simple solutions (i.e. user routes were defaulted to show a sequence of stops based on the shortest distance and allowed the user to manually edit if they so choose.

The full link to the clickable prototype is here.

Had we more time with the phase two of this project, I would have eliminated the need for VolunteerHub entirely. Not only would it have been possible given our design and engineering resources, preliminary discovery also showed that eliminating the need for a third party service provided a more seamless experience for the app users.

The Future

Despite increasing laxation around the pandemic, I am currently still involved with Invisible Hands at the time of this writing. With the rise of the troubling Delta/Mu variant, second vaccine booster uncertainty, and Florida being Florida, there will be new challenges along the way that we need to face head on.

As the pandemic continues to evolve so most the platform to ensure the safety of the community. The only thing that is certain is that there may hopefully be a day when the virus will be behind us and we won’t need the service any more. That would be a real mission accomplished.