Hos Dwarf er vi flere gange stødt på, at vores kunder ikke læser vores prototyper. De får dem til gennemlæsning som en pdf eller som et link, hvor de kan klikke sig rundt. Dog sker det, at kunden ikke kommer med nogen feedback på prototypen overhovedet. Vi ved derfor tit ikke, om det er fordi de ikke fatter en brik af hvad prototypen prøver at kommunikere eller om det hele bare er lige i skabet og det er derfor vi ikke hører noget.
Det har fået os til at overveje om prototypen afleveres til kunden i det rette format. Vi veksler mellem at lave interaktive prototyper og statiske i form af pdf-dokumenter. Den sidste form har den fordel, at den kan læses fra den ene ende til den anden. Den første, at den viser interaktiviteten og giver kunden en fornemmelse af hvordan specifikke funktioner virker. Dog diskuterer vi sjældent med kunden om hvilken form de foretrækker inden vi går i gang.
Et andet tilbagevendende diskussionspunkt er hvor meget og hvilket indhold, prototypen skal indeholde. De prototyper vi laver bliver som regel både vist til kunden, men også brugt som et opslagsværktøj for udviklingsafdelingen. Derfor indeholder prototypen tit backend-elementer som ikke altid giver særligt meget mening for kunden.
Hvad er praksis hos jer andre?
Holder I møder hver gang med kunden hvor prototypen bliver gennemgået?
Tager I kunden med på råd i spørgsmålet om det er en interaktiv/statisk prototype der skal leveres – og hvad er jeres egne holdninger til de to typer?
Laver I adskilte prototyper – en til kunden og en anden til internt brug?
februar 21, 2008 kl. 8:14 am |
“Jeg er enig”
Well, hos os laver vi bare ikke prototyper. Det er i hvert fald sjældent. Jeg har tit lyst til det selv – fordi det fungerer godt som udviklingsværktøj eller til idégenerering om hvilken form for forløb og oplevelse, man som udvikler ønsker at skabe.
Al oplevelse jeg har haft med prototyper o.lign. i forhold til kundedialogen er analogt til dét I beskriver her. Det er ganske enkelt en for kompliceret repræsentationsform for langt de fleste kunder, der ikke har en webudviklers indsigt og den deraf følgende mulighed for eller evne til at oversætte prototypen til en indre forestilling om slut-oplevelsens karakter.
Jeg arbejder derfor selv mere og mere udfra en producer-tankegang. Fremfor at forsøge at opdele ting, så forsøger vi at systematisere dét at have en person, der bygger bro mellem alt hvad der involverer slutresultatet.
Denne producer-rolle handler så om at oversætte og handle udfra f.eks. hvad designeren siger om oplevelsen af et forløb fra side til side, hvad programmøren siger om performance, der kan påvirke brugeroplevelsen osv. Hvor en koordinator ville sige “nogen siger at der er et hul i broen – somebody’s gotta fix”, så siger produceren “hvis du nu lige giver dig lidt her, så bliver de andre glade og hullet i broen bliver mindre”.
Den oversættelse og dialog er for mig præcis dét, som prototypen var tiltænkt til at løse overfor kunden. Og det kan systematiseres og professionaliseres lige så meget som Axure-vejen, når det handler om den fælles forestilling om slutresultatet.
Ift. at forbedre selve den interne udviklingsproces, så synes jeg bare prototypen er velfungerende. Dér fungerer den optimalt og løser reelle problemer.
Der vil selvsagt altid være kunder som formår at indgå i denne interne proces og have en kvalificeret dialog omkring en prototype, men jeg har oplevet ganske mange kunder, som bare har sagt, at de ikke kan lide (aka. hader) informationsarkitekter, prototyper og wireframes. No kidding. Og her snakker jeg altså om til tider meget erfarne web-kunder.
februar 21, 2008 kl. 7:06 pm |
Deler generelt ikke jeres oplevelser. Vi har generelt meget gode erfaringer med at bruge helt flade sideskabeloner/wireframes i form af PowerPoint-skitser. Det hænder også, at vi til testformål tidligt i projektet gør dem klikbare.
Generelt er kunderne positive over for denne måde at overlevere information på. Sideskabeloner er lette at forstå og giver et øjeblikkeligt visuelt og håndgribeligt indtryk af, hvad det er, kunden kan forvente.
Vi lader som regel sideskabelonerne være kommenteret – enten i form af noter i PowerPoint-filerne eller i form af små call-outs.
Det skaber en fælles reference for hele udviklingsteamet, som betyder, at de forskellige interessenters forventninger meget tidligt i projektet kan bringes på linie.
Kunderne er som regel meget interesserede i at forholde sig til sideskabelonerne og forstår vigtigheden af det.
marts 4, 2008 kl. 10:05 am |
Jeg har ikke så meget at tilføje til diskussionen, andet end at jeg insisterer på altid at præsentere og gennemgå prototyper med kunden. Det kan godt blive nogle lange møder, men vi opnår større fælles forståelse. Vigtigheden af prototyperne har vi allerede tidligere understreget og illustreret for dem gennem indledende møder og workshops, men jeg synes ikke jeg møder kunder der virker uinteresserede i den del, tværtimod.
Hvad angår værktøjet: Axure er et værktøj – og jeg synes ikke om at indgå i en diskussion om hvilke værktøjer, der er bedre end andre. Min filosofi er, at når grundtegningerne er lavet, så er det komplet ligegyldigt, hvad de blev tegnet med.
Jeg kan, personligt, godt lide Axure – og hos os har vi valgt at bruge det på alle projekter, hvor der er mere end én IA’er på – så vi kan udveklse delprototyper og komponenter. Og vi præsenterer næsten altid klikbare prototyper, fordi “print”-prototyper kan virke mere kedelige og sværere at gå til.
Vi skal, efter min mening, ofte huske på at det er vores job at involvere kunden (og andre interessenter) og at der ikke er noget i vejen med at vi prøver at gøre det hele lidt mere spændende og interessant, end absolut nødvendigt
marts 6, 2008 kl. 10:17 pm |
Jeg oplever at prototyper er blevet et større og større aktiv – ikke alene på grund af kundernes efterspørgsel men også som følge af
outsourcing og de øgede krav til dokumentation.
Vi laver statiske prototyper, der let kan indgå direkte i løsningsbeskrivelsen, som en del af det samlede dokument. Men vi laver også dynamiske prototyper, således at brugertests kan gennemføres vha. screen capture programmer.
Vi gør meget ud af at prototyperne skal fungere som illustrationer af de funktionelle krav, hvilket har vist sig særligt værdifuldt i relation til kunderne og deres oplevelser af en kommende løsning.
Omvendt har vi også erfaret at prototyperne ikke kan stå alene, når de skal indgå som en del af en løsningsbeskrivelse, der bruges som grundlag for et implementeringsprojekt.
Derfor bruger vi gerne en matrix, der indeholder en eksplicitering af den enkelte funktion på den enkelte side, således at dennes navn, type, egenskaber, valideringer, handlinger m.v. er entydigt dokumenteret.