A detached design system team is risky as hell. Mainly because the symptoms of being cut off from the systems users tend to lag. Once the symptoms begin to show, it can get real bad, real fast.

That’s why design system teams put in a considerable time trying to limit disconnection. Here are the stages of engagement I’ve typically seen:

First stage: Connect with everyone all the time The team attempts to join every crit. They check in with every person. Their existence is a meeting. Welcome to Burnoutville. Population, you.

It’s not rocket science to conclude embedding into consumer teams improves connection. It’s also not rocket science to conclude that does not scale. At all.

Second stage: Connect with everyone some of the time The next logical conclusion is to meet on demand. That’s a no-brainer, right? In my experience that doesn’t work out too well either. Calendars and schedules fill up and needs typically don’t give a two-week notice. I’ve seen this model atrophy as people become unavailabl. The habit trails off–because the process isn’t habitual. Ad hoc becomes no hoc.

Third stage: Retreat to the fortress of solitude The next conclusion is to remove the touch points altogether. Asynchronous communication becomes the primary method. That’s far and away the most cost-effective approach.

But just because something can’t be measured doesn’t mean it isn’t meaningful. Efficiency comes at the cost of connection. Collaboration can wither. It’s not inevitable, but it’s easy to lose touch as a design system team without explicit collaboration.

How about the right people at the right frequency?

Design systems at even moderately-sized companies have to be choosy about engagement. There’s too many people to have deep touch points with every single person. It’s not personal, it’s math.

It’s a vibe-killer to say that some people’s opinions are more valuable than others… But it’s true. Your doctor’s diagnosis for that rash that won’t go away is way more important than some dude in line for coffee. It feels nice for everyone to have a voice. Design system teams have to prioritize the voices with the right context. That’s not to say others should never be heard. But proportion is important.

Who matters the most? That’s up to every team to decide. I don’t think it’s all about seniority. The qualities I look for engagment, commitment and a strong point of view.

The more focused the group is, the greater chance some real collaboration can occur. Especially if the people collaborating actually want to.

Now let’s name it something fancy to make it sound important

I’m not a fan of marketing, but I also am not naive enough about the allure of a fancy title. People are gravitate to the allure of status. Now, that can be bad. You don’t want people joining just to add another corporate merit badge to their collection. But it doesn’t hurt to give this role a little bling to get people’s attention.

This better be worth everyone’s time

Ain’t no one has time for nothing no more. Ambassador programs need to have a high bang-for-buck return. It’s important to bias towards adding the least people for the least time for the most return. Not mind-blowing, I know.

Roles and responsibilities for each side need to be simple, clear and actionable. I have some real mixed feelings about RACI/DACI tables, but this may be a good time to make one.

These meetings better be the crispest and leanest ones the team runs. I’m talking agendas, pre-reads, meeting notes, action items. All that. Hell, with any luck, most meetings end early. Keep it short, simple, productive and (ideally) fun.

Each side needs to get something they want–but otherwise can’t. And make no mistake, there’s no shortage of want. Let’s cover the classics:

Feature teams want support and influence

The people who use the design system obviously want it to support what they’re working on. That can be hilariously hard to predict ahead of time. On Monday, a team thinks they don’t need a new component. On Tuesday, they do. Immediately. Design system teams can’t pivot that quickly. In large part because it sets the expectation that every request will happen that fast. But, maybe exceptions are made for teams that with ambassadors… That can be an enticing incentive.

Hopefully, most support isn’t of the “need it yesterday” variety. Less urgent asks can be made during planning cycles. Knowing that a needed component/pattern will be ready ahead of time can be a huge relief for feature teams. Ambassadors can help steer the design system roadmap to ensure what they need makes it in. That can also be an enticing incentive.

Teams also want the system to work for them. Maybe the type ramp isn’t quite handling their needs. Or some button variant needs tuning. Ambassadors have the ear of the design system team to steer the direction to better meet their needs. Granted, not at the cost of other teams’ needs. But it nonetheless gives them a direct line to the people who make system decisions. Also tempting.

Design system team want visibility and feedback

Anyone who’s worked on design systems knows how important visibility is. It also feels impossible to get. Having a view into all in-flight design work before development begins is priceless. System teams can get that information from ambassadors. They’re the window into all team-level happenings–without having to join every team crit. That’s gold.

Speaking of visibility, design system teams often struggle with having their comms seen. This isn’t surprising given the flood of information that teams are pelted with. But ambassadors represent a liaison to an org’s collective ear holes. Simple design system cascades from team ambassadors can raise awareness significantly.

Then there’s feedback. Design system teams are often starving for input on new/improved components. Getting eyeballs from feature teams can prove to be a herculean feat. Ambassadors can be that reliable input that’s so very needed.

Why not scratch each others’ backs?

The arrangement laid out sounds transactional. Because it is. I don’t think that’s a bad thing. Corporate altruism is self-contradictory. It doesn’t mean people don’t want to work together, but it requires mutual benefit. That’s why, any ambassador program needs to be scratch both backs.

This tracks at the individual level as well. Expecting volunteers to put in time on top of all their other work is a recipe for low participation. I’m a big believer that there needs to be some carrot for anyone putting in the time. Fancy title aside.

The carrot may be a prerequisite for promotion past a certain level. It could be a yearly bonus. Or something else altogether. But extra work should come with extra compensation.

Will ambassadors solve poor cross-team collaboration. Hardly. But it can be a good start. Like most things, finding the right balance between competing factors is the key. But hey, you might like Burnoutville–who am I to judge?

There are few things more impactful than good planning. Planning isn’t all that different for design system teams. But I do think is plays a more important role. Design systems are playing with a different time scale than feature teams. Systems think in years whereas feature teams focus more on immediate outcomes. Feature teams are most autonomous in their focus. Design systems thrive on connections.

It’s those differences that’s made me such a stickler for planning within a design system team. I’m no expert at planning. It’s been one of the most humbling rituals I’ve had the “pleasure” to be a part of. I’ll be in learning-mode until the day I stop working. This post doesn’t have absolute answers. I’m writing this because people in design systems don’t come from a planning background. But we’re on the hook to deliver one nonetheless. I’m hoping this may help someone that’s heading into their first planning cycle.

No one can/should tell another team how they should choose what to plan or prioritize. Especially me. The purpose of this post is focus on _how organizing and constructing your plan.

Things I’ve picked up along the way

I’ve learned a lot about planning. The hard way. Not all lessons learned are correct. Your mileage will vary.

Define work around projects, not people

It’s easy to have each individual define their focus on defining their own work. I prefer focus thinking around projects.. Teams grow, teams shift, teams can get help from other teams. Define for the work to be done independent of personnel. Once defined, it’s easy to prioritize/scope based on team capacity. Overflow can be cut, planned for the next cycle, or pitched as need for more headcount.

Build in a capacity buffer

Support is a big part of what design system teams do. Support takes time. That time takes away from other work. You’re going to have a big math problem, if you’re planning based on 100% capacity.

In an ideal world a design system team has a measurement of how much time support takes up. Subtract that measurement from the team’s capacity when planning. If that measurement doesn’t exist, ballpark it. If the team is allergic to ball-parking, set aside 20%.

Planning complexity scales exponentially based on team size

What works for a team of 5 will begin to buckle at a team of 10. And it’s a hell of a lot more than twice as hard…

The less defined process, roles and responsibilities are, the harder planning will be. Trust me, I know by experience.

Aim to be cycle ahead or behind

Design system work benefits from staying out of the product development fray. It’s difficult, if not impossible, for a design system team to keep up with the pivots and shifts of feature teams. It’s equally difficult for feature teams to wait on a system team to deliver a systems-based solution. Those teams think in an ASAP-level–systems teams can’t.

To combat this, design system teams should either:

• Plan a cycle ahead to enable feature teams to hit the ground running
• Plan a cycle behind to systemize common patterns once the dust settles

Under-promise

Teams often plan based on what the design system team commits to delivering. Meaning, if you say you’re going to deliver that button component, you better damn well deliver it. A design system team’s goals should be attainable–barring unforeseen circumstances.

Feature teams heavily rely on design systems. When a design system commits to work, there’s a good chance another team has planned around that. Missing a commitment can dramatically impact a feature team’s ability to deliver. It’s critical to make good on commitments. Better to underpromise on what’s possible to make sure it gets done. Overdelivering is always an option.

Over-communicate

Did I mention feature teams rely on design systems? That reliance means they need to be constantly kept in the loop. Teams need to be aware of what the design system team plans to take on. They need to be aware of progress. They should be aware when milestones are hit.

Also, plans change. Shit happens. When (not if) those things come up, it’s critical that everyone who relies on the system is aware. Ideally sooner than later.

It’s not a democratic exercise

This doesn’t mean that folks shouldn’t aim for consensus, but it isn’t necessary. The people doing the work outvote the team members who aren’t. Unless that work impact others’–that’ll need coordination.

Planning can be fluffy–especially early in the process. It’s critical to give everyone on the team the ability to push back. Every, “why?” should damn well have an answer. Or at least a hypothesis. If not, that’s a sign to go rethink decisions.

There’s never enough time for it

So make sure to constantly refine your planning process. Starting by documenting your planning process. I’ve also begun to consider planning a nonstop process. The second the team has landed its upcoming plan marks the moment to start organizing the next.

Plans almost always falls apart to some degree the second the rubber hits the road

Don’t be precious. It’s important to stick to the plan–until it’s not. What’s the turning point? That’s for everyone to figure out on their own.

How I currently structure plans

Most companies I’ve worked for use OKRs to structure plans. They’ve worked fine for me. I’ve made some small tweaks the based on experience and preference. There’s nothing wrong with OKRs–hell, they could be better than my tweaks. So take my structure as either a gentle consideration or cautionary tale.

Projects follow a structural hierarchy of: Long-term direction > Theme > Objectives > Projects > Tasks. Each child supports the parent with greater fidelity and concrete definition.

A brief detour on product owners

The following section discusses ownership of responsibilities–with product owner being frequently mentioned. Who should the product owner be? Whoever is willing/able to own the direction of the roadmap. It can be a product manager, a people manager or a lead designer/engineer. Any/all can work. It’s down to culture/people/capabilities.

Long-term direction

Everything starts with a long-term direction. It’s both the least and most required part of planning. The long-term direction is your design system’s roadmap of roadmaps. It charts a multi-year course for where it plans to go and what to achieve. The product owner drives long-term direction with input and influence from senior leadership.

I usually aim for a four to five year plan. I find the long-term direction to be the ideal altitude to work with senior leadership. It’s great for strategic input without disrupting the team’s day-to-day work.

The long-term direction won’t perfectly lay out what each year will look like. That’s impossible. The goal is to form a point of view to work towards–knowing that point of view will constantly evolve. This point of view helps the team understand how each planning cycle intends feeds into the next.

The fidelity and accuracy of the roadmap drops exponentially over each year. That’s expected. Again, the long-term direction’s purpose isn’t to be accurate, it’s to define an actual direction.

Planning starts with a review the long-term direction. That review helps inform the plan’s upcoming theme.

Theme

A theme is used to help focus a team’s work for the cycle. The theme is typically defined by mangers/product owners on the design system team. It’s guided by company business goals and senior leadership. A planning theme provides a lens to put all projects through and a filter for efforts that are on the fence. Not all work will fall perfectly under a theme, because reality doesn’t work that way. That’s absolutely OK.

Objectives

Objectives represent a distinct goal in service of the planning cycle’s theme. Each objective contains a collection of projects that feed into the goal. Objectives can be defined by the product owner or be driven by senior team members. All team members should have heavy input in the definition of objectives. Some objectives won’t map to the plan’s them. As mentioned, that’s OK. Just be honest about it.

I like objectives to have their own goal/success measure as I find this a better altitude to report upward. I also think it’s important to show how all the projects in an objective map to an single definition of success. This creates extra work from how I’ve seen others set up OKRs, but I’ve found it useful.

Projects

Projects are what I use instead of key results. I find it easier to wrap my head about this mapping. Projects are where the rubber hits the road. I like using projects because they’re exactly what the name suggests. They’re a logical chunk of work with clear boundaries that cleanly map to the objective it’s a part of. Projects are typically defined by the product owner and people who’ll work on the project.

Each project in the objective should also have a clear goal/success measure(s). Those goals should clearly feed into the success of its objective’s goal.

Projects are defined through a one pager or requirements doc that outlines what the hell you plan to do. A project should have an owner who’s responsible to drive the work forward. The project’s requirements doc are written by the product owner and/or the project owner. At the very least, the person who owns the project needs to be heavily involved.

Tasks

Once each project has definition and goals, the job is to scope out the work as granularly as possible. Ideally, down to the task level. This is akin to pre-visualizing a project.

The project owner should work with all involved to define tasks. Tasks have an assignee, rough level of effort and requirements. The product owner and the project owner weigh in on prioritization and requirements. Assignees need to own the level of effort.

How does this usually play out?

Planning follows a pretty straightforward process. First define the high-level direction. Then scope out the tasks to support that direction. Next, sequence the work out across the length of the roadmap. Afterwards, you tweak the roadmap based on capacity and dependences. Then you use any overflow and learnings to pre-plan the following roadmap. Lastly, you socialize it across the company.

Defining

The team works to set a theme for the roadmap and then work to set objectives. The goal of this step is to make sure we’re all bought in to spending a large part of our year working on what’s suggested. I usually stub out skeleton projects to act as a conversation starter. The skeletons don’t need requirements or finalized goals. They only need to kick help start the conversation. This high level definition is shared with the team for review and spirited gut-checks.

Scoping

Once the high level plan has been established, the team goes into scoping mode. The goal of this step is to get all the work to be done defined, prioritized, assigned and level of effort estimated. This is the onerous project of defining all the work that needs to be done for each project. The more granular the tasks are the defined, the better. Have I mentioned it’s a lot of work? Because it is.

Sequencing

Once tasks are created and assigned, it’s time to map them across the planning cycle. Each team member sets an order and rough start dates for their workload. This step makes sure projects are scheduled accordingly when there are hard deadlines. It also ensures that work flows in the right order. Meaning all design tasks need to be sequenced ahead of development. But most of the time, each team member is able to map this to their own personal roadmap based on how they prefer to work.

Rejiggering

Once tasks are scoped and sequenced, it’ll be clear what the team has time for and what’s got to go. Tasks that can’t fit within capacity are cut and project scope is reduced. Objective and project goals are adjusted to reflect what’s been removed.

Future planning

What do you do with all that work that got cut from the current plan? You log it for the next planning cycle. The scope and goals set for the upcoming roadmap should impact the next roadmap. And knowing what will have to spill over is a big part of shaping that future outlook.

So don’t feel like all those created tasks that were cut was a waste. Quite the opposite–it’s helping the team prepare for the next planning cycle.

Evangelizing

Once the roadmap is set, it’s time for the road tour. A design system’s roadmap has the potential to impact so many teams. So, it’s important to plan and roadmap as visible as possible. Share it in meetings. Share it in email. Share it on Slack. Share it at happy hour. Share it over and over. People should be tired of hearing about your plan.

Our team typically posts the planning document which contains a all the gory details. It lays out the theme, objectives, projects and tasks. It’s paired with a Gantt chart that shows the sequencing of work by each project. All this is capped by a summary document which outlines the plan in a conversational tone. I’ll also sometimes go as far as reaching out to teams to see if they have questions/concerns.

Without fail, something is going to come up a week after planning ends. Teams will then ask why the design system team can’t take on a specific project. That’s when you point back to the plan that everyone’s tired of hearing about.

Planning is a lot of work

Make no mistake, I don’t enjoy planning by nature. This isn’t what I get out of bed for. But good planning is can turn a team clinging on for dear life into one that’s hyper-effective. As much as I recoil from the tedium of the work, I love the outcomes produced. Like many other things that are hard work, the payoff is worth it.

To be clear, I don’t blame Figma. This is their job. We, the consumer, aren’t holding up our end of the bargain. The job of the business is to sell. To pitch everything with the rosiest tint possible. To make their product look irresistible. The consumers’ job is to be aware of this and act correspondingly. That’s not happening–at least not enough. Here’s what I observe far too often: A company pitches its wares. Customers squee in excitement at what will absolutely not disappoint in any way whatsoever. Think Cybertruck. Think Humane. I could go on.

