What It Actually Takes to Institutionalize Human-Centered Design in a Global Development Organisation

Eight years ago, I came back from Stanford with a methodology I was convinced could change how we design development programmes. What followed was a humbling, iterative, occasionally frustrating — and ultimately rewarding — journey of trying to make that vision real across the Aga Khan Foundation. This is the story of every barrier we hit, every solution we built, and how AI ended up becoming the unexpected final piece of a puzzle I have been working on for nearly a decade.

In some ways, this work isn't new for AKF. The Aga Khan Foundation was founded in 1967 with the explicit intention, in the words of its founder, of "melding professional management and technical skills with genuine participation by local people to explore innovative approaches to development." Human-centered design offered a structured way to make that aspiration practical at every stage of programme design.

Eight years ago, I set out to make this the way AKF works — not a workshop people attend, but a mindset that shapes how programmes are designed across the 18 countries where AKF works.

What followed was a lesson in how hard that actually is.


The first wall: understanding it and applying it are not the same thing

When no existing toolkit fits, you build your own

From a room with post-its to a virtual whiteboard without borders

I started by pitching this methodology to anyone who would listen — programme officers, country directors, CEOs. The early reaction was remarkably consistent. In a presentation, it made immediate sense. Of course you should design with communities rather than for them. Of course you should test before you scale. Of course empathy should precede solutions.

But moving from "this makes sense" to "I can actually do this" turned out to be a much bigger leap than I anticipated.

It's worth noting something important about who I was working with. Ninety-nine percent of AKF's roughly 4,000 staff are local to the places we serve. The challenge wasn't teaching outsiders to listen to communities. It was giving people who already understood those communities deeply — often having grown up in them — a structured way to translate that knowledge into programme design.

In practice, HCD felt overwhelming. Where do you start? Which methods do you use? How do you balance rigour with the realities of a programme that has deadlines, limited budgets, and staff who are already stretched?

We ran workshops. Five-day in-country trainings. Bootcamps. They worked — in the room. People got energized. They left motivated.

Then they went back to their programmes. And the energy faded.

Not because they didn't believe in it. But because belief isn't the same as capability. When you're a programme officer in Tajikistan juggling a dozen priorities, "go apply what you learned" isn't enough of a bridge.

The trainings were working — but they were revealing a deeper gap.

There's a big difference between learning HCD with an experienced coach guiding you through each step, and going back to your programme and trying to apply it on your own. In a facilitated setting, the coach carries a lot of the invisible weight: knowing which tool to use at which moment, reading when a team is ready to move to the next phase, helping people sit with ambiguity without abandoning the process. Without that scaffolding, teams — especially those new to design thinking — would quickly lose their footing.

What people needed wasn't just training. They needed structure they could rely on when no one was in the room with them.

We looked at existing HCD toolkits. There are good ones. But most were designed for product teams in tech companies or innovation consultancies — the language, the examples, the assumptions about resources and timelines didn't map onto community development work in Central Asia, East Africa, or South Asia. And most assumed a level of prior design knowledge our teams simply didn't have.

So we decided to build our own.

After five years of field testing across sectors and communities — iterating based on real feedback from practitioners in India, Tajikistan, Afghanistan, Syria, and beyond — we launched the AKF HCD Toolkit: an open-source, modular guide that provides step-by-step structure for teams at any experience level. It addresses the specific challenges of development work: entrenched social issues, power dynamics between communities and organizations, the need for ethical co-design, even environmental sustainability.

12 guidebooks, full of methods, tools, templates, and real examples. Available on the AKF Learning Hub, free to anyone. It won the Don Norman Design Award and has been used by 1,600+ practitioners from 1000+ organizations.

It addressed the scaffolding problem. But it surfaced a new one.

Before 2020, HCD was something you did in a room. Post-it notes on a wall, teams physically clustering ideas together, the energy of people working through a problem side by side. We ran all our in-country workshops exactly that way.

Then COVID hit and the world closed.

We moved to Zoom and Teams. We adopted Mural — a virtual whiteboard — and rebuilt all our templates for digital collaboration. A team scattered across the country — some working from home, some at the office, some in the field — could now work on the same board in real time.

It turned out to be one of the best things to happen to our reach. Remote collaboration meant teams could work across geographies and train alongside colleagues from several countries simultaneously — something logistically impossible before. The constraint became a capability. Work that was geographically bounded was no longer constrained by borders.

When the system depends on you, it isn't really a system

The time problem — and how AI finally answered it

The time problem — and how AI finally answered it

As more teams started using the toolkit, a pattern emerged. People would be working through a phase — synthesizing interview data, deciding how to prototype a service — and they'd hit a decision point. Should I use this tool or that one? Is this the right moment to move to the next phase? What does a good insight statement actually look like?

And they'd send me a message.

I'd set up a call, talk them through it, get them unstuck. It worked. But I was one person, and the network was growing. I couldn't be on call for 18 country offices.

There's something humbling about realizing that the system you built was running through you — and that scaling it meant trusting a tool to do something I had been doing personally for years.

So we built an AI-powered HCD Coach — a custom bot trained on everything we know about our approach and methodology. Practitioners describe what they're trying to do, where they're stuck, what phase they're in. The bot recommends tools, shares examples, drafts session agendas, helps facilitators plan workshops. It works in multiple languages — which matters enormously in a network where English is often a second or third language.

The coaching didn't go away. It scaled.

There's a fair critique of HCD I've heard many times: it takes too long. And it's not wrong. Genuine community engagement takes time. Reading secondary research takes time. Designing interview guides, conducting interviews, synthesizing findings — a rigorous HCD process is not a fast one.

For years, my answer was: that time is the point. Skipping it is how you end up with solutions that don't work for the people they're meant to serve.

I still believe that. But AI has genuinely changed what's possible within the process.

Our most recent Global HCD Bootcamp brought together 16 teams from 16 countries — 64 participants over 12 weeks. And this time, we didn't just teach HCD. We taught HCD with AI embedded at every phase. How to use AI to synthesize secondary research. How to generate and refine interview guides. How to cluster insights, draft "How Might We" questions, stress-test prototypes.

One team compressed weeks of interview synthesis into an afternoon — and used the time they got back to run two additional rounds of community feedback before finalizing their prototype.

That's the shift. AI holds the promise of compressing the journey from problem to a solution that could actually work by at least tenfold. Not by skipping the human work. By making everything around it faster, so the human work gets the space it deserves.

Institutionalizing HCD isn't just a capacity problem. It's a system problem.

Every solution we built addressed a real barrier — and revealed the next one. Training built motivation but not sustained capability, so we built a toolkit. The toolkit was comprehensive but left people stuck at decision points, so we built an AI coach. The process was rigorous but time-intensive, so we embedded AI throughout.

What I didn't expect, eight years in, is that the hardest part was never the methodology. It was building the ecosystem and the conditions in which it could actually live

The work is still not finished. The toolkit keeps evolving. The AI coach gets smarter with every question it's asked. And this year, we hope to launch a self-paced experiential course — HCD + AI for Social Innovation — openly licensed, designed to take any development practitioner from HCD fundamentals to confident, AI-supported practice.


The goal remains what it always was: not to make HCD a programme people attend, but a way of thinking and working that stays rooted in the communities we serve.