Men først vil jeg sige, at selvom arrangementet rent praktisk var en succes og deltagelse god, så mener jeg ikke rigtigt vi fik svaret på spørgsmålet om, hvordan GA kan bruges til at skabe bedre usability.

Det er måske også grunden til, at jeg gerne vil uddybe her – ikke for nødvendigvis at give et konkret svar, men mere for at sige hvorfor jeg (der trods alt kalder sig usability specialist) synes det er svært – men også interessant – at stille et tilfredsstillende svar.

Hvis du har lyst, kan du se mit oplæg på youtube her:

Link til kommenterede powerpoint slides.

Her kort indlæggets hovedpointer:

Afdækkende/problemsøgende – bekræftende/kvalificerende
For mig er den primære brug af GA: Enten at afdække problemstillinger, altså at identificere steder hvor "det gør ondt" – eller at kvalificere ændringer, altså at se på udviklingen i data, for at vurdere om en designændring har givet den ønskede virkning. I de to dele ligger der ikke selve forbedringen og det er måske en af grundene til at det ikke er GA, men andre processer, der bruges til at skabe bedre usability.

Effekt, effektivitet, tilfredshed
Er jo de tre overordnede dimensioner af brug, som de er beskrevet i ISO-definitionen for usability (9241). Min pointe her er, at vi ikke kan bruge GA til at måle på tilfredsheden, ligesom at det sjældent virker frugtbart at se på de data, der kan bruges til at måle på effektiviteten, fx brugerens tidsforbrug, antallet af sider de kigger på eller antallet af klik. Tilbage bliver "effekt", der primært handler om hvorvidt brugeren kan gennemføre sin opgave. GA kan bruges til at vurdere, hvor langt brugeren kom på vej mod et givent mål, hvordan det end er defineret. Det helt typisk den type viden jeg selv henter fra GA.

Det store webanalyse spørgsmål: Hvad vil du gerne vide
Jeg opfordrer til at du slukker din computer og spørger dig selv: Hvad er det du gerne vil have svar på. Få det formuleret, inden du igen drukner dig selv i tal og grafer der fiser op og ned. Som i alle andre projekter, er det vigtigt at have de rigtige briller på inden du går i gang. Det gælder i særdeleshed også i GA. Formuler det som helt almindelige spørgsmål: "Hvor mange af de brugere der kommer til vores site via forsiden, klikker på billedet øverst på siden?".

De gode svar er relative = du skal bruge mål og konverteringsrater
Det har hjulpet mig at se helt afgrænset på forholdet mellem to elementer i GA. Fx mellem to sider (lad os sige forsiden til en underside) eller en side og et mål (som defineret i GA) eller en side og en hændelse (også kaldet event). Rigtigt mange spørgsmål går på hvordan en sådan konverteringsrate ser ud, forholdet mellem en indgang og et mål. I e-handel tales der meget om konverteringsrater og købstragt og lignende, der på en måde er en række sider/hændelser i rækkefølge, hvor man følger frafaldet undervejs mål et slutmål. I den slags arbejde er mål og proces ret tydeligt formuleret, men alle andre kan også få glæde af at formulere mål for deres site. Det kan være svært for fx websites der mest handler om information/kommunikation, men jeg mener nu alligevel det med fordel kan gøres. Kun derved kan man klarere få et sammenligneligt billede af hvordan bestemte dele af ens site "performer".

Dashboard og event tracking
Der er to steder i GA som jeg trækker frem her. Dashboarded, som man i den nye version af GA kan lave mange af, kan bruges til at: Kommunikere resultater og prioritere ting man vil holde øje med – de af dine kollegaer der ikke bruger GA så tit, kan med fordel gå ind der og se de tal de lige har brug for. Du kan selv bruge det til at holde fokus på de ting der er vigtige for din rolle. Det er let at lave rapporter og præsentere dem på dashboarded. Et glimrende værktøj.

Event tracking har jeg skrevet om tidligere. Det korte budskab her er, at det giver mulighed for at opsætte og styre nogle forsøg, hvor du kan måle på udvalgte elementer på dit website (også ting som ikke er sidevisninger) og bruge disse tal i sammenhæng med alle de andre dejlige tal i GA. I min præsentation taler jeg om tracking af video og hvordan jeg kan give min kollega nogle enkle bud på hvordan hans video-elementer klarer sig (ikke at det direkte er usability, men eksemplet viser hvordan GA kan bruges til at mål på brugen af bestemte dele af sitet).