Again, this isn’t a slight at Figma. It’s a slight at naive buyers. This naivety does both parties dirty. I saw untethered hype first hand at InVision. The design community was emotionally and irrationally bought in at a level that defied reason. From a company that at no point earned that right. That delusion allowed a few at the top to believe what they made was all they thought it was. It wasn’t.

A skeptical customer is a gift. And we, the customers, are being miserly. This isn’t a call to mob up and blast negative absurdities on social media. It’s to just do the job of a customer. Brush the sales pitch aside. Reserve judgement. And once you have enough information, tell them what you expect for what they’re asking.

I’d say there are two logical conclusions to make from any demo presented at conference like this:

1. Interest is piqued, but prolonged first-hand experience is needed to make a decision
2. Not interested, but prolonged first-hand experience is needed to make a decision

Tools are not an impulse purchase. They’re not a candy bar at the checkout lane. Something like Figma is a significant investment of your time and money. Don’t just consume the pitch. Ask questions. Find chinks in the talking points. Constantly ask if what you’re seeing is what’s most valuable to you. Check your emotions, check the vibe, check the atmosphere and remember that you’re being sold.

And respond accordingly.

Part of me thinks this is due to modern-day internet hyperbole. If something isn’t the best thing ever, it’s the worst thing ever. Another part thinks this is due to people’s experience with documentation.

As mentioned, I think documentation is essential. Specifically, I think good documentation is essential. You’ll have my full agreement on the worthlessness of bad documentation.

So I thought I’d write a short-ish articulation of what good documentation looks like and what it can do.

Good documentation is short, simple, structured, and actionable

Writing a bunch of stuff down may technically be documentation. But it doesn’t mean it’s good. Getting to good is hard work. Below are the qualities necessary to get to good.

Succinct

Documentation should not be flowery or poetic. Each word should have meaning. Use the fewest words needed to get the point across. It can be tempting to “fill the space” to create the feeling of rigor. No one benefits from that approach.

Predictable

A reader should know how to consume design system documentation in less than a day. The structure/format of content should be logical and consistent. Guidelines and best-practices will always evolve. But readers should know what to expect to see when they look for information.

As an example, component documentation should lead with, what it is, what it does, and what it’s for. Order the remaining content should by what readers need to know next. The goal should be to get readers using the component as quick as possible.

Concrete

Design system guidance must be explicit, objective and not subject to interpretation. Phrases like, “Use sparingly” or, “Avoid when possible” are subjective. What does “sparingly” mean? What’s the definition of “when possible”? Many words can have wildly different individual interpretations. The goal of documentation is to replace individual interpretation with shared definition. If a component should only be used once on a surface, say that.

Exact

Words in documentation must be used precisely. Use the same words to mean the same thing. For example, it’s problematic to use “quality” and “high craft” to reference the same subject. As mentioned, words have different individual interpretations. It’s already difficult to align on the meaning of one word. Don’t make it harder by using other words. Yes, this will make the writing repetitive. That’s a feature, not a bug. Repetition helps build familiarity.

Similarly, use different words to mean different things. Terms like “font”, “typography”, and “text” all have distinct meanings. Resist glomming terms together for the sake of convenience.

Approachable

Documentation doesn’t need fancy words. Use clear, simple language. Our work isn’t a science, so our language doesn’t need to be scientific.

Small words can have big meaning. The harder it is to read documentation, the fewer people will read it. That’s a basic, but important truth.

In a similar vein, avoid jargon and acronyms. Don’t make up new words that don’t need to be made up. Remember that a company’s dialect is not inherently understood–meaning it represents a dependency for people to understand the documentation.

A a rule, a junior-level employee should be able to understand a design system’s documentation.

Encapsulated

Individual guidelines should be self-contained and understandable on their own. The reader shouldn’t have to read the entire Button component’s docs to know when to add an icon. Each specific guideline should be able to guide the reader on its own. Readers need to be able to skim and digest documentation piecemeal.

Principles for a design system can be helpful. But they should be able to perform basis tasks without reading them.

Actionable

People’s relationship with documentation is transactional. A person needs to know how to do a thing–they read the documentation to find out. 99% of the time they are not interested in design principles or mission statements. They just need to know how to do a thing.

Documentation should be tuned for action. Remove preamble. Frame guidance in a way that enables people to act with certainty in the least amount of steps.

Similarly, only telling readers what not to do* isn’t actionable. People aren’t interested in what _not* to do. They’re need to know what to do. Documentation will not have all the answers. But it’s important for documentation to avoid being the “Book of Don’ts”. “Don’t dos” should be paired with “…do this instead”.

Justified

Documentation should be able to answer, “But, why?” Recommending a reader not do something without justification is not actionable or educational. It does not guide the reader to better understand how the system works or how to interpret its rules. Including rationale is critical to help readers understand the system’s underlying logic.

Best practices are a clear area of opportunity for providing rationale. Ideally this rationale is rooted in evidence with cited sources. Sharing this information is a window into how the system works. It’ll drive a deeper understanding.

90% of the time this info will not be needed or desired. It can counter-intuitively make the documentation less actionable. To remain succinct, this may mean including footnotes or linking to an appendix. Receipts should be available when readers come asking for them.

Definitive (in a chill kind of way)

Remember that documentation is guidance. It’s a recommendation based on known use cases and needs. The unknowns are just that. Design system documentation will always be imperfect and incomplete.

In that spirit, the tone of documentation should always reinforce that reality. Recommendations are just that. They are not a dictate or an ultimatum. Words like must should be used with extreme care and precision.

Good documentation can help transform the way work is done

Yeah, those are strong words. But I believe them–strongly. Below are all things (except for one) that I’ve seen documentation do with my own two eyes.

It forces a point of view

A design system team without documentation is dangerous. It gives them room to waffle. Today, only one primary button on a surface is allowed. Tomorrow, maybe not. Without documentation, a point of view can change at any moment. With no accountability.

Design system consumers deserve a clear, stable point of view on how to use it. They should be able to push back when feedback doesn’t align with documented guidelines. Documentation keeps a design system team honest and answerable to those who use it.

It improves the thinking behind the system

I believe writing documentation is valuable even if no one reads it. Look, it’s been said a million times–the act of writing fortifies the thinking behind it.

A design system’s component or pattern isn’t complete until it’s been documented. Documentation is a design system’s mental QA. It’s one thing to think a component or pattern’s logic works in your head. It’s another to prove it by writing that logic out.

Writing documentation has resulted in more component revisions than I can count. The process is worth it for that reason alone.

It keeps the design system team aligned

It’s naive to think the entire design system team shares the same understanding of every token, component and pattern. Quite the opposite–I’d say there’s far more misalignment than there’s alignment on the average team. Documentation can correct that quickly.

Documentation acts as a team’s handbook and rallying point. It helps team members catch up on areas they have less exposure to. In times of disagreement, it can help ground conversations. Docs can be the mental glue between all team members.

It keeps thinking available when people aren’t

A lot of design system teams rely on Slack or Teams to answer questions as they come in. It’s common for those mediums to be the de facto form of documentation. Which, I’ll say, is the least efficient form of documentation possible. But on top of that, what happens when the person answering the questions isn’t available?

The thinking behind a design system is–far and away–its most valuable piece. It’s a huge risk to for all that thinking to stay bottled up in one person’s head. That person will be too busy to respond. They’ll get sick. They’ll go on vacation. Those moments represent blockers to anyone with questions about the system.

And someday, that person will leave. At which point that knowledge is gone forever.

It creates a common language

Design system docs help folks understand a product’s design/engineering best practices. Duh. But it also creates shared terminology and definitions. Which allows people to effectively communicate.

It’s hard to have conversations when people use different words with the same meaning. Or the same words with different meaning. A component with different names between design and code can screw things up big time. Take a guess at what shines a light on issues like that?

Words matter–now more than ever. Documentation produces a shared set of words to help generate shared understanding.

It levels the playing field (maybe)

This one’s a little aspirational and admittedly not proven. But I believe in it nonetheless. Documentation can be a (hypothetical) leveling agent within organizations. It’s far too common for decisions to suffer from highest-paid-opinion-In-the-room-syndrome. I see documentation as a way for people to fortify their decisions to those above them.

Will this always work? No. Will it work the majority of situations? Probably not. But even if it works on occasion, that’s damned valuable.

Naive/idealistic? Guilty as charged.

It reduces team overhead

Design system support is as important as it is costly. Make no mistake, support is a key part of a design system’s success. But support doesn’t need to be only handled by humans.

People do read. Good documentation is read. Every question documentation answers is one that a person doesn’t. I’ve seen cases where growth in docs usage coincided with decreases in support volume. Cases–as in plural.

That decrease in support is time saved. And that saved time is free to apply elsewhere–like improving the system. Or writing more documentation. Time is always money. Good documentation prints it.

It acts as a feeder for AI

Yeah, I said it. I’ve yet to see AI perform effectively in typical design systems work. I remain uncertain what role it will play within design and engineering. But I am certain that design system documentation is an ideal source to train LLMs. Those who are pursuing AI in their internal processes should be documenting.

This is an area I continue to explore with mixed opinions. But it shows enough promise to keep chipping away at it with interest.

People read good stuff. So write good stuff.

There may come a day where humans invent a better form of information transfer than written text. I’ll back off this crusade once that day comes. But it ain’t here yet.

Until then, take the time to document your system.

Twenty years ago I said, “Ten years from now, design technologists will replace the software design role”. My bad. I maintain the opinion that design techs are the ideal role for making software. They have a fuller understanding of the software medium. That makes them more capable to design and build for it. That all seems logical in my mind. But people and society aren’t logical. Corporate America definitely isn’t logical. And so the hybrid role has continued to tread water–quite literally between the margins.

My belief in the practice has not wavered. But I had lost confidence that it would take off beyond isolated pockets. That may be changing due to market conditions and advancements in technology. And so I’m dusting off my optimism to discuss what makes this role so special and what qualities I look for when hiring.

The design technologist role is a wide spectrum

It’s important to note that design technologists come in many shapes and sizes. It’s easy to fall into the trap of thinking of them as engineers who like to dabble in design. But that’s flat out wrong. Some design technologists are 10% design and 90% engineering. Others are the complete opposite. Most are somewhere in the middle.

The emphasis doesn’t matter–if there even is one. What matters is that there’s a blend of the two skills. Each blend is going to bring its own strengths and weaknesses. But they all bring something valuable to the table.

This role remains special–and misunderstood

Yes, I’m biased. Unapologetically. I’ve seen what this role can do and it’s invaluable. It’s also undervalued. They’re typically only half-understood regardless where they exist in an org chart. Design leadership doesn’t get how the engineering skills apply to their org. Engineering leadership doesn’t see how the ability to design is useful for them. This role can feel unappreciated without the right support.

None of that changes that the design technologist brings a whole new set of capabilities to a team. They’re not a partial designer and a partial engineer–they’re a whole other thing entirely.

Design techs get things done

People in this role drive results–quickly. It may not be perfect. But it’ll happen. And let’s be honest, a lot of day-to-day work is about getting it done. Their wide skillset frees them to take an idea all the way to final execution with little to no support.

I’ve also noticed a common streak of pragmatism from people in this role. They’re often implementing their own designs. So, they know how uncompromised design can lead to painful engineering. They also know engineering decisions that impact design lead to a crap experience. Design technologists usually aim for the best practical blend of design and engineering. They know usually leads to the best all-round outcome.

On top of being able to go soup-to-nuts, they’re also incredible at filling gaps in projects. If a team is short on dev cycles, they can assist. Need some design support? They can do that as well. Need a little of both, they have that covered. Design techs are blocker killing machines. The flexibility of the role makes them a resourcing dream.

They improve the ways teams work

Design technologists’ have an understanding of how the sausage is made on both sides. They know how design impacts engineering (and vice-versa). They know how designers can set up engineers for success (and vice-versa). They also understand how engineers piss off designers (and, again, vice-versa).

They, more than most, know how design and engineering are interconnected. That understanding helps them shape ways of working that benefits all parties. Designers and engineers still struggle to work well together after decades of trying. This skill alone should have teams hiring design techs like their lives depended on it.

They develop novel solutions

The Law of the instrument is the origin of a pretty famous quote, “If all you have is a hammer, everything looks like a nail”.

Pure designers will always try to solve problems with design. Pure engineers will always try to solve problems with engineering. Design technologists by nature have a bigger toolbox.

Sometimes they’ll solve a tricky development roadblock with an alternative design. Other times they’ll fix some design challenge through technology. Sometimes it’s a blend of both.

They have a lot of tools at their reach and it allows them to approach problems differently. This results in solutions that neither a designer nor engineer would even consider. One design tech working on a problem is fundamentally different than a designer and engineer working on that problem in tandem. I wouldn’t say one is better than the other, but they’re absolutely different. And that difference opens up the possibility for original solutions.

They make connections more specialized people don’t

Design techs see patterns and make connections that most specialists won’t. Viewing software creation through a wide-angle lens makes that almost inevitable. Being in more steps of the process shows how one decision impacts every future one. In a way, working as a design technologist is a crash course in systems thinking.

I also don’t think it’s a coincidence that so many design technologists gravitate to design systems. My experience building with reusable code made design systems seem like only reasonable way to make software. It’s impossible to unsee.

Good design techs are action-oriented, collaborative, and curious problem solvers

I’ve hired a decent number of design technologists in my time. I’m typically not looking for portfolios or experience with specific tools. I’m definitely not looking for years of experience as a design technologist. I’m looking for a mindset. In my experience, there are certain qualities that thrive in this role. I look for one or more of these when hiring.

Action-oriented

Good design technologists bias towards action. They’d rather beg for forgiveness than ask for permission. In part, they broadened their skillset to avoid being blocked in the first place. They’d rather cut through the red tape and do it themselves than wait.

I’ve never met a design technologist with Initiative as their legal middle name. But it may as well have been for most I’ve worked with.

Collaborative

But don’t get it twisted. Sure, they may not want to wait around and do nothing. But the good design technologists are some of the best collaborators around. Their hybrid experience gives them healthy amounts of respect for each discipline. They may not be keen on waiting around. But they’re also typically the first person to want to include folks for different perspectives.

Intellectually curious

Design technologists are naturally interested in a lot of things. They see something they don’t know about and want to learn more. Many can be a little like butterflies that need space to fly around where they see fit. I try to give folks in this role a lot of space so they have room to experiment and tinker.

This is often their fuel and their source of greatest value. Some of our teams’ greatest achievements came from a design technologists’ unplanned tinkering.

Problem solvers

The defining trait I’ve seen in nearly all strong design techs is an insatiable desire to solve problems. That may sound like a platitude. You may think, “Designers and engineers also want to solve problems”. And you’d be correct. But design technologists take this to another level. The drive to solve problems is the motivator to grow beyond design or engineering. That’s what got me into this mess. And many others I’ve worked with.

Design technologists see problems and aggressively want to fix them. That often makes them incredible enablers. They thrive in solving problems other people/teams are facing.

What’s the future for this practice?

I don’t know. A part of me continues to think that if it was going to take off, it would have done so by now. But we’re in a cycle of big change. Companies want to do more with less. Engineering orgs in particular seem to be slimming down. AI may not be the magic some are selling, but it’s not completely hype.

We may be heading to a world of dwindling headcount and tools to supplement code creation. We can debate the merits of such a future, but that’s for another day. If that’s in our future, the design technologist could be ready for its time in the sun. And frankly, it’s about damned time.

I hold extreme opinions on naming because I think there are really effective and equally ineffective ways to do it. The effective ways seem important. The ineffective ways seem like navel-gazing.

Fun is only fun for the people having fun

Gestalt’s color palette is probably my biggest regret. I consider it a great case study in clever, creative, fun, and horrible naming. I distinctly remember the meeting where everyone acknowledged how much we fucked up. You could literally hear pain in the engineer’s voice when they asked, “So I need to type Matchacado every time I want to color something green?” “Why not just call it green?”, was the next question. Which, to be fair, was a damned good question.

