Nigeria’s AI landscape is defined by ‘building for constraints’. Unlike Silicon Valley, Nigerian innovators design human-centred tools optimised for basic devices and unstable connectivity. Focusing on ‘amplification over replacement’, Digital Product Designer, Cindy Shontan, spoke with ADEYEMI ADEPETUN about her five years of experience in Lagos creating AI tools that empower teachers and simplify government portals.

Can you compare AI use in Nigeria and other regions?
Nigeria is moving faster than most people outside the ecosystem realise. The talent and the problems worth solving with AI are here and the appetite from founders and product teams to integrate.
  
AI is genuine. But what is still catching up is infrastructure (reliable connectivity, affordable devices, the kind of digital foundations that make AI products work seamlessly for the average user).
  
However, what I find most interesting about AI in Nigeria specifically is that the constraints force a different kind of creativity. The truth is, you cannot build AI products the way Silicon Valley builds them when your user has a basic Android phone and intermittent to shaky Internet. That constraint produces more thoughtful, more human-centred AI design, which I think is actually a competitive advantage over time.

Should the labour market expect more job losses as a result of AI deployment?
From my direct experience designing AI features for Nigerian teachers and school administrators, I saw something more nuanced than job replacement. Teachers who adopted the AI lesson planning tool did not become redundant; in fact, they became more effective.
  
The time they previously spent writing curriculum content for weeks was freed up to actually teach, to give individual attention to students, to do the parts of their job that AI genuinely cannot do.
  
The honest answer is that some roles will change significantly and some jobs that exist today will not exist in the same form in 10 years. But in education specifically, in the African context I worked in, the more immediate reality I observed was that AI gave under-resourced teachers capabilities they had never had before. That to me feels more like amplification than replacement.
  
So, the more important conversation is about who gets access to AI tools and who gets left behind. That access gap is a much bigger risk than job displacement in the African context.

How can AI features be designed to provide personalised insights while maintaining user trust?
The principle I followed consistently was progressive disclosure, which is simply giving users just enough information at each step without overwhelming them with everything the AI knows at once.
    
For the parent formative assessment feature specifically, the challenge was translating.

AI-generated academic insights into language that a parent without a university education could act on. The AI could identify that a child was struggling with fractions in mathematics. But telling a parent ‘your child demonstrates weakness in fractional arithmetic, “ is useless. Telling them ‘here are three things you can do this week to help your child understand fractions better’ is actionable.
   
Now, on the scepticism question, I built in transparency wherever possible. The AI never presented its insights as definitive facts. The interface communicated clearly that these were suggestions based on performance patterns, and not verdicts. It’s important to be open about the AI’s limitations, because it’s that openness that made users trust it more.

For the lesson planning tool, I made every AI-generated output fully editable.   
  
Teachers could modify, reject or completely rewrite anything the AI produced. That editability was the single most important trust-building design decision I made, and this kept the teacher in control of their professional expertise.

Explain how real-world teacher interactions with AI lesson and exam tools differ most from your initial research expectations?
The most surprising thing was how quickly the sceptics became the advocates. My research before designing these features surfaced significant resistance, from cultural concerns, fears about accuracy, and some teachers who felt that AI-generated lesson content was somehow cheating or taking a shortcut. I designed specifically around this resistance by making the manual method available alongside the AI option.
   
What I did not fully anticipate was how fast the experience of using the tool would convert resistant users. The experience itself was the most persuasive argument I could not have designed into the interface. There was a time when a teacher saw a week’s worth of lesson notes generated in five minutes, notes that they could edit and make their own, and that experience dissolved most of the concerns about AI.
  
The other surprise was how teachers personalised the AI output. I expected them to use the generated content directly or reject it entirely. Instead, they developed a hybrid approach. So, what they did was that they used the AI as a first draft, then shaped it with their own knowledge of their specific students and class context. That hybrid use pattern was not something I had designed explicitly, but it turned out to be the most sustainable adoption model.

How did you design the AI to ensure its insights were ethically supportive and constructive rather than biased or reductive?
This was something I thought about carefully, particularly for the parent formative assessment feature, because it was surfacing information about children’s academic performance directly to parents.
  