På det sidste slide  (i videoen altså) opsummerer jeg bare nogle pointer fra ovenstående.

Fra GA til bedre usability?
Her til sidst vil jeg blot tilføje, at jeg tror min vigtigste pointe er at GA er et værktøj der indgår i den cyklus der altid opstår omkring usability: Der afdækkes nogle problemer, der opstilles designforslag, der måles på de designs, der implementeres og måles måske igen for at overveje en ny iteration. Som jeg startede med at sige, så indgår GA for mig i at afdække og kvalificere.

Dog kan man blive meget god til at identificere problemstillinger, hvilket jo næsten er det samme som at identificere problemer i en brugertest. Hvis vi med større sikkerhed kan sige hvor problemet er, så kan vi tage den viden med når vi skal undersøge hvorfor.

Er det så det samme som at gå fra GA til at vide hvad man skal ændre på sitet? Nej, det er det ikke. Dertil skal heldigvis stadig bruges en menneskelig kompetence, sammen med andre værktøjer, både online og offline. Men GA er stadig et godt værktøj i den proces og det giver mening at undersøge og øve sig I at udvide den del af værktøjskassen.

Jeg arbejder dagligt på at blive bedre til at bruge GA til den opgave og jeg kommer til at lave flere SIGCHI arrangementer om emnet. Håber du vil være med. Husk at SIGCHI er på både facebook og Linkedin og at vi meget gerne hører fra dig med ønsker og erfaringer.

Usability KPI i en kommune

En kommune i hovedstadsområdet ønsker helt overordnet at sætte sig en række mål for brugen af kommunens digitale services – alt fra antal henvendelser i borgerservice om barsel til antallet af downloads af bestemmelser omkring sygefraværsregler. Behovet udspringer primært fra tankegang (tror jeg) omkring at styre fremdrift igennem måling – altså en form for ledelsesstrategi. Det betyder at kommunens afdelinger skal definere en række KPI'er – målepunkter på deres ydelser – og på et mere systematisk niveau kunne afgøre om der sker fremdrift på baggrund af de aktiviteter og initiativer/projekter der sættes i søen. Det giver sikkert alt sammen udmærket mening.

Webafdelingen i pågældende kommune står nu overfor en udfordring, om ikke andet, så som kompetence på det digitale område og ansvarlig for at hjælpe resten af organisationen på vej: Hvilke målepunkter skal der opstilles (på vegne af hele kommunens online servicestruktur) og hvordan skal disse måles?

Jeg blev inviteret til at give lidt input, gennemgå et par måder at måle på usability og tage en diskussion med nogle af medarbejderne omkring hvordan de skulle bevæge sig fremad i den proces. Her er i korte træk hvad vi talte om:

Første trin er at beslutte hvad der skal måles på. De enkelte afdelinger har nogle svagt definerede ønsker og forskellige politiske prioriteter, men trænger til at kigge på to ting: Den ene er at få defineret hvad der skaber værdi for kommunen (eller afdelingerne) og den anden er at undersøge hvad der skaber værdi for brugerne. Værdi kan være at have færre borgere der ringer til kommunen og i stedet selvbetjener sig til svar/løsninger. For begge parter er dette en nemmere og hurtigere løsning = værdi. Målet er selvsagt at skabe mere af den værdi for kommunen, ved at forøge værdien for borgerne (det er jo en slags essens af det arbejde med usability).

Hvordan kan den værdi så måles? Det kan være gennem helt almindelig statistik, altså besøgstal eller lignende. Både på den online del, men også på presset på telefoner og email. Uanset hvordan vi skaber den viden, så vil den blive et udgangspunkt, det vi med fint kan kalde for et benchmark. Der vil også blive behov for nogle tilgange til at teste/måle, hvordan brugen udvikler sig, efterhånden som vi re-designer vores digitale services.

Fra den viden kan man også forsøge at skabe nogle usabilitymål. Et usabilitymål kan indeholde en beskrivelse af hvem der skal kunne hvad og i hvilken grad, samt naturligvis et niveau der skal opnås. Så kan kommunen fra test til test, vurdere om der er fremdrift.
En begrundelse for at tale om usabilitymål og for at se på andre tilgang en at kigge på brugs-relateret statistik, er at fx besøgstal og bouncerate%, ikke siger noget om hvor svært brugerne har ved fx at forstå regler eller love. Der skal andre metoder til.

Tre måder at måle på brugen

Den typiske tilgang er at lave brugertests. At stille repræsentative brugere repræsentative opgaver og tage bestik af hvordan det går. Det giver masser af input til at forbedre de digitale services, men der kan være en udfordring omkring at måle på disse tests. Uden måling kan vi ikke arbejde med målepunkter. Men til en start kan man sagtens få tal ud af brugertests, fx den procentvise gennemførelse af testopgaver, antal klik eller den tid det tager at løse opgaven (alt efter typen af test).

En anden tilgang kan være at gå mere digitalt til værks. Her kommer kommunen lidt til kort, fordi der ligger en række tekniske begrænsninger for hvilke værktøjer der må implementeres på kommunale hjemmesider (hvilket jeg personligt synes er bullocks). Men hvis vi lige ser bort fra det, så kunne en tilgang være hændelses-sporing.

I Google Analytics hedder det også Event Tracking. Det er et spændende og relativt nyt fænomen. Fordelen er at der kan opstilles hele specifikke handlinger online, som tælles og opsummeres i Googles Analytics interfacet. Det kan være klik på bestemte elementer, udfyldning af felter, downloads eller alt muligt andet. Det giver mulighed for at komme lidt mere i detaljen end blot sidevisninger og besøg. Det giver også mulighed for at måle på handlinger der foregår på den enkelte side eller opsamle sammensatte handlinger, som man fokuseret ønsker at tælle.

Denne metode giver ikke indblik i hvorfor brugerne handler som de gør, men prøver i stedet at fokusere på at tælle ønskede handlinger, som et symptom (eller målepunkt) på kvaliteten af brugen.

En tredie tilgang kan være at lave A/B eller multivariant test, hvor forskellige variationer af en hjemmeside, eller dens elementer testes live op mod hinanden. Det er også et område under stor udvikling, som har en vis iboende evidensbaseret styrke, fordi man direkte kan måle hvordan forskellige designs klarer sig.

Det kan gøre på mange måder, fra at teste en enkel sides evne til at skabe flere most-wanted-actions, til at vurdere om en hele sekvens af sider får flere brugere til at gennemføre et bestemt forløb. Om det bruges til e-handel eller til regler for sygedagpenge er som sådan underordnet.

Hvad skal vi måle på?

Så lang så godt. Tre forskellige tilgange som har hver deres styrker og svagheder, som til dels kan minimeres ved at afvikle dem sideløbende. Men også tre tilgange som alle har som forudsætning, at man ved hvad man vil måle på.

Så den største opgave, også for omtalte kommune, er at definere: Hvad vil vi måle på og hvilke mål skal vi sætte for brugen?

Kommunen valgte at starte med at indsamle viden. Lave brugertest og spørgeskemaer, for at få et indtryk af den nuværende brugs-situation(er).

Men kommunen er blot et eksempel. Samme behov opstår i denne tid naturligt i mange andre virksomheder, hvor ledelsen meget gerne vil have bedre styre på fremdrift og værdi af alle de digitale services. Men ikke bare værdi som besøgstal eller antal klik – også værdi som kvalitet i brugen – fordi den kvalitet i stigende grad er en afgørende faktor i virksomhedens strategi.

/Ole Gregersen

Den starter her: Jeg, Ole Gregersen, har endeligt besluttet mig for at købe en iPhone!
Jeg vil gerne købe den hos Telia på deres billige Flex-abonnement. Jeg er allerede erhvervskunde hos Telia, hvilket betyder, at jeg skal overdrage nummeret til et privat abonnement og derfor er tvunget til at udfylde, udskrive og aflevere en overdragelses-aftale i en Teliabutik. Lidt kluntet og gammeldags, men hvad. Det klarer jeg nok, jeg forstår at jeg lige der, er offer for en undtagelse, noget der ikek sker så tit.

Her begynder festen!

Har ud prøvet at ringe til en Telia-butik? 80 40 44 44. Telia har sådan noget telefonmenu på alt hvad de laver. Fra et brugs-perspektivt er det tungt og langsomt. "Tryk 1 og dit, tryk 2 for dat. Vi optager dit opkald og alt muligt, tryk 1 hvis det er ok, osv…" – der synes ikke at være grænser for hvor urimelig den dialog må være.

