A lecke végére a projektet nem képernyők felsorolásaként, hanem ellenőrizhető tervezési történetként tudod bemutatni. Meg tudod különböztetni az állítást, a bizonyítékot, a döntést és az eredményt, és tudod, miért fontos a bizonyíték erejével arányosan fogalmazni.
Miért nem elég megmutatni a képernyőket?
A félév végén van egy kész prototípusod, és kézenfekvő, hogy végigmutasd. A hallgatóság azonban a végeredményből nem látja, mit tudsz: a tervezői munka lényege a döntések mögötti gondolkodás. Ha csak a képernyőket látják, az olyan, mintha egy szakács csak a kész ételt mutatná, a receptet és a kóstolásokat nem. A design story azt teszi láthatóvá, miért ez a megoldás, a vizsgált helyzetben.
A design story szerkezete
A tervezési történet (design story) a probléma, bizonyíték, döntés és eredmény összefüggő bemutatása. A tervezési indoklás (design rationale) annak rövid, bizonyítékokkal alátámasztott magyarázata, hogy miért éppen ezt az elrendezést, címkét vagy interakciót választottad. A kettő összetartozik: a rationale a történet egy-egy „mert”-je.
Az állítás legyen konkrét. „A felhasználók nehezen találták meg a lemondást” helyett mutasd meg, milyen feladatban, hány vizsgált résztvevőnél, milyen viselkedésben jelent meg ez. A bizonyíték lehet idézet, megfigyelés, user flow, előtte–utána képernyő vagy tesztlelet. Egyetlen erős, releváns bizonyíték többet ér, mint sok dekoratív képernyőkép.
Bizonyíték, döntés, eredmény
Ne hagyj logikai ugrást. Ha egy kutatási idézetből közvetlenül új funkció következik, magyarázd el az értelmezést. A lánc négy láncszeme:
Láncszem
Mit mutat?
Példa (Mai program)
Megfigyelés
Mit láttál / hallottál
A résztvevők több nézet között váltanak az időpont és ár összehasonlításához
Insight
Mit jelent ez
A döntési adatok nem jelennek meg együtt
Döntés
Mit változtattál
A találati kártyán mindkét adat előre látható
Eredmény
Mi lett a hatás
A következő tesztben a résztvevők kevesebb visszalépéssel választottak
Ez a lánc teszi szakmailag követhetővé a bemutatót.
Ne állíts többet, mint amit a bizonyíték enged. Kis tesztből beszélj „a vizsgált résztvevőkről”, ne „minden felhasználóról”. Ha egy változás még nem tesztelt, nevezd hipotézisnek, ne eredménynek.
Mit érdemes megmutatni?
Az artefaktum a tervezési folyamat kézzelfogható dokumentuma vagy kimenete. Válassz olyan artefaktumot, amely döntést magyaráz:
rövid kutatási összegzés vagy egy beszédes idézet;
persona vagy helyzetleírás;
user journey vagy user flow;
low-fi vázlat és a belőle született finomítás (előtte–utána);
prototípus-részlet;
tesztjegyzet és lelet;
iteráció a döntési naplóból.
Nem kell a teljes munkafolyamatot kivetíteni. Egy képernyő akkor hasznos, ha megmutatja, melyik problémára válaszol, és miből látszik, hogy a válasz működik vagy még bizonytalan.
Egy hosszú projekt sűrítése
A féléves munka sok szálból áll; a bemutatóba csak a főszál kerül. Szűrőkérdések:
Ez a dolog megváltoztatott egy döntést? (Ha nem, valószínűleg nem kell.)
Szükséges-e a fő állítás megértéséhez?
Van-e mögötte bizonyíték, vagy csak szép?
Amit kihagysz, az mehet mellékletbe.
flowchart TD
A["Probléma és kontextus"] --> B["Kutatási bizonyíték"]
B --> C["Tervezési döntés"]
C --> D["Prototípus és teszt"]
D --> E["Eredmény és korlátok"]
E --> F["Következő lépés"]
Végigvezetett példa: a Mai program története
„A kutatásban a résztvevők nem tudták összevetni az események alapadatait, ezért külső füleket nyitottak. A kártyákon az időt, árat, helyet és jelentkezési feltételt együtt jelenítettük meg. A második tesztben mindhárom résztvevő el tudta dönteni, megfelel-e egy találat; a csoportméret értelmezése azonban nyitott maradt.”
Ez rövid design story: helyzet, bizonyíték, döntés, eredmény és korlát. A design rationale ebből a „mert” rész: az egységes kártya azért került a lista elejére, mert a résztvevők a döntéshez szükséges adatokat hiányolták, és a térképes nézet feltételezésen alapult.
Gyakori tévhitek
Állítás
Pontosítás
„Ha minden képernyőt megmutatok, alapos vagyok.”
Az alaposság a döntések indoklásában látszik, nem a képernyők számában.
„A kudarcot ne mutassam meg.”
Egy elvetett alternatíva vagy nyitott kérdés hitelesebbé teszi a történetet.
„A design story kitalált mese.”
Ellenkezőleg: minden állítása bizonyítékhoz kötött.
Röviden
A design story a probléma, a bizonyíték, a döntés és az eredmény összefüggő bemutatása; a rationale ennek „mert”-je.
A lánc: megfigyelés → insight → döntés → eredmény; ne legyen logikai ugrás.
Csak a főszálat mutasd meg; a döntést nem változtató részletek mehetnek mellékletbe.
A bizonyíték erejével arányosan fogalmazz.
Ellenőrző kérdések
Mi a projekted egy mondatos fő állítása?
Mely bizonyíték támasztja alá a legfontosabb döntésedet?
Hol van logikai ugrás a jelenlegi bemutatódban?
Melyik képernyőt hagyhatod ki, mert nem magyaráz döntést?
Design story és bizonyíték
Célok
A lecke végére a projektet nem képernyők felsorolásaként, hanem ellenőrizhető tervezési történetként tudod bemutatni. Meg tudod különböztetni az állítást, a bizonyítékot, a döntést és az eredményt, és tudod, miért fontos a bizonyíték erejével arányosan fogalmazni.
Miért nem elég megmutatni a képernyőket?
A félév végén van egy kész prototípusod, és kézenfekvő, hogy végigmutasd. A hallgatóság azonban a végeredményből nem látja, mit tudsz: a tervezői munka lényege a döntések mögötti gondolkodás. Ha csak a képernyőket látják, az olyan, mintha egy szakács csak a kész ételt mutatná, a receptet és a kóstolásokat nem. A design story azt teszi láthatóvá, miért ez a megoldás, a vizsgált helyzetben.
A design story szerkezete
A tervezési történet (design story) a probléma, bizonyíték, döntés és eredmény összefüggő bemutatása. A tervezési indoklás (design rationale) annak rövid, bizonyítékokkal alátámasztott magyarázata, hogy miért éppen ezt az elrendezést, címkét vagy interakciót választottad. A kettő összetartozik: a rationale a történet egy-egy „mert”-je.
Az állítás legyen konkrét. „A felhasználók nehezen találták meg a lemondást” helyett mutasd meg, milyen feladatban, hány vizsgált résztvevőnél, milyen viselkedésben jelent meg ez. A bizonyíték lehet idézet, megfigyelés, user flow, előtte–utána képernyő vagy tesztlelet. Egyetlen erős, releváns bizonyíték többet ér, mint sok dekoratív képernyőkép.
Bizonyíték, döntés, eredmény
Ne hagyj logikai ugrást. Ha egy kutatási idézetből közvetlenül új funkció következik, magyarázd el az értelmezést. A lánc négy láncszeme:
Ez a lánc teszi szakmailag követhetővé a bemutatót.
Ne állíts többet, mint amit a bizonyíték enged. Kis tesztből beszélj „a vizsgált résztvevőkről”, ne „minden felhasználóról”. Ha egy változás még nem tesztelt, nevezd hipotézisnek, ne eredménynek.
Mit érdemes megmutatni?
Az artefaktum a tervezési folyamat kézzelfogható dokumentuma vagy kimenete. Válassz olyan artefaktumot, amely döntést magyaráz:
Nem kell a teljes munkafolyamatot kivetíteni. Egy képernyő akkor hasznos, ha megmutatja, melyik problémára válaszol, és miből látszik, hogy a válasz működik vagy még bizonytalan.
Egy hosszú projekt sűrítése
A féléves munka sok szálból áll; a bemutatóba csak a főszál kerül. Szűrőkérdések:
Amit kihagysz, az mehet mellékletbe.
flowchart TD A["Probléma és kontextus"] --> B["Kutatási bizonyíték"] B --> C["Tervezési döntés"] C --> D["Prototípus és teszt"] D --> E["Eredmény és korlátok"] E --> F["Következő lépés"]Végigvezetett példa: a Mai program története
„A kutatásban a résztvevők nem tudták összevetni az események alapadatait, ezért külső füleket nyitottak. A kártyákon az időt, árat, helyet és jelentkezési feltételt együtt jelenítettük meg. A második tesztben mindhárom résztvevő el tudta dönteni, megfelel-e egy találat; a csoportméret értelmezése azonban nyitott maradt.”
Ez rövid design story: helyzet, bizonyíték, döntés, eredmény és korlát. A design rationale ebből a „mert” rész: az egységes kártya azért került a lista elejére, mert a résztvevők a döntéshez szükséges adatokat hiányolták, és a térképes nézet feltételezésen alapult.
Gyakori tévhitek
Röviden
Ellenőrző kérdések