Fun names aren’t as fun as the namers think they are. Don’t get me wrong, it’s fun as hell to come up with clever new words. Even when there’s a perfectly functional existing word available. Pharmaceutical ads may well be the zenith of make-shit-up naming. Where we once had “General Steel”, in today’s marketing-driven mindset we’d have “Ferraxa”. These names are creative (I guess?), but I don’t think creativity is a good thing when it comes to naming. At least not in design systems.

Anyone reading this who’s worked with me is rolling their eyes now. I’ve been public enemy number one for creating stupid names purely for the sake of juvenile humor. Guilty as charged. My case nonetheless stands.

Clear or flexible (you choose)

A name should clearly and concisely describe its subject. Dishwasher may be the best name ever invented. “What’s a dishwasher do?”, is not a question people ask. A name has succeeded if it’s self-descriptive.

Concise and clear naming is all fine and dandy to say, but much harder in the realm of systems. Specifically in the realm of design tokens. Tokens are design systems’ magnum opus in masochism. Design tokens defy clarity because they are abstract by design. Tokens shift based on context. Things like color schemes and density settings mean that what was once dark is now light. What once was big is now less big. We can’t just call a thing what it is, because it isn’t always the same thing.

How do you name a thing that changes? Abstraction. Terms like light/dark are replaced with negative/positive. Which is fine, but it chips away at clarity. People innately get “dark” faster than “positive”. Abstraction gives us flexibility at the cost of clarity.

To make things harder, a lot of things in design systems are relative. Think size/color ramps. Sure, we could just name each size its actual value, but what happens when that value has to change? Now that name makes no sense whatsoever. Going back to our friend abstraction, we’ve historically named ramps in relative terms (e.g., small, medium, large or light, medium, dark). This also sucks. Because what happens when you need to add a value between small and medium? You get the infamous smedium. Too many sizes and you get a bunch of Xs in names (e.g., xx-small, xxx-small, xxxx-small). No one will convince me those are good names.

So, to combat this, we’ve typically used numeric stops for ramps (e.g., size-100, size-200 and red-100, red-200). More abstraction. This fixes the issue of needing to shunt a size/color in the ramp (size-150/red-150) but it’s even more abstracted. Meaning it’s even less clear. Someone tell me what size-100 is. It’s nothing. In a way, that’s the point.

In real life, I can call a chair a “chair” and know that it will always be a chair. In the world of design systems, a chair could become a sofa, or a table, or a Volkswagen. I know we haven’t cracked design tokens because they continue to make no goddamned sense. Due in large part to obtuse naming conventions.

Rules of thumb for naming components

I don’t see a world where token naming doesn’t devolve into said mindfuck death spiral. At least not in the near future. But that doesn’t need to be the case for other areas of a system. Luckily, many other areas of systems can be much simpler. And it’s important to lean into that simplicity.

I think it’s important to have one name–and only one–for a thing. This seems obvious. But different platforms have different names for the same thing. What would be considered a list on Web has been called a table on iOS. There’s a million of these discrepancies once you get in the weeds. As difficult as it may be, I maintain the opinion that a design system needs to settle on one name.

Once that name is settled, the focus should be short, simple and clear. As few simple words as possible that clearly describe the thing. Mind you, this is deceptively hard. Maybe even deceptively impossible. But a few smart decisions during the naming phase can at least reduce pain down the road. For example, is, “Loading Spinner” a good name? What if it’s redesigned to no longer spin? What about, “Loading Indicator”? Well, “indicator” is a pretty big word for a pretty small meaning. Maybe, “Loading Sign”? What about just, “Loading”? Too vague?

Side note, I don’t think I’ll ever understand why “Floating Action Button” isn’t called “Floating Button”. Aren’t all buttons, action buttons? Floating Action Button, in particular, sticks in my craw. This overly complicated name led it to become FAB. It committed the ultimate sin of becoming an acronym. A name has failed once it’s become an acronym. I could go on and on about the blight of acronyms, but that’s for another day. I’d argue that naming simplicity is critical solely to avoid being acronymed.

Lastly, names should have decent separation between each other. The more components differ in form/function, the more their names should differ. For instance, “Tag” and “Tab” are pretty damned different components, but the sound really similar. That alone can cause confusion. It doesn’t help when the “G” and “B” keys are so close together. One fat-finger typo and now there are tags where there were supposed to be tabs.

Think before you name

I could go on and on about naming in design systems. Suffice to say, it’s important (as much as I can think otherwise). Design systems are many things. Their role as a language may be its most critical. The nomenclature used in a system is what creates common understanding or general confusion. It can bring people together or keep them siloed.

For as critical as naming is, it’s not always treated that way. Many teams don’t have people with the background, expertise or even general interest to deftly handle taxonomy. Think twice before you name that component Floating Upsell Card. You may end up regretting it.

This blog is a place to get things out of my head. I write for myself. Putting it on display provides just enough social pressure to give it that much more care. But it’d be fine if it was read by no one. I won’t lie–that wasn’t always the case. It took me a lot of years to grind that desire out of me.

Social media platforms were supposed to the way for anyone to grow an audience. For many, dare I say most, the goal was simply to be seen. To fulfill a need to feel validated. And man, has social media preyed on that need.

Speaking of preying. Social media has also preyed on the tale as old as time: “you can become the next big thing”. Many folks got caught in the trap that they just might be able to make a living by making content. And just like every other road to fame, 99.9% of them didn’t.

What was once a snowball’s chance in hell is now even harder. We’ve seen a slow-motion rugpull for the past decade. Platform algorithms increasingly have more sway on content consumption. A creator’s “audience” means less than ever. Now that 99.9% looks more like 99.999%.

In response, we’ve seen a small, yet steady push towards independence. Content creators are experimenting with newsletters to distribute content. I get it–newsletters give creators the ability to have a direct line to their followers. No algorithms, just a direct line.

The problem is, it’s still flawed. First, there continues to be a middleman. There seems to always be a middleman nowadays. It’s easy to see for plaforms like Substack because they are the middleman. And that middleman can change their rules at a moment’s notice. Even “independent” newsletters use services like Mailchimp or whatever other newsletter services exist. Those too are middlemen that can also change the terms as they see fit.

The second and more essential issue is that the overwhelmingly vast majority of creator will never make real money. All the while, the people trying to consume content deal with layers, and layers, and layers of bullshit. Privacy issues, invasive advertising, increasingly aggressive dark patterns. All to make 30 cents in revenue. Which, begs the question, “Why even try?”

I understand the desire to grow an audience. I also understand the desire to know who your audience is. Even more so, I understand the desire to be in more control of your own destiny. But that desire comes with some serious strings. And when you cut those strings, things get incredibly simpler for everyone.

I’ll never grow a following or make a dime from this blog. That’s just fine. It keeps things clean and easy. I have a simple site that I pay nothing to host. I have no aspirations beyond what this currently is. I write the things I want to write. People may read it. If they do, awesome. If they don’t, whatever. It’s freeing.

But who cares about how I feel. More importantly, this approach respects readers. They’re not tracked. They’re not bothered with ads. There are no stupid GDPR labyrinths. None of their personal information is stored. They come, they read, they leave. That’s it.

I don’t think it’s wrong that people want to have their content seen. It’s completely logical to want a payoff for what they create. None of that in itself is “bad”. But in our current day and age, it can come with some pretty nasty consequences. We should at least go into that with our eyes wide open.

I don’t want anyone’s email. Even more so, I don’t want anyone to want to give me their email. Frankly, I want us to give less.

Not much to be honest. I’ve been working in this industry for a long while now and I still don’t have a damned clue. But, as the years go by, I don’t think many people do either. Meaning most of us are all just figuring this out together.

I don’t have answers, but I do have experiences. That’s all I can share. These experiences are not profound. They’re not new. There’s no guarantee they’ll work for anyone else.

But I’m sharing them anyway. Because they may be useful for someone. Someone like you.

Our industry is not in a good place

Welcome to 2025. Layoffs are happening every other day. Companies are shifting values with shifting administrations. The future seems more opaque than ever.

People are frustrated. To say the least. Which means morale is more fragile than ever. This is no longer something we can “take seriously” in the air quotes kind of way. It’s become existential.

Design systeming is really hard

And to make matters worse, the role of a system designer is just really challenging. Common issues include:

• Chronic reactivity to requests and support needs
• Being overwhelmed by too much to do in not enough time
• Challenges with knowing how people use the system
• A general sense of their work/role being misunderstood and unappreciated

And much more! But you get the gist.

Burnout has become a rite of passage. It’s (sadly) become a problem to manage versus avoid. Every design system team I’ve worked on had these challenges. And I know my experience is not the exception. We’re all in good company. Or, maybe, bad company.

Design systems are hard. Because the work of design systems is hard. But guess what? So is every other discipline of design and engineering. Just hard in different ways. It’s important to remember everyone is going through challenges.

Avoid the “us” versus “them” mindset. Trust me, that’s not a healthy place to go.

Morale is a hefty topic that can fill a book

And all I have is this blog…

This post won’t cover everything–because it can’t. So much of morale is squishy and hyper situational. My personal experiences aren’t going to be useful to someone’s specific situations. People write whole books on this topic. I have not, nor never will, write a book. Especially about this.

But if there’s one thing my experiences have taught me, it’s that morale can’t grow on a shaky foundation. I might be able to help with that.

It’s called work for a reason

I don’t think work is supposed to be fun. I think parts of it can be. But a lot of work is, well, work. And other parts can be downright misery. Compliance training isn’t fun. Corporate jargon isn’t fun. Mandatory fun isn’t fun.

When I think of morale, I don’t think fun. I think morale is made up of more subtle emotions. Things like fulfillment, security, trust, stability, hope. They’re less in your face. They’re fragile. They’re important.

Those are what I’m aiming for when building morale.

Boring is good

I think our industry undervalues boring things. But my goal as a manager is to make people’s day to day as boring as humanly possible. Not “boring” as in mundane. Not soul-crushing. But “boring” as in obvious, consistent, and predictable.

We’re living in an “exciting” age. Nothing about today’s world is boring. Everything is changing. Yesterday’s assumptions are today’s uncertainties. We’re waking up to something new everyday. And many, many of us want off the fucking ride.

That level of unpredictability makes life (and work) difficult. I can say with increasing confidence there’s a growing consensus yearning for more boring in their life.

Design systems are boring

I think a little boring is good for every team, but I think it’s essential for design system teams. Because I think good design systems are boring by nature. They just work. They’re reliable. No surprises. No excitement.

Design systems are institutions. They’re your local utility. Think of about the last time you turned on your water faucet. You didn’t ponder what would happen. You just expected clean, running water. A surprise would’ve been a failure.

And that’s one of the many values design systems can bring. Like many other institutions, they can establish stability. But it’s hard for a design system to establish stability when its team isn’t…

Discipline, focus and patience as the foundation for morale

Strong team morale is built on being able to work effectively. I don’t think you can disconnect impact and team sentiment. So, I don’t.

My focus to maintain healthy morale is to maintain a healthy team working model. And the three things I’ve found to be most important are:

• Discipline: Follow a process and stick to it
• Focus: Work with minimal distraction
• Patience: Tackle right thing at the right time

None of those things are giving off the fun vibes. I know. But they create structure to avoid the typical pitfalls of design systems. They help avoid reactivity. They reduce the feeling of being overwhelmed. They give people the space to do great work.

And doing great work is pretty damned fun.

Discipline to follow process

I don’t know how a functioning design system team works without discipline. There’s simply so many ways to get distracted and too many jingling keys to stare at. If there’s one thing I’ve seen gut a design system team it’s a lack of discipline.

People who work on design systems love to help. It seems to be hard-wired into the personalities that gravitate towards the practice. That’s endearing, but dangerous. This is amplified for teams that feel misunderstood or unappreciated. Because helping is so validating. And the act of helping can satisfy that craving to be appreciated and validated. All at once.

That dynamic can cause a reactivity death spiral. It starts from a design system team’s craving of appreciation and validation. People over-compensate by being hyper responsive to peoples’ needs. Outside teams see that behavior and say, “Oh, that’s what design system teams do”. Expectations are reinforced that feature teams can ask and they shall receive. The team feels even more misunderstood/unappreciated. In response, they over-over-compensate…

Rinse, repeat.

De-spiraling death spirals

Ironically, design system teams are especially knee-capped in a reactive environment. So, it’s essential to have the discipline to avoid those distractions. But that doesn’t come out of thin air.

The way I try to blunt reactivity is with structure. My goal is to create just enough friction to make reacting hard. This structure looks a little different for every team. There isn’t a single formula to follow. Rather, following is the formula. Meaning sticking to the chosen process is what’s most critical. Yes, you’re always improving the process, but incrementally.

For teams I’ve been on, the good mojo comes from sprint planning. I know, boring. But this structure helps keep the team focused on what we’ve committed to work on. Requests are always welcome. But the soonest we commit to is the following sprint. Rare is the time when that is ever a real issue. That structure helps us defer those “quick wins”. And that’s important, because quick wins can be addictive. And in my experience, most “quick wins” are neither quick nor wins.

This means you’ll need to be good at saying, “No”. Ideally, you’re not literally saying “No”, but in essence you are. Yes, this can be awkward and make people sad. It certainly won’t be fun. But discipline requires “No”.

And luckily, there’s a way to make “No” easier…

Goals put you in a proactive state

I said earlier that corporate jargon isn’t fun. Things like OKRs, and KPIs are not fun. But damn can they help you approach work proactively. And proactivity makes it much easier to say no.

Nothing makes someone feel less appreciated than having to drop what they’re doing because someone “said so”. Team goals, OKRs, and KPIs can act as a shield against those asks.

That’s why I think it’s so important to rally around team KPIs–with buy in from senior leadership. These KPIs can set the tone for how performance is evaluated. And they immediately give you an out for work that doesn’t fit.

“We’d love to help you, but we’re committed to increasing adoption by X% this half and can’t risk missing that goal.” It’s not you saying no, it’s the agreed upon measure of success that’s saying it.

Design system success metrics could be a series of novels on their own. They’re a can of worms and I have a love/hate relationship with them. But troublesome as they are, they can save a team’s ass when used the wisely.

Rote through repetition

So, the team has developed the discipline to follow a process day after day, week after week…

A funny thing begins to happen over time… All that process and structure becomes second nature. Now all of the sudden people aren’t thinking about how to do the work, they’re just doing it. Because it’s become muscle memory. It’s amazing how much friction can be removed through building up healthy muscle memory.

It’s equally amazing how unhealthy muscle memory can invisibly hurt morale. And given that much of it happens without intention, it’s difficult to even notice.

Spending the time on better habits goes a long way.

Focus to execute (well) on one thing

Discipline is the gateway drug of focus. A disciplined team should be taking on less unplanned work. Which means it should have more time. That newly-acquired time gives team members the freedom to focus.

Focus drives quality

Good work requires focus. This is not breaking news. And in the world of design systems, quality is pretty damned important. I’d go as far to say it’s a requirement. One bug in a highly-used component could create tens of thousands in production. The scale of design systems do not allow the luxury of half-assery.

You need a focus to focus

Duh. It’s basic, but important. Which brings us back to team goals, KPIs and OKRs. It’s surprising how many design system teams don’t have these. Yes, they’re boring (there’s that word again). But they create a shared focus.

That focus will look different for different team members. It may be more granular and atomic for people on the junior side. It may be a strategic area for more senior folks. The more important thing is that everyone has something.

Ownership at all levels

What better way to create focus than through ownership? I’m a big believer in creating domains of ownership on the team. Our team overlaps responsibility to avoid single points of failure. But there’s still an official subject-matter expert that drives the team’s thinking. This ownership gives people the freedom and expectation to go deep in their subject area.

And the people who own a subject, own it. They’re trusted to make the final decision. No micromanagement. No hovering. They’ll be supported when it’s helpful, but their hands are firmly on the wheel at all times.

As mentioned, focus/ownership is necessary for quality. But even more importantly, it gets people invested. Invested in the subject matter, in solving the problem, in success. Most importantly, it gets them invested in the team.

And in my experience, personal investment plays a major role in morale.

Patience to take one step at a time

And lastly, there’s patience…

Patience was easily the hardest skill for me to learn. My younger self always wanted everything to happen immediately. I wanted team to adopt immediately. I wanted leadership to fund immediately. I wanted results immediately.