Jeg skal hente min nye telefon på Fisketorvet i København. Men jeg vil gerne sikre mig at butikken har den rigtige model liggende – Telia hjememside angiver at de har udsolgt på nogle modeller og jeg gider ikke gå forgæves – hvilket jeg så alligevel ender med at gøre to gange inden dagen er omme.

Men ok, jeg skal have fat butikken. Jeg ringer på det fælles nummer. "Tryk 1 for dit, 2 for dat. Indtast postnummer og vælg butik 1 ved at trykke dit og dat". Det tager en krig, men jeg omstilles til butikken på Fisketorvet (går jeg ud fra). Ingen tager den. Den ringer cirka 5 dut, så får jeg besked om at den ikke bliver taget og farvel. Systemet lægger på. Hvis der bare er en kunde i butikken, så når en sælger aldrig at tage telefonen inden for periode den ringer. Jeg prøver igen. "Tryk 1 for dit og 2 for dat"…
Super 'effektivt' system, for jeg gider ikke blive ved. Telia undgår at svare og bruge tid. I princippet har jeg ingen reel chance for at vide om der overhovedet er en telefon der ringer ude i virkeligheden.

Men via Fisketorvets hjemmeside, finder jeg så alligevel et mobilnummer til butikken. Jeg ringer op – "de har meget travlt i butikken og ikke tid til at tage telefonen". Fair nok. Der kan være mange mennesker på Fisketorvet.

Jeg kører alligevel til butikken. Nu har jeg hidset mig op til at ville have en iPhone. Nu skal det være.
Så ankommer jeg til butikken. Der er ikke en eneste kunde. Der er til gengæld to unge sælgere der står og hænger. Jeg siger jeg vil købe en telefon. De oplyser at mit abonnement er spærret og at jeg ikke kan komme ud af det før september. Jeg husker svagt noget med at jeg har skiftet abonnement og at der måske var en klausul. Telia ringer og ændrer mit abonnement cirka en gang om året… Slukøret accepterer jeg mit nederlag.

Jeg ringer dog til erhverv og finder ud af, at det er en fejl. Fejlen bliver rettet. Jeg er ikke bundet mere (jeg går ikke i detaljer her, men det var sgu også ret åndssvagt).

Tilbage til butikken – nu skal jeg have min iPhone!

Der er stadig optaget på telefonen. Samme stemme der oplyser at de har travlt. I butikken står de to unge stadig og glor, ikke en kunde i sigte. Jeg fortæller dem om telefonsvareren. de griner smørret.
Nu er jeg klar til min iPhone. Men de har bare ikke en på lager. For helvede.  De har til gengæld den model der er beskrevet som udsolgt på Telia's hjemmeside. Jeg tager hjem og overvejer om noget større i universet prøver at fortælle mig at det hele er en dårlig idé med den alligevel alt for dyre og unødvendige dims.

Her kunne jeg så komme med sådan nogle kloge forslag til hvordan Telia skal arbejde med den samlede User Experience på deres kontaktpunkter og jeg kunne skælde de unge mennesker ud for deres åbenlyse ligegyldige og sjuskede omgang med Telias brand og serviceniveau. Gode råd til virksomhedens User Experience Design.
Men jeg vil hellere komme med nogle handlingsorienterede forslag til Telia's telefonsvarer-strategi – de er jo trods alt eksperter i telefoner, men åbenbart bare ikke i hvordan man kommunikerer i dem:

Forslag til besked i telefon når man skal i kontakt med butik: "Kære dig der har ringet. Her i Telia har vi vurdere, at det er alt for dyrt at bruge tid på at tale i telefon med dig. Desuden vil vi helst undgå at du ringer direkte til vores butikker. Derfor slutter opkaldet her. Tak for din forståelse." Dut. Det er effektivt. Både jeg og Telia har nu sparet flere minutter – gange antallet af opkald = win-win for alle!

Jeg vil også hellere udtrykke mig lidt jordnært:
Kære Telia. Det er simpelthen for slapt. Det er en af de mest sjuskede og kluntede serviceoplevelser jeg har haft længe. Det er ineffektivt og potentielt forulempende. Kommer i lige ind i kampen!?

