From John Swartzwelder, a writer for The Simpsons:

But I do have a trick that makes things easier for me. Since writing is very hard and rewriting is comparatively easy and rather fun, I always write my scripts all the way through as fast as I can, the first day, if possible, putting in crap jokes and pattern dialogue—’Homer, I don’t want you to do that.’ ‘Then I won’t do it.’ Then the next day, when I get up, the script’s been written. It’s lousy, but it’s a script. The hard part is done. It’s like a crappy little elf has snuck into my office and badly done all my work for me, and then left with a tip of his crappy hat. All I have to do from that point on is fix it. So I’ve taken a very hard job, writing, and turned it into an easy one, rewriting, overnight. I advise all writers to do their scripts and other writing this way. And be sure to send me a small royalty every time you do it.

I don’t think it will come as a surprise to tell you that as designers, most of us have a tendency to overthink things (understatement). But something that has really helped me as I grew was recognizing that you have to get to done, first – and the sooner you get to done, the quicker you can get to done, well. If you have 3 days to complete a task, you can either spend 3 days working on getting it to done, or you can spend 4 hours working on getting it to done, get feedback, make it better, get more feedback, and make it really, really good.

there is a vast difference between

“we’ll figure it out as we go” or “here is the detailed step-by-step plan”
-vs-
“we’ll have a loosely structured plan of approach that can adapt as we learn new stuff.”

I like to use a road trip analogy for strategic project planning. YOU HAVE TO KNOW WHERE YOU WANT TO END UP. This is the one thing you absolutely need to know before you start. There may be road construction you didn’t anticipate, or car trouble, or bad weather, but as long as everyone in the car knows where you are headed, you can work together to find an alternate way to the destination.

So many of the project challenges I see essentially feel like a road trip where everyone is so concerned about the right snacks and a great playlist that they completely forget to talk about where they are going and why they are taking the trip.

So...do you know where you are going?

I’ve been thinking lately about the impact of being asked, year after year, to define the “ROI of UX”.

Early in my career, this was never a question asked of me. For decades, working in “tech” meant working in enterprise software. There were no smart phones, so there were no consumer apps. (For a long time, there was no GUI!) Software companies competed based on features.

Then, things started changing. Feature parity started happening and smart phones popped into existence, and all of a sudden, the competitive differentiator was user experience. (You have likely heard the phrase “consumer grade experience” applied to business software). The need for our work was clear.

But organizational memory is INCREDIBLY short, and the best UX work is often invisible, by design. So, when you do your job well, it seems like there isn’t much value in it. Hence the push for us to define the ROI of our work. (sidebar: Have you ever heard an executive ask a development team to define the “ROI of code?”)

I think some of our industry grief right now is the absolute weariness to have our value, our worth, constantly questioned. Because UX is the type of work where the value is recognized only in the absence of great work, not in the presence of it. That would drain the joy and the hope out of anybody. I cannot even imagine what it is like for people who experience this questioning of their worth outside of work as well.

We have to change the system, not our attitudes.

Some time ago, I was having a discussion with a few other “people who sometimes give talks at conferences” (don’t want to call us “speakers” because none of us make any money from these talks and we support ourselves through UX jobs) and we were reflecting on past talks, and what, if anything, we’d change about them now.

And the first thing I said was how much I regret the advice to assume good intent (in my collaboration talk). I was spouting off trite, common advice without really considering the place of privilege I was speaking from. Upon reflection, I now view that advice in direct conflict with human-centered design goals: focus on the outcome, rather than the output. It puts the responsibility for managing harm on the harmed, and doesn’t leave an avenue for gentle (or when needed, not so gentle) correction, which is the only way the one who harmed can have an opportunity to grow. I believe providing that growth opportunity is a gift and a responsibility, and choosing to accept that gift gracefully is one of the strongest acts of community, and of hope.

As a manager, the most consistent challenge I see with early-career designers is the belief that with enough research, with enough information, with enough bench-marking, whatever, there will be a clear path forward. So they get stuck when they have limited information, when the path remains unclear. The default instinct is to continue gathering information, because it’s really uncomfortable to “start design” feeling like you don’t have the full picture. (required disclaimer that research is good, important, and necessary, I identify as a researcher myself)

