Enterprise Navigation: Metodologii de proiectare pentru colaborarea părților interesate
Publicat: 2022-03-11Proiectarea (sau reproiectarea) unui sistem de navigație pentru întreprinderi nu este o sarcină luată cu ușurință. Aplicațiile pentru întreprinderi servesc un număr mare de utilizatori, găzduiesc o gamă largă de persoane și conțin un volum semnificativ de conținut și caracteristici. Unele aplicații de întreprindere au chiar și mai multe produse desktop și mobile bazate pe web, care trebuie să se integreze perfect pentru o experiență de utilizator mai plăcută.
Deși aceasta poate părea a fi o sarcină descurajantă sau chiar imposibilă gestionată cel mai bine de o echipă mare de „experți”, un arhitect de informare individual sau un designer UX poate aborda de unul singur o revizuire a designului UX al aplicației de întreprindere – atâta timp cât urmează o metodologie eficientă. pentru colaborarea părților interesate.
„Când mănânci un elefant, mușcă-te o dată.” - Creighton Williams Abrams Jr.
Despre Enterprise Navigation Design Systems
Diferențele principale dintre aplicațiile de întreprindere și sistemele web mai mici sunt volumul mare de conținut și varietatea de caracteristici. Acolo unde sistemele mai mici se pot baza în mod eficient pe un sistem de navigare relativ plat (adică, mai puține clicuri pentru a accesa tot conținutul), arhitectura aplicațiilor de întreprindere necesită adesea meniuri pe mai multe niveluri și mecanisme de orientare atent plasate. Cu cât sistemul de navigație este mai complex, cu atât este mai important ca sistemul în sine să fie ușor de utilizat, bine organizat și în concordanță cu modelul mental al utilizatorului.
Scopul final poate fi clar, dar dacă ar fi existat un design „perfect” pentru un sistem de navigație pentru întreprinderi, fiecare întreprindere l-ar fi adoptat. Fără un sistem perfecționat, există mult loc de îmbunătățire, creativitate și inovație. De asemenea, dezvăluie faptul că fiecare întreprindere este diferită, cu cazuri de utilizare și cerințe diferite pentru navigarea printr-o aplicație complexă.
Navigarea este pur și simplu „Găsire a drumului”
În principiu, navigarea este „orientare”. Navele maritime pot naviga într-un ocean larg deschis folosind stelele; călătorii terestre își pot găsi destinația cu ajutorul reperelor; și, utilizatorii de aplicații pentru întreprinderi își ating obiectivele finale bazându-se pe diverși indicatori digitali.
De exemplu, în universul digital, navigarea depinde de selecția și plasarea cuvintelor cheie, a etichetelor, a culorii, a iconografiei, a obiectelor de apel la acțiune și a altor indicatori de pe ecran. Când conținutul este prost organizat, caracteristicile sunt etichetate în mod neintuitiv, cuvintele cheie sunt selectate la întâmplare sau pictogramele sunt obtuze sau neconvenționale, utilizatorii pot deveni frustrați sau pierduți... și pot pleca pur și simplu.
Metodologie de colaborare în proiectarea navigației
Mediile de întreprindere sunt în mod inerent complexe și necesită multă organizare pentru a funcționa eficient. Nicio persoană nu poate cunoaște sau înțelege în mod intuitiv întregul domeniu de aplicare al unei aplicații de întreprindere sau așteptările unice și variate ale bazei de utilizatori. Există multe opinii cu privire la care livrabile sunt esențiale pentru orice metodologie de proiectare dată. Indiferent de ceea ce este creat în final, orice metodologie ar trebui să înceapă cu colaborarea părților interesate.
1. Reuniunea de lansare a părților interesate
Orice proiect la scară largă ar trebui să înceapă cu o întâlnire de lansare a părților interesate. În principiu, aceasta este o întâlnire mare cu toți jucătorii cheie prezenți (de la distanță sau la fața locului) pentru a porni proiectul. În mod obișnuit, o întâlnire de lansare a părților interesate are un singur facilitator care introduce obiectivele proiectului, identifică toate rolurile părților interesate și se adresează liderilor de proiect (dacă este cazul) pentru context suplimentar, astfel încât să poată începe colaborarea.
Cu cât echipa este mai mare, cu atât mai important este organizarea unei întâlniri oficiale de lansare a părților interesate. La fel ca și ceremonia de deschidere a Jocurilor Olimpice, acest punct de plecare oarecum ceremonial pentru un proiect arată clar tuturor părților interesate că „jocurile au început”.
În calitate de designer, cel mai bine este să obțineți lista părților interesate și rolurile acestora ca referință atunci când programați sesiuni de design de navigație și interviuri. Toți cei de pe această listă sunt importanți și valoroși pentru munca care trebuie făcută.
2. Cerul albastru Brainstorming
Cu toate părțile interesate identificate și implicate, găsiți timp pentru a vă întâlni în grupuri mai mici sau programați interviuri individuale pentru a desfășura sesiuni de brainstorming și ideație. Deschizând ușa pentru a visa la un viitor „cer albastru”, indivizii sunt mai puțin probabil să-și filtreze ideile sau opiniile, iar inovației i se oferă șansa de a-și deschide aripile.
În multe cazuri, blocaje istorice sau limitări nefondate pot persista în mintea părților interesate, dar nu mai există în realitate (datorită, de exemplu, noilor tehnologii, schimbărilor pe piață, modificărilor veniturilor generate de aplicația întreprinderii sau altor factori) . Atunci când părțile interesate împărtășesc preocupările cu privire la aceste bariere, încercați să întrebați „de ce” înainte de a le accepta așa cum sunt. S-ar putea să existe o oportunitate ascunsă aici.
Pentru a iniția acest proces de brainstorming, începeți cu câteva întrebări:
- Dacă ar fi să avansați cu 5 sau 10 ani în viitor, fără limitări sau blocaje, ce ați dori să vedeți în designul viitor?
- Ați avut idei – indiferent cât de ușor sau complicate – dar nicio oportunitate de a le aduce la viață?
- Dacă ai fi CEO-ul acestei companii, ce ai face în această situație?
- Vedeți nevoi pe piață care ar putea fi deservite de această aplicație?
Poate părea că această abordare ar deschide o „cutie de viermi”, dar atâta timp cât toată lumea are clar scenariul „cerului albastru”, se pot întâmpla lucruri grozave. Incearca!
3. Puncte dureroase și identificarea problemelor
Atunci când utilizatorii se confruntă cu durere sau frustrare când navighează printr-un sistem de întreprindere la scară largă pentru a găsi conținut sau funcții care ar trebui să fie mai ușor accesibile, acești utilizatori sunt mai susceptibili să renunțe și (uneori) să găsească o alternativă. Această alternativă poate fi cu un concurent.
Fii realist și agresiv în identificarea punctelor dureroase și a problemelor utilizatorului. Multe părți interesate au acces direct la feedback-ul utilizatorilor prin sondaje, sesiuni de formare și alte forme de comunicare. Folosiți aceste cunoștințe pentru a obține o mai bună înțelegere a modului în care sistemul actual de navigație al întreprinderii eșuează.
Aceste întrebări pot pune mingea în mișcare cu identificarea punctelor dureroase și a problemelor:
- De ce se plâng cel mai mult utilizatorii?
- Utilizați servicii (cum ar fi analiza traficului web sau urmărirea clicurilor) care urmăresc comportamentul utilizatorilor în sistem?
- Există zone ale sistemului de întreprindere care sunt rar utilizate și nu puteți explica de ce?
- Dacă ați putea schimba ceva la această aplicație, care ar fi?
O perspectivă asupra locurilor în care utilizatorii au probleme va juca un rol major în identificarea lacunelor în designul actual. Capturați aceste puncte pentru a le utiliza în această metodologie.
4. Diagramarea afinității
Ca designer, „notele lipicioase” pot fi cel mai bun prieten al tău. Dar dacă prea mulți stakeholderi nu sunt localizați în același birou sau sunteți singura resursă la distanță, note lipicioase de hârtie sunt folosite în zadar. Găsirea unei abordări eficiente pentru colaborarea online este esențială. Există o mare varietate de instrumente de colaborare online care pot fi folosite pentru a capta toate intrările din fazele de Brainstorming Blue Sky și Pain Points și Identificarea problemelor.
Odată ce ați capturat o cantitate semnificativă de intrare, următorul pas este să organizați acea intrare în grupuri de afinitate. Diagrama de afinitate este un exercițiu de colaborare care oferă tuturor părților interesate șansa de a găsi relații sau caracteristici comune între ideile individuale sau tipurile de conținut. Acest exercițiu îi permite unui designer să aducă împreună toate ideile „cerului albastru” și „punctele dureroase și problemele”.
De exemplu, ar putea ajuta să grupați conținutul proceselor și procedurilor într-o bibliotecă sau evenimentele curente și actualizările demne de știri într-un ziar online consolidat. Încurajați părțile interesate să fie creative în ceea ce privește modul în care formulează grupurile de afinitate.

