Jacob Hage

Jeg og to kolleger arbejder for en stor international kunde for tiden og på vej til Düsseldorf, sad jeg endnu engang og diskuterede service design med min kollega, Flemming. Vi har ofte drøftet kvaliteten af den service virksomheder i servicesektoren leverer. Det er et felt, jeg først for nylig har fået øjnene op for, men nu er de til gengæld åbne. Det er grundlæggende ret enkelt: Det handler om at en virksomhed skal skabe gode (bedre) services for dens kunder.

Great experiences
Oftest handler vores samtaler om den generelt dårlige service man oplever eller de situationer, hvor der liiige mangler den sidste indsats… men denne dag på flyturen var vi (for en gangs skyld) positive og i et anfald af optimisme foreslog jeg, at oprette en blog, hvor vi kan poste indlæg om positive service oplevelser. Vel ankommet på hotellet blev Wordpress hentet ned, installeret og efter at have fundet et passende theme, og redegjort for de første gode serviceoplevelser var vi klar med bloggen gr8xperience.com. Her kan du bl.a. læse om vores flytur, en togtur i Oslo m.m. Og der er flere positive historier på vej i trykken…

Er netop startet på et igangværende projekt, hvor en række udviklere brygger på en Ruby on Rails prototype. Jeg har længe ledt efter en undskyldning for at kigge nærmere på dette framework, så her er en god chance for at kigge med fra sidelinien.

Der er ingen tvivl om, at man med Ruby hurtigt kan producere “noget” brugbart – spørgsmålet er blot, hvad det skal kunne bruges til. I det konkrete projekt fungerer Ruby-prototypen netop som en prototype af det endelige produkt. Dvs. at dropdown-menuer trækker indhold fra datamodellen og at data opdateres på baggrund af brugerens handlinger – so far so good. Til gengæld halter interfacet – de Ruby-genererede sider kan ikke gøre det ud for den endelige løsnings look and feel (endnu). Det forekommer mig at skabe visse barrierer, når prototypen præsenteres for kunden. Fair nok at dropdownmenuerne fungerer, men de er “kastet ind” i layoutet.

Selv er jeg stor fan af Axure. Det er ikke data-baseret, men man kan simulere handlinger meget let. Man kan lynhurtigt banke et mockup sammen og evaluere såvel form som funktion. Det er nemt at foretage forbedringer, iterationer og eftersom man ikke har noget kode-lag, så føles det ikke så slemt at “kill’e en darling”.

Så hvor står vi? Axure har været ekstremt nyttig til at visualisere tanker og flows (på bare én formiddag er vi kommet forståelsesmæssigt længere end de foregående dage). Ruby har derimode foreløbig ikke bidraget synderligt til forståelsen af den kommende løsning (efter min mening). Jeg ved dog af erfaring, at der kommer et tidspunkt, hvor Axure ikke længere slår til. Når de grundlæggende skabeloner, sidetyper og flows er defineret og de enkelte elementer er skitseret og placeret, så opstår behovet for at berige prototypen med “rigtig” funktionalitet. Her er jeg spændt på at se, hvor effektiv Ruby egentlig er, og hvor hurtigt man kan levendegøre det brugerinterface, jeg har skitseret i Axure.

I disse dage er vi en fase, hvor alt kan laves om, og der er det rart at kunne rive elementer fra hinanden og simultanprototype mens man diskuterer løsningen med kunden. Så min foreløbige konklusion er, at vi er ude i den klassiske “brug-det-rigtige-værktøj-til-det-rigtige-behov”. Axure forekommer mig fornuftigt at bruge i denne indledende designfase, mens Ruby formentlig vil komme til sin ret allerede om få dage, når løsningen er blevet moden.

Fortsættelse følger…