Numérisk, designing an emergency alert tool that is simple to use in a crisis

Numérisk develops crisis management software for French local authorities.

Public tenders regularly asked for an emergency alert module, which the software did not offer yet.

Adding it would let Numérisk answer more tenders and win market share.

It would also limit disruptions during crisis management.

The initial brief was to offer a solution simpler than the ones already on the market.

During scoping, though, the team wanted a very complete module, and found it hard to prioritize.

The problem statement: How might we make sending alert campaigns to residents simpler and more reliable?

To design a relevant alternative, I had to understand the difficulties people met with existing tools and the practices of the people in charge of alerting residents.

From scoping to interviews

1. 01Workshop with the stakeholders: 1 hour with Numérisk's co-founder and CTO, to set out the main lines of the project and what Numérisk expected from the module.
2. 02Workshop with the domain experts: 1 hour with 2 domain experts who support local authorities. We listed the features regularly requested in public tenders, which set what I would compare during the benchmark.
3. 03Benchmark of 2 solutions: The 2 main players, the most used by local authorities, identified thanks to the Numérisk team's knowledge of the market. Analyzing them helped me write the hypotheses to check in interviews.
4. 044 interviews: With municipal staff and elected officials from 4 local authorities, to check these hypotheses in the field.

The benchmark grid

The criteria follow the features requested in public tenders, listed with the domain experts, for example:

• sending by SMS, voice message or email;
• targeting by geographic area;
• message templates;
• test before sending;
• cost shown before sending.

The results stay confidential, but the blank grid is free to download (page in French).

2 hypotheses to check in the field

1. H1

   A tool used once or twice a year must be usable without relearning it, even in a crisis.

   Signal to watch for: Users, even those familiar with the platform, hesitate, make mistakes, or work around the tool by calling or texting by hand.

2. H2

   Uncertainty about the content of an alert and whether it went out can hold back sending it.

   Signal to watch for: The officer rereads the message several times before sending, tries to check what residents will receive, or makes sure the alert was actually sent.

Users who are hard to reach

Municipal staff and elected officials are in constant demand.

Recruiting took 5 reminders per participant on average.

To make the conversations easier, I used technical meetings already planned with Numérisk, keeping their last 30 minutes for the interviews.

This way, I met 4 people from 4 local authorities, all of whom had already taken part in sending a real alert.

The sample is small, but the conversations revealed several difficulties to take into account in the design.

Difficulty 1 Directories kept up to date separately

Competing alert tools require a separate contact directory, apart from the data already entered in the municipal emergency plan (Plan communal de sauvegarde, PCS).

The PCS is the document that organizes the town's response to a crisis, under the mayor's authority.

Among other things, it contains the crisis directory, the list of people to reach during a crisis: elected officials, municipal staff, emergency services, gendarmerie, utility operators.

For local authorities, this second directory means extra maintenance work: the same information has to be kept up to date in several places.

Yet Numérisk already holds this data in its software.

The opportunity: Use the PCS data to feed the alert directory directly.

Difficulty 2 Too many options for occasional use

The solutions studied offer many settings and advanced features.

These options can serve expert users, but they complicate the main tasks for municipal staff and elected officials who are not IT specialists.

Some use an alert tool only once or twice a year.

The challenge was to make the main functions available right away: write a message, select its recipients and send it.

The opportunity: Make the tool usable without relearning, even after months without opening it.

Difficulty 3 Apprehension when triggering the alert

During the interviews, 3 participants out of 4 said they reread their message several times before sending it.

Beyond handling mistakes, they wondered how the message would be received and understood by residents.

This apprehension weighed all the more because an alert can reach a large part of the population.

The opportunity: Let users receive a test message themselves before triggering the campaign.

Difficulty 4 Costs that are hard to predict

Competing solutions also lacked transparency on the credits used.

Local authorities had to work out the cost of their campaigns themselves, sometimes with unpleasant surprises on the quarterly invoice.

The opportunity: Show the remaining credits and the number of credits needed before a campaign is launched.

I tested a first prototype with 3 participants, then iterated on a single point: the number of steps.

A first prototype with as few steps as possible

These actions fit on the same page:

• selecting the recipients;
• writing the message;
• the sending settings.

It already included all the features of the final version.

One screen for each phase of the alert

After testing, the second prototype gave one screen to each phase of the alert, in 5 steps.

1. 01Creating the campaign: Campaign name and type of send: SMS or voice message.
2. 02Choosing the recipients: Directory or mailing list, with the option to add recipients by hand.
3. 03Writing the message: With the option to start from a template.
4. 04Summary and test: All the campaign information, with the option to test before sending.
5. 05Results: Send status and tracking of replies.

Participants read the current step without scrolling the page, then moved on to the next one.

The decision: Favor one screen per phase over a flow cut down to as few steps as possible, which forced users to scroll.

What I learned from the benchmark, the interviews and the tests guided the design of the module.

Choice 1 Reuse the contacts from the PCS

The alert directory relies on the data already entered in the Numérisk software.

Local authorities no longer have to maintain 2 separate contact databases.

Choice 2 Focus on the main functions

The interface gives priority to preparing the message, choosing the recipients and sending.

The idea was close to a remote control: give users direct access to the functions they use, without having to master many expert options.

Choice 3 Check the message before it goes out

A test send lets the officer receive the SMS or voice message just as residents would.

They can check the content and how it looks before launching the campaign.

Neither of the 2 competing solutions studied offered this test.

Yet an alert can go out to more than 500 numbers, and many more depending on the size of the town.

Checking that everything is right before sending is reassuring.

This feature responds directly to the apprehension expressed in the interviews.

Choice 4 Show the credits before sending

The number of remaining credits and the number of credits the campaign needs are visible before confirmation.

Local authorities can plan their usage without doing the math themselves.