Přeskočit na obsah

Vzor zadání k vyplnění

Vzor zadání UX/UI návrhu digitálního produktu

Vyplňte, co víte. Z odpovědí vznikne souvislé zadání UX/UI návrhu, které si můžete zkopírovat, vytisknout nebo použít jako přípravu před poptávkou.

  • Není nutné znát řešení dopředu. Popište problém a cíl vlastními slovy; konkrétní návrh obrazovek navrhne designér.
  • Oddělte pevné požadavky od preferencí. Pevný požadavek je podmínka, bez které návrh nedává smysl (např. platforma, existující design systém).
  • Co nevíte, označte jako „Nevím – potřebuji doporučit“. Otevřená položka je lepší než vymyšlená odpověď.
  • Příklady jsou jen pomůcka k pochopení otázky. Nemají se automaticky stát součástí vašeho zadání.

Pokud si u některé části nejste jistí, co má obsahovat, přečtěte si podrobné vysvětlení jednotlivých částí zadání. Tato stránka je záměrně stručná šablona k vyplnění.

Šablona zadání

Šablona má 15 částí. Vyplněno: 0 z 15.

  1. 01

    Kontext a stav produktu

    Rozsah UX/UI práce se zásadně liší u návrhu od nuly a u redesignu fungujícího produktu.

    Příklad: Existující webová aplikace pro plánování směn, provozujeme ji tři roky, teď řešíme redesign hlavního přehledu a plánovacího kalendáře.

  2. 02

    Problém a cíle návrhu

    Jasně formulovaný problém určuje priority návrhu víc než seznam požadovaných obrazovek.

    Příklad: Uživatelé si stěžují, že nenajdou historii směn a plánování zabere moc kroků; úspěchem je zkrácení počtu kliknutí k vytvoření směny.

  3. 03

    Uživatelé a role

    Rozdílné role často znamenají odlišné obrazovky, oprávnění i prioritu funkcí.

    Příklad: Vedoucí směny (plánuje a schvaluje), řadový zaměstnanec (jen zobrazuje a žádá o výměnu), administrátor (spravuje uživatele a nastavení).

  4. 04

    Klíčové scénáře

    Návrh se staví kolem konkrétních scénářů, ne kolem obecného výčtu funkcí.

    Příklad: Vedoucí vytvoří týdenní plán směn za pět minut. Zaměstnanec požádá o výměnu směny a dostane notifikaci o schválení.

  5. 05

    Platformy a zařízení

    Platforma určuje návrhové vzory, velikost dotykových prvků i práci s omezeným prostorem obrazovky.

    Příklad: Primárně desktopový web pro vedoucí, doplňkově responzivní zobrazení na mobilu pro zaměstnance.

  6. 06

    Rozsah obrazovek

    Výčet obrazovek určuje pracnost a je základem pro odhad a harmonogram.

    Příklad: Přihlášení, přehled plánu, detail směny, žádost o výměnu, schvalování žádostí, nastavení uživatele – šest hlavních obrazovek.

  7. 07

    Informační architektura a flow

    Bez znalosti návaznosti na existující strukturu hrozí, že návrh nesedne na zbytek aplikace.

    Příklad: Základní navigace (hlavní menu, sekce) je daná současnou aplikací a mění se jen minimálně, tok uvnitř plánování se navrhuje nově.

  8. 08

    Požadovaná fidelity výstupu

    Úroveň detailu výstupu zásadně mění pracnost i to, co lze podle výstupu předat vývoji.

    Příklad: Nejdřív drátěné modely (wireframy) ke schválení toku, po schválení vizuální návrh a klikatelný prototyp klíčových scénářů pro testování.

  9. 09

    Existující značka a design systém

    Design systém určuje, zda se navrhují nové komponenty, nebo se skládá z existujících.

    Příklad: Máme základní knihovnu komponent (barvy, typografie, tlačítka, formulářové prvky) ve Figmě, nové komponenty je potřeba do ní doplnit.

  10. 10

    Výzkumné vstupy

    Existující vstupy šetří čas a snižují riziko, že návrh řeší domnělý, ne skutečný problém.

    Příklad: Máme přepis rozhovorů s pěti vedoucími směn a přehled nejčastějších tiketů podpory týkajících se plánování.

  11. 11

    Přístupnost

    Požadavky na přístupnost ovlivňují barevné kontrasty, velikost prvků i chování pro klávesnici a čtečky obrazovky už od návrhu.

    Příklad: Cílíme na běžné požadavky přístupnosti (dostatečný kontrast, ovladatelnost klávesnicí), bez specifické certifikace.

  12. 12

    Návaznost na vývoj a formát předání

    Formát předání (soubory, specifikace, red-lines) určuje, jak plynule návrh naváže na vývoj.

    Příklad: Implementuje interní tým vývojářů, předání proběhne ve Figmě s popisem stavů komponent a odkazem na existující design systém.

  13. 13

    Schvalování a odpovědnosti

    Nejasné schvalování je nejčastější příčinou zdržení a opakovaných úprav návrhu.

    Příklad: Kontaktní osoba je produktový manažer, finální vizuální návrh schvaluje spolu s vedoucím zákaznické podpory.

  14. 14

    Termín a rozpočet

    Rámec umožní navrhnout realistický rozsah fidelity a počet obrazovek místo obecné nabídky.

    Příklad: Wireframy potřebujeme do tří týdnů kvůli plánovanému testování, rozpočtový rámec na celý návrh máme orientačně schválený.

  15. 15

    Akceptace výstupu

    Jasná akceptační kritéria předchází sporům o to, zda je výstup dokončený.

    Příklad: Návrh je hotový, když klikatelný prototyp projde uživatelským testováním bez zásadních problémů a schválí ho produktový manažer.

Vyplněné údaje zůstávají ve vašem prohlížeči. Reklamka.ai je při vyplňování této stránky nikam neodesílá ani neukládá – odeslány budou jedině údaje, které sami vyplníte v poptávkovém formuláři.

Souhrn zadání

Zatím jste nevyplnili žádnou část. Souhrn se sestaví z vyplněných odpovědí.

Časté otázky

Musíme vyplnit všechny položky?
Ne. Vyplňte, co víte. Nevyplněné části se do souhrnu nedostanou a u témat, kde to dává smysl, můžete zvolit „Nevím – potřebuji doporučit“. Otevřená položka je pro designéra užitečnější než vymyšlená odpověď.
Musíme předem vědět, jestli chceme wireframy, nebo klikatelný prototyp?
Ne. Popište, na co výstup navazuje (schvalování toku, uživatelské testování, přímé předání vývoji) – úroveň detailu pak navrhne designér. Pokud si nejste jistí, označte položku jako otevřenou.
Potřebujeme mít hotový design systém?
Ne. Stačí uvést, jestli nějaký existuje a v jaké je podobě. Bez design systému se počítá s tím, že jeho základ vznikne jako součást návrhu.
Lze zadání použít i pro redesign existujícího produktu?
Ano. Části o kontextu produktu a informační architektuře jsou pro redesign klíčové – popište, co se má zachovat a co se má zásadně změnit.
Ukládá Reklamka.ai rozepsané údaje?
Ne. Vyplněné údaje zůstávají ve vašem prohlížeči a při vyplňování této stránky se nikam neodesílají. Uloží se až to, co sami vyplníte a odešlete v poptávkovém formuláři.
Co se stane po přechodu do poptávky?
Otevře se poptávkový formulář s předvolenou oblastí a službou. Vyplněné odpovědi z této šablony se do formuláře nepřenášejí automaticky – zkopírujte si souhrn a vložte ho do příslušných polí nebo z něj vycházejte při vyplňování.

Máte zadání? Pokračujte poptávkou

Formulář se otevře s předvybranou oblastí i službou. Poptávka je nezávazná; vyplněné údaje z této šablony se do formuláře nepřenášejí automaticky, souhrn si zkopírujte a vložte ho do příslušných polí sami.

Pokračovat do poptávky UX/UI návrhu

Nejdřív si projít detail služby UX/UI návrh digitálního produktu

Kam pokračovat