Nielsen’s Heuristic Evaluation

Při návrhu uživatelského rozhraní aplikace, ať již webové, nebo desktopové, je vždy vhodné nejdříve vytvořit prototyp uživatelského rozhraní (UI). Výhoda prototypování spočívá hlavně v rychlejším zpracování, které je jednodušší a levnější, než provádění změn přímo v grafickém návrhu. Prototyp (neboli wireframe/mockup) lze zpracovat buď elektronicky pomocí některého z prototypovacích nástrojů (Balsamiq Mockup), nebo i pomocí tužky a papíru.

Po vytvoření návrhu rozhraní je potřeba ověřit, že uživatelé budou schopni systém používat. Práce v systému musí být intuitivní a co nejjednodušší. Splnění těchto předpokladů je možno ověřit uživatelským testováním, které lze provádět buď za pomocí uživatelů, nebo i bez nich. Výstupy analýzy je pak potřeba zpracovat a návrh rozhraní dle toho přizpůsobit. Poté může následuje tvorba grafického návrhu.

Jednou z možnosti jak testovat aplikaci bez využití uživatelů je heuristická analýza, která vychází z poznatků, které byly získány dlouhodobým pozorováním. Jedná se o soubor zkušeností, jak jsou uživatelé zvyklý se systémem pracovat a co od něho očekávají. Jednou z heuristických analýz je Nielsenova heuristická analýza [en], která se skládá z deseti základních pravidel, které je nutno zkontrolovat, aby byla zajištěna odpovídající použitelnost a intuitivní ovládání aplikace. Tyto pravidla je dobré mít na paměti již při vytváření návrhu UI.

1) Visibility of system status

Stav systému musí být vždy viditelný. Uživatel musí vždy vidět, v jakém stavu se aplikace nachází, jestli čeká na nějaký vstup, nebo provádí určitou operaci, například pomocí ikonky přesýpacích hodin, nebo rotujícího kolečka.

2) Match between system and the real Word

Systém „mluví uživatelským jazykem“ a je co nejvíce přizpůsoben tak, aby práce s ním připomínala práci v reálném světě. Toto pravidlo se vztahuje převážně k vizualizaci informací. Například ikona koše opravdu vypadá jako koš a přetažení souborů na tuto ikonu způsobí přesunutí souborů do koše, stejně tak jako v reálném světě vyhazujeme papírové soubory.

3) User control and freedom

Systém musí poskytovat uživateli možnost vrátit ze z určitého stavu zpět, nebo zrušit zvolenou akci. Nejčastěji se to řeší pomocí tlačítek, nebo odkazů s nápisem Zpět, Undo, Storno.

4) Consistency and standards

Systém by měl být konzistentní jak vzhledově, tak i co se týče ovládání. Popisky stejných akcí by měli mít stejný název, nemělo by se střídat např. uložit/upravit. Stejně tak by se měl používat výchozí vzhled, dle použitého systému a standardní ovládací prvky. Např. nepoužívat vzhled prvků z platformy Mac pro program, který poběží na platformě Windows.

5) Error prevention

Systém by měl předcházet chybovým stavům, např. pomocí potvrzovacích dialogů a varování. Je vhodné upozornit uživatele, pokud zapomene vyplnit povinné položky formuláře, stejně tak jako zeptat se, že si opravdu přeje smazat vybraný adresář i přesto, že není prázdný.

6) Recognition rather than recall

Uživatel by měl být při používání systému co nejméně kognitivně zatížen. To zajistíme tím, že bude systém nabízet pouze volby, které lze vybrat a ostatní skryje, nebo vizuálně zneplatní. Dále je vhodné použití drobečkové navigace, stránkování, nebo zvýraznění pozice ve stromové struktuře, aby uživatel ihned viděl jeho aktuální pozici v systému.

7) Flexibility and efficiency of use

Systém musí být efektivní a jednoduchý pro použítí. Zároveň však musí poskytovat i dostatečný počet voleb, které využijí hlavně pokročilí uživatelé. V rámci možností je také vhodné poskytovat uživatelům klávesové zkratky anebo funkce automatického doplňování vstupních polí.

8) Aesthetic and minimalist design

Systém by měl zobrazovat co nejméně informací a voleb, tak aby práce v něm byla co nejrychlejší, přehledná, a uživatel musel co nejméně přemýšlet. Položky a volby, které nejsou často využívány, není vhodné umísťovat přímo na běžně používané obrazovky.

9) Help users recognize, diagnose, and recover from errors

Systém by měl uživateli poskytovat srozumitelné chybové zprávy tak, aby měl uživatel možnost chyby obratem opravit a věděl, co po něm systém vyžaduje. Zprávy by měli být v běžném jazyce a musí zároveň informovat o možném řešení problému.

10) Help and documentation

Systém musí poskytovat nápovědu přesně tam, kde jí uživatel očekává a v situacích, kdy je nejvíce potřeba. Například vyplňování formulářů, zakládaní nových projektů apod. Nápověda by měla být buď kontextová (přímo u daného prvku), nebo globální s možností vyhledávání.

Dodržováním těchto pravidel nám pomůže vytvořit systém, který bude jednoduchý a efektivní na práci, proto bychom na tato pravidla neměli zapomínat, nebo si je alespoň rychle projít předtím, než začneme prototypovat, nebo navrhovat grafický návrh.