But it is so often the act of making itself–making not-quite-right things and even making outright wrong things–that provides the most direct path to clarity, to understanding the right next step. Design is the act of creating as a thought process, as research, as a tool for discussion, alignment, and direction. (another disclaimer: this requires a safe environment to do this and strong feedback loops.)

I go back to my oft-referenced example of the game Wordle. When you are starting out, all you know are the constraints: 5 letters, 6 chances to guess. There are literally thousands of possibilities. The ONLY thing you can do is start with a word, often a strategic one, and then use the contextual cues to limit the possibilities and make a better, more informed choice for the next guess.

One thing that often doesn’t come up in discussions about design fidelity is the need to layer decision-making. If you start the process with high fidelity mockups, you are essentially making all different types of decisions at once: decisions about creative vision, information architecture, flows, and content. It is almost impossible to get clear feedback in that type of situation.

In my experience, breaking the design artifacts down in a way that allows the team to align on one aspect of the broader design approach makes the entire process more manageable and encourages better decision making.

This doesn’t necessarily mean wireframes. It could include things like:

• brand messaging architecture to identify tone and creative vision
• content model to identify structure and priority
• style tiles or mood boards to explore visual brand identity
• etc

Each decision creates a healthy constraint for the next layer of exploration. Then, by the time you get to the high fidelity mockups, the majority of the high level decisions have already been made.

I could say a lot about particular delivery frameworks (SAFe, SCRUM, lean, etc.), but I think in general, the key questions to consider in evaluating their effectiveness are:

Are you looking at your desired project outcomes and using that to determine the best approach to support those outcomes?

-or-

Do you begin the process with an approach and all that comes with it, including potentially limiting or constraining the types of outcomes you can achieve?

friendly reminder that you tend to get much better outcomes (including a happier and healthier team) when your process adapts to your context rather than vice versa.

In my new talk, I share that I like to think of ideas as promises. The word “promise” holds dual meanings, each of which is equally valuable AND necessary to deliver positive outcomes.

To hold promise means to have the capacity for excellence. To make a promise means to commit to follow through on that excellence.

A great idea is only one half of the equation. The ability to execute on that idea, in a way that’s viable (and sustainable for the team), is just as critical to success. Making sure your teams have the right support, tools, and skills to balance both sides of the equation is where the magic happens.

If a team is struggling, I’ve found it REALLY helpful to figure out on which side of the equation the challenge lies before I make any recommendations for improvement.

(hint: it’s almost never on the “capacity for excellence” side…)

If you struggle to understand the very direct relationship between mistake tolerance and creativity, I often reference Wordle (and similar games) to demonstrate this.

How would your approach (and attitude) change if you only got one guess? How about two guesses? How often would you win? HOW OFTEN WOULD YOU PLAY?

How does knowing exactly how many guesses you get direct your strategy? How would that change if you got a different number of guesses each time?

How much more cautious (and anxious) do you get when you are at the fifth or sixth attempt and still essentially guessing? How do you rethink your previous attempts at that point – what do you wish you had done differently?

What is the relationship between your time to achieve the task and the number of mistakes you are willing to make? How would your strategy change if you had no limit on mistakes but a hard limit on time to complete? (fun fact, I play six different word games every morning, so I think about this one a lot)

How valuable is the process of elimination (identifying which letters you know are absolutely not part of the solution) towards solving correctly?

How willing are you to be intentionally wrong in order to get closer to being right?

I got 99 problems but components ain’t one (with respect to Jay-Z).

I worked on my first design system back in 2006 (as a point of reference, the original iPhone launched in 2007, and the first iPad in 2010). At the time, I worked for a large enterprise software company with just a handful of UX team members and a huge product catalog, built exclusively through acquisitions (which means different branding, different tech stacks, and different cultures). It took almost 10 years and multiple design system attempts (and failures) before we finally started gaining traction with design system work. I discussed my experiences in my 2016 talk Taming the Enterprise, where I shared the root cause for our early failures, as well as our eventual success: our ability (or inability) and willingness to communicate and collaborate across teams and disciplines. None of our core issues were caused (or solved) by tools or technology.

