Een SaaS (Software as a Service) oplossing begint vaak met een geniaal idee. We kunnen probleem X oplossen als we Y bouwen. Maar hoe zorg je voor een prettige gebruikerservaring? Hoe zorg je dat je kan doorontwikkelen zonder steeds opnieuw de interface om te moeten gooien? Ik werkte zelf aan diverse SaaS oplossingen met honderden gebruikers, in verschillende branches. Ik heb gezien hoe bedrijven groeiden van een leuk software bedrijfje op zolder naar een onmisbare schakel met meerdere development teams, met de bijbehorende uitdagingen op UI en UX vlak. In deze blogpost geef ik je 5 bruikbare tips om je SaaS oplossing goed te ontwerpen.

UI? UX?

Voordat we beginnen even een korte uitleg van de begrippen UI en UX. Met UI bedoel ik de User Interface. Dus dat wat de gebruiker op zijn scherm ziet. UX gaat over de User Experience, dus dat wat de gebruiker ervaart als hij de software gebruikt. Daarbij gaat het dus meer om de manier van navigeren, het krijgen van feedback en hoe makkelijk het is om bepaalde taken uit te voeren. De User Interface draagt bij aan een prettige User Experience. Klein voorbeeld: als je de knoppen er niet uit laat zien als knoppen, of als je ze veel te klein maakt om er makkelijk op te kunnen klikken, dan heeft dat een negatieve invloed op de User Experience (UX).

Standaardisatie

Standaardisatie maakt het makkelijker te schalen en zorgt voor een consistente gebruikerservaring. Veel developers zullen al werken met componenten. Herbruikbare stukjes code die ze zo ergens in kunnen plakken. Ook in ontwerp kennen we componenten, vaak als onderdeel van een design system. Zorg dat de onderdelen van jouw design system (denk aan kleuren, typografie, buttons, tables, formulier elementen, etc.) aansluiten op de library van de developers. Het loont om hier tijd en energie in te steken. Als jij consequent dezelfde elementen gebruikt dan kunnen zij veel sneller bouwen. Andersom werkt het in de praktijk vaak ook: als jij weet welke componenten de developers gebruiken dan moet je zorgen dat deze ook onderdeel zijn van je design system.

Design standaardiseren is dus belangrijk. Vaak wordt er dan al gedacht aan kleuren, typografie en onderdelen die door de hele applicatie heen gebruikt worden:

• Buttons

• Invoervelden

• Checkboxen/radio buttons, switches (toggles)

• Tables

• Tooltips

• Badges

• Tabs of andere navigatie onderdelen

• Icons

Wat ik echter gemerkt heb is dat het ook enorm helpt om na te denken over vaste interactiepatronen en een vaste pagina opbouw.

Zo’n vaste pagina opbouw klinkt logisch: het menu staat bijvoorbeeld bovenin of links en de content altijd in het midden. Maar probeer iets verder te denken. Waar komen bijvoorbeeld meldingen, welke informatie wil je altijd in beeld hebben en hoeveel ruimte mag dat innemen? Hoe ga ik om met detailschermen? Kan een gebruiker meerdere views naast elkaar hebben? Hoe gaan we om met het filteren van data? En moet dit altijd beschikbaar zijn of oproepbaar? Hoe gaan we om met smalle schermen? Door hier van tevoren goed over na te denken (of een bestaande opzet kritisch onder de loep te nemen) voorkom je dat je later in de knel komt omdat iets niet past binnen het bedachte framework.
Start met het opzetten van een grove pagina opbouw, bijvoorbeeld in wireframes. Kijk hoe toptaken (de taken die het meeste worden uitgevoerd) hierin passen. Lijkt dit te werken, probeer dan met echte data een eerste prototype te maken en toets dit bij een aantal mensen. Het lastige van applicaties is dat je van tevoren niet altijd weet welke (grote) features er allemaal nog gaan komen. Daarom helpt het om te denken in concepten: dit type data stoppen we hier, details plaatsen we daar in paneel X, filters altijd in paneel Y, etc.

Vaste interactiepatronen kunnen bijvoorbeeld zijn:

• Een taak voer ik altijd uit in een modal

• Notificaties komen altijd als balk bovenin en zijn terug te vinden op een vaste plek

• Het verwijderen van iets gaat altijd in 2 stappen