Min samlede oplevelse er at I kan rende mig i røven – venligst. Jeg vælger af uransagelige grunde at blive ved med at være jeres kunde, men I vil fra nu af, blive mit glanseksempel på hvorfor det er vigtigt at holde styr på den samlede brugeroplevelse. I bliver min case, når jeg skal forklare hvordan det ikke skal gøres, når de forskellige kontaktpunkter og kanaler skal spille sammen på en velfungerende måde.

Og – det var jo ikke fordi det var en helt særlig prekær situation. Det var en helt almindelig, dagligdags arbejdsgang for en kunde: Vælg produkt på hjemmeside, ring til butik, hent produkt. Det skal Telia altså have 100% styr på efter min mening.

 Jeg glæder mig dog stadig til en dag at hente min iPhone i en af jeres travle butikker…

Ole

“Du skal ud i virkeligheden” – ja hvad pokker skulle vi ellers. Det er (sgu) ikke en nyhed, at vi skal ud i virkeligheden og lære vores brugere, kunder, marked at kende. Jeg forstår ikke at det budskab sælger billetter. Men hvis det kommer som en overraskelse for dig, at du skal ud af stolen og ud i virkeligheden, så har du lang vej endnu. Der findes ikke en bog om usability eller UX, hvor det ikke står på side 1.

“Det tager ikke 5 år på universitetet at lære” – Nej, hvem har også påstået det? Nu skal jeg lære dig det: “Gå ud og interview og observér”. Værsgo’ det tog 5 sekunder. Men som så meget andet, så er det nu alligevel ikke så nemt. Det handler meget om erfaring og om at lære at udføre på en god måde. Forberedelse, udførelse og analyse kræver simpelthen erfaring og hvis man også har brugt lidt tid på at studere fejlkilder og ting som validitet, så er man bedre rustet.

“Lad ikke fordomme og politik stoppe god research” – Er det ikke dejligt at der stadig (?) findes masser af virksomheder, som sidder i mørke kældre, med topstyrede vandfalds-modeller og vat i ørerne, der ikke har fattet noget som helst af hvad der er foregået på nettet de sidste 20 år. Hurra! Nu kan IT-bureauet fortælle jer, at I skal komme ud af busken. Storartet. Men man behøver jo ikke tale ned til folk…

“Det er det, der sker de fleste af gangene” tilføjes det. Er det virkeligt sandt. Ok, så skal jeg lige skrive en hurtig bog mere, for den er da for nem…

Agile processer, iterativt design – hallo, er der aldrig nogen der har hørt om det? Jeg har ikke hørt om andet siden 1995!

En personlig holdning til sidstnævnte er, at problemet som oftest er, at de der ikke ønsker for meget af virkelighed – og hellere vil lade personlige eller politiske strømninger styre projektet – også er de, der bestemmer, hvorvidt der skal udføres  bruger research. Så hvem er lige modtageren for det budskab. Lederne? Næ, de er jo problemet og lytter derfor ikke nødvendigvis. Medarbejderne på gulvet? Ja sikkert, men de skal jo bokse med lederne og i så fald er opgaven en helt anden.

Så lær os lige er bokse med lederne i stedet for at fortælle hvad vi skal gøre rent praktisk. Jeg plejer også at sige, at metoder og udførelse efterhånden er lidt “kedeligt og banalt” at fortælle om. Bare giv os ressourcer til at udføre arbejdet, så skal vi klare den – om ikke andet tillære os metoderne på lyntid. Det er mere det at få lov det kniber med.

Men ok. Lad os da bare sammen løfte banneret og holde ryggen rank. Der er åbenbart stadig masser af uvidende zombier derude vi kan belære. Måske er de bare usikre eller måske er de netop bare de der ikke har været 5 år på universitetet. Der er lang vej endnu mange steder, men vi skal nok til at have nogle andre værktøjer i brug. Ikke de værktøjer der handler om metoderne, men dem der handler om argumenterne. Sådan at vi ikke bare siger “der kan I se, det går galt hvis I ikke gør det” – show me, don’t tell me – giv mig værktøjer til at få tilgangen, metoderne, strategien osv integreret og implementeret.

Det har vi brug for og de frugter hænger faktisk ret højt.

Lad mig lige bruge et par linjer på at beskrive, hvorfor jeg selv mener at den situation er opstået. Mere overordnet går usability eller UX ud på at se på IT-udvikling med et brugs-centreret perspektiv. På et tidspunkt i udviklingsprocessen skal noget tankegods oversættes til mekanik. De der traditionelt ofte har skulle foretage denne oversættelse er udviklerne. De har gerne opgaven med at omsætte nogle krav, som kan være meget overordnede, til noget teknologi. De designer, foretager valg, beslutter. Det er i den proces de ofte ikke er kvalificerede til at – kvalificere. De har en anden faglig baggrund, kommer fra en anden uddannelsesmæssig kultur og er løsningsorienterede. De har som regel slet ikke direkte empirisk indblik i hvordan produktet skal bruges og har ikke mulighed for selv at kvalificere deres designvalg.

Men – og det er her jeg synes man burde ændre retorikken – er det nu også fair at give udviklerne det ansvar og dermed skylden for ikke at arbejde brugercentreret nok?

Nej, naturligvis ikke. Det skal de heller ikke umiddelbart, det er ikke deres opgave. På samme måde som jeg ikke skal bestemme hvordan en teknisk validering skal skrives eller bestemme hvordan databasen bedst normaliseres.

Skylden må i første omgang placeres hos ledelsen. Den ledelse, der ikke sikrer at der er kompetencer og ressourcer til rådighed, til at få kvalificeret designbeslutninger igennem hele udviklingsprocessen. Se bare på Usability Maturity Model. For den handler langt overvejende om at sikre, at de rigtige metoder, processer, ressourcer og kompetencer er til stede i organisationen.

Så usabilityfolk skal holde op med at skyde på pianisten, men i stedet skyde på barejeren.

Det ændrer dog ikke ved den udfordring der stadig eksisterer. Det ændrer heller ikke ved at usabilityfolket, til stadighed må arbejde på at sælge budskabet, til både udviklere og ledelse, uanset hvor træls det kan blive i længden (vi ved vi har ret?). Det ændrer heller ikke ved, at vi skal blive ved med at finde gode måder at gå fra idé og koncept til teknologi, uden at tabe brugerne og os selv på vejen.

Men alt det ved vi jo godt…

iOle

Der er flere grunde til at det er interessant: For det første er det helt rigtigt at Google sådan officielt definerer user experience, så alle kan se det (andre har nok gjort det før dem, men alligevel). Det sender signaler af flere slags, især til omverdenen, men reelt også indadtil. Et signal der siger: Kære medarbejdere, det her er hvad vi står for. Og siger: Kære omverden, det her er hvad I kan forvente. Og i særlig grad siger: Kære konkurrenter, det her er vores udgangspunkt, det er her vi vil være bedst.

Min holdning er at alle virksomheder på samme måde burde fremsætte sådanne aspirationer, sådan at medarbejdere, ledelse og konkurrenter kan se hvad niveauet er. Ligesom HR-afdelingen typisk har travlt med at lave værdier for medarbejderne, så er det her noget lignende for user experience.

Jeg har tidligere præsenteret forskellige usability-kriterier: Let at lære, fejltolerant, effektivt osv, som jeg mener kan danne udgangspunkt for en usability målsætning for en organisation.

Google laver også kriterier, når de siger at de vil lave:

[ designs that are useful, fast, simple, engaging, innovative, universal, profitable, beautiful, trustworthy, and personable. ]

De enkelte kriterier bliver så uddybet, med en overskrift (Fast = Every millisecond counts – hvilket nærmest er målbart), og en beskrivende tekst. Som en heuristik kunne man sige.
Man kan ikke direkte aflæse hvordan Google sikrer at disse målsætninger opretholdes, selvom de kommer med anvisninger som: “Our products ask for feedback, and Google acts on that feedback.”

Vi ved ikke hvordan og hvor meget, men vi kan håbe at Google har styr på det. Hvis man selv laver sådanne kriterier, så anbefaler jeg trods alt at man gør det færdigt og klistrer nogle processer, metoder og ressourcer på. Ellers er det bare varmt luft – hvilket det godt kan være fra Google’s side.

Der udover har Google deres 10 Things filosofi, der starter med:

Ten things Google has found to be true:
1. Focus on the user and all else will follow.

Det lækre er, at det er noget de siger er baseret på erfaring. Det er da glædeligt.

Det inspirerer mig – om ikke andet. Jeg vil begynde at lede efter andre virksomheders kriterier, det ikke noget jeg har gjort før, men mon ikke det også findes for andre store virksomheder. Det kan være der kan siges noget generelt her…

OLe