Share
Adembenemende en nuttige ontwerpen gebeuren omdat de UI onvermoeibaar is bewerkt. Er is een echte UI Master voor nodig om te begrijpen hoe je een geweldige gebruikerservaring op een website kunt maken. Hier zijn 10 uiterst nuttige principes van enkele van de slimste geesten in het veld Gebruikersinterface.
Gebruikersinterfaces (UI) zijn wat aparte top-websites van waardeloze websites. De afwezigheid van een nuttige gebruikersinterface kan een uiterst nuttige web-app nutteloos maken. Waarom? Omdat de gebruikersinterface niet doordacht en grondig getest is. Als een gebruiker niet gemakkelijk door een website kan navigeren, slaagt ze er graag in mee naar een andere vergelijkbare site die een betere gebruikerservaring biedt.
Bijna elke webontwikkelaar heeft gehoord van 37 signalen. Het zijn uitgesproken voorvechters van agile ontwikkelingspraktijken, maar wat nog belangrijker is, ze maken een aantal fantastische webtoepassingen. Zo geweldig zelfs dat ze over het algemeen worden beschouwd als de slimste mensen als het erom gaat in de hoofden van de gebruiker te kruipen.
37 Signalen CEO Jason Fried is een groot voorstander van minder tijd te besteden aan het kiezen van neppe details en het maken van details
bruikbare interfaces, met de gebruiker in gedachten.
"Er is veel te veel gepraat over CSS en XHTML en standaarden en toegankelijkheid en er wordt niet genoeg gepraat over mensen. CSS en standaarden Compliant Code zijn slechts hulpmiddelen. Je moet weten wat je met deze tools moet bouwen. Geweldig, ik ben blij dat je gebruikersinterface niet werkt geen gebruik maken van tabellen. Dus wat? Who cares als het dat nog steeds niet doet, laat mensen hun doelen bereiken. Webstandaarden zijn geweldig, maar de eigen normen van de mensen zijn om dingen gedaan te krijgen (en dat is nog steeds te moeilijk om online te doen). "
UI-ontwerpers maken dezelfde oude fundamentele fouten en vergeten de mens aan de andere kant, zodat hun code er beter uitziet. Mensen, geen code-validators, gebruiken interfaces. "
Als je weken achter elkaar met codelagen werkt, is het soms moeilijk om een stap terug te doen en te onthouden dat onze sites door mensen worden gebruikt, geen robots. Dit betekent niet dat we ons helemaal geen zorgen hoeven maken over normen. Normen zijn geweldig en moeten worden nageleefd. We kunnen er gewoon niet van uitgaan dat de naleving van standaarden alles is wat nodig is om een goede gebruikersinterface te maken.
Foutpagina's zijn iets dat de meeste webontwikkelaars, waaronder ikzelf, graag onder het tapijt vegen. Het is een klein detail dat slechts een klein deel van de bezoekers van onze website beïnvloedt, toch??
Usability-expert Jakob Nielsen stelt dat we misschien 404 foutpagina's in het verkeerde licht zien. Misschien moeten we de foutpagina bekijken als een leermiddel.
De meest voorkomende schending van richtlijnen is wanneer een foutmelding eenvoudigweg zegt dat er iets mis is, zonder uit te leggen waarom en hoe de gebruiker het probleem kan oplossen. Dergelijke berichten laten gebruikers achter.
Informatieve foutmeldingen helpen niet alleen gebruikers hun huidige problemen op te lossen, ze kunnen ook dienen als een leermoment. Doorgaans investeren gebruikers niet in het lezen en leren van functies, maar zullen ze de tijd nemen om een foutsituatie te begrijpen als u dit duidelijk uitlegt, omdat ze de fout willen oplossen.
Jeffrey Zeldman is de oprichter van webdesignbureau Happy Cog, een auteur, en is ook A List Apart gestart, een geweldige bron voor webontwikkelaars. Als iemand weet hoe een juiste gebruikersinterface te maken, is het Zeldman.
Jeffrey wijst erop dat een heel over het hoofd gezien stuk van code in webontwikkeling is de afwezigheid van het instellen van een achtergrondkleur.
Het is verbluffend hoeveel webontwerpers vergeten een achtergrondkleur op hun site op te geven. Ze zullen maanden doorbrengen met itererende wireframes en ontwerp-comps; schrijf CSS-hacks voor browsers van vóór deze eeuw; test hun werk op alles van Blackberries tot oude Macs met System 7; en natuurlijk zullen ze hun opmaak- en stijlbladen valideren. Maar na dat alles zullen ze vergeten om een achtergrondkleur op hun site aan te brengen, en ze zullen er niet aan denken om ernaar te kijken.
Toegankelijkheid is een fantastisch ding voor ontwikkelaars om in te schakelen bij het bouwen van een webapplicatie. Het lijkt er echter op dat we ons soms een beetje kunnen laten meeslepen door onze sites en formulieren toegankelijk te maken. Ontwerpgoeroe Roger Johansson wijst erop dat overtoegankelijkheid soms kostbaar kan zijn voor onze gebruikersinterfaces.
Soms, wanneer mensen voor het eerst over webtoegankelijkheid leren, zoeken ze naar snelle manieren om de sites die ze bouwen te verbeteren. Dit leidt vaak tot misbruik of overmatig gebruik van bepaalde HTML-functies die bedoeld zijn om toegankelijkheid te bevorderen, maar bij verkeerd gebruik geen effect hebben en in feite het tegenovergestelde effect hebben door de pagina minder toegankelijk en minder bruikbaar te maken.
Veel van de vaak misbruikte toegankelijkheidsfuncties zijn HTML-kenmerken. Ik heb het idee dat ze misbruikt worden door ontwikkelaars die het goed bedoelen maar niet helemaal begrijpen hoe de attributen eindgebruikers helpen, of door ontwikkelaars die ze toevoegen om simpelweg 'Toegankelijkheid' van hun takenlijst af te vinken en te sluiten hun manager, klant of wie dan ook pesten over het toegankelijker maken van de site.
Mr. Fried of 37 Signals verschijnt nog een keer op onze lijst, dankzij zijn uitstekende advies over hoe ervoor te zorgen dat het belangrijkste aspect van het ontwerp altijd eerst wordt ontworpen. Hij heeft deze methode bedacht als 'Epicenter Design'.
Epicenter Design houdt in dat je je concentreert op de ware essentie van de pagina (het 'Epicentrum') en vervolgens naar buiten bouwt. Dit betekent niet beginnen met de navigatie / tabs, of de voettekst, of de kleuren, of de zijbalk, of het logo, etc. Het betekent beginnen met het gedeelte van de pagina dat, indien gewijzigd of verwijderd, het hele doel van de pagina. Dat is het epicentrum.
Door gebruik te maken van de Epicenter Design-methode blijven onze gebruikersinterfaces gericht en wordt ervoor gezorgd dat we niet "het punt" van de pagina missen.
NETTUTS 'eigen Collis Ta'eed heeft overal een uitstekende tip voor webontwikkelaars: gebruik testen van gebruikers. Wanneer u talloze uren besteedt aan het kijken naar hetzelfde ontwerp op uw monitor, is het soms gemakkelijk om te vergeten hoe de gebruiker de website zou kunnen gebruiken. In feite kan de gemiddelde gebruiker uw applicatie veel anders gebruiken dan zich ooit zou kunnen voorstellen.
Het eerste dat u moet weten, is dat wanneer u een of ander gebruikerstest uitvoert, u een betere webontwerper wordt. U zult precies zien hoe mensen uw webdesign gebruiken en de kans is groot dat u verrast zult zijn hoe zij dit doen. Dingen waarvan je denkt dat ze voor de hand liggen, zijn vaak niet, tekst waarvan je dacht dat ze uitgelegd werd, iets werd niet eens gelezen en gebruikers doen meestal dingen die ze niet zouden moeten doen. Zelfs als de enige gebruiker die je test ooit doet, sommige vrienden vraagt om een site te gebruiken terwijl je ze observeert, ben je er al beter in, ongeacht het project zelf.
Weten hoe gebruikers omgaan met en gebruik maken van uw website is ongelooflijk waardevolle informatie, en bij correct gebruik kunnen uw gebruikersinterfaces aanzienlijk veranderen om beter bij uw gebruikers te passen.
Wat misschien een gek idee lijkt, je vergeet gemakkelijk dat sitegebruikers een stimulans nodig hebben om dingen te doen zoals formulieren invullen en op je website communiceren. Niemand begrijpt dit beter dan een succesvolle internet marketeer. Jim Kukral wijst erop dat de gebruikers, om een succesvolle gebruikersinterface te hebben, op de een of andere manier baat hebben bij het invullen van zaken als feedback of aanmeldingsformulieren.
De gebruiker moet het gevoel hebben dat de waarde of uitkomst zwaarder weegt dan de kosten (of tijd) van het moeten invullen van het formulier. Daarom verminderen de kansen dat de gebruiker de taak voltooit, tenzij u gebruikers iets waardevols teruggeeft.
Incentives kunnen zijn wat u bereid bent te bieden. Hier zijn voorbeelden van mogelijke incentives:
- Geef een cadeaubon weg voor een aantal van uw producten in ruil voor de contactgegevens van de gebruiker.
- Geef de gebruiker een kans om deel te nemen aan een sweepstake of ander soort wedstrijd.
- Bied een gratis download van een aantal expertinhoud of -informatie die relevant is voor het bedrijf bij de hand.
Jakob Nielsen heeft meer dan een decennium webgebruikers onderzocht. Hij heeft talloze tips gegeven over het gebruikersvriendelijk maken van gebruikersinterfaces, maar een van zijn beste adviezen is om ontwerpelementen consistent te houden.
Consistentie is een van de krachtigste usability-principes: wanneer dingen altijd hetzelfde blijven, hoeven gebruikers zich geen zorgen te maken over wat er zal gebeuren. In plaats daarvan weten ze wat er zal gebeuren op basis van eerdere ervaringen. Telkens als je een appel over Sir Isaac Newton laat vallen, valt die op zijn hoofd. Dat is goed.
Hoe meer verwachtingen van gebruikers kloppen, des te meer zullen ze de controle over het systeem krijgen en hoe meer ze het leuk zullen vinden. En hoe meer het systeem de verwachtingen van gebruikers overtreedt, hoe meer ze zich onzeker zullen voelen. Oeps, misschien als ik deze appel loslaat, wordt het een tomaat en spring ik een kilometer de lucht in.
Het is veel te gemakkelijk om een paar buzzwords of een snufje jargon in je UI-kopie te plaatsen. Waarom? Omdat we weten wat dat stukje jargon betekent. We kunnen de gemiddelde gebruiker echter vervreemden door termen te gebruiken die hij misschien niet kent. Webstrateeg Erin Kissane adviseert ons om het jargon om deze reden tot een minimum te beperken.
Er is een tijd voor professioneel jargon: als je weet dat je spreekt met een publiek dat je begrijpt, en je hebt de extra specificiteit en precisie nodig die jargon kan bieden. Als u het buiten deze situatie gebruikt, communiceert u waarschijnlijk niet duidelijk, eerlijk of effectief.
Jargon is hier echter niet echt het probleem. Het probleem met de kopie op deze pagina - en zoveel andere die informatieproducten promoten - is dat het niets zegt. Misplaatst jargon, buzzwords en andere soorten pluis stromen binnen omdat het gebrek aan transporteerbare betekenis een vacuüm creëert.
Als het gaat om het daadwerkelijk bouwen van onze UI's, beginnen veel ontwikkelaars met een draadmodel van hoe de site eruit zal zien. Naarmate Ajax-gestuurde rijke internettoepassingen (RIA) echter steeds algemener worden, is het niet logisch om een bewegende, dynamische website te bouwen met een eenvoudig draadframe. Soms is het alleen effectiever om een prototype te bouwen.
Adaptive Path CTO David Verba betoogt dat het draadframe misschien niet de beste pasvorm is voor het ontwerpen van gebruikersinterfaces, omdat ze gewoon de mosterd niet snijden om een complexe applicatie echt uit te werken.
Prototyping stelt ons in staat om problemen duidelijker - en vaak eerder - te zien in het ontwerp- en ontwikkelingsproces. Naarmate we verder gaan dan websites met bedrijfsinhoud en naar applicaties met een rijke, complexe functionaliteit, is ons vermogen om aan het begin van het project te zitten en mogelijke interacties en problemen te voorzien, verminderd. De probleemruimte is gewoon te complex. Dit is de reden dat we in de eerste plaats wireframes begonnen te gebruiken. Vaak is de enige manier om echt te begrijpen waar problemen zich gaan voordoen of om mogelijke oplossingen te vinden, het schetsen ervan. We gebruiken wireframes om inhoud en lay-out te schetsen, maar als we naar meer interactieve interfaces gaan, zijn wireframes minder effectief. We moeten schetsen met daadwerkelijke functionaliteit - schets in code, om zo te zeggen - zodat we kunnen zien hoe de applicatie zich echt zal gedragen.
Glen Stansberry is een webontwikkelaar en blogger die meer worstelt dan hij zou willen toegeven met CSS. Je kunt meer tips over webontwikkeling lezen op zijn blog Web Jackalope.
Accentsconagua