Nicole Trigodet : "Don't let AI define your project"

"We're going to create a chatbot for our beneficiaries." "We'd like to automate our guidance process with AI." "We're thinking of generating our training content with generative tools."

If you've ever said (or heard) one of these phrases, you're not alone. These ideas aren't bad. But they share a common thread: AI defines the starting point, not your beneficiaries.

This is the trap that Nicole Marion Trigodet sees everywhere. An expert in learning product design, she has worked at OpenClassrooms and Tomorrow University, and co-authored Cap IA, an action-research project on AI implementation in education. We invited her to share her perspective on AI, and frankly, it made us think.

Here are our key takeaways: three principles for successfully launching an AI project, and two pitfalls that are very easy to fall into. The article takes about ten minutes to read: we chose to delve deeper rather than stay on the surface. The headings are designed to be explicit, so if you're in a hurry, you can simply skim them to get the main points.

(Prefer to hear it directly? The link to Nicole's full conference is at the bottom of the article.)

Principle 1 — Ask the right question from the start: not "what can AI do?", but "what do my beneficiaries truly need?"

Imagine an organization that supports job seekers. It thinks: "What if we created an AI that automatically writes CVs based on a discussion? That would save us time, and it would help our beneficiaries."

The idea isn't bad. But it starts with a tool and its capabilities, not a need. Nicole calls this approach augmenting the existing : you take what you already do (writing CVs) and accelerate it with AI. Useful, but limited.

The other approach, which she calls AI by design, it changes the starting point. We no longer start from "how can AI help us create resumes faster?", we start from "what does our beneficiary truly seek?". The answer is never "a resume". It's more like: "finding a job where I feel I belong", or "escaping the anxiety of having to start all over again after 50", or "regaining self-confidence after two years of unemployment".

When we frame the question like that, the resume reverts to what it is: one tool among many. And other avenues open up. Perhaps before the resume, a tool is needed to help people articulate their journey when they struggle to highlight their strengths. Perhaps an assistant is needed to prepare for interviews. Perhaps a system is needed that identifies opportunities compatible with a non-linear career path.

This shift in questioning is what researcher Clayton Christensen theorized as Jobs to be Done(a concept developed in Competing Against Luck, 2016): people don't use a service for what it is, but for what it allows them to accomplish in their lives. Same initial intuition, radically different solution, just because we changed the initial question.

In practical terms. You already know the life change you want to see happen for your beneficiaries: it's your raison d'être, you've been working on it for years. The question isn't to rediscover it. It's about verifying that your AI project is truly the vehicle for it. A simple test: try to write in one sentence what the tool will concretely enable a beneficiary to do, experience, or become. "Thanks to this, [such type of beneficiary] will be able to [such concrete result in their life]." If the sentence doesn't flow naturally, or if it ends with something that talks about your process rather than their lives, it's probably because the project is poorly designed.

Pitfall 1 — Beware of removing friction where it is useful

AI promises to make everything seamless. Your jumbled thoughts become a clean summary. Your hastily told journey becomes a resume. It's practical, and for many uses, that's exactly what we want.

But for projects aiming to help someone grow, make them more independent, or teach them something lasting, effort isn't a problem to eliminate. That's often where real progress happens.

Learning scientists refer to desirable difficulties : some efforts slow down learning in the short term, but it's precisely these efforts that make it lasting. Too easy, we get bored and retain nothing. Too hard, we give up. It's in this sweet spot, neither too easy nor too hard, that transformation occurs.

A recent study (CMU, Oxford, MIT, UCLA) shows what happens when AI removes this sweet spot. Two groups of students solve math problems: one with an AI assistant, the other without. At the 13th problem, the AI is removed without warning. The assisted group gets lower scores, but more importantly, they give up more often. By eliminating effort, the tool not only impoverished learning: it also undermined their capacity to try.

What does this mean in practice for a non-profit? Imagine a non-profit that supports young dropouts in building a career plan, and is considering an AI that automatically generates this plan based on a few questions. An obvious time-saver for coaches. Except that what makes the project useful for the young person isn't the final document: it's the process of self-reflection, testing hypotheses, and confronting contradictions. If the AI does this work instead of the young person, the deliverable is there, but the effect is nil.

Nicole gives a contrasting example, where AI is used intelligently. A leadership coaching company organizes conflict management sessions, followed by role-playing between participants. But between the group session (comfortable) and the role-play with a human (intimidating), there was a huge gap. Many didn't take the plunge.

Their solution: insert eight minutes with an AI chatbot between the two. The AI serves as a warm-up, a safe space to practice before the real human confrontation. The AI doesn't remove the important difficulty; it just helps to overcome the initial hurdle. The transformation itself always happens through interaction with another human.

In practice. When you consider integrating an AI tool somewhere in your process, ask yourself: at this point, was the effort I'm eliminating an effort useless (administrative, repetitive, needlessly frustrating) or an effort that fostered growth for the beneficiary? If you're in the second case, don't eliminate the effort. Use AI to help the beneficiary overcome it, not bypass it.

Principle 2 — Make your beneficiaries co-designers, not just testers

Nicole tells a story from her youth. At 16, as a summer camp counselor, she was helping 3-to-5-year-olds with a puppet project. Her colleague announced that the children would cut the cardboard themselves. With box cutters.

"I was convinced they would get hurt. But in fact, their precision was impressive. Because they had been told it was dangerous, they were extremely focused."

There's a default way of designing a project for beneficiaries: you identify their needs (often in a team meeting), you design the solution, and then you deliver it to them. At best, you have them test it at the end to adjust a few details. The Brazilian educator Paulo Freire called this the banking model of education : where the beneficiary is treated like an empty account into which knowledge is deposited, without ever asking them what they think or what they already know.

Building with your beneficiaries is the opposite. It's based on the principle that they know better than you what it's like to live their situation, and that the best solutions emerge from discussing with them, not by thinking on their behalf.

In practice, this can take several forms:

- Invite 3 beneficiaries to the scoping meeting from the start, not just at the end for validation. Not as mere witnesses, but as contributors.

- Organize a design workshop where your beneficiaries draw their ideal tool themselves, even roughly. You'll be surprised by the ideas that emerge.

- Test in real-world conditions very early, even with an ugly prototype. Better a makeshift item that reveals a real problem than a polished one that hasn't faced reality.

- Include beneficiaries in the governance of the project, not just in user groups.

Especially since the young people you work with (if you're working with 16-24 year olds) haven't waited for your tool to use AI. They're already using ChatGPT, sometimes clumsily. Involving them upstream also means leveraging what they already know, instead of imposing a solution designed without them.

It's not a hands-off approach. It's simply about stopping believing you have the answer before asking the people most concerned.

In practice. For your next project, you could identify 2 or 3 beneficiaries (varying in age, background, digital comfort level) and invite them at 3 key moments: the initial framing, the design of the first prototype, and the decision on adjustments. Your beneficiaries are involved as project stakeholders, not “just” testers.

Principle 3 — Your values are not a preamble, they are a design tool

Many organizations view AI ethics as a separate, specialist topic. Something entrusted to an expert or a committee, and checked off in a "social responsibility" box. Nicole observed a different, much more practical approach.

She provides a particularly relevant example for non-profits. A British organization prepares adults, who often left school very early, for their secondary school leaving exams. They attend evening sessions, persevere, participate. And then, five days later, when it's time to hand in homework: nothing. A blank page, loss of confidence, giving up. It wasn't due to a lack of ability, but fear of doing it wrong.

The organization decides to develop a chatbot to help them overcome this hurdle. But instead of starting with possible features ("we could make an automatic corrector", "we could make a chatbot"), they start from their values: compassion, building self-confidence, respect for the difficult relationship these adults have with school.

These values translate into very concrete decisions:

- Warm, adult tone (no infantilizing "well done, you did a great job!")

- Celebration of small victories but without overdoing it

- Key decision: final feedback is still given by the human tutor, never by the AI. Because for this audience, being graded by a robot would have replicated exactly the academic trauma they are trying to heal.

The interesting point is that each design choice embodies a value. The warm tone embodies compassion. Human feedback embodies trust. The tool doesn't explicitly say "we respect our learners": it demonstrates it in every interaction. Your organization's values, taken seriously, are already an excellent guide. No need for a PhD in AI ethics for that.

In practice. Revisit your organization's values, those you display and uphold. For each design choice for your future tool (tone, design, features, what is automated or not), ask yourself: does this choice truly express them, or does it contradict them?

Trap 2 — Adding AI without parallel human support

In 2023, Khan Academy, one of the largest free online educational platforms, launched Khanmigo, an AI tutor, with a strong promise: "a tutor in every student's pocket, 24/7, for free." On paper, it was an educational revolution. Three years later, its founder himself admits that it hasn't transformed results to the expected scale. His self-diagnosis: he deployed the tool in classrooms as if its mere availability would make it useful.

This trap is tempting for many non-profits: if my beneficiaries' problem is a lack of access to support (lack of counselor time, lack of funding, lack of geographical coverage), then an AI that supports them continuously, for free, at any hour… that solves the problem, right?

Not necessarily. Because there's a big difference between having access to a tool and being able to make the most of it. Beneficiaries who need the most help are often those least equipped to use a tool on their own: disciplining oneself for 30 minutes a day when one has a chaotic life, formulating the right question, persevering when stuck—all of this requires conditions that aren't created simply by distributing a tool. This is what education researchers call the Matthew effect: tools primarily benefit those who already have the resources to make the most of them, and risk widening disparities instead of reducing them.

The data from Khan Academy confirms this. Students who use the platform 30 minutes a day make enormous progress. The problem is that these students represent only 5% of the user base. For the remaining 95%, the tool makes almost no difference. And these are precisely the ones we wanted to help.

This is not a criticism of Khan Academy in particular. Ivan Illich wrote about it as early as 1973 in Tools for Conviviality : beyond a certain threshold of autonomy, tools become counterproductive. They replace human connection instead of supporting it, and they widen disparities instead of reducing them.

This gives you a simple rule: every time you add AI to your process, ask yourself what human element needs to be strengthened in parallel. More time with a counselor at key moments. A weekly call to ensure the person doesn't give up. A group workshop to share challenges. A point person to call in case of a roadblock.

AI can multiply your reach. But it doesn't replace what makes your organization unique: the relationship, the presence, the listening, the bond that builds over time.

In practical terms. For every AI feature you envision, list a human feature that supports it. If you can't find one, you might be replacing human interaction rather than amplifying it.

What if we fail?

Let's be honest. Everything we've just discussed is easier to write than to implement. In the day-to-day life of an organization, here's what can happen, even with the best intentions:

- You interview 3 beneficiaries, but they are the 3 most available and comfortable ones. You completely miss the voice of the 80% who didn't respond to your invitation. This is a classic bias, and it has no easy solution.

- You identify the real need, but you have neither the budget nor the technical team to build the right solution. You end up doing what you could afford, not what truly met the need.

- You co-design with your beneficiaries, and they propose unrealistic or contradictory things. And then, you don't know what to do with them.

No method completely protects you from these pitfalls. They are part of the reality of any project that faces real-world challenges. The only thing that truly helps is to start small, test quickly, and accept that you'll make corrections along the way. A successful AI project isn't one where you didn't make mistakes. It's one where you made mistakes on things you were able to correct.

And sometimes, the best decision after this reflection is to not launch your AI project. Not right away, not like that, or not at all. For many organizations, the priority isn't to "get into AI" but to consolidate what they're already doing. That's also a valid response.

Key takeaways

Nicole's five points all stem from the same observation: AI amplifies what you do; it doesn't decide what you should do. It's up to you to define the real need, calibrate the effort, involve beneficiaries, anchor your choices in your values, and decide where human involvement remains irreplaceable.

At Share it, we support many organizations on these topics. What we most often observe are organizations that know all this but apply it in an accelerated mode. Organizations know they need to survey their beneficiaries, they know they need to pay attention to the quality of the relationship, they know that values should guide choices. The problem is that with two employees, three thousand beneficiaries, and funding that ends in six months, steps are skipped. This is understandable. But it's almost always where projects fail.

The true measure of an AI project isn't what the tool does. It's what it enables your beneficiaries to do, to learn, to become. The economist Amartya Sen called this thecapabilities approach : what matters isn't what people have access to, but what they are truly capable of doing with it.

No tool asks these questions for you. It's rewarding, and it's also work. The good news is that this kind of work, you know how to do. You already do it with your beneficiaries every day, outside of any AI.

Want to watch Nicole Marion Trigodet's full conference? Click here.

Nicole Marion Trigodet's conference took place during the launch event of forwa, the first European program supporting 15 associations fighting against inequalities in access to education and employment through AI.

From our sources

Here are some starting points to explore the concepts mentioned in the article:

- Jobs to be Done : Clayton Christensen, Bob Moesta, Competing Against Luck (2016)

- Counter-productivity of Tools : Ivan Illich, Tools for Conviviality (1973)

- Capabilities Approach : Amartya Sen, Development as Freedom (1999)

- Desirable Difficulties : Robert A. Bjork, "Memory and Metamemory Considerations in the Training of Human Beings" (1994)

- Zone of Proximal Development : Lev Vygotsky, Mind in Society (1978)

- Banking Model of Education : Paulo Freire, Pedagogy of the Oppressed (1968)

- Design and Encoded Values : Donald Norman, The Design of Everyday Things (1988)

- Study on AI and Cognitive Reliance : Bastani et al. (CMU, Oxford, MIT, UCLA), arxiv.org/abs/2604.04721(2025)

- For an SSE Approach to AI : Latitudes, Let's promote generative AIs that empower us, not give us power