The Anti-Waterfall Workflow
Tear down the wall between engineering and design.
One of the worries about a high-touch relationship between design and engineering teams is that the back-and-forth can create drag on a project. The fear that revisiting a design may lead to churn on the engineering team can often stop a designer in their tracks. That same fear can prevent an engineer from speaking up if they have a product improvement that wasn’t in the design specs.
The result of these mutually held fears is a waterfall workflow in which design makes a deliverable and then throws it over the wall to engineering. But that wall — even if it wasn’t constructed intentionally — is bad for morale and bad for the product. At Postlight, we strive to create a completely different environment — one that not only encourages early collaboration between disciplines but expects it.
We’ve seen how building with blended design and engineering teams from the beginning makes for better software and happier teams. Our team of designers factor in performance, and our engineers focus on user experience — an invaluable combination that leads to world-class software.
Anti-waterfall at the MTA
Case in point: In late 2019, the New York City’s Metropolitan Transit Authority engaged Postlight to build the messaging platform that would power the MTA — and fast. We needed to ship a lot of software for one of the largest transportation systems in the world, and we needed to do it in 120 days.
The engineering team began to grapple with the network of APIs, data formats, and endpoints that flowed into that messaging platform. Meanwhile, the product and design teams immediately dove into learning the current state of each MTA team’s workflow. As design interviewed MTA team members, we started to uncover a wish list for the new messaging platform and learned that helping riders understand why their train was late was just as important as targeting and accuracy.
We had assumed we would build a “Mad Libs” style of messaging that was data-driven and built for standardizing every message. But the MTA was searching for a consistent, tailored, and humanized voice that prioritized the rider’s experience and ensured that messages didn’t feel formulaic or overly automated.
That message also needed to transform across multiple outlets and be distributed to thousands of digital signage displays. Our engineering team understood complex data models and how every API call was contingent on time, location, and upstream conditions. The design team had to figure out how to take all the user journeys and map them into a cohesive system that would be intuitive to use but also robust enough to handle the volume and complexity of hundreds of targeted alerts and campaigns every day. To do so, the design team knew that every new idea needed to be vetted by a high-level engineer who understood they “why” behind the build.
Tear down the wall to build better
On the MTA project, close collaboration and genuine thought partnership between design and engineering opened the door for the brightest minds on both teams to help shape the product. Engineers are heavy-duty users of software and management tools by the nature of their jobs, and they give a lot of valuable design input. (There’s a reason there are so many project management software options!) And both engineers and designers are always focused on how to improve processes, so involving engineers early in the design process allows them to start uncovering areas of opportunity that could be obscured by technical complexity.
Throughout the project, our design team looked for ways to make the experience more adaptive to the way the MTA works today and sought opportunities to build efficiency into every corner of the app. That resulted in a great deal of rapid iteration after every user testing session. Our designers were able to easily have those conversations with engineering, and they were met with an empathetic response and open-minded attitude to every proposed change in spec.
Nearly every internal design meeting started with a sync with engineering to understand the current state of how the schema was being built, and the same was true for every internal design review where features continued to evolve. The anti-waterfall workflow wasn’t just beneficial to the software — we couldn’t have built it without close collaboration.
High-touch collaboration is a feature, not a bug
At Postlight, engineers validate design, and designers QA and improve what actually gets built. Nothing gets thrown over the wall and forgotten about. Designers leverage the expertise of our engineers to uncover any potential roadblocks and ship prototypes as early as possible. Engineers are motivated by building products that people use, not by purity of process or novelty of technologies. There’s a deep respect for the craft of product design from every engineer on our team — something we seek out when we hire.
The nature of building for the web has to be fluid; we’re constantly learning through building and using live code, and this blended-team perspective is what keeps our products nimble. That mindset truly pays off when we see users experience the new product with delight — and when our clients continue to evolve with their new product in-hand.
Postlight has always lived at the intersection of design and engineering, and we find the balance works well for us and our clients. If this sounds like your ideal working environment, we’re hiring!
Aaron Ortbals is a Partner and Director of Engineering at Postlight. Matt Quintanilla is a Partner and Director of Product Design at Postlight. Say hello: email@example.com.
Story published on Mar 17, 2021.