Misforståelsen om bruk av farger i wireframes/prototyper

De fleste interaksjonsdesignere unngår å bruke farger  som virkemiddel når en designer wireframes/prototyper. Årsaken er grei nok; bruk av farger forvirrer mottakeren (klienten/prosjektgruppen), og det er vanskeligere og styre diskusjonen til å handle om funksjonalitet og informasjon når enkelte finner det nesten umulig å se forbi paletter og layout.

Ed_wireframes Wireframes eller prototyper er et vanskelig dokument å forstå for de som ikke lever i bransjen. Hvorfor vil en da øke forvirringen ytterligere ved blande farger inn i dette også?

Et av hovedproblemene er at wireframene blir oppfattet som design. For å begrense forvirringen for kundene er derfor standarden å trappe ned på de visuelle elementene og forholde seg til mono- eller duotone skisser (en eller to farger). Mest vanlig er svarte strek på hvit bakgrunn eller lys, lys blå bakgrunner i bokser som har en tynn strek/ramme rundt.

Men, på den annen side:

Riktig strategisk fargebruk er svært viktig for å fremme det intuitive grensesnittet, og for å hjelpe kunden til å forstå og finne frem på nettstedet uten å måtte l-e-s-e seg frem. Det er både det raskeste og samtidig et av de sterkeste virkemidlene vi har innenfor kommunikasjon. Brukt strategisk riktig vil farger hjelpe til med å gjøre grensesnittet mer brukervennlig og effektivt for de besøkende.

Spørsmålet jeg stiller meg er om det er opp til den grafiske designeren eller interaksjonsdesigneren å bestemme at farger skal brukes for å mellom annet:

  • Utheve/dempe enkelte innholdsflater i forhold til hverandre innad på en skjermflate.
  • Tydeliggjøre relasjon og sammenheng mellom informasjon på tvers av et helt nettsted.
  • Intuitivt hjelpe den besøkende til å forstå og bruke nettstedet uten å måtte l-e-s-e seg frem til innhold og logikk.

Det er opp til interaksjonsdesigneren og forsterke logikken og nytten av nettstedet, mens det er opp til den grafiske designeren og forsterke disse egenskapene gjennom visuell merkevarebasert kommunikasjon. En interaksjonsdesigner skal altså ikke bestemme farger og gradienter, men skal dokumentere for den grafiske designeren hvor det er viktig at farger brukes.

En interaksjonsdesigner burde bruke farger i wireframene og ta ansvar for den styrken visuelle virkemidler har inn i den strategiske delen av nettdesign. Så får det heller bare kreve en runde ekstra med forklaring i møte de første gangene.

Vedlagt ligger et utkast/wireframe med fargene inkludert. Her bruker vi farger (rødt) for å illustrere søkeapplikasjonens fokus på tvers av alle sider/maler, samt at vi tydeliggjør at der skal brukes farger som merkelapper (blått, gult og grønt) på de ulike underkategoriene for å hjelpe kunden med å identifisere de ulike kategoriene. Vi har også lagt et eget fargelag (lyseblått) bak ”Rådgivning”bolken til høyre for å understreke at denne må visuelt skilles fra det omliggende designet ved hjelp av en bakgrunnsfarge. (pdf )

En av måtene vi forsøker unngå sammenblandingen av wireframes og design er ved å bruke være egne (Objectware) sine profilfarger i alle modeller og verktøy, og unngår derfor å strekke opp noen referanser til kundens profil eller trå inn på den grafiske designerens fagdomene.

Verktøy for oversikt og forståelse

Hvordan fungerer konseptmodeller som verktøy for å forenkle forståelsen og forsterke detaljene i et nettprosjekt?

Ed_konseptmodeller Er dagens eksisterende modeller og verktøy gode nok? Jeg stilte spørsmålet for et par dager siden og tenkte supplere med en referanse til den utforskingen som vi gjør i forhold til nye metoder.

I det siste har vi (gjennom jobben min som rådgiver hos Objectware og utviklingen av en verktøypakke som vi kaller for ”Objectware Experience Framework”) jobbet mye med konseptmodeller for å supplere og erstatte informasjonsarkitekturen [IA] og innholdsoversikten (content inventory) på et prosjekt. Årsaken til dette er litt pga. en magefølelse om at IA har mange svakheter samtidig som IA bare berører en brøkdel av det som en trenger å spesifisere i et forprosjekt.

I tillegg vil en prosjektprosess inneholde en rekke office-dokumenter, e-poster og IM-samtaler som svirrer rundt og definerer ulike deler av prosessen på en tungvindt tekstformat-måte. Behovet for visualisering eksisterer altså ikke bare for informasjonsarkitekturen, men vel så mye for dusinvis av andre konsepter og avgjørelser som må taes i starten av et prosjekt.

En grafisk fremstilling i konseptmodellformat er mye raskere, mer effektivt og tilfører høyere kvalitet til avgjørelsene en tekst- og regnearkformatene vil kunne gjøre.

Hovedideen bak konseptmodeller er å bryte ned forprosjektet i mindre behov og innhold. Og produsere enkle oversiktlige modeller for å presentere konsepter enkeltvis for kunden, meningsytrerne og prosjektmedarbeidere.

