Prototyp (prototype)

Příklady z praxe

1. 01

   Klikací registrace před vývojem

   Produktový tým navrhne novou registraci do SaaS aplikace jako klikací prototyp ve Figmě. Pět uživatelů během testu opakovaně přehlédne volbu pro firemní účet, takže tým změní pořadí kroků ještě před vývojem. Výsledkem je úprava návrhu bez zásahu do produkčního kódu.

2. 02

   Dočasný endpoint pro cenový model

   Backend vývojář potřebuje ověřit, jestli obchodní tým dokáže pracovat s novým modelem cen. Vytvoří dočasný endpoint s falešným výpočtem a poznámkou, že nejde o produkční logiku. Po schválení pravidel tým prototyp zahodí a napíše skutečnou implementaci s testy a auditem změn.

   app.get('/pricing-preview', async (req, res) => {
     const estimate = await fakePricingEngine(req.query.plan);
   
     res.json({
       plan: req.query.plan,
       estimatedPrice: estimate,
       note: 'prototype, not production logic'
     });
   });

Časté omyly

MýtusPrototyp je skoro hotový produkt, stačí ho jen vyčistit.

Ve skutečnostiPrototyp často vzniká s vědomými zkratkami, které by v produkci neobstály. Převzetí prototypu bez přepsání může přinést bezpečnostní, provozní i údržbové problémy.

MýtusPrototyp má smysl jen v designu obrazovek.

Ve skutečnostiPrototyp se používá také v backendu, datových systémech, hardwaru, algoritmech i obchodních procesech. Společným cílem je ověřit nejistotu dřív, než vznikne drahé finální řešení.

Časté dotazy

Má se prototyp po ověření vždy zahodit?

Prototyp má být zahoditelný tehdy, když vznikl rychlou cestou a obsahuje vědomé zkratky. Produktový prototyp může posloužit jako zdroj poznatků, testovacích scénářů nebo návrhových rozhodnutí, ale nemusí být dobrým základem pro produkci. Pokud tým chce prototyp převzít, měl by nejdřív projít kontrolou architektury, bezpečnosti, testovatelnosti a provozních požadavků.

Jak detailní má být prototyp?

Prototyp má obsahovat jen tolik detailů, kolik je potřeba k ověření konkrétní nejistoty. Pro test navigace stačí často jednoduché obrazovky bez reálných dat. Pro ověření výkonu nebo integrace je naopak potřeba technicky věrnější řešení. Příliš detailní prototyp spotřebuje zbytečně moc času a může vyvolat falešný dojem, že produkt je téměř hotový.

Kdo má prototyp hodnotit?

Prototyp by měli hodnotit lidé, kteří umí odpovědět na ověřovanou otázku. U použitelnosti jsou nejdůležitější skuteční nebo velmi podobní uživatelé. U technického rizika má prototyp posoudit vývojář, architekt, bezpečnostní specialista nebo provozní tým. U obchodní hypotézy dává smysl zapojit zákazníky, podporu, obchod a produktového manažera.

Kdy prototyp nestačí pro rozhodnutí o vývoji?

Prototyp nestačí jako důkaz proveditelnosti, pokud ověřuje jen povrchní část problému. Klikací maketa například neprokáže škálovatelnost backendu, bezpečnost plateb ani správnost datových migrací. Technický prototyp zase nemusí potvrdit, že uživatelé nové řešení pochopí. Silné rozhodnutí často vyžaduje více prototypů s různou věrností.

Zdroje

1. Prototype(otevře se v novém okně)Wikipedia
2. Software prototyping(otevře se v novém okně)Wikipedia
3. Inheritance and the prototype chain(otevře se v novém okně)MDN Web Docs

Související pojmy

• Technický dluhTechnický dluh je stav, kdy software nese následky rychlejšího nebo kompromisního rozhodnutí, které zjednodušilo dodání, ale ztížilo budoucí změny. Dluh může být vědomý i nechtěný; projevuje se složitějším kódem, chybějícími testy, zastaralými knihovnami, křehkou architekturou nebo dražším provozem a postupně vytváří „úrok“ v podobě pomalejšího vývoje.
• WireframeWireframe je hrubý návrh obrazovky, stránky nebo toku, který ukazuje rozmístění obsahu, ovládacích prvků a priorit bez finální grafiky. Slouží k rychlé debatě o struktuře, navigaci a interakci, aby tým odhalil chyby v zadání dřív, než vznikne vizuální design nebo kód.
• Uživatelské testováníUživatelské testování je výzkumná metoda, při které skuteční lidé z cílové skupiny plní na produktu předem připravené úkoly a moderátor sleduje, kde narazí na potíže. Cílem není zjistit názor uživatele, ale pozorovat jeho chování: kde zaváhá, co si špatně vyloží a kde úkol vzdá. Výstupem je seznam konkrétních problémů použitelnosti.
• Design sprintDesign sprint je časově ohraničený pracovní formát, obvykle pětidenní, ve kterém malý tým převede podnikatelskou otázku na prototyp a otestuje ho na skutečných uživatelích. Metodiku popsali Jake Knapp a kolegové z Google Ventures. Cílem není hotový produkt, ale rychlé rozhodnutí, zda má smysl daný směr dál vyvíjet.
• 3D model3D model je digitální reprezentace objektu nebo prostoru ve třech rozměrech, složená z geometrie, materiálů a často i textur, animací či fyzikálních vlastností. Používá se v hrách, filmech, průmyslovém návrhu, architektuře, e-commerce i simulacích, kde software z modelu počítá zobrazení nebo další data.
• A/B testováníA/B testování je řízený experiment, který porovnává dvě varianty stránky, funkce, ceny nebo sdělení na podobných skupinách uživatelů. Měří předem zvolenou metriku, například konverzi nebo retenci, a pomáhá rozhodnout, zda změna skutečně zlepšuje výsledek, nebo zda pozorovaný rozdíl mohl vzniknout náhodou.
• ACIDACID je sada čtyř vlastností databázové transakce: atomicity, consistency, isolation a durability. Zaručuje, že skupina zápisů proběhne jako jeden celek, neporuší definovaná pravidla databáze, nebude se nebezpečně míchat s jinými transakcemi a po potvrzení přežije pád systému, například při převodu peněz.
• Adaptive IconAdaptivní ikona je formát ikony aplikace na Androidu, který se místo jedné hotové bitmapy skládá z oddělených vrstev: pozadí a popředí. Systém výsledný tvar sám ořízne podle masky výrobce zařízení a může vrstvy animovat nebo přebarvit. Vývojář tak dodá jeden zdroj a launcher z něj vytvoří kruh, čtverec i squircle.