Content & user interface, een liefdesverhaal

Voor een webshop ontwerp ik voor de zoveelste keer een filter: een lange lijst met mogelijkheden waarmee de gebruiker het aantal producten vermindert tot wat voor hem interessant is. Het ontwerpen van een goede filter is een struikelblok. De oplossing die ik zie, plaats ik in een breder perspectief: integratie tussen content en user interfaces.

Tijdens usabilityonderzoeken zie ik dat gebruikers filters vaak gewoon overslaan en alle producten stuk voor stuk langsgaan, tot ze uiteindelijk vinden wat ze zochten. Niet vreemd, want filteren is een ondersteunende taak. Gebruikers focussen zo snel mogelijk op hun doel, de content. Maar om nou die duizenden producten langs te lopen, dat lijkt me nou ook weer gekkenwerk. Een mogelijke oplossing is dat je de gebruiker eerst op een pagina voor het productoverzicht uit verschillende categorieën laat kiezen. Alleen mis je daarmee het mooie van filteren, namelijk een flexibel zoekpad: de gebruiker kan een keuze overslaan, ongedaan maken of naar wens combineren.

Wat er mis gaat met filters

Stel even dat de gebruiker de filter gebruikt zoals je dat hebt bedoeld. Hij zou dan optimaal efficiënt bezig moeten zijn, en zelfs dan is en blijft een filter verre van ideaal. We kruipen even in de huid van de gebruiker. De gebruiker moet na het bekijken van een aantal producten weer helemaal terug naar de filter scrollen om de filterregel te verfijnen. Je kunt eraan denken om de filter mee te laten scrollen. Helaas is een filter daar te groot voor. Je kunt filters ook ingeklapt tonen om ruimte te winnen, maar dan wordt het zo klein dat nog minder gebruikers het zien.

De gebruiker moet bij elke aanpassing van de filter weer terug omhoog scrollen om het eerste resultaat te zien. Niet erg gebruiksvriendelijk. Het is ook een slecht idee om na elke filterwijziging het scherm automatisch naar het eerste product te laten scrollen. Grote kans dat de gebruiker meerdere filters wil selecteren. Resultaat: chaos en ergernis in het hoofd van de gebruiker. Hoe we de puzzel ook proberen op te lossen: het gaat allemaal niet goed werken op mobiel.

Verschillende type filters leveren dus een verre van optimale ervaring. De oplossing die ik zie, plaats ik eerst in een breder perspectief: integratie tussen content en user interfaces. Daarin schuilt niet alleen de oplossing voor het ‘filterprobleem’, het raakt elk type user interface.

Integreer de user interface in de content

Dat gebruikers user interface-elementen overslaan, geldt niet alleen voor filters. We zien tijdens usabilityonderzoeken dat gebruikers zelden naar onze mening ‘handige tools’, gebruiken. Als interactie-ontwerper reageer je daarop door deze ‘tools’ nog sterker onder de aandacht te brengen, in de hoop dat gebruikers ze gaan gebruiken. Alleen gaan die tools daardoor visueel concurreren met de content, terwijl niets van de content mag afleiden.

We zien content en user interface als twee losse delen

Het probleem is ontstaan doordat we user interface en inhoud als twee losse, onafhankelijke delen zijn gaan zien. Langzamerhand borrelt wel het besef naar boven, ook bij opdrachtgevers, dat je user interfaces pas kunt ontwerpen nádat de content of contentspecificaties er zijn. Een enorme stap voorwaarts, maar hiermee zijn we er niet.

Ik pleit voor de complete integratie van user interface met content. We moeten een website of applicatie niet indelen in blokken user interface en blokken content. Richt je op de contextuele user interface. Daar zit het geheim in.

Voorbeeld ter illustratie

Het voorbeeld van de filters pak ik erbij om dit te illustreren. We gaan het productoverzicht zo ontwerpen dat de gebruiker ook via een product de filtering kan aanpassen. Weer even terug naar de gebruiker. Hij bekijkt een product omdat een eigenschap van dat product hem bevalt, puur omdat hij er naar kijkt. Daarna laten we die keuze de verdere filtering beïnvloeden.

