Prototip experiența utilizatorului- aceasta este o ipoteză, o opțiune de dezvoltare a designului pe care o considerați ca posibila solutie probleme. Cel mai simplu mod de a testa o ipoteză este să te uiți la modul în care utilizatorii obișnuiți vor lucra cu ea. Există diferite clasificări ale prototipurilor:

• un site cu o pagină, sau unul cu mai multe pagini cu un număr suficient de meniuri și ecrane cu care utilizatorul își îndeplinește sarcinile;
• un prototip realist și detaliat sau unul schematic care există ca schiță pe hârtie;
• interactiv (clickable) sau static (acțiunile computerului sunt imitate de o persoană).

Alegerea uneia sau a alteia opțiuni depinde de obiectivele testării, de caracterul complet al designului, de instrumentele utilizate pentru a crea prototipul și de resursele pentru suport înainte și în timpul testării de utilizare. Dar indiferent de prototipul pe care îl utilizați, testarea acestuia vă va spune multe despre eficacitatea experienței utilizatorului, calitatea interacțiunii publicului cu interfața și vă va permite să faceți ajustările necesare.

De ce să testăm un prototip?

Corectarea codului unui produs finit sau al unui site web este costisitoare, dar schimbarea unui prototip este mult mai ieftină, mai ales dacă este înfățișat pe o bucată de hârtie. Dar următoarele argumente sunt adesea date împotriva testării prototipurilor:

• versiunea finală a desenului este de preferat pentru testare deoarece reprezintă sistem de lucru, iar utilizatorii, care interacționează cu acesta, se vor simți mult mai naturali și mai calmi, ceea ce înseamnă că rezultatele testelor vor fi mai fiabile;
• unii susținători ai conceptului Lean Startup notează că, fără a testa un prototip, nu va fi nevoie să scapi de el dacă nu trece testele, ceea ce înseamnă că nu vor exista costuri suplimentare;
• lipsa personalizării într-un model de dezvoltare agil sau cascadă atunci când se aliniază UX și designul iterativ.

Aceste argumente par convingătoare doar la prima vedere. Dar abandonarea testării produselor până la etapa finală este destul de riscantă. Dezvoltatori cu experiență va lua timp să prototipeze produsul, să-l testeze și să-l îmbunătățească până la o stare optimă. În același timp, testarea produsului în etapa finală este, de asemenea, obligatorie: pentru a evalua gradul de utilizare, rentabilitatea, efectuarea unei analize competitive și verificarea finală a proiectului.

Prototipuri interactive și statice

Orice prototip trebuie să răspundă la acțiunile utilizatorului. Puteți petrece mult timp, dar totuși implementați elemente interactive înainte de a începe testele sau pur și simplu imitați răspunsul sistemului. Ambele metode au avantaje și dezavantaje.

Prototipuri interactive (pe care se poate face clic).

Atunci când alege un prototip interactiv, proiectantul va trebui să stabilească răspunsul sistemului la fiecare acțiune posibilă a utilizatorului înainte de testare. Chiar dacă toată lumea este acolo instrumentele necesare va dura mult timp.

Prototipuri statice

Aici, răspunsul sistemului la acțiunile utilizatorului este simulat de o persoană familiarizată cu designul. Există mai multe metode de simulare care sunt utile în prototipurile statice:

1. „Vrăjitorul din Oz”

Metoda poartă numele după populara carte a lui Frank Baum. În lucrare, după cum vă amintiți, vrăjitorul s-a dovedit a fi persoană obișnuită. În experiență, un „vrăjitor” (jucat de un designer care este intim familiarizat cu prototipul) controlează de la distanță ecranul participantului dintr-o altă cameră. Niciunul dintre clicurile utilizatorului nu înseamnă nimic. Când o persoană face o acțiune, un „vrăjitor” din spatele peretelui decide ce ar trebui să se întâmple în continuare și face modificări pe ecranul utilizatorului. În acest caz, sursa modificărilor și răspunsurile sistemului este necunoscută subiecților. Și, de regulă, sunt indignați de faptul că sistemul încetinește constant și durează mult timp să răspundă.

Această metodă este utilă atunci când se testează sisteme bazate pe inteligenţă artificială- înainte de implementarea sa, deoarece „vrăjitorul” care controlează computerul imită reacțiile AI bazate pe inteligența naturală.

2. Prototip de computer de hârtie

