UI/UX pro vývojáře: past, která zabíjí použitelnost

Druhým klíčovým bodem je identifikace typických skrytých činností ve vašem týmu. Může to být dohledávání informací v dokumentaci (která je často neúplná), synchronizace s backendem, nastavování lokálního prostředí, nebo dokonce čekání na schválení přístupů. Zkuste si po dokončení úkolu zapsat, co jste skutečně dělali, a porovnat to s původním odhadem. Po několika takových záznamech budete mít data, která vám umožní odhady zpřesnit.

Praktickým chybou bývá kombinování kódu pod různými licencemi bez rozmyšlení kompatibility. Například projekt pod GPL může používat knihovnu pod MIT, ale pokud je MIT kód upraven a začleněn do GPL projektu, výsledek spadá pod GPL. Naopak pokud chcete použít GPL kód ve svém projektu s permisivní licencí, narazíte na konflikt. Proto si před psaním kódu ověřte, zda jsou licence všech závislostí vzájemně slučitelné. K tomu slouží tabulky kompatibility, které najdete na webu, ale i jednoduché pravidlo: copyleft přebíjí permisivní, nikdy ne naopak.

Nakonec si osvojte zvyk testovat své vlastní rozhraní jako uživatel – ne jako vývojář. Vypněte vývojářské nástroje, zkuste aplikaci používat bez znalosti kódu. Klikněte na všechno, co vypadá klikatelně, a sledujte, co se stane. Najdete tak desítky drobností, které by vám jinak unikly. Až budete příště předávat práci, projděte si ji z pohledu někoho, kdo vidí aplikaci poprvé. Tohle je nejlevnější způsob, jak zlepšit kvalitu vašeho UI/UX – a výsledek ocení jak klienti, tak koncoví uživatelé.

Typografii berte jako součást designu, ne jen jako výplň. Výchozí prohlížečové fonty sice fungují, ale ne vždy podporují češtinu správně. Dbejte na dostatečný řádkování a kontrast mezi textem a pozadím. Špatný kontrast je častý problém – zvlášť když použijete světle šedou na bílém. Doporučuji si ověřit kontrast nástrojem, ale jednejte obezřetně: minimální poměr pro běžný text je 4,5:1. V praxi to znamená, že raději sáhnete po tmavší barvě textu, než byste riskovali nečitelnost.

Formuláře jsou další oblast, kde se chyby projevují nejvíc. Nikdy neoznačujte jen barvou, že je pole neplatné – barvoslepí uživatelé to nepoznají. Přidejte textovou hlášku pod pole, ideálně s vysvětlením, co je špatně a jak to opravit. A nemusíte kontrolovat až při odeslání – lepší je validace v reálném čase, ale pozor, aby nebyla příliš agresivní. Zkuste si projít vlastní formulář jako uživatel: kolik kliknutí potřebujete, než formulář úspěšně odešlete? Pokud je kroků víc než pět, zjednodušte to.

Začněte u ovládacích prvků. Typický problém je tlačítko, které vypadá jako odkaz, nebo odkaz, který vypadá jako text. Uživatel si musí být jistý, že na prvek může kliknout. Používejte konzistentní vizuální styl pro všechny interaktivní elementy – změna barvy při najetí myší, zřetelný obrys nebo stín. A pozor na velikost: na dotykovém zařízení je minimální velikost cílové oblasti kolem 40 pixelů, ale spíše sáhněte po větších hodnotách. Malé tlačítko sice vypadá elegantně, ale uživatel ho netrefí a aplikaci opustí.

Výběr open source licence bývá často podceňovaným rozhodnutím. Mnoho vývojářů sáhne po té první, kterou znají – obvykle MIT nebo GPL – aniž by si uvědomili, jaké důsledky to bude mít pro ně i pro uživatele jejich kódu. Přitom stačí položit si pět až sedm konkrétních otázek a odpovědi vás spolehlivě dovedou k vhodné licenci. Není to o právnické průpravě, ale o tom, co od šíření kódu skutečně očekáváte.

Častým nešvarem je práce na více feature větvích z jednoho lokálního klonu bez přepínání mezi nimi. Pokud máte rozjeté tři větve a v každé děláte něco jiného, snadno se stane, že začnete commitovat změny do nesprávné větve. Řešením je buď používat samostatné pracovní adresáře pro každou větev, nebo důsledně kontrolovat aktuální větev před každým commitem a pull requestem. Mnoho vývojářů si také plete stav v lokálním úložišti se stavem na vzdáleném serveru. Než začnete novou práci, vždy si stáhněte nejnovější změny a porovnejte, jestli vaše lokální větev odpovídá té vzdálené.

Třetí situace, kdy je pokrytí spíše škodlivé, je porovnávání mezi týmy nebo projekty. Čísla se dají snadno zmanipulovat a neberou v úvahu specifika domény. Testy pro bankovní převod budou vždy složitější než testy pro zobrazení statické stránky. Místo celkového procenta se proto zaměřte na pokrytí kritických částí — tam, kde chyba stojí hodně peněz nebo ohrozí bezpečnost. Dobrý test je takový, který selže, když dojde k reálné chybě. Pokrytí vám to neřekne, ale můžete si to ověřit mutačním testováním nebo tím, že do kódu záměrně vložíte chybu a podíváte se, jestli testy zareagují.