Dette er bloggpostene som traff våre lesere best i 2011.

1. Netlife redesign:  I mars fikk Netlife Research ny merkevareplattform og grafisk profil. Her gir Inge et innblikk i prosessen bak designet.
2. App eller webapplikasjoner? Hva skiller apper fra webapplikasjoner og når er det smart å utvikle det ene fremfor det andre? Nikolai forklarer.
3. 5 metoder for å sjekke om nettstedet ditt funker: Vet du hva brukerne dine vil ha, hva de er fornøyd med og hvordan de opptrer på nettstedet ditt? Bjørn viser deg fem metoder for å komme i gang.
4. Unngå tapsprosjekt – prøv vår ROI-kalkulator: Får du noe igjen for investeringene på web? Anders har utviklet en ROI-kalkulator som hjelper deg med å finne ut hvor lønnsomt nettstedet ditt egentlig er. Denne har Smashing Magazine publisert en variant av.
5. Sosiale medier 2012 edition. Dette bør du tenke på: Nå har vi kommet så langt at vi ikke leker sosiale medier lenger, det må planlegges på samme måte som arbeid med andre kommunikasjons- og markedstiltak. Sesilie forteller hvordan.
6. Navigasjon: 5 myter og 1 paradigmeskifte: Are går gjennom hovedpoenga fra debatt-innlegget som forårsaka ein ganske heftig debatt på Kjøkkenfesten for ei tid tilbake.
7. En nybegynners vei fra papirskisser til HTML5: Må designere kunne kode for å gjøre en skikkelig jobb? Ida gir deg et nybegynnerperspektiv på koding som prototypingsverktøy.
8. Dette kjennetegner en god webskribent: Ove forteller hva vi ser etter når vi ansetter innholdshoder i Netlife Research.
9. - Konsulenter, skjerp dere: Slutt å synse. Slutt å kaste bort tiden vår. Eivind Lund er klinkende klar i sin tale til landets webkonsulenter. Bjørn rapporterer fra den nå så kjente debatten mellom Jostein og Eivind på Webdagene.
10. 5 grunner til at norske nettbutikker bør gå mobilt: 2011 – året da mobil e-handel begynte å ta av! Anders stiller spørsmålet: Har du råd til å vente?

Hva har du lyst til at vi skal skrive om (evt. skrive mer om) i 2012?

Det kommer et tidspunkt i prosjekter der ting har satt seg, man har fått flyten, og det går raskere å bli enige når interaksjonsdesignskissene kommer på bordet. Det er da det bør gå opp et rødt flagg.

Dersom man blir raskt enige kan det bety at man tenker for likt. Man jobber mye sammen, blir påvirket av hverandre og da er en slik utvikling nesten uunngåelig. Og litt for komfortabel. Løsningene blir enkle for oss som skal lage dem, men blir de enkle for sluttbrukerne?

Dette er et av mange argumenter for ulike typer brukerinvolvering (brukertesting, beta-testing, etc.). Men før du kommer dit, prøv denne enkle og billige teknikken for å kvalitetssikre i tidlige faser av prosjektet.

Slik gjør du

1. Samle sammen 4-5 personer som ikke er “infisert” av prosjektet, men som har mye kunnskap om enten domenet, konseptutvikling, interaksjonsdesign eller brukeratferd. Og som ikke er redde for å kritisere. 
2. Få med deg en person som kan notere, og som ikke skal komme med innspill samtidig.
3. Gi deltakerne minimalt (akkurat nok) med bakgrunnsinformasjon og vis dem skisser til løsningen. La dem fyre løs en times tid, med spørsmål, kritikk og forslag til forbedringer. Og uten at du forsvarer deg.
4. Ikke bruk mye tid på hvert innspill, bare akkurat nok til å forstå og notere innspillet. Gå så videre til neste innspill. Da får du utnyttet de kloke hodene til ekspertene du har der den timen på best mulig måte.

Erfaringer

Det er tøft å sitte der og ta imot kritikk, man har jo som regel gjort så godt man kan. Jeg merker at det er lett å skli over i (bort)forklaringer om hvorfor ting har blitt som de har blitt. Men tenk da på dette: de menneskene som skal bruke systemet til slutt kommer ikke til å ha deg ved siden av seg til å forklare hvorfor ting er som de er. Og ikke er de interesserte i forklaringene heller.

Det vil være gode grunner til ikke å ta hensyn til en del av innspillene, men vær da bevisst på hvorfor. Baker man inn alle gode innspill vokser løsningen ut av sitt gode skinn, så ha med i briefen til ekspertene at de gjerne kan se etter elementer som kan tas ut.

Hvorfor bare en time? Helt pragmatisk årsak. Det er ganske lett å få ekspertene til å bli med en time, men bare en halv time ekstra gjør det vanskeligere å få det til å passe inn i en travel arbeidag. Det hjelper også å reklamere med null forarbeid og etterarbeid, og at de bare kan lene seg tilbake og kritisere uimotsagt. Hvem kan motså det?

Mer om teknikken

For de som gjerne vil ha en metodisk tilhørighet for en slik gjennomgang, så regnes den som en av de gode gamle “usability inspection“-teknikkene, og kalles gjerne “pluralistic walkthrough”. Selv om jeg oftest kjører en slik gjennomgang med eksperter på interaksjonsdesign og brukskvalitet, evt. med observatører fra utviklingsteamet, så kan man også involvere brukere og andre domeneeksperter.

Innenfor programutvikling gjør man noe som minner om slike gjennomganger, “code review”, der en eller flere programmerere går gjennom en annen programmerers kode og sjekker at den er effektiv, godt strukturert, etc.

Give-away

Jeg har lagt ved en liten presentasjon som jeg bruker som innledning til gjennomgangene mine. Du er hjertelig velkommen til å bruke den som utgangspunkt hvis du skal gjøre noe liknende. Jeg vil anbefale deg å prøve det. Det er litt ubehagelig, men veldig nyttig.

Hvordan pleier du å kvalitetssikre i tidlige faser av prosjektet?

Last ned PPT-fil

1. Lag grensesnittskisser med riktige proporsjoner for mobilenheten (f.eks. iPhone, iPad, Android eller Blackberry).
2. Legg bildefilene på Dropbox og åpne dem i Dropbox-appen på mobilenheten.
3. Sjekk at elementer er store nok, står langt nok fra hverandre, at sekvenser virker logiske, at ikke skjermbilder er overfylte, etc.

Dette er enkelt og kjapt å gjøre, og du kan teste kontinuerlig og gjennom hele designprosessen:

• Test håndtegnede konseptskisser
• Test wireframes
• Test grafisk design

Man kan selvfølgelig bruke andre tjenester enn Dropbox, kom gjerne med tips til alternativer.

Metoden har klare begrensninger, siden selve interaksjonen ikke virker. Men man kan komme ganske langt, og eliminere potensielle problemer tidlig i prosessen.

Hvordan prototyper og tester du mobilapper i ulike stadier av utviklingen?

Johnson jobber i en avdeling som lager verktøy for animatørene i Pixar, blant annet verktøy for å sette sammen storyboards (tegninger av scener i filmen) til en full-lengde prototype av filmen.

Pixar spiller inn dialogen (voiceover) først, fordi det bestemmer lengde og timing på filmen, og så legger de inn storyboardene etterpå.

Når prototype-filmen er ferdig vises den i kinoformat for alle relevante interessenter, både beslutningstakere, markedsfolk og de som lager filmen.

Johnson sier at det er først når de ser prototype-filmen i fullformat i en kino-setting at de klarer å se både hva som fungerer og ikke fungerer. Selv om scenene ikke er animert, så gjør selve formatet og at ting er satt sammen i riktig sekvens at de ser hva som må forenkles eller forandres. Han anbefaler sterkt å prototype i det samme mediet som sluttproduktet faktisk skal være i.

Det er paralleller her til hvordan vi prototyper nettsteder. Inge Fossland hos oss er en stor tilhenger av å prototype designet i HTML med XML-data. Etter utforsking og gradvis detaljering gjennom konseptskisser (lo-fi prototyper – se f.eks. Veronicas artikkel om skissing eller Marthas om papp-prototyping) går vi over til hi-fi prototyping med virkelige data.

Ved å prototype med virkelige data ser man hvor godt designet tåler ulike mengder data, litt tilsvarende grenseverditesting i programvareutvikling. Ingresser kan ha ulike lengder, noen felter er det ikke lagt innhold i, noen ganger er det et bilde der, andre ganger ikke – slike situasjoner gjør at sidemaler oppfører seg og ser forskjellige ut.

Ved å bruke virkelige data ser man bedre hvor det må gjøres endringer. Man må tenke nøyere gjennom hvor innhold skal komme fra og hvem som skal produsere det. Og kunden – nettstedseieren – kan være mer involvert i prototypingsprosessen gjennom å starte innholdsproduksjon og tenke på publiseringsrutiner på et tidlig tidspunkt.  Lorem Ipsums dager er definitivt talte.

Her er en startpakke med 78 gode user experience (UX)-blogger og oppskrift på hvordan du effektivt følger med på dem.

Tvitreren @qthrul skriver i en tweet:

The true power of RSS is the ability to ignore the sheer volume of information more easily.

Blogglesere hjelper deg definitivt med dette.

• Blogglesere – en lise ved informasjonsoverlast
• Abonnere på blogger
• Gode UX-blogger
• Oppskrift
• Om framtida til RSS og blogglesere

Blogglesere – en lise ved informasjonsoverlast

