THAYNÁ COELHO
I design learning systems that reduce complexity and improve performance.
Choose your learning experience
On a rush? Start here.
Illustrative case study: Global onboarding for a distributed team produces inconsistent results: slower ramp times, repeated questions, regional gaps. Here’s how I’d redesign the system from the decision layer up.
What I’d aim for: faster time to productivity · fewer repeated questions across teams · a more consistent onboarding experience globally
01
A diagnostic instinct: find the real problem before designing the solution
02
Systems that work at scale: built for the 10th time, not just the first
03
Simpler operations: fewer decisions, less friction, faster performance
About me
I've spent 5 years working in global operations, close enough to the business to understand that most learning problems are actually systems problems in disguise.
I work at the intersection of instructional design and enablement strategy: I figure out where performance is breaking, then build the simplest, most scalable solution to fix it.
Built enablement for a global support org: cut ramp time by 50% and onboarded 400+ hires across LATAM, EMEA and APAC
Run customer education for 40,000+ customers across the world
Part of the pilot team behind Deel Academy: 130+ courses, 150+ countries
I work in English, Portuguese, Spanish and French
How I work
I start with the system.
Mapping where decisions break down, where complexity is unnecessary, and where the simplest intervention will have the most impact.
-
Before I open a slide deck or write a single learning objective, I map what's actually happening.
Who decides what?
Where does the process break down?
What does the environment reward?
Most performance problems have a systems cause. I find it first, so I'm solving the right thing.
-
Complexity is not a sign of quality. I build the simplest intervention that changes behaviour, the thing that gets used, not just launched. If a one-page decision guide does the job, I'm not building a course. If the system needs restructuring, I design for that, not around it.
-
Scale is a design constraint, not an afterthought. I think about maintenance, localisation, and hand off from the start. So what I build doesn't collapse under its own weight six months later. Everything is documented and transferable.
-
Every project I deliver comes with a rationale.
Why I made the choices I did
What I ruled out and why
What to watch for as the context evolves
This means stakeholders understand the system they're inheriting, not just the output.