În sesiunile de diagrame de afinitate ale părților interesate, adresați întrebări ca acestea:
- Ce caracteristici sau conținut se simt ca și cum ar fi împreună?
- Încearcă utilizatorii să întreprindă anumite acțiuni care ar fi mai ușoare dacă ar avea loc în succesiune?
- Există capabilități redundante care ar putea fi ușor îmbinate sau simplificate?
- Există vreo oportunitate de a potrivi ideile de cer albastru cu punctele sau problemele existente?
Încurajați părțile interesate să se gândească la scenarii specifice care aduc utilizatorii la o anumită caracteristică din sistem. Utilizarea scenariilor din viața reală pune lucrurile în perspectivă și facilitează pentru părțile interesate să fie empatici față de experiența utilizatorului.
5. Reorganizare logică
După ce exercițiul de diagramă de afinitate este finalizat, este important să faceți un pas înapoi și să priviți sistemul în mod holist. Există adesea o ordine logică a operațiunilor pe care un utilizator o poate urma în orice mediu complex dat. Luați în considerare cu atenție dacă există oportunități de a oferi un serviciu care nu este disponibil în prezent (inovație) sau de a încuraja un utilizator să-și extindă utilitatea sistemului de navigație al întreprinderii (descoperire) prin furnizarea de indicatori de orientare.
Pentru a surprinde această organizare logică sau ordine a operațiunilor, un designer poate crea o diagramă de flux sau, în scenarii mai complexe, o hartă a călătoriei utilizatorului, începând cu fluxul de lucru principal și apoi ramificându-se în alte conținuturi sau caracteristici.
Întrebările care ar putea încuraja părțile interesate includ:
- Acum că utilizatorul este „aici”, ce altceva poate face?
- Care este următoarea activitate logică pentru utilizator în acest scenariu?
- Pierdem vreo oportunitate de a rezolva problema utilizatorului din acest avantaj?
- Există caracteristici sau conținut care există în altă parte care ar putea fi utile în acest scenariu?
Odată ce ați început conversația pe acest subiect, colaborați cu părțile interesate pentru a rearanja grupurile de afinitate în consecință.
6. Ierarhie
În cadrul unui grup de afinitate mai mare sau între grupuri de afinitate individuale, probabil că vor exista relații sau dependențe. Lucrați cu părțile interesate pentru a identifica acele relații sau dependențe și apoi organizați-le în ierarhii. O ierarhie este pur și simplu un mod elegant de a descrie modul în care un conținut sau o caracteristică aparține unui grup de conținut sau caracteristici similare. De exemplu, un singur articol de știri aparține unui subiect, iar subiectul aparține unei secțiuni dedicate știrilor.
Avertizare!
În acest moment al procesului de proiectare, părțile interesate pot dori să folosească organizația departamentală corporativă existentă ca bază pentru ierarhia sistemului de întreprindere. Deși este ușor să imiteți organizația departamentală a întreprinderii (care este de obicei locul în care se află proprietatea asupra conținutului și funcțiilor), aceasta poate fi o greșeală imensă!
Utilizatorilor nu le pasă cine deține conținutul. Mai mult, deoarece întreprinderilor mari le place să se reorganizeze frecvent, sistemul de proiectare a navigației pentru întreprinderi care se aliniază cu organizarea departamentală nu va mai fi valabil de îndată ce apare prima „reorg”.
Folosiți metodologia prezentată până acum și respingeți această abordare periculoasă. Aceste întrebări pot ajuta la facilitarea unei conversații cu părțile interesate:
- Cum sunt legate aceste grupuri de afinitate și de ce sunt legate?
- Există vreo dependență între grupurile de afinitate pe care trebuie să le recunoaștem?
- Utilizatorii vor putea finaliza o sarcină fără a fi nevoiți să navigheze în altă zonă a sistemului?
- Există ierarhii convenționale care sunt familiare utilizatorilor din alte industrii sau modele de servicii care pot fi folosite ca referință?
În acest moment al procesului de proiectare, există multe modalități de a verifica dacă abordarea funcționează. Luați în considerare diferite metode de testare și cercetare a utilizatorilor pentru a vă confirma ierarhia sau pentru a identifica zonele cu probleme care necesită mai multă atenție.
7. Nomenclatură și parametri
Cu un model complet al viitoarei arhitecturi de aplicații de întreprindere, cunoscută și sub denumirea de arhitectură informațională, este timpul să selectați cuvintele cheie (nomenclatură) și să setați parametrii (definiții).
Nomenclatura, sau etichetarea, este un element important al proiectării navigației din trei motive principale: (a) nomenclatura este direct legată de SEO (optimizare pentru motoarele de căutare) prin aceea că motoarele de căutare caută în principal conținut după cuvinte cheie; (b) utilizarea terminologiei adecvate ca mecanism de orientare va ajuta utilizatorii să găsească ceea ce caută, servind drept „reper” digital; și (c) etichetele inteligente pot conduce utilizatorii către o zonă a sistemului care poate să nu fie ușor accesibilă dintr-o pagină de destinație sau o pagină de pornire. Capacitatea de găsire este determinată de mecanisme de orientare, cum ar fi etichetele. Dacă o etichetă este înșelătoare sau nu este intuitivă, este posibil ca utilizatorul să nu se obosească deloc să facă clic pe ea.
Cu toată nomenclatura (etichetele) identificată în modelul arhitecturii informaționale, colaborați cu părțile interesate pentru a defini parametrii (definițiile) pentru fiecare zonă etichetată din model. Acest lucru va asigura că conținutul și funcțiile aparțin unei anumite zone. În plus, acest exercițiu creează linii directoare pe termen lung pentru construirea arhitecturii aplicației de întreprindere, care va dura mai mult decât procesul de proiectare actual.
În ceea ce privește nomenclatura și parametrii, iată câteva întrebări de adresat părților interesate care vor conduce conversația:
- Ce caută cel mai des utilizatorii când vizitează?
- Este greu de găsit conținut sau caracteristică? De ce sunt greu de găsit?
- Există termeni din industrie sau limbaj care ar putea fi nefamiliari unor utilizatori, ceea ce le face mai greu să găsească ceea ce caută?
- Cum putem alege etichete care sunt convenționale sau mainstream?
După cum s-a menționat mai sus, există multe metode diferite care pot fi folosite pentru a testa nomenclatura, cum ar fi sortarea cardurilor, testarea A/B și UX orientat pe obiect (OOUX). Atunci când aveți de-a face cu un sistem de întreprindere foarte tehnic, cu o mulțime de limbaj din industrie, luați în considerare construirea unui vocabular controlat sau a unui glosar în sistem pentru referință de utilizator.
8. Integrarea cu procesul de proiectare a experienței utilizatorului
Având o imagine completă a viitoarei arhitecturi informaționale, acum este timpul să aplicăm rezultatele acestei metodologii procesului general de proiectare a experienței utilizatorului.
Deși pot exista zone ale noului sistem de navigație pentru întreprinderi care nu există atunci când proiectul de proiectare este în zbor, acele zone pot fi „dezactivate” sau ascunse până când conținutul sau caracteristicile sunt gata pentru a fi lansate. Apoi, după ce proiectantul a trecut mai departe, părțile interesate pot continua să construiască sistemul spre visele lor de „cer albastru”.
„Dacă îl construiești, [ei] vor veni.” - Câmpul Viselor, 1989.
Concluzia
Proiectarea unui sistem de navigație pentru întreprinderi nu este o sarcină ușoară. Cu toate acestea, valorificarea cunoștințelor părților interesate va face ca acest efort să fie gestionabil.
Lăsând deoparte complexitatea proiectelor de proiectare la scară largă, scopul este întotdeauna să țină cont de utilizator. Cu o abordare practică a cercetării utilizatorilor și punând întrebări inteligente persoanelor care au contact direct cu utilizatorul, chiar și un designer de la distanță, singur sau independent poate rezolva probleme mari de design. Nu vă lăsați intimidați – doar faceți lucrurile pas câte un pas.