it-swarm-eu.dev

Jak se rozhodnout mezi „konzistentním uživatelským rozhraním“ a „odpovídajícím uživatelským rozhraním“?

V současné době bojuji s návrhem nového uživatelského rozhraní pro poměrně velkou aplikaci. Aktuální verze softwaru se skládá z ~ 150 formulářů a nejsou ani hezké, ani intuitivní, a proto redesign.

V novém designu chci udržet věci konzistentní, tj. Chci, aby tyto formy vypadaly a cítily se co nejpodobněji. Ale v některých případech se to prostě necítí dobře. Například rozvržení, které má smysl pro správu tabulky hlavních dat s mnoha poli a několika podrobnými tabulkami, se zdá být celkově nafouknuté pro menší tabulku bez podrobných tabulek. Na druhé straně nejpřímějším jednoduchým návrhovým přístupem pro malou tabulku je IMO příliš neslučitelný s rozvržením části, která spravuje větší tabulku.

Jak zaútočit na problém? Držet se jednoho rozložení? Zmírnit tvrzení o konzistenci? Hledáte lepší přístup univerzální pro všechny?

5
ammoQ

Přichází na mysl několik myšlenek:

  • Nedělal bych si příliš starosti s konzistentností se staršími formami, zejména pokud zavádíte nové formy v krátkém časovém období. Brzy budou tyto staré formy matnou pamětí, ani pomůckou, ani překážkou výkonu nového designu.

  • Není to tak špatné, pokud různé formy vypadají jinak, pokud jsou tyto rozdíly ve vzhledu spojeny s rozdíly ve funkci. Může existovat malá zátěž při učení, ale uživatelé pravděpodobně nebudou zmateni, protože vizuální rozdíly je vedou k tomu, že existují funkční rozdíly. Nejednotnost je nejproblematičtější, když věci vypadají stejně, ale chovají se jinak, což je stav, který nazývám „rozpor“.

  • Na druhou stranu můžete chtít zvážit zahrnutí některých stejných základních funkcí do všech forem, nikoli pro konzistenci, ale pro flexibilitu. Například váš uživatelský průzkum může naznačovat, že pouze 20 z vašich formulářů potřebuje funkci klonování pro normální operace, ale možná budete chtít zahrnout schopnost klonování do všech formulářů, aby bylo možné pokrýt výjimečné operace, které váš výzkum neodhalil.

  • Měli byste se také vyhýbat věcem, které vypadají jinak, ale udělejte to samé (např. Mít tlačítko Odstranit je textově označené tlačítko v jednom formuláři, zatímco je to ikona v jiném formuláři). Toto je stav, který nazývám „nepravidelnost“, což není tak špatné jako rozpor, ale stále špatné. K vyrovnání nesrovnalosti potřebujete přesvědčivý zisk použitelnosti v jiných oblastech (např. Účinnost).

Máte pravdu, že konzistence není všechno, a měli byste zvážit její výhody s ohledem na jiné aspekty, jako je účinnost každého formuláře. Mám podrobnosti pro odhad a zmírnění závažnosti nekonzistencí pro takové kompromisy při dosažení a vyvážení konzistence v návrhu uživatelského rozhraní . Diskutuji o flexibilitě na E očekávám neočekávané .

11
Michael Zuschlag

Důsledné chování, přiměřený vzhled

IMO musíte objasnit (pro nás, nebo možná i pro sebe) , co musí být konzistentní a co ne.

Důsledné chování znamená: Věci, které vypadají stejně, by se měly chovat stejně.
Přiměřený vzhled znamená: vzhled pomáhá uživateli předvídat funkčnost.

S těmito definicemi ad-hoc podle mě pokornými nejsou antagonisty.

Viděl jsem mnoho pokusů o konzistentní vzhled u věcí, které jsou funkčně odlišné. Nyní, s určitým věkem, se domnívám, že to byla chyba v mnoha případech - alespoň když podobné pohledy byly motivovány podobnou nebo sdílenou implementací.