Designul este realizat pe hârtie. O persoană familiarizată cu aspectul joacă rolul computerului și pune hârtiile pe masă lângă utilizator, dar nu în raza lui vizuală. De îndată ce utilizatorul atinge „ecranul” de hârtie care se află în fața lui cu degetul, „calculatorul” selectează pagina corectași îl plasează în fața utilizatorului.

3. Fură-Șoarecele

O versiune a Vrăjitorului din Oz, în care „vrăjitorul” stă în aceeași cameră cu utilizatorul (rolul „vrăjitorului” poate fi jucat de gazdă). Prototipul este arătat utilizatorului pe ecranul unui computer. De îndată ce participantul dă clic, prezentatorul îi cere să se întoarcă în timp ce face modificări pe ecran. Persoana continuă apoi să lucreze cu prototipul.

1. „Computerul” trebuie să anunțe finalizarea fiecărei operațiuni, astfel încât utilizatorul să continue să interacționeze cu sistemul. Cu un astfel de semnal, puteți alege un gest special sau o pictogramă imprimată pe hârtie (de exemplu, o clepsidră), care apare de fiecare dată când „calculatorul” selectează cel mai potrivit răspuns la situație și dispare când operațiunea este finalizată.

2. Prezentatorul trebuie să se abțină de la a comenta sau explica designul utilizatorului.

Pentru a determina prototipul care vi se potrivește cel mai bine, răspundeți la următoarele întrebări:

• Aveți timpul și abilitățile necesare pentru a implementa răspunsuri la orice în sistem? acțiuni posibile utilizator?
• aveți timp să efectuați teste pilot și să remediați erorile găsite?
• poți spune că designul tău este complet și nu va trebui să faci modificări între sesiuni?
• Este posibil ca un designer să joace rolul unui computer în toate testele care se desfășoară?
• Este trecerea de la un ecran la altul o parte importantă a cercetării?
• Este răspunsul utilizatorului la schimbările dinamice o parte importantă a testării?

Dacă majoritatea răspunsurilor sunt da, atunci încercați opțiunea pe care se poate face clic, dacă nu, atunci opțiunea statică va funcționa.

Prototipurile pot fi exacte sau inexacte. Precizia unui prototip înseamnă cât de mult se potrivește forma finala sisteme. Model precis poate din punct de vedere al interactivitatii, aspect, conținut și management.

Prototipul poate avea fidelitate mare sau scăzută pentru toate sau unele dintre componentele enumerate. Precizia mare și scăzută a acestor elemente este explicată mai jos:

Beneficiile prototipurilor de înaltă fidelitate

1. Prototipurile care sunt precise în ceea ce privește interactivitatea arată mai mult răspuns ridicat la teste. Adesea caută ecran corect sau răspuns la o acțiune a utilizatorului, poate fi nevoie de o persoană care joacă rolul unui computer timp suplimentar. Întârzierile prea mari între acțiunea utilizatorului și reacția „calculatorului” perturbă interacțiunea lină cu interfața și distrage atenția participantului de la ultimul evenimentși răspunsul așteptat al sistemului.

Întârzierea vă oferă, de asemenea, timp suplimentar pentru a studia pagina. Prin urmare, atunci când lucrează cu un prototip lent, participanții la testul de utilizare acoperă mai multe detalii și conținut decât atunci când lucrează cu sistemul real. Desigur, acest lucru introduce o anumită distorsiune în rezultatele finale. Puteți reduce impactul negativ al întârzierilor cerând utilizatorului să privească în altă parte sau plasând o foaie albă goală în fața lui în timp ce așteptați un răspuns din partea sistemului.

De îndată ce ecran nou va fi gata, ar trebui să afișați ecranul anterior timp de câteva secunde, astfel încât utilizatorul să-și reîmprospătească memoria despre acțiunile sale trecute și abia apoi să-l afișeze pe cel nou. Liderul experimentului poate oferi, de asemenea, toată asistența posibilă, subliniind verbal utilizatorului acțiunile sale din trecut. De exemplu, solicitând: „Aici ați făcut clic pe linkul „Despre companie”.

2. Dacă prototipul este aproape de forma finală a sistemului în ceea ce privește interactivitatea sau latura sa vizuală, puteți testa fluxurile de lucru și componentele specifice interfata utilizator(de exemplu, mega meniuri, meniuri drop-down), cum ar fi elemente grafice, cum ar fi („evidență” în design), ierarhia paginilor, lizibilitatea fontului, calitatea imaginii și chiar gradul de implicare.

