Why some of my favorite designers are engineers

Or, how I learned to stop sweating the details and love the agile process.

The organizational shift from waterfall-style software development to embracing agile methodologies left some designers in a quandary. How could one create a stunning, innovative, cutting-edge, delightful, remarkable, and thoughtful design without toiling over the minutia of each design detail from the silo of the-other-side-of-the-wall? What, we’re supposed to throw a design together and work to improve it over time? After customers have already seen it? Before it’s done?!

Agile software development is a team sport. No, not “team” like a relay race, where everyone does their best during their turn to run and then hands off the work to the next person who will hopefully carry it over the finish line. More like a rugby team. I mean, they call it “scrum” for a reason.

Plans

The reason I say “Some of my favorite designers are engineers” is because like rugby players, an individual can be well suited and trained for playing their position but that doesn’t exclude them from having innovative ideas about how others might play to bring that W closer to reality. A bit of pre-game brainstorming can net a wealth of ideas from the entire team based on the myriad of variables and challenges before them. Many of the engineers I’ve had the pleasure to work with have the unique ability to look at all the information available and formulate a plan based on action. They want to build something.

When paired with a product designer who uniquely understands the design process, they can plan quickly and get to the building quickly. That’s the magic of an agile product team. They’re fast because the planning and the building are done as a team while overall, everything is kept flexible to allow for quick pivots in the face of each new challenge.

Good Enough

As a designer, the first time I was embedded in an agile product team, I kind of freaked out. “How am I supposed to paint the boards as they’re being nailed together?” You see, I was used to being the planner. Historically it was design and project management going back and forth, considering the many facets involved in reaching the goal, drawing up the specifications, and tossing the well-meant instructions over the wall to be built according to said plan. This is the way.

We stuck to this process even though inevitably, at some point during the building process an engineer would show up with information no one else had, asking a question no one else had considered or had a feasible answer to, bringing forward momentum to a standstill while the design was reevaluated and corrected. Plans changed even though our process made it awkward and somewhat painful each time they did. Agile methodologies taught me that sometimes “good enough” was indeed enough. It brought out spec-destroying questions before changing the plan became painful. It left details like finding the perfect corner radius or the most delightful color of blue to be sorted out after we had more context.

And testing, well, testing became a pleasure of its own. I was surprised at how little “finish” a customer needed to tell us they did not in fact find our design delightful. Together we were learning more, and faster, thus we moved faster even with the unknowns and inevitable corrections.

I Think I Love You

When my product team added an amazing Scrum Master and uber-knowledgeable Product Manager it took our abilities to the next level. As a bonus, the engineers often had amazing ideas for the design of our product and I found out that applying design thinking to engineering challenges could yield tremendous results. Why would anyone ever want to build software any other way?! The more successful sprints our product team completed, the more we gelled together and the better our win streak became. When we didn’t manage a win, we learned and grew even more. I loved designing with engineers, dare I say slightly more than designing with designers.

It’s the engineers' bias toward action that makes the difference for me. They have no qualms about throwing a completely unstyled heading, text, input fields, and a button onto a page to move the ball forward. Similarly, they don’t see the need to pass the ball laterally or even backward as a setback when done with such a minimal investment. Your team is learning more sooner, so who cares? There’s always time to fret over the details when you know more and have less to lose. Add a well-planned design system and even a team’s rough work can look polished.

Running Down A Dream

During an agile sprint, much like a rugby match, you’ve got everyone running this way and that way, attacking, defending, tackling, and passing. The team is actively coordinating and working together to move the ball forward, get points, and avoid penalties. Sure, each player has their own position but it’s the active planning, collaboration, and improvisation between them that makes the magic. As the saying goes, “Teamwork makes the dream work”. That dream being a win both in rugby and software development.