Firmy neustále potřebují sledovat a měřit svůj výkon a fungování. Potřebují tedy spojit a vizualizovat svá data, na základě kterých mohou dělat informovaná rozhodnutí.

Tento projekt byl o návrhu aplikace pro správu a sledování nahrávání dat v rámci Business Intelligence platformy. Šlo o re-design aplikace, neboť původní verze měla nízkou adopci a používání, chybějící funkcionalitu a nízký technický výkon. V projektu jsem zastával roli designéra a Product Ownera.

Poznámka – O návrhu této aplikace jsem psal také v článku Jak jsem úspěšně re-designoval jednu z aplikací v GoodData z roku 2014.

Cíle projektu

• Zvýšit používání a adopci této aplikace interními i externími zákazníky
• Zvýšit technický výkon a spolehlivost aplikace
• Sjednotit design a využít novou vizuální identitu pro aplikace s využitím interního Design Systému.

Výsledek

Novou verzi aplikace jsme vyvinuli v rámci 4 měsíců s týmem čítajících 2 vývojáře.

• Čas strávený v aplikace zvýšen o ~70 %
• Použití klíčových funkcí aplikace zvýšeno o ~44 %
• Opouštění aplikace sníženo o ~25 %
• Výkon zvýšen o ~1 650 %

Poznámka ohledně výkonu – předchozí verze aplikace byla schopna „obsloužit“ přibližně 200 projektů. Nová verze byla koncipována tak, aby zvládla poskytnout více než 3 500 projektů.

Má role

• Hlavní designér – byl jsem zodpovědný za vedení a koordinování návrhu
• Product Owner – vedl jsem vývoj a doručení produktu zákazníkům, spolupráci

Poznámka – V rámci své role jsem také spolupracoval (a koordinoval spolupráci) mezi dalšími rolemi jako byly související vývojové týmy, marketing, zákaznická podpora, atd.

Postup

1. Porozumět problému – Pro lepší pochopení a definování toho, co potřebujeme řešit jsme aplikovali metody výzkumu. Například deníčkové studie, contextual inquiries, web analytics, atd.
2. Syntéza a nápadování – Na základě získaných dat jsme informace kategorizovali, vytvořili z nich scénáře a prioritizovali je v rámci týmu a diskuzi se Subject Matter Experts.
3. Kontinuální ověřování návrhů – Na základě priorit jsme vytvořili wireframy, které jsme s využitím testování použitelnosti formou RITE ověřili s uživateli, zapracovali zjištění a dále zpřesňovali.
4. Implementace a měření po spuštění – Aplikaci jsme postupně vyvíjeli a od uživatelů získávali další zpětnou vazbu pro zlepšení.

Porozumět problému

Než jsme začali s návrhem nové aplikace, pomocí metod uživatelského výzkumu jsme identifikovali kritické problémy a místa, která bylo potřeba zlepšit. Pro získání informací jsme využili například metody:

• Deníčkové studie,
• Contextual inquiries,
• Hloubokové rozhovory s uživateli,
• Web analytics.

O použití deníkových studiích

Deníčkové studie name velice pomohli prozkoumat problematická místa v souvislosti s chováním uživatelů, jejich návyky a potřebami pro používání aplikace.

Fungovalo to tak, že jsme je poprosili o zaznamenávání poznatků online do Google Dokumentu. Primárně nás zajímalo:

• Co dělali
• Co se stalo
• Co očekávali

Zápisky jsme pravidelně analyzovali a motivovali lidi k pokračování zapisování do jejich deníčku.

Jako designér a Product Owner jsem se snažil praktikovat continual discovery pro pochopení příležitostí pro zlepšení v rámci aplikace.

Vedle jsem ale také strávil hodně času:

• Konzultacemi se Subject Matter Experts – například o tom, jak se takové věci běžně dělají a proč (industry standards), jaké jsou podmínky a nutnosti pro efektivní fungování, atd.
• Zkoumáním podobných existujících řešení a konkurence.

O použití webové analytiky

Pro získání informací jsme hojně využívali kvalitativní metody. Potřeboval jsem ale vědět, jak lidé aplikaci skutečně používají – jak fungují, jak se chovají. Například, pokud lidé odchází, kde tráví nejvíce času, atp. Tyto informace jsem dále používal pro další zjišťování.

Pro takové měření jsme využívali Google Analytics. Sledovali jsme, jak se lidé v aplikaci chovají, kam nejvíce chodí a jak jí celkově používají. Například s využitím Pokročilých segmentů s Flow analysis jsme zjistili, jak se lidé chovají za různých stavů v rámci aplikace.

Poznámka – Také jsme využívali interní logovací a sledovací nástroje. Ten jsme využívali primárně pro zjištění detailních informací, například kolik projektů lidé spravují a jaké konkrétně, jaké objemy dat lidé nahrávají, jak nahrávání plánují, atd.

Během příprav nových návrhů a zlepšení jsme přemýšleli především nad tím:

• Jak pomoci být lidem více efektivní?
• Které části existující verze znesnadňuje být lidem efektivní?
• Co lidem zásadně chybí v existující aplikaci?

Všechny získané informace a postřehy jsem měli uložené ve sdílené knowledge base. Včetně známých problémů. Zjistili jsme například, že:

• Lidé stráví hromadu času nastavením a správou data loadů místo automatizace.
• Protože lidé často spravovali víc data loadů, neměli žádný přehled o tom, v jaké jsou stavu.
• Lidé se v aplikaci špatně orientovali kvůli nevhodné informační architektuře.
• Lidé nemohli snadno nahrát nové data loady do více projektů zároveň, ač byly stejné.

