Fyra testförhållanden. Testa UX-prototyper som en nödvändig del av produktutvecklingen

En prototyp för användarupplevelsen är en hypotes, ett designalternativ som du betraktar som möjlig lösning Problem. Det enklaste sättet att testa en hypotes är att titta på hur vanliga användare kommer att arbeta med den. Det finns olika klassificeringar av prototyper:

• en ensidig webbplats, eller en flersidig webbplats med ett tillräckligt antal menyer och skärmar med vilka användaren utför sina uppgifter;
• en realistisk och detaljerad prototyp eller en schematisk som finns som en skiss på papper;
• interaktiv (klickbar) eller statisk (datorns handlingar imiteras av en person).

Valet av ett eller annat alternativ beror på testmålen, designens fullständighet, verktygen som används för att skapa prototypen och resurserna för support före och under användbarhetstestning. Men oavsett vilken prototyp du använder, kommer testning av den att berätta mycket om effektiviteten av användarupplevelsen, kvaliteten på publikens interaktion med gränssnittet och gör att du kan göra nödvändiga justeringar.

Varför testa en prototyp?

Att korrigera koden för en färdig produkt eller webbplats är dyrt, men att byta en prototyp är mycket billigare, särskilt om den är avbildad på ett papper. Men följande argument ges ofta mot att testa prototyper:

• den slutliga versionen av designen är att föredra för testning eftersom den representerar fungerande system, och användare som interagerar med det kommer att känna sig mycket mer naturliga och lugnare, vilket innebär att testresultaten blir mer tillförlitliga;
• vissa anhängare av Lean Startup-konceptet noterar att utan att testa en prototyp kommer det inte att finnas något behov av att bli av med den om den inte klarar testerna, vilket innebär att det inte kommer att tillkomma några extra kostnader;
• brist på anpassning i en agil eller vattenfallsutvecklingsmodell vid anpassning av UX och iterativ design.

Dessa argument verkar övertygande endast vid första anblicken. Men att överge produkttestning tills slutskedet är ganska riskabelt. Erfarna utvecklare kommer att ta sig tid att prototypa en produkt, testa den och förfina den till ett optimalt tillstånd. Samtidigt är det också obligatoriskt att testa produkten i slutskedet: att bedöma användbarhet, lönsamhet, genomföra konkurrensanalys och slutkontrollera projektet.

Interaktiva och statiska prototyper

Alla prototyper måste svara på användaråtgärder. Du kan spendera mycket tid, men ändå implementera interaktiva element innan du startar tester, eller helt enkelt imitera systemets svar. Båda metoderna har fördelar och nackdelar.

Interaktiva (klickbara) prototyper

När designern väljer en interaktiv prototyp måste konstruktören fastställa systemets svar på alla möjliga användaråtgärder innan testning. Även om alla är där nödvändiga verktyg det kommer att ta mycket tid.

Statiska prototyper

Här simuleras systemets svar på användaråtgärder av en person som är bekant med designen. Det finns flera simuleringsmetoder som är användbara i statiska prototyper:

1. "Trollkarlen från Oz"

Metoden är uppkallad efter den populära boken av Frank Baum. I arbetet, som du minns, visade sig trollkarlen vara en vanlig person. I upplevelsen kan en "trollkarl" (spelad av en designer som är väl bekant med prototypen) fjärrstyra deltagarens skärm från ett annat rum. Inget av användarens klick betyder egentligen någonting. När en person vidtar en åtgärd bestämmer en "trollkarl" bakom väggen vad som ska hända härnäst och gör ändringar på användarens skärm. I det här fallet är källan till förändringar och systemsvar okänd för försökspersonerna. Och som regel är de indignerade över att systemet hela tiden saktar ner och tar lång tid att svara.

Denna metod är användbar när man testar system baserade på artificiell intelligens- innan dess implementering, eftersom "trollkarlen" som kontrollerar datorn imiterar AI-reaktioner baserade på naturlig intelligens.