3. Prototipurile de înaltă fidelitate sunt percepute ca versiuni funcționale ale programelor și site-urilor web. Aceasta înseamnă că participanții la experiment se vor comporta mai realist, ca și cum ar interacționa cu un sistem real. Iar un prototip incomplet poate crea așteptări neclare cu privire la capacitățile sistemului. Ca urmare, comportamentul utilizatorului încetează să fie complet natural.

4. Prototipurile care sunt precise în ceea ce privește interactivitatea vă eliberează de nevoia de a imita funcționarea sistemului și vă permit să vă concentrați asupra progresului experimentului.

5. Există mai puține șanse de eroare la testarea prototipurilor interactive. Imitarea funcționării unui sistem este o sarcină responsabilă și este natura umană să facă greșeli. Grabă, stres, tensiune nervoasă, necesitatea de a monitoriza îndeaproape clicurile utilizatorului - toate acestea vor face ca „computerul” să funcționeze ilogic și să distorsioneze rezultatele testului.

Beneficiile prototipurilor cu fidelitate scăzută

1. Mai puțin timp pentru pregătirea unui prototip static, mai mult timp pentru a lucra la design înainte de a începe experimentele

Crearea unui prototip pe care se poate face clic necesită timp. Dar este mai înțelept să-l cheltuiți pentru a crea Mai mult pagini, meniuri sau conținut. (Va trebui totuși să aranjați paginile în în ordinea corectă a oferi munca normala„computer”, dar acest lucru durează de obicei mult mai puțin timp decât crearea unui prototip interactiv).

2. Este mai ușor să ajustați designul în timpul experimentului

Proiectantul poate schița un plan rapid de modificări și le poate face între sesiunile de testare, fără a pierde timpul cu adaptarea și comunicarea noilor elemente cu sistem existent, ca și în cazul unui prototip interactiv.

3. Prototipurile inexacte nu pun presiune asupra utilizatorilor

Dacă un design pare neterminat, utilizatorii nu se vor întreba dacă a durat o lună sau câteva zile pentru a-l dezvolta. Ei vor fi convinși că tu chiar testezi sistemul și nu participanții înșiși, nu se vor simți obligați să îndeplinească toate sarcinile și vor fi mai dispuși să arate emoții negative.

4. Designerii tratează prototipurile fără nicio trepidare.

A face ajustări la un sistem gata făcut, interactiv și nu lipsit de estetică, nu este întotdeauna plăcut. Odată ce investești timp și efort într-un design, este mult mai dificil să-l abandonezi, chiar dacă nu funcționează satisfăcător. Designul, care există sub forma unei schițe pe hârtie, este ajustat fără vorbe inutile sau sentimentalism.

5. Investitorii și alte părți interesate nu vă deranjează

Când oamenii văd un prototip brut, nu se așteaptă să primească un produs finit a doua zi. Fiecare membru al echipei de dezvoltare va fi pregătit pentru orice modificare a proiectului înainte de finalizarea acestuia.

Interacțiunea utilizatorului în timpul testării oricărui prototip

Când testează un prototip, facilitatorul comunică de obicei cu participanții mult mai mult decât atunci când testează un sistem terminat. În principal, acest lucru se întâmplă din următoarele motive:

• prezentatorul trebuie să explice natura prototipului (dar nu cum funcționează designul);
• uneori prezentatorul trebuie să explice starea actuală sisteme (de exemplu, „Această pagină nu funcționează încă”) sau întreabă „Ce te așteptai să se întâmple?”;
• Se întâmplă că prezentatorul trebuie să afle de ce participantul la experiment a încetat să mai lucreze: pentru că aștepta un răspuns sau pentru că credea că a finalizat sarcina.

Chiar dacă facilitatorul poate fi nevoit să interacționeze din când în când cu participantul la test, scopul său principal este să observe cu calm persoana care lucrează cu designul, mai degrabă decât să vorbească cu el.

1. Dacă utilizatorul face clic pe un element pentru care nu a fost încă conceput un răspuns corespunzător:

• spuneți: „Acest element nu funcționează”;
• întrebați: „Ce vă așteptați să se întâmple?”;
• cere utilizatorului să facă clic pe următorul element.

De exemplu: „Ați făcut clic pe linkul „mașini compacte”. Din păcate, încă nu am pregătit ecranul corespunzător. Încercați să selectați categoria „mașini de dimensiuni medii”. După ce utilizatorul selectează această opțiune, încercați să vorbiți cât mai puțin posibil, rămâneți indiferent.

2. Dacă după clic utilizatorul se deschide pagina gresita, „calculatorul” trebuie să-l elimine din câmpul vizual al participantului cât mai repede posibil, încărcându-l în schimb pagina anterioară. Prezentatorul trebuie să raporteze imediat că s-a deschis o pagină greșită, apoi să spună verbal acțiunile participantului pagina curentă. Abia atunci „calculatorul” arată pagina corectă.

Erorile computerului distorsionează datele

Vă rugăm să rețineți că inexactitățile făcute de „calculator” pot avea un impact semnificativ asupra rezultatelor testelor. Odată ce ecranul apare, utilizatorii formează un model mental al modului în care funcționează sistemul și metoda de cercetare. Dacă este afișată o pagină greșită, nu presupuneți că utilizatorii vor șterge imediat ceea ce au văzut din memorie.

Chiar dacă derulați înapoi procesul și încercați să explicați eroarea, participanții vor concluziona că ecranul incorect este încă legat de sarcină și vor afla și mai multe informatii utile din explicațiile tale, care le vor influența apoi alegerile și comportamentul. Demonstraţie pagina gresita de asemenea, întrerupe succesiunea acțiunilor și derutează utilizatorii. Ei pot decide că prototipul este defect. Acest lucru va afecta așteptările, încrederea în metoda de cercetare și capacitatea de a forma un model mental coerent.

Din moment ce erori de calculator impact negativ asupra studiului, faceți-vă timp pentru a efectua un test pilot și corectați orice inexactități înainte de a rula testele principale.

Concluzie

Este imposibil să refuzi testele prototip. Designul dumneavoastră va fi testat într-un fel sau altul, indiferent dacă vă place sau nu. Odată ce sistemul este pornit și funcționează și oamenii îl pot folosi, îl vor testa. Și în locul informațiilor necesare despre calitatea experienței și a interfeței utilizatorului, veți primi: recenzii proaste și vânzări pierdute, comenzi abandonate, retururi, lipsă de înțelegere a conținutului și a produselor, apeluri la asistență, costuri crescute de formare, deteriorare a imaginii.

Și va trebui să corectați aceste erori, care, desigur, vor fi incredibil de costisitoare. Prin urmare, testarea prototipurilor – interactive sau desenate pe hârtie – este o etapă obligatorie de intrare pe piață.

Buna ziua!

CSS pare simplu și direct atâta timp cât nu trebuie să faceți nimic personalizat. Iată o altă privire la Probleme CSS. Aceasta este o traducere a articolului „5 Cele mai enervante lucruri cu CSS”.

În 1996, browserele majore acceptau doar parțial CSS și, din această cauză, designerii web au fost forțați să vină cu o grămadă de hack-uri și soluții pentru ca stilurile lor să funcționeze așa cum și-au dorit. De fapt, abia în 1999 fiecare browser a început în sfârșit să accepte pe deplin CSS1. IE 5.0 pentru Macintosh, lansat în martie 2000, a fost primul browser realizat sprijin deplin Specificații CSS1. CSS2 a fost lansat în 1999, dar designerii au ezitat să-l folosească pe scară largă din cauza suportului incomplet de browser pentru standard.

CSS3 a început dezvoltarea în 1998 și a fost în dezvoltare până în 2009. Conținea o mulțime de completări binevenite, cum ar fi colțuri rotunjite, umbre, degrade, tranziții și animații, precum și noi funcții de aspect, cum ar fi aspecte cu mai multe coloane, flexbox și grile.

Din fericire, pe lângă eforturile W3C de a îmbunătăți specificația pentru a satisface nevoile dezvoltatorilor, comunitatea însăși a dezvoltat multe soluții pentru a îmbunătăți și simplifica lucrul cu CSS într-un mediu complex. SASS, Stylus, LESS au introdus bucle, mixuri și funcții. Introducerea variabilelor CSS a făcut mai ușor de scris stiluri complexe, a îmbunătățit lizibilitatea și mai ușor de întreținut.