It didn’t work–and it made me incredibly unhappy in the process. A great combo.

You can’t solve every problem

I still want to make everything happen overnight. The difference is that I know it’s just not possible. All I’ll get in return is burnout and mediocre results. Boring as it may be, I’ve learned the fastest way to get to that better place is by staying focused on one thing at a time.

Ultimately, this can only be solved by…

Playing the long game

Design systems just take time. It’s tempting to throw more resources/effort in the hopes to speed things up. Don’t bet on it. It’s not just about how fast a design system team can make a design system. It also requires designers and engineers using it. And that takes (you guessed it) time.

That makes gratification delay incredibly important. I think about progress in years, not quarters–and definitely not months.

Progress is powerful

Big bursts of productivity is alluring. But I’ll choose consistent, incremental, progress every day of the week. It’s safer, more predictable and typically leads to higher morale.

The roller coaster of big releases and big hangovers creates a roller coaster of emotions. A steady drip feed of progress creates a steadier team atmosphere. It shows that things are heading in the right direction. Plus, it helps encourage patience. It’s a lot easier to be patient when you’re seeing progress every day. It doesn’t even need to be a lot. But steady, consistent forward progress gives people hope.

Roadmaps make progress visible

Incremental progress can be incredibly hard to see. Sometimes it’s so small that it’s impossible to visualize. Roadmaps can help visualize a team’s accomplishment. Your team’s metrics will quantify accomplishment. Those two create a powerful combination.

It’s easy to say, “We’re doing great” or “We’re not doing great”. It’s also a platitude on its own. The value of having a roadmap and team metrics is that you don’t have to say anything. Because they speak for themselves.

But it doesn’t hurt to tell your team they’re doing great. Even if you don’t have it. Just saying.

No → Not yet

That fancy roadmap creates even more protection against reactivity. Simply adding someone’s ask onto a long-term roadmap can immediately diffuse tension. It represents that you’re taking their needs seriously and have a plan to address.

It instantly transforms, “No” into “Yes, but later”.

This is a foundation to build on

These are the things I focus on to create an environment for healthy morale. I can’t guarantee this alone will improve morale. For myself, it’s laid the groundwork to get there. In a way, it unblocks the ability to do all the other work. You’re still going to have to understand what motivates each person. You still need to invest time and energy into relationships. You still need to do a lot of things. But those things will be easier with a stronger foundation

None of this matters if you don’t care

If you’ve read this far, I’m admittedly shocked. I’m also assuming that you are probably disappointed because none of the things I’ve outlined are new. Or novel. Or advanced.

They’re boring. And they’re basic. Sometimes I wonder if that’s why they’re overlooked.

Ironically, many of the processes outlined are used elsewhere to disservice of morale. Creating healthy morale often comes down to caring about it. Because if you care about it, you’re going to put in the work to improve it. You’re going to keep trying things until it gets better. You’re going to come up with better ideas than what’s in this stupid blog post.

But if you don’t care, then none of what I’ve shared will help. Nor will the advice of much smarter people. In retrospect, I should have led with this and saved us all a lot of time.

It’s hard to know where this bottoms out. And those who rely on these services are just along for the ride. Web 2.0 seemed like such a great idea in a more innocent time. We’re at a point where it’s only prudent to view third-parties as guilty until proven innocent. Not as some abstract, principled stance, but for our own direct benefit.

Now, more than ever, it’s critical to own your data. Really own it. Like, on your hard drive and hosted on your website. Ideally on your own server, but one step at a time.

The most common advice I give to junior designers is to write. I’m doubling down in the age of AI. Unique ideas and critical thinking are more valuable than ever. The craft of writing looks like it will go the way of cursive based on our current trajectory. People who can uniquely and independently articulate their own ideas have an advantage.

If I’m right, your unique and independent ideas will be increasingly valued. Don’t give that away. Control is ceded the minute it’s published on another service. How much control? Hard to say. It’s at the whims of their EULA, product direction, policy changes, and business health The most reliable way to publish ideas and have them remained published is on a site you control.

Yes, AI companies will almost assuredly scrape your site to feed their LLMs. Whether that will remain legal is questionable. But there’s no question when it’s willingly posted on their platform.

Is taking control of your content less convenient? Yeah–of course. That’s how we got in this mess to begin with. It can be a downright pain in the ass. But it’s your pain in the ass. And that’s the point.

Plus, people over-think self-publishing. It doesn’t take much. Words–that’s all. An image of two if you’re feeling fancy. But things like search, and all the other fluff associated with modern websites–nah. Less features is a feature.

This isn’t the post to tell you what tools you should or should not use. It doesn’t matter as long as you own what comes from it. It can be something like Obsidian. It can be plain-ol’ HTML and CSS. It doesn’t matter–as much as folks want you to think it does.

And this isn’t just about blogs. This relates to portfolios, code snippets, photos. You name it. What’s made by you should be owned and controlled by you.

Web 2.0 failed. True online sharing died a long time ago. So start taking. Take your ideas, your words, your work–and go home.

The software design practice remains in a self-imposed existential crisis related to craft. So seeing how actual craftspeople do their work seems pretty damned worthwhile.

Craftspeople are toolmakers

I learned early on as a crappy DIYer that good craft requires good tools. There are simple limitations to what a human being can do. This does not mean that skill doesn’t matter. The skill comes from how it’s directed through the right tools–“right” being both in function and quality.

There are the off-the-shelf tools, like chisels and planers and all sorts of other things. For software designers, that’ll typically equate to Figma or Sketch. Woodworkers tend to have many single-purpose tools–not to much for software designers. I think that’s a problem, but that’s another topic for another day.

Getting back to the topic–craftspeople are toolmakers. For all the off-the-shelf tools there are, there’s always that specific thing they can’t do. Which brings me to jigs.

Jigs are the custom tools that craftspeople create to enable them to do great work. In woodworking it’s often used to help make cuts with optimal precision. But, really, it can be used for anything. Jigs are what allow craftspeople to deliver quality predictably and faster.

Jigs are “fine, I’ll make it myself” made manifest. The tool they need doesn’t exist or is too expensive or is too much of a pain in the ass. So a jig is born. The craftsperson has a job to do and they’re not going to let a tool not existing stop them.

Designers who are not toolmakers are not (effective) craftspeople

I’m not sure I agree with the above statement, but I agree with it enough to keep it in. Crafting with high quality takes time–no matter the medium. Time is not generously handed out in the software industry. Hand-crafted, from-scratch quality in software is incredibly rare.

And it’s not like other craftspeople enjoy burning time. A master woodworker can almost assuredly create high quality without the use of jigs. But it would take considerably more time and be prone to mistakes (which takes time).

It doesn’t take a genius to connect less collective design time to the steady decline of software experiences. Designers simply have less and less time to focus on craft. So craft suffers.

Do jigs fix this? No. But they help. A designer that can speed up their work through design jigs has a distinct advantage. And every jig that cuts out a step or improves the precision of the output gives time back to focus on craft.

No, Figma plugins are not jigs

More specifically third-party plugins. And don’t get me wrong, plugins are great. They’re the closest thing we have to single-purpose tools. But jigs they are not.

While more focused than Figma (I mean, what isn’t nowadays) most are far too broad. Jigs are usually made for one person to do one job. Many plugins–especially popular ones–are made for many people and do many things.

Secondly, and this is just me, but I like things the way I like them. Why would I use a plugin that doesn’t work exactly how I want it to when I can make my own that does? That’s what’s great about jigs. They’re made especially for you because they’re made by you.

Lastly, I don’t trust 99% of them. It’s not immediately obvious what they’re doing or tracking behind the scenes. I have no control over updates or what the tool is going to be tomorrow. Today’s free plugin is tomorrow’s SaaS asking for my email and credit card. Call me cynical, but I’ve been burned too many times to rely on a random plugin.

Jigs in software design

So, if community plugins aren’t jigs, then what are? Well, it’s not complicated–it’s the things a designer makes for themselves to make something else. This can take many different forms.

Local components

The easiest jig a designer can make is a local Figma component. No, not a library component from their friendly-neighborhood design system. I am talking about a local, custom component for a project-specific need. I am shocked at how infrequently designers use local components. I am also shocked when those designers rail at long it takes to make global changes in their design. Local components are the epitome of design jigs.

Figma scripts

The next level up are Figma scripts. I typically use Scripter or, in cases where it works, the developer console. My custom Figma scripts usually follow the pattern of iterating through elements to:

• Replace all fills in a file from one color with another (no, Figma’s built-in functionality doesn’t work for this)
• Layer counting
• Remove all hidden layers in a file
• Remove layers outside of its parent’s frame bounds
• Remove floating point values layer attributes
• etc.

Notice the pattern here. Many of the examples are focused on cleanup and file hygiene. It’s not directly enhancing the design, but it’s making it cleaner and more precise.

And yes, Figma plugins exist for all these things, but without fail, I’ll need to do something that the plugin doesn’t do. And I’m at the point where I can make these “jigs” faster than I can navigate the Figma community plugin labyrinth.

Your own Figma plugins

Every once in a while a jig becomes a repeatedly used resource. At some point it makes sense to commit to making it a tool–or in our case, a plugin. These cases are more rare than we like to believe, so don’t hoard. But in cases where something is useful over, and over, it can be worth making it more permanent as a plugin.

But again, be careful how much time you spend on this. Figma isn’t going to be around forever and so the minute the next “it” design tool comes out, all this work is for naught.

Single-purpose CLIs

For any tooling that isn’t Figma-specific, I like to write Node-based scripts that I run in the terminal. If the tool is graphics-based, I output the result as a PNG or SVG. I can then import said output into Figma or whatever tool comes next.

What I like about this is Node and Javascript are not going to depart this world anytime soon. I can rely on these tools working far after Figma goes offline.

And, by all means, don’t limit yourself to only automating design tasks. How much of our day is absorbed by not design? Build jigs for note taking, or improving focus or whatever helps you do your job better.

Toolmaking is a craft–for the sake of craft

I’m not a believer in “work hard or work smart”. I think good work takes hard work and smart work. I also think it requires a different line of thinking for designers who want to focus on craft. The outcome alone cannot be the focus. There needs to be as much thought and planning put into how the hell that outcome can actually be produced.

Designers love to create. I encourage them to do just that. Create things that help you create better things. Time is precious. White-knuckling through repetitive, error-prone tasks lead to lower quality. Use all the skills you’ve built up to help enhance the way you work. And if you don’t know how to code yet, here’s a nudge to learn. Unless you enjoy white-knuckling through repetitive, error-prone tasks.

If the design practice wants to elevate craft, it’s going to need a healthy dose of toolmaking.

This is a problem–a big one. It represents a single instance of a more pervasive issue. where People use the same words to communicate different things. People assume alignment when reality is quite the opposite.

The word consistency is a loaded term in my work. To some it’s a mantra, to others it’s a slur. If you ask five people what consistency is, you’ll get ten different answers. Some people think it means everything looks and works exactly the same way. Others are a little more loosey-goosey in interpretation. These differences matter.

One thing I’ve come to believe in is the power of shared understanding. It seems so obvious, but it’s shockingly rare in organizations. It’s impossible to have a meaningful discussion if the words used don’t line up.

Consistency is a broad term. More specificity is needed to be useful for the context of design. Here’s my imperfect definition of consistency in regards to design:

The characteristic of following a logical, perceptible, and predictable pattern.

Those three attributes–logical, perceptible, and predictable–are all important.

• Logical means that decisions are intentional, rationale and rule-based. And those rules lack contradictions. In short, “2+2” always equals “4”.
• Perceptible means that the logic is simple enough to be [discernible]. There are plenty of logical formulas that don’t seem logical. The logic needs to be clear to the end user, otherwise it’s worthless.
• Predictable means that not only can they notice the logic, but that logic helps them know what to expect. Either consciously or subconsciously, people should be able to “finish the sentence”.

This is my definition of consistency and what I use to assess consistency in a design (or lack thereof). Mind you, this alone is severely lacking in detail to be actionable. There’s still plenty of room for interpretation in this definition. This, definition, would need serve as a nucleus for examples and use cases to prove useful.

A definition supported by concrete examples and detail is a great start. But sadly it doesn’t make things easier. Consistency in and of itself isn’t a “thing”. It’s not a binary state. It’s a spectrum. On one side there’s the complete lack of consistency–disorder. On the other there’s absolute consistency–homogeny. And then there’s everything between. Each has its place

Modern software is a paradox. On one hand it’s more conformist than ever. On the other hand, most are hilariously inconsistent in execution. The majority of software from large orgs leans towards disorder. This is often due to how large orgs operate. Siloed teams make siloed decisions to support their siloed goals. Most decisions are quite logical in their independent vacuum. But those independent logical decisions end up seeming quite illogical as a whole. It’s common knowledge what the negative outcomes are. It’s not a great place to be–except when it is. Sometimes a little surprise can shake things up. A little goes a long way, but it has its place.

Homogeny is typically not possible in a large organization. The sheer number of contributors and the pace of development make that unrealistic. I advise against even trying. I’ve observed attempts that resulted in square-pegging round holes at scale. It’s illogical to force things together that don’t logically fit. Consistency for the sake of consistency isn’t consistency–it’s circular logic. And even if absolute consistency is achieved, it could come at the cost of a boring experience. Monotony can be just as bad as chaos. That said, there are plenty of situations where you want to keep things nice and boring. Like forms.

There’s a time and a place for everything. A little chaos can be helpful to shake things up. On And yes, there are rules that should be inflexible.. But 90% of the time you’re aiming for the messy middle of consistency.

This is what makes this a difficult topic. Each organization’s relationship with consistency is going to be slightly different. Their ideal amount of consistency will vary as well. But establishing that relationship and finding that right amount doesn’t just happen. It requires conversations, debate and (healthy) conflict. Those things don’t happen without a shared understanding of what the hell consistency really, actually means.

Designers like to design. Developers like to develop. But neither can do their job well without a shared understanding and common language. Words like quality, craft, simplicity and, yes, consistency need definition. And not a dictionary-level definition. They need exhaustive, gory, and unambiguous detail. They’ll remain contentious and unreachable topics until that happens.

Consistency is essential. But to what degree, and in what situations? That’s up to each organization to decide. But without definition, this mess will persist.

Design system teams are just as vulnerable to the knowing/understanding gap. A team can know how people use it. They can know what’s working and what’s not. But they may not understand due to lack of first-hand experience. The why behind the what is missing. And why is pretty damned important when it comes to design systems.

And this is why I decided to make a design system for my personal websites. It’d been a while since I drank my own kool aid. Which, for the record, I am an ardent drinker of. I wanted to once again be on the consumer side to refresh my first-hand experience. It didn’t hurt that my websites were a hot mess. And I keep telling people that design systems can fix that kind of thing…

This article isn’t about the design system I made. It’s about what I better understand from going through the process. Below are the things that stood out.

You can make a design system too late

I typically warn teams not create a system before it makes sense. Going through this process made it clear how crappy too late can be as well. I’d never been the engineer tasked to inject a design system into a mature codebase. It’s not fun. Now I understand even more why design system pushes often coincide with redesigns.

Clearly, it’s possible to adopt a design system after it’s “too late”. But it’ll be painful. Lesson learned. There’s an ideal window for injecting a design system. I don’t think that window is uniform, but I’d wager the ramifications are.

Breaking changes suck

People know breaking changes suck. But experiencing that suck is something else. Early in the process I made various half-baked components/patterns. Against my better judgement, I implemented them into the websites nonetheless. I then had to refactor every instance once it was clear the components weren’t ready. Not fun. That kind of work is ancillary and avoidable. Better planning would have avoided find-and-replace hell.

Behind every “oopsie” are people dealing with the fallout. There are two solutions:

1. Make sure the design system cleans up after its own messes. It can be code mods or assisting with refactors. Anything to ease the pain.
2. Don’t make the mess to begin with.

There’s a time and a place for messes. Thrash can be healthy in a design system’s youth. But make sure you have a plan to blunt the impact.

The least amount of technology is the best technology

I didn’t use React for my design system. I didn’t use Vue, or whatever framework is cool today. I didn’t even use web components. I just used HTML and CSS. And that made this process so much simpler.