Foreløpig har det gitt svært gode resultater. Oversiktlige leveranser, tydeligere konsepter og bedre kontroll på forventinger, innhold og kvalitet både for oss som leverandør og for kunden på andre siden av bordet.

Vedlagt pdf viser noen enkle konseptmodelleksempler for den som er interessert. (pga. prosjektet har jeg vært nødt til å anonymisere innholdet).
Last ned Konseptmodell_objectware_EKS.pdf

Side 1 er en oversikt over hoveddelene av informasjonsarkitekturen. Denne må ses i sammenheng med side 2 som er innholdsoversikten. Side 3 er en definering av hvordan de ulike elementene kobles sammen, og side 4 vises hvordan disse koblingene er for et spesifikt element.

Der er ingen generelle regler for hva som skal i en konseptmodell og ikke. Det tilpasses prosjektets, kundenes og medarbeidernes behov for forklaring, oversikt og forståelse.

Generelle regler for visualisering gjelder spesielt for konseptmodeller, mellom annet: Konsekvent bruk av farger for sette merkelapp på enkelte typer innhold samt understreke sammenhenger. Størrelse for å gi et inntrykk av hierarki. Oversiktlige flater som er bygd opp ut fra et mønster for at presentasjonen skal virke rolig og ikke i seg selv kreve oppmerksomhet. Bevisst forhold til primær og sekundær informasjon.

Ta vare på de beste videoforelesningene

Sett noen videoforelesninger på nett i det siste som du skulle ønske du kunne laste ned og ta vare på?

Gvi2 For oss som ikke er superbrukere på teknologifronten har det ikke vært lett. men nå kan du med Google Video Player laste ned og ta vare på de videoene som ligger på video.google.com (forutsatt at den som publiserte videoen har gitt tillatelse).

For underholdning har vel ikke dette noe å si, men for fagrelatert informasjon kan dette bli et verdifult tillegg til kildebiblioteket.

Selv har jeg allerede funnet fire forelesninger som jeg gleder meg til å bytte ut med Donald Pocketen på nattbordet.

Applaudert strategiverktøy og helhetlig arbeidsmodell for digitale løsninger

Models_namahnwarfel Er du en av de som setter pris på en god arbeidsmodell eller forsøker å holde deg oppdatert på nye/andre sine arbeidsmetodikker? Kilden til all informasjon rommer disse to svært nyttige posterne fra Namahn og Todd Warfel.

1. Call history er et eksempel på en ”compiled task analysis”. Dette er en kombinasjon mellom "Personas" , "Mental Models" og "Task Analysis". Disse tre metodene debateres varmt i artikler og på blogger på nett, hvor en i diskusjonene kan se en enighet om at det er en kombinasjon av de ulike modellene som er den beste løsningen – hver for seg er de for svake og håndterer et for snevert perspektiv i forhold til den informasjonen som behøves for å kunne konseptutvikle, designe og produsere en ”digital applikasjon”.

Todd Warfel har publisert sin ”løsning” på problemstillingen som de kaller for ”compiled task analysis”. En svært oversiktlig struktur over en liksom-person (personas) sine behov, oppgaver, mulige løsninger og sammenhengen alle elementene er satt i. Når en får alt dette inn i en oversikt begynner verktøyene å bli kraftige.

2. ”The user centered design of digital products” fra Namahn er en oversikt over de verktøy og faser som inngår i en utviklingsprosess for en digital applikasjon eller løsning. Modellen setter verktøy, øvelser, rapporter og faser i en sammenheng, linker de mot hverandre på kritiske punkt og kommer med små beskrivelser av hvert element. Alt plassert på en tidsakse, med svært gode konsepter knyttet til når hver delprosess burde slås sammen med andre og når de anbefales å kjøres for seg.

Dette er en av de mest komplette og oversiktlige modeller for produksjon av digitale produkter som jeg har sett, og denne kommer til å henge på veggen fremover som en plukk- og huskeliste for min egen del (og da hjelper det selvfølgelig at den ser svært fin ut :o)

Link til Call History - Compiled Task Analysis (pdf)
Link til The user centered design of digital products (pdf)

Opplevelser, opplevelser, opplevelser

Xmp_eyesondarfur_2 Eyes on Darfur er et initiativ fra Amnesty International USA hvor satelittbilder er et av flere verktøy som hjelper til med og engasjere besøkende i konflikten.
(kilde: AlJazeera)

Xmp_cnn beta.cnn.com har blitt snakket om en del allerede. CNN gjør i likhet med flere andre leverandører vågale skritt i retning av deltagersamfunnet, mer involverende verktøy og mer omfattende verktøy.

Flott liste over oppgaver og formål

Karlphillip Karl Phillip Lund har en fin liste på sin post over oppgaver/formål nettsiden din vil løse.

link

INMA - bransjenytt

Inma Ser endelig en veldig positiv utvikling hos INMA. Under kategorien bransjenytt publiseres det nå gode linker til relevante artikler og undersøkelser rundt om på nett.

++ fra denne bloggen.

http://www.inma.no/?sectionId=497

Blog powered by TypePad
Member since 11/2005

Enter your email address:

Delivered by FeedBurner

180360720.no

AltNyttErFarlig