CSS este cu siguranță o îmbunătățire grozavă a vechiului HTML bun, dar Limitări CSS sunt uneori copleșitoare, iar lipsa de sprijin din industrie i-a reținut pe designeri de mulți ani. Prin urmare, CSS nu și-a găsit încă locul în inimile dezvoltatorilor.

Chiar și astăzi, numindu-te „dezvoltator fullstack” sau „dezvoltator front-end”, cu un an sau opt ani de experiență, vei întâlni totuși o situație în care CSS te va face să transpiri.

Voi enumera câteva probleme majore CSS:

CSS este despre markup, nu despre design

Designerii trebuie să petreacă mai mult timp creând design grozavși mai puțin timp de lucru cu problemele de marcare și compatibilitate cu browserul. Când spun „centrat pe markup”, vreau să spun că fiecare instrument de design CSS te obligă să intri cod sursă a crea design bun. Instrumentele pentru designeri ar trebui să fie axate pe design. CSS este rău, deoarece îi obligă pe designeri să se gândească la cum să-și implementeze design-urile din punct de vedere tehnic, mai degrabă decât din perspectiva designului.

Războaie de browser

Ați creat un aspect uimitor pentru noul dvs. site web. Dar transformarea acelei machete frumoase Photoshop într-un aspect perfect pentru pixeli este o provocare. Problema nu este că nu înțelegi cum să-l codezi. Problema este mai ales că browsere diferite interpretați-vă marcarea diferit, chiar dacă utilizați CSS complet valid. Este foarte demotivant atunci când remediați o eroare într-un browser și, prin urmare, adăugați o eroare nouă în altul.

• Folosiți întotdeauna Normalize.css. Forțează browserele să redea toate elementele mai previzibil și în conformitate cu standarde moderne. Afectează tocmai elementele care au nevoie de normalizare.
• Puteți folosi cadre precum Bootstrap, Bulma și Materialise. În cea mai mare parte, sunt foarte compatibile cu majoritatea browserelor.
• Utilizați generatoare de cod CSS3. Ele îi ajută pe dezvoltatori să scrie cod pentru diferite browsere pentru diferite proprietăți CSS3. Ei oferă dezvoltatorilor oportunități ample personalizare, inclusiv chenar-rază, text-umbră, RGBa, dimensiunea casetei. Unul dintre servicii este CSS3 Generator.
• Validare: Serviciul de validare W3C validează versiuni diferite XHTML și HTML, producând o grămadă greșeli importanteși postări pentru a ajuta dezvoltatorii să creeze site-uri web grozave. Validator W3C: http://validator.w3.org
• Validator Css W3C: http://jigsaw.w3.org/css-validator
• Testare: deoarece este aproape imposibil să testați manual site-ul în totalitate browsere posibileŞi sisteme de operare, instrumentele de testare cross-browser vin în ajutor! Puteți utiliza Browsershots, BrowserStack, Cross Browser Testing și servicii similare pentru testare.

Aspect receptiv

Odată cu apariția multora diferite dispozitive a aparut rezoluții diferiteși dimensiunile ecranului și orientări diferite. Dispozitive noi cu dimensiuni noi de ecran apar în fiecare zi și fiecare dispozitiv are o oarecare variabilitate în dimensiune și funcționalitate. Unii dintre ei au orientare portret, unele sunt peisaje, iar uneori pot fi chiar pătrate. Mai mult, uitându-ne la popularitatea iPhone, iPad și altele smartphone-uri moderne, înțelegem că utilizatorul poate schimba orientarea ecranului oricând dorește. Cum să acționezi într-o astfel de situație din punct de vedere al designului?

Pe lângă orientare, trebuie să luăm în considerare și miile dimensiuni diferite ecran. Mulți utilizatori nu extind browserul la ecran complet, iar acest lucru contribuie și el.

• Acordați prioritate continut importantși ascundeți detalii neimportante pe ecranele mici. Cred că cel mai important lucru este să arăți cele mai importante lucruri mici ecrane. Uneori este imposibil să ștergeți un anumit conținut de pe telefoanele mobile, atunci merită să luați în considerare posibilitatea de a-l ascunde.
• Folosiți SVG. Spre deosebire de imaginile tradiționale precum PNG sau JPEG, SVG este ușor de scalat fără a pierde calitatea. Mai mult, ei adesea mai mici ca dimensiuni, astfel încât să vă îmbunătățiți puțin viteza de încărcare a site-ului.
• Când vine vorba de interacțiunea cu utilizatorul, concentrați-vă pe furnizarea de controale suficient de mari (intrari, butoane, butoane radio).
• Pentru smartphone-uri, dacă este posibil, faceți butoanele de cel puțin 44 de pixeli, așa cum se recomandă în Ghidul uman iOS
• Testați designul cu cel puțin cinci utilizatori folosind dispozitivele lor obișnuite.
• Utilizați cadre precum Bootstrap. Cu ei, creând ceva potrivit pentru dispozitive mobile site-ul devine mult mai ușor. Folosirea unor clase gata făcute din Bootstrap vă va ajuta să decideți asupra grilei și plasării conținutului.

Faceți roșul mai albastru

Mulți clienți vin cu cerințe ciudate, așteptări mari, funcționalitate dorită despre care nu se discută niciodată. Ca rezultat, ajungem cu nenumărate editări și nenumărate iterații. Clienții își schimbă dorințele în fiecare secundă, mai ales când vine vorba de design. Fiind forțați să cedeze fiecărui capriciu al clientului, designerii percep acest lucru ca pe un maltratare sau o insultă. Acesta este motivul pentru care site-uri precum Clients From Hell sunt populare.

• Crearea de prototipuri animate - opțiune bună arată-ți ideile. Utilizați programe precum Adobe XD, Sketch, InVision și așa mai departe. Începeți dezvoltarea numai după ce proiectul a fost convenit.
• Este înțelept să planificați întregul proces de dezvoltare încă de la început. Cel mai probabil, va trebui să adăugați timp pentru diverse surprize în acest proces. Amintiți-vă Legea lui Murphy: „Ce poate merge prost, va merge prost”.
• Stai calm. Nu lăsa emoțiile tale să devină mai bine de tine. Nu uitați doar că clientul nu a absolvit școala de artă și este posibil să nu realizeze că textul roșu pe fundal verde nu îmbunătățește lizibilitatea. Explicați-vă deciziile cu privire la ierarhia vizuală, tipografia și orice altceva care ar putea fi afectat de modificări.
• Amintiți-vă că site-ul este pentru clientul dvs., iar scopul dvs. este să faceți clientul mulțumit de site. Cel mai bun lucru pe care îl puteți face este să vă faceți recomandări pentru modificări. Dacă nu sunteți de acord, faceți tot posibilul pentru ca site-ul să arate cât mai bine posibil.

CSS este subestimat

CSS este frustrant în cea mai mare parte, pur și simplu pentru că nimeni nu vrea cu adevărat să-și ia timp pentru a-l învăța. Mulți oameni, în special programatori, îl subestimează și încearcă să facă ceva fără a vrea să înțeleagă măcar mecanica acestuia. Și rămân mereu blocați în aceleași probleme.

Am lucrat cu niște ingineri backend uimitori care cunoșteau fiecare model OOP din carte, dar erau blocați cu poziționarea, flotarea și numărarea CSS receptiv ceva ca magia neagră. Așa că mi se pare că această benzi desenate este foarte exactă.

Oamenii se așteaptă ca CSS să fie simplu și direct, dar, ca majoritatea lucrurilor, este nevoie de ceva timp.

După cum am spus în articolul meu anterior „Depanarea CSS”, lucrul cu CSS și obținerea rezultate bune din lucrul cu CSS - doi mari diferente. Este ușor să începeți cu CSS, dar stăpânirea necesită efort. Acesta este ceva ce durează un minut pentru a fi cunoscut și o viață întreagă (cu exagerare) pentru a stăpâni.

Luând ca criteriu sistemul de lucru (deoarece este rezultatul final al tuturor proceselor de dezvoltare anterioare), este posibil să puneți prototipul, prototipul și simulatorul în diferite condiții de funcționare. Dacă evaluăm asemănarea cu un sistem de lucru, atunci macheta seamănă mai puțin cu ea decât cu simulatorul. Un prototip este mult mai aproape de un simulator decât de o machetă. În ceea ce privește numărul de unități din aceste sisteme, aspectul constă de obicei dintr-un singur dispozitiv, deși se poate potrivi întregului sistem; prototipul descrie întregul sistem exact în același mod ca și simulatorul (ca și pentru simulator, acest dispozitiv este furnizat operatorului uman ca interfață cu mașina). Dacă vorbim despre numărul de acțiuni cu echipamente sau aspecte de întreținere a sistemului de către personal, atunci mai puține verificări se poate face cu o machetă, cu atât mai mult cu un simulator de sistem și prototipul acestuia (totuși, desigur, nu la fel de mult ca cu un sistem real).