2. Pappersdatorprototyp

Designen är skapad på papper. En person som är bekant med layouten spelar rollen som datorn och lägger pappren på bordet nära användaren, men inte i hans synfält. Så snart användaren rör papprets "skärm" som ligger framför honom med fingret väljer "datorn" rätt sida och placerar den framför användaren.

3. Stjäla-musen

En version av The Wizard of Oz, där "trollkarlen" sitter i samma rum som användaren (rollen som "trollkarlen" kan spelas av värden). Prototypen visas för användaren på en datorskärm. Så fort deltagaren klickar ber presentatören honom att vända sig bort medan han gör ändringar på skärmen. Personen fortsätter sedan att arbeta med prototypen.

1. "Datorn" måste meddela slutförandet av varje operation så att användaren fortsätter att interagera med systemet. Med denna signal kan du välja en speciell gest eller en ikon tryckt på papper (till exempel ett timglas), som visas varje gång "datorn" väljer det mest lämpliga svaret för situationen och försvinner när operationen är klar.

2. Presentatören bör avstå från att kommentera eller förklara designen för användaren.

För att avgöra vilken prototyp som passar dig bäst, svara på följande frågor:

• Har du tid och nödvändig kompetens för att implementera svar på allt i systemet? möjliga åtgärder användare?
• Har du tid att genomföra pilottester och fixa eventuella buggar som hittats?
• kan du säga att din design är komplett och att du inte behöver göra ändringar mellan sessionerna?
• Är det möjligt för en designer att spela rollen som en dator i alla tester som utförs?
• att flytta från en skärm till en annan är viktig del forskning?
• Är användarnas reaktion på dynamiska förändringar en viktig del av testning?

Om de flesta svaren är ja, prova det klickbara alternativet om inte, då duger det statiska alternativet.

Prototyper kan vara korrekta eller felaktiga. En prototyps trohet hänvisar till hur nära den matchar systemets slutliga design. Modellen kan vara korrekt när det gäller interaktivitet, utseende, innehåll och hantering.

Prototypen kan ha hög eller låg kvalitet för alla eller några av de listade komponenterna. Den höga och låga noggrannheten hos dessa element förklaras nedan:

Fördelarna med högtrohetsprototyper

1. Prototyper som är korrekta vad gäller interaktivitet visar högre respons i tester. Att hitta rätt skärm eller svar på en användares åtgärd kan ofta ta en person som spelar rollen som en dator. Extra tid. Förseningar som är för långa mellan användarens handling och "datorns" reaktion stör den smidiga interaktionen med gränssnittet och distraherar deltagaren från senaste händelsen och förväntad systemrespons.

Förseningen ger dig också extra tid att studera sidan. Därför, när de arbetar med en långsam prototyp, täcker deltagare i användarvänlighetstestet fler detaljer och innehåll än när de arbetar med det verkliga systemet. Naturligtvis introducerar detta en viss förvrängning i slutresultatet. Du kan minska den negativa effekten av förseningar genom att be användaren titta bort eller placera ett tomt vitt ark framför honom i väntan på ett svar från systemet.

Så snart som ny skärm kommer att vara redo bör du visa föregående skärm i några sekunder så att användaren uppdaterar sitt minne av sina tidigare handlingar och först då visa den nya. Experimentets ledare kan också ge all möjlig hjälp och muntligt påpeka för användaren hans tidigare handlingar. Till exempel genom att fråga: "Här klickade du på länken "Om företaget."

2. Om prototypen ligger nära systemets slutliga form vad gäller interaktivitet eller dess visuella sida kan du testa arbetsflöden och specifika komponenter användargränssnitt(t.ex. megamenyer, rullgardinsmenyer), t.ex grafiska element, såsom ("självklarhet" i design), sidhierarki, teckensnittsläsbarhet, bildkvalitet och till och med graden av engagemang.

