Senior Product Designer · Product Builder
Back
UAEN
Back

Design Mentoring

Teaching designers to think, not just to design

Education
Design Mentoring
Role: Mentor, curriculum designerFormat: Online and offline, groups and 1:1Scope: Curricula, reviews, webinars, learning materials

I started mentoring almost at the same time as my design career. After completing my first design course in 2015, I was invited back by the school's founder to mentor the next group.

What started as reviewing student work grew into years of teaching: designing curricula, running webinars, and creating assignments and learning materials. Over the years, more than 700 students went through my online and offline groups and individual mentoring, from people opening Figma for the first time to working Junior and Middle designers.

Over time, I realised that teaching design wasn't really about Figma, UX methods, or visual rules. It was about teaching people how to approach an unfamiliar problem, turn ambiguity into structure, find information, make decisions, and explain their reasoning.

700+
students online, offline, and 1:1
10+ years
in design education
Beginner → Middle
different experience levels
Learning model

From following instructions to solving problems

I didn't teach a set of tools. I built an environment in which a person gradually moved from following instructions to solving problems on their own. The curriculum follows the same path.

  1. 01

    Instruction

    Clear steps and a result to reproduce

  2. 02

    Practice

    Repetition until the tool stops getting in the way

  3. 03

    Understanding

    Seeing why one version works better

  4. 04

    Reasoning

    Comparing options and choosing with arguments

  5. 05

    Independence

    Finding the problem and the path without a mentor

At the start
“What should I do?”
A good result
“Here is the problem I found, the information I gathered, the options I explored, and why I chose this solution.”
01 · What I was teaching

Tools change. The ability to think stays.

The programme covered everything a working designer needs: from UI and Figma to research, design systems, portfolio, and career. But all of it was connected by one core skill.

For me, product thinking isn't knowing CJM or Jobs To Be Done. It's the ability to take a messy situation, give it structure, find the real problem, gather information, explore options, and make a decision you can explain.

Product thinking
  • UX
  • UI
  • Research
  • Information architecture
  • Figma
  • Prototyping
  • Motion
  • Design systems
  • Portfolio
  • Communication
  • Career
  1. Chaos
  2. Structure
  3. Problem
  4. Information
  5. Options
  6. Decision
  7. Solution
02 · Designing the curriculum

Do, see, understand, do again

A course is a product too: it has users, a flow, a pace, and drop-off points. I designed programmes so that each module builds on the previous one and complexity grows gradually.

My rule of thumb was 20% theory and 80% practice. Instead of theory, theory, theory, exam, students first did something, saw the result, understood why it worked, and did it again.

20%Theory
80%Practice
  1. Do
  2. See
  3. Understand
  4. Do again
  1. 01

    Tools

    • Frames
    • Text
    • Color
    • Figma basics
  2. 02

    Visual craft

    • Composition
    • Typography
    • Spacing
    • Visual hierarchy
  3. 03

    Interface

    • Components
    • Auto Layout
    • Screens
    • Responsive layouts
  4. 04

    Experience

    • User flows
    • Information architecture
    • Scenarios
    • Prototypes
  5. 05

    Product thinking

    • Research
    • Evidence
    • Decomposition
    • Decisions
    • Metrics
  6. 06

    Professional practice

    • Handoff
    • Communication
    • Presentation
    • Portfolio
    • CV and interviews
03 · Same curriculum, different people

The curriculum could be shared. The path through it couldn't.

Two students in the same group could need opposite things. To understand where each person was, I looked at several dimensions rather than a single level.

DimensionWhat I looked for
Product thinkingCan they turn ambiguity into structure?
Visual craftCan they see hierarchy, spacing, and composition?
ToolsCan they use their tools without fighting them?
UXDo they think in scenarios rather than screens?
IndependenceDo they search and experiment before asking?
CommunicationCan they explain why they made a decision?
04 · Different starting points

Different starting points need different strategies

Knowing the gap is only half of the work. The other half is choosing the next step that a specific person can actually take.

High motivation, low experience