Pentru echipamentele electronice, panourile sunt mult mai simple decât simulatoarele, dar dacă adăugați echipamente suplimentare(microcalculator, software, blocuri de control și afișare etc.), apoi aspectul se va transforma în cele din urmă într-un simulator.

Testarea aspectului este efectuată în cazul în care IChF decide că este necesar, deoarece, de obicei, controalele nu sunt prevăzute în această etapă de dezvoltare. Prototipurile RF sunt reglementate de instrucțiunile Ministerului Apărării. Ca și în cazul testării modelelor, procesele de măsurare a performanței simulatorului și a sistemului de rulare depind de circumstanțe speciale (cum ar fi dacă există cerințe pentru a testa o anumită modificare a sistemului); Uneori, aceste măsurători sunt efectuate în scopuri de cercetare (de exemplu, pentru a confirma posibilitatea utilizării simulatorului pentru instruirea personalului).

Simulator - dispozitiv fizic, care reproduce acele caracteristici ale echipamentelor reale care sunt legate de interfața om-mașină. Este necesar să se facă distincția între sistemele de simulare și modele de calculator, care sunt în esență conceptuale. Pe lângă evaluarea eficienței simulatorului de antrenament, ICHF preferă de obicei să folosească sistem real, iar simulatorul este în următoarele cazuri: 1) nu se pot efectua măsurători cu sistemul în funcțiune; 2) este necesară modificarea parametrilor sistemului pentru a efectua o comparație experimentală, iar parametrii sistemului actual nu pot fi modificați în acest scop; 3) verifica conditii de urgenta, ceea ce este prea periculos pentru echipamentul real.

În plus, măsurătorile cu ajutorul unui simulator au anumite avantaje, și anume capacitatea de a 1) porni și opri sistemul simulat la orice momentul potrivit, 2) fixați o anumită etapă a funcționării sistemului și examinați-o mai atent, 3) schimbați modul de funcționare și 4) asigurați-vă înregistrare automată date.

Pe de altă parte, există o serie de dezavantaje: 1) folosind un simulator este imposibil de reprodus ciclu complet operarea sistemului (desigur, aceasta se referă la procesul de operare); 2) calitatea modelării poate fi mai scăzută decât se dorește; 3) personalul testat nu are de obicei aceleași abilități ca și personalul operațional; 4) la modelarea unui sistem, pot fi jucate doar scenarii de antrenament care nu reflectă în totalitate toate condițiile de funcționare; 5) timpul pentru care IChF poate obține un simulator numai pentru măsurători poate fi limitat.

Situațiile de testare rămase au doar propriile lor dezavantaje inerente. Deoarece sistemul de operare este inclus în mediu extern, uneori pot exista influențe externe asupra acestuia care reduc puritatea cercetării (de exemplu, în cazul întreruperilor cauzate de comenzi cu prioritate mai mare). Acesta este motivul pentru multe cazuri cunoscute de defecțiune a controlului atunci când se lucrează conditii reale. Se poate întâmpla ca premisele RI ale sistemului prototip să nu fie pe deplin îndeplinite, de exemplu în cazul configurațiilor hardware stabile (atât echipamente, cât și proceduri); Din cauza dificultăților continue de dezvoltare, echipamentul testat poate eșua mai des decât în ​​condiții reale. Designul este atât de limitat în capacitatea sa de a prezenta stimuli și răspunsurile corespunzătoare ale personalului încât este necesară o extrapolare atentă atunci când se analizează rezultatele testelor.

Principalele obiective ale evaluării eficacității sistemelor pot fi următoarele: 1) verifica dacă personalul poate rezolva sarcinile cu care se confruntă fără erori semnificative sau suprasolicitare; 2) verificați dacă procedurile de control și alte caracteristici ale echipamentului și sistemului reprezintă obstacole insurmontabile munca eficienta personalului și dacă aceste caracteristici îndeplinesc criteriile psihologiei inginerești; 3) determina impactul asupra muncii personalului al anumitor variabile puternic diferite legate direct de scopul echipamentului și al întregului sistem (de exemplu, operațiuni efectuate în timpul zilei și operațiuni efectuate pe timp de noapte); 4) determina din punct de vedere comportamental caracterul adecvat al unei anumite modificări în lucrare, echipament, întregul sistem sau scopul acestuia, precum și adecvarea unei anumite soluții constructive la problema; 5) prin evaluarea muncii personalului în condițiile de funcționare ale sistemului, să se determine dacă această muncă este adecvată și, dacă nu, să se afle ce factori determină o scădere a eficienței muncii.