I’m back to design system work again, this time as a consultant. Despite the speed of evolution in the digital space, including the influx of new tools and libraries, it feels like not that much has really changed.

I took to LinkedIn and Twitter recently to ask the following question:

“When a design system project fails to deliver on expectations (whatever those may be), what have been the observable failures or issues, and what do you think are the underlying causes of those issues?”

The responses I received aligned almost perfectly with what I saw back in 2006, back in 2016 when I wrote “Taming the Enterprise”, and now, in 2023, when I’m back into the design system space.

So, what are these patterns of failure?

1. No shared (and contextual) sense of purpose
2. Overbuilding, or scaling too early
3. Inability to make decisions and move forward quickly
4. Lack of clear ownership and dedicated resources
5. Lack of cultural alignment

Let’s explore each of these in more detail.

No shared (and contextual) sense of purpose

Amy Hupe gave a great talk at at the 2022 Clarity Conference titled “Down with Design System Dogma.” She emphasized the importance for a team to align on the purpose of a design system before creating outputs, and she pushed us to think beyond the most commonly accepted promises of a design system: consistency, efficiency, and scale.

Consider what is unique about your organization, your teams, your products, your challenges and opportunities. Answers to the following questions can help you surface that unique contextual purpose:

1. What prompted the decision to invest in a design system?
2. How do you anticipate the design system changing the way your teams work together and deliver products to your customers?
3. What are your product OKRs/KPIs, and how will a design system help your teams achieve those goals?
4. How should the design system affect the user experience of your product?
5. How will you measure impact and make continual improvements?

And, after you have the answers to these questions, it’s important to consider this final question:

Are your expectations of the design system realistic?

For example, a common “purpose” I hear from teams is “improve the UX of our products.” I’m sorry, but that’s essentially meaningless. However, if you can describe what an improved experienced might mean to your customers, how it will change their behavior, and the impact those changes will have on your organizational bottom line, then you get closer to your purpose.

I like to think about design systems not as a set of components, but a collection of decisions that have been formalized (and ideally validated). Clarifying purpose helps you prioritize which decisions to formalize. Then, by formalizing those decisions, you eliminate the small decisions a team has to make and the recurring problems they need to solve for, which provides more space and creative energy for the big decisions and unique problems. That’s how you improve the UX of your products.

Overbuilding or scaling too early

A common recommendation among design system enthusiasts is to treat your design system like a product. By this, they usually are referring to a dedicated team (more on that below), continual evolution based on feedback, etc. And that is correct.

But those things are for existing products. We rarely talk about how to validate the approach and investment prior to committing to a full scale design system. The cardinal sin of product is to build without validating first. What might an MVP of a design system look like? How will you will validate with your users —the product teams using it to build and deliver?

One of the problems we see is that what works for a small, focused team does not work at scale. Many design systems begin with developers trying to improve efficiency and consistency in their own jobs. When that work is successful, the organization seeks to expand usage of the design system, perhaps to other products or teams. Without a clear understanding of how other people will interact with the system, and a shared language and vocabulary to talk about the components and how they work together, the design system stops being a SYSTEM and starts being a mess.

Karen McGrane

The most successful design systems often start with grass roots efforts at an individual team level. But in a desire to leverage that success more broadly, organizations often jump to immediately scaling vertically—make the design system bigger and therefore more complex to both use and manage—before considering what is actually relevant to other teams and scaling that horizontally. Identify your lowest common denominator: the smallest set of shared decisions and resources that can provide value across all teams. By using a small, experimental approach, transplanting approaches from one team into another, and then observing results before scaling further, you can better identify what ideas hold the most potential for being systemized across all teams.

There is a misconception that a design system can only provide value if it is comprehensive, covering the majority of use cases your teams may encounter. Consider the Pareto principle, aka the 80/20 rule. A design system that supports the right 20% of the user experience can drive 80% of the business outcomes, if you have carefully considered the questions about purpose outlined above. A small, iterative approach also allows you to design components (and other resources) in-context, introduce changes to users slowly, and incorporate both internal and external user feedback when it can still be impactful. Even more importantly, starting small and iterating in small increments helps you validate your investment at each step of the way, exactly how good product work is done.

