Safeguard alarmeert, verbindt en volgt de BHV'ers van een bedrijf als er iets misgaat. Het platform was sneller gegroeid dan de interface. In drie maanden deden we het onderzoek, bouwden we een design system in Figma en code, ontwierpen we dashboard en app opnieuw en droegen we een iOS-app over om zo realistisch mogelijk te kunnen testen.
De uitdaging
Safeguard maakt het platform waarmee Nederlandse en Belgische bedrijven hun bedrijfshulpverlening organiseren: een app die de BHV'ers op locatie alarmeert, een dashboard voor de coördinator, push-to-talk om tijdens een incident te blijven praten, en knoppen, QR-codes en brandmeldkoppelingen om alarm te slaan. Het wordt gebruikt in kantoren, fabrieken en verzorgingshuizen, op het moment dat er iets misgaat.
Het bedrijf werd volwassen: van een groep vrienden die een product bouwt naar een team van tweeëntwintig met ambities in Duitsland en in de zorg. Het product was niet meegegroeid. De look was gedateerd en functies waarin maanden werk zat werden door klanten niet opgemerkt.
Safeguard vroeg ons om onderzoek en het fundament: een design system waar het team op kan bouwen, en de belangrijkste flows opnieuw ontworpen.
We begonnen met een ochtend in Breda met de oprichters en de product lead, om de productvisie in kaart te brengen: voor wie Safeguard is, wat die nodig heeft in de eerste minuut van een incident en waar het bedrijf over vijf jaar wil staan. Diezelfde ochtend haalden we bij sales en customer support alles op wat zij over de eindgebruiker weten, zodat onze interviewvragen ergens op konden voortbouwen.
Daarna interviewden we vijf BHV-coördinatoren, de helft op locatie: een fabriek met ploegendiensten, een luchthaven, een kantoorgebouw met meerdere huurders, een zorgorganisatie, een gemeente. Elk gesprek duurde een uur, één op één, over wat er in de praktijk gebeurt als iemand in elkaar zakt of rook wordt gezien. De patronen legden we naast Safeguards eigen klanttevredenheidsonderzoek, om te zien welke signalen structureel waren en welke eenmalig.
De nuttigste bevinding was ongemakkelijk: het product is ontworpen rond een medewerker die een incident in de app meldt, maar in de praktijk bellen mensen de receptie of roepen ze. Waar coördinatoren het meest over piekeren, is of de aanwezigheid die het dashboard toont klopt.
De developers van Safeguard hadden al een componentenbibliotheek en Tailwind-stijlen, en hun eigen woorden ervoor waren "te flexibel". Dus bouwden we het design system vanaf het fundament op: kleuren, typografie en iconen, dan de componenten, dan de paginasjablonen die vastleggen waar dingen staan. De stijl is zwart-wit met rood alleen waar het iets betekent, gevulde iconen die de ronding van het logo volgen, licht afgeronde hoeken en schaduwen op kaarten maar nooit op knoppen, omdat een noodtool plat en zeker moet voelen.
Het systeem leeft bewust op twee plekken: in Figma, zodat designers erin ontwerpen, en in code, als componentenbibliotheek met Storybook als de ene bron van waarheid voor hoe een component eruitziet en zich gedraagt. We schreven een werkwijze die een designer van een schone laptop naar een gemergede pull request brengt, zodat het team er vanaf dag één in kon werken.
Hoe het systeem stroomt: het Figma design system voedt zowel de Figma-designbestanden als de Storybook in code, en het prototype wordt uit Storybook gebouwd.
Het dashboard van de coördinator
Incidenten, actief bovenaan
Wat nu speelt staat bovenaan, met wie erop zit en een ingang. Wat voorbij is wordt een rij om te evalueren, zodat rapporteren geen losse klus meer is.
De app is wat een BHV'er vasthoudt als de adrenaline komt, in een gang die net luid is geworden. Dus elke flow is voor die toestand ontworpen. Het homescherm beantwoordt eerst één vraag (ben je oproepbaar?) en zet noodnummer, oproep en kanalen binnen duimbereik. Een oproep doen is een scenario kiezen en gaan.
Een binnenkomende oproep vult het scherm en vraagt één antwoord. Een actief incident leeft in een vaste kaart boven de navigatie, zodat je altijd verbonden blijft met het incident en het push-to-talk-kanaal.
We bouwden het prototype in code in plaats van in Figma: elke toestand is een instelling in de URL, zodat een stakeholder een link kon openen en precies de situatie zag die we bedoelden.
- De rustige dag draait om zekerheid: laten zien dat je oproepbaar bent, dat je instellingen kloppen zodat er geen schijnaanwezigheid ontstaat en welke acties er nog voor je openstaan.
- Melden begint bij één vraag: wat is er aan de hand? Je kiest het scenario dat past, en de juiste mensen worden opgeroepen.
- Een binnenkomende oproep haalt alle ruis weg, zodat je je volledig op het noodgeval richt: wat, waar en één keuze: kom je of niet?
- Het incidentscherm zelf: wie er komt, de checklist en push-to-talk. Het is bewust groter ontworpen, voor de momenten dat je telefoon verder weg ligt.
- Een lopend incident blijft als vaste kaart boven de navigatie: waar je ook in de app bent, je bent er met één tik bij en je push-to-talk zit onder je duim.
Een prototype in een browser overtuigt een directiekamer. Het vertelt je niet of een BHV'er de oproepknop vindt met een natte duim op de trap. Dus porteerden we het prototype naar een native SwiftUI-app: geen externe afhankelijkheden, dezelfde schermen en dezelfde scenario's. De kleuren en de scenariodata worden gegenereerd uit de bron van het webprototype, zodat de twee niet uit elkaar kunnen lopen.
We droegen alles over: zes Figma-bestanden, twee repositories, de Storybook, de werkwijze en het iOS-project, klaar voor het team om eigen builds te publiceren. Het design system groeit nu mee met de volgende cycles van het team, een alleenwerkermodule en de academy, met ons een berichtje verderop.
Vanaf dag één was de opdracht een fundament waar het team zonder ons op door kan bouwen. De maat ervoor is wat ze na ons vertrek uitbrachten.
De impact
Safeguard kreeg waar het om vroeg: onderzoek dat het kan citeren, een design system in Figma en code dat een designer en een developer hetzelfde lezen en de belangrijkste flows van dashboard en app opnieuw ontworpen en bewezen op echte apparaten.
Het team bouwt er nu op door. De cijfers hieronder zijn van ons, de cijfers waar we zonder te vragen achter kunnen staan; de resultaten in het product zijn aan hen om te delen.
5
Interviews
Coördinatoren uit vijf sectoren, naast het klanttevredenheidsonderzoek gelegd om patronen van eenmalige signalen te scheiden.
40 dagen
Van onderzoek naar fundament
We begonnen met onderzoek en productcontext en werkten toe naar een design system waar het team op verder bouwt.
12
Core flows
De BHV-app en het dashboard van de coördinator, van alarmeren en aanwezigheid tot het actieve incident, opnieuw ontworpen als één systeem.