3. High-fidelity-prototyper uppfattas som fungerande versioner av program och webbplatser. Detta innebär att deltagarna i experimentet kommer att bete sig mer realistiskt, som om de interagerar med detta system. Och en skissartad prototyp kan skapa oklara förväntningar om systemets kapacitet. Som ett resultat upphör användarbeteendet att vara helt naturligt.

4. Prototyper som är korrekta när det gäller interaktivitet frigör dig från behovet av att imitera systemets funktion och låter dig fokusera på experimentets framsteg.

5. Det är mindre risk för fel när man testar interaktiva prototyper. Att imitera driften av ett system är en ansvarsfull uppgift, och det ligger i människans natur att göra misstag. Brådska, stress, nervös spänning, behovet av att noggrant övervaka användarens klick - allt detta kommer att få "datorn" att fungera ologiskt och förvränga testresultaten.

Fördelar med Low Fidelity-prototyper

1. Mindre tid att förbereda en statisk prototyp, mer tid att arbeta med designen innan experiment påbörjas

Att skapa en klickbar prototyp tar tid. Men det skulle vara klokare att spendera det på att skapa fler sidor, menyer eller innehåll. (Du måste fortfarande ordna sidorna i rätt ordning för att säkerställa normalt arbete"dator", men detta tar vanligtvis mycket kortare tid än att skapa en interaktiv prototyp).

2. Det är lättare att justera designen under experimentet

Designern kan skissa upp en snabb plan för förändringar och göra dem mellan testtillfällena, utan att slösa tid på anpassning och kommunikation av nya element med befintligt system, som med en interaktiv prototyp.

3. Felaktiga prototyper sätter inte press på användarna

Om en design verkar oavslutad kommer användarna inte att undra om det tog en månad eller ett par dagar att utveckla den. De kommer att vara övertygade om att du verkligen testar systemet och inte deltagarna själva, de kommer inte att känna sig skyldiga att slutföra alla uppgifter och kommer att vara mer villiga att visa negativa känslor.

4. Designers behandlar prototyper utan bävan.

Att göra justeringar av ett färdigt system, interaktivt och inte utan estetik, är inte alltid trevligt. När du väl investerar tid och kraft i en design är det mycket svårare att överge den, även om den inte fungerar tillfredsställande. Designen, som finns i form av en skiss på papper, justeras utan onödigt prat eller sentimentalitet.

5. Investerare och andra intresserade stör dig inte

När människor ser en rå prototyp, förväntar de sig inte att få en färdig produkt nästa dag. Varje medlem i utvecklingsteamet kommer att vara förberedd på eventuella förändringar av projektet innan det slutförs.

Användarinteraktion under testning av valfri prototyp

När man testar en prototyp kommunicerar presentatören som regel med deltagarna mycket mer än under testning färdigt system. Detta händer främst av följande skäl:

• presentatören måste förklara prototypens natur (men inte hur designen fungerar);
• ibland behöver presentatören förklara systemets nuvarande tillstånd (till exempel "Den här sidan fungerar inte ännu") eller fråga "Vad förväntade du dig att hända?";
• Det händer att presentatören behöver ta reda på varför deltagaren i experimentet slutade fungera: för att han väntade på svar eller för att han trodde att han hade slutfört uppgiften.

Även om handledaren kan behöva interagera med testdeltagaren då och då, är hans främsta mål att lugnt observera personen som arbetar med designen, snarare än att prata med honom.

1. Om användaren klickar på ett element för vilket ett motsvarande svar ännu inte har utformats:

• säga: "Detta element fungerar inte";
• fråga: "Vad förväntade du dig att hända?";
• be användaren att klicka på nästa element.

Till exempel: "Du klickade på länken "kompakta bilar." Tyvärr har vi ännu inte förberett motsvarande skärm. Prova att välja kategorin "medelstora bilar". Efter att användaren har valt det här alternativet, försök att prata så lite som möjligt, förbli likgiltig.

2. Om användaren öppnas efter att ha klickat fel sida, måste "datorn" ta bort den från deltagarens vy så snabbt som möjligt, och ladda föregående sida istället. Presentatören måste omedelbart rapportera att fel sida har öppnats och sedan muntligt tala ut deltagarens handlingar på nuvarande sida. Först då visar "datorn" rätt sida.

Datorfel förvränger data

Observera att felaktigheter som görs av "datorn" kan ha en betydande inverkan på testresultaten. När skärmen väl dyker upp bildar användarna sig en mental modell av hur systemet och forskningsmetoden fungerar. Om fel sida visas, anta inte att användare omedelbart kommer att radera det de såg från sitt minne.

Även om du rullar tillbaka processen och försöker förklara felet kommer deltagarna att dra slutsatsen att den felaktiga skärmen fortfarande på något sätt är relaterad till uppgiften och kommer att lära sig ännu mer användbar information från dina förklaringar, som sedan kommer att påverka deras val och beteende. Att visa fel sida bryter också flödet och förvirrar användare. De kan besluta att prototypen är felaktig. Detta kommer att påverka förväntningarna, förtroendet för forskningsmetoden och förmågan att bilda en sammanhängande mental modell.

Eftersom den datorfel påverka studien negativt, ta dig tid att genomföra ett pilottest och korrigera eventuella felaktigheter innan du kör huvudtesterna.

Slutsats

Det är omöjligt att vägra prototyptester. Din design kommer att testas på ett eller annat sätt, oavsett om du gillar det eller inte. När systemet väl är igång och folk kan använda det kommer de att testa det. Och istället för den nödvändiga informationen om kvaliteten på användarupplevelsen och gränssnittet får du: dåliga recensioner och förlorad försäljning, övergivna beställningar, returer, bristande förståelse för innehåll och produkter, samtal till support, ökade utbildningskostnader, försämrad image.

Och du måste rätta till dessa fel, som naturligtvis kommer att bli otroligt dyra. Därför är testning av prototyper – interaktiva eller ritade på papper – ett obligatoriskt steg för att komma in på marknaden.

Hallå!

CSS verkar enkelt och okomplicerat så länge du inte behöver göra något anpassat. Här är en annan titt på CSS-problem. Detta är en översättning av artikeln "5 Most Annoying Things with CSS".

1996 stödde stora webbläsare endast delvis CSS, och på grund av detta tvingades webbdesigners komma med ett gäng hacks och lösningar för att få deras stilar att fungera som de ville. Det var faktiskt inte förrän 1999 som varje webbläsare äntligen började stödja CSS1 fullt ut. IE 5.0 för Macintosh, som släpptes i mars 2000, blev den första webbläsaren som fick fullt stöd för CSS1-specifikationen. CSS2 släpptes 1999, men designers var tveksamma till att använda den i stor utsträckning på grund av ofullständigt webbläsarstöd för standarden.

CSS3 började utvecklas 1998 och var under utveckling fram till 2009. Den innehöll massor av välkomna tillägg som rundade hörn, skuggor, gradienter, övergångar och animationer, såväl som nya layoutfunktioner som flerkolumnlayouter, flexbox och rutnät.

Som tur är, förutom W3C:s ansträngningar att förbättra specifikationen för att möta utvecklarnas behov, har communityn själva utvecklat många lösningar för att förbättra och förenkla arbetet med CSS i en komplex miljö. SASS, Stylus, LESS introducerade loopar, mixins och funktioner. Genomförande CSS-variabler förenklat skrivning av komplexa stilar, förbättrad läsbarhet och förenklat underhåll.

CSS är definitivt stor förbättring gammal bra HTML, men CSS-begränsningarär ibland överväldigande, och bristen på branschstöd har hållit designers tillbaka i många år. Därför har CSS ännu inte hittat sin plats i utvecklarnas hjärtan.

