CPINSIncident app for bomb squads
Bomb squads needed one place to report a suspect package, alert the squads around it and see it through to resolution. I led the design of CPINS, the app technicians use on scene, and of the admin portal we proposed to keep the network closed to outsiders.
The client needed squads to log suspect packages in a structured way, pull in nearby squads and record how each one ended. The information is sensitive, so the system had to stay closed to the public.
Proposed the design process with the team and got it agreed. Researched the context, defined roles and permissions, worked through every flow on the whiteboard with the team and developers, then designed both products: structure, flows, screens and guidelines.
A mobile app with eight core features for technicians and non-technicians, an admin web portal for accounts and squads, and visual guidelines for both.
A suspect package could be a bomb.
Until it is cleared, every detail about it matters: where it is, what it looks like, who has seen it and what has been done. CPINS moves those details to the squads that need them, quickly, and to nobody else.
The brief arrived as four jobs. Background research on how bomb squads work added the constraints that shaped every screen after it.
Each job became one or more features. The links jump to where it landed in the app.
Capture the details of a suspect package
Answered byCreate incidentIncident detailLet other squads help resolve it
Answered byCommentsTake actionFind other unattended packages nearby
Answered byMap viewSee only the locations you care about
Answered bySubscriptionsFiltersAn incident moves through five moments and three statuses. The status is the one thing every squad has to read correctly, so it travels with the incident everywhere it appears.
A technician on scene logs the package. Location comes from the map, the details are taps, and up to three photos go with it.
Technician on sceneSquads subscribed to that squad or area get a notification on their phones.
Subscribed squadsOther technicians open it, read the details and comment. If the photos aren't clear, they ask for more.
Nearby techniciansIf it can't be closed yet, it is marked pending, so nobody assumes it is over.
Any technicianWhoever acts records the outcome: a real device and what was done, or no device, a hoax or a false alarm.
Acting technicianWe researched how bomb squads operate and what is sensitive about their work. Five findings became rules for the design.
Nobody joins the network on their own. People register, and an admin approves or rejects every request.
What you can do follows your role. Non-technicians can follow incidents but can't add or remove them.
Reports use predefined options and carry a timestamp and a status. Every change notifies the squads that follow the incident.
One decision per screen, large tap targets, and follow-up options that appear only after you choose.
A separate admin portal takes account work out of the database and out of the field app.
No process had been defined for the project, so we drafted one and convinced the authorities it suited the work before a single screen was drawn.
What the client asked for, who would use it and what could go wrong.
What the client asked for, who would use it and what could go wrong.
Background research on how bomb squads work and what is sensitive about it.
Can send us back to problem understandingWhiteboard sessions with the team, then with developers to check feasibility.
Can send us back to research or to the problemInformation architecture, flows, screens and the visual guidelines.
Reviewing the designs against the brief.
Anything that fails goes back to the startHanding the designs to the developers building the app.
Design support while the product was being built.
As lead designer I carried the work through every stage, from research to the guidelines the developers built from. Select a stage to see what happened in it.
The data is sensitive, so the first thing we pinned down was who can see and do what. Both products are structured around those three roles.
Select a role to see its permissions. A dash means that role works in the other product.
Columns: technician, non-technician, admin.
The app is built around a feed of incidents. The portal is built around people and requests.
Hover a screen to trace its path from sign-in.Tap a screen to trace its path from sign-in. Swipe the map sideways to see all of it.
We sketched every flow on a whiteboard with the team, then walked it through with the developers, so feasibility came up while ideas were still cheap to change. The notes in the margins are where the decisions happened.
Select a numbered note. Hover the photo to magnify the handwriting.
I sketched these flows with the team and kept the open questions in the margins, then turned each answer into a change in the screens that follow.
The visual language is small on purpose: one action colour, three status colours, two typefaces and a set of icons that fill in when they are active.
From the original guidelines
Contrast is measured against white. Status colours always sit next to a text label, never alone.
Two families
Reused on every screen
Scroll through the core features. The phone is a live rebuild of the original screens, re-moulded for iPhone 16 Plus, so you can tap through it at any point.
Every incident in the squads and areas you follow, newest first. Each card leads with photos and a status, so a technician can size up an incident before opening it.
In the field, a picture of the package answers more than a paragraph about it.
Location comes from the map and the time from the clock. Everything else is a tap: package type, function, how it was identified, how it is employed and its status, plus up to three photos.
Tiles are faster than typing, and they make every report read the same way. Rare fields wait under Add more details.
Status, type, time, squad, the reporting technician and a number to call with one tap. Comments and photos sit below the details.
Take action is pinned to the bottom of every incident, in the same place each time.
Three actions: resolve the incident, ask for more information or resend the alert. Pick one, and only the options that follow from it appear.
Under pressure, a long form invites mistakes. Showing one decision at a time keeps every path to three taps or fewer before Proceed.
Nine scenarios, one screen. Pick one and watch the path.
Every comment on an incident lives in one thread, so whoever opens it later gets the whole story without asking around.
Context that lives in side channels gets lost between squads and shifts.
Nearby incidents appear as pins coloured by status. The nearest one's card is already open when the map loads.
On the map, the first question is what is closest. The card answers it before anyone taps.
Filter by device type, status, region, area or squad. A specialist can narrow the feed to the incidents that match what they know best.
Filtering by device type means the right technician can offer help, not just the nearest one.
Technicians choose which squads, areas and regions they hear from. New users pick these straight after registering, so their first feed is already relevant.
A few alerts that matter beat many that don't. Fewer interruptions leave room for the ones that count.
Updates on incidents you follow or reported, grouped as New, Today, Yesterday and Older. Actions you take in this prototype show up here too.
Returning to the app, the only question is what is new. The grouping answers it in one glance.
Live prototype. Tap anything on the screen.
At the start, a database programmer added every account by hand. That made the squads depend on someone outside them, and squad members couldn't be trusted to add or remove each other. We proposed a separate web portal for admins.
Every account used to be added by hand by someone outside the squads.
Members can't add or delete other members, which protects trust and privacy.
A web interface makes squad management straightforward and needs little outside support.
Admin work happens in the background, so people in the field never have to deal with it.
Create technician and non-technician accounts
Assign squads and approve squad changes
Add, remove and manage admins
Users, Add new user. Drag across to compare. The final portal runs dark, with the app's action blue kept for the one button that matters.
Drag the handle or use the arrow keys.Drag the handle.
The app went into development with its guidelines, and the admin portal we proposed was designed through to final screens. The brief asked for something simple enough to use in a crisis, and that one requirement settled most of our arguments.
Predefined options made reports quick to file and consistent to read, whichever squad filed them.
It kept the app about incidents and solved the trust problem at the same time.
Our reviews happened at desks. Today I would watch technicians run the core flows in a timed exercise, in their gear.
Basements and cordoned buildings drop connections. Reports should save on the device and send when the signal returns.
The grey supporting text in the cards is under 3:1 against its background, and the resolved teal #4DDDC7 is 1.68:1 on white. Status always carries a text label, but I would darken both.
Time from first sighting to the first alert is the number this product exists to shrink. I would baseline it with the client before design starts.
Thanks for reading.