Inability to make decisions and move forward quickly

Call it lack of urgency, analysis paralysis, or even navel-gazing (a term that came up many times in my discussions), a lack of an explicit decision making structure and cadence often makes design system projects stretch out much longer than they should.

Too much focus on quality over impact, or obsession with tools over impact. I’ve seen teams spend way too much time building systems — years —and never get them finished.

Mia Blume

Yes, there are important decisions to make when building a design system—but not all decisions are of either equal importance or urgency.

For example, I’ve seen, many times, design teams agonize over selecting the “right” color scheme and fonts for a design system. I’m going to tell you something: once you account for accessibility, readability, and appropriate levels of contrast for visual hierarchy…it doesn’t matter. Some of your users will love what you choose, and some will hate it, regardless of how attached you are to it.

This affects more than just time to deliver. Decision fatigue is real. When you treat all decisions of equal importance, you don’t have the appropriate energy to devote to the truly important, impactful ones.

A few things I recommend to teams:

1. Decide what is important to your industry, product, and team. Impact looks different for consumer vs. enterprise apps, for example. Design for your context, not anyone else’s. What 20% of effort will drive that 80% of value for you and your customers?
2. Plan the project so decisions are stacked: each big decision lays the foundation for the next decision to come.
3. Be patient with moving slowly at first; trust that momentum will build as you layer these decisions. Starting slowly but thoughtfully will end up getting you good results faster in the long run.
4. Set a process and timelines for decision making. Time box discussion, then make the call.
5. Build in small increments so no one decision carries too much weight.

Lack of clear ownership and dedicated resources

Going back to “your design system is a product”—I bet you don’t expect to deliver quality products with scattered, part time resources. And yet, that is exactly how many orgs treat their design systems. Rather than having a few dedicated team members with clear ownership (which helps greatly with decision making), a large group of people randomly contribute small amounts of time in bits and pieces.

I’ve seen teams fawn over the idea of a design system but don’t have a team in place to develop and maintain said system. Often what happens is that the champion for the system is also a key part of another product sector or project and has to create and support it as a part-time gig. It then gains traction and interest but the company or agency isn’t in a position to staff a full time design system project with design, engineering, and product management.

Josh Franklin

Note, if you start small, you don’t necessarily need full time resources, you just need consistent resources who are aligned on purpose of the work and empowered to make decisions for the organization.

Bottom line, not only does product delivery require resources, it requires investment and engagement, and that comes from dedicated team members who are accountable for the metrics of success. When everyone is responsible for the work, it often ends up that no one is actually accountable for results.

Lack of cultural adoption alignment

One of the most common success metrics of design systems is the concept of adoption: the level at which product teams have fully (or partially, or sometimes not at all) adopted the design system into their products.

The big problems with design systems are all cultural, and often under the hand-waving heading of ‘adoption’.

Margot Bloomstein

This focus on adoption frames the problem from the wrong direction. In Taming the Enterprise, I said that “every organization is a special snowflake of dysfunction.” By that, I meant that there is no perfect environment or culture; best practices are only best when they align with how your teams already work (or at least how they want to work).

Rather than cultural adoption, I’d encourage teams to focus on cultural alignment. Whatever you build, it should align with the organic culture (both the healthy and not-so-healthy parts) of the organization and the design, development, and product teams that are the eventual users of the system. Consider what challenges you are currently facing, what needs to change about how your teams are working, and how your design system effort can support that change (all questions you should already have answers to if you defined your purpose). Lean into what is already working well across your teams and start by systemizing that good work (and formalizing the informal ownership and contribution models). Even if it doesn’t align with that book you read, that tweet you saw, that talk you loved. Yes, even this article!

Conclusion

The common thread among these issues is that none are related to technical or tooling decisions —or even to the components themselves. This work is not easy: organizations have to balance the risk of under-investing in design systems (and getting left behind) with the risk of over-investing before they’ve identified a contextual purpose and strategy. Luckily, there is a great way to surface those risks, and identify the best ways to mitigate them. Using service design early in the process can provide a clarity of context and a vision of how the humans who build and adopt the design systems (and who use the products of those systems) can successfully interact with that system.

