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.
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.
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.
Pokud se na re-design podívám ze svého pohledu, skládal se z několika částí:
- Tvorba koncepce a výzkum,
- Design aplikace,
- 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:
- Deničkové studie,
- Contextual inquiries,
- Rozhovory s uživateli,
- Webová analytika.
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.
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.
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.
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).
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.
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í.
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.
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.
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.
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.
Pěkná práce. Jen mi přijde, že je okolo spousta sraní. 🙂 Teda peněz.
Nechceš se víc rozepsat o tom Task Analysis? Docela by mne zajímal konkrétní postup, jak jsi došel k té IA.
Jinak mne trochu překvapuje, že zapojení vývoje probíhalo až po designové fázi a ne před ní nebo během ní. Stejně tak prioritizace. Ale asi je to tím, že to není web, ale inhouse produkt a proces se bude zřejmě právě v tomto lišit.
Ošklivý sup: klidně mohu. Je to hodně užitečná metoda. Dost se o ní zmiňuje například Gerry McGovern (http://www.gerrymcgovern.com/).
Vývoj byl iterativní. Vývojáři znali koncepci a implementovali vždy části aplikace. Například na základě skic začali připravovat back-endové úpravy, atp. Nedostali k implementaci prototyp celé aplikace. To bychom nestihli v tak krátkém čase. Dopsal jsem to do článku :).
Jarka: Díky za komentář :). Něco to samozřejmě stálo. Ale kvalita vždy něco stojí. Především pokud děláme produkty pro lidi. Ve výsledku vyjde levněji udělat produkt pořádně, než jej později nákladně předělávat a opravovat chyby.
Co by se podle tebe dalo udělat efektivněji nebo které kroky Ti přijdou zbytečné?
Ahoj,
klobouk dolů, vypadá to mnohem jednodušeji – super „behind the scene“.
Mam 2 dotazy k blogpostu
1. Jak vypadala aplikace před redesignem? Mam pocit, že žádná nebyla nebo bylo sofistikovane ukryta.
2. Nebylo by to celé podstatně jednodušší, kdyby se na návrhu podílel někdo z manage service týmu?
A jednu inspirovanou:
– kdy budeme my, uživatelé GoodData, moct používat Google Analytics k tomu, abysme mohli obdobně jako ty sbírat data o tom co dělají naší zákazníci na dashboardech?
Diky a držím palce!
Petr
P. S. Drobná UX k blogu: jak se dozvím, že přibyl komentář? Píšu z hor přes mobil a nemam kam dát svůj email.
Petr Simecek: ahoj, díky za komentář :).
1. Aplikace byla a hrubou podobu ukazují první dva screenshoty
2. Lidé z Manage Services (a Consultingu) se na návrhu podíleli. Konzultoval a procházel jsem s nimi vše. Nejsou ale jediní, kdo aplikaci používají.
A k jedné inspirativní: nejsem si jist, jestli to mohu prozradit veřejně :).
A k Tvému druhému komentáři: tuto možnost doufám brzy na blog přidám.
Díky za odpovědi!
K inspirativní: takže příští vánoce nejdřív? 🙂
Asi dobrá práce, votom nic. Ale i když chápu, že je třeba se prezentovat, tak by to šlo udělat mnohem méně jájínkově… Obsah dobrý, forma děsná.
pilkr: ahoj, díky za komentář. Článek jsem psal ze svého pohledu designera. A protože jsem byl v podstatě jediný designer při tomto re-designu, vzešla z toho taková forma. Když bych popisoval konkrétně i imlementaci, určitě by to dopadlo jinak.
Když jsou uživatelé ajťáci, kteří si ty skripty někdy ukládají i v lokálním GITu, tak proč jim nenabídnout i GIT rozhraní, pomocí kterého by mohli ze svého repozitáře nahrát nové verze přímo do aplikace pomocí GIT remote? Myslím, že u lidí, co ten GIT umí používat, by byl celý proces výrazně jednodušší.
Pro ty, co GIT nepoužívají, proč je nutíte celý adresář nejdříve zazipovat? Dnešní browsery jsou schopné pracovat s celými adresáří (uživatel jej musí vybrat systémovým dialogem nebo drag&drop)
Jan Pobořil: díky za komentář. Na daném příkladu jsem chtěl demonstrovat postup.
Naše uploadovací API využívá i další aplikace, která soubory automaticky komprimuje za uživatele. A právě skripty nejsou jediným typem, který lidé nahrávají. U dalších typů je potřeba nahrát i podsložky, které bohužel nejde formulářem nahrát (zkoušel jsem to, nahrají se pouze soubory). Takže je jednodušší, když si vytvoří balík a ten celý nahrají.
Ne všichni uživatelé jsou čistí ajťáci. Takže ne vždy využívají GIT. Ale moc díky za tip s GIT remote. O tom jsem nevěděl a mohli bychom tak lidem práci usnadnit. Zkusím se na to zeptat vývojářů. A zkusím víc zjistit o tom, do jaké úrovně GIT lidé používají. Protože jsme identifikovali jiné workflow.
Super! Libi se mi proces i metody, ktere v nem pouzivas…
Par dotazu:
– Do jake miry ti pomohly denicky, a jake informace ti daly navic oproti contextual inquiries?
– Do jake miry jsi pri tomhle projektu take ziskal informace, ktere vyuzijes pro dalsich projektech (napriklad navrhu/redesignu jinych nastroju)?
– Pokud bude tvuj pristi projekt obdobny, pouzijes stejny proces a metody, nebo nektere vynechas/nahradis/pridas? Zajimalo by me tvoje zpetne zhodnoceni tohohle procesu, ktery jsi tu popsal.
Diky!
Petr Kosnar: ahoj Petře. Jsem rád, že se ti můj proces líbí. A taky díky za skvělé otázky, na které se ti pokusím odpovědět:
– Díky deníčkům jsem jsem získaval pravidelnou zpětnou vazbu i k menším věcem. Největší přidaná hodnota deníčků byla v tom, že jsem mohl sledoval, jaké mají lidi návyky, proč, atd. Což jsem právě při Contextual Inquiries nemohl tak snadno zjistit. Díky CI jsem naopak zjistil, s čím vším pracují, s kým a o čem diskutují, atp. Díky kombinaci obou metod jsem tak získal mnohem detailnější pohled na práci a život lidí, kteří danou aplikaci používají.
– Získal jsem informací dost. V podstatě je mohu využít i pro další nástroje. A využívám, protože v GoodData připravujeme další nástroj pro nahrávání dat. Který bude doufám pomáhat lidem v co největší efektivitě. Což se snad podle prvních ohlasů na koncepci povede :). Pro jiné aplikace než nahrávání dat (a s tím spojené věci) však informace moc použitelné nejsou. Samotná doména je dost odlišná od toho, co je potřeba umět a znát. A pro jiné lidi je potřeba produkt navrhovat jinak.
– Protože už na dalším projektu pracujeme, snažil jsem se využít informací, které jsem nasbíral. Ale protože bude muset sloužit více cílových skupin, proces jsem trochu pozměnil – hlavně ze začátku. Ještě před stavbou koncepce jsem hledal informace formou rozhovorů, zkoumal jsem konkurenční produkty, atp. Taky jsem se snažil uživatele zapojit co nejdřív – v podstatě zkusit tzv. participatory design. A stavěl koncepci s nimi a ve spolupráci se SME. Až budeme mít hotový první milestone (v podstatě hotový prototyp), rád bych udělal větší výzkum a opět zapojil třeba deníčky. Protože to nejde bez sledování reálného použití. Je to dost komplikovaný produkt, který se hrozně špatně mockupuje (ale i to jsem udělal, protože jsem potřeboval ověřit koncepci). Snad o tom taky něco napíšu :).
A když bych se měl trochu ohlédnout zpátky, věřím, že jsme zvolili správný postup – jak v designovém, tak i implementačním řešení. Pár míst nebylo efektivních. Například při řešení technických omezení, ke kterým jsme se dostali až těsně před implementací front-endu. A to jsem se kluky vývojáře snažil zapojovat co nejdřív. Ale to se nikdy neodhadne. Proto jsme na větší celky začali dělat technické analýzy.
Vedle toho re-designu jsem také musel dodávat design pro další aplikaci, kterou v GoodData máme. Takže jsem se musel hodně otáčet, aby to klapalo. Takže bude moje hodnocení možná trochu zkreslené. Ale zase jsem byl na druhou stranu dost efektivní.
Snad jsem ti odpověděl na všechno :). Klidně se zeptej, pokud bys na něco chtěl konkrétnější info.