it-swarm-eu.dev

Může se UCD stát agilním procesem?

Všechny diskuse o Agile UX se týkají toho, jak přizpůsobujeme aktivity UX agilnímu vývojovému procesu, ale chci vědět, jak můžeme UCD proměnit v agilní proces, který podporuje vývojovou aktivitu.

Nějaké nápady na Agile UCD?

13
Matt Goddard

Iterativní design, který charakterizuje UCD, se velmi dobře hodí s iteračním vývojem, který charakterizuje Agile. Chcete, aby vaše iterace designu odpovídaly iteracím vývoje.

Předtím však budete potřebovat čas dopředu, než vývojáři začnou kódovat, aby provedli předběžný výzkum k identifikaci uživatelských cílů a bodů bolesti a získání vize produktu. Doporučuji vám však začít navrhovat (pouze pro sebe) před dokončením výzkum . Pomůže vám to soustředit váš výzkum a dosáhnout toho dříve. Někdy ještě předtím, než budete hotovi, budete mít obrys produktu z pohledu uživatelů, který můžete rozdat vývojářům, aby mohli začít s backendem nezbytným pro jeho podporu.

Jakmile budete mít tento základ, spustíte jeden krok na hlavě vývojářů, vymáčknete mini-návrhy, testujete prototypy s rychlými a špinavými testy použitelnosti a poté předáte načmárané drátové modely vývojářům. V určitém okamžiku vývoje je kód vytvořený vývojáři vaším prototypem a jste v synchronizaci s vývojáři. Testy použitelnosti jsou pak součástí obvyklé zpětné vazby zúčastněných stran, která je součástí agilní iterace. V této fázi začnete slábnout, jemně doladit uživatelské rozhraní, než poskytovat strategické směřování.

Více o osazení UX/UCD s Agile a osazení Agile k UX/UCD:

11

Myslím, že je důležité nezaměňovat Agile s Scrumem. Odpověď na tuto otázku: Přemýšlejte o UCD a přečtěte si Zásady agilního manifest níže.

  1. Naší nejvyšší prioritou je spokojenost zákazníka včasným a nepřetržitým dodáváním hodnotného softwaru.
  2. Vítejte měnící se požadavky, a to i pozdě ve vývoji. Agilní procesy využívají změnu pro konkurenční výhodu zákazníka.
  3. Dodávejte pracovní software často, od několika týdnů do několika měsíců, s upřednostněním kratšího časového harmonogramu.
  4. Podnikatelé a vývojáři musí po celý projekt spolupracovat každý den.
  5. Budujte projekty kolem motivovaných jednotlivců. Poskytněte jim prostředí a podporu, kterou potřebují, a důvěřujte jim, aby svou práci dokončili.
  6. Nejúčinnějším a nejefektivnějším způsobem předávání informací vývojovému týmu a uvnitř něj je osobní rozhovor.
  7. Pracovní software je primárním měřítkem pokroku.
  8. Agilní procesy podporují udržitelný rozvoj. Sponzoři, vývojáři a uživatelé by měli být schopni udržovat konstantní tempo po neomezenou dobu.
  9. Stálá pozornost na technické dokonalosti a dobrý design zvyšuje obratnost.
  10. Jednoduchost - umění maximalizace množství nedokončené práce - je zásadní.
  11. Nejlepší architektury, požadavky a návrhy vycházejí ze samoorganizujících se týmů.
  12. V pravidelných intervalech tým přemýšlí o tom, jak se zefektivnit, poté naladí a přizpůsobí své chování.

Osobně jsem si je přečetl a přemýšlel:

  1. Jsou v tomto týmu návrháři, které popisují?
  2. Kolik času musí návrhář zjistit uživatelské rozhraní, než vývojáři řeknou, že chtějí rychle dodat pracovní software?
  3. Změny v informační architektuře jsou velmi bolestivé. Opravdu je vítají pozdě ve hře?
  4. Je to skutečně způsob, jak vytvořit nejlepší UX?

V Marketu jsem byl velmi UCD a dodal jsem skvělý produkt se skvělým UX. Náš proces byl docela chaotický. Nenazvali jsme to agilní, nazývali jsme to křehkou .

Moje odpověď zní: Vývojáři nejsou designéři a ani obchodníci. Dostane se Agile do cesty velkému UX? Ano, někdy. Schopnost opakovat věci je však kritická a já bych ji za vodopád nevyměnil.

Zde je graf, který ukazuje proč se mi líbí Agilní metodologie nad Vodopádem .

4
Glen Lipka

Na loňské konferenci UPA v Portlandu jsem slyšel, jak panelista říká (parafrázuji):

Agile řeší starý problém pro vývojáře - problém doručit špatnou věc, příliš pozdě. Protože Agile řeší tento problém, staví design i použitelnost na kritickou cestu. Potřebujeme spolupracovat s vývojáři, abychom jim pomohli pochopit, že řešení jejich problémů musí vyřešit náš problém.

Z tohoto bodu pro mě vyplývá, že buď celý tým Agile - vývojáři, QA a všichni - jsou všichni zapojeni do designu a použitelnosti společně, nebo - pokud to nedokáží dostatečně dobře - Agile proces vytváří prostor pro odborníky, kteří mohou.

- = - Jerome

1
JeromeR

Procesy UCD vylepšují Agile a mohou z něj učinit úspěch pro obě strany (biz/dev).

Pokud je osoba UX zapojena jak do biznisu, tak do vývoje, spolupracuje s analytikem (nebo je analytikem) a zapisuje/účastní se uživatelských příběhů, je k dispozici, když je hodnocena (aby pomohla týmu pochopit priority stanovené pro UX) a účastní se každodenního scrumu, aby slyšeli problémy, které má vývoj, změny, které chtějí provést, naslouchá testovacím procesům a problémům QA atd. Je to situace, kdy je možné vyhrát/vyhrát a úspěšný agilní projekt.

Někteří návrháři mohou bojovat s agilním procesem, ti, kteří si myslí, že dokonalost pixelů a žádná odchylka jsou tím, co dělá úspěšný projekt, ale neexistuje skutečný konflikt. Design se může ohýbat jako změna req, stejně jako se může přizpůsobit architektura, data, kód.

1
Susan R

Od doby, kdy byla tato otázka poprvé položena, došlo v odvětví určitě ke změnám, které se pokusily přijmout „agilnější“ a „štíhlejší“ verzi UX. Například tato otázka, která byla položena nedávno, odráží potřebu vyvážit agilnost s ux, aby bylo možné využít jak přístupů, tak filozofií v designu: Jak optimalizovat proces UX pro projekty s pevně stanovenými termíny?

V mé odpovědi na otázku jde o upuštění od postupů a metodik v UX, které nejsou kritické pro splnění cílů návrhu, a shrnutí mé odpovědi na otázku bylo zlepšit komunikaci s dokumentací, jednoduše/zefektivnit pracovní postup a zaměření na konečný cíl. Způsob, jakým je výzkum a testování prováděno, závisí na tom, jak ochotný je konstruktér dělat předpoklady a pokročit v budoucích iteracích.

Takže je to možné a pravděpodobně i běžná praxe.

0
Michael Lai