• Na het toevoegen van een item lichten we dit even uit

• Primaire acties hebben een button, secundaire acties tonen we als link

• Etc.

Het vastleggen van dit soort interactiepatronen zorgt ervoor dat je sneller nieuwe features kan ontwerpen en bouwen.

Begrijpelijke copy

Een SaaS oplossing is net een collega, het helpt als deze sympathiek en vriendelijk is. Besteed daarom aandacht aan de teksten in je applicatie. Vergeet daarbij niet de fout- en succesmeldingen of de micro-copy (teksten bij buttons, labels, etc).
Wat tips hierbij

• Voorkom afkortingen

• Zorg dat buttons duidelijk de actie beschrijven

• Ga er niet vanuit dat jargon bij iedereen bekend is. Er kunnen ook nieuwe medewerkers komen die het systeem gaan gebruiken

• Maak tekst zo leesbaar mogelijk. Stel je toont het moment van opslaan, zet dan niet ‘9:12 uur’ neer maar liever ‘X minuten geleden’.

• Wees vriendelijk. Dus niet: Error. Dit veld is verplicht. Maar liever: Zou je dit veld nog even in willen vullen? (Wil je meer tips over goede foutmeldingen, lees dan de blogpost hierover)

• Wees sympathiek. Complimentjes krijgen vinden we allemaal leuk. Kleine moeite om dit in je software te verwerken. Als iemand alle taken heeft afgerond: ‘Lekker gewerkt! Er zijn geen taken meer.’ Als er een nieuw item is aangemaakt: ‘Goed bezig, X is met succes aangemaakt’.
  Je kan hier nog een stap verder in gaan door goed te bestuderen welke taken je wellicht (deels) kan automatiseren. ‘We zien dat er nog 2 vergelijkbare taken zijn, wil je die nu ook meteen doen?’ of ‘Door deze wijziging is het slim om ook even X en Y na te lopen. Wil je hier een taak voor aanmaken?’. Zo wordt het systeem een collega die je werk uit handen neemt en zal de waardering toenemen.

Elimineer ruis

Hoe minder ruis, hoe prettiger een applicatie werkt. Dat geldt ook voor jouw SaaS oplossing. Hierbij spelen 2 belangrijke regels: voorkom wildgroei aan features en ontwerp een taakgerichte interface.

Voorkom wildgroei

Het beperken van het aantal features is waarschijnlijk de grootste uitdaging voor elk SaaS project. En zeker als het gaat om een generiek platform waarvan meerdere klanten gebruik maken. Met bijbehorende wensen per klant. Je wil tegemoetkomen aan de wensen van de klant maar moet tegelijkertijd voorkomen dat er te specifieke onderdelen in je applicatie zitten. De oplossing? Een hele duidelijke visie. Jij moet vooruit denken. Waar beweegt de markt zich naar toe, welke kant willen jullie op als bedrijf en hoe moet jullie software zich ontwikkelen om die kant op te kunnen?

Wat ik vaak zie gebeuren is dat – uit angst een klant te verliezen – er voortdurend features geïmplementeerd  worden die voortkomen uit klantwensen. De backlog loopt over en Customer Success managers vechten voor hun klanten om wensen erdoor te krijgen. Degene die het hard roept wint. Dat is het moment om aan de handrem te trekken en even de stilte op te zoeken. Stel jezelf de vraag: welke problemen lost onze software op en hoe denken wij dat we het oplossen van die problemen het beste kunnen aanvliegen?

Moet je dan de klantwensen negeren? Nee, zeker niet! Je kan je klanten nog steeds betrekken bij alle ontwikkelingen die je doet. Bijvoorbeeld door per kwartaal thema’s te bedenken die jullie belangrijk vinden binnen jullie SaaS oplossing en daar met klanten over in gesprek te gaan. Jullie pakken de leiding, maar de  klant kan meedenken en input leveren die waardevol is bij het verder uitwerken van zo’n thema. Win win.

Taakgerichte interface

Elimineer ruis met een taakgerichte interface. Hou er in je ontwerp rekening mee dat er doorgaans twee verschillende views bestaan: kijken en wijzigen. In de kijkmodus wil je dat de gebruiker makkelijk de informatie kan vinden die hij zoekt. In de wijzig modus draait het om het zo eenvoudig mogelijk kunnen wijzigen of toevoegen van content. Voor beide gevallen geldt: de gebruiker komt met een doel.

