Career GrowthApr 09, 20248 min read

TheFeynmanTechniqueforDesigners

Teach to learn, simplify to understand. A practical method for deepening your grasp of design concepts.

Darian Rosebrook
Darian RosebrookDesign Systems Architect & Design Technologist

There is a gap that haunts every growing designer. You look at a layout and you know it works. You can feel the visual hierarchy pulling your eye, sense the spacing creating rhythm, recognize that the color choices are doing something right. But when someone asks you to explain why it works, the words fall apart. You reach for "it just feels balanced" or "the whitespace is nice" and you know, even as you say it, that you are not actually explaining anything.

That gap between intuition and articulation is the single biggest barrier to career growth in design. It is what separates the designer who can execute from the designer who can lead. It is what makes the difference between a portfolio case study that impresses and one that falls flat. And it is exactly the gap that the Feynman Technique was built to close.

I have spent years teaching design concepts through the Compass of Design community, working with designers at every stage of their careers. The pattern is consistent: the designers who grow fastest are not the ones consuming the most courses or tutorials. They are the ones who force themselves to explain what they are learning, out loud, in their own words, to someone else. That act of explanation is where real understanding is forged.

What the Feynman Technique Is

Richard Feynman was a Nobel Prize-winning physicist known for his extraordinary ability to explain difficult concepts in plain language. He believed that complexity was often a sign of shallow understanding dressed up in jargon. If you truly understood something, you could explain it simply.

The technique that bears his name has four steps:

  1. Choose a concept. Pick the thing you want to understand better. Be specific. Not "design systems" but "how design tokens create consistency across platforms."
  2. Teach it in simple language. Write or speak your explanation as if your audience has no background in design. No jargon. No shorthand. If you cannot explain it without specialized vocabulary, you are borrowing someone else's understanding instead of building your own.
  3. Identify the gaps. Pay attention to where your explanation breaks down. Where did you get vague? Where did you wave your hands and say "and then it just kind of works"? Those gaps are the exact boundaries of your understanding.
  4. Simplify and refine. Go back to the source material. Study the parts you could not explain. Then try the explanation again. Repeat until you can walk someone through the concept from start to finish without hitting a wall.

The core insight is deceptively simple: the act of teaching is the most effective form of learning. Not because teaching helps other people (though it does), but because the process of translating knowledge into plain language forces your brain to organize, connect, and pressure-test what you actually know.

Why It Works for Design

Design is a discipline built on concepts that feel intuitive but resist explanation. You can spend years developing a sharp eye for typography, layout, and color without ever building the vocabulary to describe what you are seeing. That creates a strange paradox: experienced designers who make excellent decisions but cannot defend them in a review, justify them to a stakeholder, or teach them to a junior.

This matters more than most designers realize. Design interviews do not test whether you can push pixels. They test whether you can articulate your thinking. A portfolio review is not about the final screens. It is about the story you tell: what the problem was, why you made the decisions you made, and what you learned. Hiring managers are listening for clarity of thought, not just quality of output.

The Feynman Technique addresses this directly. When you practice explaining "visual hierarchy" to someone who has never heard the term, you are not just studying visual hierarchy. You are building the exact communication muscle that design careers are built on. You are training yourself to think in explanations rather than instincts.

Design also draws from dozens of adjacent fields: psychology, business, engineering, accessibility, research methodology. Career changers often feel overwhelmed by the volume. The Feynman Technique gives you a concrete way to process it. Instead of passively consuming, you actively reconstruct each concept in your own words, which dramatically improves both retention and depth.

Applying the Technique to Design Concepts

Let me walk through three examples to show what this looks like in practice. Each one demonstrates how the technique exposes gaps that passive learning never would.

Example: Explaining Visual Hierarchy to a Non-Designer

First attempt: "Visual hierarchy is how designers arrange elements so that the most important things stand out." Not wrong, but thin. A non-designer would nod politely and still have no idea how it works.

Push yourself. You might arrive at: "When you look at a page, your eye does not read every element equally. Bigger text grabs attention before smaller text. Bold colors before muted ones. Isolated elements before clustered ones. Visual hierarchy is the deliberate use of size, color, contrast, spacing, and position to control the order in which someone notices things. A well-designed page guides your eye like a path: first here, then here, then here."

The second explanation required naming specific mechanisms. If you could not list them, that is your gap. The Feynman Technique does not just test your knowledge. It maps the edges of it.

Example: Explaining Design Tokens to a Product Manager

Try explaining design tokens to a product manager who needs to know why they matter, not how they are implemented.

First attempt: "Design tokens are variables that store design decisions." True, but meaningless to a non-technical audience.

Better: "Imagine you decide that every primary button in your product should be a specific shade of blue. Instead of telling every designer and developer to remember that exact blue, you give it a name: 'primary-action-color.' That name is a design token. It is a single, named decision that gets used everywhere. If you later decide to change that blue to a slightly different shade, you change it in one place and it updates across every screen, every platform, every component. Design tokens are how a product stays visually consistent without relying on everyone's memory."