There was no installation process. No command line BS. No library dependencies. I wrote CSS, saved the file and viewed the results. There was a straight line from start to destination.

I never focused on framework errors or compatibility issues. We know heaping technology on top technology creates a mess. I knew messes weren’t a good thing, but experiencing reminded me why. Messes are a distraction. My focus had to include how all added technologies worked (and worked together). Sure, they were convenient, but at a cost. I understand the value of frameworks in a large team environment. But this experience further reinforced to keep things as simple as possible. Add with extreme caution.

Design systems aren’t immune from this. They’re an abstraction and can represent a detour from the direct line of goal to destination. The people who use your design system just want to get their job done. And your design system is yet another thing they need to keep track of.

“Just because” is a viable excuse

My websites had numerous instances of similar patterns with slightly different executions. Not out of malice to myself. Just because. I wasn’t thinking ahead. I forgot how I did it in the past. My focus was elsewhere. Maybe all the above.

Designers and engineers think of a design system like a carpenter thinks of a hammer. Which is to say they don’t. They’re thinking about the goal. So when people deviate from a design system, or miss some rule, there’s a 99.9% chance it’s because they were focused on other things… Like the goal. The more the design system is detached from their goal, the more because happens.

This was reminder that deviation isn’t usually from malice, but just because. The more the design system helps reach the goal, the more people will naturally use (and master) it.

Not yet doesn’t mean not ever

My design process focuses on getting the idea out of my head as quick as possible. I don’t want to spend time polishing a turd. Get things right, then clean up.

If I’m focused on the problem, I’m focused on the problem. Not hunting for components or fiddling with properties. I want the straightest path to the objective. The more the design system wrinkles that path, the less it fits in the process.

There’s three options to address this:

1. Make the design system so natural to use that it becomes the default way to work.
2. Bake in time to translate rough ideation to use the system.
3. Both.

I’d say the realistic answer is both. Of course it’d be great for a design system to create a flow state. That’s not how everyone works though. Some people prefer to wing it and get ideas out of their head. I am one of those people, so I can relate.

Seeing myself work this way reinforced that it’s OK to not use a design system. Careful pushing when folks use it, as long as it eventually happens.

Different can be a barrier

I have years of conditioning to “trust the system”. I still had a knee-jerk dislike of the subtle changes my design system had on my websites. From, my own system. Yes, ironic. I didn’t think the changes were bad. But, I was used to the old thing.

It’s fair for design system consumers to be skeptical of changes. It’s fair for them to be unhappy. Change management is part of the joy of working on a design system.

Be thoughtful of change. Not too much, not too frequent, not too abrupt. Change isn’t inherently good or bad. But either way, it demands others’ time.

The system made me naturally sweat the details more

This process exposed how much more investment I’d put into detail when it was in the system. I could shrug off a rough edge if it only showed up once. Not so much if it would be everywhere.

This can be a great forcing function for quality. It’s easier to sell investment in quality when the work will be far reaching. There’s a clearer bang for the buck. Conversely, it stings a little more to knowingly ship crap across the entire product.

This is a strong case for measuring and driving system adoption. Design systems can dramatically improve quality in a fraction of the effort. But it only if it’s used.

System design is a way of thinking

The design systems practice is being held back by its focus on artifacts. Tokens and components are an important part of design systems. But they are an output. They are the byproduct of unifying separate, but related patterns in an interface. The thinking behind that output is the real value—and its applications are endless.

This realization took the shape of my sites’ build scripts. They were unnecessarily disparate. Different build destinations, different naming conventions, some would clear the build directory, others wouldn’t. These variances didn’t lead to better outcomes. They were only a distraction.

I refactored my build scripts to work from a common codebase. All sites follow a standard convention and structure.This wouldn’t traditionally be considered a design system effort. But it required the same thinking and returned the same benefits. If it quacks like a duck…

This experience cemented my opinion. System designers should expand beyond current definitions of design systems. Find other instances of related-yet-unnecessarily-disconnected things. Connect the dots. Create order from chaos. Reap the same rewards.

There’s a whole world outside our little house we’re cloistered in. We just need to step out the door…

Don’t take my word for it

Now you know what I learned, but the lesson here is to understand for yourself. Get your hands dirty, form your own opinions based on direct experience. Don’t buy what I or anyone else is saying until you’ve lived it yourself. I bet it’ll impact your thinking more than you know.

I’m skeptical of AI. Less because of the tech and more because of those ushering it into the world. Behind the bluster and marketing-hallucinations is something that could provide value. But, unfortunately, it doesn’t appear headed in that direction.

I’ve been noodling with various AI tools off and on for a year now. Most of my experiences have not been what I’d consider extraordinary. But there are three use cases that I think have real potential.

Your own brain in a jar

I’ve been using Google’s NotebookLM for the past few weeks and feeding it all my public content. The results are vacillate between so-so and promising. Nonetheless, I must laud Google’s execution of AI with this tool. NotebookLM focuses on referencing existing data as opposed to conjuring up slop. I’ve seen more nuanced and sophisticated responses as the corpus of data increases. It’s becoming a useful utility to query my past thoughts/musings. Essential? Not by a long shot, but intriguing.

This could be a valuable utility in the corporate setting to train on team meeting transcripts. A team can rack up dozens of meeting hours a week. Having a team brain-in-a-jar has limitless applications. It can enable quick recall, act as a temporary proxy when people aren’t available to respond—just to name couple. It also has limitless ethical risks. I’m less enthusiastic of this application given its penchant for abuse.

But, I see potential as a sole user my own information, I see potential here. I plan to continue exploring this avenue.

Reductive AI could be incredibly helpful

I have a growing belief that speed is not a problem within tech. Improved tools and processes have made productivity higher than ever. Hell, design systems can generate 20%-40% efficiency gains on their own. I’m starting to wonder if all our progress in efficiency is, in turn, creating inefficiency. Now that things can be output so quickly, we’re struggling to keep track of all that extra stuff.

I don’t think we need technology’s help in making more stuff. Stuff deficit isn’t our problem. The last decade of tech has been a continual slide towards more. More features, more meetings, more messages, more documents. More everything. In my experience, the majority of that stuff is unorganized and/or unnecessary. Generative AI is dousing our existing dumpster fire with napalm.

Instead of using AI to make stuff, we should be using it to get rid of stuff. AI can help pull signal from all our noise. I see three main themes where AI could help here:

1. Aggregation: It’s hard to keep track of what everyone is working on. The larger the company, the harder this becomes. AI could improve visibility through aggregating team activity and output. I dream for a way to see what every design team is up to without resorting to hours of Figma-stalking. But it’s not only a design problem. It’s universal and acts as a constant impediment.

2. Organization: One thing I’ve been noodling on is the idea of corporate librarians. This imaginary role would collate company information for logical access. Our current reality of corporate wikis and document collections are a mess. If corportations won’t librarians, the second best option is to have AI take a crack at it. My hope is a well-trained AI could continually organize, index and prune company data. Maybe then finding that one HR doc wouldn’t be like embarking on an odyssey.

3. Extraction: We have so many documents. So many notes. So many transcripts, emails, messages. Imagine simplifying the buffet of artifacts into more digestible tapas—with citations. I worry about hallucinations, but citations should blunt this concern. And any potential to reduce information clutter is worth a bit of risk.

Outputting average as an advantage

People write differently. Often very differently. There’s a slim handful of company employees that know its content/writing guidelines. Even less follow them.

One of the criticisms of AI is that it produces “average”. But average can be good. It’d be great if all company documents were written the same way. Same typeface, same styling, same indents. Same verbiage, same tone. Same everything. I will never let AI touch my personal writing, but I would understand and welcome it in a team environment.

There’s tremendous upside to removing the cognitive overhead of learning someone’s “written dialect”. There’s even greater upside to removing thousands of them.

None of the above feel generative

I understand the potential of AI—I’m not that much of a dummy. But the biggest AI hallucination is us thinking it’s something it isn’t. I remain stubbornly convinced that we’re steering this tech in the wrong direction. I think there’s a world where AI could provide true utility without much of the (perceived or real) SkyNet vibes. But those applications are far smaller in ambition and much more boring. So I’m not holding my breath on my ideas taking off.

We have made a mess of the internet—on many levels. We may have backed into a way to fix it with AI. Ironically, and also unsurprisingly, we’re choosing to double down on more of the same.

I’m hoping for the best and planning for the worst.

Color is both potent and volatile. What’s vibrant to one person may be gray to another. A certain hue can mean good luck in one culture and uh oh in another. What reads as violet on one device looks like navy blue on another. Some people really like green. Others don’t. Why? Because.

Many colors clash. Put red and magenta together and look at it for 30 seconds. I dare you. Sometimes an interface controls every pixel on the screen. But usually not. A beautiful color in isolation can look like garbage placed next to the wrong photo.

A lot about color falls under “it depends”—which makes it tricky. It’s super effective. Except when not. That a tough foundation to build from.

An interface is a white wall

The folks who designed the MoMA knew what they were doing. If you haven’t been, prepare to see a lot of white walls. Those white walls are a figurative blank canvas to display art. The walls stay out of the way to let the art be art. Interfaces play the same role—a means to an end.

Think about some of the most-used software today. They’re galleries for content. Content made people who didn’t design the interface. Imagery, videos, avatars - all likely using a lot of color. Sure, there are situations where an interface needs snatch attention. That’s typically when I see color show up the most. But, there are more alternatives.

Like words. It turns out words are great at communication. Start there. Words are a gateway drug to typography. Those two, plus spacing, pacing, proportion, contrast and form do wonders. All without needing to dip into color.

Gray goes a long way

An interface that relies on color to work is an interface that doesn’t work. I advise starting design in grayscale to ensure it works there first. Yes, that limits options, but there are 256 shades of gray to work with. That’s a lot. Most folks (including myself) aren’t using those 256 options to the fullest.

Every single one of us are guilty of slapping down white or black and moving on. That’s a problem because white and black are hard limits. There’s no up or down to go from there. What happens when an element needs stronger emphasis than black or white? Color is the obvious fallback.

I avoid using black for my default positive value. I pull the shade back to feel like black when set on white but still maintaining separation when paired with pure black. This gives extra room to go to 11 when needed. Color has a hard floor/ceiling like black and white. There’s no room for 11 once color intensity is maxed out. I recommend the same approach when using color.

Shocker: Increasing the intensity of a color intensifies its visual prominence. And this can be done in a way that will works in grayscale.

Errors come in all sorts of shapes, sizes and severity. Some errors are oh shucks, others are OH SHIT. Color can be a great supplement to distance shucks from SHIT.

Restraint is key

My personal style is to remove color whenever possible. I acknowledge that I’m on the extreme end of the spectrum. No, I do not think this is appropriate for all use cases. But a little color can go a long way. Think better use of less as opposed to more on top of more. That’s a recipe for trouble.

Keeping two colors working together isn’t too tough. Keeping 144 working together is not going to be fun.

I’m partial to quantitatively dissecting design. It offers a different lens to put work through to separate the feels from the reals. I like applying budgets to design work. Not as a draconian, freedom-squelching overlord. Rather, something that keeps people aware of decisions to avoid going down a bad road. Sometimes a small nudge towards restraint can avoid big hassles.

I’ve begun to experiment with tools to color budget. These tools would track color usage on a screen and relay it’s under or over budget. But the devil is in the details. For example, gray-blue is not the same as BLUE-blue. Those two colors should have different “costs” in a budget. A lot needs to be figured out, but I’m intrigued.

Which square draws more attention? Hint: It’s not the bigger one.

This is something I want to test out on my own work to see how it changes my process, if at all. Things like spellcheck are now a given in writing tools. I want to start trying to use spellcheck-equivalents in my design process. I’m hopeful this can ensure I’m being economical in color usage.

Color is great—no, really

It may seem like I have a beef with color. I guess I do to some extent. Not with color itself, but how it’s used. I think that comes down to underestimating its potency and volatility. By all means, use color. But treat it like using a four letter word in an all-hands meeting. Make it count.

You can find stimulation in strange places. I watched The Batman with comic-book-movie expectations and little anticipation. Then I watched it again. And again. Numerous times. Its style grabbed me. Then I watched the Nolan-era Batman movies to see if it caused the same reaction. Nope. It seemed worthwhile to dig into why.

I dissected the elements of The Batman compared to Nolan’s The Dark Knight to examine each style. With any luck, I’d glean some nugget of insight.

Silence says something

The Batman’s dialog is sparse. Conversations are spread out. Lines can often be one or two words. A lot is said without saying anything. The brevity alone developed a mood. The Dark Knight in comparison felt heavier in dialog. It wasn’t bad, but noticeably more of it.

I parsed the subtitles and visualized all lines of dialog in each movie to better understand their differences. The Dark Knight is visualized on the left and The Batman on the right. The diameter of each visualization reflects duration given The Batman is considerably longer (165 minutes versus 138 minutes). Each line in the visualization represents a line of dialog. Its length reflects the line’s number of words.

The subtitles of The Dark Knight (left) and The Batman (right) compared.

The Dark Knight is much more dense in dialog with far fewer breaks. In contrast, The Batman’s dialog is more spread out with more instances of shorter dialog.

According to this analysis, The Batman is considerably lower than the median number of spoken words by any genre listed in that article.

The examination confirmed the initial observation—nearly a third less dialog per minute. The Batman’s skews towards a noir crime thriller which only accentuates its contrast to The Dark Knight. Less talking gave other elements prominence. The atmosphere played a larger role. I understood how succinct language impacts user interfaces, but this further reinforced the power of brevity.

A persistent aesthetic

The look of The Batman has been discussed ad nauseam. Of note is the narrow use of color used throughout The Batman. It’s dark, it’s desaturated save for the occasional bloom of red or orange. The Dark Knight in contrast had a wider spectrum of hues, saturations and brightnesses. Scenes’ color grading varied realistic and stylistic. The colors of The Dark Knight never felt discordant, but more varied.

Below are frames from similar scenes in each movie. First being The Dark Knight, the second The Batman. I observed less color continuity in The Dark Knight compared to The Batman.

Scenes from The Dark Knight ©Warner Bros.

Scenes from The Batman ©Warner Bros.

I attempted to get confirmation by extracting dominant colors of every second from both movies. Each vertical line represents each second’s frame.

The Dark Knight has a diverse spread of hues, saturations and brightness.

A timeline of The Dark Knight’s dominant color palette, broken down by second.

Whereas the Batman is far more suppressed—especially in situation and brightness.

A timeline of The Batman’s dominant color palette, broken down by second.

Using the dataset of unique colors taken from a frame every second, I correlated the following color palette ordered by frequency:

The most prominent colors from The Dark Knight (left) and The Batman (right), ordered by frequency.

There’s a dramatic difference in range of lightness and saturation between the two films which leads to less variance in overall palette. The Batman is dark. For some, too dark. But that stylistic constraint helped create a cohesive visual style.

The wider range of colors in The Dark Knight aren’t distracting, but they didn’t reinforce the atmosphere. Shots of Gotham’s skyline in The Dark Knight could have been a skyline from any city. The constant darkness of The Batman gave its environment a personality of its own. Gotham never broke character.

It’s tempting to inject color in the design of experiences, but this movie is a lesson in the value of less. It’s surprising just how little is needed.

Subtraction by addition

The Batman is known for its use of vintage and intentionally-detuned lenses. Those lenses introduced corner distortion and sharpness falloff which limited the frame’s “workable” area to its center. The film also went through the process of transferring digitally-recorded footage to film to introduce grain and overall softness. There’s a clear difference in acuity, which made The Batman more visually pleasing to me.

The Dark Knight in comparison appears technically flawless. Scenes are sharp with no distortion or aberration. I would have assumed a “cleaner” frame would be less distracting, but I had the opposite response.

Take this scene from The Dark Knight. The frame is technically clean and sharp. Which brings attention to the antennas, building details and Chase sign in the lower-left corner of the frame. Those details don’t add value.

Scene from The Dark Knight ©Warner Bros.

In comparison, almost everything in the frame below is out of focus. Its corners are heavily distorted. Paradoxically, The Batman reads cleaner in composition because of its lack of detail.

Scene from The Batman ©Warner Bros.

In addition to suppressed focus, The Batman frequently shot in rain. The random streaks of rain created visual interference further softened background detail, which gave the main subject more prominence.

Scene from The Batman ©Warner Bros.

The results from a sharpness detection script confirmed just how much softer The Batman was compared to the The Dark Knight. Each column represents a minute in the film with each dot being a second’s frame sharpness. The sharper the dot, the sharper the overall frame. The Dark Knight shows a strong variation between frame sharpness.

A second-by-second analysis of frame sharpness in The Dark Knight.

The Batman is significantly softer both in magnitude and consistency from frame to frame.

A second-by-second analysis of frame sharpness in The Batman.

As an interesting comparison, below are the sharpest frames detected from each movie. The Dark Knight has a large depth of field with seemingly everything in focus.

Scene from The Dark Knight ©Warner Bros.

Whereas even the sharpest frame in The Batman is considerably softer in comparison. That lack of detail ends up saying more.

Scene from The Batman ©Warner Bros.

I am dogmatically reductive which made this result fascinating. I believed that simplicity relied on removal. I still believe that—but sometimes the best way to remove is to add. The Batman’s additive process of lens distortion/falloff, film grain and background visual noise removed more significant detail. I’m unsure how I will employ this in my work, but I’m eager to try.

Less moving, moving parts

The Batman stood out with how simple the cinematography was. There were less cuts, less camera movement. The viewer was given an unchanging scene to simply take in. It was vindicating to find this quote:

We had such great sets. We had such great actors. It’s such a great script. I would ask the question, why do you have to move the camera for no reason? If you’re moving the camera for no good reason, I feel like you’re doing all of your parts a disservice.

—Greig Fraser

After watching The Batman, it felt like The Dark Knight was in constant movement. More cuts, pans, zooms and shake. It was constant stimulus.

I wanted to see just how different the style was. I ran a visual diff from a frames a second apart. I expected a difference, but the magnitude was surprising.

First is the second-to-second frame difference for The Dark Knight. Each column represents one minute of film. Dark purple represents small change, where bright yellow represents high change. The Dark Knight has significant deltas.

Visual diff by second in The Dark Knight.

The Batman is substantially muted in comparison, with only a single 3 to 4 minute stretch having the similar levels of change.

Visual diff by second in The Batman.

My hypothesis is that the lack of change in The Batman is accentuated by its dark color palette and suppression of detail. All of these elements converge to create a gestalt stillness. I think this stillness gave room for the viewer to more effectively take in its atmosphere and style.

Much confirmed, but also some surprise

Running these two movies through its paces clarified why I enjoyed The Batman’s style so much. The movie was long, but it employed constraint and consistency that amplified its style into something I considered noteworthy. The movie clearly had a vision that was followed from start to end. This isn’t a judgment on the worth of either movie, but I do find The Batman to be better cinematically executed based on consistent constraint.

This exercise wasn’t just a reinforcement of previously held beliefs. The Batman’s use of additives to simplify has weakened some strongly held beliefs—especially in regards to my photographic work. To be honest, I wish I would have come to this conclusion roughly nine years ago, but it’s better than never.

Epilogue

Designers are addicted to inspiration—which isn’t a problem if it’s the first step in a larger process. Inspiration alone lacks understanding behind the reaction. Inspiration requires examination.

Developing a point of view on design is essential to fostering one’s own style. The things that inspire you should be broken into a million pieces to see what makes it tick. That lack of understanding keeps you at the mercy of basic mimicry.

This post attempts to provide an example of examination. Both for myself and others. I give designers two main suggestions to help their growth: 1) Dissect others’ work that resonates with you so you can take its elements to make something of your own. 2) Write about your thoughts to fortify your thinking and communication.

Do I think every designer should go through this length with design that catches their eye? Absolutely not. But I do think following an abbreviated process of observation, examination, validation is invaluable for growth.

It would have been easy to say, “The Batman has less dialog and feels simpler.” But, did it actually have less dialog? If so, by how much? It was important to understand if my observations were accurate. How would it help if my point of view was shaped on false pretenses?

I do not think everything can or should be quantified, but I do think it should be examined. While I’ve spent considerable effort quantifying these two films, this analysis remains an interpretation. And through this interpretation, I have just that much better of an idea of what I consider to be good design. I encourage you to do the same.

Prologue

I’ve wanted to design my own typeface for nearly two decades. Now seemed like as good of a time as any. I thought it may be worthwhile to document this process and therefore I’m going to chronicle my process in this post. With any luck, the final update in this post will be when I’m “finished”.

Why write about this? First and foremost, I want to track what I learn through this process so I can refer back to something if I’m foolish enough to do this again. Secondly, I thought this post could encourage others to give something like this a try as well. Who knows, I may just end up with something decent—and if I can do it, anyone can.

Friday, November 3, 2023

In order to prep for my foreray into type design, I watched most of this series on how to use Glyphs to create a typeface. I viewed close to half of the videos, so I’d say success is all but guaranteed.

I chose Glyphs as my tool of choice as it appears to be the best of what I’d say is a mediocre set of options. I spent the first hour or two in a cage fight with the app to understand how to draw paths. It’s fine, but there was still a considerable learning curve given I cut my teeth on Illustrator and still consider that to be the finest vector drawing tool I’ve used.

I’ve decided to design a sans serif for this project because I’m not a complete masochist. I’m unabashedly reverse-engineering existing typefaces to help form my letter forms. The two fonts I’m using as my reference point are Avenir and Helvetica Nueue. Yeah, those are two very different typefaces, but there are distinct stylistic points of interest in each of them. I’d like to pull what I like about each into my font.

Saturday, November 4, 2023

I learned that all good typefaces start with the lowercase n, so that’s where I started. I don’t particularly like it.

I think thicks and thins will need more contrast, but it’s good enough for the time being. One nice thing about starting with n is that you basically get h for free. The letter m is a little more complicated. I learned that the first hump should be slightly more compressed than the second. I’m not entirely sure why yet, but I’m just going to run with it.

I’m starting to schedule out a letter (or two for each day). I’m hoping that I’ll be able to put one or two hours a night into this project after we get our daughters to sleep.

Sunday, November 5, 2023

OK, so I devised a plan and that’s to race towards a full coverage of all glyphs and refine from there. I’m trying not to dwell on how much work this is going to be—especially when taking weights and italics into account… I’m hopeful that making solid progress in the weeks to come will give me the momentum to keep this going. And speaking of progress, I’ve landed a first pass on over 40% of the glyphs I’m planning to design. Some of them are hot garbage, but they exist and that’s what I’m going for.

Here’s a sample of my typeface interspersed with other commonly used sans serif fonts. No, I’m not going to say which one is mine.

Maybe I’m delusional, but I don’t think my font stands out as clearly worse than the comparing fonts. I definitely see things that need to be improved, but all very doable. I’m also starting to better leverage Glyphs as a tool. It’s by no means sparking joy, but the grudge-match phase is behind me. I’m semi-hopeful that I’ll have a first pass of letter forms complete by the end of the next weekend.

The most interesting tidbit I learned today was that horizontal strokes need to be a smidge thinner than vertical strokes as horzontal strokes appear optically thicker than their counterpart. Note to self: you have a lot of horizontal stroke clean up in your future…

Monday, November 6, 2023

Not many updates for today. However, there are two big takeaways. The first, is that I’m firmly convinced now that I can do this. I can’t guarantee that the final outcome will be anything to write home about, but it will get made.

The second is that I’m quickly coming to the conclusion that I’ll end up having to make a font testing tool for this project. I’m learning that Figma takes some coercing to detect a font update and online tools are fine, but nothing to write home about. I’m looking at the the following resources as a starting point:

• Spacing templates
• Font testing page
• adhesiontext.com

Tuesday, November 7, 2023

I was able to fit in time to get some simple symbols out of the way. It’s the kind of no-brainer task that can happen after a full day of work that doesn’t take a ton of thinking but keeps progress humming. I’m well past the 50% mark in terms of glyph coverage.

I don’t think it’s even worth sharing examples given it would just be a smattering of horizontal and/or vertical lines. Lines are easy. Curves are not. I know I have a lot of pain ahead of me with the remaining lowercase letters.

Thursday, November 9, 2023

No work gets done when there’s a sick kiddo in the house. I’m hopeful that I can make some serious progress with the three day weekend.

That said, I’ve been chipping away at some of the simpler symbols here and there before I go to bed. Here’s some of the progress made since Monday.

The more I noodle on this project, the more I know this is just going to take a lot of time.

Friday, November 10, 2023

Today was a big day, so much so that I’m convinced I’ll have a full draft character set by the end of the weekend. I have all capital letters in a first draft phase. Capital S was a pain in the ass and will likely need numerous tweaks to get to a better place.

I was able to spend some general refinements related to stroke angles. I’m trying to limit the number of angles I use to help with overall visual continuity. So far I’ve limited myself to the following angles: 17°, 30°, 40°, 49°, 55°, 60°, 69°, 75°, and 83°

That seems like a lot (and maybe it is), but so far each has felt necessary. I’m going to try to whittle down these angles in the days/weeks to come. There’s plenty to improve upon, but I’m still pretty excited with the progress.

Saturday, November 11, 2023

Well, I’m a little more than a little surprised, but I got all my initial characters drawn. The lowercase a and s were major pains and they’ll need massaging. Nonetheless, I never thought I would get this far this fast.

One thing that I put a lot of effort into is to use as few vector points as possible—for a couple reasons. The first is that is makes curves cleaner in general. This is something I learned a lifetime ago when drawing a lot of icons. The second is that it keeps the font’s file size down. Less points, means less information. Less information means a smaller file size.

This was a major milestone and I couldn’t be happier. Next up is building the bold weight for the font!

Sunday, November 12, 2023

The sick kiddo got me sick, so I’m not putting any time into the typeface today. However, I started to broach the creation of a bold weight. What I’ve learned is that I have ink traps in my future. My lowercase a in particular is in dire need of an ink trap.

One thing that I’m really happy I did was to design my regular weight to be on the lighter side. I did this because I don’t use light weights a ton and so I wasn’t interested in building out versions of every glyph for something I’d never utilize. I plan to make this font variable and so I’ll likely up the weight a smidge for body copy—which is totally A-OK for me. I’m hopeful this will have cut a ton of time and effort from this project. We’ll see…

Wednesday, November 15, 2023

Work and sickness have slowed progress down, but major progress has still been made. My big focus has been on spacing. And I’m not going to lie, I leaned heavily into reverse-engineering the spacing of other fonts to speed up progress. Make no mistake, my final result went through my own translation, but I relied on the logic from other fonts to drive me work. This is a big part of why I knocked this out with relatively little effort.

One important note—while I have spacing in a generally decent space, I have not touched kerning. And I know that’s just going to be a ball of yuck. An important yuck, mind you, but yuck nonetheless. Knowing myself, I’ll likely wait as long as possible to do that, so next I’m on to creating the bold weight.

Thursday, November 16, 2023

OK, bolding this font isn’t a complete cakewalk, but it’s also not as tough as I initially expected. Glyphs gives you a nice head start with the ability to offset outlines. The big thing to know about font weight management is that you need to keep the same number of points in each weight. Otherwise things break. Luckily, I made two initial design decisions which paid off nicely. The first is that I put a lot of focus in using as few points as possible in each glyph’s vector form. The second is that I started with a pretty thin (perhaps too thin?) stroke thickness for the regular weight.

This meant that there was plenty of room for each glyph to expand without colliding into itself and less points in the vector path meant less opportunities for points being awkwardly close to each other and creating yucky paths. I have had a few issues pop up in the process so far (ahem, lowercase a…) but far less than I thought would be the case.

This weight range is plenty for my needs, and so I’m getting oh-so-close to having Regular and Bold master weights complete. I also toyed with variable font export. And the progress? Well, look for yourself.

On a completely unrelated topic, I once again need to give a tip of the cap to Remotion which enabled me to programmatically animate the font weight of my typeface and then render as a video. Such an amazingly cool tool that I plan to utilize quite a bit in the near future.

I’m hopeful I’ll have weights in a first-draft form by the end of the weekend. I never would have imagined I’d make this far by this point.

Friday, November 17, 2023

No major updates from today, but I do have my first regret which is to not have accounted for ink traps earlier on. I now have a ton of retrofitting of existing glyphs to include ink traps. I’m hoping like hell that doesn’t break anything…

I also have a roster of characters that need to be unhit by the ugly stick. Namely, a, e, m, 2, 4, 7, and &. There are plenty others, but those are the most egregious—especially the m.

So, this weekend will be all about bolding, ink trapping and un-uglifying some key glyphs. I’m crossing my fingers that I make decent progress.

Saturday, November 18, 2023

Well, I did it. I finished up the bold weight for all glyphs in the typeface. Glyphs made this about as easy as you could expect. The unnerving part of this process was joining all overlapping shapes of each glyph into a single path. That was a point of no return.

The lowercase a was a complete pain in the ass to get working due to the bold weight’s paths getting modified during the bolding process. Learning how to debug that was a whole process in and of itself. Many, if not most glyphs were easy-breezy though.

In addition to finishing up the first pass of the bold weight, I also un-uglied some of my worst offending designs. Below are below/after/difference screenshots.

Lowercase a had one curve that were way too strong. I chilled that out and while the change is hilariously subtle in the image below, I think it makes a big difference.

Lowercase m was one of the first letters I made and it shows. The point between the two humps was way too low. That got resolved.

The number 2 was far too curvy. I made it so that the bottom was more orthogonal. It feels far more stable now.

Number 4 was just too narrow. I widened it up a smidge to appear more balanced when paired with other numbers.

Number 7’s thins were just too thin. I just reduced the line contrast a bit.

So, now that those are done, I need to chip away at my new least favorite glyphs, namely &, ?, and 3. I also plan to italicize the weights next. I’m honestly a little dumbstruck that I have a semi-working typeface in this amount of time. With any luck, I’ll have something really fun to share tomorrow.

Sunday, November 19, 2023

Italics: Check. Kind of.

It turns out Glyphs makes it really easy to auto-magically italicize a glyph, but there clearly needs to be some more human TLC put into this. This phase hasn’t hit the TLC phase, but it’s nonetheless great to have basic italics added to the font.

Here’s an example of italicized text.

I’m able to render out what italicized text looks like directly in this post because I’m now using the font on this blog. I’m going to have to alter the design a bit more to optimize for the new typeface. I’ll get to it.

One thing I’ve been working on behind the scenes was to build some tools to proof each glyph. There were some existing tools to export proofs as a PDF, but that just didn’t sit well with me. I wanted something more web-based to proof the typeface given it will primarily be displayed on the web. So, I wrote some build scripts to generate generic HTML that can be styled to proof a typeface. I’ll share what I have on pjonori.codes once it’s a little cleaner.

Until then, I had the chance to style my proofing HTML into a showcase page for the typeface. Given this is my first typeface, I’ve named it Olivia Sans after our first child. I never had wild aspirations for this project. I simply wanted to make a typeface I liked that would hopefully be something my daughters could use for their own creative projects. As far as I’m concerned, that’s success.

And yes, our second daughter is already lobbying for her own font. I’m hopeful there’s a Gianna Serif in her future…

Monday, November 20, 2023

Oh man… Kerning… This is just going to be a lot of work. I’m using the Glyphs’ kerning tutorial as my starting point. My guess is this is going to just be a pain in the ass. I’m hopeful I’ll have an update by the end of the week.

Monday, November 27, 2023

Thanksgiving and some family issues made updates a little thin since the last post. However, I did put an ample amount of time into kerning. And, it’s much better than what it previously was. Most of the work was around how a, c, e and o sat next to F, K, k, P and Y. There’s still plenty to work on, but it’s less glaringly awful.

Kerning is a trudge at baseline, but the fact that kerning values cannot be automatically be applied to all masters makes it even worse. Luckily, there’s a script to copy all kerning values to all masters. I used the following script graciously shared here:

sourceMaster = Font.masters[0]
targetMasters = [Font.masters[1], Font.masters[2], Font.masters[3]]

sourceKerning = Font.kerning[sourceMaster.id]
for targetMaster in targetMasters:
	targetKerning = sourceKerning.deepMutableCopy()
	Font.kerning[targetMaster.id] = targetKerning

So, now words like “walked” should look much better than they used to. I will continue to chip away at kerning, but it’ll likely be small, continuous improvements as I see them as opposed to some big Kernapalooza event.

On another note, I’ve been working to clean up my scripts for generating typeface proofs. My goal is to release the code—I can’t guarantee it’ll be useful, but it worked for me.

Wednesday, November 29, 2023

It’s becoming a game of nanometers now where I’m making smaller and smaller adjustments to individual glyphs based on how much they annoy me. Lowercase a will likely be in perpetual improvement mode. I look at Helvetica’s lowercase a and if I can get even infinitesimally close to its form, I’ll consider it a success. I finally isolated the thing that has been driving me nuts—the top and bottom of the letterform weren’t balanced. The top was far too recessed and once I pulled the two closer it immediately looked better.

I was also able to remove an unnecessary point from the vector path, so not only did I improve upon the form, the font file size is now just a smidge smaller as well!

Thursday, November 30, 2023

No typeface updates, but I did end up publishing the generator script I used to make my Olivia Sans specimen page. It’s rough, but it’s a start. I hope to make improvements as this project progresses.

Thursday, December 7, 2023

As you can see, updates are slowing down because progress is slowing down. I’m officially in the tuning phase. I cleaned up the ampersand, question mark and some really subtle adjustments to the number 3. I also found a stray spacing issue with my lowercase y. All of these are minor, but they’ll no doubt add up.

Sunday, December 10, 2023

One big update and a small one as well. I finally took the time to learn how to properly export the font. I now have a functional typeface that I can use in my design tools. That’s been bugging me for some time. While it’s not a direct improvement to the design of the font, it’s pretty damned important nonetheless.

The smaller update is that I improved upon the number 2. In all honesty, nearly the whole range of numbers need work, but I’m glad I have one in a better place. My guess is that I’ll be making numerous improvements to all numbers in the following weeks.

Sunday, December 21, 2023

I made some minor updates to the numeral 3 and uppercase K. Both glyphs were only minimally adjusted to be completely honest. Italics remains a hot mess. That will be the next big focus in the new year.

Friday, January 12, 2024

Progress has slowed as you can see, but that’s because the typeface is meeting my needs for the most part. The italics remain a wart on the overall design, and so I recently cleaned up the uppercase P and the numerals 2, 3, 5, 6, and 9. That addresses most of my discontent, but there’s obviously ample room for improvement. Here are a couple that come to mind:

• My ampersand is gross. I wish I had kinder words, but I don’t. I’m mulling to take that glyph down to the studs for a full rehaul.
• There’s literally no difference between my uppercase I and lowercase L. That’s a problem—this is the kind of thing I chirp about all the time in UI design. What is a typeface if not an interface for language? So, I need to get to that as well.
• I’m still not entirely happy with my lowercase A. The problem is I can’t yet diagnose what about the letterform is causing that reaction. I’m hopeful I’ll get to the source of this and address in the following weeks.
• I don’t like the full vertical bar in the dollar sign. It makes the form too busy, especially at small sizes. I’ll likely address this sooner or later.

So, progress has slowed, but there’s still plenty to do. I also have hope that I’ll eventually break ground on a serif font.

The first collection of three dots has three connections. Obvious. The second collection has nine dots, but now there are 36 connections. The last collection of dots has 27 dots, but the connections have ballooned to 351. This phenomenon is called a combinatorial explosion. It appears exponential in nature, but for the math nerds, it’s actually polynomial. Honestly, for the sake of this article, it doesn’t matter.

Combinatorial explosions are complexity explosions

Those who work on any kind of system know what combinatorial explosions are even if they haven’t heard the term. As pieces in a system increase linearly, its connections increase much, much faster. Consequentially, the system’s complexity grows much, much faster. Spoiler: That’s bad.

Let’s take the “Hello world” of complexity explosions for design systems—color palettes. The best color palette I made for a design system had seven colors. Was it constraining? Absolutely. But it was also manageable from a systems standpoint and highly approachable/understandable for those who used it. However, most systems have a hundred colors or more. Below is a visualization of all the 2-color combos in 7, 25 and 50 color palettes.

I threw in Material’s 190 color palette in the table above to show how complex this can get in actual reality. The more complex the combinations become, the more large color palettes become essentially incomprehensible. How many 7-color combinations does a 7 color palette have? One. How many does a 190 color palette have? 1,585,940,245,560.

Piles of stuff are unpredictable

A system is a system because its connections work together. As a system grows, it becomes increasingly difficult to understand how everything works—or if it works at all. This rears its head in general unintelligibility, brittleness and unpredictability. At which point the system has officially devolved into a pile of stuff.

Unpredictability in particular is scary. Because unpredictability, is well, unpredictable. Unpredictable can result in good, bad, or horrible. It can be a combination of the three one minute, then none of the above the next. Which is chaos. And chaos is bad.

The ways we avoid complexity can also create complexity

But have no fear! People have honed plenty of tools to stave off complexity. The bad news is that the cure can be worse than the disease. That’s not to say these tools are inherently bad, but they have limitations which are often summarily ignored. Below are a few:

Compartmentalization obfuscates complexity

Compartmentalization is the go to when trying to simplify systems. It’s a great tool to turn one big, monolithic system into a system of smaller, more manageable sub-systems.

Compartmentalization is your basic org chart. The org chart is the quintessential definition of breaking a huge system of things (people) into smaller, more digestible sub-systems (teams). Some may question whether the org chart is a good example given their challenges. That’s the point.

One problem with org charts is they can create artificial barriers between people which make it harder for them to work together. These partitions don’t really exist in people’s day-to-day work, but are created anyway in the goal of simplification. Teams become siloed, overly focused on their own goals and lose visibility of the greater direction.

That’s the rub of compartmentalization. It can be difficult to create “clean cuts” where all important connections remain intact. This can lead to a disjointed system where elements don’t feel like they’re working together—because they aren’t.

Reducing connections moves complexity around

Just because two pieces in a system can connect, doesn’t mean they should. Explicitly paring down connections between pieces is another clear cut way to reduce complexity.

This can be achieved by restricting component APIs to only accept a subset of options. A system may provide 100 colors, but that doesn’t mean all of them should be available for every component. This significantly reduces permutations in a system.

On the downside, there’s added cognitive load to understand which pieces connect, and how. This load increases by how unique each set of options are for each component. Another downside is that rules can get complicated fast. One rule of thumb is to avoid rules with clauses. Once design systems start having rules like, “Do ____ except when ____ unless ____” you should just assume someone out there is losing their mind trying to understand or already gave up.

It also begs the question, “Why have 100 colors in the first place if 90 of them can’t be used half the time?” Which is a good question.

Abstraction creates layers of complexity

Another approach is to just make a subset of the system available to use. A simple, approachable public system is made available to all—driven by a bigger, gnarlier private one. This could also be seen as an extreme level of compartmentalization.

This approach creates less cognitive load—especially for beginners. The user benefits from a robust system under the hood, but with far less options to get themselves into trouble.

But of course there are downsides. First off, a public and private system means more systems to deal with. Secondly, abstraction risks long-term confusion as people begin to see that they aren’t provided all the options. That will beg the questions, “What are all those other options not available to me?”, “Why can’t I use them?” and, “Why does the system get to play by a different set of rules than me?” Which are all good questions.

Reduction is the only real way to reduce complexity

The tools outlined can be effective when well-employed. But math is math. Linearly remove pieces in a system and the connections decrease much, much faster. Treating the symptoms of complexity often just redistributes it. In short, the best way to avoid the pitfalls of complexity is to avoid complexity altogether.

But make no mistake, reduction ain’t no walk in the park…

Stifling order or cataclysmic chaos

Robin Rendle mentioned that design systems are hyperobjects. For the uninitiated (which included myself until a few weeks ago), hyperobjects are things so big that it’s beyond human understanding. I don’t think all systems are hyperobjects, but plenty are. I don’t think it’s interesting whether systems can by hyperobjects as much as how quickly they can become one. One second, you’re fine. The next, chaos.

I don’t know many people who find chaos appealing. Why then is it so prevalent? Here’s my theory: we’re willing to accept the mess because it’s comfortable.

Avoiding chaos seeks out conflict. Complexity explosions are fueled on “Yes” and starved by “No”. “No” brings dispute. It’s painful, exclusionary, stifling. It won’t make you the life of the party. And it typically takes incredible discipline to sustain.

Uncomfortable as “No” may be, it’s ultimately the simplest way to keep an explosion from becoming an explosion.

• 1: Yes, this is a blantant adaptation of Arthur C. Clarke, but there was no way I would craft a better way to say it. ↩
• 2: Total colors from Material’s color palette. ↩

designsystems.news in all its glory

I launched designsystems.news in April of 2023 as a weekly editorial on design systems. I needed space for more reading and thinking, but knew that wouldn’t reliably happen without an intentional process in place. I made the site to keep me learning and accountable. But it would fail if it was too much work.

So why write about this? It’s certainly not for self-aggrandizement as the project isn’t worthy of it. Rather, the goal is to show what simplicity can yield in concrete terms.

Simple concept begets simple design begets simple execution

I had a clear constraint of time and worked backwards from that. Essentially anything that could be removed from the project, was. Its concept, format, structure, aesthetic and implementation all aimed for extreme simplicity. In practice, this meant:

• The concept behind the site was as straightforward as it gets. It’s editorial “news” about design systems. I got the “designsystems.news” domain to avoid the need to describe its purpose. The domain tells you all you need to know.
• The format of a weekly links with short-form observations and quotes is, well, simple. It’s easy to mess up this format with adding imagery, summaries or whatever else. No thanks.
• The site is one page. It has no navigation, no search, no pagination, no categories, no nothing else. The layout is so simple it doesn’t require CSS breakpoints to be responsive.
• The design of the site has three colors, no custom fonts, no sophisticate type ramps, no visuals. It’s admittedly austere.
• The site is one request coming in at ~10 KB (as of May 2023). There’s no JavaScript. The (little) CSS used is added to the head and the header SVG is inlined. Any device on any connection can effortlessly access this site. Entries are compiled from (simple) Markdown meaning it unfortunately required a build script. I begrudgingly have three NPM dependencies, which ideally would be zero.
• All of the above has enabled a simple relationship with the reader. There’s no tracking, no cookies, no upsell, no “Sign up for my newsletter”, no “Follow me some godforsaken social network”. No strings. Just come and read.

Truth be told, it could be simpler. Perhaps one day it will.

Shipping nearly nothing turns out to be simple

Removing so much resulted in removing many problems typically faced when making a website. One page meant no information architecture or navigation schemes. No JavaScript meant no complicated toolchains or build scripts. Minimal NPM dependencies meant minimal maintenance. No images or fonts meant no optimization, performance-tuning or FOUT. No tracking, upsells or hidden agendas meant no GDPR compliance, marketing or general nonsense getting in the way of the content.

All that simplicity enabled the entire project to go from idea to deployed in roughly 5 hours (including 2 hours of muddling through regular expressions). Posting updates takes minutes. Reading articles is far and away the largest time commitment—as it should be.

Honest and clean

I don’t have much free time. Any time commitment nowadays has to be worth it. Nowadays, “worth it” often equates to money. That dynamic plays a large part in the modern web’s proclivity for bait-and-switches, “Please like/follow/subscribe”, hidden sponsorships and the ever-present invisible eye that’s collecting your personal information. I simply wasn’t going to do that. But, I had to make this site in a way where that was actually feasible.

A project that took months of time to create and required constant high-maintenance would require something substantial in return. I have no need for a return because I’ve reduced the investment to all but nothing. With essentially no overhead or maintenance, this site isn’t costing me anything. And no cost means no need to extract value.

I now have a site that’s encouraging me think about design system ideas. The reader gets content in return. In short, this site was designed to be clean-burning to ensure a clean relationship with its readers.

Parting words

Simple isn’t always fun. It’s often not inspirational. It’s typically not convenient. It’s not easy. But simple is simple. And boy is simple a breath of fresh air in today’s world. That’s why I’m so proud of of this project. It’s not beautiful to look at. It’s not a technical marvel. It isn’t solving some grand problem. It’s just a single page on the internet.

I’m most satisfied by what this project isn’t. There’s not much to it, and that’s the point. Practically speaking, it had to be made this way due to life’s constraints. Simple is a word so trodden over that it’s lost its meaning. Real simplicity is often unnoticed by design. But overlooked as it may be, incredible things can come from it. Working on this project has reaffirmed just how much can happen when you do as little as possible.

Measuring true adoption is impossible

Design system adoption isn’t quantifiably measurable because adoption isn’t purely quantitative. It’s also one of those things I suspect we all think we agree in definition, but there’d be some wild disagreements once we got into brass tacks. My take is adoption that just measures amount of use is missing the amount it’s used correctly. And it’s that last part that’s the monkey wrench. Once intended use is in the picture, well, now you’re crossing quantitative and qualitative streams.

So, if you buy what I’m selling, true adoption measure isn’t attainable. Congratulations! You now have the freedom to define something less loaded than adoption while still providing useful signal.

Measure aspiration instead of adoption

Now is a good time to stop reading and think about what wild, unmitigated success looks like for your design system. What part of that wild, unmitigated success is:

1. Quantifiable
2. Simple to understand
3. The most critical marker of success

That’s your “adoption” measure.

As an example, if success looks like enabling teams to quickly develop new components on top of your system, perhaps you measure the use of your tokens/building block components in non-system components. I’m spit-balling here, you’ll come up with something better.

An approachable measure helps reinforce your vision of success

Simple is hard. We all know that. But an approachable metric is critical. I’d argue the way you measure success can be just as powerful of a narrative as the measure itself. How do you measure your view of success that’s approachable? I can tell you it’s not with more math. And that’s the beauty of not measuring adoption–you get to choose your own adventure.

For my work on Gestalt, success has always been moving usage from the small, atomic components to the bigger, more opinionated ones. Thus, the measure I’m proposing is to divide our bigger, opinionated components by everything else. Meaning our own smaller components count against us. The rationale goes back to the fact that while our smaller components are critical, their usage does not equate to wild, unmitigated success. There’s even signal that those smaller components impede on the usage of bigger ones. Is that an accurate measure of adoption? Nope. May it even be a little controversial? Sure. But it was the clearest measure I could think of that communicates success.

Metrics are a hell of a drug

I love numbers. In moderation.

In my experience, metrics can be a gateway drug to more metrics. Without discipline, you end with metrics for the sake of metrics. Then one day you wake up in a pool of spreadsheets and aren’t quite sure how you got there.

Metrics can be fudged, manipulated and stomped on. Worst of all, metrics can abstract what you’re actually trying to accomplish. Without a thinly veiled skepticism of metrics, you can fall trap to believing that moving the metric is the job. It’s not. And even despite best efforts, once this measure becomes a KPI or shows up in OKRs, some people will be solely focused on it.

Let’s be clear, you’ve hit wild, unmitigated success when when you’ve hit wild, unmitigated success. Metrics can help validate and contextualize, but chances are, you’ll already know when you’ve done it.

One of the major challenges of systems design is communicating the rationale of decisions — why you landed on certain choices, and why they make sense in the bigger picture. I’ve found language is an effective metaphor to explain my rationale: Creating a system is, in essence, creating a language.

Let’s look at the definition of the word “language”: The method of human communication, either spoken or written, consisting of the use of words in a structured and conventional way.

We can tweak that a bit to apply to design systems: The method of human communication within a user interface, consisting of interface elements in a structured and conventional way.

I’ve found the rules of language to be a great way to vet my own ideas…and to critique other people’s work, too. Using language metaphors to describe system tenets keeps things tangible. Language is as common a denominator as there is — the translation (no pun intended) is straightforward.

What’s less straightforward, however, is the English language. From first-hand experience, I know English’s rules are not fun to learn. It’s riddled with inconsistencies and irrational rules. It’s also a gold mine if you’re looking for examples on how to not design a system. Here are some ways that language can translate to and help explain your system’s design.

Doppelgänger depot

The words doppelgänger and depot are adopted into the English language. Doppelgänger originates from German and depot from French. By adopting these words, we’ve also adopted the rules for how those words are constructed. Now all of a sudden we have umlauts and silent t’s in our language that we need to make sense of. There’s nothing wrong with this (who doesn’t love an umlaut?), but they don’t fit the foundational rules of English. The result is they don’t feel as though they’re a natural part of the language.

The common equivalent in systems is the classic, “Design System ABC did XYZ — we should just do what they do!”

Material’s color system is no doubt impressive, but that doesn’t necessarily mean it’s compatible with yours.

Everything in a design system should originate from its fundamental rules. Pulling ideas from other systems is expected, but those ideas need translation to conform to your system’s underlying thinking. So it might have made more sense for Doppelgänger to become Doppleganer in English and for Depot to become Deepoe (or Deepow? or Deapoh?). Just sayin’.

Flammable? Inflammable? Whatever, you choose!

Flammable and inflammable mean the exact same thing — just look it up. But then…why do both exist? Should I use one over the other in certain contexts? Do people even know they mean the same thing? I have so many questions! Couldn’t we have settled on one word and moved on?

The go-to example of this principle in design systems is the checkbox and switch. Systems often provide both these solutions to address the same need. This makes you ask: When do I use one over the other?

There are good reasons to have both a checkbox and a switch. For instance, you use a switch in the mobile context and a checkbox in the web context. In that case, you’re providing a single solution (per platform) to solve a single need.

Our design system at Pinterest system has supported both checkboxes and switches on the web platform which led to unnecessary variance in usage. We’re working to consolidate to one single treatment.

When people have many options to do the same thing, they’ll usually end up using every option. That almost always leads to poor outcomes, and the design system’s job isn’t to provide a buffet of options, but to provide the solution for specific use cases.

Design systems, just pick “flammable” (or “inflammable”) and move on.

There, their, they’re

Come on…you knew this example was coming.

English is full of nearly identical homonyms and they cause constant confusion. It sure would be nice if English had distinct words for distinct concepts.

A common example of breaking this rule is link treatment. Due to accessibility, color alone isn’t enough to signify a link. There should be a clear and distinctive way to tell the user, “Hey, this text here is a link.”

Another example using Pinterest’s design principles. We could improve upon this.

Distinct interface elements should have something which makes it distinct. Elements that look the same but are different in purpose will always cause confusion. It’s simple: If things are different, they should look, sound and feel different. Don’t go their (sorry…there).

Exceptions of acceptions

Accept (əkˈsept) and except (ikˈsept) have technically different pronunciations. But let’s be honest, they sound the same. Unfortunately, they mean drastically different things: “It was excepted” means something very different from, “It was accepted.” Given how diametrically opposed those two words are, it’s safe to say the words should be more clearly differentiated.

A similar example in design? Using color as the only differentiator between statuses like success and error. Given how fundamentally different these are, there should be a strong distinction between the two. Color is one way, but it should go well beyond just that. For maximum accessibility, we should differentiate error messages through messaging and iconography as well as color.

Well, we got 1 out of 3 differentiators here. Sure, the text is different, but there aren’t any distinguishing features in how the text is constructed with our error toast’s text (something like Oops! at the beginning) to differentiate it at a glance.

Logophobia, phobophobia, panophobia

You don’t need to be a rocket scientist to know the three words above are related. The phobia suffix makes these three words immediately relatable: They share a commonality, yet represent distinct concepts.

Families of design components should have shared traits that make it clear they’re related. This often happens naturally, but it’s important to be intentional about what those traits are. Doing so will help you make system-friendly decisions when you add to the family.

Pinterest’s form inputs share a set of visual traits (corner radius, border treatment, sizing, etc.), but each also has a distinct trait that makes it unique. The shared visual traits also act as a contrast from other components, such as our buttons.

Elements that are a part of a family should intuitively and consistently feel that way. The more intentional you are on how related components are visually communicated, the easier it’ll be to add your next phobia.

Supercalifragilisticexpialidocious

Avoid being fancy when you can use a simple word — say “good” rather than “transplendent” so people stay on your page. The same goes for design: Don’t complicate basic concepts. You’re only going to make it harder for people to understand how to use the system.

This was one of Pinterest’s guiding principles for our initial dark mode rollout. We were set on keeping things simple and not overthinking. So our dark mode was in essence a palette flip with a super minor tweak to one of our grays for accessibility. And it worked (For the most part, I’ll get into that later.) It also allowed us to ship extremely quickly with minimal overhead.

We kept our dark mode simple and it paid off.

I before E except after C…except when not

Anyone that’s had to learn English is familiar with the classic “i before e” rule. They’re also keenly aware of how silly the rule is, and that it’s not even reliable. A language is useless if no one can learn its rules. The harder a language’s rules are to learn, the greater chance people will:

• Misunderstand how to use it
• Not feel comfortable speaking to people
• Stop trying to learn it

Systems are especially difficult when components have different properties depending on its context. If you use words like “if,” “but,” and except” to explain how a component works, it’s time to reevaluate. Either streamline the component to remove conditional rules or break it up into separate, easier-to-use ones. I’m guilty of the example below.

About that dark mode effort… Our initial palette forced some unfortunate one-offs, specifically how our inputs and buttons needed to slightly lighten on elevated surfaces to remain accessible. That treatment is something I’d love to take back.

Complicated or nonsensical rules won’t be followed. If you want to make a system that no one uses, make it hard to understand.

OMGLOL

Slang happens. People make up words. In a perfect world, those words still feel like they’re a part of the language. But they shouldn’t rehash another word for a different meaning (see: salty) or be gibberish (see: ROFL).

Custom components that aren’t a part of your system are like slang — and they can and should conform to the system’s rules. Plan for design-slang deviations and find a way to guide them to be compatible with the system. This is where higher-level guidance of how to design components is so helpful. If you don’t provide guardrails, you’ll be dealing with the UI equivalent of Thicc. Come on, two Cs?

Above is an example of a custom combo button created by one of our product designers. It lets people combine a list and a button (the “OMGLOL” in this situation), and easily fits into the system’s aesthetic rules.

Epilogue

It’s easy to overthink design systems. This isn’t to say that creating a design system is a piece of cake — it’s not — but we don’t need to make it harder than it already is. At the core of a design system, we’re trying to create logical, repeatable rules that allow people to “speak the language” competently, salty slang and all.

I am not suggesting that the design community considers writing unimportant. It is just treated as something else. The aesthetics of the visual and textual will continue to be disconnected until that changes. Writing is design. There is no separation.

Designers devote endless hours to make their solutions more elegant. They understand the importance of detail. They cherish clarity and simplicity. The same isn’t often said about their craftsmanship of words. Dieter Rams published the ten principles of design which guide many in the practice. Below is a derivation of Ram’s principles to illustrate how writing and design are often one and the same.

Good writing is reader-focused

Your writing’s content, style and format should benefit your readers. Publishing content to fit a schedule, prop up traffic or just rant wastes readers’ time.

Good writing is trustworthy

Readers have to know they read is honest, genuine and fair. Writing that lacks any of those qualities erodes credibility and trust.

Good writing makes its subject useful

Writing has limited impact if readers can’t relate to the subject. If they can’t relate, they can’t “use” it. Informing is prerequisite, empowering is ideal.

Good writing is unobtrusive

Writing does not need to be verbose to be smart. Communicate with the most accurate, simple words.

Good writing is focused

A good piece of writing concentrates on the subject. Tangents dilute and create confusion.

Good writing provides novel information and perspectives

Writing should have something useful to say. Piling on a subject with nothing new to share helps no one. Better to direct readers to a well-written piece than duplicate it.

Good writing is aesthetically pleasing

Content should be enjoyable to read. The meaning of words should carry as much beauty as their visual representation. Well executed typography without well executed writing is missing the point.

Good writing is well-crafted

Typos and grammatical errors are unacceptable. Writers should strive for a technically flawless reading experience.

Good writing is succinct

Every word written should count. Any paragraph, sentence or word lacking significance wastes the writer’s and the readers’ time.

Good writing is long-lasting

Trends may affect subject matter and language. Ideas shouldn’t have an expiration date.

Communicating ideas has been and continues to be a primary goal of design. Designers spend considerable effort to convey complex emotions, processes and concepts through visual abstractions. These endeavors have merit and provide results. Yet a simple, well-written sentence is often more effective.

By everything, I mean everything. Sketches, wireframes, visual comps, clickable demos, beta releases, version 1.0 and version 2.0. They’re all a prototype for what comes next. This could be seen as arguing over semantics, so let me explain why this distinction is important.

We build prototypes with the explicit purpose of learning. Good prototypes don’t get bogged down in the details until necessary. Thus, they’re streamlined and fast. There’s a clear acknowledgement of “I don’t know”. Changed is assumed and failure, to varying degrees, is an expectation. Understanding is the product of a prototype.

When working to make something exactly right, the blinders go on. We can spend a disproportionate amount of time fussing instead of learning. More than often you find a fundamental flaw in your thinking; all your time fussing was for not. This process is inefficient and hit-or-miss.

Today’s digital products have short lives. Technologies change, expectations change. The things designers obsess over today are forgotten tomorrow. What persists is the knowledge uncovered through the process of creation. It’s those learnings that will make the next manifestation better. That’s why viewing design as a constant state of prototyping is important. It puts us in a state of fluidity, a openness to learn and respond. The focus is on learning.

The worst kept secret about design is no one knows if something will work until it’s tried. Even time-tested approaches can fall flat given the right (or perhaps wrong) circumstances. I like to say that the first try isn’t what’s important — it’s the second try. What happens between those two steps is what matters.

You’re obviously going to apply this principle differently in a sketch than a GA launch. The experiments taken with mature products will be more subtle and focused. This approach can be applied to any of the traditional steps in the design process. It’s more a way of designing than a particular kind of output.

Human beings are not perfect. As such, the things we make are imperfect as well. However, we have an amazing capacity to learn and adapt from our mistakes. It only makes sense then to focus less on perfect and more on slowly, constantly better. The process of design should improve yourself as much as what you’re designing.

Why Speed is Important

The breaks between loading times or interactions create breaks in experience. Speed often has a greater impact on experience than what’s typically focused on in design. Page loads are more important than ever when considering mobile devices. A 500Kb page size may be annoying on desktops, but it can prove unusable on mobile. Responsive design is not just about fitting a website nicely in a smaller screen. It is also responsive to bandwidth, lower computing power and other less celebrated constraints.

Tips to Shape Your Thinking

Consider time as a core dimension of user experience

Speed has traditionally been considered an engineering topic and been ignored by most designers. Yet design often makes or breaks performance before a single line of code is written. The temporal experience of a product (e.g., page load speeds, app performance and anything else that impedes fluidity) is foundational to the practice of interaction design. Translation: A design is unsuccessful if it sufficiently impedes performance.

Understand how design can impact speed

Grasping the basics of design’s impact on speed is simple. Digging into the nitty-gritty of performance is quite difficult. The basics are obvious: large files and many requests will take more time to download. Anything delivered to the user takes time. The challenge is uncovering the less obvious. Issues like avoiding expensive database queries or CPU-intensive tasks. The main takeaway is that every decision has an impact. The goal is to take a preventative approach towards the basics and to work closely with developers to avoid the less obvious.

Determine where speed resides in the hierarchy of experiences you’re designing

Every designed experience has a hierarchy of needs. Those needs shift in priority based on the product’s focus or the people it’s for. While speed may not always be at the top of the list in needs, it should always be part of the equation. Understanding the importance of speed in the experience will inform your compromises.

Make every element justify its existence

Designers already know that every pixel on the screen needs to be accounted for; every interaction justified. That same approach should be taken towards speed. Each request, byte and query added should be intentional and markedly improving the experience. If not, it should be gone.

Treat bytes like pixels

It’s great to see an increased attention to craft, simplicity and a pixel-level focus in interface design. That same tenacity towards aesthetic and reduction needs to be directed towards performance. This means optimizing your images, cleaning your HTML, CSS and Javascript. Make your sites pixel-perfect and byte-perfect.

The points above are not far off from what’s typically prescribed for effective design. The difference is that designers normally talk about stripping things away to simplify interaction. Those same practices of refinement and reduction yield equally worthwhile results for faster web experiences. The world will thank you.

When easy becomes vapid

The line between simple and simplistic is subjective. No one wants unnecessary complexity. However, we cross the line when simplifying a concept negatively impacts the user. An example is the ubiquitous auto spell check feature in today’s software. While convenient, it can become a crutch leading some unable to adequately proofread.

Vapidity lets people down

Designers put immeasurable time and resources into removing cognitive load from our daily interactions. On the surface, there is nothing wrong with this, yet, overemphasis on easy comes at a cost. This effort often results in a shallow derivative of the subject’s original form, trivializing both subject and user. The premise for removing difficulty is justifiable. Many people feel intimidated when presented with too much complexity. Yet the conclusion to remove complexity at any cost misses the mark. The simplification-at-any-cost approach leads to potentially innovative solutions being dead on arrival if they have the unfortunate side-effect of a learning curve.

Simplistic products give a false impression of competence which removes the incentive to learn. This illusion of aptitude ultimately wastes peoples’ time. It either creates dependency on the product or let-down when people discover their domain knowledge was never adequate.

An example of trivializing important, complex experiences is found on legacy.com. The website takes the burden out of sharing your condolences by writing them for you.

There should be nothing easy about writing the condolences for the loss of a loved one. This is a prime example of how over-simplifying tasks robs opportunities for growth. When we automate something so fundamentally human, we strip out our most essential experiences. Making the naturally complex unnaturally simple treats neither the subject or the user with respect. This denies people the skills they need to perform a task when it inevitably becomes necessary.

No one advocates for designing solutions that are unnecessarily obtrusive or convoluted. We should not need to “walk in the snow uphill both ways” for every single thing we do in our lives. Yet we should also not create the false impression that one can walk downhill both ways.

Recommendations

Our goal should be to transform the difficult into rewardingly challenging. While nothing below is particularly new, they are still worth noting.

Challenge people (in the right ways)

Expect more of your users and make your product worth their time. Some of our most rewarding moments come from overcoming challenges. Not the convoluted, time-wasting moments, but the difficult, yet important tasks that we had to work through. Why then would we shy away from presenting these types of opportunities to our audiences? Software should expect or even a demand people to learn and grow to “get to the good stuff”.

Determining the correct level of difficulty is necessary for a fulfilling experience. Too elementary, and the value to engage is questionable. Too onerous and immediate frustration kicks in. Regardless of its difficulty, this equilibrium is crucial to maintaining a state of flow. Mihaly Csikszentmihalyi states one of the three conditions for flow is, “… a good balance between the perceived challenges of the task at hand and his or her own perceived skills. One must have confidence that he or she is capable to do the task at hand.”

Honest trumps simple

Superficially presented subjects lead to superficial understandings of them. In dumbing down our language, concepts and processes, we often warp their true form. Some tasks are just tough. Some require weeks, months, or years of practice to become proficient. That’s OK. It’s our responsibility to be upfront about this and to help encourage/empower users’ growth. It’s irresponsible to insinuate a shortcut exists when it doesn’t.

Simple, with depth

Some of the most successful products don’t take much time to learn, but take a long time to master. This comes from drawing out the subject’s full complexity until the user is ready for it. The elementary is obvious, the advanced is more subtle. An example of this is the OS X close button’s unsaved state. If a file has unsaved changes, the close button will have a dark dot in the middle.

Explicit? No. Yet I doubt that was the intention of this design decision. It was there, adding depth to the experience if/when it was noticed, but not critical if missed.

Articulate the importance of complexity rather than avoid it

If a subject is naturally complex, work to make it no more complex than it needs to be — but no less. People are not averse to complexity, but they need to know it’s worth their time and energy. Educating them on how to do something is not enough, there should be education on why it’s important. People enjoy learning if the subject is engaging.

Challenging users in the correct manner will lead to them being more self-sufficient. Informed users have a better idea of what they want and can better articulate why they want it. A person engaged with a subject is more willing and able to grow with it.

The task to make difficult processes simple, while preserving their true form is significant. Selling it to people can be even more difficult. For myself, the debate is not whether it is necessary, but where the line is drawn. No matter where each of us land on this line, if designers take the easy way out, we can expect no better from users.