What teaching art taught me about product design

Before I designed software, I taught art.

Drawing, painting, composition, anatomy, colour theory... I taught students of all types and ages. The job was never really about teaching technique. It was about making an abstract idea land in someone else's head, using the tools and vocabulary they already had to get them closer to their goals.

Some students were young aspiring artists, designers, tattoo artists, or art restorers on a mission to gain technical expertise. Others were children learning fine motor skills and confidence through playful artistic expression.

There were also teenagers who had an artistic inclination but had developed bad habits, lacked confidence, or simply needed a more structured approach. And there were retired and elderly people who, after a lifetime of working, felt called back to a long-lost passion — or simply wanted a relaxing social activity that kept their minds sharp.

These were my clients and my users.

Each needed to be treated differently, but with the same fundamental goal: to become confident and independent creators.

Looking back, I realize that teaching gave me a way of working that I now bring into product design.

Nobody arrives with your context

In a classroom, you can't be annoyed that a student doesn't know what you know. You have to meet them where they are.

Sometimes that meant explaining the block-in method for the tenth time. Sometimes it meant finding a completely different way to explain the same thing because the first nine hadn't landed. Sometimes the same concept needed to be explained differently depending on the student.

The point was to build the bridge between what they knew and what they needed to understand next.

I see the same thing in product teams.

If, for example, engineering doesn't immediately see why a loading state needs staging, that isn't necessarily resistance. They may simply be looking at the problem from a different context.

Good communication isn't about having the clearest explanation in your head. It's about making the idea accessible from where the other person is standing and matching your communication to the audience.

Critique is a thinking tool

In the early stages, it's really easy for an art student to confuse the work with the maker. Poorly delivered critique makes people get defensive and freeze. When this happens, they stop listening. This is a growth and decision killer.

Bad critique is essentially an opinion delivered with confidence.

Good critique, on the other hand, helps make decisions and helps people grow. It first describes what's actually there before judging it, giving the person something they can act on.

I learned to approach critique through a few simple questions:

• What is the current state?
• What is the goal?
• Did they achieve it?
• If not, why?
• What could change?

When I run a team session, whether it is a review or a refinement, I try to create the same conditions as in a classroom. The goal isn't for everyone to defend their work or for the loudest opinion to win.

It's to get people to reason about the work out loud, with curiosity.

Instead of "I don't like this," we can ask: "What is actually happening here?"

Instead of "This feels wrong," we can ask: "What user problem are we trying to solve here, and does this UI facilitate it?"

Critique stops being about taste and becomes a tool for thinking.

Anatomy taught me to look beneath the surface

One of the things I spent years learning about and teaching was anatomy.

If you want to draw a convincing human figure, you should not simply copy what the surface looks like. To render the crease of a shirt, or the shape of a shoulder, you need to understand the way the arm moves and the structure of the muscles and skeleton underneath it.

The visible form is a consequence of what is underneath.

I remember students sometimes trying to fix a drawing by adding more detail. They would spend time refining the shape of the nose or the eyes  — when the underlying structure was wrong.

No amount of detail could fix the problem.

That shaped the way I look at design.

When something feels wrong in an interface, or when a PM comes with a half-baked solution and no clearly defined problem, my first instinct isn't necessarily to change the interface. I want to understand the structure underneath it.

• Who is the user?
• What is the user actually trying to do?
• What constraints does the system have?
• What happens before and after this interaction?

A good solution shouldn't begin with personal preference. It should emerge from understanding the need and the constraints around it.

That doesn't mean there is always one objectively correct solution. Product design is full of trade-offs, and sometimes a solution has an expiry date. We account for that with iteration.

Teaching taught me to resist the urge to immediately fix things.

To observe first.

To meet people where they are.

To separate judgement from critique.

And to look beneath the surface before changing it.

Even though I don't officially teach art anymore, I use these principles every day.