Hva er en Leverbar?

Den "leverbare". Et enkelt konsept å forstå (noe du "leverer"), men vanskelig å forklare riktig.

En måte å beskrive en levererbar på, ville være som et stykke arbeid eller en artefakt som er en kollektiv av en større gruppe arbeid. For eksempel: Et sitemap, en nav-modell og en søkedefinisjon vil alle falle under paraplyen av "informationsarkitektur". For å formalisere denne leveransen kan det være et dokument som inneholder alle disse artefakter og et dekselark med litt versionsinformasjon. 

Videre kan gjenstander og leveranser også være frittstående og utskiftbare. En wireframe kan for eksempel brukes som levererbar på et prosjekt for å vise en leder du gjør fremgang, gi utviklerinformasjon om strukturen som trengs, eller samle en milepælbetaling fra en klient. 

Det viktige å ta bort er at en leverbar ikke er noe som skal gjøres for en produksjons skyld, men for å gi større klarhet eller bringe prosjektet / produktet nærmere den ønskede sluttstaten. Derfor er det viktig å tenke kritisk på hvorfor du skaper en leverbar og til hvilket nivå av troskap / formalitet som det er potensial for å kaste bort mye tid!

Hvem er målgruppen din?

Leveranser har et publikum, og noen ganger er det noen overlapping som vist i Venn-diagrammet nedenfor. Å forstå at målgruppen er et viktig første skritt i å forstå behovet for leveransen og nivået på troskap eller formalitet som kan være nødvendig. 

Produktsjef

Generelt vil produktansvarlig eller en intern leder i stor grad være interessert i funn og definisjonsfase. Dette er når forretningsbehovene og prosessene blir hevet og produktet defineres. Derfor, hvis de ber om noen representasjon av hva produktet kan se ut på linjen, kan det være bedre å levere en håndskisse av noen layouter, i stedet for å kaste bort tid på å kode en prototype, for eksempel. 

Utvikler

Utviklere har oppgaven med å programmere det som er oppdaget, definert og utformet i endelige representasjoner gjennom kode. Det er mye rom for feilfortolkning med wireframes. Uansett hvilke layouter som leveres til en dev-gruppe, må være piksel perfekt og spesifikasjoner skal opprettes, da din gjennomsnittlige utvikler vil skape akkurat det du ber om, spesielt hvis de er et outsourcet lag!

klienter

Når det gjelder klienter, må leveranser kanskje være mer polerte og tjene som markedsføringsverktøy (for å vise hvor godt byrået er). Du bruker noen ganger leveranser til å påvirke den eksterne interessenten, eller i å møte en del av en kontraktsavtale når du arbeider med en "milepælbetalingsstruktur". 

Målgrupper og leverbare typer

Hvilken type miljø jobber du i? 

Ikke bare spiller publikum en stor rolle i hvordan leveransen skal skje, men også organisasjonens struktur. Ingenting forblir konstant, selv innenfor samme struktur (som et konsulentfirma); Leveranser kan variere fra prosjekt til prosjekt. Beskrivelsene nedenfor er generaliseringer, men et godt utgangspunkt hvis du har det vanskelig å prøve å hash ut hvilken type utganger du trenger. 

Rådgivende konserter og digitale kontorer

Leveranser er ofte av høyere troskap i dette miljøet, fordi ditt mål er ikke bare å flytte prosjektet fremover, men også utdanne klienten og sikre at de er "wowed" av leveransen. Effektivt er det beroligende klienten at de har gjort det riktige valget med deg over en konkurrent. 

Dette er kritisk i anbudsperioden når en rekke konsulentselskaper konkurrerer om samme jobb. Vær imidlertid oppmerksom på at det finnes en rekke andre ting som klienter har i tankene når de velger slik som teknologiekspertise, ressurser osv.

Hackathons

Resultatene i en "hackathon" er utformet med det formål å presentere til et panel av dommere. Det kan være et lysbildeaggregat, og du kan presentere noen storyboards, produkt veikart ... Alt som vil fremkalle følelser, kommunisere et problem og en løsning på problemet og vise en klar visjon om trinnene som kommer framover! Dette er sannsynligvis ikke anledning til en fullt utviklet prototype, med mindre du har medlemmer på laget ditt med den muligheten.