IMHO, snaha o podobný vzhled mezi 150 formuláři (OMG!) Není ani dobrý cíl. Jak vaši uživatelé říkají, co dělají?

Příklad:

alt text

Vidíte ten rozdíl? Velmi konzistentní, ale recept na katastrofu.

V tomto příkladu by se měly podrobnosti , jako je výběr přijímače, výběr produktů a množství atd., Chovat stejně - to je konzistence. Vzhled, OTOH by se měl výrazně lišit.


V praxi vidím dva možné problémy:

Předvolby vývojáře: Přístup „jedna velikost padne všem“ s vývojáři jednodušší. Namísto implementace 150 formulářů implementují modul generování formulářů, který se většinou konfiguruje z databázových metadat. (Rádi řešíme meta problémy a nenávidíme opakovanou práci. Toto dokonce je efektivnější přístup , pokud výsledkem je to, co uživatel potřebuje.)

Vnímání uživatele: Nahrazení stávajícího UX se liší od zavedení nového. Pro netechnické uživatele aplikace Formuláře jso - neznají obchodní logiku a backendy, znají pouze seznamy, pole a tlačítka.
To znamená, že pokud změníte uživatelské rozhraní úplně, můžete vidět velké tření, když je řešení zavedeno, jednoduše proto, že uživatelé vidí neznámou aplikaci, zatímco IT si myslí, že jsou to stejná data, takže jen malé školení je Požadované.
Což mě vezme k části mé odpovědi, kterou sotva říkám: Buďte opatrní s tím, co vyhodíte. Efektivní a elegantní uživatelské rozhraní může být mnohem náchylnější k chybám než ošklivé, ale známé.

[editovat] Jak Michael Zuschlag zdůrazňuje, nebojte se, jen se připravte na rozvinutí.

5
peterchen

Udržujte tok skupin prvků konzistentní .

Kromě viditelných prvků je další věcí, která má být konzistentní, tok dat a pořadí karet, když uživatel aktivně přidává informace do formuláře. Pravidlem, které je třeba dodržovat, by bylo důsledné dodržování stejného pořadí toku datových skupin, jako je adresa (složená z věcí, jako je ulice, město, PSČ, země atd.), Jméno (oslovení, první, střední, poslední) nebo produkt položka (název, stručný popis, dlouhý popis, barva, hmotnost, počet zahrnutých čteček atd.).

Například: Blok adresy bude obvykle obsahovat stejná pole: ulice, město, poštovní směrovací číslo, země. Má smysl vždy uvádět stejné prvky ve stejném relativním pořadí (nikoli ulice, město, země, poštovní směrovací číslo v jedné formě a ulice, město, poštovní směrovací číslo, země v jiné). A ačkoli se některé formuláře mohou mírně lišit (pole apt number na tomto poli, žádné pole země na tom jednom), vytvoření konzistentního toku významně zjednoduší chybu při zadávání dat.

Zkušení uživatelé, zejména ti, kteří se dotýkají typu, začnou používat tlačítko tab pro rychlé zlepšení své účinnosti. Hlavní přestávky v toku karet nebo nutení uživatele pohnout myší a ručně kliknout (zalapat po dechu!) Změnit zaměření způsobí časté uživatele systémové bitvy.

Také je možná nebudete implementovat pro web, ale základní myšlenka stále platí: Prvky seskupení formulářů nebo Explicitly Setting Tab Order má další výhodu v tom, že jsou přístupnější.

1
Peach

co si myslíte, co si uživatelé myslí o vašich změnách? Provedli jste vyšetřování problémů uživatelů? Myslím, že máte alespoň dvě paralelní práce:

  • redesign na jedno-styl UI (vytvořit prototyp, který používá obecně pro všechny ovládací prvky formulářů)
  • použitelnost, řešení problémů s konzistencí (podrobnější analýzu pro každou skupinu uživatelů)

Štěstí.

0
igor