Heldigvis finnes det hjelpemidler for oss som gaper over for mye: RSS-lesere, nyhetsaggregatorer – kjært barn har mange navn. For letthets skyld kaller jeg alt sammen for blogglesere fra nå av.

Blogglesere gjør slavejobben for deg – de følger med på om det er noe nytt på de bloggene du er interessert i. Du går ett sted for å sjekke om det er endringer, og slipper å gå til hver enkelt blogg for på sjekke. Det er raskt å skumme titler og sammendrag av innleggene for å se hva som er interessant og ikke.

For å lese innleggene går jeg nesten alltid til selve bloggen, det gir som regel en bedre opplevelse.

Uleste innlegg markert omtrent som i e-postprogrammer (eksempel fra Bloglines)

Min strategi for å holde meg oppdatert og fortrinnsvis dele med andre er omtrent som så:

• Bruke maks 5 minutter hver dag eller annenhver dag til å skanne uleste innlegg og markere de jeg vil lese, samt markere “lest” de jeg ikke vil lese
• Lese de artiklene som virkelig trigger der og da – hvis jeg har tid
• Tvitre eller maile mine kolleger hvis jeg finner noe bra eller kuriøst
• Returnere til innlegg jeg har spart ved anledning, f.eks. fra mobil når jeg venter på bussen, eller fra sofaen når jeg ser på en gammel “That 70s show”-episode med et halvt øye

Jeg vil anbefale en web-basert bloggleser, da har du alltid en oppdatert versjon av leselista di som du kan bruke fra ulike maskiner eller håndholdte enheter.

Abonnere på blogger

De fleste blogger er godt tilrettelagt for å abonnere.

Når du klikker på et oransje RSS-ikon, eller en lenke til en RSS-strøm får du som regel mulighet til å abonnere direkte i ulike blogglesere (se under).

Abonnere på en RSS nyhetsstrøm

Gode UX-blogger

Jeg har gjort en grov klassifisering av “mine” UX-relaterte blogger for å få litt struktur på det, men dette er ikke noe stringent bloggklassifiseringssystem. Det er heller ingen komplett liste. Men det kan være en startpakke som man kan nøste seg videre fra. Oversikten finner du på http://www.bloglines.com/public/karihamnes.

Blogg-kategorier i oversikten

Kategoriene ligger som mapper i venstre marg, og så er det bare å bla seg gjennom. Du kan eksportere listen og legge inn i din favorittbloggleser (se oppskriften under).

Oppskrift

1. Hvis du ikke allerede bruker en bloggleser, prøv en av de som Appstorm har tatt med i oversikten over 10 av de beste/mest brukte web-baserte bloggleserne.
2. Har du Google-konto er det lavtersel å bruke Google Reader, da slipper du registreringen.
3. På min oversikt over UX-blogger velger du “Export Subscriptions”  (venstre kolonne, se bildet under). Da vil du laste ned en fil som heter export.opml. Det er en XML-fil som har lenke til de ulike bloggene, samt beskriver organiseringen i mapper. Lagre filen lokalt på din maskin. Alternativt: Last ned export.opml direkte
4. Logg inn på din egen bloggleser og velg å importere den samme .OPML-filen. Under er vist hvor du gjør det i Google Reader, Bloglines og Netvibes.
5. I bloggleseren din kan du ordne mappene etter ditt eget hode eller slette abonnement du ikke vil ha.

Importere bloggliste i Google Reader: Google Reader > Settings > Reader settings > Import/Export: Importere abonnement (.OPML-fil)

Importere bloggliste i Bloglines: Bloglines >Additional Features > Import Subscriptions: Importere abonnement (.OPML-fil)

Importere bloggliste i Netvibes: Netvibes > Add content > Add a feed > Import: Importere abonnement (.OPML-fil)

Om framtida til RSS og blogglesere

Det kommer stadig meldinger om at “RSS er død, leve Twitter“, og at Twitter og Facebook tar over den rollen RSS og blogglesere har hatt. Mange abonnerer på nyhetsstrømmer på Facebook, fordi de likevel er på Facebook – så hvorfor ha enda et sted å måtte sjekke innhold?

Her går det begge veier. Når du søker på Twitter får du tilbud om en RSS-strøm på søkeresultatsiden. Denne RSS-strømmen kan du abonnere på i bloggleseren din, og så vil bloggleseren følge med om det kommer nye meldinger som handler om det du har søkt på.

Jeg er fortsatt mest opptatt av å klare å følge med innen fagområdet mitt uten å slite meg i hjel. Om det er blogglesere, Twitter eller Facebook som hjelper meg er ikke så viktig. Det som er viktig er at det er så mange gode blogger og så lite tid! Blogglesere erverktøy som kan hjelpe.

Hva er dine favorittblogger innen user experience-området? Og hva gjør du for å rekke å følge med?