Are design solutions really solutions?

So fundamentally, these processes are different, but as long as we can keep the Design phase discrete from the production phase, we’re fine. We can optimize our tools to make cascading changes through design outputs easier, and more sensible organizations can use a wiki for documenting that information rather than something static((like in-design, microsoft trio, etc…)) or tools that don’t scale well((like Zeplin)). A modern tool set and better collaborative practices can make it easier for design teams to function so they can produce higher quality, higher fidelity, and more robust design artifacts faster.

But before we set about optimizing an old process, we may consider whether this is really a worthwhile effort. Is creating design artifacts faster and organizing them better really the answer? From a lean perspective, this would be like building a bigger warehouse for all of this excess design inventory.

In the end, it doesn’t really matter which process we like better. There is an expectation for faster time to deployment, so the process that we need will be the one that drives success of the organization’s mission.

What process should we be trying to optimize for?

The verb, “design” will always be a part of the production process, but the role “designer” and the “Design Industry” are products of 20th century business structure that needed to implement at scale with long timelines and large batch sizes. Today, it is becoming less and less apparent that this is a recipe for success.

I believe we can expect 21st century production processes, and business processes as a whole, to look much more like the tight feedback loops of Agile and Lean than the long linear process of yesteryear.

The Lean Startup process was developed for strategy problems, Agile for development workflow, and design for planning. If we were to try to map these processes with the linear business approach, it would look something like this:

We wouldn’t map it this way, though, because it wouldn’t make sense. Lean is meant to be holistic in a business-sense – concept to reality in a small, fast increment (“mvp”), then scale up over time. The Agile process nests perfectly as the production engine for an agile enterprise.

But where does the design thinking go? Where do the “designers” fit in? Technically speaking, product definition still happens, but it happens in a tiny, fast, and minimal way as a part of the increment rather than a holistic strategic mandate.

Rather than a long “discovery” process where a centralized team attempts to define a holistic scope, definition happens in short bursts. This enables learning to respond to actual markets rather than simulated user testing.

In a world that requires faster time to market and, the future of design (the verb) is not conducted by specialists in studios with their own, unembedded process – the tendency of these practices to form eddies of information is simply too great a risk. Design has to be embedded within the lean cycle.

Design Process? Design Thinking? Designers? You don’t them anymore. At least, not in the old sense, you don’t need some humans with the “role” of designer that laboriously interview stakeholders, make high-resolution artifacts, and spend time doing holistic storytelling to executives before the production can begin((Though you should still keep someone on the team that can pick colors and draw icons)). You can’t have them, because the process takes too long and focuses on simulation-based-projections rather than real-world validated data.

The shape of learning changes. When things are in the real world, our ability to collect data to better inform the next decisions changes. This pushes the importance more toward the streamlined flow of information rather than holistic visions.

To learn quickly, we have to ship quickly. To ship quickly, everyone takes on the “task” of of crafting the agile team as a learning machine – the task of designing the next iteration has to be informed by and deeply embedded in the process of gathering feedback and turning that feedback into the next strategic product iteration.  Anything that does not contribute to the flow of information into and within the organization – the titles people have, the tools people use, and other attempts to compartmentalize a part of the flow – should be modified or abandoned.

So we’re all going to be unemployed?

This isn’t to say that today’s designers will be unemployed tomorrow – simply that our titles will fall away. Many of the skills we have – the ability to understand feedback, visualize information, moderate discussions, and quickly generate ideas – will still be useful in this new world. We must recognize, however, that days of the hallowed designation of “designer” are numbered.

A good team tends to have people that are strong in different areas and a lot of overlap in the middle. Some designers will lean more toward the production side of things, and concentrate on the craft of the next iteration. Others will focus more on the interpretation of data – creating strategies for taking in information and understanding how to shape it into a plan for the next iteration.

The key is that all of these team members will be a part of the same team embedded within the iteration. This keeps information flows between the interpreters and the builders tight. It means that those with a background in engineering can learn about how to best position a product strategically, and those with business backgrounds get a sharp sense of how to bring a product to market quickly. As engineers learn what business strategists are looking for, they can suggest (and build) solutions for quicker data gathering and analysis. As those with subject-matter backgrounds learn more about engineering, they can better plan information gathering approaches over longer-horizons without sacrificing short-term improvements.

None of it is easy, but by orienting a process around smooth and fast flow of information rather than titles, roles, and artificial internal deliverables to be consumed by other parts in our linear production chains – we can all ensure that the efforts we put in day to day have more meaningful outcomes.

For more on this topic, I’ve put together a reading list on the next page.