Jobs not to be done: how charities can design safer AI

Many digital teams are familiar with the idea of jobs to be done. This framework helps us focus on the specific tasks a user wants to achieve when they visit a website or use a service.

As Alice explains, Using ‘problems to solve’, rather than requirements gathering offers a guiding light that helps create product focus, clarity on how to prioritise and a more collaborative approach to your project. You can read more in her article here

But when we design digital services, we also need to think about jobs not to be done. These are the harmful tasks or malicious goals that we must actively prevent people from achieving.

Focusing on jobs not to be done helps teams spot vulnerabilities before they are built into the final product. It forces us to think critically about how well-meaning design can be exploited.

Defining jobs not to be done for your charity

In a charity context, planning for the worst is a vital part of safeguarding and cyber security. For example, if you are designing an online community, you have a duty to ensure it remains a safe environment.

You must define the possible harmful jobs that bad actors might try to complete. For example, a clear job not to be done might be using a domestic abuse survivor’s forum search tools to stalk an ex-partner.

Another critical job not to be done could be tracking or identifying victims of child abuse through shared user stories.

When we map out these potentially harmful actions, we can build better safeguards. This process helps charity leaders identify where they need stronger moderation or better data security.

How AI creates new jobs not to be done

Artificial intelligence introduces new capabilities for malicious actors. This means charities face entirely new risks that require careful planning.

AI lowers the barrier to entry for building new digital tools, products and services - which is something worth valuing. But this democratisation also makes it easier to cause harm at scale.

When integrating AI into your services, you must map out the specific jobs you want to block the technology from doing.

Case study 1: Preventing AI image manipulation

A youth charity wants to build a digital platform for young people to share their creative writing and artwork. To make the space feel welcoming, they plan to let users upload profile pictures and share personal photos.

The job not to be done here is clear. The charity must not allow predators to easily download images of young people.

In the past, the main risk was someone saving a photo and sharing it elsewhere. But artificial intelligence changes the scale and nature of this threat. Bad actors can now use generative AI tools to take an innocent profile picture and manipulate it into something abusive or harmful in a matter of seconds.

To stop this job from being done, the charity must think like a predator during the design phase. They might decide that the risk of allowing photo uploads is simply too high.

Instead of real photos, they could offer a set of pre-designed avatars. They could also use software to block automated systems from scraping the website for data.

By removing the source material entirely, the charity protects its young audience from a deeply damaging form of digital harm. This shows how designing for the worst case could completely change the features you choose to build.

Case study 2: Stopping automated harassment

A charity supporting survivors of domestic abuse is designing an anonymous peer-support forum. The goal is to help people connect and share advice. The team considers adding a private messaging feature so users can offer each other direct support.

The job not to be done is allowing abusers to track down or harass their victims.

Abusers often try to overwhelm their victims with messages. AI makes this easier and much more dangerous. A perpetrator could use a large language model (LLM) to generate hundreds of unique, emotionally manipulative messages.

Because the messages are generated by AI, they do not read like traditional spam. They easily bypass standard security filters and flood the survivor’s inbox.

To prevent this harmful job, the digital team must design intentional friction into the service. They might decide not to build a private messaging feature at all. If they do build it, they need strict safeguards.

They could limit the number of messages a new account can send each day. They could also use human moderators to review accounts that send messages too quickly. By anticipating how AI can be weaponised, the charity ensures their platform remains a genuine safe space.

Chayn, a global non-profit supporting survivors of gender-based violence shared why they decided to take down their chatbot:

Case study 3: Blocking AI-powered phishing

A health charity manages an online network for people living with a rare medical condition. Users regularly share detailed stories about their treatment, their daily struggles and their locations. This openness helps people feel less alone.

The job not to be done is allowing scammers to harvest this vulnerable information to steal money or data.

Scammers have always targeted vulnerable groups. But AI tools now allow them to do this at a massive scale. A bad actor can use AI to quickly read thousands of public forum posts and extract personal details.

The AI can then write highly convincing, personalised phishing emails. These messages might pretend to offer a miracle cure or ask for a donation to a fake treatment fund.

Because the AI uses real details shared by the user, the scam is incredibly hard to spot. To block this job, the charity needs to change how data is stored and viewed.

The team could hide forum posts behind a secure login, meaning public search engines and bots cannot read them. They could also provide clear guidance to users about what personal details to leave out of their stories. Protecting this data cuts off the fuel that AI needs to generate these convincing scams.

Practical tips for mapping jobs not to be done

To put this into practice, your team needs to adjust how you run research and design sessions. You need to create space to think like a bad actor.

When planning a new feature, start by asking what the worst possible outcome could be. Think about how someone could use this exact feature to cause distress or steal data.

Next, define the specific job not to be done. Write it down clearly, just as you would a normal user need, so the whole team understands the threat you are trying to block.

Finally, design the friction needed to stop that job. This might mean removing a feature entirely, adding human moderation, or limiting how much data users can share.

Our approach to digital design is guided by inclusion and care for people. If we want new tools to genuinely help, we must design our processes to centre and protect vulnerable groups.