Navrhovanie (alebo redizajnovanie) podnikového navigačného systému nie je úlohou, ktorá sa berie na ľahkú váhu. Podnikové aplikácie slúžia veľkému počtu používateľov, sú prispôsobené širokému spektru osôb a obsahujú značný objem obsahu a funkcií. Niektoré podnikové aplikácie majú dokonca aj viac webových a mobilných produktov, ktoré je potrebné bezproblémovo integrovať, aby ste užívateľom dosiahli príjemnejšiu skúsenosť.

Aj keď sa to môže javiť ako skľučujúca alebo dokonca nemožná úloha, ktorú najlepšie zvládne veľký tím „odborníkov“, sólový informačný architekt alebo návrhár UX môžu bez problémov vyriešiť generálnu opravu podnikového návrhu UX dizajnu, pokiaľ bude dodržiavať efektívnu metodiku pre spoluprácu so zainteresovanými stranami.

'Keď jedieš slona, ​​sústo po jednom.' - Creighton Williams Abrams Jr.

O Enterprise Navigation Design Systems

Primárnymi rozdielmi medzi podnikovými aplikáciami a menšími webovými systémami sú obrovský objem obsahu a množstvo funkcií. Tam, kde sa menšie systémy môžu efektívne spoliehať na relatívne plochý navigačný systém (t. J. Menej kliknutí na prístup k celému obsahu), vyžaduje architektúra podnikových aplikácií často viacúrovňové ponuky a starostlivo umiestnené mechanizmy hľadania cesty. Čím je navigačný systém zložitejší, tým dôležitejšie je, aby bol samotný systém ľahko použiteľný, prehľadný a zosúladený s pokynmi používateľa. mentálny model .

Konečný cieľ môže byť jasný, ale ak by existoval „dokonalý“ dizajn podnikového navigačného systému, každý podnik by si ho osvojil. Bez dokonalého systému existuje veľký priestor pre zlepšovanie, tvorivosť a inovácie. Odhaľuje tiež skutočnosť, že každý podnik je iný, s rôznymi prípadmi použitia a požiadavkami na navigáciu v zložitej aplikácii.

Navigácia je jednoducho „hľadanie cesty“

Navigácia je v zásade „hľadaním cesty“. Námorné lode môžu navigovať v šírom oceáne pomocou hviezd; cestujúci na pevnine môžu nájsť svoj cieľ pomocou pamiatok; a používatelia podnikových aplikácií dosahujú svoje konečné ciele spoliehaním sa na rôzne digitálne ukazovatele.

Napríklad v digitálnom vesmíre závisí navigácia od výberu a umiestnenia kľúčových slov, štítkov, farieb, ikonografie, objektov výzvy na akciu a ďalších indikátorov na obrazovke. Ak je obsah zle organizovaný, funkcie sú neintuitívne označené, kľúčové slová sú vybrané náhodne alebo ikony sú tupé alebo nekonvenčné, používatelia môžu byť frustrovaní alebo stratení ... a môžu jednoducho odísť.

Systém londýnskeho metra je komplexná sieť rúrok a tunelov. Vďaka dobre navrhnutému navigačnému systému je však používateľská skúsenosť jednoduchá a ľahko pochopiteľná. ( Zdroj )

Metodika spolupráce pri návrhu navigácie

Podnikové prostredia sú vo svojej podstate zložité a na efektívne fungovanie si vyžadujú veľkú organizáciu. Žiadna osoba nemôže intuitívne poznať alebo pochopiť celý rozsah podnikovej aplikácie alebo jedinečné a rozmanité očakávania jej užívateľskej základne. Existuje veľa názorov týkajúcich sa ktoré výstupy sú nevyhnutné podľa akejkoľvek danej metodiky návrhu. Bez ohľadu na to, čo sa nakoniec vytvorí, akákoľvek metodika by mala začínať spolupráca zainteresovaných strán .

1. Stretnutie Kickoff zainteresovaných strán

Akýkoľvek rozsiahly projekt by mal začínať a úvodné stretnutie zainteresovaných strán . V zásade ide o veľké stretnutie so všetkými kľúčovými účastníkmi (na diaľku alebo na mieste), ktorí sa zúčastnia projektu, aby mohli začať projekt. Na úvodnom stretnutí zainteresovaných strán je zvyčajne jediný sprostredkovateľ, ktorý predstaví ciele projektu, identifikuje všetky roly zainteresovaných strán a v prípade potreby sa odvoláva na vedenie projektu (v prípade potreby) pre ďalší kontext, aby mohla začať spolupráca.

Čím je tím väčší, tým dôležitejšie je usporiadať oficiálne úvodné stretnutie zainteresovaných strán. Rovnako ako úvodný ceremoniál olympiády, aj tento trochu slávnostný východiskový bod projektu objasňuje všetkým zainteresovaným stranám, že „hry sa začali“.