The first ethical principle I applied was that the AI should never label a child. No feature of the platform ever said ‘your child is weak at mathematics’ as a fixed characteristic. Every insight was framed around specific topics, specific recent performance and specific actionable next steps. The language was always forward-looking, such as “here is what you can do” and never “here is what your child cannot do”.
    
The second principle was balance. The feature surfaced areas for improvement, but always alongside areas of strength. A parent should never leave an interaction with the platform feeling only that their child is failing. The design had to hold both truths simultaneously.
    
The third was transparency about the AI’s basis for its insights. The AI was drawing on recent assessment performance data, not making psychological judgments about a child’s ability.
  
Making that basis clear to parents helped them understand what they were seeing and why, which reduced the risk of misinterpretation.
  
So, these were design decisions made in a startup environment with limited time and resources, not the product of an extensive ethics review process. But they reflected a genuine attempt to think through what harm could look like and design against it.

What advice for resource-constrained environments do you wish you’d known when starting?
Stakeholder communication is your most important design skill, more important than your Figma proficiency, more important than your visual sense, more important than your research methodology.
 
When you are the only designer in a room full of engineers, product managers and executives who do not think in user experience terms, you are constantly translating. You are translating user needs into language that resonates with business goals. You are translating design decisions into language that engineers can build from. You are translating feedback into decisions that move the product forward rather than sending you back to square one.
   
I spent my first year as a solo designer thinking my job was to produce great designs, and it took me another year to understand that my job was to bring the right people with me on the journey so that the great designs I produced actually got built the way I intended them. Nobody had told me that, and this is something I wish they had.

How did you design govt portals to ensure accessibility for administrators with varying levels of digital literacy?
The foundational strategy was progressive disclosure, and not showing users more than they needed to complete the immediate task. A ministry official approving a school’s ATO application does not need to see the entire school registration database simultaneously.

What they need to see is the documents submitted, and two buttons, whether approve or reject with a reason.

Everything else is secondary. The second strategy was familiar mental models. Many of these administrators had never used a web portal but they had used paper forms. I designed the digital flows to mirror the logical sequence of the paper process they already understood and not to reimagine the process from scratch. They were already comfortable with the logic, so that stayed the same.

The third was security signalling. These portals were processing official government approvals and school fee payments. Users needed to feel and not just be told that the system was secure so every payment confirmation, submission receipt, status update was designed to communicate that an official action had taken place and was recorded. That paper trail feeling even in a digital environment was critical for users who had spent their careers working with physical documents.

The fourth was shipping with the minimum viable complexity. Government deadlines gave me no choice but to prioritise ruthlessly. So features that were nice to have but not essential to the core government service were deferred.

What was the biggest psychological or UX hurdle in convincing traditionally manual users to trust a digital-first subscription model?
The biggest hurdle was not the technology; it was the perceived irreversibility of digital decisions.

Manual users are comfortable with paper processes partly because mistakes are visible and correctable. You can see a paper form, you can cross something out, you can even ask someone to look at it with you. But digital processes feel more permanent and opaque to users, who are not comfortable with them. For example, a school administrator selecting a subscription plan on a screen and entering payment details felt like they could not undo or verify that commitment they were making.

I addressed this by coming up with a confirmation architecture, by making every significant action visible, reversible or explainable at every step before it became final. So before any payment was processed, the user saw a clear summary (Subscription summary) of exactly what they were paying for, how much, and what they would receive.

After payment they received a detailed receipt with every line item confirmed. The wallet system I also designed showed that schools could credit their wallet before committing to a specific plan, and that gave users a way to engage with the digital financial system without immediately committing to an irreversible transaction.

The second hurdle I faced was trust in the payment infrastructure itself. Nigerian users, particularly institutions managing school funds are really cautious about online payments.

So, integrating with Flutterwave helped because these are names of schools already associated with legitimate financial transactions. Design cannot build trust that the underlying infrastructure has not earned. But it can make the trust that exists more legible to the user, and that is what I focused on.