Give momentum

  1. Reference
  2. Reproduce
  3. Result
  4. Questions
  5. Experiment

A few concrete lessons and a result repeated one to one. It removes the fear of the tool, and then independence is added step by step.

Low autonomy

Make the next step smaller

  1. Button
  2. Component
  3. Section
  4. Page
  5. Flow

Smaller scope, more specific tasks, and more short iterations, so the person keeps moving instead of getting stuck.

Strong UI, weak product thinking

Ask why

  1. Why?
  2. For whom?
  3. What happens before?
  4. What happens after?
  5. What supports this?

Questions instead of answers, plus breaking down existing products to see the decisions behind the screens.

Middle designer

Expand the system

  1. Design systems
  2. Development
  3. Metrics
  4. Research
  5. Handoff

Not “draw better”, but prototyping, motion, HTML/CSS/JS basics, engineering communication, and implementation review. Design starts to live inside the product, not inside Figma.

05 · Feedback is a loop

Several short reviews instead of one final critique

Feedback worked best as a continuous cycle rather than a verdict at the end. Each iteration was small enough to act on quickly, and each review built on the previous one.

  1. Attempt
  2. Feedback
  3. Reflection
  4. Iteration
  5. Review

Written

Comments directly in Figma, next to the element they refer to.

Video

5–30 minute recorded reviews that show the reasoning, not just the verdict.

Iterative

Several short reviews instead of one big critique at the end.

Shared

Students also learned from reviews of other people's work.

06 · Experience before theory

Let people see the difference before explaining it

A beginner makes a weak UI. I don't give them a lecture on typography, composition, negative space, hierarchy, Gestalt, and color. I say: change this, move this, reduce this, align these.

They make version two, then three, then four, and start to see the difference themselves. Only then do I explain why the newer version works better, and the theory finally has something to attach to.

  1. Correction
  2. Repetition
  3. Pattern recognition
  4. Explanation
  5. Principle
  6. Independent application
07 · Feedback without killing motivation

Correct the work. Protect the motivation.

Feedback has to be specific enough to act on, but it shouldn't turn into a stream of criticism that makes someone afraid of the next iteration.

  1. 01What worksSo the person knows what to keep.
  2. 02What needs improvementSpecific and limited to what matters now.
  3. 03What has progressedCompared with their previous version, not with others.
08 · From screens to reasoning

The real outcome is a different way of thinking

Before
“I designed 10 screens.”
After
“I found users struggling with this scenario, looked through reviews and discussions, explored several approaches, and chose this flow because…”
  • OutputReasoning
  • InstructionsDecisions
  • ScreensScenarios
  • MethodsTools
  • ExecutionOwnership

Many students went on to find their first design roles. That is their achievement; my part was helping them learn how to think about the work.

09 · There is no universal design process
If all you have is a hammer, everything looks like a nail.

Research methods, personas, journey maps, workshops, and frameworks are tools. Knowing them doesn't mean they belong in every project.

With more experienced students, the conversation moved from the “correct” process to choosing what a specific decision actually needs.

  1. Beginner

    What is the correct process?

  2. Intermediate

    Which methodology should I use?

  3. Experienced

    What do I need to learn to make this decision?

10 · What mentoring taught me

Teaching made me understand my own decisions

To explain a decision to someone else, I had to understand it well enough myself. The same principles now shape how I work with product teams.

01

Explain complexity simply

If I can't explain a decision, I probably don't understand it well enough yet.

02

Give direction, not answers

Help the person move forward without doing the work for them.

03

Adapt to the person

One person needs a specific instruction. Another needs the right question.

04

Build systems for growth

Current state, desired state, the gap, and the next achievable step.

05

Question the tools

A method exists to solve a problem, not the other way around.

06

Keep learning

Teaching others kept me searching, testing approaches, and rethinking what I knew.

The best outcome of mentoring is when the mentor becomes unnecessary.

A designer who can find information, structure ambiguity, make decisions, critique their own work, and explain their reasoning no longer needs someone standing behind them telling them what to do.