A call for tighter design in the software development process
“Hire more designers, okay?”
That’s the call from John Cutler, who, in a recent video presentation, urges software teams to embed more designers into software teams as they grow. Cutler illustrates that as software development teams are formed, they will, at some point, incorporate a designer into the process to assure the application is as user-friendly as possible. They may bring in one designer during the initial phase, who works closely with each iteration of the product.
Of course, the product gains traction, and more developers get added to the team. The single designer “has his hands full, but he’s able to manage if he has a sense of what is in the to-do list, he’s able to juggle how he spends his time and energy.”
But then “it becomes hard to operate as a team of eight developers so the team splits into two teams of four,” Cutler says, noting that the changes in the process will be subtle at first. “He now has to go to two stand-ups and the other shared meetings. He also has to scan two boards for their respective to-do lists.”. As more developers join the effort, the designer’s schedule gets even more hectic, and “he is tempted to get upstream and grapple with and finished design work before handing off the work to developers.” The designer ends up playing “Tetris” with software release schedules, Cutler observes.
The key is not to let design get marginalized in the software development process, Cutler says. Increasing designer headcount is one approach. In addition, “visualize the whole system,” he advises, noting that a deep evaluation of the way designers and developers collaborate is essential. “Efficiency and output probably isn’t your problem. Adding developers won’t help. Prettier pixels will probably not help. You need to make better product decisions. Designers empowered to do research and discovery, along with enough designers to embed on teams will help with that. We want to learn faster we don’t want to add more complexity.”
The need for well-designed software casts the spotlight on the emerging practice of “DesignOps,” In a recent post, Nick Babich defines it as “an attempt to operationalize design… to establish a highly efficient design process that generates high-quality design outputs.” Babich echos Cutler’s observations on the challenges of ever-more complexity in software delivery. “Introducing a DesignOps role is not only a structural change, but it’s also a cultural shift,” Babich states. “Our understanding of the design process matures, and we no longer want to segregate different teams. Instead, we want designers, developers, researchers, and other team members working together during the design process, and the DesignOps team is the one who makes this happen.”