Share
Om overal software en applicaties van te maken, is UX een steeds belangrijkere stap in de levenscyclus van softwareontwikkeling geworden. Hoewel UX een enigszins heimelijk laag ontwerp is, is het niet minder belangrijk. Het definieert, door de aard van zijn naam, de ervaring van de gebruikers. Die ervaring bepaalt of ze terug willen komen voor meer, of schreeuwen in de andere richting.
UX is iets dat iedereen kan doen. Het probleem is niet dat iedereen het goed kan. Ik kan het visuele ontwerp voor een website uitvoeren, maar ik garandeer je dat het er vreselijk en onprofessioneel uitziet.
Als je niets anders over UX leert, vraag ik je deze twee dingen te onthouden.
Als u uw gebruikersbestand, hun gewoonten en neigingen niet kent en waarom zij bepaalde acties niet uitvoeren, kunt u van hen niet verwachten dat ze een goede ervaring ontwerpen. Zelfs als u sterk op uw gebruikers lijkt, moet u er rekening mee houden dat u maar één persoon bent en dat dit niet de kwaliteiten van uw gebruikersbestand als geheel bepaalt. Maak kennis met uw gebruikers en ontwerp de ervaring met hen in gedachten. De rol van een UXer is om die kennis te hebben, deze voortdurend uit te breiden en vervolgens te ontwerpen met die gebruikers in gedachten, geweldige ervaringen te maken die hen zullen verrassen en vervullen..
Laten we eens kijken naar alle mogelijke stappen die een UXer kan nemen bij het definiëren van de UX van een product. Deze stappen creëren het ideale proces. Deze stappen zijn niet altijd mogelijk om te voltooien in de echte wereld, maar we moeten ze allemaal behandelen, zodat je weet wanneer je bepaalde stappen kunt weglaten en waarom. Soms laat je niet per se een stap achterwege, maar wordt het samengevoegd in een andere stap of vervangen door een combinatie van ervaring, kennis en intuïtie.
Requirements Gathering is een van de eerste stappen bij het ontwerpen van de UX. Tijdens deze fase moet je veel vragen stellen. Veel vragen kunnen mogelijk niet meteen worden beantwoord, maar noteer deze en wees persistent. Er zijn verschillende soorten vereisten:
Deze vereisten vormen de basis voor uw ontwerp. Zonder deze zijn je ontwerpen doelloos.
Voordat we kunnen ontwerpen voor een gebruiker, moeten we onze gebruikers kennen. Soms heb je veel bestaande kennis over hen. Soms ken je maar een handvol veronderstellingen over hen. Als u geen kennis heeft van uw gebruikers, is uw ontwerp op zijn best een goed opgeleide gok. Gebruikersanalyse is nodig om de behoeften en neigingen van de gebruikers te begrijpen.
U moet ten minste de volgende vragen stellen om een goed beeld te krijgen van uw gebruikersbestand:
Nadat we onze gebruikersanalyse hebben voltooid, moeten we verder gaan met de taakanalyse. Wat is de primaire actie die de gebruikers moeten uitvoeren? Er kunnen veel dingen zijn die iemand op uw site of in uw applicatie kan doen, maar er is altijd wel een hoofdtaak. U moet uitzoeken wat die taak is en de UX voor die taak optimaliseren voor het specifieke gebruikersbestand waarvoor het is bestemd. We zijn nog steeds niet in de ontwerpfase, maar we weten nu wat we gaan ontwerpen en voor wie we het ontwerpen.
We moeten ook eventuele secundaire taken bepalen. Er zijn maar weinig sites / applicaties waar gebruikers maar één ding kunnen doen; er zijn vaak verschillende gerelateerde taken die moeten worden uitgevoerd. Doe dit allemaal om te weten wat de breedte is van wat u ontwerpt.
Andere dingen om uit te vinden in de taakanalyse:
Functie Toewijzing is uitzoeken wat moet omgaan met alle functies waarvan u hebt vastgesteld dat deze moeten gebeuren. Dit gebeurt op verschillende niveaus.
De antwoorden op deze vragen kunnen de efficiëntie en bruikbaarheid van uw product drastisch beïnvloeden.
Schetsen. Veel. Het is snel. Het is goedkoop. Het is effectief.
Schetsen krijgt heel wat ideeën uit je hoofd en snel op papier. Het helpt goede ideeën vorm te geven en slechte ideeën te elimineren. U kunt zeer snel doorschaven naar schetsen. De investering is laag voor het rendement.
Creativiteit is ook de sleutel in deze stap. Doe wat gekke, ongebruikelijke dingen. Ze werken mogelijk niet, maar ze kunnen een ander idee oproepen. Probeer je schetsen aanzienlijk te variëren om te zien hoe ver je een idee kunt rekken.
Pen / Potlood + Papier = Een bank om vanaf te tekenen voor wanneer je echt begint met het definiëren van je ontwerpen.
Nu zou je op zijn minst een idee moeten hebben van waar je wilt dat je ontwerp gaat. De eerste set wireframes moet een iteratie zijn van uw schetsen en moet meer definitie opleveren. De informatiearchitectuur zou moeten beginnen plaatsvinden. Dit is waar dingen gaan van een stel losse concepten en stukjes informatie naar een meer samenhangende documentatie over hoe het product eruit ziet en functioneert.
Er zijn veel verschillende prototypen die je kunt doen. Deze kunnen variëren van een zeer eenvoudige klikbare PDF tot een bijna volledig functionerende HTML / CSS-website. Het hangt er echt van af wat je nodig hebt voor je project en hoe ver je daarmee gaat. Er zijn echter genoeg tools om je prototypes snel op te zetten. Een klein voorbeeld omvat:
Zoek de tool uit die bij uw workflow en kennisbasis past om erachter te komen wat u snel en effectief kunt prototypen. Prototypes moeten niet lang duren, maar ze moeten uw ontwerp en interacties effectief overbrengen.
Prototypes helpen te achterhalen waar vreemde dingen liggen in de interactie en hoe het voelt als het product daadwerkelijk in beweging is. Het kan helpen bij het blootleggen van sommige dingen die statische wireframes mogelijk niet volledig kunnen ontdekken.
Dit is waar je dan teruggaat en de wireframes high-fidelity gaat maken. Voeg alle gewenste definities toe. Behandel zoveel details over de lay-out en interactie als je kunt. Alles wat u open laat voor interpretatie, kan gemakkelijk op de tegenovergestelde manier worden opgevat als u wilde. Neem niets aan.
Betere visuele kwaliteit kan al dan niet noodzakelijk zijn. Meestal moet dit in de visuele ontwerpfase echt worden opgevangen. Ik heb gemerkt dat het vaak beter is om terug te vallen op meer wireframe-y-beelden om verwarring met uiteindelijke kleuren en visuele ontwerpspecificaties te voorkomen. Ik gebruik echter wel kleur als deze gerelateerd is aan functionaliteit (bijvoorbeeld rood voor foutmeldingen).
Deze stap kan plaatsvinden waar u het nodig heeft tijdens het ontwerpproces. Het past soms aan het einde en soms meer aan het begin van een project. Dit is echter waar u daadwerkelijke gebruikersfeedback krijgt. Ze kunnen uw vermoedens bevestigen. Ze kunnen je gedachten op hun kop zetten. Dit is echter cruciaal om hun gedachten te kennen en waar hun problemen liggen.
U ontwerpt voor de gebruiker. Deze feedback zou uw ontwerp of herontwerp moeten stimuleren om de problemen aan te pakken die zich tijdens deze test voordoen. Het uitsluiten en negeren van deze feedback, zonder echte uitschieters, is onverstandig en een absolute UX-zonde.
Ik heb veel UX-processen gezien, beschouw dit als het punt waarop ze hun documentatie overhandigen, hun vingers kruisen en er het beste van hopen. Dat zou niet het geval moeten zijn! Ik werk zeer samen, zelfs nadat ik klaar ben met de juiste UX.
Je visuele ontwerpers moeten ook aan de UX denken. Als ze dat niet zijn, zou ik beweren dat ze hun werk niet volledig doen. Het is geweldig om je wireframes er beter uit te laten zien, maar als ze een idee hebben dat de UX nog beter bereid maakt om te luisteren en te integreren. Vaak denken ontwerpers anders genoeg om geweldige ideeën en verbeteringen aan te sturen.
Op dezelfde manier zou je met ontwikkelaars moeten werken. Dit is misschien niet zo een samenwerking, maar er zijn vaak problemen die zich voordoen tijdens deze fase waarin u de UX moet aanpassen. Dit helpt u ook om een goed begrip te krijgen van de technische beperkingen voor toekomstige projecten. Uw ontwikkelaars zullen veel gelukkiger zijn om deze kennis te vergaren dan om onmogelijke oplossingen te ontwerpen.
Test ook je UX tegen het eindproduct. Hier ga je terug naar de wireframes en zorg je ervoor dat wat je klanten gaan doen, is wat je hebt ontworpen. Het is niet ongebruikelijk dat iets niet klopt en je zou je ontwikkelaars voldoende moeten opzoeken om die problemen naar voren te brengen. Uiteindelijk bent u verantwoordelijk voor de ervaring van uw gebruikers, dus zorg ervoor dat ze het product krijgen dat u hebt ontworpen.
Dit zijn slechts de basis voor het samenstellen van geweldige UX. Mogelijk kunt u niet al deze stappen uitvoeren, maar u moet zich ervan bewust zijn wanneer u ze kunt weglaten.
Ik vind persoonlijk dat UX geen formule is. Het verschilt project per project en is gebaseerd op een samensmelting van kennis, ervaring, onderzoek en intuïtie. We zullen in toekomstige artikelen nader ingaan op specifieke gebieden, maar we hadden eerst een basis nodig van wat een UXer op een bepaalde dag op het werk doet. Met de hierboven geschetste stappen bent u op weg om te weten hoe u geweldige UX kunt samenstellen voor producten waar uw gebruikers dol op zullen zijn.
Accentsconagua