Cu cât sistemul testat este mai complet și cu cât condițiile sale de funcționare sunt mai apropiate de cele reale, cu atât obiectivele de testare sunt mai deplin atinse.

Acesta este motivul pentru care se poate face doar o parte scopuri de testare folosind un m:mock static (cel mai comun tip de simulare). Aceasta înseamnă că este posibil să se obțină date parțiale care nu satisfac pe deplin obiectivele de testare. De exemplu, să presupunem că avem o machetă statică a cabina unui avion de luptă. Apoi, cu ajutorul acestuia, se stabilește că comenzile sunt accesibile, iar citirile instrumentelor sunt citite, ceea ce este necesar pentru funcționare eficientă avion. Cu toate acestea, acesta este doar un test parțial (numai din punct de vedere antropometric) pentru a stabili că personalul își poate îndeplini sarcinile. Este necesar și un simulator cel puţin pentru a verifica dacă pilotul reacţionează suficient de rapid la schimbările din mediu.

Sarcinile de testare descrise mai sus se aplică atât sistemelor din lumea reală, cât și procesului de dezvoltare a sistemului. Pe măsură ce sistemul este creat, se descoperă noi caracteristici, pe baza cărora echipamentele și procedurile sunt modificate. Testarea este necesară pentru a determina dacă aceste modificări sunt fezabile. Sistemul trebuie retestat în timpul funcționării, deoarece testarea nu poate furniza date despre cât de bine își îndeplinește scopul propus; de exemplu, sistemele militare nu sunt programate să funcționeze în condiții de luptă până când nu încep luptă. Testarea sistemelor de luptă poate fi efectuată în jocurile de război, de exemplu, atunci când două unități de infanterie concurează cu sprijin sub formă de tancuri, artilerie și avioane. Dacă apar întreruperi în funcționarea sistemului, atunci este necesar să se examineze parametrii problemei. Sau FSI ar trebui să determine impactul variabilelor interne potențial importante (de exemplu, rotația schimburilor) asupra performanței. Uneori, testele RI și simulatoare sunt efectuate pur și simplu pentru a colecta date de cercetare.
Evaluarea eficacității unui sistem (SI) are caracteristici care au puțină legătură cu caracteristicile cercetării tradiționale într-un mod de experiment controlat (de exemplu, în condiții de laborator): 1) orientare către sarcini reale, dar cu prezența interferențelor: 2 ) limitări de timp și resurse; 3) măsurătorile se fac mai degrabă în macrounități decât în ​​microunități (minute mai degrabă decât secunde); 4) sunt evaluate atât echipamentele cât și personalul; 5) se utilizează o abordare sistematică; 6) caracterizat prin valabilitate ridicată; 7) există mai puține opțiuni pentru managementul testelor; 8) obiective multiple și criterii multiple (atât intermediare, cât și finale); 9) prezența mai multor niveluri de intrare în procesul de testare și/sau în sistem.

Termenul „evaluare a performanței sistemului” înseamnă că FSI măsoară caracteristicile de performanță ale personalului. Testarea trăsăturilor (care constă în obținerea de evaluări subiective ale caracteristicilor unui sistem, echipament și funcționare, spre deosebire de performanța personalului care interacționează cu acele caracteristici) nu este o evaluare a performanței. Cel mai comun tip de testare bazată pe caracteristici este evaluarea adecvării caracteristicilor inginerești și psihologice ale echipamentelor. Geer a făcut distincția între procedurile I și E informale și formale, primele referitoare la testarea atributelor (evaluarea performanței unui design hardware, reprezentat fie de desene, fie de o machetă sau de echipamente nefuncționale), iar cele din urmă referitoare la măsurarea performanței. Evaluarea performanței echipamentului face uneori parte din procesul de testare a performanței și, prin urmare, este abordată și aici. Cele de mai sus se aplică și instrumentelor subiective de măsurare precum interviurile, chestionarele și clasamentele, care sunt folosite pentru a obține informații despre performanță, deși nu pot fi utilizate pentru a măsura direct performanța.