Jak jsem úspěšně re-designoval jednu z aplikací v GoodData

Před pár měsíci jsme v GoodData re-designovali jednu z našich aplikací. Napadlo mě se podělit o to, jak jsem postupoval. Protože najít informace o tom, jak designeři postupují při návrhu produktu, lze jen velmi zřídka.

Re-design trval přibližně 6 měsíců. Po 3 měsících práce jsem aplikaci doručili k beta testování. Po dalších necelých dvou měsících jsme přidali další funkce, aplikovali nový vizuální design a opravili desítky technických bugů. A následně jí oficiálně spustili.

Po více jak dvou měsících produkčního fungování sbíráme zpětnou vazbu a sledujeme, jestli jsme cíle re-designu splnili. Ohlasy jsou pozitivní a kýženou experience jsme v produktu dodali. Nyní se snažíme aplikaci dále zlepšovat a přidávat další funkcionalitu.

Bohužel nemohu zmínit všechny potřebné informace, např. informace o cílových skupinách, konkrétní statistiky, atp. Chci se ale podělit o svůj postup a využité metody. A jak jsem byl díky nim při návrhu efektivní.

O re-designu aplikace

Na základě zpětné vazby od uživatelů jsme se rozhodli zásadně re-designovat aplikaci pro automatizaci a monitoring nahrávání dat. Lidem chyběly některé důležité funkce, aplikace nebyla příliš rychlá a hůře se v aplikaci orientovali.

Úvodní (přehledová) obrazovka původní aplikace.
Úvodní (přehledová) obrazovka původní aplikace.
Detail jednoho z procesů pro nahrávní dat v původní aplikaci.
Detail jednoho z procesů pro nahrávní dat v původní aplikaci.

Pro re-design jsme tak měli několik cílů:

  • Zjednudušit informační architekturu a navigaci v aplikaci.
  • Přidat nové funkce pro efektivnější práci.
  • Doplnění chybějící funkcionalitu na základě potřeb uživatelů.
  • Zásadně aplikaci zrychlit.

Zároveň jsme také s Ondrou Válkou, té doby Lead Visual Designerem, aplikovali nový vizuální styl, který se v té době připravoval. Ač to nebyl primární cíl.

Finální podoba jedné ze stránek aplikace - konkrétně přehledová stránka.
Finální podoba jedné ze stránek aplikace – konkrétně přehledová stránka.
Finální podoba jedné ze stránek aplikace - konkrétně detail projektu s jednotlivými procesy nahrávání dat.
Finální podoba jedné ze stránek aplikace – konkrétně detail projektu s jednotlivými procesy nahrávání dat.

Má role v projektu

Má role v GoodData je User Experience Designer. U tohoto „projektu“ jsem zastal i pozici Product Managera. A byl jsem tak zodpovědný nejen za návrh produktu, ale také za prioritizaci funkcionality, specifikace a za doručení produktu k zákazníkům.

Má role tedy spočívala v zajištění:

  • Uživatelského výzkum a testování použitelnosti.
  • Tvorby koncepce a informační architektury aplikace.
  • Interakčního a UI designu.
  • Prioritizace a plánování úkolu pro development.
  • Interní komunikace ohledně projektu.
  • Spolupráce s Lead Visuálním Designerem na tvorbě nového vizuálního stylu.

Proces návrhu aplikace

Na aplikaci jsme intenzivně pracovali tři lidé – já a dva programátoři. A abychom tvorbu aplikaci a řízení projektu co nejvíce zefektivnili, inspirovali jsme se prvky v metodice SCRUM ve spojení s Lean UX.

Proces návrhu a tvorby aplikace z pohledu UX Designera.
Proces návrhu a tvorby aplikace z pohledu UX Designera.

Pokud se na re-design podívám ze svého pohledu, skládal se z několika částí:

  1. Tvorba koncepce a výzkum,
  2. Design aplikace,
  3. Implementace.

Tvorba koncepce a výzkum

Před re-designem jsem prováděl kontinuální výzkum. Především abych ověřil, zda původní aplikace splňuje vše potřebné. A pomáhá lidem řešit potřeby a cíle co nejefektivněji.

Pro získání těchto informací jsem využil následující metody:

Vzhledem k tomu, že největší skupinou jsou interní uživatelé, byl pro mě výzkum jednodušší. S lidmi jsme trávil téměř každý den a sledoval jsem, co lidé typicky řeší a proč. Zároveň jsem sledoval prostředí, ve kterém pracují.

Samozřejmě jsem také hledal co nejvíce informací o lidech mimo naší společnost.

V Google Analytics jsem pečlivě zkoumal vzory chování pro získání odpovědí na své otázky nebo případné další hypotézy.
V Google Analytics jsem pečlivě zkoumal vzory chování pro získání odpovědí na své otázky nebo případné další hypotézy.

Informací jsem získal spoustu – jak lidé aplikaci používají, co jim v aplikací chybí, atp. Když jsem tedy začal re-design připravovat, snadno jsem mohl odpovědět na následující otázky:

  • V čem má lidem aplikace pomoci – jaké jsou jejich cíle a potřeby?
  • V čem stávající aplikace lidem efektivně nepomáhá a s čím mají problémy?
  • Co lidem ve stávající aplikaci chybí k dosažení efektivní práce?

Při analýze stávající aplikace jsem také využil metodu Task Analysis. Díky které jsem vytvořil Task Flow – jak lidé stávající aplikaci používají, co na které stránce hledají, jaké akce využívají, atp. A identifikoval tak problematická místa.

Informace jsem syntetizoval do myšlenkových map a matic. A následně snadno vytvořil seznam problémů. A určil jejich důležitost.

Na základě těchto syntetizovaných informací jsem připravil návrh nové mapy informační architektury. Kterou jsem tvořil od nejdůležitějších částí aplikace. Ty jsem následně spojil do větších celků, až jsem vytvořil kompletní mapu aplikace s objekty, přidruženými akcemi, atp.

Návrh informační architektury nové aplikace.
Návrh informační architektury nové aplikace.

Získal jsem tak celkový pohled na strukturu aplikace a většinu kritických stavů. A mohl tak začít tvořit koncepci aplikace a připravovat požadavky na změny ve funkcionalitě.

Výsledný koncept jsem dále validoval s uživateli, např. pomocí metody Reverse Card Sorting. U které jsem připravil různé sady úkolů, které má aplikace podporovat a které lidé potřebují splnit.

Ověřování informační architektury pomocí online metody Reversive Card Sorting.
Ověřování informační architektury pomocí online metody Reversive Card Sorting.

Získané informace jsem analyzoval a zapracoval případné úpravy. Čímž jsem získal vše potřebné pro detailnější návrhy aplikace.

Design aplikace

Koncepci aplikace jsem měl vytvořenou. Nyní jsem potřeboval finální podobu informační architektury a první koncepty uživatelského rozhraní.

Začal jsem tedy s generováním a syntetizováním nápadů na koncepci stránek formou skicování (s využitím metody 10 plus 10 ve spojení s metodou Design Studio).

Generování nápadů na koncepci, fungování a vizualizaci detailu projektu.
Generování nápadů na koncepci, fungování a vizualizaci detailu projektu.
Konkrétní koncepse stránek a flow jsem před dalšími kroky skicoval. Například zde je obrazovka detailu projektu.
Konkrétní koncepse stránek a flow jsem před dalšími kroky skicoval. Například zde je obrazovka detailu projektu.

Pro některé funkční celky jsem prozkoumal konkurenční řešení nebo podobné aplikace. Nechtěl jsem zbytečně vymýšlet kolo. K tomu jsem mimo jiné využil i literaturu a online galerie existujících vzorů. Např. knihu Designing Interfaces.

Na základě skic jsem vytvořil wireframy, u kterých jsem definoval i jednotlivé stavy, které mohou v aplikaci nastat. Například:

  • Nenahraje se celý obsah stránky.
  • Nenahraje se část stránky.
  • Nastane chyba v aplikaci.
  • Uživatel vloží neplatné informace do formuláře.

Výsledné wireframy jsem poté validoval s uživateli. Především abych získal odpovědi na otázky, např.:

  • Mají lidé vše, co potřebují?
  • Dokáží lidé najít požadované informace a rozumí všem popiskům?

A po případných úpravách jsem wireframy propojil v digitálním prototypu. A ověřoval jsem větší celky a flow.

Takto vypadal wireframe úvodní obrazovky, který jsem používal pro testování použitelnosti.
Takto vypadal wireframe úvodní obrazovky, který jsem používal pro testování použitelnosti.
Wireframe detailu projektu. Po testování použitelnosti jsem jej upravil.
Wireframe detailu projektu. Po testování použitelnosti jsem jej upravil.

Po ověření a úpravách jsem s vývojáři probral:

  • Náročnost implementace,
  • Zda prototyp obsahuje vše potřebné – jestli není potřeba něco domyslet.

Atp. Díky čemuž jsem mohl jednotlivé úkoly efektivněji plánovat.

Některé komplexní stavy aplikace jsem popsal do samostatného dokumentu nebo vytvořil tzv. Formal Process Flow diagramy. Což usnadnilo vyhodnocení implementace a vyjasnění fungování aplikace.

Konkrétní příklad designového řešení

Následující příklad demonstruje řešení jednoho problémů, se kterým má lidem aplikace pomoci.

  • Scénář: Uživatel potřebuje na server nahrát nový skript pro nahrávání dat do projektu.
  • Persona: Technický uživatel.

Aby mohl uživatel nahrát skript na server, musí splnit několik požadavků. Například:

  • Skript může nahrát pouze jako ZIP – díky čemuž může nahrát i více skriptů.
  • ZIP archiv musí být menší než 1 MB.