The gaps this exposes are telling. Can you explain the difference between a reference token and a semantic token? Can you articulate why naming matters? Can you describe what happens in an organization that does not use tokens? Each gap points you toward a specific area to study.

Example: Explaining Accessibility to a Skeptical Stakeholder

Designers are regularly asked to justify accessibility work to stakeholders who see it as a compliance checkbox. This is where the technique becomes a career tool.

A weak explanation: "Accessibility means making our product usable for people with disabilities. It is the right thing to do and legally required." This frames accessibility as an obligation, which is why stakeholders treat it as a checkbox.

Feynman-refined: "About one in four adults has some form of disability, including permanent conditions like blindness, temporary ones like a broken arm, and situational ones like using your phone in bright sunlight. A button with sufficient color contrast helps someone with low vision, but it also helps everyone outdoors. Captions help deaf users and anyone in a noisy office. Accessible design is not an edge case. It is design that works for how people actually use products. If our product is hard to use for 25 percent of the population, that is a market problem, not just an ethics problem."

Notice how the simplification process forced a reframing. The first version presented accessibility as a burden. The refined version presents it as good product thinking. That reframing only happened because the Feynman process demanded a clear, jargon-free explanation that would actually make sense to the audience.

Making It Part of Your Practice

The Feynman Technique is not something you do once and move on. It is a practice, like sketching or journaling, that gets more valuable the more consistently you do it. Here are four ways to integrate it into your design work.

Teaching as Learning

Every design critique is a Feynman opportunity. When you present work, explain the reasoning, not just the screens. When reviewing others, articulate why something does or does not work in plain language rather than gut reactions.

Mentoring juniors is one of the most powerful exercises. When someone asks why you chose a particular layout, you cannot fall back on "it felt right." You have to construct a real explanation, and that deepens your own understanding every time.

In the Compass of Design community, I have watched designers transform their understanding by helping others. The person explaining almost always learns more than the person receiving the explanation. That is the Feynman Technique in action.

The Rubber Duck Method for Design Decisions

Software developers have a practice called "rubber duck debugging" where they explain their code to a rubber duck on their desk. The act of verbalizing the logic often reveals the bug. Designers can do the same thing. Before a design review, talk through your decisions out loud. Why that type scale? Why that padding? Why did you group these elements and separate those? When your explanation stumbles, you have found a decision that needs more thought before it faces stakeholders.

Writing as a Feynman Exercise

Blog posts, case studies, and internal documentation are all Feynman exercises in disguise. The best portfolio case studies are teaching documents that walk the reader through the problem, the reasoning, and the outcome. If you are struggling to write a case study, the technique gives you a diagnostic: the parts you cannot explain clearly are the parts you did not fully understand during the project. Go back, reconstruct the reasoning, and the case study will be better for it.

Keeping a Concept Journal

Dedicate a notebook to Feynman explanations. When you encounter a new concept, write a one-paragraph explanation in your own words, jargon-free, at a level a friend outside design could follow. Review these entries periodically. You will be surprised how often an explanation you thought was solid reveals new gaps on a second read.

When to Reach for This Technique

This is a deliberate practice best applied where the return on effort is highest.

When you are stuck on a concept from a course or book. If you have read the same chapter twice and it still feels fuzzy, stop reading. Start writing an explanation instead. The act of writing will show you exactly which piece is not clicking.

Before a design review or presentation. Talking through your reasoning in plain language before the meeting is the single best preparation you can do. It surfaces weak justifications, reveals assumptions you have not examined, and builds the fluency you need to handle hard questions in the room.

When preparing portfolio case studies. The strongest case studies teach the reader something. They do not just show what you did; they show how you thought. The Feynman Technique ensures that your thinking is clear enough to actually teach from, which is what separates a forgettable case study from a memorable one.

When you feel like an imposter. Imposter syndrome often comes from the gap between what you can do and what you can explain. The Feynman Technique closes that gap. Every concept you can articulate clearly is one less thing that feels like a secret you are faking your way through.

Start Today with One Concept

You do not need to overhaul your learning process. Pick one design concept you use regularly but have never explained out loud. It could be visual hierarchy, responsive design, the gestalt principles, color theory, or information architecture. Open a blank document and explain it as if you were teaching a friend who works in a completely different field.

Do not look anything up while you write your first draft. That is the point. The draft exposes the gaps. The gaps tell you what to study. The studying produces a richer understanding and a better explanation you can use in your next critique, interview, or case study.

The designers who grow fastest are the ones who build the habit of turning what they know into something they can teach. The Feynman Technique is the simplest way to build that habit. It costs nothing, requires no tools, and works on any concept at any level. The only requirement is honesty about what you do and do not actually understand. That honesty is where growth starts.