It’s really easy to say agents are able to use a design system. See, I just said it–that’s how easy it is. It’s another thing to show that agents are able it use it well–with receipts to prove it.

Now, don’t get all excited–I haven’t done that. But what I’ve done is built a tool that’s helping us get there. And, as much as it doesn’t benefit me to say this, it’s not rocket science.

So, I don’t want anyone to get it twisted that I’m touting this as some ground breaking innovation. I mentioned this offhand in a thread and people asked for me to share more. So, here we are.

How it works, basically

I’m not a smart guy–to my benefit. Being not smart, I don’t try to get fancy. So, when pondering on this problem, I landed on something very not fancy.

Two groups of agents get spun up, and both are given the same prompt to make an interface. One group’s given the old design system. The other is given our new one.

Each agent provides feedback on problems faced after it’s done. Once all agents finish, the builds are evaluated on a bunch of crap and a report is generated.

That’s it. Like I said, not rocket science.

How it works, in gory(ish) detail

OK, I’ll admit there’s more that goes into this. I wouldn’t say it’s important to know unless you want to replicate this.

The tool is relatively configurable. I don’t know what I’m doing, so I need to turn knobs and levers.

• You can choose how many agents get spun up per group. I typically go with three per group–mainly because three is an awesome number.
• The model is also configurable. It only supports Claude models, for a number of reasons. But there’s nothing technically stopping it from using other providers.
• There’s a flag for accessing training through a static markdown file or MCP. The results are pretty dramatically different. I’m still working out why.
• It allows you to add your own prompt to test from or let Robot Jesus to take the wheel. In that case, the prompt is created by an agent-generated in PRD format.

All agents are run independently to avoid sharing context. That’s obviously pretty important. Each agent is instructed to confirm that the app builds and runs. If an error occurs, the error message is logged and the agent is prompted to fix. They get a finite number of chances before being told to sit in a corner and feel bad. That feature avoids the nightmare “4,568th time’s a charm” scenario along with the $10,000 bill.

Each test is locally stored and self contained. Below is basic directory structure, with different names to (hopefully) be clearer.

test/
├── old/ 
│   ├── agent-1/
│   ├── agent-2/
│   ├── agent-n/
└── new/ 
    ├── agent-1/ 
    ├── agent-2/
    ├── agent-n/

(No, I didn’t use AI to make that diagram. Yes, it look an embarrassingly long amount of time to make it.)

Agent output (generated code, error messages, screenshots etc.) is stored in its own agent-n folder. It’s basically everything that came out of the work. That’s helpful for when you want to run the code to dig into details.

All analysis happens after all agents finished the work or died trying. The report compiles all the results into group averages. So, the more agents you spin up, the larger the sample size (duh).

What it measures

A lot–but there’s still a lot of work to be done. This is what’s tracked so far:

• Timing: How long it takes to complete the task. Ideally, a well-trained agent will be able to get the job done faster.
• Lines of code: How much code did it produce to complete the job. My hope is to see lines of code decrease as we build more high-order components.
• Code variance: How different the code is between each iteration. This measure shows how consistent and predictable code output is across agents.
• Fix attempts: How many times the agent had to go back and fix an error. Ideally, the design system allows agents to one-shot an interface.
• Components used: A breakdown of all the components used, and the amount of time each is used.
• Accessibility: A fairly basic set of axe accessibility tests. At best, the tests are assessing airquote-accessibility. Admittedly not great, but a start.
• Performance: Baseline render time, LCP, FCP, and OPP (that last one isn’t real, but it was a good song)
• Inline styles: Tracks component instances with inline styles. This one is a legit nightmare–agents love to slap inline styles on pretty much everything.
• Visual diff: Just your run of the mill pixel diffing for each screenshot. This is also used to assess how consistent the output is from agent to agent.
• Token usage: No, not design tokens–the robot kind. Input and output token spend is recorded to measure efficiency. Results should be good–and not break the bank.
• Feedback: Last, but not least, feedback from every agent is added and broken down by general theme.

There’s always more to track. Responsive screenshots seems like an obvious one. I’ll be adding more as they are needed.

How I use the tool

I’m still learning how to make the most use of this tool. In general, I use a basic flywheel approach. I run tests, collect data, synthesize it, then make improvements. Rinse, repeat. What this process lacks in fanciness, it makes up for in actually working.

Sometimes I approach improvements from a broad spectrum. That usually means combing through agent feedback like API issues, or install woes. Other times, I use it to improve on specific facets. Like the time I went to war on inline style usage.

I’ve gotten in the habit of running a test with a decent number of agents when a new release ships. Sometimes, nothing new shows up. Other times, the test catches bugs, or inconsistencies with documentation.

I also try to run tests when new models come out. To be honest, I should spend more time doing this.

The results are promising

But way too early to get giddy about. In a nutshell, every track metric improved. What I find most promising is the consistent trajectory of improvement. Results vary, but they’re not thrashy.

It’s worth noting the tests have only run on Claude 4.5/4.6 models. I still need to give the 4.7 models a spin. I also have zero use on any other providers. So, again, promising, but too early to get cocky.

What I learned

Now, I’ll admit–“learned” is doing some heavy lifting. Everyday, people “learn” the world is flat on YouTube. I can’t say what I’ve learned is right. All I can share is where my head’s at based on this experience. Your mileage will vary.

This isn’t a replacement for talking to people

OK, confession, I already knew that. But I want to lead with this so people don’t get wild (and stupid) ideas in their heads. This tool won’t save you from having to (god forbid) talk to actual people. Agents are a whole other animal–figuratively. Believe it or not, an agent evaluation tool is used to evaluate agents.

This can be pretty cheap

My instructions always explicitly state to only write code for the front-end. And that turns out to be a pretty light lift. Tests with 3 agents per group costs about the same as a cheap coffee.

Super big sample sizes aren’t super necessary

Most of the time the results from 3 agents versus 30 look about the same. There are cases where you get that out-of-nowhere result. Those show up more often with a larger set of agents (duh). Those can be helpful because it exposes the edge cases. But the common issues tend to show up with a low number of agents.

It’s easy to start teaching to the test

I was using the same template prompt for tests when I first got started. I was making solid progress, but it began to feel too easy. That’s when I added the ability to randomize prompts. And, yeah, all sorts of new crap started popping up.

Randomizing prompts emulates how a design system is used–which is unpredictably.

Documentation makes a huge difference

I was starting to question if documentation was making things better. Maybe component improvements was doing the heavy lifting–who knows? So, I ran a couple tests without documentation… The documentation was clearly the heavy lifter. This seems like a no brainer–but it was important for me to verify. Documentation is essential for systems that agents don’t have a lot of reps with.

Agents are somehow more stubborn than I am

Agent muscle memory is a complete pain in the ass. It can be overcome, but it’s going to piss you off the entire way there. Agents often straight-up ignore guidelines. I’ve combatted this with weapons-grade repetition. I’ll often repeat the same damned point five or six times in critical points of the documentation.

Agents (probably) need their own docs

Repeating points for agents may be fine, but it can be a pain in the ass for people. I’ve started to add a “For agents” section in the docs. That section is the dumpster for “get it in your silicon head” training. I remain a strong advocate for human-written documentation. But I could care less if documentation for agents is written by agents. As long as people don’t see that content, I’m all for it.

MCPs are hard

I’m really struggling with getting good results with MCPs. My best results come from agents getting a big context dump of all documentation. Agents that use the MCP ask all the wrong questions. They make bad assumptions. A lot more tokens get spent for worse results. All I’ve learned so far is that I need to learn more.

Documentation probably won’t cut it

Yes, I said documentation makes a big difference. But I don’t think it’s going to be enough. Agents still do dumb things for dumb reasons–or no reason. I’m pretty sure systems will have to ship with linters and other tools to unscrew basic agent stupidity.

Feedback needs to go through a BS filter

The feedback part of the analysis is helpful. Make no mistake. But it needs heavy interpretation. A lot of the feedback is half true, or framed on a poor conclusion. There’s usually a nugget of value, but it can take a decent amount of polishing to extract it.

Don’t let that flywheel spin on its own

Now, I know what you’re thinking. You’re think it’d be great for agents to run the entire flywheel. Have them kick off tests, analyze, and then apply updates to the system. Over and over.

That’s a bad idea.

There’s a lot of noise in the output, feedback, and analysis–otherwise known as everything. That noise compounds fast. Think of the telephone game–then think about what that’d do to a design system.

I haven’t made something worth sharing

At least not yet. “Working for me” isn’t actually working. This was made on the company dime and so it’s not even my decision to begin with. And that’s not even the point. If I can make this, you can too–so go and do it!

I’m not saying this is the right way to do this

I’m saying it’s how my dumb ass did. Just like 99.9% of AI “experts”, I have no idea what I’m doing. But that’s not going to stop me from trying. If I learn something worth sharing, I will. Maybe that’ll be a better way to do this. Maybe it’ll be a cautionary tale against the whole ordeal. Either way, you should give something like this a go. Then you too can join the world’s least exclusive club of AI “experts”.

Corporate newspeak sucks

I’m labeling corporate jargon as newspeak. That word seems like a better fit with every passing day. It’s the language of bullshit.

It’s used as a dog whistle to announce they’re “in the club”–because they aren’t. It’s used to sound credible–without actually having to be. It’s used to sound smart–by people who usually aren’t. It’s used to prop up ideas with fancy words–because they can’t stand on their own. It’s used to filibuster–to fill up space with a lot of words that mean nothing. It’s used to sow confusion–so that they can avoid having to stand behind a message. What sucks the most is that it’s almost always done for the gain of the speaker instead of the audience.

And in an ironic twist of fate, the peddlers of bullshit convinced countless others to adopt it. It’s both universal and non-existent. Every press release and quarterly report is soaked in it. But it’s nowhere in real human conversations.

I could go on and on about why corporate newspeak sucks. It’s cathartic, but not helpful. Instead, I’ll spend the rest of this writing about how it doesn’t need to be like this.

Doers don’t need to do this

Designers and engineers are makers. They’re doers. They don’t need to talk in bullshit. Because they do shit. Now, I’m under no illusion that designers and engineers are perfect. An encylopedia can be filled with their failings. But both professions are makers. And that holds weight. That doesn’t mean makers don’t have to talk about what they make or what they do. At some point, everyone has to explain their thinking, their work, or their value. That can take the form of a portfolio, or a job interview, or a presentation. The trick is not to fall into the trap of speaking bullshit.

So, how does one not bullshit? There’s not one single answer, but this is mine.

First, have something to say. This is the key point–all else hinges on this. Be selective and critical of what you put out in the world. That, “something”, should be intentional, considered, and helpful to others. It’s far better to say nothing if you have nothing to say. Save it for when there’s something worth other’s time. Use that time spent not saying stuff finding something useful to say for you and others.

Yes, The Algorithm ™ will argue otherwise. It wants volume. It wants frequency. It wants what helps itself. You do not fit into that picture. Quality is much better than quantity.

Second, say what you mean. Yes, this means being honest. But it also means to be direct and plain-spoken. Big ideas don’t need big words. Get to the point.

Let’s use the example of design system documentation. A button component could be described as, “The button component constitutes a discrete, interactive user interface element facilitating the initiation of deterministic actions within the application context.” Or it could be, “Buttons let people take actions.” One says, “I take myself way too seriously”. The other describes what a button is.

Third, say it like you’d actually say it. Write and talk like you actually talk. The things people publish are working double-duty. Their first job is to get the intended point across. But they also open a window into who the person behind the words is. Don’t undervalue that.

Talking or writing in corporate newspeak sucks the personality out of the message. The same goes for the messenger. Now, someone may be saying, “The way I talk is boring and meandering.” Well, then fix that. “Be yourself” isn’t a call to celebrate mediocracy. Be who you are–while trying to be better.

If you’re not able to describe something in a document or presentation, say it out loud. Hell, talk to a rubber duck. Do whatever you need to say things how you’d actually say them.

Fourth, back it up. People who describe themselves as visionaries aren’t visionaries. The actual handful of visionaries alive don’t have to say it–because they’ve proven it.

Don’t describe what can be shown. Great work speaks for itself. Yeah, most of us aren’t in that echelon. So, it’s understandable that us mortals need to add color from time to time. But showing should take center stage.

A portfolio spending more time describing the work has a problem (I’m looking at you, Gestalt case study). Sometimes you have to puff your chest out a little. But a little goes a long way. Showing the work should do the heavy lifting. Let the audience come to their own conclusion.

The same goes for documentation. Sometimes the best thing to say is nothing at all. Documentation can try to explain a pattern with a wall of text. But it’ll be more effective to let a working demo do the heavy lifting.

Oh, and AI

The term, “soulless language” now has a whole other dimension to it. Corporate newspeak is now a basic prompt away.

Let me be radically transparent with you. There was a season in the zeitgeist when leveraging elevated vernacular signaled intellectual capital. That era? Sunset.

In today’s landscape, over-indexing on sophisticated terminology is actually a red flag for authenticity debt. Why? Because the playing field has been fundamentally leveled.

Every single individual now has frictionless access to AI-powered linguistic augmentation tools. The prompt “optimize my lexicon for executive presence” is literally one click away for anyone ready to uplevel their content game.

See? Now everyone can sound like an asshole. There was a time when using fancy jargon made someone sound smart. “Rewrite this to use fancier words” is a prompt anyone can type into their agent of choice.

Sounding like a normal human hasn’t been normal for a while now. AI will only exaggerate this. And let’s be honest–many, many people are leaning on AI for what they say.

We can do better

A lot of people despise writing, speaking, or plain old communication. I get it–we all don’t like the same thing. Some people feel shaky in their qualifications, or skills to articulate. I get that as well. Defaulting to corporate lingo can feel like a shortcut around those issues. But it’s going through the motions.

I see it as a missed opportunity. Bullshitters need to bullshit, because that’s all they have. Doers don’t need to bullshit. Not only that–doing so harms the standing that comes with being a doer. Writing and/or speaking may not be your thing. But for skilled doers, the hardest work is already done. The work of the work. The reward of doing the work is not having to rely on bullshit.

It may not be fun, but I urge doers to hone the craft of saying. It’ll create even more distance from them.

And in that setting, contributions have been more about feeling than function. They were a way to keep consumer teams engaged. It made it clear the design system team was something they could be a part of. But was it the most cost-effective way to run a system? Oh, hell no.

Big orgs, big problems

Big anything means complexity. Companies are no exception. Anything with a lot of people is going to make things complicated. Things that work fine for a few folks don’t with one hundred. And vice versa.

Contribution models are no exception. They’re hard for systems that support a lot of people. How can people effectively contribute to a system supporting thousands of use cases? Especially when their focus is on a handful–or one. It’s hard for anyone to have such a wide perspective–especially when it’s not their full-time job.

And that’s how we get complicated contribution models. Thousands of system consumers could mean a deluge of contributions. One bad addition could impact hundreds of people. Safeguards, checks, and process get put into place for a reason.

Either way, contribution model’s success is inversely related to how involved it is. The more process, the more pain. All those steps may be important. But they also introduce more failure points. There are tax codes simpler than some contribution models. One in particular made me question my mental acuity. I’ve seen some shit…

That’s why I’ve shied away from contributions at larger orgs. Now, that’s not to say that contributions at big companies can’t work. My experience says they’re very hard. You may got it all figured out. Kudos. I don’t. And I’d rather focus on design systems than cracking the code of contributions at mega-corp scale. That’s just me.

Contributions make sense for Cheers-sized teams

But small teams are simpler. There’s less moving pieces. Less complexity. The problems are still there–but they haven’t snowballed to the point where they’re an actual problem.

I have a super-scientific take. Contributions are most effective on teams small enough where everyone knows your name. A contribution is a mutual effort. Mutual efforts rely on established relationships and a heaping spoonful of trust. Right or wrong, the bigger the org, the more little fiefdoms begin to form. The “team” is actually nine or ten real teams. The “mutual” in mutual effort doesn’t feel so mutual.

That’s when process begins to kick into overdrive. I couldn’t tell you what the exact cliff when things stop working. But a sign to look out for is when contributions begin with introductions.

Not every process has to be a process

I like to say that you should be able to describe a component in a sentence. Anything more and it’s too complicated. Similarly, you should be able to describe a contribution model in couple paragraphs. Maybe three. The process shouldn’t be a process.

Folks are going to disagree with this. They’ll say two paragraphs is not even close enough detail. I agree! That’s where established relationships and trust come in to play. Sure, you could outline every hypothetical situation and edge case… Or you could create just enough structure so it gets done. And yes, that’s going to be a mess at a larger org. Which is my point.

So, what could a contribution process look like?

Step 1: Make a recipe

Add a recipe to the shared library. That’s it. People can as much or as little detail as they’d like. Stopping at step 1 is fine. No matter what happens, the creator has something everyone can use.

Step 2: Review a recipe

If the creator or the team wants it graduate to the system, they’d review the recipe with the design system team. Maybe it goes in. Maybe it doesn’t. Either way, the recipe is still usable.

Step 3: Contribute a recipe

If everyone agrees to bring a recipe into the system, they do the following:

• Agree on what needs to change to the existing design
• Define a spec for development
• Write usage documentation
• Assign owners for who takes on what

That’s my one rule for contribution. There needs to be a payoff for putting in the time to contribute. There are few worse feelings than wasted time. Putting in work and getting nothing out of it? That’s shitty. This process makes sure that, at the very least, the designer or engineer gets a recipe.

But, like, what’s a recipe?

Recipes are low-key, air-quote contributions

Recipes are a distinct composition of existing (mainly) of design system components. An example of a recipe would be an onboarding stepper pattern. All the design system’s bits and bobs are used to make something new.

Using the system for a recipe is the secret sauce. A good design system is going to cover all important bases–like accessibility. Which means a lot of the recipe’s details are theoretically sorted out. Mind you, “theoretically” and reality aren’t the same thing. But, it creates a much higher chance for less overhead.

They’re the low-key, low-stakes way to (kinda) add to the system–in a good way. They provide a color-by-numbers interface for making something. This way means people don’t have to know all the gory details of the system to make something for it.

Can recipes be smaller than a pattern? Sure. Instead of using design system components, they’d use design system tokens. It’s the same idea, just taken down a rung in the hierarchy of design system elements.

The most important characteristic of recipes is that the design system doesn’t own it. No policing. No oversight. No nothing. It’s a place where designers can do what they think makes sense. Designers can choose to make recipes completely detatched from the design system. Which is fine. It also means it’ll only exist as a recipe. Which is also fine.

Now, this isn’t some magic bullet. A recipe library needs the same care and maintenance, like any other. And that means that one or more product designers will have to own it. Because–say it with me–the design system team doesn’t own recipes

Small and mighty

Yes, this is high level. Yes, there ten sub-steps for each outlined step. But, in my experience, a team with a strong partnership and trust fill in those gaps. Often differently each time.

Process and rules are important. But they also can get between people. I’ve seen loose process work really well among teams with a strong relationships and trust. Would this work in a large-org setting? Maybe, but I could see a hundred different ways it may not. I see this playing out much better in a healthy smaller team. Emphasis on healthy.

Some may see this as a cop-out. I prefer pragmatic. Some things scale like crap. My two cents is that contribution models fall in that category. But if you may want to try out my approach if you go to work where everyone knows your name.

A new kind of claustrophobia has kicked in now. Software ships across countless platforms and device types. UI frameworks are all but considered mandatory. There are layers and layers of complexity that make 2005 feel like a kindergartner’s naive daydream. Managing the complexity of “modern” software takes considerable focus. And focus doesn’t grow on trees.

None of this happened overnight. The complexification of software crept in gradually. The ways of working haven’t kept up to account this–especially within design. The general process is basically unchanged. Sure, the tools are different and we have different names for stuff. But it’s the same song and dance.

And people wonder why software quality is in decline.

How we’re keeping it together

Abstraction has done a lot of the heavy lifting to blunt the impact of complexity. Kind of like shoving all your toys under the bed to clean your room. Make no mistake, abstraction has been a boon for productivity. It handles a lot of things that otherwise need deeper knowledge and skill. Abstraction makes tasks more approachable and attainable to a broader audience. Work that needed a front-end developer is now (theoretically) possible for a full stack dev. Why hire three specialist designers when one product designer can do it? Or, more accurately, “do” it.

Which brings me to design systems. They’re nothing if not an abstraction. And, boy howdy, have they been putting in work to stem the bleeding of managing complexity. The growth of design systems has gone a long way to keep the engine humming. Mature design systems handle so much that fly under the radar. Things like addressing critical states, accessibility compliance, managing edge-cases, performance, and more. These were the things designers and engineers used to sweat. Now, it just works. Great, right?

Right?

The ticking time bomb

Design systems and other abstractions keep software development’s engine running. But it’s starting to make some weird noises and the check engine light is on.

Do any of us see software getting simpler soon? No? Me neither. I’d bet the farm that design systems will only be more relied on moving forward. This sounds like a good thing. I don’t think so.

Design systems–like any abstraction–only obfuscate complexity. Yes, it speeds things up. Yes, it’s simpler at face value. But it’s yet another abstraction layer. And abstractions create complexity. Plot twist–our practice has been working to combat complexity by adding it elsewhere. You can only fight fire with fire for so long.

If/when this formula breaks down, we could see an even greater fall in software quality. Which should be a barrel of laughs.

A yucky future of dependence

Design systems exist to help people do their job faster and better. “Do their job” carries a lot of weight in that sentence. This assumes designers and engineers can make high-quality interfaces from scratch. Design systems just streamline the process.

But a funny thing is happening. Those skills to make high quality interfaces have started to erode. Specialist roles are disappearing. Remember front-end engineers? Instead of enhancing existing skills, design systems are becoming a dependency. Less people know how to create interfaces from the ground up. Abstractions, such as design systems, are becoming the new baseline.

It’s nice to be needed. But not like this. True dependency on design systems would change the fabric of the practice. Design systems have typically focused on happy paths and common use cases. Feature teams would build things the system didn’t have. Use was optional. But more teams rely on design systems to handle more of the work. Optional is turning into a hard necessity.

What happens when teams can’t ship a quality interface without the design system? What happens when you depend on the things to make the things? First, feature teams start square-pegging the design system into round-hole use cases. Components purpose built for specific situations are duct taped into something else altogether. Second, design system teams are pressured to cover more ground. More nice-to-have gaps in the system are now considered blockers. Quantity becomes the name of the game. Quality? That’s so yesterday.

Design system teams aren’t exactly flush with cash as is. Now imagine propping up quality across design and engineering. The typical funding, headcount and capacity ain’t enough. It’s a recipe for failure. And that failure will show up in even lower software quality.

This is how we’ll see a continual downward slide in quality. Dependency on design systems will further gut foundational skills for making interfaces. Greater dependency will force design systems to cover greater surface area. Sprawling design systems will become quality sinks due to their size. Dependent teams have no choice but to use the degrading system.

Next thing you know, teams are shipping crap built from a crap design system. What’s worse, as those skills drop, who’s left to make the next generation of design systems? What happens when there aren’t enough people to make the things that make the things?

How do we diffuse the bomb?

There’s no easy answer. Well, kinda. The things I suggest aren’t all that mind-blowing. The hard part is pulling it off in an environment allergic to moving slower and not breaking things. Nonetheless, this is how I’m personally circling this issue. Make no mistake–I don’t think this train is stopping. But that doesn’t mean we all need to get on–or get hit.

Remain dogmatically focused

Say no–as much as possible. Cover critical use cases and ignore the others. Draw a clear line for what the system supports and what it absolutely won’t. This won’t always be popular, but it has two critical values.

Saying no stunts dependency. Teams will need things the design system doesn’t have. Which means they’ll need to design and build it themselves. This is a good thing. This’ll force teams to flex their skills to make high-quality interfaces on their own. This means they can do it again the next time. The trick is finding the right balance between when to support and when not. No, there isn’t an easy answer.

Saying no also creates focus. Raising quality demands time and attention. The more a design system has, the more it has to maintain. The more it has to maintain, the less time and energy is available to improve quality. It’s not rocket science.

So, do less at a higher level of quality. Ween teams off relying on the system for everything. Drop support for unused components/patterns. Make quality a priority by not making other things a priority.

Make education on fundamentals a core pillar of design systems

Design systems that remove the need for foundational skills are killing them. I’m not saying it’s intentional, but it’s happening nonetheless. That’s not going to end well.

I’ve been guilty of saying, “You don’t need to worry about that–the system just takes care of it.” I was wrong. We need designers and engineers to worry about things. Which means exposing them to as much minutiae as possible. That’s not to say that design systems shouldn’t handle minutiae. It can–and should. But learning the details is, and always will be, important. High quality software needs everyone aware of and concerned about the details.

Design systems are perfectly set to teach these details. So many foundations run through design systems. Color palettes, type ramps, component architecture, API conventions–and so much more. Design systems can help teach people how to use it–and how it all actually works. This means going beyond “do this” and “don’t do this”. This means explaining. Give a “why” and “how” behind every principle, guideline, and best practice.

Yes, it’s a lot of work. But it gives people the skills to not just use the system. It helps them understand it–really understand it. And if they really understand it, they aren’t dependent on it. They’ll be capable of delivering quality independent of using the system.

Get consumers of the design system involved

The saying, “teach a person to fish” exists for a reason. Yes, documentation is a critical form of education. But nothing beats getting your hands dirty.

This can take shape in many different ways. New hires can spend a part of their onboarding embedded on the design system team. Team members can rotate on/off the team. Ambassador programs can create regular points of collaboration. There’s no shortage of approaches and no right or wrong way.

Design systems work a lot on foundations. Getting more people to work on them will help more people learn foundations. It’s not complicated.

No smoke and mirrors

Design systems can make many things work like magic. Magic isn’t real–it’s entertainment dependent on the suspension of disbelief.

A lot of high-level components/patterns can feel like magic. Think molecules or organisms. These kinds of elements represent the peak of design systems’ potential. They can save countless human hours in design/development and increase quality.

I’m not suggesting we stop making these. I’m suggesting we remove the “magic”. These components are often black-boxed with no simple way to recreate. Teams need to buy into the magic.

Instead, it’s important for these kinds of components to be composable by anyone. Meaning all the parts to reproduce the component are available and accessible. There’s no magic–anyone can see how the sausage is made. And everyone has the tools to make their own sausage. This means that if/when a team needs to diverge–they can–while still using the system.

Bare metal solutions

I’ve been crapping on the over-dependence of abstraction for this entire article. Yet the elephant in the room is that many design systems are guilty of this. Let’s be honest, how many web-based design systems are not built on top of React? Make no mistake, this makes a lot of sense–especially from an efficiency perspective. I question how this benefits software quality in the long run.

It’s tempting to take a “jump to the end” approach towards building a design system. I think it comes at the cost of quality. The implementation of a design system is vital, but tangential. Its true value comes from its definition of foundations, standards, and best practices. Those are the things that last. Those are the things that lead to quality. The less that comes between that and implementation, the better. What better way to foster foundations and standards than to build directly on top of them?

There’s no reason why a design system can’t provide React components. But I don’t think it should be required. Having a headline React component can be a nice abstraction of type hierarchy. But we also have to question how much overhead comes with it. If we want engineers to feel more comfortable writing markup, we need to expect them to write more markup. It’s worth considering lower-level entry points to implementing design systems.

Much of our thinking to date is how much a design system can abstract. It may be worth flipping the argument to ask how little we can get away with. How far can pure CSS take you? With the rapid maturation of web components, there’s a growing opportunity to get back to basics. And it’s that focus on the basics that’ll help improve software quality.

Quality has always been the point. Right?

Sure, velocity grabbed the headlines. But the goal’s been higher velocity to create quality interfaces. If quality goes, design systems are nothing more than an enshittification accelerator.

The best way for a design system to succeed is to make sure everyone has the skills to never have to use it. Systems can define the shape of quality. They can enable quality. But at the end of the day, they rely on capable people to wield the system capably.

If design systems care about quality, they need to work in a way to sustain it. If you think trying to get people to use a system is stressful, wait until people can’t do anything without it.

This post was initially written for the Zeroheight blog.

There’s no such thing as an unlayered design system

A design system is always using something to render a UI component. It can be as “low-level” as layered on vanilla HTML/CSS/JS. It can be layered on a framework like React. But it doesn’t stop there. Design systems often layer on top of headless component libraries like React Aria. They layer on full design systems, like many have done with Material. It can even add layers on top of that–like adding data-viz components to Material.

All design systems are layered on top of something. the million dollar question is how high (or low) should you go? Any why? But keep in mind, the higher up those layers go, the more things become interesting.

Making a design system on top of Bootstrap

One of the first design systems I worked on, circa -6000 BC, was built on top of Bootstrap. That had a lot of advantages. It made initial progress incredibly fast. It was the most used framework around at the time. It was familiar and reduced the learning curve for those using it. And given how many decisions Bootstrap took care of, we had much less initial load to carry. It made a ton of sense and worked well…

There’s always the, ‘…’

Initial progress was quite fast–as long as we played nicely with Bootstrap. Things got tricky when we tried to bend it to our will. The wheels began to wobble once we began including major CSS overrides. It only got harder from there. And managing Bootstrap updates… That was “fun”. As Bootstrap evolved and changed, our “fixes” would break. This made the codebase eventually feel like a vat of pasta.

Was this the fault of Bootstrap? No. We wanted the framework’s benefits without the costs of layering on a framework. That’s not how it works.

The pros are the cons (and vice versa)

What I’ve come to believe is that every upside of layering is also its downside. The trick is to maximize the upsides’ benefits while slimming the downsides.

A lot of the decisions have been made

Building a design system from scratch requires making an eye-watering amount of decisions. Layering on top of an existing framework makes a lot of those decisions. Fighting those decisions can make life very hard. It’s important to know what you’re getting into–and what decisions you want to control.

If flows and patterns are the priority, layering right on top of Material could make sense. Want full control over how the system looks? That means a headless component library like React Aria is probably the ceiling. Want more control over what is rendered in the DOM (and how)? Go even lower. Every layer descended means more control. It also means more decisions to make. Oh, and more work to do. Rule of thumb: Less layers means more control, but more headaches (from more work). More layers means less control, but more headaches (from managing/supplementing dependencies).

Either way, it’s important to know you don’t just inherit the decisions of what you’re layered on. You also inherit the decisions from the things they’re layered on. Engineers understand this, designers may not. Run npm install @carbon/react and see how much more comes along in node_modules.

And that’s no shade on Carbon. But it’s important to know. Dependencies have dependencies–that you now depend on.

Building on top of an established codebase

The value of layering on top of established libraries is that they’re established. A lot of the issues, edge cases, and bugs are already ironed out. Those would all be work to plow through–which is daunting. Sure, LLMs can pump out code pretty fast. But time is typically a big gating factor to get things working well.

But, established can also come with baggage. The codebase may have accumulated tech debt. Or it’s built with stale ideas/technologies. Or it contains a yet-to-be-discovered security hole. Yes, you get the good of established functionality and bake-time. But you also get the bad that comes along with time.

Tap into an shared mental model

Layering on top of a library like React can be a quick win. People know how to use it–they can rely on muscle memory. Everyone can hit the ground running. This is no small part why React so pervasive with design systems. It’s critical for design systems to meet people where they are. This is not something to ignore.

Tapping into an established library is a tacit endorsement of their point of view. Ignore or buck that point of view and risk losing that shared mental model. What about those who don’t agree with that point of view? Let’s say a team doesn’t buy into “the React way”. They disregard those best practices when building their design system components. They could be leaving a lot of value on the table if people aren’t able to use the React components like React. So be careful how much you buck what you layer on–you may be missing the point.

On the other hand, what’s hot today is gone tomorrow. Who uses Bootstrap anymore (rhetorical question)? The asset of leveraging a popular library could someday become a liability. Teams that disagreed but followed suit anyways may be feeling regret.

Community-backed

Using an open-source, community backed library means not being alone. There’s support from other people contributing, pressure testing, and answering questions. This feels like a life-line for small teams with limited resources.

But when being a part of a community, that means being a part of a community. Meaning being one voice of many. People may not be interested in your requests. Your contributions may not be accepted. The roadmap may not be headed in a direction you don’t like.

Or, the community dries up and development stops altogether. Now you depend on a codebase created by other people, but you need to support. On your own.

Continuous improvements

Many libraries are constantly updated and improved. A lot of that work would be things your team wouldn’t have time for. This frees up to work on areas are worth the time and focus.

But update fatigue is a real thing. And not all those “improvements” may seem like improvements to you. Some of the changes may not align with your point of view. There will be breaking changes that involve migrations. Some migrations can be incredibly time intensive. Sure, you can stick to a previous version, but that comes with its own set of risks…

There’s no right or wrong here

Like I said, every rose has its thorn. The “right” decision has a lot to do with what you’re aiming to do–and why. Everyone is going to have their own mental questionnaire. Below is mine:

How many frameworks need supporting?

A lot of systems don’t have the luxury of supporting a single framework. It’s critical to focus on the common denominator when supporting more than one. Need your components to be available in React and Vue? The last thing you want is to have to update styles in two places. So, it’ll going to be important to have a one solid HTML/CSS structure that both pull from.

How much expertise (and time) is really available?

It’s tempting to want full control over a system. But are you prepared to build everything from the ground up? That may sound fun, but you have to ask yourself if have the time and chops to pull that off. React isn’t perfect, but it’s one hell of an accomplishment. Same with Material. It’s important to be honest about what you’re ready to take on and live with. And not just about you. Are you sure you can make the thing that supports hundreds of designers and engineers on a daily basis? To power a product millions use? Think about that before you sign on the dotted line.

How loose can the dependency be?

Not all layers need to be tightly coupled. Sometimes a little more upfront work can save a ton of headache in the future. For instance, I recommend managing design tokens in JSON instead of Figma. JSON is a standard, portable format and can go anywhere. Yeah, that means those JSON values will need to be imported and synced. But it also represents one less hard dependency in case a design tool migration needs to happen.

Being able to “rip the cord” is an immensely liberating feeling.

How specific are the needs?

Does the business rely on supporting an old legacy browser? What happens if/when the UI framework drops support? How much risk does that represent?

What’s Plan B?

It’s worth taking a moment to consider how to avoid a worst case scenario. Try to pre-plan a graceful exit where a dropped dependency doesn’t spell doom. For me, that means biasing towards standard formats and technologies. Sure, some folks prefer the developer experience of CSS-in-JS. But CSS-in-CSS can be used in any web stack.

Who are the people working on those dependencies?

How long have they been around? Do they have a history of doing good work? Are they trusted? The design system is now partially relying on these people. It’s worth knowing who they are.

How much functionality is actually needed?

Don’t inherit the Titanic to ship a canoe. Keep a design system as small as possible. It may turn out 99% of what a library offer isn’t relevant. It’s probably worth building that 1%.

What’s the endgame?

If the goal is to spin up a product and sell it in a year or so, layer like it’s going out of style. A lot of the downsides of dependencies only show up over time. The longer the horizon, the more beneficial ownership and control becomes.

Own what matters

No design system is built completely from scratch. That’s impossible. The moral of this story is not to hand crank everything. It’s to be intentional about what you own and what you don’t. A system focused on strong presentation better damn well own its visual styles. If it’s first class developer experience, then again, you need to own it. Dependencies aren’t to be avoided at all cost. Neither are they something to take on willy-nilly. They’re a necessity–both a pro and a con–to consider with care.

The point is if you decide to make a podcast, no one will listen, you’ll lose money, and it’ll be totally worth it. These past four years have been immensely rewarding. It’s one of the best impulse-decisions I’ve ever made. More people should spend their time and money to make podcasts no cares about.

Disclaimer: I don’t actually podcast

What I do is get on a call and talk for roughly 30 minutes. Then, a week later, a podcast episode shows up. Like magic. My partner Davy podcasts. He sets up the recording. He edits the audio. He publishes the episodes. He does everything. Which is probably why I’m having so much fun.

Every great story starts with a dumb idea

It’s peak Covid and everyone is stuck in their houses. We’re trying to distract ourselves from the daily, “unprecedented times”. My buddy Davy and I stay in touch via texts and I probably said something like, “We should do a podcast.” And that was it. No grand plans or big dreams. Just two dummies that were too dumb to think they couldn’t make a podcast.

And that’s the thing. Like so much in life, shit isn’t as hard as it looks. Podcasting doesn’t take much. You need a mic, a laptop, and (ideally) a partner. Sure, there’s other stuff, but you get the idea. One of the best things we did was not think too much. It’s frightening how often I find that useful advice.

You pick up a lot of stuff in four years

Again, I know next to nothing about the technical aspects of podcasting. But I’ve learned a lot about the stuff around it.

Some people take podcasts way too seriously

I try to make it a point not to talk about my podcast. Ever. I’m hoping this doesn’t count because I’m not specifically calling mine out. Actually, crap, it is was on my homepage. That’s embarrassing.

I don’t like to talk about it because, a) it’s insufferable to do so, and b) 95% of people could (rightfully) not care less. I should know–I’m one of them.

The other 5% assign way too much credibility. People have called me an expert, thought leader, and all sorts of other slurs. Like having a podcast means something. Please refer to how this got started. Anyone can make a podcast in minutes. That’s what’s so great about it. It also means a podcast has the same credibility as your average YouTube comment.

Some folks think they’re not qualified to podcast. Like there are any qualifications on the internet. The folks on ShopTalk refer to podcasting as “mouth blogging”. I’ve yet to hear a better description. And like blogs, anyone can have one. No one is checking credentials. Some are decent. Most aren’t–which is fine. That’s not the point.

The point of a podcast is to get things out of your head

Most of the ideas we have rattling in our head are incredibly dumb. The act of blurting them out does two things. 1) Helps you come to terms with the terminally-dumb ideas and, 2) Forces you to un-dumb the ones that have potential.

I maintain the opinion that writing is the best way to distill your thoughts. But sometimes you ain’t got time for that. If you’re like me and find writing to be one rung above a to-the-death pit fight, podcasting may be for you.

Sometimes it’s helpful to just talk through an idea–especially while it’s still forming. I’ve found podcasting to be a great pre-first draft for a later blog post. I’d say blogging and podcasting are a great combo if you have the time and inclination.

That said, talking and writing ain’t the same thing. Maybe all you do is stick to talking on a podcast. Either way, you’re getting your ideas out into the world. Good on you.

Either way, the process of sharing an idea will make it better. It’ll be clearer, more succinct, and with less holes. So you’re getting a ton in return even when inevitably no one listens.

It’s a great way to keep in touch with friends

The main idea behind the podcast–at least for myself–was to create a ritual to hang out with a friend. Davy and I were usually talking about design systems anyways–we just decided to record it.

I’m a borderline recluse. So a ritual like this has been huge in staying connected with my friend. Now, I’m not saying podcasts are going to solve the loneliness epidemic. But it sure as hell ain’t going to hurt it either.

And then there’s the other side of the podcast. I joke that no one listens to our podcast. That’s not entirely true. It gets some listeners (that’s as specific as I’ll get). But the people who do listen, fucking listen. We have a core audience that seems to come back for almost every episode. In a way, it’s how I can “stay in touch” with folks I know. Kind of like sending Christmas card with the year’s updates–but it’s every two weeks and about design systems.

Doing the thing is the fun part

I’m not ashamed to say that I enjoy fun. And while I like writing, I’ll never mistake it with fun. Podcasting has been a way to get many of the benefits of writing–but with a lot more fun. Now, keep in mind, I do none of the work for the podcast. Which is probably why it doesn’t feel like work. Major caveat.

Talking about the right subject with the right person/people is a recipe for fun. Fun for you, for your co-host(s), and for the four people that listen. I’m joking–two people. But that’s what’s great–you all had fun even if no one listens. And believe it or not, it’s OK to have fun without other people knowing about it.

It’s the most low-key way to be an independent publisher

I didn’t dawn on me until a few years in that podcasting is still indie at its core. Somehow this format has fallen through the cracks and avoided being swallowed up. It’s RSS-based and can basically be hosted from anywhere. Sure, it’s syndicated in commercial platforms, but it doesn’t need to be. And that great–especially now.

Social media has been a complete failure. We made a huge mistake by donating our thoughts, ideas and creativity to these monsters. Making a podcast is the most pain-free middle finger to all that. You may think your social media platform of choice is fine. And it may be–now. All it takes is a change of ownership for it to become a nazi porn platform. Or even worse, LinkedIn. Having an independent podcast means you never need to worry about that. You can keep truckin’ in your cozy little space as the next platform goes up in flames.

How in the world are there only like five design systems podcasts? And by such untalented people? Okay, fine, maybe just one of them is untalented. We need more voices talking about things they’re interested in. It’d also be nice if it’s stuff they’re semi-knowledgable about. We need those voices broadcast on not TikTok, Twitter or LinkedIn. Maybe with a few more peeps who aren’t middle-aged dudes.

No, I probably won’t listen to your podcast

And that’s fine. A good idea isn’t measured in stars. Fun isn’t measured in reposts. A platform isn’t a platform unless it’s yours to stand on. What I’ve learned is that the value of making a podcast is just that. Give it a try.

Now let’s fast forward. The marketplace went bankrupt. Sharing ideas for the sake of sharing? How quaint. We’re very much in the, “what’s in it for me?” phase of the web.

I’m not mad–I’m disappointed. Ok, fine, I’m a little mad. But this seems to be the cycle. To quote Eric Hoffer: “Every great cause begins as a movement, becomes a business, and eventually degenerates into a racket.”

Public design systems are our marketplace of ideas

Design systems lagged behind the web a bit, so we’ve been gleefully in the movement lifecycle. It’s been our little Web 2.0 moment where work and ideas have been open. System teams publish their work for all to see. Am I naive enough to think this hasn’t at least a little bit about self-aggrandizement? Of course not. But the benefits remain.

Public design systems have lifted all boats in the harbor. Most design system teams do the rounds to see how other teams have tackled problems. Every system that raises bar puts healthy pressure on others to meet or exceed it. This shared ecosystem may be the most important facet of the design systems practice.

But things that begin as a movement don’t stay that way.

All good things…

There’s a growing trend to close down public systems. Funny enough, the first thing I did when I left Pinterest was clone the Gestalt repo. I had this spidey sense it wouldn’t be around forever. Yes, their web codebase is still open source, but the docs have gone private. That one stung. Gestalt wasn’t the first design system to be public. It wasn’t the best one either. But it’s hat was in the ring–and that’s what mattered.

But that’s only one design system, right? Sadly, I’m hearing more chatting about mounting pressure to privatize their systems.

This is an incredibly shitty idea.

It doesn’t seem like a shitty idea

I don’t want to paint some unrealistic picture. Making a design system public is a pain in the ass. There’s plenty of crap to deal with. The obvious one is how to handle confidential/proprietary information. There’s also risk of “speaking on behalf of the company”. Documentation is a company-owned property. Is every word vetted by people with law degrees? Probably not. And let’s not forget that going public brings gobs of added work.

There are plenty more reasons where those came from. A private design makes all those issues non-issues. With that out of the way, I’ll now explain why it’s still a shitty idea.

Decisions don’t exist in a vacuum

I think a lot of teams view the public/private decision through the lens of their own benefit. Ironically they’re missing how each system exists in a larger system.

That individual decision to go dark sets a precedent. It makes it that much easier for the next team to justify doing the same. The next thing you know, public systems are rare. Then gone altogether. And everyone’s flying blind.

These decisions are infectious. And on the flip-side, other teams take notice when a system opens up. Those cases make it easier to do the same. “Everyone’s doing it” is a powerful driver in the corporate world.

Sharing a design system may feel like a drag, or a luxury. But the ability to study/source other design systems is a necessity. One that’s taken for granted. Losing this resource will make design systems work much, much harder.

Going public is an unmitigated benefit for design systems

The statement above may seem hyperbolic. I don’t think it is. Yes, private is easier–but it lowers the ceiling of potential. Significantly. Here’s how.

It’s a quality forcing function

If the 2020’s have taught us anything, it’s that a product doesn’t need to be good to be valuable. It doesn’t need to be effective. It doesn’t need to work as advertised. It needs to make money.

But here’s the thing about design systems. Their value is entirely based on being good. Design systems don’t make money. They help companies work more effectively–which makes money. They do that by being good. For design systems, good takes the shape of well designed and engineered components. Clear guidelines for implementation. A strong, intuitive developer experience. Good equates to better output in less time. That right there enables design systems to pay for themselves (and then some).

But that payback depends on a high quality system. Which is why quality has to be at the center of everything a design system team does. “Work fast and break things” is anathema.

What in the hell does this have to do with public design systems? Well, I’ll tell you. I’ve yet to find a better forcing function for design system quality than making it public. Because it turns out that people care that much more when the whole damned world can see it.

I’ve worked on private and public systems. My experience is that public systems lead to higher quality end results. Without exception. It’s public presence drives more thought and attention to what gets published. It’s not something that’s discussed–it doesn’t need to be. It’s just understood. Documentation gets one more edit. Prop names get double checked. The layout and organization of visuals get more love and attention. Everything gets an extra coat of varnish before going out the door.

And you know who benefits? Everyone. The design system team benefits because they’ve delivered something better. The broader community benefits because they get to reference it. But more than anyone, the daily users of the system benefit the most. Instead of a half-assed wiki page, they have something people are willing to put their name behind.

Work behind company lines is notoriously bad. The things that don’t see the light of day don’t get as much polish. It’s critical to place a design system in a position to get as much polish as possible. It may not feel like a system’s documentation or library is external. But all those components in the product very much are.

It may not be right. It may not be fair. But people are going to take more pride in the work that the public at large will see. It’s a tale as old as time. You can fight it, or you can work with it.

It’s easier to access and use

Do you enjoy five-factor authentication to view a website? I understand the necessity of VPNs and security measures. But why not leave that for the things that actually need to be secure?

Building an org-wide habit of reading system documentation is challenging on its own. Throwing in extra friction is just plain mean.

It’s a recruiting funnel

Gestalt’s documentation was a positive reinforcing feedback loop for quality. The public presence attracted great talent. That allowed us to hire great talent. That great talent made our system better. And since our better system was available for all to see, it attracted even more great talent.

And it’s not rocket science why. People want to know what the hell they’re getting into with a job–especially now. Being an open book has the benefit of, well, being open. You can point to your system and say, “Hey, do you want to work on that?”

It’s pretty damned sweet for the interview process as well. Applicants actually have a genuine way to prep ahead of time. They can assess the system and have a general idea of what they’d be working on. That’s a win/win in my book.

It helps make a happier design system team

I’ve discussed the challenges design system teams can have with morale. A lot of that comes down to not feeling seen. That can be blunted by having a public system. That doesn’t guarantee that they’ll gain greater visibility within their org. But there’s a good chance they’ll collect some outside eyeballs. And that can go a long way to mellow bad mojo.

It’s also worth noting that a pinch of external validation can go a long way to build up internal cred. I don’t think it’s chance that Gestalt’s outside exposure aligned with more internal visibility.

It trains the next generation of system designers

The current generation of system designers and engineers won’t be around forever. Or even in a decade. The cast needs to be continually refreshed. And let’s face it, learning design systems is effin’ hard. You know what a great learning resource is? I’ll let you guess.

Design systems are becoming a larger part of the product development process. The market isn’t flooded with skilled design system peeps. And no, AI isn’t going to fix this. We’re already short people and none of us are getting any younger.

Open design systems are the library for people wanting to get into design systems. They’re a free resource to expand their understanding. There’s no college of design systems. Bootcamps exist, but they’re bootcamps–and I’ll leave it at that. The generation who shaped design systems didn’t create universities–they built libraries. Those libraries can train the next generation once people like me age out. When the libraries go, so does the transfer of knowledge.

Public doesn’t need mean full-monty-open

Public doesn’t mean everything’s flapping in the wind. Open source is great. Source available is awesome as well. But even a closed source design system can be public through its documentation. Yes, open source/source available lends itself to better public documentation. It’s easier to connect design, guidance and implementation when code is a hyperlink away.

But documentation without code is still valuable. And not just for designers. The thinking/logic behind how to compose an interface is valuable to all disciplines. And 99% of that is not proprietary in any way.

This isn’t some all-or-nothing kind of thing. Not everything needs to be public to be public.

Just take the goddamned win

I’ve found few things more valuable for a design system than to work with the garage door open. The value may not show up in a spreadsheet. It may not pump next quarter’s goals. But it has broad and long-lasting value. It’s such a small and simple gesture–in the relative sense–for so much in return.

I see the writing on the wall and I don’t like it. What we currently have only works if enough chip in. But it’s looking like it’s too tempting to pull the cord on an “unnecessary expense”. Cord-pulling tends to be contagious.

I hope I’m wrong. Or it’s just a phase. Otherwise we’ll all be lamenting the big, fat, L in our future.

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?

Yup, that’s what I made.

It Makes Noise is a mobile app that (you guessed it) makes noise. I wanted something to block out background sounds. Nothing on the market really did it for me–so I did it for myself.

I learn a lot through these projects. That’s primarily why I do them. It seems like it’d be worth outlining what those things were. Keep in mind, these are my experiences. No more, no less. I make no guarantees about their value for anyone other than me.

AI continues to be a real mixed bag

Yeah, I used AI to make my app. I tried to use it with my first mobile app, with little success. This time worked better, mainly due to better tooling. But to say it was effective would be a wholesale lie. This is solely based on my experience. I’ve used AI with some success on other projects. All those projects were significantly smaller than this one.

I thought it’d be interesting to get a first-hand take on vibe coding. I decided to throw caution and reason to the wind. I let an LLM build out the codebase with my involvement limited to prompts.

I will never, ever do that again.

The appeal of AI to so many is how fast something real is made. That was exactly how this project played out. I had an app that would compile and function the way I had in my head (more or less). Mind you, it took some wild turns, but there was something resembling an app in a short amount of time. I should have stopped there.

But I didn’t. I decided to just ride this out to the bitter end. And it was in fact bitter. The initial app was fine. But as I tried to shift functionality, fix bugs and iterate on features, the joy ride broke down.

A hyper-precise graph that charts my productivity with AI-driven development over time.

The innate problem with AI is that it can feel magical at first. So much in such a short amount of time. But that spike in productivity begins to slide over time. And in my experience, it eventually descends into madness. Do you enjoy tracking down a bug in tens of thousands lines of code that you didn’t write? If so, you’re in for a treat.

The codebase got so convoluted and irrational that I had to step in and break the party up. The app required a full re-architecture that culminated in roughly 50% of the code removed.

Now, many are likely saying, “That’s not how you’re supposed to use AI.” To which I very clearly understand. But like it or not, many people, especially designers, are attempting to use AI how I did. I’ve long held this approach to software development to be problematic, if not dangerous. But who am I to judge without having direct experience?

Now I do have experience. I hold this approach to software development to be problematic, if not dangerous.

AI can be like arrogance and overconfidence in a bottle. It can give people the perception that they can do things with no direct skill/experience. And that’s the problem. They have no skill/experience in the given subject. They have no way to judge the quality of what’s generated.

I know enough to know what I don’t know. That’s valuable in and of itself. I understand where I’m safe to tread and what I need to leave be. This experiment was enough to reaffirm I’d rather take the time to know what I’m making.

I’d still use AI though

I will never vibe code anything of even moderate complexity again. I tried it, despite my apprehensions. If anything, it was worse than I imagined.

But, there remains value. I use it for two different scenarios:

1. Stub out a tightly scoped and narrowly defined set of functionality
2. Help me with something I have no idea how to even start

Searching for answers to technical challenges can also be a mixed bag. Sometimes I don’t even know the terminology needed to seek out the answer. Also, the internet kind of sucks now. Even if the answer is out there, I have to fight with ads, SEO-riddled gobbledygook and paywalls.

AI has been a better solution in certain cases. To say otherwise would be disingenuous. I don’t plan to abandon AI. But I prefer to have it solve a problem outside of the main codebase. That can take two routes:

1. Creating separate, self-contained demos to reverse-engineer
2. Provide code recommendations that I manually copy into my code (or not)

I’ve found those approaches quite useful. But that is a very different reality than the promise of, “Hey AI, make me an app.”

Doing something creates respect for the people who do it well

This project also reaffirmed the value in doing something outside your own wheelhouse. And by doing, I mean actually doing it. Not sitting in the passenger seat pretending to drive. Really driving. That first-hand experience gives a new appreciation for those who are actually good at it.

That’s probably the thing that worries me the most about AI. I’m concerned it’ll erode our appreciation for the people who have put in the work. I see this harming society’s collective expertise in countless subjects. Not to mention how it devalues the very people who could counteract the harm.

From my view, that’s the insipid cost of vibe whatevering. It’s the ultimate means to an end. I’ll go to the grave believing the slog towards the end is what’s truly valuable. The things I’ve done have made me who I am. I have a comically meandering career. And, yes, it took a while, but those various off ramps I’ve taken have rounded out my thinking. I wouldn’t change anything. I pity those who will lose out at the chance to learn things the hard way.

All those meanderings helped me to pull the atrocity-of-a-codebase back into something usable. Your run of the mill designer won’t have the experience to do that. There are a lot of designers who are about to vibe code into in comedic humiliation.

It’s important to give a project time to breathe

This app started a long, long way from where it ended. I’ll admit that the current version of the app came together pretty damned quickly. But that came after sitting with a janky-ass prototype for large amount of time. It was barely good enough for just me. But it was good enough to clear things up.

I made something to scratch a personal itch. And it kind of worked. Barely. That time sitting in my metaphorical stink gave me a much better idea of what I actually wanted. I paused for a large amount of time to gain a much larger amount of clarity.

Yes, there were still plenty of minor course corrections once I restarted work. But they were minor. Sitting, stopping and evaluating saved a ton of design and development time.

In truth, that’s painting a rosier picture than what really happened. Many dumb ideas don’t start off dumb. They become dumb because context shifts around them. This app started off as a tool to procedurally generate binaural beats and white noise. The app at that time let you select your frequency and phase shift to create custom recipes. At some point, the app shifted to be simpler. But the underlying functionality did not.

I ended up with a frankenstein codebase. The app was juggling multiple audio controllers for different audio types. I didn’t take a moment to re-evaluate the situation. Instead I kept building on top of a shaky foundation to feed progress addiction. At some point it dawned on me that I could just use audio files for everything. I should have come to that conclusion much sooner. And I would have. If I would have stopped to think for a damned minute.

I still don’t understand iOS development

To be more specific, I don’t understand SwiftUI–not really. It still feels magical at times. Things seem to happen and I don’t fully grasp why. I’ll admit there are many lines of code in the app that work for reasons beyond me.

That’s obviously bad.

I can still make things work, but I know they’re not elegant. That bothers me, but I’ll live. I know enough to build something that more or less reflects what’s in my head. What has really been driven home is that anyone can make a native mobile app. Mind you, not any mobile app. But, something is possible assuming they’re willing to do the work and keep it simple/pragmatic.

I find building native apps equally exciting and maddening. I makes it clear how much my home is building for the web.

My favorite design tool (continues to be) the code editor

I used Figma (or any other drawing tool) precisely zero times to design this app. Yes, I used it to create the App Icon–you got me. All other design iterations happened through code.

I’m one of the weird ones that’s considered the text editor to be their primary design tool for the past 20 years or so. That opinion was held with less conviction even 5 years ago. Now it’s cemented. I’ve come to actively avoid using traditional design tools. This project was one of my biggest projects that was made entirely from a text editor.

Now, I can’t say I enjoyed the editors used for this project, but that’s another story altogether…

I now directly understand why software is where it is.

It’s hilariously uncompetitive to charge for an app. This is the kind of thing you “know”, but don’t really know until you experience it first-hand. Which sucks–and explains a lot.

Selling an app–for real, upfront money–is an uphill battle. I’m not arrogant enough to assume that’s the primary reason why my apps aren’t flying off the digital shelves. But it’s hard to ignore that $2.99 is infinitely more expensive than free. And, look I get it. Why pay for something that could very likely suck. Especially when there are hundreds of free options available. There’s no reason to believe my app is worth paying for, or even better than the free alternatives. It’s a leap most aren’t willing to take.

It’s not a coincidence that the overwhelming majority of apps made available are free. But they aren’t–which readers of this blog likely know. A lot of people in the world prefer to live under the belief that there’s such a thing as a free lunch. And perpetuating that belief to extract money is really fucking complicated. A lot of the software that we use on a daily basis could be pretty simple. It’s the business angle that makes that reality impossible.

It takes a certain kind of genius to develop the mainstream platforms we see today. But it’s resulted in a lot of unhappiness. When all the bullshit is set aside–when an app can just be an app instead of a service–things get simpler. Simple enough that a dumbass like yours truly can actually make something. Twice.

I’d rather be a good dumbass than an evil genius.

I like writing. It took about three decades to come to that conclusion. I’m still not good at it–and I probably never will be. But I still like it.

So, of course, I have opinions on writing software. I’ve tried countless and enjoyed few. I’m the first to admit that it’s a hard nut to crack. So many people want so many different things. Many of the things some people want are what others specifically don’t. The app I’ve had the longest run with is iA Writer–mainly because it’s objectively good. The app has been in active development for what feels like forever (in internet years). Its business model isn’t exploitative. There’s just a lot to like.

But, because I’m me, I have my issues with it. Not so much with what it doesn’t do. It does too much–for me. And, yes, I’ve tried a numerous distraction-free, minimal writing apps. And many are just fine. But they’re either not minimal enough, or minimal in the wrong ways–again, for me. So, because I’m me and insufferable, I’ve decided to make a writing app that does just the right amount and is minimal in all the right ways–for me.

And just to make it more laborious, I’ve decided to write about the process of making it. This is something that’s going to take time. It should. I’d like to get this right–mainly because I want to use it. My hope is that writing about this will help straighten out my thinking. The straighter the thinking, the less code I need to write/rewrite. Also, I think it’s important to live through the jank of early prototypes. Trudging through crap strengthens one’s resolve to improve.

So, this is the first in what should be many, many, many updates. Let’s see how this goes…

Doing the basics

A little can do a lot. I spent a little time cleaning up the spacing, line height and more general massaging of the editor experience. I can say with enthusiasm that my editor is unabashedly mediocre.

The current build is working for iPhone, iPad and Mac. I’m primarily using the editor on my laptop and I can already tell that the interface is going to have to take some pretty sharp departures between iOS and Mac OS. How much? Uncertain, but there’s going to be a considerable UI shift.

But, damn, part of me thinks I could probably tolerate what I have for a decent amount of time. Except for one thing… Which I’ll discuss next time.

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.

Yes, reading habits have changed. Attention spans are down. Skimming is pervasive. Everybody reads, but a fewer keep reading. Given the abysmal quality and experience of the average online article, I don’t blame them. People don’t enjoy unenjoyable things. Is that the sole reason? Doubtful, but we’re sure not helping ourselves.

Yet, regardless of shorter attention spans exposed to poor reading experiences, people continue to read. Because text is at the heart of interfaces. People need to read a button label to know the action it will perform. Headers are how people orient within apps. I can’t think of a single interface that works without reading.

And if that wasn’t enough, the growth of remote work means communication is more text-based than ever. Which makes reading more important than ever. Which also makes writing more important than ever. Quality writing in Slack/email is undervalued. Think of how many cumulative hours people spend reading Slack messages. Now multiply that by the size of the company. Imagine a scenario where someone sends an important message to a 200 person channel. Poor writing can simultaneously tank the productivity of those 200 hundred people. The result could be as small as forcing people to re-read the message in order to understand. It could be as big as harmful actions taken due to misunderstanding. Either way, poor writing led to a poor outcome.

But “nobody reads” has taken hold. That narrative feeds the following negative feedback loop:

1. “Nobody reads”
2. Investment in writing decreases
3. Writing quality diminishes
4. Less people engage with lower quality writing
5. Return to step 1

As mentioned, the vast majority of people are reading all the time. Just not as much at once. That means writing needs to be better than ever. Writing has to get the point across clearly, interestingly and quickly. More meaning with less words—which is hard. It takes people with exceptional writing skills to achieve. Yet UX Writers and Content Designers seem to be the last hired and the first let go.

I can’t control how companies invests in writing, but I can control my personal investment. I’m not a great writer. But I am astoundingly better than I was ten years ago. There’s no magic trick behind the improvement, it boils down to respecting the reader.

If you respect the reader, then you’re going to work at getting better at writing. Because you know that someone has to read what you’re writing. And if you respect the reader, you want that to be as enjoyable as possible. At the very least, you want to avoid it being unenjoyable.

If I’m wriitng a draft for review, I’m proof-reading it first.¹ Yes, a proof-reader is also a reader. They’re volunteering their time to read my draft. The least I can do is find and fix basic errors not worth their time. I’ve been horrible at this in the past. In retrospect, I could have saved my proof reader hours of editing by spending 10-15 minutes of my own time.

If it’s an internal company message, I am trying to be as clear and succinct as possible. I understand how many messages people need to sift through, so short and sweet is the goal. If I’m writing a message for hundreds of co-workers, that’s a tremendous amount of attention I’m about to pull. At that scale, even a minor improvement in comprehension can have a big impact. It’s a major net gain in time if I spend an hour refining a message to save 200 people even one minute of reading.

The importance of in-product writing goes without saying. One poor writing decision can lead to subpar comprehension. The label on a button matters profoundly more than its color or shape. I often spend as much time on the writing in an interface as I do the interface itself.

The better I write, the better the readers’ experience. That could be a friend, a team member or a complete stranger. It could be an idea I’m bouncing off of someone or a feature’s call to action. Words remain the straightest line towards communicating ideas. Ignore them at your own peril. Because as much as we’re told otherwise, everybody reads.

1. Yes, there’s a typo in the sentence covering the importance of proof-reading. No, I’m not clever enough to have done that on purpose for the sake of irony. Yes, I’m keeping it because it’ll no doubt be my zenith in literary achievement.

This post doesn’t have “answers”. If there were answers, there wouldn’t be countless people asking about it. But I do have experience. I’ve been working on design systems long enough to develop a point of view.

Skepticism is healthy

Design systems represent massive change to how most software teams work. Of course the design systems team thinks design systems are great. Please excuse those who may have questions before turning everything upside down.

We need more skepticism in this industry. A healthy amount of skepticism keeps us honest. Unfortunately, it disproportionately resides in design systems. The practice will be better for it in the long run. Use that skepticism to improve your skills at influence. That skill will always be valuable.

Who cares who cares?

A common complaint I hear from people who work on design systems is that “nobody cares” about the work they do. It’s true, people overlook systems design work when everything is humming along. When something goes wrong, not so much. Design systems are infrastructure. We don’t gaze in awe at a running faucet pouring clean, drinkable water on demand. We should, but we don’t. The same thing goes for design systems.

The best thing I learned about working on design systems was to stop waiting for the medal. Most people aren’t ever going to care. That’s OK. Those people care about all sorts of things I don’t care about. Design systems don’t need people to care, they need people bought in.

Play the long game

I was far too impatient early in my time working on design systems. I didn’t respect how much change design systems represented—and change is hard. I expected the mountain to come to me, which was immature. Getting buy in doesn’t happen overnight. It should’t happen overnight. Getting buy in is a slow, gradual process of gaining trust.

Be prepared for things to take time. “No” will be be a common term. Do your best to translate every “no” to “not yet”. Use each “not yet” as a data point for improving your case.

There’s almost always something you can do to show progress. It may mean working slower than desired, but some progress is better than none. Focus on what you can do with what you have. Avoid impatience or the delusion of instant acceptance.

Swim in the same direction—loudly

This isn’t rocket science, focus on what the company is focused on. The folks who fund the work are more likely to fund what helps their work. The folks who do the work are more likely to use what helps their work. It’s easier to get people bought in when they see how there’s a clear connect between your work and theirs.

Aligning to company priorities may mean delaying critical foundational work for the system. This becomes a balancing act. The foundational work needs to happen, but funding makes it more possible. There’s no right answer for this. Find a blend that works best for all parties.

It’s not enough to align priorities though. The work needs to be visible. People need to know that the design system is driving company priorities. And visibility can be really hard. Getting people to see what other teams are doing requires dogged communication. It’ll be a lot of work, but if our experiences match, it’ll be well worth it.

People respond to incentives

Charlie Munger said, “Show me the incentive, and I will show you the outcome”. People will not use a design system if there’s no incentive to do so. People will definitely not use a design system if there are incentives against it.

Understanding the ecosystem of incentives at your company and tap into them. It could be compensation, performance, convenience, validation, or all of the above. And don’t stop with one! Different people react to different incentives. Build up a diverse portfolio to pull from.

What’s in it for you

“We” and “us” are a go-to word in the system designer’s lexicon. “Our system will help us all be more effective”. “We’ll have higher quality output in less time”. That makes sense because the focus is on the whole. And it’s all true. It’s a big part of why I work on design systems.