Än idag kallar du dig själv en "fullstack-utvecklare" eller " front-end utvecklare", med ett år eller åtta års erfarenhet kommer du fortfarande att stöta på en situation där CSS kommer att få dig att svettas.

Jag kommer att lista några större CSS-problem:

CSS handlar om uppmärkning, inte design

Designers bör lägga mer tid på att skapa fantastiska mönster och mindre tid på att pilla med märkning och problem med webbläsarkompatibilitet. När jag säger "markup-centrerad" menar jag att varje CSS-designverktyg tvingar dig att gå in källa att skapa bra design. Verktyg för designers bör vara designfokuserade. CSS är dåligt eftersom det tvingar designers att tänka på hur de ska implementera sin design tekniskt, snarare än ur ett designperspektiv.

Webbläsarkrig

Du har skapat en fantastisk layout för din nya webbplats. Men att förvandla den vackra Photoshop-mockupen till pixelperfekt layout är en utmaning. Problemet är inte att du inte förstår hur man kodar det. Problemet är mest det olika webbläsare tolka din uppmärkning annorlunda, även om du använder fullt giltig CSS. Det är väldigt demotiverande när man fixar en bugg i en webbläsare, och därigenom lägger till en ny bugg i en annan.

• Använd alltid Normalize.css. Det tvingar webbläsare att rendera alla element mer förutsägbart och i enlighet med moderna standarder. Det påverkar just bara de element som behöver normaliseras.
• Du kan använda ramverk som Bootstrap, Bulma och Materialize. För det mesta är de mycket kompatibla med de flesta webbläsare.
• Använd CSS3-kodgeneratorer. De hjälper utvecklare att skriva kod över webbläsare för olika CSS3-egenskaper. De ger utvecklare breda anpassningsmöjligheter, inklusive kant-radie, text-skugga, RGBa, boxstorlek. En av tjänsterna är CSS3 Generator.
• Validering: W3C Validation Service validerar olika versioner XHTML och HTML, utmatning en massa viktiga misstag och inlägg för att hjälpa utvecklare att bygga fantastiska webbplatser. W3C Validator: http://validator.w3.org
• W3C Css Validator: http://jigsaw.w3.org/css-validator
• Testning: eftersom det är nästan omöjligt att testa webbplatsen manuellt i alla möjliga webbläsare Och operativsystem, testverktyg över webbläsare kommer till undsättning! Du kan använda Browsershots, BrowserStack, Cross Browser Testing och liknande tjänster för att testa.

responsiv layout

Med mångas tillkomst olika enheter dök upp olika upplösningar och skärmstorlekar och olika orienteringar. Nya enheter med nya skärmstorlekar dyker upp varje dag, och varje enhet har en viss variation i storlek och funktionalitet. Några av dem har stående format, vissa är liggande, och ibland kan de vara till och med fyrkantiga. Dessutom, titta på populariteten för iPhone, iPad och andra moderna smartphones, vi förstår att användaren kan ändra skärmorienteringen när han vill. Hur ska man agera i en sådan situation ur designsynpunkt?

Förutom orientering måste vi också ta hänsyn till tusentals olika storlekar skärm. Många användare utökar inte webbläsaren till helskärm, och detta bidrar också.

• Ge prioritet viktigt innehåll och dölj oviktiga detaljer på små skärmar. Jag tror att det viktigaste är att visa det viktigaste små skärmar. Ibland är det omöjligt att radera visst innehåll på mobiltelefoner, då är det värt att överväga möjligheten att dölja det.
• Använd SVG. Till skillnad från traditionella bilder som PNG eller JPEG, skalas SVG enkelt utan att förlora kvalitet. Dessutom, de ofta mindre i storlek, så att du kommer att förbättra din sajts laddningshastighet lite.
• När det kommer till användarinteraktion, fokusera på att tillhandahålla tillräckligt stora kontroller (ingångar, knappar, radioknappar).
• För smartphones, om möjligt, gör knappar minst 44px, som rekommenderas i iOS Human Guidelines
• Testa designen med minst fem användare som använder sina vanliga enheter.
• Använd ramverk som Bootstrap. Med dem, skapa något som passar för Mobil enheter sajten blir mycket enklare. Att använda färdiga klasser från Bootstrap hjälper dig att bestämma rutnätet och innehållsplaceringen.

