it-swarm-eu.dev

Jak komunikujete závažnost chyb v designu? Máte nějaké standardizované způsoby, jak toho dosáhnout?

Při řešení a třídění chyb souvisejících s použitelností často zjišťuji, že se musím uchýlit k provedení show nebo komplikovaně a dramaticky popsat bolest uživatele kolem problému. I když jsem si jist, že to budu muset vždy udělat, přál bych si, aby existoval standardizovanější způsob komunikace, jak závažný problém je/je. Četl jsem o lidech v Mozillu, kteří označují chyby, se kterými heuristiku rozbijí, což je podle mě skvělý nápad, ale ve skutečnosti to s vážností nepomůže. Má někdo nějaké dobré nápady nebo procesy?

Příkladem může být, že jedna chyba může cítit projektanta, ach můj bože, neměli bychom to v tomto stavu nikdy uvolnit, ale vývojáři, který to naprogramoval, se může zdát toto chování zřejmé, takže se nezdá být příliš závažné.

8
Becky

User Focus má dobrý článek na téma přednostňování problémů s použitelností .

Souhlasím se sentimentem úvodního příspěvku. Pokud pracujete ve strojírenském prostředí nebo s velkým komplexním systémem, je nezbytné mít konzistentní a srozumitelnou metodiku a postup podávání zpráv. Část toho, proč je důležité, je třeba brát vážně a druhou částí je procvičování dobré komunikace a smysluplné integrace s ostatními týmy a procesy, se kterými pracujete.

Opravdu řídit domů, že něco opravdu opravdu je problém a je to obrovská bolest pro uživatele, pak doplnění vaší zprávy s videoklipy z interakce může udělat zázraky k posunu názorů.

7
Splog

Poté, co jsem s tímto problémem bojoval několik let a skončil vytvořením produktu s relativně špatnou použitelností, vyřešil jsem tento problém jiným způsobem.

Existují dva zdroje (přinejmenším tam, kde pracuji) k problému: 1) „Podnikání“ nikdy nebude plánovat/upřednostňovat otázky použitelnosti, protože a) raději mají nové funkce/opravy chyb ab) nemají reálný způsob, jak si představit nebo kvantifikovat náklady na špatnou použitelnost (přece jen jsou to experti na domény, ne softwaroví experti).

2) (Tradiční) vývojáři nikdy nebudou plánovat/upřednostňovat otázky použitelnosti, protože a) často nevidí rozsah/náklady na problém ab) jsou často méně sebevědomí v front-end vývoji ac) jejich zaměření je neustále odcizeno problémy, které jsou více jádrem práce vývojáře.

V důsledku toho trpí použitelnost.

Jako takový, IMO, v podstatě potřebujete samostatný vývojový kanál, který by řešil použitelnost. Je to skoro stejné jako technické zadlužení (které bych také obhajoval, aby se takto „vyřešilo“). Vytvořte nový kanál dev, ať už je tak malý, jak věnovat pár agilních bodů na iteraci (nebo pár dní za dvoutýdenní vydání, cokoli), aby v ideálním světě najal front-endového inženýra s jeho vlastní prioritou -seznam. Tento nový kanál dev neustále a důsledně přechází přes problémy s použitelností a problémy s použitelností již nejsou upřednostňovány proti problémům s nepoužitelností, ale spíše proti sobě.

Nyní, pro obě diváky v mém prvním odstavci, pokud jdete a strávíte pár dní shromažďováním některých výzkumných shrnutí, výsledků případových studií, citací z uznávaných guru atd., Měli byste být schopni vytvořit argument, který přesvědčí lidi . Ale kdo má čas věnovat se 4 hodinám výzkumu a vytváření argumentů, aby dostatečně upřednostnil jednu hodinu práce? Pokud ale dostanete argument společně (s odvoláním na několik příkladů špatné použitelnosti ve vaší aplikaci), nikoli na podporu ospravedlnění prioritizace jednoho problému, ale spíše na ospravedlnění samostatného kanálu rozvoje, vyplatí se najednou mnohem větší úsilí.

Jsem obyčejný vývojář C # .Net s rostoucím zájmem o použitelnost. Co jsem udělal, je formulovat argument pro důležitost pohledu na otázky použitelnosti, šel do mého CTO s návrhem a nyní věnuji procento svého času otázkám použitelnosti. Můj tým ztratil některé základní vývojové zdroje (najímali jsme se, takže to byl snazší argument), ale nyní se na některé použitelnosti konečně podíváme.

Dlouhodobě si myslím, že součástí mé nové práce je vzdělávat ostatní vývojáře takovým způsobem, aby nedošlo k uvolnění funkcí, které vykazují špatnou použitelnost. Zesilujte účinky tak, jak byly.

Hodně štěstí!

7
Mark Gibaud

Vizuální efekty, zejména demonstrace, jsou tím, co jsem viděl, největší dopad.

Bylo to v agilním prostředí, kde tým UX odeslal příběhy do produktového backlogu a nechal je hlasovat během odhadů.

Visuals vždy pracoval ve smyslu odkazování screenshotů, ale nejlepší bylo skutečně ukázat problém v akci a popsat, proč to byl problém.

Pokud nejste v agilním prostředí, musíte mít pořádání vývojových schůzek, na nichž mohou být nastoleny problémy - buďte připraveni ukázat, co je rozbité a diskutovat o tom, proč to považujete za „rozbité“.

(BTW, pro ty, kteří nejsou obeznámeni s Agile, když chcete, aby na něčem něco pracovalo, zapište to a odešlete jej na velký seznam „na čem musíme pracovat.“ Seznam se každý týden přezkoumává a diskutuje o vývoji, UX, QA. , produktový management a klíčové zúčastněné strany).

1
gef05

Přicházejí na mysl standardní měřidla, možná v kombinaci s barevným přechodem přecházejícím od žluté přes oranžovou k červenou.

Mohou být použity i jiné analogie: ikona dámské chyby, nádoba na nádobí, sklenice na pití, osoba, v různých fázích „zlomivosti“. Tj: omítka z nějaké části, prasklina (nebo pomačkaný „úsměv“), zlomený kus (pryč), ... úplně roztříštěný/rozmačkaný

Při používání zvířecích a lidských analogií buďte opatrní, aby se nestala příliš grafickou.

1
Marjan Venema

Použitelnost není programování.

Vytvoření takového postupného systému by bylo zavádějící.

Pokud si opravdu myslíte, že je něco tak vadného, ​​že to nějak naruší systém (například chybějící tlačítko, které vás přenese k dalšímu kroku), opravte jej.

Jinak je to jen problém s použitelností a nezáleží na tom, jak je pro nás jako praktikující důležité najít, že nejsou podle metrik blízko, když kód nefunguje.

V programování, kdy si myslí, že nefungují, nepracují. Aby to fungovalo, musíte to opravit.

V použitelnosti se můžete dostat mnohem více, než se systém rozbije.

0
ThomPete