Fenntartható stratégia a technikai adósság ellen
Bármely szoftvertermék életciklusa során bizonyos mennyiségű tervezési tartozás felhalmozódik. Új funkciókat adunk hozzá, a régiek elavulnak; ahogy a tervezési nyelvünk és a felhasználóinkról alkotott kép fejlődött, a termék egyes interfészei frissítésre szorulnak az új gondolkodásmód beépítése érdekében. Az egyes problémák önmagukban jelentéktelennek tűnhetnek, és nem jelentenek prioritást a javításukban. Ezek a problémák összességükben viszont frusztrált ügyfelekhez, hatékonytalan és időigényes munkafolyamatokhoz és a termékbe vetett bizalom csökkenéséhez vezethetnek, ha nem foglalkoznak velük.
A „technikai adósság” kifejezést a technológia fenntartásának megnövekedett költségeinek leírására használjuk a fejlesztési folyamat során.
Fenntartható stratégia létrehozása a termékszintű UX-adósság kezelésére
- A „technikai adósság” kifejezést Ward Cunningham alkotta meg, mint metaforát, amelyet a technológia fenntartásának megnövekedett költségeinek leírására használnak a fejlesztési folyamat során alkalmazott rövidítések miatt.
-
Joshua Kerievsky később kiterjesztette a metaforát a felhasználói élménytervezésre a „felhasználói élmény (UX) adósság” kifejezéssel. Kerievsky kifejtette, hogy a technikai adóssághoz hasonlóan a UX-adósság is idővel esedékessé válik, általában a vevői elégedettség csökkenése és esetleges vevői hibák formájában.
Ez azt jelenti, hogy nem minden UX-adósság egyforma. A tervezési problémák univerzuma a látszólag triviálisnak tűnő javításoktól (némi távolságtartás javítása, néhány rendszerüzenet javítása) egészen az újratervezést igénylő teljes munkafolyamatokig terjedhet. A legtöbb beszélgetés során a csapatok az egyik vagy a másik megközelítést választják; az UX-adósság vagy bizonyos UI-elemek kisebb javítását jelenti, vagy pedig több teljes munkafolyamat újratervezésének szükségességét. Az UX-adósságnak ez a tipikus megfogalmazása problémákat okoz a prioritások meghatározásában. A probléma vagy túl kicsi/triviális ahhoz, hogy prioritásként kezeljék, vagy olyan nagy, hogy a csapat nem akarja megkockáztatni, hogy dolgozzon rajta.
Először is beszéljünk arról, hogy mi az UX adósság – és mi nem az
- A mi csapatunkban az „UX-adósság” fogalmát úgy határozzuk meg, mint minden olyan tervezési probléma, amely befolyásolja a felhasználó munkájának pontosságát, hatékonyságát vagy felfedezhetőségét, vagy amely befolyásolja a termékünk hitelességét a felhasználók számára. Ez származhat következetlen interakcióból vagy vizuális tervezésből, nem megfelelő rendszerüzenetekből vagy bizonyos feladatok elvégzéséhez szükséges túlzott kognitív terhelésből.
Ezt szem előtt tartva szükségünk volt egy strukturált módszerre, hogy:
- meghatározzuk a kezelt adósságtípusokat és -kört;
- az adósságállomány tárolása és rangsorolása a termék ütemterv többi részével együtt;
- meghatározni, hogyan lehet nyomon követni a tartozások „kifizetését” a sprintek és kiadások között;
- a beszélgetések középpontjában a konstruktív, kezelhető dolgok álltak, amelyeket meg tudtunk javítani, miközben azt is figyelembe vettük, hogy hol voltak célszerűbbek a nagyobb újratervezések.
Más szóval, ha a csapat elkötelezi magát az UX-adósságok visszafizetése mellett, az adósságokat először is világosan meg kell határozni, katalogizálni és rangsorolni kell – nem pedig az UX-problémák amorf csoportjába kell tömöríteni.
Az UX-adósság azonosítása a probléma terjedelme szerint
A csapattal folytatott megbeszélések során a definíciókat két alapvető jellemző köré szerveztük: a hatókör (mennyire nehéz/könnyen javítható) és a hely (globális vs. helyi). Ezután az adósságok minden egyes típusát különböző módon lehet kezelni, ami megkönnyíti a csapatok számára a munka rangsorolását a nagyobb terméklistához képest. Az adósságok ezen típusait az alábbiakban soroljuk fel:
1. Gyors győzelem
Mi ez? Egy olyan UX-probléma, amely viszonylag kis terjedelmű, és egyértelmű javítással rendelkezik, amelyet egy fejlesztő és egy tervező egyetlen sprint alatt, minimális artefaktum vagy előzetes tervezés nélkül megvalósíthat. Az ilyen típusú adósságok közé tartozhat például a hibaüzenetek vagy az oktatószövegek frissítése, vagy apróbb elrendezési finomítások, például a térközök vagy a színmeghatározás.
Mit teszünk ellene: a lehető legtöbb, ugyanazt a képernyőt érintő problémát egyesítjük egy JIRA-jegybe, amelyet a backlogban prioritásként lehet kezelni.
2. Optimalizálás
Mi ez: Olyan UX-probléma, amely helyi jellegű (egyetlen elemet vagy egyetlen képernyő egy darabját érinti), van egy világosan érthető megoldása, amelynek megvalósítása nem triviális mennyiségű munkát igényel a tervezés vagy a fejlesztés részéről, de egy-két sprint alatt megoldható. Ilyen típusú adósság lehet például egy régi UI-mintázat frissítése a Forge tervezési rendszerünk egyik mintázatának használatára, vagy egy jelölőnégyzetekből álló mező módosítása többszörös választólista használatára.
Mit teszünk ellene: Világosan meghatározzuk a jelenlegi és az elvárt állapotot, és JIRA-jegyként hozzáadjuk, amely a backlogban prioritást adhat.
3. Újratervezési erőfeszítés
Miről van szó: Az üzleti probléma ismert, és van egy működőképes, de nem optimális megoldásunk. A tervezett munkafolyamat/funkció több különböző képernyőn több problémával is küzd, és a legmegfelelőbb megoldás nem feltétlenül nyilvánvaló. A munkafolyamat javítása jelentős kutatási és tervezési erőfeszítéseket igényel, beleértve a használhatósági tesztelést is. Ilyen lehet például annak újratervezése, ahogyan a felhasználók a kórlapinformációkat kiszámlázható kódokká alakítják, vagy annak javítása, ahogyan a kórlapinformációkat a kódoló felhasználók számára megjelenítik.
Mit teszünk ez ügyben? Mivel ezek a problémák nagyobbak, mint egy JIRA-jegy, és a megoldás nem azonnal nyilvánvaló, ezért tervezési kezdeményezésekként egy külön backlogon belül prioritást kapnak.
Az adósság kezelésének megközelítése
Miután kialakítottunk egy közös nyelvet az adósságtípusaink körül, ideje volt elkezdeni megtalálni és katalogizálni azokat a priorizáláshoz. A Catriona Shedd által a tervezési adósságok meghatározására kidolgozott struktúrából kiindulva a magas szintű felhasználói célok és feladatok meghatározásával kezdtük. Ezután a Capian segítségével szakértői felülvizsgálatot végeztünk az egyes munkafolyamatokról. A szakértői felülvizsgálatok mellett elkezdtük átnézni a meglévő felhasználói kutatási archívumokat, a tervezési pontozás visszajelzéseit és a rendszeres felhasználói visszajelzési hívások jegyzeteit, hogy megtaláljuk a potenciális megoldandó problémákat.
Ezután következett mindezek tárolásának és nyomon követésének kérdése. A táblázatokban könnyű volt elveszíteni a fonalat, vagy túl sok információval zsúfolttá válni. Minden egyes probléma hozzáadása a JIRA-hoz biztos módszer volt a fejlesztőcsapatok kínzására. Végül egy olyan megközelítés mellett döntöttünk, amely két kulcsfontosságú folyamot foglal magában:
JIRA a jól meghatározott és a fejlesztőcsapat által feldolgozható problémák tárolására és nyomon követésére;
Trello a magas szintű problémák rögzítésére, amelyeket még alakítani, megvitatni stb. kell.
Ez lehetővé teszi, hogy a fejlesztési backlogok a működőképes kérdésekre összpontosítsanak, míg az UX-csapat nyomon követheti a többi kérdést, és behúzza őket a fejlesztési sorba, amint alakíthatók. A Trello kártyáinkon és a JIRA problémákon belül címkéket használunk a különböző típusú adósságok nyomon követésére, és a JIRA jelentéseket futtathatunk ezeken a címkéken, hogy lássuk, hogyan haladunk a kifizetéssel szemben.
Kiutat találni
Azzal, hogy vállaljuk ezt az erőfeszítést, reméljük, hogy a következőket érjük el:
A tervezési adósságok leltárát, amelyet nyomon követhetünk és idővel le tudunk vezetni.
Peter Drucker szavaival élve: „Nem tudod kezelni azt, amit nem mértél meg”.
Egy megbízható folyamat a tervezési adósságok azonosítására, katalogizálására és kezelésére a jövőben.
Látható javulás a felhasználói élmény minőségében ügyfeleink számára.
Miközben ezt az erőfeszítést megkezdjük, aktívan fogadjuk a termék- és mérnöki kollégáink véleményét arról, hogyan halad a folyamat, és mit tehetünk annak érdekében, hogy a lehető leghatékonyabbá tegyük.