Een ander voorbeeld: onderaan een productenlijst staat een knop ‘Toon meer producten’, geef hierbij dan de mogelijkheid om de meest gebruikte en nog niet gekozen filters te kiezen. Wanneer de gebruiker op ‘Toon meer producten’ klikt is hij nog niet tevreden met het huidige zoekresultaat. Je bent pas behulpzaam als je op het juiste moment, dit moment dus, een aantal relevante filtermogelijkheden aanbiedt. Dit is veel beter dan wanneer de gebruiker uit zijn zoekconcentratie raakt en weer helemaal omhoog moet scrollen naar de filterkeuze. Zoek dit soort momenten in je user interface en maak gebruik van deze benadering.

Integreer ook het menu in de content

Als we deze gedachtengang breder toepassen, kunnen we ook het menu boven elke webpagina laten vervallen. Ontwerpers geven het menu nu vaak vorm als een user interface-element, ondersteunend aan de content en niet geïntegreerd met die content. Dat moet veranderen.

Op de meeste homepages gebruiken bezoekers het menu vaker dan welk ander element ook, terwijl het menu hier weinig ruimte krijgt toebedeeld. Dat is vreemd. Als je de ruimte voor het menu in overeenstemming zou brengen met het gebruik ervan, dan moet het menu bijna de gehele homepage innemen. Dat kan alleen als we deze relevante navigatie uit de header halen en in het contentvlak integreren.

Creëer vrijheid

Door de navigatie op die manier meer ruimte te geven, creëren we ook meer vrijheid. Je kunt er bijvoorbeeld voor kiezen om navigatie op verschillende niveau’s direct en zichtbaar aan te bieden, in plaats van te verbergen in een mega-menu. De gebruiker heeft elke keer weer andere informatie nodig om een weloverwogen keuze te kunnen maken. Een klein horizontaal rijtje losse woorden is ontoereikend.

Bij kleine schermen zeggen we dat content voor navigatie gaat en we navigatie moeten verbergen achter de knop ‘menu’. Het probleem is dat het woord ‘menu’ niets zegt over wat je daaronder kunt verwachten. Het maakt het menu onzichtbaar en minder belangrijk, terwijl het op de homepage het belangrijkste onderdeel is. De speciale knop ‘menu’ is een tussenoplossing en natuurlijk een prima manier om de ‘oude desktopmenu’s’ beschikbaar te stellen op mobiel. Ik zie het als een overgang naar echt adaptieve websites. Ontwerp de homepage als menu en zet het menu op de onderliggende pagina’s in de footer. Het forceert en helpt je op een nieuwe manier naar webpagina’s te kijken.

Voorkom meescrollende elementen

Zoals ik al aangaf proberen ontwerpers ‘handige tools’ steeds meer onder de aandacht te brengen bij gebruikers. Eén manier is door ze continu in beeld te houden, door ze te laten meescrollen. Bekend onder de term ‘fixed position’.

Meescrollende elementen veroorzaken vaak problemen op kleine schermen. Deze fixed positions werken gewoon niet goed op verschillende platformen en we moeten rekening houden met steeds grotere beperkingen op onze schaarse verticale ontwerpruimte in ‘in-app webbrowsers’ (bijvoorbeeld bij de Facebook en Twitter app) dan we al gewend zijn van mobiele webbrowsers.

En ook zonder deze problemen blijven meescrollende elementen afleiden van waar het om draait: de content. Meescrollende elementen zijn een indicatie dat content en user interface gescheiden elementen zijn. Er bestaan goede alternatieven voor meescrollende elementen, en het belangrijkste alternatief is dat ze vaak compleet overbodig zijn.

Integratie & herhaling

Een aantal onderzoeken geeft aan dat een meescrollende header de usability verbetert. Dat ontken ik ook niet. Bij de huidige manier waarop we naar indelingen van een webpagina kijken, verbetert een meescrollende header zeker de user interface. Alleen, het is een tussenoplossing. Er mist integratie, er mist flexibiliteit. Juist de integratie tussen user interface en content zorgt ervoor dat we anders gaan denken over meescrollende elementen en het zoeken naar relevantie.

