Share
De "deliverable". Een eenvoudig concept om te begrijpen (iets wat u "aflevert"), maar moeilijk om goed uit te leggen.
Een manier om een te leveren product te beschrijven, is als een werkstuk of een artefact dat een collectief is van een grotere groep werk. Bijvoorbeeld: een sitemap, een nav-model en een zoekdefinitie vallen allemaal onder de paraplu van 'informatiearchitectuur'. Om dit product te formaliseren, kan er een document zijn met al deze artefacten en een voorblad met informatie over versiebeheer.
Bovendien kunnen artefacten en deliverables ook standalone en uitwisselbaar zijn. Een wireframe kan bijvoorbeeld worden gebruikt als een deliverable voor een project om een manager te tonen dat u vooruitgang boekt, ontwikkelaars informatie te verstrekken over de benodigde structuur of een mijlpaalbetaling van een klant te ontvangen..
Het belangrijkste om mee te nemen is dat een deliverable niet iets is dat gedaan moet worden omwille van een output, maar om meer duidelijkheid te verschaffen of om het project / product dichter bij de gewenste eindtoestand te brengen. Daarom is het belangrijk om kritisch na te denken over de reden waarom u een deliverable creëert en naar welk niveau van getrouwheid / formaliteit omdat er potentieel is voor het verspillen van veel tijd!
Deliverables hebben een publiek en soms is er wat overlapping zoals weergegeven in het Venn Diagram hieronder. Begrijpen dat publiek is een belangrijke eerste stap in het begrijpen van de behoefte aan het te leveren product en het niveau van betrouwbaarheid of formaliteit dat vereist kan zijn.
Over het algemeen zal de productmanager of een interne manager grotendeels geïnteresseerd zijn in de ontdekkings- en definitiefase. Dit is wanneer de bedrijfsbehoeften en -processen worden verhaspeld en het product wordt gedefinieerd. Daarom is het misschien beter om een afbeelding van sommige lay-outs met de hand te maken in plaats van tijd te verspillen aan het coderen van een prototype, bijvoorbeeld als ze om een representatief beeld vragen van hoe het product er in de regel uit kan zien..
Ontwikkelaars zijn belast met het programmeren van wat is ontdekt, gedefinieerd en ontworpen in definitieve representaties door middel van code. Er is veel ruimte voor misinterpretatie met wireframes. Welke lay-outs ook worden geleverd aan een ontwikkelaarsteam, het moet perfect zijn voor pixels en er moeten specificaties worden gemaakt, omdat uw gemiddelde ontwikkelaar precies datgene zal maken wat u vraagt, vooral als het een uitbesteed team is!
In het geval van klanten moeten deliverables mogelijk meer gepolijst zijn en dienen als marketingtools (om te laten zien hoe goed het bureau is). Soms gebruikt u deliverables om invloed uit te oefenen op de externe stakeholder, of om een deel van een contractuele overeenkomst te voldoen bij het werken met een "mijlpaalbetalingsstructuur".
Doelgroepen en deliverable typesNiet alleen speelt het publiek een grote rol in de manier waarop het product moet worden gemaakt, maar ook de structuur van de organisatie. Niets blijft constant, zelfs binnen dezelfde structuur (zoals een adviesbureau); deliverables kunnen van project tot project variëren. De onderstaande beschrijvingen zijn generalisaties, maar een goed startpunt als je het moeilijk vindt om te proberen te bepalen welk type uitgangen nodig zijn.
Deliverables zijn vaak van hogere betrouwbaarheid in deze omgeving omdat het niet alleen de bedoeling is om het project vooruit te helpen, maar ook om de klant te informeren en ervoor te zorgen dat ze 'wowed' zijn door het deliverable. Het is feitelijk een geruststelling voor de klant dat zij de juiste keuze hebben gemaakt om met u samen over een concurrent te gaan.
Dit is van cruciaal belang in de aanbestedingsfase wanneer een aantal adviesbureaus voor dezelfde functie strijden. Houd er echter rekening mee dat er een aantal andere dingen zijn die klanten in gedachten hebben bij het maken van hun selectie; zoals technologische expertise, middelen, enz.
De deliverables in een "hackathon" zijn ontworpen met het doel om aan een panel van rechters voor te stellen. Er is misschien een slide-deck en je kunt een aantal storyboards, product-roadmaps presenteren ... Alles wat emoties oproept, een probleem en oplossing voor het probleem oplevert en een duidelijke visie van de stappen die voor je liggen, demonstreert! Dit is waarschijnlijk niet de gelegenheid voor een volledig ontwikkeld prototype, tenzij je leden in je team hebt met die mogelijkheid.
In mijn ervaring zijn freelance-optredens (met name die welke online worden uitgevoerd) vaak erg klein van omvang. Het is vaak "Wireframes nodig voor X-app" of "Usability-rapport voor X-website". Deze deliverables worden voornamelijk gebruikt om voltooiing aan te geven in plaats van vooruitgang en zijn vaak gekoppeld aan mijlpaalbetalingen.
Starten van deliverables is grotendeels gericht op ontdekking, validatie en definitie, omdat de ondernemer de markt probeert te kraken. Design is ook belangrijk en deliverables binnen de verfijningsfase van het project zullen draaien rond het idee en het aanbrengen van wijzigingen op basis van feedback van gebruikers en vroege belanghebbenden..
Met 'Productteam' verwijs ik naar een bedrijf dat een of meer digitale producten en interne medewerkers heeft. Deze teams gebruiken over het algemeen deliverables in een end-to-end proces. Ze kunnen minder trouw zijn, behalve wanneer de productmanager moet communiceren en informatie moet verpakken voor leidinggevenden. Elk product heeft de neiging om meer op meerdere fasen van het UX-proces af te stemmen.
Deliverables kunnen ook in een aantal fasen vallen binnen het UX Design-proces:
Soorten deliverables tijdens het UX-ontwerpprocesZoals u kunt zien, zijn er eerder in het proces meer deliverables als het project in grote lijnen begint en er meer werk wordt besteed aan het plannen en proberen vast te stellen wat het juiste is om aan te werken. Dit model is waarschijnlijk het meest van toepassing op productteams en er is veel cross-over in rol tijdens de eerste twee fasen. UX-ontwerpers, productmanagers en bedrijfsanalisten werken mogelijk allemaal mee aan customer journey-kaarten, bijvoorbeeld.
Waarom we deliverables maken, zoals hierboven vermeld, is contextueel. Redenen zijn gebaseerd op rol, type organisatie, publiek en vele andere factoren. Hier zijn vijf van de meest voorkomende redenen om deliverables te maken:
Mijn persoonlijke benadering is om de gemeenschappelijke deliverables voorop en in het midden van mijn proces te houden; zoals persona's, prototypen en gebruikersinterviews. Ik houd de minder courante deliverables aan de rand; zoals focusgroepen en domeinmodellen.
Ik ben ook dol op het onderzoeken van deliverables waarvan ik misschien nog nooit gehoord heb. Er zijn zoveel verschillende methoden die er zijn. Het kan je een breder perspectief geven en je een betere ontwerper maken om een aantal nieuwe deliverables aan je workflow toe te voegen.
Nou, dat dekt deliverables! Hier zijn enkele details om mee weg te nemen:
Accentsconagua