My experience has taught me buy in doesn’t come from “we”. It comes from convincing people how it will benefit them, as in singular. As in, “Your work will be easier.” “The design system will unblock your pet project.” “Your OKRs will go green.” That piques interest.

Speak the love language(s)

Different companies want different things from design systems. For some places I worked, they wanted cost reductions. For others, speed of delivery. Others, quality. Don’t sell quality to a team that’s looking for speed. The beauty of design systems is that there’s so much value to be had. Understand what the company wants and hammer that talking point.

The same goes for people. Some find motivation by doing great work. Other people want to climb the ladder. We’re not here to judge, we’re here to get them bought in. Understand the language that resonates with individuals and deliver it.

Offer no easy exits

A design system without a mandate is a design system with no leverage. If you create any reason for teams to not use it, there’s a good chance they won’t.

A common example is framework choice. Let’s say the company uses Angular but the design system team wants to use React. That’s clearly a bad idea because you’re giving teams the ultimate easy-out for not using the system. Teams will not completely refactor their code base to use something no one is requiring them to use.

A more subtle example would be a design system’s Figma library. Designers have an easy-out if the library isn’t improving output and/or efficiency. People are not going to volunteer to make their work harder. At least not with any regularity.

If the system is not required, the upside needs to be clear and present to everyone. It’s never a bad thing to make a design system desirable to use, but it’s needed without a mandate.

Make it “everyone’s baby”

People are more invested in what they’re a part of. Keep an arm’s length from your customers at your own peril. Contributions are an obvious way to make that happen. I’m on record saying that design system contributions are a real mixed bag. But there’s no denying how they can help create personal investment, and thus buy-in.

There are other ways to get people to get people involved beyond contributions. It can be a suggestion on improvement. It can be adding guidelines to documentation. It can be lots of things. The actual thing is less important than its impact on people.

Sell everything, everywhere, all at once

A major in design systems requires a minor in sales. If there’s one thing to take away, it’s that fostering buy in is a full time job. A full time job that no one has time for. The answer isn’t to do two jobs. Instead, find ways to bake selling into the work you’re actually paid to do.

A design system has many touchpoints. Documentation, design librarys, weekly updates, office hours. All of which can help sell the system. There’s nothing stopping documentation from making the case for the system’s value. You can’t expect people to get it if they aren’t made aware.

I spent the majority of my time on “selling” at Pinterest. Either in our comms or prioritizing ways to make Gestalt more appealing. “If you build it they will come” is a fallacy. People won’t buy what you aren’t selling. Prioritize this work.

“What is beautiful is usable”

I believe the substance of design systems is what eventually wins people over. But damn if a little style doesn’t get people’s attention in the short term.

You’re in the game of building trust and credibility. As much as I hate this about people, things that look nice are more trusted. I fought this reality for far too long. Don’t repeat my mistakes.

I primarily focused on substance when I started working on Pinterest’s design system. I leaned on logic and fundamentals to drive the case for Gestalt. I thought improving fundamentals would be the most effective first step. We focused on documentation writing, infrastructure, and core components. I don’t regret that decision, but it did create an uphill battle because those things didn’t turn heads.

Later on we began adding polish to our docs, our Slack comms, and pretty much every other touchpoint. That’s when visibility and buy in accelerated. Would that have happened without the fundamentals in place? Debatable. But there likely was a better blend of basics and pizazz that could have gotten us further, faster.

Don’t sacrifice substance. But also don’t shy away from sprinkling in “just enough style” to get people’s attention. Spend the time to make your artifacts clear and well crafted. This takes precious time, but it’ll build up credibility and trust. And that’s going to get you buy in.

Facts matter most

If style gets people’s attention, substance keeps it. Even with the best marketing and hype train-ing, people will eventually ask for proof.

Proof can be a lot of things. It can be testimonials or case studies, but numbers are my go to. Yes, metrics have flaws. People play plenty of games to make the numbers tell the story they want. But there’s not a more effective way to make your case than accurate and honest data.

For every sprinkle of style, heap on a big ol’ glob of substance. Which means you need to have measurements in place. Take the time to quantitatively measure the value of your system. Please. And once you have data to share, share it.

A few other bits of advice:

1. Brush up on statistics. It doesn’t need to be PhD-level knowledge. Basic statistical formulas will go a long way.
2. Fuzzy math is better than no math at all. Things like measuring time savings is incredibly difficult. But my experience has been that something is better than nothing. Share your data, share your methods for measurement, but most of all, share your learnings. It’s better to say, “We’re pretty confident we’re improving efficiency by X-Y%” than “Boy howdy, we have no idea!”
3. Underestimate, always. Better to underpromise and overdeliver. I like to cut my ROI estimates in half. If the return is still in the black, we have a strong case. I can then go to leadership and say, “Hey, even if we only hit half of our estimates, we’re still making you money.” That gives leadership faith we don’t need to stick a perfect landing to be worth the time and effort.

“Yes” is great, but not enough

I’d love to say getting that elusive buy in is where you ride into the sunset and credits role. Unfortunately, buy in on its own can be downright dangerous. A design system team isn’t set up for success if the people around you don’t know what they just bought. That’s a recipe for unmet expectations.

No, the work of getting buy in may not be fun, but buyer’s remorse is much, much less fun. But that’s another topic for another day.

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.

So, I grind away at this silly article, knowing I’ll figure it out. That was the big shift-knowing that with work, it’s a matter of when, not if. I know a lot of designers struggle with writing—because designers tell me. I decided to write this entry for two reasons. First, writing is critical-now more than ever. Think about how much time you spend in Slack writing to other people. Writing always was important, now it’s a deal breaker. Second, it was a good excuse to take a break from the post I’m struggling with. So hey, we’re both getting something out of this.

Many designers feel more comfortable drawing boxes versus typing letters. Because they spend a lot of time drawing boxes. Many designers also consider writing a different skill. It’s not. Writing is design. Both are a creative act. Both aim to communicate an idea; to lead someone towards a destination. Sure, if you pull out the microscope, there are plenty of differences. But at a healthy distance, those differences become unimportant details. Given both are creative acts, my suggestion is to treat them the same. Use the same style and process you use to design that you use for writing. That’s it.

What process should you use? Your own. You probably/hopefully already have a process that works for you. Apply it to how you write. If you’ve found ways to create something then you’re a long way to creating anything. The trick is to generalize the process(es) you use in design and translate it to writing. I’ll bet the farm you’ll find an analog.

What writing style should you use? Your own. If you’re design with precision and aim for simplicity, write like that. If you’re more casual/playful, do that. There’s a reason you gravitate towards that style-don’t ignore it. Work with what works.

Am I saying writing will immediately come to you? Were you a kerning machine at age 5? Likely not. There ain’t no shortcuts - it takes work. This advice won’t make you a better writer overnight. This should give you the structure to do the work.

There may be folks blowing a gasket that I’m oversampling the writing process. This advice isn’t intended to make designers into Pulitzer writers. It’s intended to get designers writing. The best way to get started is to start with something you already know.

A lot of the things espoused as different aren’t that different. I’m strange, but I see more commonality with engineering and design than differences. The same goes for a lot of things, including writing. The common denominator in any creative act is making an idea real. If you’ve already found a process to do that… Do that.

I’m a simple guy. I don’t like “stuff”. Yet, there’s an abundance of “stuff” in today’s mobile apps. I’ve come to terms with it as much as possible, but there’s been one thing I’ve been unable to get over. Playing music.

I want my music player to play music—and nothing else. I know I’m a minority in this view, but I’m not a fan of audio streaming services. I like to own my music and listen to it. I’m not into discovery or serendipity. I know what I like and that’s what I listen to. But today’s major music apps are more discovery engines that happen to play music rather than music players first. Discovery is hard and requires a completely different experience than media consumption. All of that adds complexity—which I dislike.

I’ve looked far and wide for an existing app that would meet my needs and was unable to find anything. If one does exist, well, it’s too late because I’ve decided to fix this for myself. Hell, if I can make a typeface, I can make a mobile app, right? Right?

This blog post will chronicle my process of making my first mobile app, similar to how I documented the creation of Olivia Sans. I’m fairly far along in development, so forgive me as you’ll be joining midway through the process.

These are the tenets driving this project

A music player should focus on playing music

This is the north star. This app is a music player and, thus, it will focus on playing music. There will be no favoriting or sharing or any other feature that isn’t directly tied to the process of playing music. And yes, this can be subjective. For instance, one could say that searching for music is critical to play music as you need to find it to play it. I’m interested to see how I develop my point of view in regard to what is and what is not directly related to playback.

I don’t plan to add any functionality for adjusting your library and/or downloading songs. Yes, this means I’ll be relying on iOS’s Music app to manage my library. Is this a pain? Maybe, but it keeps the app experience simple and given how infrequently I play with my library, I’m betting it’s worth it.

Playback controls should be persistent

I am not a fan of how music apps have different control layouts for playback depending on where you are in the app. Typically there’s a Now Playing view which has large controls and then a minimized view with a subset. I want one playback interface that doesn’t change so I can rely on muscle memory for interaction and not be concerned with what view I’m on to do so.

If there’s one thing I accomplish with this project, I want this to be it.

A simple mental model is critical for a simple experience

I want it to be abundantly clear how this app allows you to interact with content. The goal is for this app to have two views: Library and Album. The Library view let’s you choose your desired album and Album view let’s you play your desired song. I’m not a fan of the “Now Playing” pattern as it diffuses the Library > Album > Song relationship. I don’t think I’ll need more than two views to make this experience work—and frankly, I think it’ll be better because of it.

If there isn’t room for a feature, it’s not included

There will never be an overflow menu in this app. If I can’t find room for a button/action/whatever, it doesn’t go in. This will be a lovely forcing function to keep this app simple. I also want to rely on the OS to handle as much as possible. If a user can easily do something outside of this app, I’d highly prefer to just leave it out.

There won’t be any settings either. I can see the minimal value in some settings like toggling cross-fading, but it just doesn’t seem worth it. The closest I would get to settings is the inclusion of a Library view switcher (e.g., Recently played, Albums, Artist, etc.), but I’m mentally fighting that tooth and nail.

Don’t get fancy

Animated art covers are novel, but ultimately fluff. Ideally one is listening to music without looking at their phone. I’m not aiming for a radical departure in interface design. Ironically, I believe most music apps have developed sound interface patters—their primary flaw is that there’s just too much of it. I aim for polish and attention to detail, but I don’t see this interface breaking new ground.

We deserve more purpose-built experiences

So, this marks day one in my documenting the build of this app. I will be updating this post as I have updates to share. My goal is for this app to solve a very specific problem and nothing more. I also want this project to signify that anyone can do this with enough time and effort. I firmly believe that we’d all have far better options to choose from.

Updates

January 5, 2024

I need to start writing before this project is too far along. I’ve been at this for about a week and a half at this point and I’m much farther along than expected. I chose to write this app in SwiftUI and while it’s sped up initial process, it’s been painful at every step. I forgot how much I don’t enjoy declarative languages—it’s just not how I’m used to writing code. I can see how SwiftUI can be great once you’re up to speed, but the learning curve is steep. For every convenience I’ve be able to utilize, three head-scratchers have halted progress.

That said, I have a semi-working app. The interface is nothing groundbreaking—it consists of two views, Library and Album.

The Library follows the standard grid layout with persistent playback controls fixed at the bottom. I was hoping to remove album/band name labels, but that only works if you can rely on the album cover being available. I may explore a treatment where album/band is only shown if the cover art isn’t available. That would make the Library view as reduced as I can imagine.

Tapping into any album shows the Album view.

Again, nothing mindblowing. If anything, it’s the lack of elements that stand out. There’s the barest of metadata, no album-level actions and no track level actions. After using this view for a bit, it’s been refreshing just having less to look at. The playback controls persist on the Album view as well, so playback can be adjusted the same way while navigating through albums.

I’m not sure what I think about the cover art being as large as I currently have it, given how much it pushes the album tracks down. I might toy with alternative layouts to make the Album view a smidge more utilitarian.

Much of the work in the past view days have been refining the interaction within the playback controls. That little piece of UI is the heart of the app, and so it needs to put in a lot of work. I’ll go into that area of the app in more detail in a future entry.

Next up is to migrate my views to utilize NavigationStack so that I can more easily implement a nice shortcut to the active album from the playback controls interface. From there, I’m on to code cleanups and bugfixing to hit my first milestone.

January 7, 2024

Progress is speeding up. I continue to not enjoy building in SwiftUI, but I’m understanding it more. I went through a pretty exhaustive cleanup after accumulating a lot of debt in the initial build. It’s still a mess, but not a catastrophic mess. I think I’m about 3-4 days away from being ready for an alpha-ish build—which means I’m still a long way away from completion.

I took the leap and removed all album/artist labels in the Library view. That means I’ll need to create a variant of the album preview component to display album/artist name when the cover art is unavailable. It’s worth it though as it dramatically simplifies the Library. And yes, I’ve temporarily blurred the album covers because I’m not interested in sharing my entire music library.

I still need to take on the NavigationStack migration, but the cleanup/refactor should make that considerably easier. After that, I have one more major issue to fix and then the app will be heading to TestFlight. I’m trying to defer all visual/interactive refinements until I’m in the TestFlight phase as it’s far too easy to rathole in pixel peeping instead of ensuring the app actually works. I have a plethora of refinements planned, but I’m forcing myself to take my own advice and focus on the basics for now.

January 11, 2024

All main features are now built. I’ve also left a trail of codebase destruction in my wake. I’m nonetheless proud that I have a release build ready after a couple weeks of work. Here’s some of the functionality I’ve added since the last post:

Quick access to the currently playing track

The currently playing track is now tappable and takes you directly to the album. I’d like to improve this feature by scrolling directly to the currently playing song.

Library sorting

I added the ability to sort the library by date added and most listens. I didn’t enjoy adding this feature, but at least it’s hidden above the library on first load.

Pull to refresh

I don’t think it’s reasonable to have to terminate the app to have newly purchased tracks show up in the library. This feature allows you to refresh your available songs/albums, and luckily there’s no button added on the screen to do it.

Long press from Library to play album

This is the one addition that I think I’ll be using the most. 90% of the time I’m just opening the app to play an album from the beginning. This quick access interaction is something I’m already using every day.

I want to work on refinements, but I know the right thing to do is clean up the mess I’ve made. I’ve also begun to share the app out with friends through TestFlight. I was avoiding like the plague, but it’s clear I’ll have to add search functionality. Just another task to put on the list.

January 21, 2024

My last update was 10 days ago, but that feels like an eternity…

There’s been so much progress on the app since the last update. And even more frustration. I’m glad I took this project on, but it’s been painful and not in ways that I think I’ll look back on appreciatively. Developing for iOS is just painful in ways that doesn’t feel necessary. I’ll spare you the gory details, but I ran into a couple bugs that were beyond frustrating.

That said, through all the frustration, I have a build ready for public beta. It’s still missing some key improvements I’d like to get in, but it’s ready enough to share with strangers. Here are the latest updates:

• Added the library search—only by artist/album name for now
• Enabled toggling album/artist labels in the Library (through the Settings app). This was one of those design decisions that I knew would be polarizing, if not downright unusable for some folks. I told myself I wouldn’t add settings to my app, but I have no problem adding it into iOS’ Settings app.
• It’s not entirely working just yet, but I have the beginnings of functionality to fetch all album artwork that isn’t available on load. This is an example of Swift libraries being frustrating to work with and having to move mountains to do what seems to be simple.
• Numerous accessibility improvements. It’s not where it needs to be, but it’s considerably better.

So, while imperfect, it’s time to let this bird out of the nest. The TestFlight build will be made public tomorrow. Speaking of which, the TestFlight experience was pretty awesome. I had consistent support from some good friends who gave me continuous feedback. I also got a huge assist from a friend to fix a bug I wasn’t able to address. They’re why I’ve decided to make this public.

As much as I know the codebase could improve, the stability of the app has been shockingly good. The crash rate is at 0.12% with the last one occurring 2 releases ago. If this public beta gets used with even the slightest amount of volume, I expect that number to go up significantly.

And this public beta is going to be a major influence on what comes next. I’m admittedly tired and not ready to pour an unlimited number of hours into this app with no realistic goal in sight. In many ways, I’ve far exceeded my initial goal of building an app that met my needs. The rest is a bonus.

So, if the public beta goes well and there isn’t some existential flaw with the app, I will be putting it up for sale on the App Store. Which is bonkers and not something that I expected would come of this. Why? Well, damn, why not? I’ve learned so much from this process already, why not just jump into another learning experience related to App Store submission and marketing. But, I shouldn’t get ahead of myself. Let’s see where this public beta goes…

January 30, 2024

Well, it’s been a ride. The public beta went… not great. Abysmal would be another way to describe it. My goal is to have 0.1% crash rate to be confident actually putting it on the App Store. The crash rate for the public beta was roughly 25%. I’m no math wizard, but by my calculations, 25% is significantly higher than 0.1%.

That was the bad news. And, yes, it was pretty bad. I spent a full day trying to decipher crash logs and sending numerous test builds to an overwhelmingly generous individual. No success. Not even progress. I seriously contemplated just hanging up the project given the lack of progress and my complete unwillingness to ship something so busted. I took a few days off and just let it go.

The good(ish) news was that every crash had the same crash report. They all failed in the same place and in the same way. Meaning that if I fixed this one issue, it should fix the only issue folks were running into. I just had to figure out how the hell to do it.

So, after my little break, I got back to work. After some dense reading, I was able to discern that the crash was memory related and it was specifically failing while instantiating album cover art. My personal music library isn’t small, but it isn’t gargantuan either. So, on a whim, I decided to not store all the album art on initialization, but rather query/instantiate album covers only when they displayed on the screen. Meaning on the library I would load the image data when the album preview scrolled into view and nil it out when it scrolled out of view. I noticed a significant drop in overall memory usage, especially on initial load. I crossed my fingers, sent a new build to the aforementioned generous individual and waited.

Luckily, the launch crash was no more. Man, that felt so good. I shipped out a new build for TestFlight and while I have no doubt I’m jinxing myself, there have been no reported crashes to date. This is such a major milestone and I’m back to being cautiously optimistic. I’ve spent the last couple days cleaning up some tech debt from bug triage and prepping for the last few pre-launch refinements.

February 17, 2024

It’s been a hot minute since I’ve posted an update. A ton has happened between now and the previous post—most notably submitting to the App Store! Here are some highlights of what I’ve done/learned recently:

More improvements around memory usage

Without a doubt, addressing memory usage issues has been the most time-consuming and frustrating part of the entire process. Album art can take up a lot of memory and since SwiftUI handles garbage collection on its own, I don’t have the ability to manually release memory. So, much of my time has been working towards reducing the baseline memory footprint. We’re finally at a good place where the app should be able to handle music libraries with many, many albums. I do wish there was a way in SwiftUI to manually clear out memory. Maybe there is and I’m not aware, but I’m just glad we’re in a better place.

Localization

While dealing with memory issues was painful, localizing the app was a joy. I was really impressed with how XCode provides a localization table for different languages and an easy API for abstracting strings. I wish there was an equivalent for the web platform, because man was it so easy to implement. I was super, super fortunate to have many generous folks contribute translations for the app. Thanks so all those people, the app is shipping with translations for Simplified Chinese, French, French-Canadian, German, Japanese, Brazilian Portuguese, Russian, Spanish, Latin American Spanish and Ukrainian.

Improved gradients

I’ll be honest with you, vanilla gradients in Swift are not great. I typically use dark mode on my phone, so I didn’t notice just how bad they were until debugging the app in light mode. I was ready to just ditch light mode altogether—that’s how bad I considered it looked. I made a last-ditch effort to improve the gradients by implementing eased gradients and it made all the difference. It’s the only reason I’m shipping with a light mode version of the app.

Yes, it sure would be nice if I had before/after examples of this. Unfortunately I don’t. Suffice to say, the new gradients have a much smoother spread and the default gradient Swift renders.

Scroll effects

If memory usage was the most frustrating part of the development process, implementing scroll logic was definitely second. I cut my teeth on learning scroll logic with the top library controls reveal. That experience provided enough background to help me create scale/blur effect on album scroll.

There’s so little to this app that I wanted to have some level of dynamism—especially in the album view. I’m frankly not super happy with many of the current motion treatments, I’m hopeful I can get some help from some peeps in the near future.

While it’s far from perfect, I have a working build that’s ready for public usage. If you asked me about a month ago, I would have said it wasn’t going to get to this point. I’m equal parts shocked and elated. Hopefully I’m able to get through the App Store approval process relatively unscathed…

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.

I’ve seen this work dynamic a thousand times over. Workplaces focus on completing the next task as quickly as possible–with little regard for its aftermath. Corners are cut, messes are made and then its on to the next, next task. After enough time, general disorder sets in. It often takes the form of:

• “Where did I put that file?”
• “Is this the final version?”
• “How do I get this to work again?”
• “Who can I ask to understand this?”

Disorder creates micro-inefficiencies which make easy tasks difficult. Less is achieved with greater effort. And there’s even less time to do what it takes to stop being too busy. The cycle only exaggerates over time. That, friends, is a doom loop.

What’s worse? Multiply this by the number of coworkers also struggling with disorder. Even if only one team member working in disorder, it’s likely affecting others. Given most teams work in shared spaces (e.g., Figma, Google Workspace, etc.), our personal mess is everyone’s mess.

Working in constant disorder has little upside. It slows you down. It’s stressful. It distracts from more important work. Worst of all, the longer it goes on, the more work it takes to fix.

The work needs to be done, but not at the cost of constant diminishing returns. Quantifying inefficiency can be challenging and every company will have its own threshold of tolerance. But at some point, focusing on improving one’s own efficiency is of greater value than continuing forward at an impeded pace. Let’s not forget the important issue of mental health. Burnout is figuratively and literally killing people. Addressing disorder is an opportunity to help employees’ wellbeing and the company’s bottom line.

Ideally, companies would allocate time in projects to address these issues. In my view this is the straightest path towards stunting systemic disorder. However, I haven’t regularly seen that be the case, so let’s discuss Plan B: Personally carving out time to create order. Let’s call it garden tending.

So, what should this look like? It’s going to vary by individual, but I can tell you how I’ve started. I’ve begun by investing an hour every Friday to take on basic orderly tasks. Namely:

• Closing all browser tabs
• Cleaning out my email inbox
• Closing up all open conversations
• Making sure my calendar for the following week is up to date

That’s helped, only prevented things from getting worse. My goal is to be in a much better place. I plan to invest an additional full day per month to focus on deeper improvements. Specifically:

• Organizing files on cloud services
• Cleaning up and generally improving shared documents
• Archiving or deleting unused documents previously shared with others
• Organizing local files on my hard drive
• Leaving non-critical Slack channels
• Cleaning/organization of my personal doc used for notes and information archiving
• Physically cleaning my work station

I plan to prioritize improvements that affect other people (such as shared docs and cloud files). My thinking is creating order for the most amount of people will be the most effective use of time. I aim to learn investment in creating order impacts long-term personal effectiveness. I’m confident the rate of return will significantly net positive, but I won’t know until I try.

Doing “the work” is why we get paid. But doing the work so you can do the work is just as important. This kind work doesn’t need to be chaos. There are many aspects to a stressful work dynamic that is not a personal choice. But the order we create for ourselves is. Do what it takes to stop being too busy. Tend your own garden. Everyone benefits in the end.

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.

Consider the photo book

Sure, books haven’t fared so well these past twenty years or so. We all know the convenience of accessing content online, but convenience doesn’t equate to effectiveness. The book format is simply a superior format for communicating the concept and vision of photographic work (I’ll get into why later).

Robert Frank’s The Americans

To be honest, you’re starting in the hole by publishing your work online. My suggestion is to take what’s best about the photo book format and translate it as best as possible into an online format.

Easier said than done.

What makes the photo book so much better?

Well, they have a distinct advantage. The book’s format never changes so photographs can be laid out explicitly to support the vision of the photographer. The book has a built-in interface (e.g., pages) so there’s no need for pagination or navigation or any other mess. The photos don’t need to be loaded, the book never encounters runtime errors, there’s no issues with rogue colorspaces, need I go on? A photo book can simply be about photos.

Josef Koudelka’s Gypsies

The static nature of a photograph is a perfect fit the the static nature of a book. The photo books I resonate with do amazingly little more than present photographs how the photographer intended them to be seen. That is incredibly difficult to do in the web format. But that’s your job nonetheless.

So, what’s this mean?

This means that the process of designing a photography site is to remove as much from the screen other than the photographer’s intent. Just like the photo book’s spreads are intended to support the photographer’s style and message, so to should the site’s design. Support is a key word though—the interface should be firmly in the backseat.

That doesn’t mean the design isn’t important—of course it is. Design choices will be critical to support the message based on the subject matter, format, aspect ratio, etc. All of those choices summed up will lead to a unique set of design choices to best communicate the work.

So, put the photo front and center, develop a layout specific to the work and remove everything else. Easy to say, hard to do.

Hard for many reasons

Just the technicalities to achieve the above are difficult. Developing a layout design that supports the work is usually even more difficult. However, the most difficult thing of all may be fighting your own impulses.

The great thing about great photo books is that they’re focused. They usually encompass a single project and there’s little more in the book other than the work.

On the other hand, the vast majority of photography sites are exponentially larger in scope. They contain a photographer’s entire body of work, which necessitates navigating through projects. Then there’s the whole other litany of content the site supports, such as a bio, contact info, press, etc. Once you actually get to the content, there’s typically some UI to paginate/navigate through content.

Then there’s the invisible stuff which still ends up complicating matters. Modern sites often have custom typefaces which puts a strain on bandwidth. Don’t forget your analytics tracking, cookies, etc. Lastly, there’s the omnipresent social media buttons… I’ll leave that subject be, but suffice to say, it’s not helping showcase the work.

Mind you, the photograph hasn’t even been mentioned yet.

All of the above are voluntary, self-inflicted wounds that get in the way of the work. It’s your job to hide or preferably remove as much of the above as possible.

Let’s get concrete

I can’t tell you how do best display work I haven’t seen to convey the message I’m unaware of. However, I can give you some general suggestions to best set you up for success. First and absolutely foremost…

Do not, under any circumstances, touch the photo

The only entity that should be making creative decisions on the photography is the photographer. That seems straightforward, but it’s often ignored. Photos are often cropped to allow them to be full bleed on the screen—this is horrible. This effectively allows an arbitrary window size on someone’s device make the creative decision on how to crop the photo.

Trent Parke’s Minutes to Midnight. This photo was almost assuredly cropped, but done so with the creative intent of the photographer. Big difference.

On top of cropping, don’t cover it up. Don’t put captions on top of your photos—because then you often need an overlay background as well. It’s just a mess. Just put the text below the image.

Lastly, hover effects that mutate the image (e.g., scaling, opacity changes, color overlays, etc.) are a no go. You have no control over where a viewer moves their mouse—all you’re doing is setting up situations where the photo is not rendered how it was intended to look.

Note, the above doesn’t apply to cases when you’re using photos for navigation. But if you’re displaying a photo for the sake of people looking at it, please just leave it be.

Make the photo big

It’s a photography site, right? The photo should be the primary subject. That means you need to find ways to get as much off the screen as possible to give the photograph room to be large. Navigation, pagination, footers, social media buttons—they’re all getting in the way.

That said, I’d suggest not going full bleed—mainly because in doing so there aren’t explicit bounds to the photo. Is the photo being cropped by the screen or is it actually this size? Creating some margins around the photo removes that question.

Show the photo quickly

This is a bit more technical, but you really need to devote time and effort to get the photos to show up fast. Having an effective compression strategy, displaying an appropriately sized image for the screen size it’s being view on and image lazy-loading will all help. Make this a priority—it’s critical.

Not to beat a dead horse, but not loading social media buttons, analytics and other unnecessary distractions will help your site (and your photos) load faster.

Keep the rest basic

If you’re doing the first three things effectively, your next job is to do as little as possible to just not screw it up. Photography sites are about photography. They’re not about motion treatments, typographic self-aggrandizement or sophisticated UI designs. Beautifully vibrant or moody subtle colors should be coming from the photographs, not from the site design.

In short, the more anything else grabs the viewer’s attention, the less the photos will. That’s bad.

Ignore any/all of the above if it conflicts with message you’re trying to convey

Obvious, but worth explicitly calling out.

How can I make this happen?

Well, that’s the rub. When I went about putting my photos online, I had absolutely no intention to build my own site. It was time consuming and laborious. The problem is that I couldn’t find a single solution, free or paid, that met these needs. There isn’t a single photo site template that’s designed to meet anyone’s specific needs. That’s the exact opposite purpose of templates—they’re intended to be flexible. But in that flexibility I failed to see how most met anything more than the baseline criteria of getting your photos to show up in a browser.

This (unfortunately) meant that I had to make my own site. This also means I’m implicitly suggesting the same to you as the reader. Which is what most people probably do not want to hear. But first things first, I highly suggest you go to a library and look at some photography books. A good place to start is The Americans and/or The Suffering of Light. Give them a gander and see if the format resonates with you. If so, the work will be worth it.

Prologue

At the risk of getting too philosophical, now is a good time to ask yourself why you want a photo site to begin with. If the honest answer is that you want to make a name for yourself or grow a social media following then you’re in luck! Don’t waste your time wrestling with how to best display your photographic work on this inhospitable platform. Just sign up for Instagram and post your work there—it’s honestly a better use of your time.

However, if you’re looking to present your work with as much creative control as possible and don’t have a publisher or gallery knocking on your door to help make that happen, you may be stuck where I was. Hopefully a little further ahead after reading this.

I’ve worked on a design system or two in my time and have learned a lot through each process. The most important lessons I’ve learned uncoincidentally have little to do with design. Instead they’re are about the factors and approaches that set teams up for success.

With that said, these are my personal learnings. There’s ample room for disagreement or different conclusions. Like most things, your mileage may vary.

Design systems help good teams work better

Design systems are great, but they are nothing more than a tool. Like any other tool, they are an amplifier of strong fundamentals. Design systems won’t fix people/cultural problems. They won’t help you get along with your colleagues. They won’t make those who don’t value design to magically see the light. Design systems are a tool to use — when adeptly wielded, they can help people be more effective.

It’s critical to not put the cart before the horse. Get the foundational aspects of your practice right. You need that strong foundation to ensure your tool is adeptly used. Design systems, like any other tool wielded in the wrong hands, can do a lot of damage. The dysfunctions within your team/org will manifest in your system. If there’s no cross-functional collaboration or teams can’t drive to actionable decisions, those problems will plague your design system.

Your team’s output is a reflection of your company’s culture and the people that work in it. Nail down the fundamentals of a strong design practice — its people, culture and relationship with the greater org. This will set you up for success when you create your design system, or anything else for that matter.

Design systems need commitment and a mandate

I’m not the kind of guy that enjoys the idea of forced mandates. I think it’s often abused and employed for the wrong reasons. But I do believe design systems need commitment and (yes) a mandate for them to take hold. The bigger the company, the more explicit that mandate should be. Let me explain why.

Building a design system is tough in the best of times. It’s all the more difficult in large orgs with disparate/disconnected teams. That’s ironic as they’re where systems can provide serious value. You’re going to push up against human dynamics like skepticism, disagreement and territorialism. You’ll face nuts-and-bolts challenges of making a system that actually works for all involved. There will be hiccups, mistakes, misunderstandings — you name it. You’ll struggle with the transition pains as teams move to your new, fledgling system. None of these no fall within the realm of “fun” — for anyone.

Any of the issue above will make it tempting for teams to bounce when the project hits a pothole. The rationale will be rational; Team A needs to ship a new feature now and migrating to the design system will slow that down. Team B’s designer is a rock star and your system will stifle her ability to deliver tailor-made solutions. The tough thing is their concerns are valid — when assessed in a vacuum.

That’s why there needs to be a clear message — from leadership — that states, “This is what we’re doing. We need everyone to help make it succeed”. It has to be a collective understanding that the system is for the collective benefit. While each team is going to feel a little pain, the goal is a net positive effect. The only way for that net positive effect to take hold is if everyone is pushing in the same direction.

Without that mandate, there’s a good chance you’ll be herding cats. Cats that don’t report to you.

The hypotheticals will kill you

It’s easy to see need for another component, another color, another xyz. Need is a strong word and usually confused with desirable. The more colors, type treatments, or whatever, you add to the system, the more complexity you own. More complexity means more maintenance, bugs, regressions, confusion, misinterpretation and general headaches. Be very careful what you commit to. It’s much easier to add things to a system than it is to remove them. Complexity is the rope you’ll hang yourself on.

Discipline yourself to keep your system as small as possible. Focus on existing, real-world team needs and address them with the simplest solution. Yes, you won’t have everything people want. Yes, there will be gaps. And, yes, those gaps mean you may need to re-evaluate past decisions (more on that later).

I’d argue a little thrash is far more healthy than a bloated system that can no longer get out of its own way.

Design systems are a product with three distinct and equally-important cohorts of users

Design systems are not only for people interacting with its byproduct. These systems are as much for the designers and developers using it to build interfaces. If the system doesn’t help designers create better solutions, they won’t design with it. If developers hate building with it, they won’t build with it. If either design or developers resist, there’s a good chance it the end-consumer won’t see it either.

Design systems need to equally serve three cohorts — designers, developers and end-consumers. Designers and developers need the tools (e.g., interface components) and resources (e.g., usage guidelines) to help them succeed. The system needs to objectively make them to be more effective at their job. It doesn’t hurt if it makes work more enjoyable as well.

The challenge is to provide enough tools/resources to help them succeed. But not too much where it becomes restrictive. Your system is never going to have all the answers. But, it can and should be your team’s design philosophy made manifest. Meaning your system should communicate the principles needed to guide going “off-script”.

There will be thrash, so have a plan to mitigate it

You’re going to get a lot wrong in your system out of the gate. It’s just going to happen. You’ll discover you had no idea what you had no idea about. Then you’ll have to make changes — sometimes drastic ones. Meaning there will be thrash. And thrash is not fun for the people consuming your system.

I am fully committed to the notion that thrash is a good thing. It means you’re committing to a direction, learning from its execution and then adjusting. But for the sake of the people using your system (and your relationship with them) it can’t be a constant. You shouldn’t fear thrash, but you need to know when it’s useful and how to help mitigate its downsides.

One of the best way to mitigate the downsides of thrash is to start small — with everything. Keep the system small, keep the documentation small, keep its user-base small. It’s crucial to limit how many people you involve. Any major thrash (like the near-180-degree turns) should occur as early as possible in the system’s lifespan, before the cement fully “hardens”.

It’s also important to only expose teams to thrash that are comfortable with it. You often need as many champions as you can get in the infancy of a design system. The last thing you want to do is create unneeded doubt and frustration.

Here’s how I like to go about kicking off a design system:

• Start with a core set of designers. Make sure the system’s design fundamentals support their core needs — or at the very least don’t hinder them. This isn’t only about missing components/states. The guidelines need to make sense, and the support materials set them up for success. Start building once you get thumbs pointing up.
• Once you’ve coded out your teeny-tiny design system, you go through the same exercise with a core set of devs. Make sure they’re on board with how you’ve constructed components and that they’ve enough guidance.
• With design and dev loosely vetted, it’s time to test it on something real. Engage with one team on a project that isn’t time-sensitive or mission critical. Bonus points for teams that are comfortable with ambiguity.

The above assumes you’re constantly evolving the system based on learnings and communicating them out. All this is in the spirit of maximizing learning while mitigating risk. As you learn from these small iterations, you’ll gain confidence that the system is ready for broader use. You don’t need to go out the door with everything if teams can see it’s headed in the right direction.

The “big reveal” approach is not advisable. You’ll be at the pre-release stage forever if you try to solve every potential solution from day one. Which means no one is using your design system — which defeats the point.

Making it is the easy part

So your design system hit the 1.0 milestone and is in circulation. Now comes the hard part. You’ll deal with training, governance, avoiding bloat and maybe the trickiest, managing progress.

Let me clarify — when I say managing progress, I’m not talking about the progress you see from 1.0 to 1.0.1 or 1.1. I’m talking about the progress from 1.0 to 2.0. It’s inevitable that almost everything that you make in the system — no matter how good — will run its course. Interface paradigms change, new platforms show up and the product you built the system for evolves. There will come a time when you’ll have a critical mass of ideas to improve your system based on the new reality of today.

If your system stagnates, your product will as well. Meaning you risk you design system becoming a liability. You can’t stop improving the system, but it also can’t be an agent of chaos within your org. I haven’t come across one-size-fits all solutions for these problems. You need to have an idea of what works for your system and your stakeholders. It doesn’t need to be a perfect answer, but you need to at least plant a flag in the sand. You may end up supporting multiple versions to give teams some flex on when they migrate. You may risk creating more forward-thinking solutions so they have a longer half-life. You can do a lot of things, but what’s most important is you have a plan that works for everyone invested in the system.

In short, you’re never done with your system. That’s something that everyone needs to be keenly aware of before committing.

Bonus: We’re designing with systems backwards

This point is a little less actionable, but I’m putting it here for folks to chew on. I posit that the way we apply design systems within the design practice is 180 degrees from where it should be. The value of code-backed design systems (what I like to call “design systems”) is that it’s theoretically a single source of truth. That’s not the case for 99.9% of teams though. In reality, we have two sources of truth. We have the the code-backed design system and an ancillary library of symbols for our design tool du jour. This is a big problem.

It’s a big problem because we’re not working from that elusive single source of truth. This is humorous since it’s one a core selling point of design systems yet it’s rarely ever the case in practice. It’s all too easy for a code-backed design system and its supporting design library to bifurcate. Bifurcation starts small and then all those small things add up. Then the questions and confusion begin. Sure, you can dedicate processes and time to keep the two in sync. But then you’ve dedicated processes and time to keep the two in sync. Meaning you’re losing out on other areas of opportunity that aren’t (dare I say) busywork.

The source of truth in product development needs to be whatever is going to show up in production. That happens to be code. The problem there isn’t a go-to solution to design with code-based components. We’re just limited by what’s possible. But there’s movement to meet this need and it’s well worth keeping an eye on. AirBnB’s Sketch React and Framer X show the promise of a very different future. But they are still very much in that promise stage. I look forward to when something makes good on it.

Let’s wrap this up

So that’s it. Those are the most important things I’ve learned in my time creating systems. Adobe XD, Figma or Sketch? Who cares. React or Angular? Whatever. Design tokens? Sure. The thing about those things is that they’re all temporary. The real, immutable challenge involves people and the people-stuff that’s always hard. It’s hard to get buy-in, align teams and create a shared understanding that everyone is embarking on a ride. A ride that’ll likely involve turbulence.

Make sure your team is ready, willing and able (in the literal sense). Get everyone to commit. Have a healthy fear/respect for complexity and hypotheticals. The rest is downhill from there.

So, to try to sum this all up in one sentence — Make it small, make it real, make it quickly — when your org is ready.

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.