Syntéze a nápadování

Protože jsme během zkoumání problematiky získali spoustu informací o tom, co lidé potřebují a jak existující aplikaci využívají, začal jsem informace postupně analyzovat a syntetizovat pro zjištění vzorů.

Na jejich základě jsem začal definovat klíčové scénáře, které aplikace musí podpořit. Například:

• Když připravuji nová nahrávání dat, potřebuji je rychle nahrát do projektu, a mohl jsem tak vytvářet reálné vizualizace dat.
• Když sleduji nahrávání dat, potřebuji vidět všechna nahrávání dat v rámci projektu, abych tak mohl optimalizovat jejich spouštění, funkci a snadno opravit ty, které nefungují.

Ve spolupráci se Subject Matter Experts jsme se v rámci Product Management oddělení shodli na těchto scénářích a začali jsme tak zkoumat možná řešení.

Začali jsme tak s tvorbou konceptů s využitím:

• Definování a ověření základní informační architektury
• Hrubé náčrtky základních obrazovek, následované low fidelity wireframes

O tvorbě informační architektury

Navržený koncept informační architektury jsme testovali s využitím nástroje TreeJack pro reverzní card sorting. Cílem testování bylo zjistit, zda jsme správně pochopili mentální modely lidí a lidé se tak dokáží v aplikaci zorientovat.

Do generování konceptů a nápadů jsem zapojil své kolegy designéry, ale také vývojáře. Využil jsem pro generování metody 10 plus 10 a také Design Studio. Díky tomu jsme mohli rozdělit fáze generování a kritiky.

Na základě vybraných slibných nápadů ve formě skic jsem poté vytvořil základní méně detailní (low fidelity) wiframy, které jsem testoval ve smyslu použitelnosti v rámci sezení testování použitelnosti. K tomu jsem se inspiroval metodou RITE (Rapid Iterative Testing Evaluation) používanou ve společnosti Microsoft. Díky tomu jsme nápady během testování neustále iterovali a upravovali.

O tvorbě základní kostry uživatelského rozhraní

V rámci generování konceptů jsem vytvářeli opravdu základní kostry toho, jak by mohla aplikace vypadat. Snažili jsme se vymyslet co nejvíce nápadů, abychom pak mohli vybrat skutečně ty nejlepší varianty.

Na základě takto vytvořených variant jsme pak vytvořili trochu více detailní wireframy, které jsme poté využívali v rámci testování použitelnosti a případných dalších úprav.

Na základě slibných návrhů vzešlých z iterací jsem poté vytvořil detailnější návrhy řešení, včetně možných stavů aplikace, ale také s návrhem textací a vizuálních priorit.

Ještě doplním, že abychom zbytečně neobjevovali kolo a využili prvky, které budou lidé znát, tak jsem zároveň:

• Prozkoumal konkurenční řešení a podobné aplikace.
• Kontinuálně sledoval, jak lidé využívají takové aplikace.
• Využíval existující knihovny návrhových vzorů v podobě online knihoven nebo knížek, například knihy Designing Interfaces.

Detailnější návrhy

Paralelně s iterováním návrhů jsem ve spolupráci s Lead Visual Designérem začal pracovat na koncepci finalizace obrazovek. Například jsme řešili:

• Které informace jsou pro lidi prioritní a které bychom měli lidem v rámci UI poskytnout a jak.
• Nápady na vizuální hierarchie a mikrointerakce.

Fungovali jsme tak, že jsem navrhl základy ve Sketch a společně s kolegou jsme je dotáhly do finálního výsledku podle našich interních design guidelines.

Příklad zpracování určitého problému

Na konkrétním příkladu bych rád ukázal svůj postup při řešení konkrétního problému. Z důvodu citlivých informací však poskytnu pouze koncepční pohled na danou problematiku.

• Persona – Technický uživatel
• Scénář – Uživatel potřebuje do projektu přidat nový script pro nahrávání dat

Doplňující informace

• Lidé mají tyto skripty uložené v jejich počítači, současně také ve sdíleném GIT repozitáři.
• Lidé mají v rámci projektu více skriptů – své a nebo dalších kolegů či správců projektu.
• Daný uživatel může spravovat a přistupovat do více projektů.
• Z technických omezení je potřeba nahrát více skriptů jako ZIP archiv (v době návrhu neexistovala možnost nahrát složky či podsložky, neboť skripty byly často v určitých strukturách).

Řešení

• Identifikovat tzv. touch points – jak a odkud budou lidé přidávat skripty
• Jak by přidávání mělo fungovat
• Jak by mělo UI vypadat a fungovat

Kroky v rámci úkolu:

1. Vybrat projekt (nebo projekty) do kterých chci nový skript přidat
2. Vybrat skript v počítači
3. Pojmenovat nova proces nahrávání pro odlišení od těch již existujících
4. Spustit nahrání skriptu
5. Vidět potvrzení o úspěšném nahrání

Díky definování těchto kroků a následnému flow diagramu jsme mohli s vývojáři navrhnout jednoduché UI, díky kterému mohou lidé skripty přidávat do svých projektů rovnou z webové aplikace. Což byla jedna z chybějících základních funkcí.

A jednotlivé kroky v uživatelské rozhraní vypadaly přibližně takto:

Kam se obrátit

Pokud vás během pročítání této ukázky cokoliv napadlo, neváhejte se na mě obrátit na adrese email@manakmichal.cz, případně mi napište pomocí tohoto formuláře: