Gemeente-apps: de volledige gids

Een gemeente-app bundelt een aantal diensten die inwoners vaak nodig hebben in een vorm die op een telefoon werkt. In de praktijk gaat het bijna altijd om dezelfde kern: een melding doen over de openbare ruimte, weten wanneer welk afval wordt opgehaald, iets aanvragen of doorgeven, en informatie vinden over de eigen buurt.

Wat een gemeente-app onderscheidt van commerciële apps is het publiek. Een winkel mag zich richten op de klanten die haar app kunnen bedienen. Een gemeente heeft dat recht niet: haar inwoners zijn iedereen, inclusief mensen die laaggeletterd zijn, slecht zien, geen recente telefoon hebben of helemaal geen smartphone. Dat is geen randvoorwaarde maar het uitgangspunt van het hele ontwerp.

Daaruit volgt een tweede uitgangspunt: de app mag nooit de enige weg naar een dienst zijn. Wie belt of langskomt, moet hetzelfde kunnen regelen. Een app die dat vergeet, verplaatst het probleem naar de balie, waar medewerkers moeten uitleggen dat iets alleen digitaal kan.

Er speelt bij gemeenten nog iets bijzonders: de app is een uithangbord. Inwoners leiden uit de kwaliteit van een app af hoe de organisatie erachter functioneert, ook al is dat oneerlijk. Een formulier dat halverwege vastloopt of een melding die nooit wordt beantwoord, kost meer vertrouwen dan een gemeente zonder app zou verliezen. Dat pleit voor terugh­oudendheid in wat u opneemt: liever drie taken die soepel verlopen dan tien die half werken. Het pleit ook voor het serieus nemen van beheer, want een app die niet wordt onderhouden gaat er na twee jaar uitzien als verwaarlozing.

Overheids­organisaties zijn verplicht hun websites en mobiele apps toegankelijk te maken voor mensen met een functi­ebeperking. De norm is WCAG op niveau A en AA. Daarbij hoort dat u per website en per app een toegan­kelijk­heidsv­erklaring publiceert waarin staat in hoeverre u aan de eisen voldoet.

Een toegan­kelijk­heidsv­erklaring is geen formulier dat u aan het eind invult. Het is een verslag van wat er is onderzocht en wat er nog niet voldoet, met een plan om dat te verbeteren. Dat betekent dat u tijdens de bouw moet toetsen in plaats van erna, en dat de bevindingen ergens moeten landen waar ze worden opgepakt.

Toegan­kelijkheid is bovendien breder dan de technische norm. Taalniveau is minstens zo bepalend: een formulier dat technisch perfect is maar in ambtelijke taal is geschreven, sluit een groot deel van uw inwoners uit. Dezelfde logica geldt voor het aantal stappen, het aantal velden en de vraag of iemand halverwege kan stoppen en later verdergaan.

De verleiding bij een gemeente-app is om alles te bundelen wat een gemeente doet. Dat levert een app op die door niemand wordt gebruikt, omdat de taken die inwoners werkelijk hebben verdwijnen in een menu met dertig ingangen. De beste gemeente-apps doen een handvol dingen goed.

De terugkoppeling op meldingen verdient de meeste aandacht. Inwoners die een melding doen en nooit meer iets horen, melden de volgende keer niet meer, of ze melden juist vaker omdat ze denken dat het niet is aangekomen. Beide zijn slecht. Een korte statusmelding is technisch eenvoudig en heeft een effect op vertrouwen dat groter is dan welke andere functie ook.

Achter een gemeente-app zit een organisatie met bestaande processen. Een melding die in de app binnenkomt, moet in het zaaksysteem terechtkomen en bij de juiste afdeling landen. Gebeurt dat niet, dan wordt de app een extra postbus die iemand met de hand moet leegmaken, en dat houdt niemand vol.

Een punt dat in gemeentelijke projecten vaak laat naar boven komt, is het verschil tussen wat een afdeling belangrijk vindt en waar inwoners voor komen. Elke afdeling heeft goede redenen om zichtbaar te zijn in de app, en het optellen van die wensen levert een menu op waarin de drie taken die er werkelijk toe doen verdwijnen. Het helpt om die keuze niet in een overleg te maken maar op basis van cijfers: waar wordt voor gebeld, wat wordt het vaakst gezocht op uw website, en waarvoor komen mensen naar de balie. Dat gesprek is korter en de uitkomst is verdedigbaar.

1. Kies de taken op basis van cijfersKijk waar inwoners nu voor bellen, mailen en langskomen. Die lijst bepaalt wat er in de app hoort, en niet wat afdelingen graag zichtbaar willen maken.
2. Volg de weg van een melding tot het eindBeschrijf wat er gebeurt vanaf het indienen tot de afhandeling, inclusief wie hem oppakt. Zonder dat is de app een voorkant zonder achterkant.
3. Ontwerp voor de moeilijkste gebruikerWie het formulier begrijpt zonder te kunnen zien, met weinig leeservaring en op een oude telefoon, kan het altijd. Andersom werkt het niet.
4. Toets tijdens de bouwToegan­kelijkheid controleren aan het einde levert een lijst op die niemand meer kan repareren binnen het budget. Toets bij elk onderdeel.
5. Regel de terugkoppelingZorg dat een indiener automatisch hoort wat er met zijn melding gebeurt. Dit is de functie met het grootste effect op vertrouwen.
6. Publiceer de verklaring en houd hem bijDe toegan­kelijk­heidsv­erklaring is geen eenmalige handeling. Bij elke wijziging aan de app hoort de vraag of hij nog klopt.

