Vad exakt är en leverans?

Den "leveransbara". Ett enkelt begrepp att förstå (något du "levererar"), men svårt att förklara ordentligt.

Ett sätt att beskriva en leveransbar skulle vara som en bit av arbete eller en artefakt som är en kollektiv av en större grupp av arbete. Till exempel: en sitemap, en nav-modell och en sökdefinition skulle alla falla under paraplyet "informationsarkitektur". För att formalisera denna leverans kan det finnas ett dokument som innehåller alla dessa artefakter och ett omslag med viss versionsinformation. 

Dessutom kan artefakter och leveranser också vara fristående och utbytbara. En wireframe kan till exempel användas som leveransbar på ett projekt för att visa en chef du gör framsteg, ge utvecklarinformation om strukturen som krävs eller samla in en milstolpebetalning från en kund. 

Det viktiga att ta bort är att en levererbar inte är något som bör göras för en produkts skull, men för att ge större klarhet eller bringa projektet / produkten närmare önskat sluttillstånd. Därför är det viktigt att tänka kritiskt på varför du skapar en leveransbar och till vilken nivå av trohet / formalitet som det finns möjlighet att slösa mycket tid!

Vem är din målgrupp?

Leveranser har en publik, och ibland finns det några överlappningar som visas i Venn Diagram nedan. Att förstå att målgruppen är ett viktigt första steg för att förstå behovet av leverans och nivån på trohet eller formalitet som kan krävas. 

Produktchef

Generellt är produktchefen eller någon intern chef i stor utsträckning intresserad av funktions- och definitionfasen. Det är när affärsbehoven och processerna hämmas och produkten definieras. Därför kan det vara bättre att leverera en handritad skiss av vissa layouter om de begär en viss representation av vad produkten kan se ut på linjen, snarare än att slösa bort tid på att koda en prototyp, till exempel. 

Utvecklare

Utvecklare har till uppgift att programmera det som har upptäckts, definierat och utformad i slutliga representationer via kod. Det finns mycket utrymme för felinterpretation med trådramar. Oavsett layouter levereras till en dev team måste vara pixel perfekt och specifikationer bör skapas, eftersom din genomsnittliga utvecklare kommer att skapa exakt vad du begär, särskilt om de är ett outsourcat lag!

kunder

För kunder kan leveranser behöva vara mer polerade och fungera som marknadsföringsverktyg (för att visa hur bra byrået är). Du använder ibland leveranser för att påverka den externa intressenten eller att träffa en del av ett kontraktsavtal när du arbetar med en "milstolpebetalningsstruktur". 

Målgrupper och leveransbara typer

Vilken typ av miljö arbetar du i? 

Publiken spelar inte bara en stor roll i hur leveransen ska skapas utan också organisationens struktur. Ingenting förblir konstant, även inom samma struktur (som ett konsultföretag); leveranser kan variera från projekt till projekt. Beskrivningarna nedan är generaliseringar, men en bra utgångspunkt om du har svårt att försöka att hash ut vilken typ av utdata som kan behövas. 

Konsulterande spelningar och digitala byråer

Leveranser är ofta högre trovärdighet i den här miljön eftersom ditt mål är inte bara att flytta projektet framåt, utan också utbilda klienten och se till att de är "wowed" av leveransen. Effektivt är det lugnande för kunden att de har gjort rätt val att gå med dig över en konkurrent. 

Detta är kritiskt i anbudsförfarandet när ett antal konsultföretag konkurrerar om samma jobb. Men kom ihåg att det finns ett antal andra saker som kunderna har i åtanke när de gör sitt val. såsom teknikkunskap, resurser mm.

hackathon

Leveranserna i en "hackathon" är utformade med det syfte att presentera för en panel av domare. Det kan finnas ett bildspel och du kan presentera några storyboards, produktkartor ... Något som kommer att framkalla känslor, kommunicera ett problem och lösa problemet och visa en tydlig vision om de steg som kommer framåt! Detta är förmodligen inte ett tillfälle för en fullt utvecklad prototyp, om du inte har medlemmar i ditt lag med den förmågan.

Freelance Gigs