Ako dizajnér je najlepšie získať zoznam zúčastnených strán a ich rolí ako referenciu pri plánovaní relácií a rozhovorov o navigačnom dizajne. Každý, kto je na tomto zozname, je dôležitý a cenný pre prácu, ktorú je potrebné vykonať.

2. Brainstorming na modrej oblohe

Ak sú všetky zainteresované strany identifikované a zapojené, nájdite si čas na stretávanie sa v menších skupinách alebo si naplánujte individuálne rozhovory na uskutočnenie brainstormingu a nápadov. Otvorením dverí snívajúcich o budúcnosti „modrej oblohy“ je menej pravdepodobné, že by jednotlivci filtrovali svoje nápady alebo názory a inovácia dostala príležitosť roztiahnuť krídla.

V mnohých prípadoch môžu v hlavách zainteresovaných strán pretrvávať historické prekážky alebo nepodložené obmedzenia, ktoré však v skutočnosti už neexistujú (napríklad kvôli novej technológii, zmenám na trhu, zmenám v príjmoch generovaných podnikovou aplikáciou alebo inými faktormi). . Ak zainteresované strany zdieľajú obavy z týchto prekážok, skúste sa ich opýtať „prečo“ skôr, ako ich prijmete také, aké sú. Môže tu byť skrytá príležitosť.

Na zahájenie tohto procesu brainstormingu začnite niekoľkými otázkami:

1. Ak by ste sa mali posunúť vpred o 5 alebo 10 rokov do budúcnosti bez obmedzení alebo blokovania ostatných ciest, čo by ste chceli vidieť v budúcom dizajne?
2. Mali ste nejaké nápady - bez ohľadu na to, aké ľahké a zložité - ale nemáte príležitosť ich uviesť do života?
3. Keby ste boli generálnym riaditeľom tejto spoločnosti, čo by ste robili v tejto situácii?
4. Vidíte na trhu nejaké potreby, ktoré by mohla uspokojiť táto aplikácia?

Môže sa zdať, že tento prístup by otvoril „plechovku červov“, ale pokiaľ budú mať všetci jasno v scenári „modrej oblohy“, môžu sa stať veľké veci. Pokúsiť sa!

Malé skupinové alebo individuálne brainstormingové stretnutia môžu odhaliť historické prekážky a vytvoriť nápady „modrej oblohy“, ktoré môžu podporiť inováciu.

3. Body bolesti a identifikácia problému

Ak používatelia pociťujú bolesť alebo frustráciu z prechádzania rozsiahlym podnikovým systémom, aby našli obsah alebo funkcie, ktoré by mali byť ľahšie dostupné, je pravdepodobnejšie, že sa títo používatelia vzdajú a (niekedy) nájdu alternatívu. Táto alternatíva môže byť u konkurencie.

Pri identifikácii bolestivých bodov a problémov používateľov buďte realistickí a agresívni. Mnoho zainteresovaných strán má priamy prístup k spätnej väzbe od používateľov prostredníctvom prieskumov, školení a iných foriem komunikácie. Využite tieto znalosti na lepšie pochopenie toho, ako zlyháva súčasný podnikový navigačný systém.

Tieto otázky môžu dostať loptu do pohybu pomocou identifikácie bolestivých bodov a problémov:

1. Na čo sa používatelia sťažujú najviac?
2. Používate nejaké služby (napríklad analýza webového prenosu alebo sledovanie kliknutí), ktoré sledujú správanie používateľov v systéme?
3. Existujú oblasti podnikového systému, ktoré sa používajú zriedka, a nemôžete vysvetliť prečo?
4. Keby ste mohli niečo zmeniť na tejto aplikácii, čo by to bolo?

Pri identifikácii medzier v súčasnom dizajne bude hrať hlavnú úlohu prehľad o tom, kde majú používatelia problémy. Zachyťte tieto body pre použitie v tejto metodike.

4. Afinitné diagramy

Ako dizajnér môžu byť „lepiace poznámky“ vašim najlepším priateľom. Ak však príliš veľa zainteresovaných strán nie je umiestnených v tej istej kancelárii alebo ste jediným vzdialeným zdrojom, papier márne sa používajú lepiace poznámky. Nájsť efektívny prístup pre online spoluprácu je zásadné. Existuje široká škála nástrojov online spolupráce ktoré možno použiť na zachytenie všetkých vstupov z fáz Brainstormingu a Bolestí modrej oblohy a Fáza identifikácie problému.

