En kjerne i moderne utviklingsprosesser er smidig utvikling . Denne utviklingsmetodikken legger vekt på å bruke små, små brukerhistorier for å definere hva et system gjør fra et brukerperspektiv, ikke et teknisk. En bruker bryr seg om et produkt er raskt, enkelt å bruke og løser problemet. De bryr seg ikke om den følger en 3-lags arkitektur, har Mongo DB, eller om den bruker Rails eller Asp.net.
Storyboard That gir en ideell plattform for å lage smidige brukerhistorier og skape samtale i et format som er mye mindre belastende enn en tekstvegg.
I sammenheng med brukerhistorier er et "epos" ganske enkelt en veldig bred historie som senere vil bli delt opp i mange spesifikke brukerhistorier. Fra og med en episk innrømmer alle med en enkelt visjon på høyt nivå. Den episke historien forankrer et prosjekt ovenfra og ned, og hvis det ikke gir mening å konstruere et epos, vil støttearbeid også være sløsing med krefter.
I denne historien er det veldig klart hva den langsiktige visjonen er og hvordan suksess skal se ut. En god episk historie bør inneholde:
Spesielt når du designer programvare, er det viktig å ha en god visjon om hvordan brukerne vil se ut. Ikke alle brukere vil matche denne visjonen nøyaktig, og det kan være flere kategorier av brukere, men disse diskrete visjonene trenger artikulasjon. Å tenke på brukerne beskytter først mot overkonstruksjon og overkomplikasjon, forhindrer et nytt produkt i å ha noe for alle og være nyttig for ingen.
Når et epos er etablert og brukerne er definert, kan mindre, mer spesifikke historier konstrueres om bestemte brukeropplevelser. Historiene nedenfor bryter ned skissert ovenfor i to fortellinger: slå opp en bestilling og ombestille et produkt.
Disse fortellingene inneholder ikke teknisk informasjon; brukerne bryr seg ikke om hvordan resultatene oppnås, så lenge de utfører de ønskede oppgavene. På samme måte er UX avbildet generisk, for å unngå å kvele innovasjon eller tvinge en vei. Generelt bør historier være:
Disse historiene bør invitere til samtale og spørsmål, for eksempel:
Det er helt rimelig å lage mange historier; faktisk bør det oppmuntres. Noen av disse historiene vil aldri bli brukt, men det er viktig å se veien de la ned. Denne samlingen av historier vil skylle ut ytterligere krav og påvirke testing.
Historiene skal provosere og informere diskusjon om hvordan programvaren skal testes og hvilke forretningsregler som må defineres eksplisitt. For eksempel: