Användbarhet är inte något du bara kan laga i någon fas av designen, men måste utvecklas och förfinas under hela processen. Om du vill ha den bästa slutprodukten måste du förutse verkliga användarscenarier från prototypfasen. Användbarhetstestning bör vara den sista platsen för att börja tänka på användbarhet.
Varför oroa dig för användbarhetsprovning så tidigt i processen när prototyper redan har en stor noggrann att göra-lista? Eftersom inte din prototyp är användbar, kommer alla dina test att berätta för dig att folk inte gillar fruktansvärda produkter.
om inte din prototyp är användbar, kommer alla dina test att berätta för dig att människor inte gillar fruktansvärda produkter
Det säger nästan självklart, men du designar produkten som används av riktiga människor. För att förbereda det för riktiga människor borde det testas på riktiga människor. Prototyper är byggda för experiment, så det är bara meningsfullt att testa dem på riktiga användare.
Med det i åtanke, låt oss se hur du håller användbarheten i åtanke när du bygger prototypen, hur man testar användbarheten innan du har en prototyp och tips för testning med prototyper ...
Användbarhetsprov före prototypen
Användbarhetsprovning behöver inte startas med prototypning - i själva verket om du har resurser att börja tidigare, borde du. Medan de flesta är konceptuella kan dessa tester hitta det bästa sättet att strukturera din prototyps navigations- och informationsarkitektur. De vanligaste före prototyperna tester inkluderar:
- Kortsortering: enkelt och stadigt, detta test avslöjar hur användarna föredrar produktens informationsarkitektur. Alla element i din produkt är skrivna på kort, och provtagarna ombeds organisera dem enligt fördefinierade kategorier ("stängda") eller under de som de har tänkt upp ("öppna"). För detaljer, se Donna Spencer s Kortsortering: En slutgiltig guide.
- Trädtestning: "systertestet" för kortsortering, utvärdering av träd utvärderar effektiviteten av befintliga informationsarkitekturer. Användare får en grundläggande, avkortad karta över webbplatsen / app / etc. och bad om att klicka igenom för att slutföra vissa uppgifter. Testet övervakar om de väljer rätt väg, och om inte, vad har de förlorat. Grundare av MeasuringU Jeff Sauro förklarar detaljerna.
- Intervjuer: Ibland är det bästa sättet att förstå dina användare att bara fråga. Det låter enkelt nog, men nyanser och strategier för användarintervjuer är oändliga. Kate Lawrence, UX Forskare vid EBSCO Publishing ger några tips om hur man kör dessa specifikt för användbarhetstestning.
Åtgärda problem tidigare är alltid bättre, och dessa preliminära tester kommer att säkerställa att den konceptuella grunden för prototypen är i god form innan en enda linje dras.
De rätta användarna och de rätta uppgifterna
Medan användbarhetstesterna är alla olika behöver de alla användare, och de flesta involverar uppgifter. Eftersom dessa två element är framträdande vid all användbarhetstestning, förklarar vi kortfattat hur man bäst ska hantera båda.
- Rekrytera användare: Efter allt arbete med personas, borde du nu ha en klar uppfattning om dina målanvändare. Det bidrar också till att segmentera dina användare baserat på beteende. Faktum är att du inte bör besatt över demografi. Den största differentiatorn kommer sannolikt att vara om användarna har tidigare erfarenhet eller är kunniga om domänen eller industrin - inte kön, ålder eller geografi.
Att veta vem du ska rekrytera är bara det första steget. Den mer inblandade delen är att hitta och rekrytera dem. Jeff Sauro skisserar de 7 bästa sätten att hitta de ideala användarna för din testning. - Skrivningsuppgifter: uppgifter bestämmer vad användaren faktiskt gör under testet och bestämmer därför vilka användbarhetsfaktorer som undersöks. Tingting Zhao, användbarhetsspecialist för Ubuntu , beskriver några skillnader att komma ihåg vid utformningen av en uppgift. Det finns två huvudsakliga beslut:
en. Direkt kontra scenariot: En direkt uppgift är en strängt instruktionell (t.ex. "Sök på webbplatsen för ett Tandoori-kycklingrecept") medan en scenariot uppgift kommer med sammanhang ("Du är värd för en middagsfest för några gamla vänner, och du behöver ett Tandoori kycklingrecept "). Direkta uppgifter fungerar bäst om du testar tekniska data, medan scenarieuppgifter är bättre i alla andra fall.
b. Stängd vs öppen: En sluten uppgift har klart definierade succeskriterier, medan en öppen uppgift kan slutföras på flera sätt. Avslutade uppgifter kontrollerar specifika funktionaliteter, medan öppna uppgifter är bättre för att förstå hur användarnas sinnen fungerar. En avslutad uppgift skulle vara: "Din vän har födelsedag i helgen. Hitta en rolig plats för upp till 15 personer. "En öppen uppgift skulle vara:" Du hörde dina medarbetare prata om iWatch. Du vill lära dig hur det fungerar. "
Allmänna råd för att testa prototypens användbarhet
Med tanke på prototypernas "ofullständiga" natur ... kommer användarna att ha frågor ... som en moderator måste svara på
En av de första frågorna användbarhetstestare frågar är huruvida det ska modereras eller ej. Medan det finns en många bra skäl för unmodererade tester, för prototyptest rekommenderar vi moderering. Med tanke på prototypernas "ofullständiga" karaktär är chansen att användarna kommer att få frågor om gränssnittet som en moderator måste svara på.
Ett annat vanligt misstag vid test är att stoppa eller ändra testet om användaren upplever svårigheter. Eftersom målet med användbarhetsprovning är att hitta och lösa problem, kan denna situation faktiskt göra testet till en framgång. Om användaren t ex avviker på vägar som inte har utvecklats än i prototypen kan du fråga dem varför de gick dit och vad de skulle ha velat göra. Några uppföljningsfrågor om hindren kan ge mer värdefull feedback än en användare med en "perfekt körning".
Olika trovärdigheter för att testa prototyper
Medan vissa tror på att testa tidigt med grova prototyper och andra förespråkar testar högre trovärdighetsprototyper, tror vi att det bästa sättet är att testa vid varje trohet som är möjligt - och så ofta som möjligt. Chris Farnum, Senior Information Architect på Enlighten, förklarar för-och nackdelar av varje typ. Som vi kommer att beskriva nedan är lägre trovärdighetstest bättre för att testa koncept, medan högre trovärdighetstester är mer lämpade för testning av avancerade interaktioner.
Det bästa sättet är att testa vid varje trovärdighet som är möjligt
- Lågt trovärdighet: Lo-fi prototyp användbarhetstester, inklusive pappersprototyper, kan fungera i de tidiga utvecklingsstadierna, men blir opraktiska senare. Lo-fi prototyper uppmuntrar också mer ärlig kritik, eftersom det är omedelbart klart att det bara är ett pågående arbete.
I senare skeden, när användbarhetstesterna kontrollerar avancerade funktioner, slutar lo-fi-prototyper bli till hjälp eftersom du har slagit fast gränsen för trovärdighet. Detta gäller speciellt för pappersprototyper, eftersom du behöver en "mänsklig dator" för att manipulera alla delar, och det kan bli extremt svårt eftersom du lägger till menyer, interaktioner, sidor och element. - Hög trovärdighet: Hi-Fi prototyptestning ger användaren en nära realistisk upplevelse av vad slutprodukten kommer att bli. Hi-fi prototyper är idealiska för att testa komplexa interaktioner och dina lösningar för användbarhetsproblem som upptäckts i tidigare testrunder. Men till skillnad från lo-fi prototyper är dessa billigare att göra.
- Medium trohet: kan inte bestämma mellan hög eller låg trovärdighet? Mid-fi prototyper fungerar bäst när du behöver en balans mellan trohet och kostnad. Om du bara ska köra en runda användbarhetstest, gå medellägenhet.
Fyra innehållsriktlinjer för att testa någon prototyp
När du börjar bygga prototypen är det inte bara acceptabelt att glansa över mindre detaljer i stället för de viktigaste, det rekommenderas ibland. Men när det är dags att testa din prototyp, se till att du har fyllt i några av dessa detaljer som kan bli förbisedda i lägre trovärdighet. Enligt vår erfarenhet är dessa de mest användbara tipsen för att förbereda din prototyp för testning:
- Undvik lorem ipsum: distraherande, förvirrande och saknar mening, lorem ipsum- texten tar inte helt upp din produkts meddelande.
- Använd generiska namn: tester kan vara roligare med dumma eller kändisnamn, men kul är inte meningen. Eventuella distraktioner kommer att förspänna resultaten, så behåll namnen generisk och realistisk.
- Inga platshållare bilder eller ikoner: lådor med X s kan fungera under trådframställning, men inte i testning. Bilder och ikoner spelar en stor roll i UX, så dessa bör genomföras genom att testa tid, även om det bara är med tillfälliga skisser. Undantaget är om dessa bilder är rent dekorativa och inte hjälper till att förstå användargränssnittet.
- Använd realistiska data - Fyll inte data som telefonnummer eller adresser med X s eller skämt - det här är distraherande. Realistiska och trovärdiga data här kommer att ge ditt användartest de mest exakta resultaten.
Testdeltagare kan bli fixerade på detaljer som du trodde var försumbar, så var försiktig med vad du inte säger. Dessa små steg för att minska distraktion och förvirring kan gå långt mot renare testdata.
Utvald bild, användbarhetstestning via genom K2_UX via Flickr.