Context

After 20+ years of acquisitions, Acosta was currently supporting 11 different apps for its field teams. Most Brand Representatives — Acosta's in-store field employees; “reps” for short — had to use at least 4 of those apps on a daily basis just to do their jobs. Furthermore, 5 of them had dedicated engineering teams, leading to unsustainable cost overruns.

Field teams also suffered from high turnover. The typical field team was replacing half of its staff every 6 months. This was exacerbated by a long training process: Reps needed ~2 months of onboarding before they could operate at full efficiency, including a costly 3-day in-person training.

Discovery

To learn more about the business problems and the employee experience that was causing such high turnover, we hit the road. Together with two other designers, I conducted interviews and field observations with over 30 reps in four U.S. states and the UK.

Cumbersome tools based on spreadsheets
The tools used to schedule, prioritize, and log their work sucked.

1. Most of the software seemed like it was designed in Excel (we later found out it was)
2. Tablets were bulky – lots of tasks required both hands; tablets being set down and then stolen was a common issue
3. Most reps used at least 4 different apps daily to do their job (e.g. 1 for scheduling, 1 for talking to their team, 2 for in-store tasks)
4. Lots of handwritten notes & manual effort taking place outside of the apps

No guidance; unclear and competing priorities
Most stores had too many tasks to complete in a single visit, and reps weren’t provided enough info to make good decisions on where to best spend their time. Which of my stores has the most value? What are the most important tasks in each store?

Reps would often follow the alphabetical task order in the app, adding tons of extra time and steps to a typical store visit.

Vague & inconsistent language
Task and location language varied by client and retailer. If you’re checking inventory levels for Frito Lays in a Walmart, it needs to be logged in the “Snacks” section of the app; the same task in a Kroger goes into “Cookies, Crackers, and Chips.” This led to a ton of frustration and time wasted hunting for the right thing.

This was exacerbated by poor visual design, which forced many product names to be severely abbreviated. “CG TBM XCLN SF 6CT” doesn’t mean “a 6-pack of Colgate Extraclean Manual Toothbrushes” until you’ve been on the job for a while, and even then it’s easy to confuse with similarly-abbreviated product names.

Waning engagement; growing frustation
In one of my last observation trips, a Rep summed up a consistent theme I’d been hearing over and over: “It all feels like busy work.”

Design

Journey Mapping
We took our findings to a few key stakeholders and ran a series of design workshops. Our first big a-ha: There’s really only 3 distinct types of in-store work, and they share common phases. Empathy mapping exercises and a SME workshop lead us to a new workflow concept that accounted for each type of work.

Reframing the task language
We worked with same group of stakeholders to simplify the task framework. We went from 22 standardized tasks with hundreds of possible responses to 5 tasks with 27 responses. We then got some quick feedback on the new language & workflow using a lo-fi Typeform prototype.

Sketching & Prototyping
Once we had some signal that the flow was correct, we started thinking about what the app might look like and how it should work. I organized a jam session with two other designers, where we sketched out ideas on what the key flows might look like.

I consolidated our sketches, mocked them up, and took them to a senior engineer who quickly (like, in a weekend!) built out a rough prototype. We got it in front of a few reps and learned the following:

1. Findability improved greatly with the new information architecture and workflow.
2. Reps had extremely positive reactions to “value” context; they especially liked seeing how much value was available at each store.
3. Our vision of a gesture-based interaction model failed miserably (and hilariously). One rep joked “it’s Tinder for store calls.”

Fast feedback loops
After that initial batch of tests, I established an every-other-week test cadence. On the weeks I wasn’t testing, I’d demo progress and learnings to stakeholders and the product team. This way of working allowed us to rapidly identify what was working and what wasn’t, and to iterate with confidence.

Onboarding, not training
I created an onboarding flow for new reps that allowed a large chunk of in-person training to happen right in the app. By capturing a few key details, the app was able to help reps seamlessly plan their routes, create flexible schedules, and effortlessly prioritize stores and tasks with the highest value.

Clear priority and flexible guidance
The new design offered a ton of advantages over the old field app ecosystem:

• Scheduling happens right in the app and can be done on the fly

• Critical store info is front & center; deeper info is a tap away

• Tasks are defaulted to a priority order, but can be sorted by location or task type

• Product alerts and value opportunities are visible right in the app

Less time searching, more time doing
I worked closely with engineering on a new task interaction design that allowed for finding products by scanning a barcode instead of searching and scrolling through endless product lists. We then prototyped a type-ahead search interaction for items missing barcodes or broken device cameras. We also simplified the in-store task interaction with a Yes/No response and follow-up model.

Feedback when it matters
A new end visit flow allowed reps to quickly log their time and review the outcome of their store visits right in the app instead of in a monthly spreadsheet.

It also reminded reps of critical tasks they may have missed while they were still in the store (instead of in an email two weeks later). Seeing the total value of their work at the end of a visit was a particularly delightful moment, providing a sorely missing sense of accomplishment.

After about 8 weeks of testing and iterating, we were confident we’d designed a viable, usable, and feasible solution and were ready to start building Engage.

Delivery

Growing pains
Our momentum took a big hit when it came time to put Engage into production.

The two teams earmarked to build it, one located outside of London and one in Jacksonville, were having a hard time agreeing on which technology would be best for the Field Tools app. The London team I'd been collaborating with wanted to build a native Android app. The Jacksonville team wanted to use Xamarin, a .NET app platform. This debate lasted for months.

Native vs. Xamarin
To solve the Native vs Xamarin debate, I worked with both teams to identify core features that would (1) be sufficiently complex to build and (2) give a good indication of each platform’s performance capabilities. After a two week sprint, the native prototype was complete; the Xamarin prototype wasn’t finished. Native also showed significant performance advantages.

Finally, a decision!
The London team would focus on building a native Engage app; Jacksonville would focus on the backend integrations and infrastructure needed to support it.

To better support the delivery efforts and conduct more research with UK field reps, I joined the UK team in Woking for the summer.

Story writing & stakeholder alignment
Shortly after I moved to Woking, a new Product Manager was brought in to oversee Engage’s development and eventual release. I worked with her to plan and facilitate a kickoff workshop. We helped the engineering team write out the user stories they needed to get started on Engage.

Once the high-level stories were in place, we helped the team work with stakeholders across Acosta to map out which backend systems would need to talk to Engage. We were riding high on a new wave of momentum... or so we thought.

New leadership = new priorities
A few weeks after I arrived in Woking, a new CEO was brought on. Shortly after the kickoff workshops, I was retasked with helping the new PM get executive buy-in for the Field Tools progam. I spent the rest of my summer building decks and demo videos, and helping the eng team clear their backlog.

Not long after I returned from Woking, the Field Tools team was disbanded. All of the new design and product hires were let go except for me and the CPO. My contract ended about a month later, and a shortly after that...

What I learned
Although Engage never launched, my time at Acosta taught me several valuable lessons that still inform my design process today:

1. User-centered thinking is contagious. Once the team started seeing feedback on their ideas from real users, they couldn’t get enough.
2. Sharing an insight is the fastest way to understand it. Explaining my research takeaways to another designer, a PM, an engineer, or even a stakeholder almost always lead to reframing it in a better, more useful light.
3. A fast, frequent, and regular test cadence is critical for any 0-to-1 product effort.