Author: Marcel Jaudian

Six months ago I started drawing for twenty minutes every day, with one rule: it doesn’t have to be good. That rule turned out to matter more than the drawing itself. What I actually want to talk about isn’t technique — it’s what changed once “every day” stopped being conditional on whether the day’s sketch was worth showing anyone. The daily sketching habit benefits I actually noticed had almost nothing to do with getting better at drawing, even though, unsurprisingly, that happened too.

Why “Even Badly” Is the Important Part

Most advice about creative habits focuses on consistency, which is true but incomplete. The part that actually made this stick was giving myself explicit permission for the daily output to be bad. Not “acceptable,” not “a rough draft of something better” — actually bad, with no qualifier attached. The moment a habit requires each entry to clear some quality bar, it stops being a habit and becomes a small daily performance review, and performance reviews are exhausting in a way that quietly kills consistency within a few weeks.

Once the bar disappeared, something practical happened: the habit became about showing up, not about the drawing. Some days that’s a five-minute doodle of a coffee cup. Some days it’s forty-five minutes on a study that actually goes somewhere. The habit doesn’t know the difference and doesn’t need to. Only the calendar does.

The Actual Daily Sketching Habit Benefits, After Six Months

1. It Rebuilt a Skill I’d Let Go Quiet

The technical improvement is real but boring to describe — hands get faster, proportions get more reliable, the gap between what I see and what lands on the page gets narrower. That was expected. What wasn’t expected was how much of my earlier hesitation to draw at all had nothing to do with skill and everything to do with treating each drawing as a referendum on whether I was “actually an artist.” Doing it daily and badly quietly dissolved that question by making it irrelevant.

2. It Became a Reliable Reset, Not Just a Practice Session

The twenty minutes turned into something closer to a decompression valve than a skill-building block. On the days a client project ran long or a piece of code refused to cooperate, the sketch became the one part of the day with no external stakes attached to it — nobody grading it, nobody billing for it, nobody’s deadline riding on it.

The bad drawings did more for me than the good ones. The good ones were nice. The bad ones proved I’d show up again tomorrow regardless.

3. It Changed How I Look at Everything Else

Six months of drawing whatever was in front of me — a chair, a stranger’s hands on a jeepney, the particular way afternoon light lands on a wall — made we notice more of it in the first place. That noticing leaks into the other half of the work too. A layout decision, a spacing choice, a color pairing: all of it gets a little more deliberate once you’ve spent six months practicing the specific discipline of actually looking at something before deciding what it is.

What Doesn’t Get Talked About Enough

Nobody mentions how much the habit depends on removing decisions, not adding discipline. I don’t decide each morning whether to draw — that decision got made once, six months ago, and now it just happens, closer to brushing teeth than to a creative choice I’m actively making. That’s not a coincidence. It’s the same underlying idea as the quiet systems and tokens that hold a design together — remove a decision from the daily pile by deciding it once, well, and letting it run on its own from then on.

The other thing that doesn’t get talked about: keeping a habit this small and unaccountable only works because other parts of the practice aren’t small or unaccountable. Client work has real deadlines and real scope, which is exactly why knowing when to say no to a project matters — it protects the twenty minutes that have no scope at all. A calendar with no boundaries anywhere doesn’t leave room for a habit that intentionally has none.

If You’re Thinking About Starting One

• Pick a length short enough that skipping it feels genuinely unnecessary, not “understandable.” Twenty minutes, not two hours.
• Decide in advance that bad days count exactly as much as good ones. Write that rule down if you have to.
• Don’t post every day’s output anywhere. An audience turns “even badly” back into a performance.
• Track the streak, not the quality. The streak is the actual habit. The quality is just a side effect that shows up on its own, eventually, if you let it.

Six months in, I still can’t always tell you in advance whether a given day’s sketch will be any good. I can tell you, with total confidence, that I’ll draw something tomorrow anyway. That certainty, it turns out, was the entire benefit I was looking for and didn’t know how to name at the start.