Laten we als voorbeeld even een SaaS oplossing pakken voor de boekhouding. Een doel van de gebruiker kan dan zijn: ik wil zien of factuur X al betaald is. Of, ik wil de omzet van Q1 zien. Doelen in de wijzig modus kunnen zijn: ik wil een inkoopfactuur inboeken. Of, ik wil een e-mailadres van een debiteur wijzigen. Allemaal taken binnen de SaaS oplossing. Zorg dat je heel goed in kaart hebt wat de toptaken zijn van je gebruikers (kom ik later nog op terug). Hou vanaf het begin af aan rekening met de 2 modi en zorg dat alle toptaken binnen een paar kliks uitgevoerd kunnen worden.

Moneybird, SaaS oplossing met een taakgerichte interface

Een goed voorbeeld van zo’n taakgerichte interface vind ik Moneybird. Het zit vol features maar ze zijn er goed in geslaagd om de toptaken centraal te houden. Dat zie je al terug in de de menu-structuur waar de meest gebruikte onderdelen staan, maar bijvoorbeeld ook in details als de dropdown ‘Facturen uit dit jaar’ in bovenstaand voorbeeld. Klap je die open dan kan je een andere periode selecteren maar bijvoorbeeld ook direct ‘Niet-betaalde facturen’. Heel handig als je taak is: ik wil herinneringen sturen naar de klanten die nog niet betaald hebben.

Een taakgerichte interface betekent ook dat je kritisch bent op wat je toont op het scherm. Als je goed kijkt naar bovenstaand voorbeeld dan zie je dat er ook een hoop informatie niet staat (bijvoorbeeld hoeveel dagen een factuur open staat, de contactpersoon, BTW bedragen, hoe vaak iets herinnert is, onder welke categorie de factuur valt, onder welke workflow de factuur valt, etc). Hierdoor blijft de interface clean waardoor je zo’n overzicht veel sneller kan scannen en door kan klikken naar een detailscherm. Is dat in jouw interface nog niet het geval? Begin dan rap met schrappen!

Doe onderzoek

Jij bent niet de gebruiker. Nee, echt niet. En zelfs de mensen binnen jouw klantenkring waarmee je contact hebt zijn hoogstwaarschijnlijk niet jouw gebruikers. Je hebt waarschijnlijk te maken met Project managers, afdelingshoofden of teamleiders, die als een extra schakel tussen jou en de daadwerkelijke eindgebruikers zitten. Wees je daar bewust van want dit betekent dat dit dus niet de mensen zijn die dagelijks met de applicatie werken. Je bent afhankelijk van wat ze terughoren van de mensen op de werkvloer. Net als jij werken ze dus niet dagelijks met de software, terwijl het best zo kan zijn dat ze prima weten wat er mee kan.

Hetzelfde geldt voor de mensen in jouw team, de mensen van marketing, de Succes managers en de dames en heren van sales. Zij horen uiteraard wat er leeft bij klanten, maar heel vaak indirect.

Voordat je dus los gaat op roadmaps, epics en user stories is het cruciaal dat je gebruikersonderzoek doet. En let op, dit kan al heel laagdrempelig en eenvoudig. Vraag of je eens een ochtend naast iemand mag zitten die dagelijks werkt met de applicatie. Ga zo een aantal verschillende klanten af en observeer goed hoe ze werken, wat ze naast jullie applicatie nog gebruiken aan software om hun werk goed te kunnen doen en waar ze daarnaast nog druk mee zijn. Zo kwamen we er bij één van mijn klanten achter dat ze veel communicatie nog via Slack deden, iets wat je niet haalt uit de statistieken. Door goed te begrijpen waarvoor ze Slack gebruikten konden we dit deels verwerken in de applicatie en zo het werk weer wat makkelijker maken.

Een andere mogelijkheid is om wat gebruikers uit te nodigen op kantoor als je een nieuwe feature bedacht hebt. Zorg voor een prototype waar ze doorheen kunnen klikken. Dit hoeft nog niet pixelperfect te zijn. Geef ze een taak en kijk goed wat er gebeurd. Gebruiken ze de feature zoals bedacht? Haperen ze ergens? Klikken ze waar je verwacht? De setup hiervoor kan best eenvoudig zijn; met een scherm op een bureau kom je al een heel eind. Je kan dan gewoon ernaast gaan zitten en kijken. Het kan wel zijn dat de testpersoon dan extra goed zijn best doet. Er bestaat ook software om op een ander scherm (bijvoorbeeld in een andere ruimte) te volgen wat iemand doet zodat je er niet persé naast hoeft te zitten.

