Startpagina » UI / UX » Herkennen en beheren van UX-schulden

    Herkennen en beheren van UX-schulden

    Schuld in gebruikerservaring gebeurt onvermijdelijk in de loop van de tijd. Het is de som van achterstallige ontwerp- en bruikbaarheidstaken afgeleid van zaken als snelle zakelijke beslissingen, ontwerpsnelkoppelingen, gemiste kansen, tijdsbeperkingen en andere factoren.

    Ervaringsschuld wordt een schuld genoemd omdat het vergelijkbaar is met de schuld in het echte leven; we krijgen iets in het heden, maar alleen betaal ervoor in de toekomst. Tot de schuld is afbetaald, rentetarieven ontstaan ​​als permanente kosten.

    Schuld van gebruikerservaring - samen met zijn naaste neef, technische schuld - is een ontwerp antipatroon die de kwaliteit van een project vermindert. Aangezien gebruikerservaringschuld een minder algemeen besproken onderwerp is, is het naast het niet altijd gemakkelijk om het te herkennen, in dit artikel van naderbij bekeken..

    Technische schuld versus UX-schuld

    Er zijn verschillende soorten schulden in webontwikkeling. De meest bekende is technische schuld dat is gedefinieerd door CSS Trucs als "de som van compromissen we maken bij het schrijven van code tijdens het ontwikkelingsproces ".

    Later in onze workflow, zullen we moeten omgaan met de gevolgen van deze compromissen, wat in de toekomst extra werk betekent.

    IMAGE: FeatureFlags.io

    Technische schuld gaat niet over regelrechte bugs, maar over het feit dat het zelfs met de beste codeerpraktijken onmogelijk is om een ​​code volledig toekomstbestendig te maken, maar efficiënte code-optimalisatie kan zeker helpen.

    Het gebruik van antipatterns, coderingssnelkoppelingen, ondoeltreffende architectuur of moeilijk te beheren afhankelijkheden kunnen allemaal bijdragen aan technische schulden, maar het punt is dat zelfs in een optimaal, hypothetisch ideaalscenario het onmogelijk te vermijden is - als toekomstige onverenigbaarheden, behoeften en problemen zijn onvoorspelbaar. Daarom wordt refactoring na een tijdje aanbevolen.

    Ervaringsschuld is vergelijkbaar met technische schuld in die zin dat:

    • kan niet worden vermeden (hoewel het kan worden verminderd)
    • is moeilijk te herkennen
    • kan het succes van een project in gevaar brengen.

    User experience debt is een bredere categorie dan bruikbaarheid schuld, omdat het niet alleen gaat om hoe bruikbaar een website of applicatie is, maar ook om de manier waarop gebruikers uw product ervaren - of ze het leuk vinden, nuttig belonen of welk gevoel dan ook dat je wilt oproepen bij je doelgroep.

    Gebruikerservaring omvat bruikbaarheid, omdat een moeilijk te gebruiken site gebruikers niet op hun gemak zal stellen, en op dezelfde manier omvat UX-schuld bruikbaarheidsschuld ook.

    Helaas zijn er niet veel online bronnen over bruikbaarheidsschuld en gebruikerservaringschuld, maar hier zijn enkele die ik nuttig heb gevonden, en hebben me geholpen mijn mening over het onderwerp te vormen:

    • Catriona Cornett, de directeur van Product Design op SalesforceIQ op hoe effectief bruikbaarheidsschuld aan te pakken (lees hier)
    • TryMyUI's blog op hoe UX schuldencrisis te voorkomen (lees hier)
    • Gebruikerservaring Professionals Association over hun benadering van UX-schuld met een aanbeveling op hoe het volume te berekenen (lees hier)
    • Van Andrew Wright uitleg en classificatie van UX-schuld op nForm Blog (lees hier)

    Van alle mogelijke illustraties die ik kon vinden op UX-schuld, is dit vrijwel de beste keuze, omdat ik denk dat het kernachtig zijn essentie laat zien.

    AFBEELDING: Diavoorstelling van Andrew Wright: User Experience Debt (dia 12)

    User experience debt kan worden gedefinieerd als de verschil tussen de ervaringskwaliteit van uw huidige en optimale product.

    UX-schuld is subjectiever dan technische schuld, omdat jij (of je klant) de kwaliteit bepaalt die je wilt bereiken. U kunt bijvoorbeeld het "Functioneel" niveau voor een minimaal haalbaar product, maar je kunt ook hoge (maar meestal dure) normen instellen gericht op de "Aangenaam" niveau voor een premium product - het hangt allemaal af van je doelen.

    Technische schuld is anders in de zin dat in veel gevallen slecht beheerde code stopt gewoon met werken. Met UX-schuld zijn er geen dergelijke drastische veranderingen, maar dit is niet alleen een extraatje, maar ook een bedreiging maakt dit soort schuld gemakkelijker te verwaarlozen.

    Hoe UX-schuld te herkennen

    Om UX-schuld te beheren, moeten we het eerst erkennen. Er zijn twee soorten UX-schulden, opzettelijk en onopzettelijk.

    1. Opzettelijke UX-schuld is het resultaat van onze bewuste beslissingen wanneer we gebrek aan geld, tijd, training, of andere bronnen, of wanneer we zijn gedwongen om externe regels te volgen. Goede ideeën die we verliezen in het midden van gehaast werk dragen ook bij aan opzettelijke UX-schuld.
    2. Het is gemakkelijk om die opzettelijke UX-schuld te zien kan op elk moment voorkomen gedurende de levenscyclus van een product.
    3. Onbedoelde UX-schuld komt voort uit valse aannames die we maken over onze gebruikers. Vaker wel dan niet hebben we de neiging om te denken dat we weten wat onze gebruikers willen, graag, of kunnen gebruiken, en we bouwen onze hele site (app, product, etc.) op deze veronderstelde kennis.
    4. Een behoorlijk bedrag van onbedoelde UX-schuld ontstaat bij de begin van de levenscyclus van het product, en het natuurlijk neemt in de loop van de tijd toe. Onbedoelde UX-schuld is veel moeilijker te vangen, zoals we nodig hebben ontdoen van onze behoefte om onze aannames te rechtvaardigen.

    Dus hoe ziet UX-schuld eruit in het echte leven? Wanneer gebruikers onze site niet kunnen of willen gebruiken vanwege slechte gebruikerservaring. Ze gewoon verloof je niet; wij kunnen hun aandacht en interesse niet vangen.

    De manifestatie van UX-schuld verschilt van site tot site, maar als we een de conversieratio verlagen of een stijgend weigeringspercentage in de meeste gevallen kunnen we vermoeden dat we een mooie hoeveelheid UX-schuld hebben opgebouwd.

    Hoe UX-schulden te beheren

    er is geen universeel recept om UX-schuld effectief te beheren, omdat veel dingen afhankelijk zijn van subjectieve kenmerken, maar het is de moeite waard om eens te kijken naar hoe anderen omgaan met het probleem om onze eigen weg te vinden.

    Bijvoorbeeld, Catriona Cornett, de Product Design Director van SalesforceIQ toont het 5-stappenproces dat ze gebruiken om bruikbaarheidsschuld bij SalesforceIQ te beheren.

    Laten we het kort zien, zodat we kunnen beoordelen hoe goed we het kunnen toepassen op onze eigen workflow.

    1. Definieer een gedeelde taal voor het bespreken van usability-problemen.
    2. Vind en verzamelen gebruiksproblemen.
    3. Organiseren en classificeren de bruikbaarheidsproblemen.
    4. Prioriteren gebruiksvriendelijkheid verbeteringen.
    5. Maatregel de impact van verbeteringen.

    Gebruikerservaring is een breder gebied dan bruikbaarheid, maar ik denk dat de bovenstaande workflow effectief kan worden toegepast.

    Andrew Wright komt met een iets andere managementworkflow in zijn UX Debt-presentatie en hij beveelt een 4-stappenplan aan om met UX-schuld om te gaan.

    1. Bepalen als en waar UX-schuld bestaat.
    2. Vergelijken ernst van belang.
    3. Maak tijd om het te repareren.
    4. Socialiseren het concept.

    Omgaan met opzettelijke en onbedoelde UX-schuld vereist ook verschillende technieken. Snelkoppelingen die we opzettelijk maken en goede ideeën die tijdens het proces verloren gaan, kunnen worden beheerd door notities maken, taak beheer, of volgen van problemen apps.

    Onbedoelde UX-schuld kan min of meer worden overwonnen door regelmatig te rennen gebruikerstests, vragen om klanten feedback, of met behulp van geavanceerde technieken zoals A / B-testen om de impact van verschillende ontwerpen te zien.

    Toepassen principes van iteratief ontwerp kan ook nuttig zijn; we kunnen onze UX schuldmanagementstappen in elke iteratie inbouwen om accumulatie te voorkomen.

    IMAGE: Wikipedia - Iteratieve en incrementele ontwikkeling

    UX-schuldbeheer moet passen in onze bredere workflow, met de kenmerken van ons team, onze doelen en de aard van ons product, maar er zijn er een paar universele dingen dat wordt aangeraden om in alle gevallen te volgen.

    1. We moeten communiceren in ons team waarom we moeten omgaan met UX-schulden, wat zijn onze doelen, en hoe we willen bereiken hen.
    2. We moeten tools vinden voor volg opzettelijke UX-schuld.
    3. We moeten manieren vinden om ons product te testen en feedback krijgen van onze gebruikers vang onbedoelde UX-schuld.
    4. We moeten organiseren en prioriteren onze problemen.
    5. We moeten maatregel de resultaten van ons werk, zoals we altijd moeten doen aanpassen UX-schuldbeheer aan onze veranderende behoeften.

    Laatste woorden

    Om kwaliteitsproducten te creëren, moeten we niet alleen innovatief zijn, maar ook aandacht besteden aan dingen die op het eerste gezicht niet zo voor de hand liggen, een daarvan is het herkennen en effectief beheren van UX-schulden. Het is waarschijnlijk niet de meest interessante taak, maar het is van cruciaal belang, want na verloop van tijd kan UX-schuld een serieuze bedreiging vormen voor het succes van ons werk..

    Als we UX-schuld inplakken beheersbare brokken, en integreer de gerelateerde taken in onze workflow, we hoeven niet te veel tegelijk te doen, we kunnen onaangename verrassingen vermijden en de kwaliteit van een product op een comfortabele manier behouden of verbeteren.