Systems thinking is the new requirement.
Your portfolio can’t show it.

What it means is less obvious. Something bigger and vaguer than a component library. Seeing the whole. Thinking in systems instead of screens. See every part as a system in a system.

So what is it, and why now?

Design is a strange word. It describes both the act and the result. We design something, and then we point at the thing and call it a design.

For a long time those two were hard to separate. Thinking, making and the final artifact were connected. A designer explored the problem by sketching, made the decisions inside the work, and arrived at something that could be shipped. The thinking was embedded in the making.

When designers got more senior they started asking bigger questions. Direction, business, organisation, purpose. We gave that another name: strategy.

AI is pulling those two apart.

Making has become a commodity. Interfaces, prototypes, code, copy, visual directions, produced faster and in far greater volume, at almost no cost. The craft still matters. The manual production needed to reach a plausible result is shrinking.

That exposes something that was always true but easy to hide inside the process. Deciding what should be made is a different problem from making it.

If I can produce ten interface directions in an afternoon, the hard question is no longer whether I can make them. It’s which one deserves to exist.

Systems thinking widens the frame. Instead of treating the thing in front of you as the problem, you look at what surrounds it. The user, the organisation, the technology, the incentives, the policies, the other people, and the consequences that turn up two years later.

A badly performing form might need a better interface. Or the form might only exist because of an internal process, a regulatory constraint and a database decision made ten years ago. You can improve that form, make the local experience better, and never touch the thing that keeps producing the problem. UX asks how to make the form better. Systems thinking asks why the form exists at all, and what breaks if it goes away.

Service designers have worked like this for years. Journeys, blueprints, ecosystem maps all push the frame past the interface. Systems thinking goes one step further. It asks what keeps producing the behaviour, and where you could intervene to actually change it.

Both podcast versions of this are small enough to steal. Stone: zoom out one click from the problem you were handed. Just one, then look again. Silber: do less. Extend the thing that already exists, build on the component you already have, or ask whether the new thing needs to exist at all.

Here is where it gets messy. The phrase is doing at least three different jobs, and they are not the same job.

Most job ads mean design systems. Components, tokens, reusable patterns, consistency across a library. Useful work, but close to the opposite of what I just described. Lindsey Norberg draws the line well: systems thinking is about why a system behaves the way it does, design systems are about building interfaces more efficiently. One helps you build the button. The other helps you ask why anyone needed a button there.

Silber means something else. Primitives that compose, so the product holds together instead of turning into a pile of one-off features. That is architecture, and it stays inside the product.

Stone means something bigger than both. Looking across all the business domains and pulling out the building blocks everyone else will need. Platforms. Paved paths. That is barely a design skill in the old sense. It is closer to what a principal engineer does.

Then there is the real thing. Feedback loops, what keeps producing the behaviour, where you could intervene, who gets hit two steps away. The form nobody thought to ask about.

Four demands, one phrase.

The market changed what it buys. It used to buy output. Screens, flows, a design system, a portfolio thick with artifacts. Now it says it wants judgment.

The hiring process did not change. You still send a portfolio, and portfolios show what you made.

Nobody can see the thing you decided not to build.

There is no agreed way to test for it either. Interviewers know how to grade a redesign. Nobody has a reliable method for grading a decision that never became a screen. A requirement nobody can measure is a requirement nobody can fail, which makes it very comfortable to put in an ad.

That’s the trade designers are stuck in. The skill that suddenly costs the most is the one that leaves nothing behind to look at.

Putting “systems thinking” in your CV will not help. Everyone will have done that by Christmas, and then it means as much as “team player.”

Start by working out which version they are asking for. The rest of the requirements list usually tells you. Figma and tokens sitting next to it means design systems. Platform, partner and multi-device means architecture. Ambiguity and “across domains” means the Stone version. Answer with feedback loops when they meant component reuse and you will sound impressive and irrelevant.

Then show the decision instead of the deliverable. In a case study, spend more words on why this and not the other four. What you argued against. What you removed. The form you deleted is a better story than the form you redesigned.

Show what happened afterwards. What it changed for support, for the ops team, for the next release. If you don’t know, say you don’t know. Admitting where your view of the system ends is also systems thinking.

Bring one example where widening the frame made things slower or worse. The necessary details that suddenly got invisible. Nobody believes the version where zooming out always works.

When making costs almost nothing, the only expensive thing left is knowing what is worth making. Designers have always done that part. We just never had to prove it separately, because the proof was the work.

Now the work is cheap.