Gör rött mer blått

Många kunder kommer med konstiga krav, höga förväntningar, önskad funktionalitet som aldrig diskuteras. Som ett resultat slutar vi med oändliga redigeringar och otaliga iterationer. Kunder ändrar sina önskemål varje sekund, speciellt när det kommer till design. Att tvingas ge efter för en kunds alla infall känns som dålig behandling eller en förolämpning mot designers. Det är därför sajter som Clients From Hell är populära.

• Skapa animerade prototyper - ett bra alternativ visa dina idéer. Använd program som Adobe XD, Sketch, InVision och så vidare. Starta utvecklingen först efter att designen har överenskommits.
• Det är klokt att planera hela utvecklingsprocessen redan från början. Troligtvis kommer du att behöva lägga till tid för olika överraskningar i processen. Kom ihåg Murphys lag: "Det som kan gå fel, kommer att gå fel."
• Håll dig lugn. Låt inte dina känslor ta över dig. Kom bara ihåg att kunden inte gick på konstskola och kanske inte inser att röd text på grön bakgrund inte förbättrar läsbarheten. Förklara dina beslut angående visuell hierarki, typografi och allt annat som kan påverkas av ändringar.
• Kom ihåg att webbplatsen är till för din kund, och ditt mål är att göra kunden nöjd med webbplatsen. Det bästa du kan göra är att ge dina rekommendationer för ändringar. Om du inte håller med, gör bara ditt bästa för att webbplatsen ska se så bra ut som möjligt.

CSS är underskattat

CSS är frustrerande för det mesta helt enkelt för att ingen verkligen vill ta sig tid att lära sig det. Många människor, särskilt programmerare, underskattar det och försöker göra något utan att åtminstone vilja förstå mekaniken i det. Och de fastnar alltid för samma problem.

Jag har arbetat med några fantastiska backend-ingenjörer som kände till varje OOP-mönster i boken, men som fastnade för positionering och flytningar och trodde att responsiv CSS var någon sorts svart magi. Så jag tycker att den här komiken är väldigt korrekt.

Folk förväntar sig att CSS ska vara enkel och okomplicerad, men som de flesta saker tar det lite tid.

Som jag sa i min tidigare artikel "Felsökning av CSS", att arbeta med CSS och få bra resultat Det finns två stora skillnader från att arbeta med CSS. CSS är lätt att komma igång med, men behärskning kräver ansträngning. Detta är något som tar en minut att lära känna och en livstid (med överdrift) att bemästra.

Att ta ett fungerande system som ett kriterium (eftersom det är slutresultat alla tidigare utvecklingsprocesser), kan du sätta prototypen, prototypen och simulatorn i olika arbetsförhållanden. Om vi ​​utvärderar likheten med ett fungerande system, så liknar modellen mindre än simulatorn. En prototyp är mycket närmare en simulator än en mock-up. Sett till antalet enheter i dessa system består layouten vanligtvis av endast en enhet, även om den kan passa hela systemet; prototypen avbildar hela systemet på exakt samma sätt som simulatorn (när det gäller simulatorn är det denna enhet som tillhandahålls den mänskliga operatören som ett gränssnitt till maskinen). Om vi ​​talar om antalet åtgärder med utrustning eller aspekter av systemunderhåll av personal, så kan färre kontroller utföras med en mock-up, fler med en systemsimulator och dess prototyp (dock naturligtvis inte lika många som med ett riktigt system).