Keď ste zachytili značné množstvo vstupov, ďalším krokom je usporiadanie týchto vstupov do afinitných skupín. Afinitné diagramy je cvičenie spolupráce, ktoré umožňuje všetkým zúčastneným stranám šancu nájsť vzťahy alebo zdieľané prvky medzi jednotlivými nápadmi alebo typmi obsahu. Toto cvičenie umožňuje návrhárovi spojiť všetky nápady a „bolestivé body a problémy“ týkajúce sa „modrej oblohy“.

Napríklad by to mohlo pomôcť zoskupiť obsah procesov a procedúr do knižnice alebo aktuálne udalosti a novinky hodné aktualizácií do konsolidovaných online novín. Nabádajte zainteresované strany, aby boli kreatívne pri formulovaní príbuzných skupín.

Na reláciách diagramov záujmov zainteresovaných strán položte otázky, ako sú tieto:

1. Ktoré funkcie alebo obsah majú pocit, že patria k sebe?
2. Pokúšajú sa používatelia podniknúť určité kroky, ktoré by boli jednoduchšie, keby k nim došlo postupne?
3. Existujú nejaké nadbytočné možnosti, ktoré by sa dali ľahko zlúčiť alebo zjednodušiť?
4. Existuje nejaká príležitosť spojiť nápady na modrej oblohe s existujúcimi problémami alebo problémami?

Nabádajte zainteresované strany, aby premýšľali o konkrétnych scenároch, ktoré používateľov dovedú k danej funkcii v systéme. Používanie scenárov z reálneho života dáva veci do perspektívy a uľahčuje zúčastneným stranám byť empatický voči používateľskej skúsenosti .

Afinitné diagramy pomáhajú tímom porozumieť mnohým kvalitatívnym údajom a vytvárať jasné a realizovateľné ďalšie kroky pre vývoj architektúry podnikových aplikácií.

5. Logická reorganizácia

Po dokončení cvičenia afinitného diagramu je dôležité ustúpiť a pozrieť sa na systém holisticky. Často existuje logické poradie operácií, ktoré môže užívateľ sledovať v akomkoľvek danom zložitom prostredí. Starostlivo zvážte, či existujú príležitosti na poskytnutie služby, ktorá nie je v súčasnosti k dispozícii (inovácia), alebo na povzbudenie používateľa, aby rozšíril svoju užitočnosť podnikového navigačného systému (objavovanie) poskytnutím ukazovateľov hľadania cesty.

Na zachytenie tejto logickej organizácie alebo poradia operácií môže návrhár vytvoriť vývojový diagram alebo v zložitejších scenároch a mapa cesty používateľa , počnúc primárnym pracovným tokom, a potom odbočením na iný obsah alebo funkcie.

Medzi vaše zainteresované strany môžu patriť napríklad tieto otázky:

1. Teraz, keď je používateľ „tu“, čo môže ešte robiť?
2. Aká je ďalšia logická aktivita pre používateľa v tomto scenári?
3. Nechýba nám z tejto výhody nejaká príležitosť vyriešiť problém používateľa?
4. Existujú inde funkcie alebo obsah, ktoré by mohli byť užitočné v tomto scenári?

Keď sa dostanete do konverzácie týkajúcej sa tejto témy, spolupracujte so zainteresovanými stranami na príslušnom usporiadaní skupín záujmov.

6. Hierarchia

V rámci väčšej afinitnej skupiny alebo medzi jednotlivými afinitnými skupinami pravdepodobne budú existovať vzťahy alebo závislosti. Spolupracujte so zainteresovanými stranami na identifikácii týchto vzťahov alebo závislostí a potom ich usporiadajte do hierarchií. Hierarchia je jednoducho efektný spôsob popisu, ako časť obsahu alebo funkcia patrí do skupiny podobného obsahu alebo funkcií. Napríklad jeden spravodajský článok patrí k téme a téma patrí do sekcie venovanej novinkám.

Skupiny záujmov odhaľujú vzťahy medzi informáciami a môžu byť prvým krokom pri definovaní architektúry podnikových aplikácií.

Výstraha!

V tomto bode procesu návrhu môžu zainteresované strany chcieť použiť existujúcu organizáciu podnikového oddelenia ako základňu pre hierarchiu podnikových systémov. Aj keď je ľahké napodobniť organizáciu podnikových oddelení (čo je typická oblasť, kde spočíva obsah a vlastníctvo funkcií), môže to byť veľká chyba!

Používateľom je jedno, komu patrí obsah. Navyše, keďže veľké podniky rád reorganizujem často , systém podnikovej navigácie, ktorý je v súlade s organizáciou rezortu, už nebude platný, akonáhle dôjde k prvému „preorigovaniu“.

Využite doteraz predstavenú metodiku a potlačte tento nebezpečný prístup. Tieto otázky môžu pomôcť uľahčiť rozhovor so zainteresovanými stranami:

