UI-ontwerp voor fintech-apps: maak financiële taken duidelijk en rustig

Maak saldi begrijpelijk in hun context

Een groot getal spreekt niet voor zich. Geef aan bij welke rekening het hoort en toon de valuta met een bekend symbool of code. Als het product onderscheid maakt tussen huidig, beschikbaar, nog te verwerken of belegd bedrag, benoem die begrippen dan rechtstreeks en licht ze zo nodig toe. Toon geen twee soorten saldo in vrijwel dezelfde stijl zonder uitleg.

Context kan ook bestaan uit het tijdstip waarop het bedrag voor het laatst is bijgewerkt of welke activiteiten nog openstaan. Kies details die iemand helpen het scherm te begrijpen, in plaats van decoratieve getallen toe te voegen. Gebruik consistente getalnotatie en voldoende ruimte om cijfers, decimaaltekens en mintekens te onderscheiden. Laat van lange rekeningnamen genoeg tekst zien om rekeningen uit elkaar te houden, in plaats van alleen op kleur of een pictogram te vertrouwen.

• Plaats een expliciet rekeninglabel en de valuta bij het bedrag.
• Leg specialistische termen zoals ‘beschikbaar’ of ‘in behandeling’ in gewone taal uit.
• Zorg dat bedrag en status ook met grotere tekst en ondersteunende technologie begrijpelijk blijven.

Toon transactiestatus als een veranderende toestand

Een transactie is een proces, niet zomaar een rij in de geschiedenis. Geef elk item waar passend een korte status, datum, bedrag en tegenpartij of bestemming. Toon het statuslabel in tekst; kleur of een pictogram mag het versterken, maar mag niet als enige de betekenis dragen. Maak onderscheid tussen wachtende, afgeronde en geweigerde activiteiten en activiteiten die aandacht vragen, volgens de werkelijke statussen van het product.

Een hypothetische overboeking van 45,00 EUR naar Alex zou bijvoorbeeld eerst ‘Gepland voor 4 november’ kunnen tonen, daarna ‘In behandeling’ en later ‘Voltooid’. Als de verbinding na het verzenden wegvalt, meld dan zonder bewijs niet stellig succes of mislukking. Zeg dat de status nog niet beschikbaar is, leg uit hoe die opnieuw kan worden gecontroleerd en maak duidelijk of opnieuw proberen een tweede verzoek kan aanmaken. De exacte tekst en mogelijke acties hangen af van het werkelijke transactiegedrag van het product.

Ontwerp financiële formulieren die vermijdbare verwarring voorkomen

Vraag gegevens wanneer ze voor de taak nodig zijn en groepeer verwante velden in een logische volgorde. Gebruik blijvende labels zoals ‘Ontvanger’ of ‘Bedrag’; een placeholder is een voorbeeld, geen vervanging van een label. Als een veld een specifieke notatie verwacht, leg die dan vóór de invoer uit, bijvoorbeeld of een bedrag centen toestaat of welke identificatiecode in het veld hoort. Apples richtlijnen voor gegevensinvoer adviseren duidelijk te maken welke informatie wordt gevraagd, onnodige invoer te beperken en waarden tijdens het invoeren te valideren.

Kies bedieningselementen die bij de gegevens passen en laat mensen hun invoer corrigeren. Maak optionele velden zichtbaar optioneel en verplichte velden herkenbaar. Als een keuze gevolgen heeft, beschrijf de opties dan in gewone taal in plaats van mensen de betekenis van korte codes te laten raden. Veldhulp moet dicht genoeg bij het veld staan om ook bij een andere schermindeling of vergroting begrijpelijk te blijven.

Geef mensen een nuttige controle- en bevestigingsstap

Vat vóór een handeling met gevolgen de gegevens samen die iemand gaat verzenden: bron, bestemming, bedrag, datum en eventuele weergegeven kosten of timing die voor de flow relevant zijn. Zet de belangrijkste details voor de beslissing bij elkaar en maak bewerken makkelijk vindbaar. De hoofdactie moet de handeling beschrijven, bijvoorbeeld ‘Overboeking plannen’ in plaats van een vaag ‘Doorgaan’.

Een bevestigingsscherm moet antwoord geven op ‘Wat is er gebeurd?’ en ‘Wat kan ik nu doen?’ Een referentie- of ontvangstbewijsweergave kan helpen om later iets terug te vinden. Behandel een druk op de knop niet als bewijs dat de onderliggende handeling is geslaagd; de interface moet de werkelijke uitkomst van het product weergeven.

• Houd de samenvatting in overeenstemming met de ingevoerde waarden en gekozen opties.
• Zorg dat teruggaan en bewerken waar mogelijk het werk van de gebruiker bewaren.
• Meld na het verzenden of het verzoek is ontvangen, in behandeling is of een bevestigde uitkomst heeft.
• Leg bij een onzekere reactie uit hoe de huidige status kan worden gecontroleerd voordat je een nieuwe verzending aanbiedt.

Maak fouten en updates toegankelijk

Als een invoerfout wordt ontdekt, wijs dan het veld aan en beschrijf het probleem in tekst. ‘Ongeldig bedrag’ is minder nuttig dan een melding die de toegestane notatie of ontbrekende waarde uitlegt. Bewaar geldige invoer zodat mensen één probleem kunnen herstellen zonder opnieuw te beginnen. De WCAG 2.2-richtlijnen van het W3C vragen om ontdekte invoerfouten te identificeren en te beschrijven en om labels of instructies te geven wanneer invoer nodig is.

Statusupdates zijn ook belangrijk. Als een pagina van ‘In behandeling’ naar ‘Voltooid’ verandert zonder de focus te verplaatsen, maak die update dan waarneembaar voor ondersteunende technologie. WCAG 2.2 omschrijft statusmeldingen als wijzigingen die resultaten, wachten, voortgang of fouten communiceren zonder contextwissel. Houd meldingen proportioneel: kondig betekenisvolle veranderingen aan zonder iemand bij elke visuele vernieuwing opnieuw te onderbreken.

Controleer contrast, tekstvergroting, toetsenbord- of schakelaarbediening en schermlezernamen in de werkende interface. Gebruik duidelijke koppen en labels en geef succes, fouten of transactierichting niet alleen met kleur aan. Apples ontwerpprincipes benadrukken duidelijke feedback en hulp bij herstel van fouten; dat zijn nuttige doelen, terwijl daadwerkelijke toegankelijkheid vraagt om beoordeling van het complete product.

Controlelijst voor de beoordeling van een fintech-interface

Doorloop een gewone taak van het beginsaldo tot de uiteindelijke status. Controleer het normale pad, een correctie en een onderbreking, zoals een trage verbinding. Vergelijk verwante mobiele schermen in de bibliotheek om te zien hoe verschillende interfaces informatie en acties indelen, en beoordeel daarna je eigen flow op basis van het echte productgedrag.

• Kan iemand zien bij welke rekening en valuta een saldo hoort?
• Zijn wachtende en afgeronde statussen duidelijk benoemd en in tekst weergegeven?
• Heeft elk veld een zichtbaar label en eventuele benodigde instructies over de notatie?
• Kunnen mensen bestemming, bedrag en timing controleren voordat ze verzenden?
• Benoemen fouten het probleem en bieden ze een praktische correctie?
• Blijft een update waarneembaar zonder kleur, scherp zicht of het verplaatsen van de focus?
• Legt de interface bij een onzekere uitkomst uit hoe iemand die kan controleren voordat die opnieuw probeert?