Freelance Gigs

I min erfaring er freelance-spill (spesielt de som utføres online) ofte svært små. Det er ofte "Wireframes som trengs for X app" eller "Usability Report for X Website". Disse resultatene er primært brukt til å betegne ferdigstillelse fremfor fremgang og er ofte knyttet til milepælbetalinger.

Start Ups

Start oppleveranser fokuserer i stor grad på oppdagelse, validering og definisjon, ettersom gründeren prøver å knekke markedet. Design er også viktig, og leveranser innen forfinningsfasen av prosjektet vil dreie seg om å dreie ideen og gjøre endringer på bakgrunn av tilbakemeldinger fra brukere og tidlige interessenter. 

Produktlag

Ved "Produktlag" refererer jeg til et selskap som har en eller flere digitale produkter og internt personale. Disse lagene bruker vanligvis leveranser i en sluttprosess. De kan være lavere trohet, bortsett fra når produktbehandleren trenger å kommunisere og pakke informasjon til ledere. Hver leveranse tendens til å justere mer til forskjellige faser av UX prosessen.

Leveranser innen UX-prosessen

Leveranser kan også falle i flere faser i UX Design-prosessen:

• Oppdagelse
• Definisjon
• Design
• Refinement

Typer av leveranser under UX designprosessen

Som du kan se, tidligere i prosessen, er det flere resultater som prosjektet starter i stor grad, og det er mer arbeid brukt på planlegging og prøver å identifisere den riktige tingen å jobbe med. Denne modellen er sannsynligvis mest anvendelig for produktgrupper, og det er mye kryss i rollen i de to første faser. UX Designers, Product Managers og Business Analysts kan alle sammen samarbeide på kundereisekart, for eksempel.

Hvorfor opprett leveranser?

Hvorfor vi lager resultater, som nevnt ovenfor, er kontekstuelle. Årsakene er basert på rolle, type organisasjon, publikum og mange andre faktorer. Her er fem av de vanligste årsakene til å skape leveranser:

1. Å møte kontraktsforpliktelser.
2. Å indikere fremdrift.
3. Å påvirke mennesker.
4. For å gjøre ting klarere og flytte prosjektet nærmere til et sluttmål.
5. For å gjøre en stort sett immateriell prosess mer synlig med en rekke utganger.

Min personlige tilnærming er å holde de felles leveranser foran og midt i prosessen min; som personas, prototyper og brukerintervjuer. Jeg holder de mindre vanlige utførelsene i periferien; for eksempel fokusgrupper og domenemodeller. 

Jeg liker også å utforske utførelser jeg kanskje ikke har hørt om før. Det er så mange forskjellige metoder der ute. Det kan virkelig gi deg et bredere perspektiv og gjøre deg til en bedre designer for å legge til noen nye leveranser til arbeidsflyten din.

Konklusjon

Vel som dekker leveranser! Her er noen detaljer å ta bort:

• Artefakter er vanligvis et antall diagrammer som er inkludert under paraplyen av noe større. En artefakt kan imidlertid også være en frittstående leverbar (for eksempel en interaktiv prototype). 
• Artefakter og leveranser er en måte å kommunisere design med interessenter internt og eksternt, og å utdype seg på visjon. De kommuniserer potensielle løsninger på utfordringer og problemer som designere står overfor hver dag.
• Leveranser bør ikke opprettes for en produksjons skyld, men som en måte å gå videre til for å skape det endelige produktet og å nå de definerte målene.
• Faser av prosjektet skal være en ganske god indikator for når du skal bruke hver leverbar, men når du er i tvil, bør du referere tilbake til prosjektets omfang og være klar over noen leveranser som brukes hyppigere enn andre!
• Leveranser er rettet mot enkelte interessenter (vanligvis ledelse, utviklere og eksterne kunder). De kan brukes til alle disse gruppene, men relevansen for hver enkelt vil variere. 
• Designere må gi instruksjoner til de vi jobber med. Enten det er utviklere, samarbeidende organer eller andre interessenter.
• Klarhet er viktig. Vi bruker en rekke diagrammer, eller leveranser til å formidle ideer.
• Leveranser kan tjene som milepæler for å markere fremgang, men først og fremst bør de være en måte å kommunisere et designkonsept på.