Every project I’ve worked on has a moment, usually a few weeks in, where the pace suddenly changes. New sections stop taking days and start taking hours. Nobody argues about whether a heading should be 28px or 32px, because the decision was already made — three sprints ago, by nobody in particular, and now it’s just how the project works. That shift is the entire point of building invisible design system tokens: not a component library anyone has to think about, but a set of quiet defaults so consistent that the question never comes up again.

Most write-ups about design systems focus on the visible parts — the Figma library, the component gallery, the Storybook instance with forty variants of a button. Those things matter, but they’re not what actually makes a project feel slow and deliberate in a good way. The infrastructure that does that work is almost never seen. It’s the token layer: color, spacing, type scale, radius, motion timing — the primitives everything else is built from.

What Invisible Design System Tokens Actually Look Like

A token, in the boring technical sense, is just a named value: --space-4 resolves to 16px, --color-ink resolves to a specific shade of near-black. The naming is deliberate — tokens describe a role in the system (“ink,” “surface,” “accent”), not a raw value (“dark gray,” “#1c1a17”), so the underlying value can shift without anyone needing to hunt down every place it was hardcoded. That’s the whole trick. Nobody has to remember a hex code, because nobody is supposed to be typing hex codes in the first place.

The test I actually use isn’t “does this look nice in the style guide.” It’s this: six months from now, when a new section needs a spacing decision, does the answer already exist? If yes, the token layer is doing its job. If someone has to guess or eyeball it against the section next to it, the system has a hole, and that hole will get wider every week it stays unpatched.

Naming Is the Real Design Work

I’ve spent more hours arguing with myself over a token name than over the actual value it holds. That’s not a waste of time — naming is where a design system either becomes invisible or becomes yet another thing to remember. A scale that goes space-1 through space-8 only works if the jump between each step is predictable enough that a reasonable person can guess the next one without opening documentation. A palette named after literal colors (“blue-500”) ages badly the moment brand colors shift; one named after roles (“accent,” “surface-raised”) survives a full visual redesign without anyone touching a component.

Knowing What Not to Abstract

The failure mode I see most often isn’t too little structure — it’s too much. Someone gets excited about tokens, and six months later there’s a --button-primary-hover-border-radius-large variable that exists to solve a problem nobody actually had twice. Every token is a promise that a value is meaningful enough to name, document, and maintain. Most one-off decisions aren’t. A design system with a token for everything is functionally the same as a design system with tokens for nothing — the signal disappears into the noise.

My rule of thumb: a value gets promoted to a token the third time it repeats with intent, not the first. The first time, it’s a decision specific to that screen. The second time, it might be a coincidence. The third time, it’s a pattern worth naming — and naming it is what actually lets a fast-moving project feel unhurried, because the fifty-first decision was already made by the third.

A design system isn’t the parts anyone can see. It’s the hundred decisions nobody has to make twice.

Where This Overlaps With Everything Else

This same instinct — building quiet structure so you don’t have to relitigate the same decision on a loop — shows up outside of code too. It’s basically the same discipline behind learning when to say no to scope creep: a boundary you set once, clearly, so you’re not negotiating it fresh every time it comes up. And it’s the inverse of what makes a daily creative habit like drawing worth keeping — there, the value is in staying unsystemized, in letting each day’s sketch be its own small decision rather than a repeatable pattern. Structure where structure earns its keep, and looseness everywhere else, is the same principle wearing two different outfits.

What This Looks Like in Practice

• Start with five to eight spacing tokens, not fifty — you can always add, and adding is cheap; removing an already-adopted token is not.
• Name by role, not by appearance, so the name still makes sense after a rebrand.
• Let a value repeat twice before you name it. Naming too early locks in a decision that hasn’t proven itself yet.
• Document the “why” behind a token once, in one place, instead of re-explaining it in every pull request that touches it.

None of this is exciting to write about, which is more or less the point. The best compliment a design system can get is that nobody mentions it. When invisible design system tokens are doing their job, the conversation moves straight to the actual problem — the feature, the content, the thing the user is trying to do — because the hundred small decisions underneath it were already settled, quietly, a long time ago.

I turned down four projects this year before I noticed the pattern. Each one, taken individually, looked like a reasonable yes — decent budget, interesting brief, a client who seemed easy enough to work with on the first call. It wasn’t until the fourth one that I actually sat down and looked at what they had in common, and once I saw it, I couldn’t unsee it. This is the short version of what a year of learning to say no to client work actually taught me, because it wasn’t any single project that did it. It was noticing the shape they all shared.

The Four Projects, Briefly

I won’t use names, but the shape is worth describing. The first was a full site rebuild with a two-week deadline that both of us knew, deep down, wasn’t realistic — I said yes anyway, because the budget was good and I didn’t want to seem difficult. The second was a “quick logo refresh” that turned into a six-week identity overhaul with no corresponding change in scope or fee. The third had a client who wanted daily check-ins on a project with a four-month runway. The fourth was almost a repeat of the first, except this time I actually paused before answering.

Here’s the pattern, once I finally looked at it straight on: every one of those projects asked me to absorb somebody else’s poor planning as if it were my own problem to solve. Not maliciously — most clients aren’t trying to take advantage of anyone, they’re just optimistic about timelines and unaware of what a realistic scope actually costs. But optimism on their end doesn’t obligate me to make it my emergency.

Learning to Say No to Client Work Is a Skill, Not a Personality Trait

I used to think some people were naturally good at setting boundaries and some people weren’t, and I filed myself firmly in the second group. What actually changed wasn’t my personality. It was that I started treating “no” as a professional tool with a specific use case, the same way I’d treat any other part of the job — something with a technique, not a talent you either have or don’t.

The Questions I Started Asking Before Saying Yes

• Is the timeline realistic for the actual scope, or does it only work if nothing goes wrong?
• Am I the right person for this, or just the available one?
• Does saying yes to this mean saying no to something I actually want to do later this quarter?
• If this exact project came to me a year from now, at double the rate, would I still hesitate?

That last question does the most work. If the honest answer is “yes, I’d still hesitate even at double the money,” the problem was never the fee. It was the shape of the project itself, and no amount of money fixes a bad shape — it just makes the bad shape more expensive to sit inside of.

A “no” said early, clearly, and without over-explaining, costs you almost nothing. A “yes” said out of guilt costs you the whole project.

What Changed Once I Started Saying No

The obvious thing happened first — fewer projects, initially, which was uncomfortable in a very predictable way. What I didn’t expect was how much better the projects I did keep got. Turning down the wrong four freed up enough attention that the right ones actually got my best thinking instead of my leftover energy. Scope creep, when it did show up, got caught in week one instead of week six, because I’d built the habit of naming a boundary out loud the moment I felt myself absorbing a problem that wasn’t mine to absorb.

This Isn’t Just a Client-Work Problem

The same instinct is really just the human version of the same kind of systemized boundaries I built into this site’s design system — a decision made once, clearly, so it doesn’t need to be relitigated every time a similar situation shows up. And it’s balanced by something almost opposite: keeping a small daily habit, like sketching, that has no boundaries at all, no scope, no client, nothing to say no to — just twenty unguarded minutes that belong entirely to me. Having strong boundaries in one part of the practice is part of what makes it safe to have none in another.

What I’d Tell Myself a Year Ago

Saying no doesn’t require a long explanation. “This timeline doesn’t work for the scope as described — here’s what would” is a complete sentence, and clients respect it more often than the anxious brain expects. The version of me who took on that first rushed rebuild wasn’t being generous. He was avoiding a slightly uncomfortable conversation by agreeing to a much more uncomfortable few weeks later. Learning to say no to client work, it turns out, was never really about the clients. It was about noticing that avoidance dressed up as flexibility is still avoidance, and it always sends the bill later, with interest.