Doplňující informace

  • Uživatel má skript typicky uložený na svém lokálním počítači nebo v Gitu, který je opět přístupný přes lokální úložiště.
  • Ve svém projektu může mít více nahraných skriptů – od sebe nebo dalších uživatelů.
  • Uživatel může spravovat více projektů najednou.

Řešení problému

  • Identifikace míst, odkud bude nejjednodušší nahrát skript do projektu.
  • Navrhnout flow pro nahrání skriptu.
  • Navrhnout jednoduché a srozumitelné rozhraní.
Na základě mapy informační architektury jsem určil výsledná místa pro call-to-actions.
Na základě mapy informační architektury jsem určil výsledná místa pro call-to-actions.

Aplikace musí dále lidem umožnit:

  • Vybrat soubor na lokálním počítači.
  • Pojmenovat nově nahraný soubor – pro rozlišení od ostatních skriptů.

Pomocí jíž zmíněného Formal Process Flow diagramu jsem navrhl jednotlivé kroky, kterými uživatel projde pro úspěšné nahrání skriptu.

Formal process flow - aneb jak vypadal návrh možnosti nahrát skript na server.
Formal process flow – aneb jak vypadal návrh možnosti nahrát skript na server.

Takto vytvořené flow jsem následně převedl do uživatelské rozhraní včetně chybových hlášek a validací. A následně jsem jej s uživateli otestoval na použitelnost.

Výsledný dialog pro nahrávání skriptů. Design samozřejmě zahrnoval i validace a chybové hlášky.
Výsledný dialog pro nahrávání skriptů. Design samozřejmě zahrnoval i validace a chybové hlášky.

Implementace

Vedle designu jsem byl zodpovědný za prioritizaci a plánování funkcionality do 14-ti denních „SCRUM sprintů“. Plánování bylo rozděleno na dvě části:

  • Před-odhady – diskuze s vývojáři, jestli zadání obsahuje vše potřebné, jsou jasně definovaná akceptační kritéria a zda není potřeba rozdělit zadání do menších celků.
  • Finální odhady – přesné odhady vývojářů na základě uceleného zadání a rozplánování úkolů do jednotlivých sprintů.

Po finálním odhadu jsme ve spolupráci s Team Leaderem vývojářů připravili jednotlivé úkoly k implementaci a seřadili je podle priority.

Výsledný dialog pro nahrávání skriptů. Design samozřejmě zahrnoval i validace a chybové hlášky.
Zadání úvodní obrazovky v podobě hi-fidelity prototypu (v původním vizuálním stylu).
Výsledný dialog pro nahrávání skriptů. Design samozřejmě zahrnoval i validace a chybové hlášky.
Zadání detailu projektu v podobě hi-fidelity prototypu (v původním vizuálním stylu).

Po zahájení sprintů jsem s vývojáři jednotlivé úkoly diskutoval. Pokud bylo potřeba, upravili jsme zadání podle možností. Především abychom mohli funkcionalitu efektivně dokončit.

A jako poslední krok jsem naimplementovaný design ověřil ve spolupráci s vývojáři a QA engineerem.

Jak jsem naznačil v úvodu, celý proces byl iterativní. Vývojáři tedy začali připravovat technické a funkční úpravy během designové fáze. Například na základě skic nebo wireframu. A vždy určitou část, ne celou aplikaci. Ta byla dostupná pouze v podobě koncepce.

Během implementace definovaných částí jsem dále ověřoval a dotvářel ty zbývající. Které pak vývojáři implementovali v další iteraci.

Během tvorby aplikace jsem nebyl zodpovědný za implementaci. Protože však šlo o webovou aplikaci, pomáhal jsem vývojářům s drobnostmi u některých HTML/CSS částí, abychom funkcionalitu doručili v požadovaném stavu a v očekávaný termín.

Další vývoj produktu

V současné době aplikaci lidé každý den používají. Což neustále vyhodnocujeme a sledujeme, abychom jí mohli neustále zlepšovat.

Aktuálně připravujeme nové funkce, které jsme nestihli do aplikace dodat. A které mají pro uživatele velký přínos.

Co jsem se naučil

I když jsme neměli zrovna jednoduchý úkol, celý re-design vnímám velice pozitivně. Hodně jsme zlepšili předchozí aplikaci a sám jsem se na „projektu“ hodně naučil. Především díky tomu, že jsem musel velkou část re-designu řídit. Ne jen navrhovat.

Díky získaným zkušenostem se nyní mohu:

  • Rychleji rozhodovat,
  • Lépe fungovat pod stresem a větší pracovní zátěží.

Získané zkušenosti se nyní snažím využít u návrhu nových produktu, které v GoodData připravujeme. A mám pocit, že mi to jde mnohem lépe.


Sdílejte článek



Michal Maňák

Jmenuji se Michal Maňák, jsem Interaction Designer a Digital Product Designer.

Pracuji ve společnosti LMC.