För elektronisk utrustning är breadboards mycket enklare än simulatorer, men om du lägger till valfri utrustning(mikrodator, programvara, kontroll- och visningsblock, etc.), kommer layouten i slutändan att förvandlas till en simulator.

Testning av layouten utförs i händelse av att IChF beslutar att det är nödvändigt, eftersom kontroller vanligtvis inte tillhandahålls i detta utvecklingsstadium. RF-prototyper regleras av anvisningar från försvarsministeriet. Precis som med mock-up-testning beror processerna för att mäta prestandan hos simulatorn och det körande systemet på speciella omständigheter (såsom testkrav). denna modifiering system); Ibland utförs dessa mätningar i forskningssyfte (till exempel för att bekräfta möjligheten att använda simulatorn för personalutbildning).

En simulator är en fysisk enhet som återger de egenskaper hos verklig utrustning som är relaterade till gränssnittet människa-maskin. Det är nödvändigt att skilja mellan simuleringssystem och datormodeller, som i huvudsak är konceptuella. Förutom att bedöma träningssimulatorns effektivitet föredrar ICHF vanligtvis att använda verkliga systemet, och en simulator i följande fall: 1) det är inte möjligt att utföra mätningar med ett fungerande system; 2) det är nödvändigt att ändra systemets parametrar för att utföra en experimentell jämförelse, och parametrarna för det nuvarande systemet kan inte ändras för detta ändamål; 3) kontrollera nödsituationer, vilket är för farligt för riktig utrustning.

Dessutom har mätningar med hjälp av en simulator vissa fördelar, nämligen möjligheten att 1) ​​starta och stoppa det simulerade systemet vid valfri rätt ögonblick, 2) fixa ett visst skede av systemets funktion och undersök det mer noggrant, 3) ändra driftläge och 4) tillhandahålla automatisk registrering data.

Å andra sidan finns det ett antal nackdelar: 1) med en simulator är det omöjligt att reproducera full cykel systemdrift (naturligtvis relaterar detta till driftprocessen); 2) kvaliteten på modelleringen kan vara lägre än önskat; 3) den personal som testas har vanligtvis inte samma kompetens som operativ personal; 4) vid modellering av ett system kan endast träningsscenarier som inte helt återspeglar alla driftsförhållanden spelas; 5) den tid under vilken IChF kan erhålla en simulator enbart för mätningar kan vara begränsad.

De återstående testsituationerna har bara sina egna inneboende nackdelar. Eftersom operativsystemet ingår i den externa miljön är det ibland möjligt yttre påverkan på den, vilket minskar forskningens renhet (till exempel vid avbrott orsakade av kommandon med högre prioritet). Detta är orsaken till många kända fall av kontrollfel under verklig drift. Det kan hända att förutsättningarna för RI prototypsystem kommer inte att vara helt nöjd, till exempel i fallet med stabila hårdvarukonfigurationer (både utrustning och procedurer); På grund av ständiga utvecklingssvårigheter kan utrustningen som testas misslyckas oftare än under verkliga förhållanden. Designen är så begränsad i sin förmåga att presentera stimuli och motsvarande svar från personal att noggrann extrapolering krävs vid analys av testresultat.

Huvudmålen för att bedöma systemens effektivitet kan vara följande: 1) kontrollera om personalen kan lösa de uppgifter de står inför utan betydande fel eller överbelastning; 2) kontrollera om kontrollprocedurer och andra egenskaper hos utrustningen och systemet utgör oöverstigliga hinder för effektivt arbete personal och om dessa egenskaper uppfyller kriterierna för ingenjörspsykologi; 3) bestämma inverkan på personalens arbete av vissa kraftigt olika variabler som är direkt relaterade till syftet med utrustningen och hela systemet (till exempel operationer som utförs under dagen och operationer som utförs på natten); 4) fastställa ur beteendesynpunkt lämpligheten av en viss modifiering i arbetet, utrustningen, hela systemet eller dess syfte, såväl som lämpligheten av en viss konstruktiv lösning på problemet; 5) genom att bedöma personalens arbete under systemets driftsförhållanden, avgöra om detta arbete är tillräckligt, och om inte, ta reda på vilka faktorer som orsakar en minskning av arbetseffektiviteten.

Ju mer komplett systemet som testas är och ju närmare dess driftsförhållanden är verkliga, desto mer fullständigt uppnås testmålen.

Det är därför det är möjligt att uppnå endast en delmängd av testmål med hjälp av en statisk mock (den vanligaste typen av mock). Detta innebär att det är möjligt att få deldata som inte helt uppfyller testmålen. Låt oss till exempel säga att vi har en statisk mockup av en jaktplanscockpit. Sedan, med dess hjälp, konstateras att kontrollerna är åtkomliga och instrumentavläsningarna avläses, vilket krävs för att flygplanet ska fungera effektivt. Detta är dock endast ett partiellt test (endast ur antropometrisk synvinkel) för att fastställa att personalen kan utföra sina uppgifter. En simulator krävs också minst för att kontrollera om piloten reagerar tillräckligt snabbt på förändringar i miljön.

Testuppgifterna som beskrivs ovan gäller både verkliga system och systemutvecklingsprocessen. När systemet skapas upptäcks nya egenskaper, baserat på vilka utrustning och procedurer modifieras. Testning är nödvändig för att avgöra om dessa ändringar är genomförbara. Systemet måste testas om under drift eftersom testning inte kan ge information om hur väl det uppfyller sitt avsedda syfte; till exempel är militära system inte programmerade att verka i en stridsmiljö förrän stridsoperationer börjar. Provning av stridssystem kan utföras i krigsspel, till exempel när två infanteriförband tävlar med stöd i form av stridsvagnar, artilleri och flygplan. Om avbrott uppstår i driften av systemet är det nödvändigt att undersöka parametrarna för problemet. Eller så bör FSI fastställa effekten av potentiellt viktiga interna variabler (till exempel skiftrotation) på prestandan. Ibland utförs RI- och simulatortester helt enkelt för att samla in forskningsdata.
Att bedöma effektiviteten av ett system (SI) har egenskaper som har liten koppling till funktionerna i traditionell forskning i ett kontrollerat experimentläge (till exempel under laboratorieförhållanden): 1) orientering mot verkliga uppgifter, men med närvaro av störningar: 2 ) tids- och resursbegränsningar; 3) mätningar görs i makroenheter snarare än mikroenheter (minuter snarare än sekunder); 4) både utrustning och personal utvärderas; 5) ett systematiskt tillvägagångssätt används; 6) kännetecknas av hög validitet; 7) det finns färre alternativ för testhantering; 8) flera mål och flera kriterier (både mellanliggande och slutliga); 9) förekomsten av många nivåer av inträde i testprocessen och/eller i systemet.

Termen "bedömning av systemprestanda" betyder att FSI mäter personalens prestationsegenskaper. Egenskapstestning (som består av att erhålla subjektiva bedömningar av egenskaperna hos ett system, utrustning och drift i motsats till prestanda hos personal som interagerar med dessa egenskaper) är inte en prestationsbedömning. Den vanligaste typen av testning baserad på egenskaper är att bedöma lämpligheten hos utrustningens tekniska och psykologiska egenskaper. Geer skiljde mellan informella och formella I- och E-procedurer, där den förra hänförde sig till attributtestning (utvärdering av prestandan hos en hårdvarudesign, representerad antingen av ritningar eller en icke-fungerande mock-up eller utrustning) och den senare relaterade till prestandamätning. Att utvärdera utrustningens prestanda är ibland en del av prestandatestningsprocessen och tas därför också upp här. Ovanstående gäller även subjektiva mätverktyg som intervjuer, enkäter och rankningar, som används för att få information om prestation, även om de inte kan användas för att direkt mäta prestation.