By applying the same level of intention and best practices to design systems as we do on our external products, we are much more likely to build design systems that actually meet the needs of our organization, its culture, and its internal and external users.

Since we’ve all been doing a lot more cooking at home, and some of you have likely experienced some kitchen disasters, I would like to present to you a parable about the different ways to address failures on projects, aka When There is Smoke, There is Fire.

When it becomes apparent that a project is struggling, that is the equivalent of the smoke detector going off while you are cooking in the kitchen. There are three typical responses to this:

1. First, remove the food from the heat source to eliminate the problem, then figure out what went wrong and move forward with this new information to do better next time. Almost always the ideal response. Dinner might not get served, but everyone is safe. Rarely happens.
2. You can also turn on the exhaust fan to disperse the smoke. This doesn’t directly address the source of the problem, BUT it can be an appropriate response when you are cooking certain types of food. Some foods naturally generate a lot of smoke because they have a lot of fat. If you are going to cook, say, a big fat porterhouse indoors, you have to expect smoke and be prepared for it. You can also open some windows (preferably before you start cooking) to help.
3. Finally, there are many, many people who just take the batteries out of the smoke detector. This clearly removes the annoying beeping but also eliminates the ability to warn of danger, and things will get worse and worse until you find your entire kitchen engulfed in flames. (delivering something – ruining your reputation)

(there is yet a fourth strategy which is to just run screaming out of the house, but that is usually reserved for spiders and that’s a whole other analogy.

Figure out what your smoke detectors are on projects. Make sure you have fans and open windows for high risk projects. So many “leadership strategies” are the equivalent of removing the batteries from smoke detectors. They simply suppress feedback while increasing risk.

A question on design twitter prompted me to create this short list of the things that ultimately helped me navigate a career in tech and design.

1. Understand that the bulk of your work is actually about understanding human behavior and not about any specific tools or deliverables. Direct your energy appropriately. Tools are going to change, human behavior not so much.
2. It’s fine to pay attention to what Design People are saying on the Socials, but always be suspicious of anyone talking about My Great Method or Tool or Framework that Fixed All the Things. Especially if they are benefiting financially from a specific approach or viewpoint. (You eventually learn in this business that there are people who make their living from doing the work, who occasionally talk about it, and then there is a whole category of people who make their living by talking about the work, while rarely actually doing it. Direct your attention appropriately.)
3. Keep project journals. Use whatever format works for you. Document your expectations, the things you tried that worked, and those that didn’t, your progress, the pivots you had to take and how you felt throughout the process, what you’ll do differently next time.
4. Encourage your team to do regular retros if they aren’t already. This allows you to learn from what your team is learning. If your team isn’t doing this and you don’t have this level of influence, do retro-style research on an individual basis with friendly team members. (The exact format of the retros matters a lot less than the practice of doing them consistently, with one exception: don’t let them devolve into bitch sessions. There’s a time and place for venting but this isn’t it. This is for learning.)
5. Start thinking about what it means to deliver value instead of just thinking in terms of deliverables. This is a huge topic you can explore, and expand your education to professionals outside of design (particularly those who are doing product management well).
6. When you get stuck, reach out to someone else in the field and see if you can hop on a call to talk it through. They don’t have to be more senior than you. Being forced to articulate a challenge to someone else, who understands the type of work we do, will give you clarity.
7. The work is messy. Get used to it. Look for mentors, virtual or IRL, that openly talk about the challenges of the work and share their failures. (This ties to #2 above: be suspicious of professionals who only talk about success and never mention failure. Failure in this industry is a feature, not a bug.)
8. There is no one right way to do this work. Don’t worry about what Current Tech Hero Company is doing. The experiences and feedback of the people who use your products/services and your teammates are your most important benchmarks of success.
9. The number one metric of success is how healthy your team & projects are. Nothing else matters if everyone is miserable. It doesn’t have to be that way. Designers are often the canary in the coal mine when it comes to declining team health. Take care of yourself.