A Few Moves Ahead

I’ve spent enough time playing chess to get somewhere around a 2000 rating, which sounds more impressive than it feels when you’re staring at a position you somehow managed to ruin in twelve moves.

The biggest difference between how I play now and how I played years ago isn’t that I’m calculating twenty moves into the future. Most of the time I’m not. It’s that fewer things on the board feel completely new.

I recognize positions I’ve seen before. I know when a pawn structure is going to become a problem later, when a piece looks active but doesn’t actually have anywhere useful to go, or when a perfectly reasonable move creates a weakness that won’t matter until ten minutes from now.

That same habit has slowly become part of how I design.

The screen directly in front of me matters, but I’m almost always thinking about what it forces us to do next.

Experience changes what you notice.

There is a long history of chess research around this idea.

The classic memory experiments that followed Adriaan de Groot’s early work found that experienced chess players were dramatically better at remembering positions taken from real games than beginners were. When researchers disrupted the board and arranged the pieces more randomly, that advantage became much smaller.

The interesting part wasn’t that stronger players had magically better memory. They had thousands of familiar patterns stored in their heads. Instead of looking at twenty individual pieces, they were recognizing relationships between them.

Later research added more nuance to those early findings. Skilled players can retain some advantage even with random positions, but the basic idea has held up well: expertise changes the way you perceive familiar information in the first place.

I think design experience works in a similar way.

When I first started designing websites, I spent a lot of mental energy on the thing directly in front of me. How wide should this button be? Is this font too large? Does this shade of blue look better?

Those questions still matter. I just don’t experience them as isolated decisions anymore.

A button immediately makes me think about what happens when the label gets longer, how it behaves on mobile, what the disabled state looks like and whether we’re creating a new pattern or reusing one we already have. A navigation change makes me think about what happens when another section gets added six months from now.

The individual choice is still there. I’m just seeing more of what comes attached to it.

A small design decision rarely stays small.

This becomes especially obvious in product work.

Imagine a team asks for one new filter on a dashboard. On the surface, it sounds like a tiny request. Add a control, open a menu, let the user choose an option.

But the filter immediately creates more questions.

What happens when nothing matches it? Can multiple filters be active at once? Do selections persist when the user comes back? What happens on a phone where there isn’t enough horizontal space? Does the URL change so someone can share the filtered view? Do we need a reset state? Does another user role have access to all the same options?

None of those questions means the feature has to become complicated.

The point is that the first rectangle you draw in Figma isn’t the whole feature.

Thinking ahead means noticing those consequences early enough that the team can decide which ones matter, rather than discovering them one by one during development.

That is where product design starts feeling a lot like chess to me.

A move doesn’t have to be bad immediately to be bad.

Sometimes the problem is what it leaves behind.

Design systems are a kind of shared memory.

This is also why I’ve come to appreciate design systems more as I’ve worked on larger products.

A design system can look like a library of buttons, colors, type styles and components. Technically, that is part of it. But the useful part is all the previous thinking stored inside those pieces.

Someone has already decided how inputs behave when they contain an error. Someone has thought through what a button does while an action is loading. Someone has established the spacing between a label and a field.

Those decisions don’t need to be solved again on every screen.

That frees the designer to think about the problem that is actually unique.

The same thing happens in chess. Recognizing a familiar position doesn’t play the game for you. It simply means you don’t have to spend all your attention rediscovering basic relationships between the pieces.

You can spend that attention somewhere more useful.

A good design system does the same thing for a team.

Consistency isn’t really about making everything match.

This is one place where I think design systems sometimes get misunderstood.

Consistency doesn’t mean every screen has to look identical or that the system should prevent anyone from making something new.

The goal is to stop spending creative energy on decisions that don’t deserve to be creative every single time.

If the product already has a clear way of showing an error, I probably shouldn’t invent another one because the new version looks interesting in my mockup.

If we’ve already established how cards, spacing and typography behave, I can use those decisions as constraints and spend more time thinking about the workflow itself.

Constraints are useful when they protect attention.

That applies outside product design too. A brand system does the same thing. Once the typography, colors and visual language are established, every new landing page or sales deck doesn’t need to reinvent the company.

You create enough structure that the next decision starts further ahead.

The best move isn’t always the most interesting one.

Chess also teaches you a slightly annoying lesson: sometimes the right move is boring.

There may be a beautiful attacking idea on one side of the board, but if your king is exposed or a piece is hanging, that’s the problem you have to solve.

Design has plenty of versions of this.

A team may want to add animation to a landing page when the hierarchy isn’t clear yet. A product may need a new feature when users are still struggling with the existing workflow. A redesign may introduce a completely new component when the current system already has something that does 90 percent of the job.

The visually interesting decision isn’t automatically the useful one.

I think experience makes you slightly less attached to proving that you designed something.

Sometimes the better design decision is to reuse what exists, simplify something or remove a choice entirely.

That doesn’t make for a dramatic before-and-after slide.

It often makes for a better product.

Thinking ahead doesn’t mean designing everything in advance.

There is another side to this.

Once you start looking for downstream consequences, it’s very easy to go too far and try to solve every possible future state before anything ships.

That isn’t useful either.

Chess players don’t calculate every legal continuation on the board. There are far too many. They narrow the possibilities using experience, principles and the information available in the position.

Product work is similar.

You don’t need to design the next five years of a platform because someone asked for a new settings page. You need enough awareness of the system to avoid backing the team into an obvious corner.

There is a difference between thinking ahead and designing ahead.

I care much more about the first one.

If we know that a table will eventually have thousands of records, that should probably influence the structure today. If there’s only a vague possibility that the product could someday support seventeen user roles and six languages, we don’t necessarily need to build the entire architecture around that possibility this afternoon.

The skill is deciding which future consequences are real enough to matter now.

This is probably what experience buys you.

When people talk about seniority in design, the conversation often becomes a list of deliverables. Research. Wireframes. Prototypes. Design systems. Workshops. Developer handoff.

Those are all things a designer might do, but I don’t think they explain the biggest difference experience makes.

For me, it’s increasingly about recognizing patterns earlier.

You see that the seemingly simple request is going to create three new states. You notice that a visual inconsistency isn’t really a color problem; it’s a missing rule in the system. You understand when something needs exploration and when the team already has enough information to make a decision.

You still get things wrong. Chess has made sure I stay familiar with that feeling.

But over time, fewer problems arrive completely disguised.

That’s why I still like the phrase a few moves ahead.

It isn’t about predicting everything that’s going to happen.

It’s about looking at the decision in front of you and understanding that it rarely ends there.

The longer I design, the less I think expertise means having all the answers.

More often, it means seeing the next question before it becomes expensive.