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!
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.
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 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!
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 typerPubliken 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.
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.
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.
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 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.
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 kan också falla i ett antal faser inom UX Design-processen:
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 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:
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.
Tja som täcker leveranser! Här är några detaljer att ta bort: