Når målsætninger er indbyrdes uforenelige

Jeg har en websiteopgave på arbejde. Der er egentlig ikke tale om en særligt kompliceret informationsstruktur eller andre applikationsfunktionelle finurligheder. Udfordringen har bestået i at opfylde nogle kriterier, der påvirker hinanden negativt. Det skal forstås således, at opfyldes et kriterie, bevirker det, at et andet ikke opfyldes. Og det på trods af, at alle kriterierne i sig selv er valide og relevante.

Det skal være netop det design

Opgaven indeholder flere udfordringer, men den største udfordring er produktsiden. På produktsiden ønsker firmaet, der har stillet opgaven, at præsentere en række produkter. 16 produkter i alt. Hvert produkt præsenteres kort på produktsiden, og brugen kan så klikke på den kort præsentation og få mere information på en ny side specifikt for hvert produkt. Firmaet har defineret en bestemt grafisk præsentation til de korte præsentationer. Hvert produkt skal præsenteres med et rundt ikon, titel, kort beskrivelse og knap med link til mere information. Det betyder, at hver korte produktpræsentation på produktsiden fylder en del. Produkterne ligger i en blok på 4 x 4 korte præsentationer. Det ser egentligt pænt ud, og er også rimeligt overskueligt. På en 24” skærm vel at mærke.

Det skal passe til alle skærmstørrelser

Et af firmaets andre krav er, at løsningen skal være brugervenlig på alle skærmstørrelser.
På en lille touch skærm ligger produkterne i en lang række under hinanden. Og det betyder, at der skal mange swipes til at bladre ned igennem alle produkterne. Det kunne gøres mere brugervenligt ved at vælge en mindre grafisk fyldig løsning. Og brugervenligheden bliver slemt skadet, når brugeren vil se mere end et produkt.  Hver gang brugeren har set et produkt og vender tilbage til produktlisten, skal han swipe ned igennem produktlisten igen for at se det næsteprodukt på listen.
Kunden vil ikke ændre den grafiske præsentation, så produktinformationssiderne kodes som sider, der opfører sig som pop-up. Det betyder, at brugeren kan ”tænde og slukke” for hver produktinfo uden at forlade sin plads på listesiden. Min dygtige udviklerkollega har kodet det til løsningen.  Og det fungerer fint og ser godt ud på alle skærmstørrelser. Med mindre, altså, brugeren søger sig frem til siden.

Det skal kunne søgemaskineoptimeres

Et af firmaets krav er, at websitet skal kunne søgemaskineindekseres. Et helt validt krav. Og sitet kan da også indekseres. Pop-uperne er konstruerede som selvstændige sider, og fx Google finder dem nemt. Men (Jep, der er et men) siderne præsenteres så også af Google som sider. Det betyder, at deres pop-up form og pop-up relation ikke præsenteres. Brugeren får derfor ved søgning blot en side med billede og tekst uden videre navigationsmuligheder. På en 24” skærm strækkes det yderligere til stor grimhed. Det ordner min kollega med et Java script.

Papirprototyper er en hjælp

Med prototyper i papir klarede vi en del af udfordringerne med det samme og synliggjorde de forskellige problematikker over for kunden.  Så på trods af udfordringerne, har det været en god proces.

Driv en semiotiker til vanvid

Kender du en semiotiker, der trænger til udfordring, så giv ham en anskuelsestavle fra wearepopular i julegave. Mismatchet mellem ord og visuelt tegn vrider den semiotiske hjerne. Min favorit er ”Artikler”.

http://www.wearepopular.dk/tavler

Tavlerne kan også bruges til gaver til andre – bare fordi de er så fede.

Har du lagt et budget? ….Altså et performancebudget

Der er ikke nyt, at brugere af hjemmesider eller apps er utålmodige. 7 sekunder har længe været nævnt som den magiske grænse for brugernes tålmodighed. Men i dag er billedet anderledes. 2-3 sekunders loadingtid er smertegrænsen for 75 % af brugerne i dag. Efter få sekunder uden at få opfyldt deres behov forlader de applikationen.

At man som applikationsejer er nødt til at tænke over performance, er ikke en nyhed, der rydder forsider. Det nye er, at det bliver mere og mere udbredt, at virksomheder forholder sig mere økonomisk til deres applikationers performance – hvad enten disse er eksterne eller interne. Dårlig performance koster ganske enkelt penge. Eksternt koster det penge, hvis kunderne forsvinder til en anden leverandør. Internt koster langsomme applikationer penge, fordi medarbejdere spilder tiden på at vente.

At dårlig performance koster penge har afledt, at vi i dag taler om performanceøkonomi. Og der bliver nu lagt performancebudgetter for applikationerne. Grundidéen er enkel. Loadingtid er en ressource, som er begrænset, så der skal tages stilling til, hvad der må tære på ressourcen. Fuldstændigt som andre budgetter. Hvor meget loadingtid må en feature koste?

Som med anden økonomi er der nogle parametre, man kan bruge til at få tallene til at gå op. Man kan:

  • Forøge budgettet
  • Skære unødvendige elementer fra så udgiften undgås
  • Mindske udgiften for nødvendige elementer

At forøge budgettet – Hvad kan I tilbyde i bytte for sekunder?

En brugt og udmærket måde at forøge budgettet på er venteanimationer. De fortæller brugerne, at applikationen arbejder. At de om lidt får deres behov opfyldt. Det lægger lidt til budgettet. Men ikke ret meget – længere. Tiden er for dyrebar. Utålmodigheden for stor. Med mindre altså du kan give brugeren værdi i bytte for tiden. Hvis din venteanimation er overraskende eller underholdende, kan du forøge dit budget. Og er du rigtigt dygtigt, bruger du det samtidigt til at brande dig selv.

Selvfølgelig er der også bagsider ved sjove eller unikke venteanimationer, fx bliver man jo kun overrasket første gang. Og i længden kan morsomheder, der gentages, blive irriterende og have den modsatte virkning af intentionen. Så test grundigt, inden I kaster jer ud i de vildeste morsomheder og hav evt. forskellige animationer, hvor præsentationen styres efter besøgeadfærd.

Det er også klart, at en bedre venteanimation, hvor god den end er, ikke har indflydelse på den tid, medarbejdere spilder internt på at vente. Her er man nødt til at vurdere, om det er muligt at udnytte ventetiden på andre opgaver. Vil det fx være muligt at ændre rækkefølgen af handlinger, så fx en mindre ressourcekrævende handling kan komme ind og udfylde ventetiden.

At skære unødvendige elementer fra – Skal I stadig bruge den dér?

Her er opgaven at identificere, hvor man betaler unødvendigt. Det svarer til at holde op med at betale den årsrejseforsikring, man i sin tid tegnede. Dengang gav det god mening, og den var nødvendig, men da man ikke længere har brug for den, giver det bedre mening, at sige den fra. Så man får budget til andre ting. Man kan jo så altid lægge den ind i budgettet igen, får man brug for den. Men så er der selvfølgelig noget andet, der må ud. Sådan er det med budgetter.

Det er klart, at denne øvelse for mange er meget mindre underholdende end at finde på sjove venteanimationer, men til gengæld kan den virkelig give plads i budgettet. Og så får man også en mulighed for at få ryddet op i sin applikation.

At mindske udgiften for nødvendige elementer – Kan I få det billigere?

Kunsten i denne disciplin er at finde ud af, hvor I kan få en feature billigere. Det er en sparedisciplin i stil med at skære det unødvendige fra. Men da I ikke kan undvære de elementer, det drejer sig om, må I i stedet se på, om I kan få dem ”billigere”.

Det er i stil med at ændre sit avisabonnement fra hel uge til weekend, fordi man alligevel ikke når at læse avisen i løbet af ugen. Eller hvis man gerne vil læse avisen hver dag, dele abonnementsudgiften med naboen, som læser samme avis.

Iiiih, en ny feature!

Alle nye features, hvad enten der er tale om design eller funktionalitet, skal vejes op imod performancebudgettet. Hvad koster de? Er de det værd? Har vi plads i budgettet? Skal noget andet ud?

Ja, det er irriterende, men der er mindst tre fordele:

  • I er nødt til at værdisætte de forskellige features.
  • I er nødt til at designe den bedst mulige løsning af en ny feature.
  • I er nødt til at fokusere på brugerens behov – især for eksterne applikationer. Opfyldelse af brugerens behov er det, der har værdi og tillader en belastning af budgettet.

Det kan lyde paradoksalt, at det er en fordel, at der er noget, I er nødt til at gøre. Men det er det, for I får det rette fokus. Og gør I det inden, I starter udvikling, kan I ikke alene spare på jeres performancebudget men også spare udviklertid og rigtige penge.