1. Ako spolu súvisia tieto afinitné skupiny a prečo?
2. Existujú nejaké závislosti medzi afinitnými skupinami, ktoré musíme uznať?
3. Budú používatelia schopní dokončiť úlohu bez toho, aby museli prechádzať do inej oblasti systému?
4. Existujú bežné hierarchie, ktoré sú známe používateľom z iných priemyselných odvetví alebo modelmi služieb, ktoré je možné použiť ako referenciu?

V tomto bode procesu návrhu existuje veľa spôsobov, ako overiť, či prístup funguje. Zvážte rôzne metódy testovania a výskumu používateľov, aby ste potvrdili svoju hierarchiu alebo identifikovali problémové oblasti, ktoré si vyžadujú väčšiu pozornosť.

7. Nomenklatúra a parametre

S kompletným modelom budúcej podnikovej architektúry aplikácií - známej tiež ako informačná architektúra —Je čas na výber kľúčových slov (nomenklatúra) a nastavenie parametrov (definícií).

Nomenklatúra alebo označovanie je dôležitým prvkom návrhu navigácie z troch hlavných dôvodov: a) nomenklatúra priamo súvisí so SEO (optimalizácia pre vyhľadávače), pretože vyhľadávače vyhľadávajú predovšetkým obsah podľa kľúčových slov; b) používanie správnej terminológie ako mechanizmu hľadania cesty pomôže používateľom nájsť to, čo hľadajú, a slúži ako digitálny „orientačný bod“; a (c) inteligentné štítky môžu viesť používateľov do oblasti systému, ktorá nemusí byť ľahko prístupná z primárnej vstupnej stránky alebo domovskej stránky. Nájditeľnosť je poháňaný mechanizmami hľadania cesty, ako sú štítky. Ak je štítok zavádzajúci alebo nie je intuitívny, používateľ sa nemusí obťažovať s jeho kliknutím vôbec.

So všetkou nomenklatúrou (štítkami) identifikovanou v modeli informačnej architektúry spolupracujte so zainteresovanými stranami na definovaní parametrov (definícií) pre každú označenú oblasť v modeli. Takto zabezpečíte, že obsah a funkcie patria do konkrétnej oblasti. Toto cvičenie navyše vytvára dlhodobé pokyny pre budovanie architektúry podnikových aplikácií, ktoré prekonajú súčasný proces návrhu.

Pokiaľ ide o nomenklatúru a parametre, je tu niekoľko otázok, ktoré je potrebné položiť zainteresovaným stranám, ktoré budú viesť konverzáciu:

1. Čo používatelia najčastejšie vyhľadávajú, keď navštívia?
2. Je ťažké nájsť nejaký obsah alebo funkcie? Prečo sa ťažko hľadajú?
3. Existujú odvetvové výrazy alebo výrazy, ktoré by mohli byť niektorým používateľom neznáme, čo im sťažuje hľadanie toho, čo hľadajú?
4. Ako si môžeme vybrať štítky, ktoré sú bežné alebo bežné?

Ako už bolo uvedené, existuje veľa rôznych metód, ktoré možno použiť na testovanie nomenklatúry, ako napr triedenie kariet , A / B testovanie a objektovo orientované UX (OOUX) . Keď pracujete s vysoko technickým podnikovým systémom s hromadou priemyselných žargónov, zvážte vybudovanie a riadená slovná zásoba alebo systémový glosár pre referenciu používateľa.

8. Integrácia s procesom návrhu používateľskej skúsenosti

S úplným obrazom budúcej informačnej architektúry je čas aplikovať výsledky tejto metodiky na celok proces návrhu používateľskej skúsenosti .

Návrh navigácie sa integruje priamo do väčšieho projektu dizajnu UX.

Hoci v novo razenom podnikovom navigačnom systéme môžu existovať oblasti, ktoré neexistujú, keď je návrhový projekt v prevádzke, môžu byť tieto oblasti „deaktivované“ alebo skryté, kým nebude pripravený obsah alebo funkcie na vydanie. Potom, ako návrhár prešiel, môžu zainteresované strany pokračovať v budovaní systému smerom k ich snom o „modrej oblohe“.

'Ak ho postavíte, [oni] prídu.' - Pole snov, 1989.

Spodný riadok

Návrh podnikového navigačného systému nie je ľahká úloha. Využitie znalostí zainteresovaných strán však umožní toto úsilie zvládnuť.

Odhliadnuc od zložitosti rozsiahlych dizajnových projektov je cieľom vždy mať na pamäti používateľa. Vďaka praktickému prístupu k užívateľskému výskumu a kladeniu múdrych otázok ľuďom, ktorí majú priamy kontakt s používateľom, zvládne veľké problémy s dizajnom aj vzdialený, sólový alebo nezávislý dizajnér. Nenechajte sa zastrašiť - robte veci krok za krokom.