Tech & society
Africa in beta mode
We're good at launching platforms. The difficult part sometimes begins after the ceremony.
Tech & society
We're good at launching platforms. The difficult part sometimes begins after the ceremony.
It's a familiar scene in the technology world.
A conference room.
Invited guests.
A giant screen.
A demonstration.
A few photographs, followed by an announcement: a new digital service has launched.
On paper, it sounds promising.
And then, one day, someone actually tries to use it.
The form won't submit.
The confirmation code never arrives.
Support doesn't answer.
Or they still have to show up in person with a folder full of paperwork.
The platform has launched. The service, not quite.
I'm not saying every African digital project fails.
That would be untrue, and unfair to the people building useful services, often with limited resources.
But I worry about a habit: treating the moment a website goes live as the end of the project.
In my line of work, deployment isn't the finish line.
It's when the application finally meets real life.
Unreliable connections.
Older phones.
Users unfamiliar with our terminology.
Employees with established ways of working.
Situations nobody thought about during the demo.
People don't adopt software merely because it exists.
Imagine a government procedure that has gone digital.
Previously, you filled in a form at a desk.
Now you fill it in on a website.
But if the documents required are unchanged, if tracking is impossible and if you still have to travel to ask where your request stands, what have we really transformed?
We've moved the form.
That isn't worthless. Downloading a form can already save someone a trip.
But it isn't the same as redesigning a service from beginning to end.
Digital transformation should mean more than placing a screen between someone and a procedure.
It should also give us permission to ask: why is this procedure so complicated in the first place?
A platform still needs a team once it launches.
People who answer questions.
Fix defects.
Update information.
Monitor performance.
Explain changes.
And have a budget to keep doing it.
None of that looks particularly exciting in a launch photograph.
Yet that's where much of the trust is built.
When a service stops working, users rarely care which programming language was used.
They want to know whether they can rely on it tomorrow.
I wrote about that quieter work in The invisible developer.
It's easy to copy interfaces created for places with reliable internet, widespread card payments and fully digital procedures.
Then discover that local usage follows different patterns.
In Senegal, a service may need to work on a modest phone, with a limited data plan, a different way to pay or a user who wants help the first time around.
Those aren't flaws in the users.
They're realities the product must account for.
I explored that gap in Not everyone has fibre.
A good digital service shouldn't require an entire population to adopt the designer's habits.
There's something interesting about the phrase beta version.
In software, it means a product is still being tested, can evolve and needs feedback.
Big public launches often prefer to present a solution as finished from day one.
But admitting that a service needs improvement isn't necessarily a failure.
It may mean the team has started listening.
We should be able to say: this step takes too long; we're simplifying it.
Nobody uses this feature; we're removing it.
This journey excludes some people; we're redesigning it.
Trust doesn't come from promising a perfect system.
It grows when people see us fixing what isn't working.
I believe digital tools can improve services, businesses and access to information.
Otherwise, I wouldn't be working in this field.
But I believe less and less in transformations that amount to a new interface.
Real progress isn't measured by the number of platforms inaugurated.
It's measured by the number of problems that actually become easier to solve.
And preferably stay easier long after the cameras leave.