Red Arrow Labs Bus Trip


Going the extra custom software development mile

A few weeks ago, I did something cool: I hopped on a chartered bus with 12 members of our application dev team to work with our client's users in their native environment. While taking a six-hour bus trip to collaborate is unique, designing software around user needs is not a new concept for us. Putting users at the center drives our design and enables us to consistently deliver software experiences that users value.

For this enterprise custom software project, our client has a high-touch customer experience and a complex distribution workflow, all for costly products that result in zero margins for error. The complexities of also integrating our UI with an advanced third-party database and designing for many different types of users all drove why we hit the road to collaborate.

Destination empathy

Our goals for the trip were straightforward: gain a clear understanding of our client’s business workflow and specific user needs through collaboration and direct observation.

We practice agile development with a cross-disciplined team of analysts, developers, designers, project managers and testers. To build features users need and value, our designers dig deep to create detail-rich artifacts through journey mapping and co-design activities. While user research artifacts are valuable, nothing beats direct observation for developing user empathy. By pairing developers with users, they could ask questions and draw inferences from personal observations, without having to look through someone else’s filter. 

Features follow ideation

To make our time efficient and productive, our analysts and designers led a set of activities for our bus trip and onsite sessions to confirm user requirements through ideation and observation.

The hands-on group sessions were designed around specific user roles and focused on framing problems, rather than working from predefined assumptions, which may have missed the mark. Our work in these sessions set up unique user problems. For example, we began by ideating on what information is important for a specific user to select to begin a task and how they need to interact with it. From there, each activity built on information discovered in the previous session, which resulted in vivid information generated from a user-centered lens.

In addition to our active ideation sessions, we paired developers with specific types of users, enabling them to see first-hand how they worked. Observing someone working with a customer and seeing his or her physical reactions is dramatically different than reading a user story at your desk that states, “User cares deeply about their customers.” Nothing tops direct observation to humanize the user experience, and user-shadowing was invaluable in gaining true design empathy.

The takeaways

We’re problem-solvers by nature, so physically being onsite to collaborate with users gave the team a richer context to do great work. Beyond nailing down a feature set based on how users perform tasks, seeing people do real work in their physical environment had a big impact on how developers viewed users’ needs. It isn’t an everyday activity that our developers visit a distribution center and get up close and personal with users, so I’m sure this experience will benefit future projects, too. Regardless, our work together will enable users to work the way they want to, with a tool they won’t want to live without.

As a project manager, seeing everyone come together to create useful software made the trip professionally rewarding. And it was personally rewarding, too. I get to work with people who are 100 percent committed to their job, giving up their personal time to road trip to do great work. Their enthusiasm and passion to make products that make a difference in people’s lives made every mile worth it.