In de introductie gaf ik aan dat je een probleem inbouwt als je een filter laat meescrollen. De oplossing ligt erin dat je op verschillende manieren de functionaliteit moet herhalen, afhankelijk van de context. Het belang van contextuele user interfaces wordt dus steeds groter. Wees niet bang om interactie te herhalen. De grote uitdaging en onze creatieve en toegevoegde waarde zit hem in het bepalen wanneer welke user interface relevant is en hoe je die moet aanpassen aan de context.

Content is niet de user interface

Eén misvatting wil ik uit de wereld helpen. Content zal altijd iets anders zijn dan user interface. Josh Clark promoot het idee dat knoppen een hack zijn. Luke Wroblewski vat het in één van z’n presentaties goed samen.

“Touch interactions will help us sweep away buttons and a lot of existing interface chrome by moving us closer to the content and away from GUI abstractions. […] Let the content be the message. Instead of labels, let people directly interact with content. Content can be the interface.” Luke Wroblewski, 2012, An Event Apart: Buttons are a Hack

Josh Clark maakt de misvatting dat de fouten in user interface design argumenten zijn voor de discussie, alsof content de taak van user interfaces kan overnemen. Content kan dat niet, content heeft geen ‘affordance’. Zelfs een onderlijning om daarmee een link aan te geven is user interface en geen content. Affordance vraagt om een user interface. Het gaat om de integratie van content en user interface, niet de vervanging.

Aanmaken en bewerken van content staat er los van

Waarvoor ik absoluut niet pleit, is dat we de user interface van de schrijver, integreren in content die bedoeld is voor de consument. Twee compleet verschillende doelen die je niet geforceerd moet combineren. De schrijver heeft zijn eigen user interface. Dus geen WYSIWYG (What-You-See-Is-What-You-Get).

Je introduceert hierdoor een nieuwe modus: de situatie waarin je content wijzigt en waarin je het consumeert. Een modus introduceren is eigenlijk not-done. Toch is dat hier niet helemaal het geval. We moeten hier dan ook spreken over een quasi-modus, omdat het bewerken en bekijken van content totaal andere doelen nastreeft. Dus zien de twee omgevingen er visueel totaal anders uit. Omdat deze visuele prikkel de gebruiker continu bewust houdt van de situatie waarin hij is, spreken we over een quasi-modus en niet over een modus. De gebruiker zal nooit per ongeluk acties uitvoeren in de verkeerde modus.

Dat benadrukt nog eens extra hoe belangrijk het is dat de bewerk-modus er niet uitziet alsof we het eindresultaat aan het bewerken zijn. Dus geen WYSIWYG, wel bijvoorbeeld een Markdown-editor. Die scheiding zal steeds sterker moeten worden om het modus-probleem blijvend op te lossen.

Zet interactie-ontwerper en copywriter bij elkaar

We promoten nu al dat content of content­specificaties voor het ontwerpen van de user interface duidelijk moet zijn. Ik pleit voor complete integratie tussen content­creatie en user interface design. Deze twee disciplines horen bij elkaar en moeten gelijktijdig aan de slag. Niet alleen tijdens SCRUM-trajecten, ook tijdens de ouderwetse ‘watervaltrajecten’. Ga je als interactie-ontwerper meer verdiepen in taal en blijf als copywriter op de hoogte van alle user interface-ontwikkelingen.

Kaders maken ons juist creatief

De kaders van mobiel leiden ons tegenwoordig steeds vaker naar nieuwe ideeën over user interfaces. Het kleine scherm forceert ontwerpers steeds meer te focussen op de content en user interface-vraagstukken anders op te lossen. Die kaders kunnen ongemakkelijk voelen en daarom misschien wel leiden tot verschillende oplossingen voor verschillende schermgroottes. Trap niet in die valkuil, bied dezelfde content op alle devices aan. Kaders forceren ons juist te focussen op het ‘waarom’. En dat is goed voor user interfaces op alle devices.

Foto intro met dank aan Fotolia.