Today I did something interesting – I eliminated Sketch – a UI screen design tool – from two more places in our design team’s workflow. I didn’t do it because Sketch is a crappy tool – it is wonderful. We did it because it significantly encumbers the flow of information within our organization (and, in turn, creates more work, not less, for us).
Our fundamental goal within an organization that provides a product or service is to consume information about the world, craft an offering1)In business, an “offering” is the actual product or service that you bring to market. If our “Value Proposition” is to “help you get home safely, our “Offering,” might be a car service, present it to the world.
To the extent that we can keep these feedback loops tight, we can iterate quickly, but experience tells us that in large organizations, this can be tough. Why is that?
I’ve been trying to prune our process for a while now – I’m on a personal crusade against both the Microsoft trio2)Word, Excel, and Powerpoint which try to be “modern” with OneDrive but tends to cause a lot of headaches in reality and email. There is nothing wrong with these tools in theory – each it powerful in its own way as places to create and structure information. The problem is that they are relics of an earlier, less collaborative era – an era where one business unit crafted artifacts for the next.
Today, the most important aspect of business is the flow of information from the real world to an offering. Traditional tools3)and the Microsoft trio is the most pernicious create eddies in this flow. Little nooks and crannies where information collects, but does not easily pass from person to person.
After diagramming our workflow with a handful of junior designers in the room, we came to the realization that one of the biggest hindrances of information flow was, in fact, Sketch. Of the 3,000 people in our organization, only about 6 people (the people with Macs) could open a sketch file. It may be great pushing pixels, but as a collaborative tool even MS Powerpoint beats it!
Sketch is just a single tool, though, and removing it from a couple places in our workflow was only a small step forward4)We didn’t remove it entirely, it is still useful for creating a design language system and for a lot of visual design stuff. We’re just trying to get it out of the decision-making part of our process where it creates a barrier to effective communication across stakeholder groups.. Sketch is not the most pernicious eddy.
“Design” itself the most pernicious information eddy, at least in its modern manifestation – and Lean startup practices and agile software development are going to kill it.
How did design stop being a verb and start being an industry?
Despite paying lip-service (and selling a lot of books) to make Design more accessible, it is amazing to me how exclusive this world is. Design tools are highly complex and priced to inaccessible levels.
I believe the core of this may involve the shape that “thought leaders” in the Design industry give to the craft. Speaking about Design as a discrete process handled by experts makes sense to us – and many feel that the enemy of good design is when our process gets diluted by outsiders. In the past half century or so, we in the first-world west have tried our hardest to make the term “design” conjures up imagery of post-it note covered walls and a magical Stanford/HBR/IDEO supported vision of an elusive business strategy (or whatever) in the minds of middle and upper managers.
This has created essentially two meanings of design in modern vernacular. In the first-world west, Design has become some kind of magical unicorn where people learn about users and then draw pretty things. In the rest of the world, it means picking logos and drawing icons.
Both of these definitions have their value, but we must recognize them as different – having to diverge sometime in the late 20th century and continued that divergence toward this day.
If we look back to some of the most influential writers about “design” during this time period, though, we’d notice that they tended to use “design” in a third way – a way that meant simply “planning.” Many of them weren’t designers – they were engineers. The “design” they were interested in wasn’t a “role,” it was a process: the planning phase of the thing that an organization was going to create. They were interested in how these things came to being – how did humans go from nothing to something? What was the process?
In the corporation of the 20th century, the distinction between a “role” and a “process” didn’t matter a great deal. The paradigm was the Smithian pin factory5)Adam Smith, The Wealth of Nations, 1776. Widely regarded as the bible for the corporate elite in the west. Don’t read, but reference as often as possible wherein the division of labor was largely separated by function and these functions were arranged linearly from idea to money.
Most importantly, this process could be stretched over timelines that mostly could support Wall Street projections for investments of large sums of money in things and expected returns from big wins6)This is actually the same model that many silicon valley startups had in the 2010’s – see an idea, raise capital, sink money, try to win big. In winner-take-all markets like social media, this makes a lot of sense – having big war chest means you can out-bleed your competition. In non-winner take all markets, it becomes a bit more difficult to justify huge investments in early-stage companies, an ideas like “bootstrapping” and the “lean start-up” practices developed..
The problems, of course, was that there was a huge amount of uncertainty with this process. What if ideas were bad? Wouldn’t it be best if we had some ways to make sure that ideas were good before we sunk fat stacks of cash into them? So the process evolved,
…but not much.
Software developers call this a “waterfall” process. Each step in the linear chain must happen before the preceding step, but the steps themselves are largely independent.
The cool, and clean, thing about this model is that you can identify certain humans for each part in the chain.
Done, fill in the slots with the “best people” and you’re good7)Well, hire the best “HR” people so they can find the rest of the “best people,” then you’re good.. In a waterfall process, your part of the process is your role, and it is no matter if everyone has different ways to interpret information because you’re likely to be surrounded by a group of humans with a similar background.
In this world, our team would inherit a directive from the strategy, then we would go through “the design process” as a “design team,” then we would deliver those designs to the developers for production.
Sometimes staffing this is tough, though, so if you can’t get the right humans, you can supplement with consultants. With a modular model like this, inserting consultants is easy. Every type of consultant has her notch, but design consultancies traditionally played here too:
… but their version of the diagram would look more like this:
Over time, the IDEOs, frogs, Continuums, and others in the design consulting world started working their way up the chain toward corporate strategy. Others worked their way down the chain toward production and branding.
For the most part, though, everything was cool because the process was cleanly defined and the timelines were long. Everything was modular, and a company could decide to bring this part in-house or out-source that part based on the DNA of it’s culture, the opinions of it’s board, and whatever their buddies in the management consulting firm told them to do8)Between 2015 and 2020, we started seeing massive buy-ups of design firms as “design” started to be seen as a core competency that might be a competitive advantage, so best to have that in-house (if you’re a producer) or on staff (if you’re a management consultancy)..
Now, I know this all sounds arcane and a bit facetious, but this is exactly the workflow that most companies continue to encourage and everything from the software we use to our budget structures, titles that we hire for, accountability tracked, and annual board meeting cycles make such a process nearly impossible to break out of.
…but the lean people and the agile people…
Some years ago, I wrote on my linkedin profile9) or in my portfolio or something that I was interested in “the nexus of lean business strategy, design thinking, and agile software development.” To me, these things had a lot in common as they were all concerned with breaking down barriers within existing business structures to find better ways of producing market fit.
What I was starting to realize, however, was that there is a great deal of friction between the agile process and the design process. Nobody in my Scrum Product Owner or Scrum Master training could tell me how the design process was supposed to fit inside or interact with the agile process.
Before turning to the details of these processes, however, we need to look at the way these conflicting ideas think about their core jobs: mitigate risk.
Design vs Agile/Lean approach to risk.
In the end, both the design and the Lean/Agile approach seek to better find “market” fit. This typically means the private commercial sector, but can also mean crafting internal tools, or product output for government, organizations, or anyone else. In any case, these approaches seek to see if the things the team is working on will be adopted in the environment they’ve been crafted for.
Designers try this by creating artificial but holistic prototypes which enable a value proposition or an artifact to be tested in a fake environment early, but testing in the real world still lags behind a development schedule. This means that real learning has to wait behind that whole linear process.
Traditionally, this hasn’t been terrible because design was less concerned about what the product should be rather than how the product should be. Designers just assumed that the value proposition was true, and set about making something usable and beautiful.
This becomes a challenge, though, as design tries to work its way up the value chain in 21st century markets. Linear timelines are simply take too much time to go to market, and in many cases, businesses are becoming more humble about their ability to divine the future. Many are starting to question where “user testing” and various market research methods are true enough to mitigate risks for large investments.
The Lean Startup mentality recognized that ultimately Design is best for testing for desirability, and perhaps usability, but not the extent to which people would adopt an offering. Seeing adoption as the biggest risk, Lean created the idea of the “Minimum Viable Product” – a product that focused on finding the most compelling value proposition and iterating from there. Rather than envisioning a holistic goal, the MVP was ‘minimal’ so it could be iterated on quickly. Viability was tested through actual adoption – once a product was deemed viable, it could be expanded upon.
Ultimately, Design believes that something has to be thought about holistically before it can be tried in real life. Agile / lean believes that if the value proposition can be identified, an MVP should suffice to take the next steps.
Whether a team favors holism or fast iteration, fundamentally influences the direction that their process will evolve.
Different Philosophies: What is the goal of an increment?
Both systems offer an “iterative approach,” and in both, the iterations attempt to grow from a fundamental core toward something more robust, but that is where the similarities end.
The first iteration from the Design perspective should feel whole, but fuzzy. It may be a quick, low-resolution sketch, but it has to consider what a holistic experience would feel like. With this simulation, stakeholders and potential customers can respond and collaborate to suggest improvements. The output of a design iteration is, fundamentally, an artifact that can be used to facilitate collaboration and work toward a shared vision.
An Agile/Lean first iteration is minimal, but functional. Whether the product is “right” is determined less by the stakeholders and more by the market itself.
What progress looks like through each process also varies. In the design process, progress looks like increased fidelity – we start with an idea on a post-it, graduate toward a sketch, then a beautiful render, and finally some kind of spec document that can be consumed by an engineering team. On an agile / lean team, we go from idea to functional in a single increment, so in agile, progress means increased product scope with a new type of feature or functionality.
The design process, therefore, is linear, while the Agile process is cyclical. Each goes through cycles, of course, but the Agile increment starts with a backlog item and ends with some software with each iteration. Design on the other hand, needs to go through several phases of fidelity increases before it can be passed off to the next part of a linear value chain where someone else will create the functional version.
Since the output of a successful “iteration” is fundamentally different, design teams and agile / lean teams have evolved completely different approaches to ensure success.
Different goals lead to different processes
In theory, there is no difference between theory and practice. In practice, the differences are profound.
The tensions really start to manifest in the workflow. Each philosophy optimizes its process based on its goal. Design is concerned with holism, and agile/lean is concerned with flow. Divergent goals means divergent processes. To understand the core friction between these two processes, we need to think about “batch size.”
The concept of “Batch size,” and the roots of lean business strategy and agile come from Japanese factories (mostly Toyota) which needed to maximize output and also provide a certain amount of flexibility in the details of each produced unit. A “batch” represents the total amount of work that is currently “in progress.” Having a large batch of work feels good in theory, because it seems like a lot of things are getting done.
In reality, though, it tends to create waste. Every process has a bottle-neck step, and the output of the whole will only be as fast as that step. Improvements that happen anywhere other than the botteneck step will not produce more efficiency, and increasing the batch size often exacerbates the problem. In the manufacturing sense, a larger batch means store rooms and factory floors need to be bigger to compensate for inventory piling up because of the bottleneck point. In software development, it results in overflowing inboxes and pointless meetings where countless things are covered, few things are resolved, and most people can’t keep track of anything.
Agile and Lean get their flexibility, therefore, not from flexibility within the running process, but from controlling batch size so they can finish the process faster. They also repeat the same process over and over again, which gives them the opportunity to have meaningful reflection and improvement on the process itself.
Design is also an iterative-based process, but its goal of being holistic means that each step has an enormous batch-size. These batches are fine when things are at the sketch or post-it level, but they get out of hand as the fidelity of output rises toward the end of a project.
In reality, I’ve yet to hear a designer talk about “batch size” because in design, “efficiency” is rarely a primary concern. As a discrete part of a linear process, it isn’t a huge concern – particularly for the more expansive, strategic projects. For the “detailed design” phase of software projects, things tend to get a little bit grueling10)and designers start getting burned out as we find ourselves tracking consistency across hundreds of screens and states. Software like Sketch has been evolving as quickly as it can to facilitate this process, but it still gets overwhelming as we prepare for a big delivery.
I know the other medium articles don’t like to talk about this because it is so old-school, but MANY, probably MOST companies still use a linear process for these kinds of things.
Part of the reason is because the devs love it. They want to produce the thing quickly, and they know that people changing their mind is the largest threat to that – by having everything documented up front, their asses are covered and then can estimate the number of sprints something will take without having to worry about a “scope change.”
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 static11)like in-design, microsoft trio, etc… or tools that don’t scale well12)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 begin13)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.
Footnotes [ + ]
|1.||↑||In business, an “offering” is the actual product or service that you bring to market. If our “Value Proposition” is to “help you get home safely, our “Offering,” might be a car service|
|2.||↑||Word, Excel, and Powerpoint which try to be “modern” with OneDrive but tends to cause a lot of headaches in reality|
|3.||↑||and the Microsoft trio is the most pernicious|
|4.||↑||We didn’t remove it entirely, it is still useful for creating a design language system and for a lot of visual design stuff. We’re just trying to get it out of the decision-making part of our process where it creates a barrier to effective communication across stakeholder groups.|
|5.||↑||Adam Smith, The Wealth of Nations, 1776. Widely regarded as the bible for the corporate elite in the west. Don’t read, but reference as often as possible|
|6.||↑||This is actually the same model that many silicon valley startups had in the 2010’s – see an idea, raise capital, sink money, try to win big. In winner-take-all markets like social media, this makes a lot of sense – having big war chest means you can out-bleed your competition. In non-winner take all markets, it becomes a bit more difficult to justify huge investments in early-stage companies, an ideas like “bootstrapping” and the “lean start-up” practices developed.|
|7.||↑||Well, hire the best “HR” people so they can find the rest of the “best people,” then you’re good.|
|8.||↑||Between 2015 and 2020, we started seeing massive buy-ups of design firms as “design” started to be seen as a core competency that might be a competitive advantage, so best to have that in-house (if you’re a producer) or on staff (if you’re a management consultancy).|
|9.||↑||or in my portfolio or something|
|10.||↑||and designers start getting burned out|
|11.||↑||like in-design, microsoft trio, etc…|
|13.||↑||Though you should still keep someone on the team that can pick colors and draw icons|