Cette édition est aussi disponible en français. Lire en français →

I remember when I started my career.

It took weeks, sometimes months, to learn how to use a tool.

I typed MS DOS commands. I tamed Oracle tools like wild animals. And I loved it.

My colleagues came to me when they were stuck. My managers noticed.

I got promotions. I got raises. I got recognition.

And every time, it confirmed what I believed: mastering the tools was my value.

I was so sure of it.

Then I changed jobs. Eight times in twenty years.

And at each new place, I did it again. I learned the tools. I became the power user. I worked with software engineers to improve and roll out new systems. And I was proud of it every single time.

But the further I progressed in my career, the more I saw it clearly.

That part was the easy part.

The real work was getting people to actually use the tools without burning out. It was making sure the tools supported the way people worked, not the other way around. It was knowing when to push for the right investment, and how to make the case for it.

Because when tools don't fit, people find workarounds. And workarounds are costly, for the humans who carry them, for security, and for quality.

In organisations carrying years of legacy, that skill mattered far more than knowing every feature of every platform.

I didn't stop mastering tools. I just stopped thinking that was enough.

I see it every day in my consulting work.

Design teams that are talented, committed, and navigating on their own.

Everyone figuring it out as they go, often on their personal time, without clear, pragmatic and human guidelines from their organisation.

And the consequences are always the same. Burnout. People questioning their own value. Inconsistent outputs. Security and quality risks that nobody planned for. And costs that keep climbing.

With AI, those problems don't disappear. They scale.

Because AI doesn't fix fuzzy inputs. It amplifies them.

The quality of what you get depends entirely on the quality of what you put in. Your user research. Your design system. Your roadmaps. Your project and product documentation. Your naming conventions.

Poor inputs mean poor outputs. At scale, at speed, and at an exponential cost.

That's not a tool problem. That's an organisational problem.

And today, my mission is to help teams develop sound judgment consistently.

That's why I do both.

I consult because I need to stay in the field. To keep making decisions under real constraints, with real teams, in real organisations.

I teach because it forces me to step back from my own practice. To explore academic work that challenges or backs up my convictions. To make implicit knowledge explicit.

And because learners are ruthless in the best possible way. If something is inconsistent in what I share, they will see it. They will say it.

That's a risk. And it's worth taking every time.

It keeps my practice agile, transformative and robust.

I recommend it to anyone who can and wants to do it.

That's what Learnings is about.

What I discover in the field. What the research says. What I test, what fails, what works.

I won't always talk about AI. For me, it's a tool in the background, not the main character.

I'll talk about design, organisation, leadership, culture, inclusion, and whatever my curiosity leads me to.

I'm Zalihata. More than twenty years in tech and education.

I'm glad you're here.