Reken erop dat een deel van de meldingen niet over uw gemeente gaat. Inwoners weten niet welke weg van de provincie is en welk water van het waterschap. Een app die zulke meldingen weigert, verliest de melder. Een app die ze aanneemt en doorstuurt, kost intern wat werk maar levert een inwoner op die de volgende keer weer meldt.

De koppelingen bepalen bij een gemeente-app of het geheel werkt. Bijna alles wat de app toont of aanneemt, komt uit een bestaand systeem, en de app is grotendeels een nieuwe voorkant op wat er al is.

Denk daarnaast na over meertaligheid en over eenvoudige taal als twee verschillende dingen. Vertalen naar het Engels helpt een deel van uw inwoners; teksten op een begrijpelijk niveau schrijven helpt een veel grotere groep, inclusief mensen die Nederlands als moedertaal hebben. Van de twee levert het tweede meestal meer op, en het is bovendien werk dat u zelf kunt doen zonder externe partij.

Let bij het ontwerp op wat er aan gegevens wordt vastgelegd. Een melding met een foto en een precieze locatie is al snel herleidbaar tot een persoon, zeker in een dunbevolkt gebied. Bepaal wat u nodig heeft om de melding af te handelen, hoe lang u dat bewaart en wat u van meldingen publiceert op een kaart. Anoniem melden mogelijk maken is meestal verstandig, ook al levert het soms een melding op waarop u niet kunt terugkomen.

Gemeente-apps mislukken zelden op techniek. Ze mislukken op te veel willen, op een achterkant die niet is meegenomen, en op toegan­kelijkheid die aan het einde wordt geregeld terwijl het budget op is.

Denk ook aan wat er gebeurt als de app niet werkt. Bij een storing in een commerciële app haakt een klant af; bij een gemeente moet een inwoner zijn zaak alsnog kunnen regelen. Dat betekent een zichtbare storingsmelding, een duidelijke verwijzing naar telefoon en balie, en interne afspraken over wie er wordt gebeld als het misgaat buiten kantoortijd.

• Kies weinig taken en doe ze goed. Kijk waar inwoners nu voor bellen. Drie taken die soepel werken, worden gebruikt; dertig ingangen worden dat niet.
• Neem de achterkant vanaf het begin mee. Een melding die in een aparte postbus belandt in plaats van in het zaaksysteem, wordt binnen een maand een handmatige klus die verwatert.
• Toets toegan­kelijkheid tijdens de bouw. Aan het eind toetsen levert een lijst op die niemand meer betaalt. Test bovendien met echte gebruikers, niet alleen met gereedschap.
• Regel de terugkoppeling op meldingen. Dit is de functie met het grootste effect op vertrouwen en technisch een van de eenvoudigste.
• Houd de app een van de kanalen. Balie en telefoon blijven bestaan. Een dienst die alleen via de app kan, sluit inwoners uit die u juist moet bedienen.
• Wees terughoudend met gegevens. Een melding met foto en locatie is snel herleidbaar. Bepaal vooraf wat u vastlegt, wat u toont en hoe lang u bewaart.

Bij een gemeente-app worden de kosten vooral bepaald door het aantal koppelingen en door het gevraagde toegan­kelijk­heidsniveau. Het aantal inwoners speelt vrijwel geen rol.

Houd er ten slotte rekening mee dat een gemeente-app na oplevering niet stil staat. Regels veranderen, besturings­systemen brengen jaarlijks nieuwe versies uit en toegan­kelijk­heidsnormen worden herzien. Een app die twee jaar niet wordt bijgewerkt, valt op enig moment uit de winkel of werkt niet meer op nieuwe toestellen. Reserveer daar structureel budget voor, want dit is geen incidenteel project maar een dienst die u onderhoudt.

Een aanzienlijke besparing zit in het niet bouwen van een app waar een goede mobiele website volstaat. Voor incidentele taken, zoals een verhuizing doorgeven, opent niemand een app die hij eerst moet installeren. Voor terugkerende taken met meldingen, zoals de afvalkalender, is een app juist wel logisch. Die afweging vooraf maken scheelt meer dan welke technische keuze ook.

1. Analyseer waar inwoners nu voor contact zoekenHaal de cijfers uit uw telefonie, uw e-mail en de balie. Die lijst is objectiever dan de wensen van afdelingen en bepaalt uw scope.
2. Bepaal per taak of een app helptTerugkerende taken met meldingen passen bij een app; eenmalige taken meestal bij een goede mobiele website.
3. Beschrijf de weg door de organisatieVolg per taak wat er na het indienen gebeurt en wie hem oppakt. Ontbreekt die route, dan bouwt u een voorkant zonder achterkant.
4. Bouw en toets tegelijkLaat toegan­kelijkheid onderdeel zijn van elke oplevering, en toets naast gereedschap ook met inwoners die het moeilijk hebben.
5. Start met een beperkte groepLaat een wijk of een testgroep de app een aantal weken gebruiken. Meet welke taken worden gebruikt en waar mensen vastlopen.
6. Publiceer de verklaring en plan het onderhoudZet de toegan­kelijk­heidsv­erklaring in het register, met wat nog niet voldoet en wanneer u dat aanpakt. Werk hem bij bij elke wijziging.

• Meldingen-app: signalen die binnenkomen
• Enquête-app: inwoners bevragen
• App of website: wat past bij deze taak?
• Alle app-gidsen

• Gids: meldingen-app
• Overheidsinkoopsoftware
• Selfservice voor gebruikers
• Gids: enquête-app