Tools als Hotjar kunnen je ook inzicht geven in het gebruik. Door middel van heat- en clickmaps krijg je een globaal inzicht in wat er veel gebruikt wordt, screen recordings kunnen erg waardevol zijn om te zien hoe iemand door de applicatie heen klikt. Het bekijken ervan kost wel veel tijd, je moet er echt wel tientallen bekijken om een goed beeld te krijgen. Daarom werkt het soms net zo makkelijk om even naast iemand te gaan zitten. Je kan dan ook nog wat vragen stellen als je ziet dat iemand de applicatie anders gebruikt dan verwacht.

Zet de content centraal

Zoals eigenlijk voor ieder web-ontwerp geldt: zet de content centraal. Jouw branding is niet boeiend voor de gebruiker. Daar hoef je dus geen rekening mee te houden.

Branding in Google docs: vrijwel niet aanwezig zodat alle focus naar de content gaat.

Hierboven een voorbeeld van een behoorlijk grote speler: Google. De stijl is herkenbaar maar zit nergens in de weg. En let op! Geen logo in beeld, de focus ligt volledig op het document en alle tools om het document te bewerken. Pak een willekeurig ander voorbeeld van een grote speler en je zal ontdekken dat ze in hun software heel weinig doen met hun branding.

Hou je daarnaast zoveel mogelijk aan conventies. Dus knoppen gewoon herkenbaar als knoppen, linkjes in blauw, inputs voorzien van een kader, etc. Dat scheelt namelijk gewoon denkwerk voor de gebruiker. Keep it Simple, stupid.

Nog een paar tips die je kunnen helpen om de content centraal te stellen:

• Gebruik koppen en subkoppen om hiërarchie aan te brengen en scanbaarheid te verhogen

• Zorg voor voldoende witruimte. Ook als dat ervoor zorgt dat mensen wat meer moeten scrollen. Dat doen ze heus wel

• Rustig aan met kleur. Hou je kleurenpalet rustig en kalm. Gebruik kleur om accenten aan te brengen, visuele clues. Niet om de boel wat op te leuken.

• Gebruik de volledige breedte van het venster. Het is bij een SaaS oplossing geen ramp als belangrijke dingen aan de zijkant staan, dit in tegenstelling tot websites. Bij veel van mijn klanten zie ik ook dat de gemiddelde resolutie behoorlijk hoog is. 1920 x 1280 px is geen uitzondering. Ga er alleen niet vanuit dat mensen altijd het venster op de volledige breedte zetten. Hou een veilige marge aan, en kijk vooral ook goed naar je Analytics data om te kijken wat de gemiddelde resolutie bij jouw klanten is.

Samenvattend

Zet bij het ontwerpen van je SaaS oplossing de gebruiker centraal. Begin met gebruikersonderzoek en zorg dat je de toptaken van je gebruikers goed in beeld hebt. Werk vanuit een duidelijke visie een interface uit die je zo veel mogelijk standaardiseert. Dit zorgt ervoor dat jouw gebruikers snel de applicatie “doorhebben” en jouw developers sneller nieuwe features kunnen implementeren. Zet de content centraal en besteed veel aandacht aan de teksten binnen je applicatie, het kan geen kwaad als je sympathiek overkomt. Draait je applicatie lekker soepel, blijf dan onderzoeken wat er beter kan en voer verbeteringen door die passen binnen de visie.

Hulp nodig?

Wil jij ook aan de slag met het verbeteren van jullie SaaS applicatie? Zie je dat het beter kan maar weet je niet hoe je het aan moet pakken? Wil je eens dat ik met je meekijk naar wat er wellicht beter kan?

Neem zeker even contact met me op, want ik help jullie graag!

Zo is er bijvoorbeeld de Around Seven UX Audit voor Saas platforms, en de Around Seven UX SaaS strippenkaart (ideaal als je af en toe eens wil sparren over UX kwesties).