Enligt min erfarenhet är frilansspel (särskilt de som utförs online) ofta mycket små. Det är ofta "Wireframes behövs för X app" eller "Användbarhetsrapport för X-webbplats". Dessa leveranser används i första hand för att beteckna slutförandet snarare än framsteg och är ofta knutna till milstolpebetalningar.

Starta Ups

Starta leveranser fokuserar i stor utsträckning kring upptäckt, validering och definition, eftersom företagaren försöker att knäcka marknaden. Design är också viktigt, och leveranser inom projektets förfiningsfas kommer att vända sig kring att pivotera idén och göra förändringar bakom feedback från användare och tidiga intressenter. 

Produktgrupper

Med "Produktlag" hänvisar jag till ett företag som har en eller flera digitala produkter och intern personal. Dessa lag använder vanligtvis leveranser i en avslutad process. De kan vara lägre trovärdighet, förutom när produktchefen behöver kommunicera och paketera information till chefer. Varje leverans tenderar att anpassa mer till olika faser av UX-processen.

Leveranser inom UX-processen

Leveranser kan också falla i ett antal faser inom UX Design-processen:

  • Upptäckt
  • Definition
  • Design
  • Förfining
Typer av leveranser under UX-designprocessen

Som du kan se tidigare i processen finns det fler resultat när projektet börjar i stort och det finns mer arbete tillbringat planering och försöker identifiera rätt sak att arbeta med. Denna modell är förmodligen mest tillämplig på produktgrupper och det finns en hel del crossover i roll under de två första faserna. UX Designers, Product Managers och Business Analysts kan alla samarbeta på kundkartor, till exempel.

Varför skapa leveranser?

Varför vi skapar leveranser, enligt ovanstående, är kontextuella. Anledningarna är baserade på roll, typ av organisation, publik och många andra faktorer. Här är fem av de vanligaste orsakerna till att skapa resultat:

  1. Att uppfylla avtalsförpliktelser.
  2. Att indikera framsteg.
  3. Att påverka människor.
  4. För att göra saker tydligare och flytta projektet närmare ett slutmål.
  5. Att göra en i stort sett immateriell process mer synlig med ett antal utgångar.

Mitt personliga tillvägagångssätt är att hålla mina processers gemensamma framträdanden och mitt centrum. som personas, prototyper och användarintervjuer. Jag håller de mindre vanliga leveranserna i periferin; till exempel fokusgrupper och domänmodeller. 

Jag gillar också att utforska resultat som jag kanske inte har hört talas om tidigare. Det finns så många olika metoder där ute. Det kan verkligen ge dig ett bredare perspektiv och göra dig till en bättre designer för att lägga till några nya leveranser till ditt arbetsflöde.

Slutsats

Tja som täcker leveranser! Här är några detaljer att ta bort:

  • Artefakter är normalt ett antal diagram som ingår i paraplyet av något större. En artefakt kan emellertid också vara en fristående levererbar (till exempel en interaktiv prototyp). 
  • Artefakter och leveranser är ett sätt att kommunicera design, med intressenter internt och externt, och att utveckla syn på. De kommunicerar potentiella lösningar på utmaningar och problem som designarna står inför varje dag.
  • Leveranser bör inte skapas för en produkts skull, men som ett sätt att gå vidare för att skapa slutprodukten och uppnå de mål som definieras.
  • Projektfaser bör vara en ganska bra indikator på när man ska använda varje leveransbar, men om du är osäker bör du referera till projektets omfattning och vara medveten om vissa leveranser som används oftare än andra!
  • Leveranser är inriktade på vissa intressenter (vanligtvis ledning, utvecklare och externa kunder). De kan användas för alla dessa grupper, men relevansen för var och en kommer att variera. 
  • Designers behöver ge instruktioner till de vi arbetar med. Oavsett om det gäller utvecklare, samarbetsorgan eller andra intressenter.
  • Tydlighet är viktigt. Vi använder ett antal diagram, eller leveranser för att kommunicera idéer.
  • Leveranser kan fungera som milstolpar för att markera framsteg, men i första hand bör de vara ett sätt att kommunicera ett konceptkoncept.