An Engineer Walks Into a Design Sprint. You Won't Believe What Happens Next.
Published on .Hello! My name is Jason and I’m a Web developer. I spend most of my time building websites with HTML, CSS, and JavaScript. I’m pretty good at Ruby, too. This will totally date me, but I’ve been tinkering on the Web since the mid-90s and, like many folks from that era, managed to spin a hobby into a decent career. While I have an interest in the entire process of building, designing, and testing Web-based things, I spend most of my work life tapping codes into computers.
I joined the United States Digital Service (USDS) back in April and currently work with my teammates at the Defense Digital Service (DDS). Alongside United States Transportation Command (TRANSCOM), we’re taking a fresh look at a sprawling mass of software and processes that over 400,000 military families use each year to coordinate movement of their household goods from one duty station to the next. We’ve heard the moving process described as the most stressful time in a service family’s life, second only to the stress of combat deployment.
For all my time spent at startups, agencies, and large corporations, I’ve rarely been involved in “design” activities such as user research, sketching sessions, and prototyping. Over the years, I’ve advocated for involving engineers throughout the design process. But while many managers pay lip service to the concept, when the rubber meets the road, organizations tend to prefer that their expensive engineers spend their time writing code. This attitude reinforces inefficient waterfall processes, prevents empathy building, precludes knowledge sharing between engineering and users, and results in lower-quality products.
As luck would have it, one of USDS’ core values is, “design with users, not for them.” In that spirit, I recently joined my DDS teammates in sunny O'Fallon, Illinois for a week-long design sprint.
Go where the work is.
We organized a Google Ventures-inspired design sprint by gathering a select group of service members, military spouses, civilian support staff, designers, and engineers with the goal of addressing some of the system’s most critical usability problems. We divided the group into six project teams, each tasked with developing a prototype that addressed a specific question around the theme of, “What would the moving experience look like if…?” Topics ranged from reimagining the inventory process to revamping the experience of visiting a transportation office.
The days were long and my brain nearly turned to mush, but I’m happy to report that by the week’s end, each team had successfully generated storyboards, produced prototypes, and tested their designs with military families. While working on a project team, I learned quite a bit about how an engineer can help organize, facilitate, and contribute to a successful design sprint.
Design with users, not for them.
I’ve wrestled with adequately capturing in words my enthusiasm coming out of the design sprint. I can’t understate the value I derived from being in the thick of the design process, sitting shoulder-to-shoulder with others deeply invested in improving such a critical system. I’ll do my best to highlight a handful of things I took away from the week’s activities.
One Conversation at a Time
This one is critical. Design sprint activities are purposefully time-boxed to drive project teams toward quick-and-dirty prototypes. In this hectic environment, side conversations could subdivide the group and divert attention from the task at hand. As one of two facilitators on my team, I had to gently—but firmly—keep sidebar conversations to a minimum. This wasn’t much of an issue in my project team, but it’s important to keep in mind.
Manage a Parking Lot
Before this design sprint, I wasn’t familiar with the meeting management concept of a “parking lot.” Basically: capture ideas or lines of conversation tangential to the meeting’s purpose in a “parking lot” for future recall and discussion. In the context of a design sprint, and given the haphazard nonlinear idea generation process, maintaining a parking lot will help the group focus without scrapping useful tangential ideas.
Ask Questions
As ideas flowed fast and furious, I found that asking plenty of questions helped the project team determine which ideas we should pursue, which we should discard, and which we should add to the “parking lot.” By asking plenty of questions, I was able to make sure I had the time to fully understand my teammate’s idea or position. Being asked questions by my teammates kept me on my toes and gave me the chance to refine and solidify an idea or position.
Listen Intently
With the clock running, adrenaline pumping, and ideas flowing, I found it difficult to quiet my mind and really listen to my teammates. My brain was in overdrive coming up with possible solutions when it should have been listening to what my teammates were sharing. Remaining mindful of my own inner voice and actively listening to others was a struggle, but a worthy one.
Create momentum.
We heard repeatedly from participants how much they enjoyed contributing and how excited they are to see their solutions considered for implementation. Some of these folks have served their country or worked in government for literal decades. They related how, in the past, they’d offered solutions to the problems we’re addressing only to watch their ideas fail to gain traction. I’m humbled by the tenacity of those who, despite the relative ease of cynicism, so freely participated and shared their experience.
I’m also grateful for the chance to take part in this design sprint. I was able to exercise a set of skills I don’t normally flex in my regular project work. The week’s activities also built empathy with the military families affected by the current systems and processes. For a brief moment, they opened to us a window into their lives. We demonstrated that cross-functional teams—designers, engineers, and users—could rapidly design, prototype, and test solutions to some of the system’s most critical usability problems.
I fully intend to participate in future design sprints and will continue advocating for an engineer’s role in the design process. If you’re an engineer, I’d encourage you to speak up when you next hear about an upcoming design sprint. If you’re a designer or project manager, include the engineers on your team as you plan out your next design sprint. Together, we—designers, developers, users—can create compelling solutions to critical challenges.
For more examples of governments using the design sprint model, check out the following Sprint Stories case studies:
Many thanks to James Athey, Justin Ellsworth, Jordan Kasper, Reina Staley, and Elliott Wilkes for reviewing an early draft of this post.