Arkiv for ‘Design’ Kategori

How to trim your design and keep it healthy

I´m exited about consistent design because it makes the interaction more intuitive.

A healthy design consist of adaptable, reusable chunks and a clear vision.

We are not designing pages, we are designing systems of components. -Stephen Hay, from Brad Frost´s blog post on Atomic Design.

Content

The content you put in your styleguide should be adapted to your clients needs. Some relevant content may be:

Design chunks – divided into 3 main types of chunks:

  • Elements (basic styles like typography, colors, buttons and icons)
  • Components (elements komposed into a komponent like a header, footer or an image slider)
  • Layouts (components komposed into pages like an article, a gallerypage or  a frontpage)

Always design a thing by considering it in its next larger context – a chair in a room, a room in a house, a house in an environment, an environment in a city plan. -Eliel Saarinen

Design rationale

  • Design principles
  • Design vision
  • Tone of Voice

CSS rationale

Vector archive

However, developing the design-chunks is not the main challenge.

The main challenge is to keep the styleguide used and continously updated. If you spend months developing a styleguide and then just forget about it and never touch it again, then you have wasted your time.

It is not just about the styleguide, but also about the creators who needs to use the styleguide and keep it alive.

You need to look at usability issues and pain points just as you would in any other design project.

Some common pain points I have found are:

Problems finding time to update the styleguide, because each project has it own problems to solve.

I found that the process of using and updating the styleguide should be integrated into the natural workflow of the teams.

Another common problem is when the developers are not implementing the design – or code chunks the way it was intended, leading to problems later on, when we need to iterate on the design and make changes to the css.

This is a simple usability problem, where you should look at how the designchunk is documentet. Each piece of design should contain:

  • A title
  • A unique reference ID or url
  • A summary of how the element can be used and how
  • html  / css code and class reference
  • A visual illustration

Now you are probably thinking – this is going to take time, we have to do usability studies and all.  So – that leaves us to the second main challenge.

Motivate

How can you motivate your peers and clients to put in the extra resources to develop the styleguide?

The benefit of developing a usable and living designguide is often overlooked. As a result, many products fail to deliver consistent design efficiently and loose time to market.

Start with dividing your peers into groups and interview them to uncover their needs and find common goals.

Customers Editors Creators Business
Communication
Reference & shared vocabulary
x x x
Operational efficiency
Living & usable styleguide, designsystem, work-flow, testability, connections, availability
x
Usability and performance
Reusable, less code, improved performance, consistent design, intuitive
x x x
TTM
Faster TTM, automated & efficient, more output for less input
x x

This needs matrix uncovers how the creators of the design and code needs the styleguide for operational efficiency. The business side don´t need the styleguide in itself, but what they do need is Faster Time To Market. And the customers needs an intuitive interface.

The styleguide will fasilitate all theese needs.

Communicate & Connect

If I have learnt anything from working in large distributed teams, it´s that communication is key. -Paul Robert Lloyd

The styleguide is also an exellent tool for communication. It is a reference with a shared vocabulary improving communication.

To exploit this effect, it is important to create connections between people and make sure the relevant people are aware of the resources in the styleguide.

We must integrate new developed chunks by presenting results and training new users.

Keep it alive

A beautiful design system is about finding the same balance of consistency and variety. Too systematic and the design becomes predictable and repetitive. Too much variation and the system is confusing and owerwhelming. -Allison Wagner

I don´t belive in implementing too strict rules in the styleguide. The styleguide is a tool that should fasilitate our needs, it is not a straitjacket. If the styleguide start feeling like a straitjacket, people will find ways around it, resulting in it not beeing used.

When we start breaking the rules, we need to look at why we do it – if we already have a designchunk but we are not using it anymore, chances are that the old chunk is ready to be iterated upon.

So – to summarise – we need to develop the styleguide, then we must integrate what we have developed and then we iterate on the developed pieces.

Theese are the 3 main steps in the continous process.

Develop (Motivate)

  • Find business needs
  • Develop design principles
  • Develop design chunks
  • Implement into existing process and organisatinal structure

Relevant activities:

  • Interview stakeholders and develop needs matrix
  • Workshop – designstudio and designcritique
  • Designer days
  • Designer – developer pairing

Integrate (Communicate)

  • Inform and communicate new results
  • Train new users
  • Implement reusable chunks

Relevant activities:

  • Presentations
  • Meetings
  • Video conferences
  • Designer days

Iterate (Keep it alive)

  • Measure progression in design revisions
  • Evaluate
  • Changes in trends and business
  • Adjust when needed

Relevant activities:

  • Discussions
  • focus groups with developers
  • Design revisions

The 3 key steps toward a healthy design:

  • Create connections and motivate the creators
  • Design the process, not just the contents of the styleguide
  • Keep it alive, integrate and iterate

Har du disse symptomene?

Når du går til dokteren, så lister du opp dine symptomer, og hvis du er heldig, så vi dokteren gi deg et lite ark med foreskrevet medisin som skal ta knekken på problemene dine. Vi som jobber med design vil at du kommer til oss med dine symtomer heller enn hvilken medisin du tror du trenger. Men nå har vi jo denne kjekke lommelegen, hvor enkelte bruker mer tid enn på facebook (de som har barnehage-barn). Hvor er designsymptomenes versjon av lommelegen? Her er mitt bidrag til designkundenes lommelege. Har du disse symptomene?

Symptomer: mye dobbeltarbeid og inkonsekvent design

Bortgjemt CSS, duplikatkode, uklar visjon og inkonsekvent design

  • CSS kode gjemmer seg i ulike hjørner av systemene
  • Unødvendig duplikat kode gjør sidene tregere
  • Tidkrevende grafisk design prosesser for hver eneste grafiske detalj
  • Utydelige designprinsipper
  • Ingen tydelig designvisjon for den helhetlige UX på tvers av prosjekter og enheter
  • Inkonsekvent design på tvers av ulike skjermoppløsninger, enheter og papirutgaver

Medisin: en levende digital stilguide

En levende og digital stilguide kan bestå av gjenbrukbare kodebiter:

  • Side layouts
  • Box layouts
  • design stiler
  • Arkiv (logo, vektorgrafikk ol.)
  • UX prinsipper
  • Front-end kode standarder

Hver bit burde inneholde:

  • Tingens navn med en unik url
  • Rationale for hvorfor tingen er som den er, og hvordan den er ment å brukes
  • Et eksempel på selve tingen
  • Og kodesnutten som genererer tingen

Stilguiden er løpende arbeid, det er ikke bare å lage stilguiden, den må også implementeres og revideres løpende i takt med løpende prosjekter. En stilguide skal være et kommunikasjons-verktøy, ikke en tvangstrøye.

Designerne bruker stilguiden til å:

  • Dele designelementer
  • Referere til designbiter som allerede har rasjonale beskrevet, istedenfor å forklare hver detalj i hver eneste prototype
  • Finne filer og kodesnutter

Front-end utviklere bruker stilguiden:

  • Som et hjelpemiddel for å skrive gjenbrukbar kode og bygge gjennomgående grensesnitt
  • Hjelper med å forstå designvisjonen
  • Live eksempler speeder opp utviklingsprosessen og testing

Ledere og nettredaktører bruker stilguiden til:

  • Hjelper nyansatte og vikarer med å forstå systemene og formidlingsmulighetene
  • Forstå hvordan de kan tilpasse sidene til sine behov
  • Et kommunikasjons-hjelpemiddel

 

Et sunt digitalt design består av gjenbrukbare deler, organiserte biter, en tydelig visjon og et fleksibelt og gjennomgående design

  • Gjenbrukbare deler som er lett å finne og gjenbruke
  • Organiserte biter, arrangert så du kan scanne, velge og bruke hver del raskt
  • Mindre duplikatkode som gjør sidene raskere
  • LO-FI prototyper kan tas rett til produksjon raskt
  • Fleksibelt og gjennomgående design på tvers av ulike skjermoppløsninger, enheter og papirutgaver
  • Tydelig designvisjon på tvers av mennesker og prosjekter
  • Det kunne vert enklere å teste
  • Dere kunne hatt et felles vokabulær
  • En nyttig referansebase
  • Og ikke minst, en mer effektiv arbeidsflyt

 

Resirkulering av designbiter gjør tjenesten mer intuitiv for de som bruker tjenesten

Når de interaktive bitene har et gjennomgående designspråk og adferd på tvers av skjermer, er det lettere å bruke, fordi det er mer lærbart og forutsigbart for de som skal bruke tjenesten. Dersom en funksjon oppfører seg på en måte på mobil, er det veldig kjekt for brukeren å kjenne igjen denne triggeren på en annen skjerm, og allerede vite hva den gjør.

 

Riv ned veggen

Siden CSS og HTML er kode, blir front-end utviklere ofte puttet i den samme boksen som Java/PHP/Ruby/back-end utviklere, heller enn hos resten av designteamet. Dette er et problem. Html og CSS er design.

Ettersom vi må være tigjengelig på alle de enhetene våre kunder/lesere/seere/brukere lever livene sine på, blir det viktigere og viktigere å jobbe i dynamiske miljøer for å artikulere hvordan designet skal oppføre deg på tvers av alle de ulike enhetene våre brukere sitter med. Sist jeg sjekket statistikken var det over 700 ulike skjermoppløsninger som besøkte våre tjenester.

For å kunne jobbe effektivt med design for dagens og fremtidens nettsider, må vi erstatte utdaterte designmetoder med ekte samarbeid og kommunikasjon. Ettersom multi-device web blir normen, vil kaste-over-veggen metoden bli mer og mer utfordende. Den moderne designprosessen krever intenst samarbeid mellom designere og front-end utviklere.

 

Hvis du ignorerer symptomene…

Dersom dere ikke tar denne medisinen, risikerer dere å ikke ha en klar designvisjon, dere designer flere versjoner for hvert designelement, en økende mengde duplikat kode som gjør sidene tregere og tregere, og en inkonsekvent brukeropplevese som leder til frustrerte kunder og lesere.

 

Gjenbrukbart = konsekvent design = lett å bruke

Design stilguiden gir mulighet for å lage et mer gjennomgående, konsekvent, forutsigbart og lærbart grensesnitt og brukeropplevelse.

Standard biter og designstiler hjelper dere med å gjenbruke løste, effektive design løsninger igjen og igjen. Resultatet av dette blir at konsekvens og brukervennlighet øker.

Til slutt, er det de aller viktigste menneskene  – de som bruker tjenestene – som drar mest nytte av det når dere har en velfungerende stilguide.

Jeg samler på behov

Alle UX avdelinger ute i det ganske land, dere som har sluttet å kalle dere for designere og døpt dere om i håp om å bli tatt på alvor som noe mer enn en grafisk avdeling. Nå er det ut å si UX. Nå er det CX som er det nye fine begrepet som skal forklare hva vi driver med.

Wikipedia om Customer Design

Tjenestedesign, brukeropplevelse på tvers av touch points, customer experience maps og user experience maps, mye begreper overlapper hverandre og kan bety ulike ting eller det samme alt ettersom hvem som snakker eller hvilken kontekst du jobber ut ifra.

Start med behov, hva er kundens behov. Derav kundeopplevelse og ikke bare brukeropplevelse. En kunde er en opphøyet variant av en bruker, en som kan stille krav. En bruker er bare en som kanskje ‘må’ bruke tjenesten din.

Men tilbake til design. Selve kjernen i en designprosess er å starte med å finne ut hva som er behovene. Design research heter det. Det samme har vert tema i ux research og cx research. Og for ikke å snakke om behovsdrevet utvikling, i de smidige miljøene. Alle tror de har gjort en eureka oppdagelse og innsett at det å oppdage behov er nøkkelen til suksess.

Jeg har samlet på behov så lenge jeg har jobbet med design. Ikke bare brukerbehov (eller var det kundebehov..?) men også behovene til de jeg jobber sammen med og interessentene.

Dette er design, det er essensen i det en designer er laget av. Store ører. Bortsett fra de designerne som vipper over på kunstnersiden da. Så – dere trenger ikke å omdøpe avdelingen igjen. Dere er designere og det dere driver med er design research.

Design research vil få brukerne til å digge nettsiden din

Faren med å ikke gjøre design research er at du kan gå glipp av muligheten din fordi du ikke har spurt målgruppen hvorfor de sa de ville kjøpe ditt produkt eller bruke din nettside.

Et scenario: Tenk deg at du har gjort markeds research og funnet at der er en forretningsmulighet for å selge prospekter i Kina.

Men prospektene må bli sett og de må levere kjøpere til selgerne som trenger å selge sine hjem. Dette er et viktig suksesskriterie.

Så vi trenger å finne ut hva disse kjøperne ønsker å gjøre med nettsiden. Hva er målgruppens viktigste behov når de ser etter sitt nye hjem? Og hvilke brukerproblemer sliter de med?

Dersom vi ikke addresserer disse punktene, risikerer vi å ikke få solgt noen boliger, og vi forspiller muligheten for å ta en posisjon i markedet.

Med en behovsanalyse kan vi finne de mest viktige brukerbehovene. Hvilke stresspunkter sliter målgruppen med når de prøver å finne drømmeboligen? Og hvordan kan vi imøtekomme disse med vårt nettsted?

Hvordan kan vi få boligsøkerne til å digge nettsted?

Design research forer designernes magefølelse med riktig type inspirasjon om hvordan tjenesten burde designes ved å identifisere brukerbehov.

Research is formalized curiosity. It is poking and prying with a purpose.

En effektiv metode kan være å kjøre kombinert observasjon og intervjuer med 30 deltakere.

Vi må finne motivasjon for bruk, men også sørge for at produktet ikke er for vanskelig å bruke.

Med brukertesting, kan vi detektere brukerproblemer tidlig og iterere på produktet.

UX research gir innsikt i hele ecosystemet til brukeren, hvordan målgruppen bruker nettsiden, alle touch points, følelser og holdninger til produktet.

En metode kan være å teste en tidlig prototype på 5 deltakere med 45 minutters sesjoner. Denne prosessen repeteres så gjennom den iterative prosessen.

For å konkludere, intervjuene og brukertesten vil sørge for at boligsøkerne digger nettsiden din. Suksesskriteriene blir addressert – boligene blir solgt og meglerne fortsetter å betale for produktet.

Strategisk prototyping

Formål

Our mission…

 

En prototype kan ha mange formål utover ren brukertesting:

  • Linking mellom parallelle prosesser
  • Intern innsalg av ideer, raskere avgjørelser
  • Samarbeids- og diskusjonsmedium
  • Reduserer misforståelser (sparer tid og penger)
  • Teste gjennomførbarhet i utviklingsteamet
  • Utforske og experimentere
  • Evolusjonere og iterere
  • Teste ut konsepter
  • Generere og raffinere ideer raskere

Evolusjon og iterasjon

To explore strange new worlds…

 

  • Prototype små biter om gangen. Hyppigere prototyping = raskere idegenerering!
  • Diskutere i teamet, gjør avsjekk med interessenter og teste på brukere. Involvere teamet i evolusjonsprosessen
  • Endre raskt og generer nye ideer
  • Kontinuerlig forbedring. Fokusere prototypen mer og mer utover prosjektets livløp
  • Myte: Gode innovative ideer popper opp ferdig utformet i geniale hjerner.

    Gode ideer er et resultat av hardt arbeid med brukersentrerte utforskningsprosesser fulgt opp av sykliske gjentagelser med prototyping, testing og justering.

Samarbeids- og kommunikasjonsmedium

To seek out life and new sivilisations…

 

  • Teamet får et felles bilde av hva vi skal lage
  • Prototypen kan fungere som et medium for samarbeid
  • Få tilbakemeldinger fra sparringspartnere, vise frem prototypen i designkritikkmøter med UX teamet
  • Avsjekk med interessenter. Jo flere ledere som går god for løsningen, jo større er muligheten for suksess
  • Samarbeide med brukere, interessenter og utviklere med hyppige prototyper for å skape eierskap og få feedback

Redusere misforståelser

  • Avansert funksjonalitet blir forklart enkelt og raskt. Du trenger ikke å skrive en masse forklaringer og spesifikasjoner på hva som skal skje når en klikker, slider eller peker
  • En prototype er svært visuell og selvforklarende, det er ikke så mye som er opp til fortolkning
  • Få avdekket uklarheter før utvikleren begynner å programmere
  • Finn feil raskere

Linking mellom parallelle prosesser 

  • Bruk prototypen til å aligne designprosessen med utviklingsprosessen og forretningsprosessene
  • En prototype kan fungere som et naturlig kommunikasjonsmedium når du gjør avsjekk med interessenter og tekniske utviklere
  • Prototypen kan hjelpe teamet med å ha fokus på riktig sted i prosessen

Utforske og experimentere

To boldly go where no man has gone before…

 

  • En prototype lar deg kjenne på hvordan det føles å klikke og bevege deg rundt i grensesnittet
  • Test ut ideer i en prototype: Hva skjer hvis vi gjør slik?
  • Å prøve å løse problemet i en prototype kan i seg selv gjøre at du forstår problemet bedre
  • Det hjelper designeren med å huske alle detaljene i grensesnittet som må designes. Eksempelvis mikrotekst for errormeldinger, innlogget/utlogget modus, bruker som har data eller ikke har data..
  • Lag scenarier som viser ulike brukermodus og hvordan designet imøtekommer individuelle brukerbehov
  • Visualisere mulige løsninger raskt

Prototypingverktøy

Choose a weapon…

 

Hvilket våpen du velger går litt på personlig stil, men ikke bli altfor komfortabel med det samme våpenet som du alltid bruker. Hvilket våpen du bør bruke kommer an på hva som er målet ditt og formålet med prototypen.

Dersom du jobber som konsulent, så er det kanskje viktigere at prototypen ser fancy ut, enn om du jobber som innomhus-designer. Da vil kunden se at en får den kvaliteten en betaler for. Da velger du kanskje en ’007 pistol’. Dersom du skal generere ideer internt, så vil du heller bruke en fargesprakende vannpistol. Dersom du skal bare klubbe raskt ned en enkel liten stubb, så trenger du en øks. Dersom du skal treffe en helt presis liten detalj og vise det til noen som er langt borte, så vil du nok heller bruke en sniper. De ulike prototypingsverktøyene som finnes der ute har ulike styrker og svakheter.  

Dette må du tenke på når du skal velge et prototypingsverktøy

  • Hvor er du i prosessen
  • Hvilke problemer skal du løse
  • Hva er formålet med prototypen
  • Trenger du HI-FI eller LO-FI
  • Hvem er publikum
  • Kultur
  • Levetid

Hvor er du i prosessen

I ulike faser av prosessen kan det være relevant å bruke ulike verktøy eller metoder. Dersom du skal generere ideer så er det kanskje best med papir og blyant for å sikre en fri kreativ flyt. Skal du lage et responsivt design, så vil du kanskje heller bruke html/CSS eller et verktøy som Edge reflow eller Proty.

HI-FI eller LO-FI

En prototype skal være tidsbesparende og kostnadsbesparende, derfor vil du velge den laveste detaljeringsgraden som får jobben gjort. Hvor høy detaljeringsgrad du trenger kommer an på prosjektet, hvor du er i prosessen, og flere andre faktorer:

  • Publikum: Eksempelvis at prosjekteieren må kunne se om løsningen møter målene, eller at utviklerne må kunne se hva som er påkrevet av funksjonalitet
  • Kultur: Noen interessenter vil respondere bedre på en HI-FI prototye
  • Levetid: Skal prototypen kunne oppdateres? Da er det lurt om du har en løsning som er lett å justere på uten å gjøre alt på nytt hver gang
  • Formål: Hvor stor del av siten skal prototypes?
Høy eller lav detaljeringsgrad kan deles opp i 3 punkter, høy eller lav:
  • Visuell detaljeringsgrad: Skissert eller stylet. Er prototypen stylet for tidlig, får diskusjonen feil fokus
  • Funksjonell: Statisk eller interaktiv. Det er mer tidkrevende å lage en funksjonell prototype, men det fungerer bedre ved brukertesting
  • Innhold:  Lorem ipsum eller autentisk tekst. Dummy tekst kan være forstyrrende i brukertester, men det fungerer helt fint på ide og konseptstadiet

LO-FI

  • Fort, farlig og billig papirprototyping
  • Eks. papirprototyping eller Mockingbird
  • En LO-FI prototype virker mer open for endringer: Noen ganger er det relevant å gjøre det ekstra tydelig at prototypen er ‘work in progress’ slik at de som skal se på den skjønner at dette ikke er det endelige produktet, men en prototype som vi gjerne vil ha tilbakemeldinger på. Det kan være eksempelvis når målgruppen for prototypen er uvant med å samarbeide med designere
  • Passer bra til idemyldring og konseptualisering
  • Tvinger fokuset over til bruken istedenfor utseendet

MEDIUM-FI

  • Med en medium-FI kan du gjøre endringer uten å tegne opp alt på nytt
  • Eks. Balsamiq, html wireframes, scenarier..
  • Interaktivitet ved lenking mellom skjermbilder
  • Se om brukeropplevelsen er optimal
  • Noen ganger lager vi en MEDIUM-FI, men får den med vilje til å se ut som en LO-FI for å tvinge andre til å se på den som ‘work in progress’ heller enn et polert produkt

HI-FI

  • EN HI-FI prototype er mer presis og realistisk, den har gjerne noe visuell design og nyansert interaksjon
  • Eks. html/CSS eller Axure
  • EN HI-FI prototype tar lenger tid å lage og opprettholde
  • Den kan fungere som et referansepunkt for utviklere når de setter i gang utviklingen
  • En HI-FI prototype fungerer bra til brukertesting. Når vi tester på reelle brukere, er det en fordel om prototypen er så tett opp mot virkeligheten som mulig, at mikrotekster er autentiske, at det visuelle er geografisk riktig, og at funksjonaliteten fungerer slik som den skal. Det som er mindre viktig å ha på plass ved en brukertest er den visuelle detaljeringsgraden

Strategisk prototyping from Janne Flusund

Kunsten å gi og å ta imot designkritikk

Der er alltid to roller som spilles når det gis designkritikk. Det er en som tar imot og en som gir kritikk.

Spilleregler for den som tar imot designkritikk: 

Det er ofte en god ide å starte med å fortelle litt om hva du har tenkt. Hva som er målet med designet, hvilket brukerbehov og forretningsmessige behov du forsøker å imøtekomme og designvisjonen. Men ikke fortell for mye, slik at du styrer for mye hva designkritikerne skal mene om designet. Noen ganger kan det være greit å starte med å la de kikke først, slik at de får oppleve grensesnittet med friske øyne og oppleve selv hvor lang tid det tar å forstå grensesnittet uten forhåndskunnskap og forklaring. Men det er en god ide at deltagerne har en viss ide om hva som er målet, slik at dere ikke snakker om helt forskjellige retninger.

  • Vær ydmyk.
  • Bruk aktiv lytting. Å lytte aktivt er å stille spørsmål for å forstå bedre det designkritikeren forsøker å si. Du skal lytte, og prøve så godt du kan å forstå hva som blir sagt og la kritikeren få fulløre setningene sine. Du kan også gjengi med egne ord hva kritikeren sier, for å sjekke om du har denotert budskapet riktig.
  • Ikke gå i forsvar. Du trenger ikke å forsvare designet ditt når du får designkritikk. Dersom du går i forsvar vil du aldri få den samme kritikeren til å gi deg konstruktiv kritikk igjen. Tenk at kritikk er ikke et angrep på din person eller dine evner, det er en mulighet for forbedring. Dette må du trene på.
  • Ikke svar. Målet er å sanke inn kritikk. Du trenger ikke å svare ja eller nei på nye forslag. Du skal bare lytte. Dette er ikke et beslutningsmøte. Ingenting skal besluttes.
  • Du vil oppleve at noen tilbakemeldinger stikker litt. Ikke gå i forsvar. Noter tilbakemeldingen, og spør hvis det er noe du ikke forstår, men ikke gå i argumentasjon. Tenk før du snakker.
  • Ta notater. Slik viser du at du lytter, og du kan bearbeide, forkaste eller ta med deg videre innspillene for deg selv etterpå. Du er fortsatt den som tar designbeslutningene.
  • Si takk når noen gir deg konstruktiv kritikk slik at det frister til gjentagelse.

Spilleregler for den som gir designkritikk:

  • Unngå å bruke begreper som ‘stygt’ eller ‘pent’ eller ‘liker’ og ‘liker ikke’. Det er koselig når kollegaen sier at han bare digger alt du gjør, men det hjelper deg ikke med å ta bedre designbeslutninger.
  • Ikke anta. Bruk spørsmålsform for å få vite mer om hva som er målet, visjonen og brukerbehovene.
  • Ikke inviter deg selv, bli invitert eller spør om designeren ønsker å motta designkritikk før du fyrer løs.
  • Dersom du bare sitter og klapper kollegaen på ryggen og sier hvor bra alt er, så gir du bare en bjørnetjeneste. Selv de beste designerne trenger designkritikk. Kritikk er en mulighet for forbedring, og for å pushe designet til nye høyder. Det kan iblant være smertefullt, men det er verdt det! Vil du jobbe i et superteam der bare det beste er bra nok, så må du ikke dyrke middelmålighet ved å si at det er bra nok. Du må pushe kollegene dine til toppen ved å gi de konstruktiv kritikk som gjør de i stand til å ta bedre designbeslutninger, og forstå designproblemet bedre.
  • Kritikk handler ikke bare om å finne svakheter ved designet. Det er også viktig å peke på styrkene i designet slik at de ikke velges bort igjen i senere iterasjoner. Relater da den positive kritikken til hvordan de møter målene, brukerbehovene og visjonen.

Dette er ikke enkelt! Det krever konsentrasjon og fokus, og masse trening.

Og husk: Unngå beslutninger og problemløsning i designkritikkmøtet. Det er designerens jobb å følge opp og ta designbeslutninger etter møtet.

Responsivt design for betalingsløsning

Sjekk ut vårt nylanserte responsive design: tb.no

tb+ er en ny betalingstjeneste laget for Edda media sine nettaviser med betaling via mobiltelefon.

Artiklene som ligger på forsiden er også tilgjengelige på touch utgaven. Det er selve produktsidene og skjemasidene som benytter seg av responsivt design. Med andre ord bruker vi både versjoner og responsive design. Produkt- og skjemasidene er 100% responsive for mobil, brett og desktop.

Vi har lagt vekt på at det skal være så enkelt som mulig for leserne å gjennomføre en prøveperiode eller kjøp.

  • Det skal være raskt og effektivt å gjennomføre et kjøp (kun mobilnummer og kode)
  • Leseren skal føle seg sikker ved bruk av tjenesten (hva skjer nå, hvordan skjer betalingen, ha kontroll på abonnementet..)
  • Leseren skal ha nok informasjon om produktet til å kunne ta et valg (motivert/konvertert for kjøp)

 

 

Mobil brukertest: Videokamerastativ i ‘mcGyver-stil’

Den største utfordringen i designprosessen var å få incentivsiden på artikkel til å fungere optimalt, og svare på de spørsmålene som leserne har i hodet på riktig tidspunkt i kjøpsprosessen. Vi redesignet incentivsiden to ganger etter at vi haddde hatt brukbarhetstester. Vi kjørte 3 runder med tester, først en tidlig-test på en klikkbar prototype laget i Axure. Senere i prosessen, etter å ha gjort noen endringer, testet vi på en mer reell prototype på testserver hos avishusene på reelle lesere av avisen. Vi testet også på mobil med eksternt web-kamera og quicktime player.

Hender eller hjerne?

Jared Spool skrev en artikkel om ‘The hands vs. the brains’

Her beskriver han forskjellen mellom en UX person som er ‘hjerne’ og en som er ‘hender’. Han påstår at svært få kan være begge deler samtidig, siden egenskapene som kreves er to ulike personlighetstyper. Kort oppsummert, på norsk:

Hender

  • Utføre.
  • Tar lang tid.
  • Designe skjermbilder.
  • Produsere wireframes.
  • Teamet vet allerede hva de skal lage, Hendene bare utfører.
  • Produksjon.
  • Utføre tester.
  • Strategi er lagt på forhånd.
  • Sliter med å jobbe med strategi. Føler de ikke er den riktige personen å spørre. Synes noen andre skulle ha svart på de spørsmålene allerede.
  • Liker å ha et sett med begrensninger, en ferdiglagt plan. Liker å begynne på et prosjekt som er godt definert på forhånd.
  • Hurtighet og nøyaktighet er viktige egenskaper.

Hjerne 

  • Legge en strategi.
  • Tar kortere tid.
  • Erfaring.
  • Teamet vet ikke hva de skal lage, dette hjelper hjernen til med å finne ut av.
  • Gir råd om hva som vil lede til suksess.
  • Teamet står fast og trenger hjelp til å ta designet videre til neste steg.
  • Går til neste prosjekt så snart prosjektgruppen vet hva de skal gjøre.
  • Analysere.
  • Klar for å hoppe til neste prosjekt så snart strategien er lagt.
  • Liker ikke å jobbe med tidkrevende produksjon og detaljer.
  • Liker kaos, Liker å dykke ned i analytisk arbeid, prioritere og pønske ut en strategi.
  • Helhetsforståelse, å forstå prosjektets visjon, mål, muligheter og begrensninger er viktige egenskaper.

Jeg selv kan trives i begge rollene, men hører nok mest hjemme i ‘Hjerne’ kategorien. Jeg liker kaos! Jeg liker å grave meg ned i en problemstilling, analysere, systematisere, generere idéer, prioritere og komme ut i andre enden med en elegant løsning. Men jeg kan nok fort begynne å kjede meg hvis jeg må produsere 30 nesten like skjermbilder med svært små forskjeller.

Hvem er du?

Responsive design – begreper

Skal du gå fra å designe desktop til å designe for mobil web med responsive design, så er det noen nye begreper som du trenger å bli kjent med. Å respondere til ulike enheter kan bety mangt. Eksempelvis:

  • Tilpasse layout til ulike skjermstørrelser
  • Nedskalere bilder
  • Hente mindre bilder for mindre skjermer (laste ned mindre filer)
  • Forenkle elementer for mobil
  • Gjemme elementer som ikke er blant de viktigste c2a
  • Større, touch-vennlige linker og knapper for mobilbrukere
  • Detektere og respondere til mobile funksjoner som gps og enhetens liggende eller stående format

Hvordan vet vi hvilke egenskaper enheten som besøker siden vår har? Jo, med:

Media queries

Dette bør ikke være helt ukjent for deg, du har sikkert designet utskriftsvennligevennlige sider før?

Med media queries kan vi levere ulik layout, ulike bildestørrelser, vise/skjule innhold ol. Vi kan tilpasse designet til ulike enheter, orienteringer, skjermstørrelser osv.

Dagens desktop enheter har ulik skjermstørrelse og omtrentlig samme dpi verdier, derfor designes desktop versjoner typisk i pixel størrelser. Dagens mobile enheter derimot kommer i mange ulike dpi verdier.

Density

En pixel er ikke en pixel. Når vi designer for mobil kan vi ikke bare forholde oss til hver enhets skjermoppløsning. Vi må også se på pixeltettheten, hva enheten rapporterer og hva dette betyr i praksis.

Dette betyr i praksis at et bilde med samme pixelstørrelse kan se veldig liten ut på en 326 dpi skjerm, og veldig stor ut på en 170 dpi skjerm med lavere pixeltetthet dersom en ikke tar hensyn til dpi. Du kan også risikere at fonter blir for små, eller trykkflater for små og vanskelige å treffe med fingeren.
Safari på IOS lyger!
En pixel er IKKE en pixel

Viewport

Refererer til størrelsen på browservinduet minus rammer. På mobil kan denne være større enn mobilskjermen. Default bredde på ios er 980 pixler.
Dersom du designer for bare iphone, sett viewport til skjermstørrelsen.
Dersom siden du designer er mindre enn 980 pixler, sett viewport til bredden på designet ditt.
Eller du kan bestemme at viewport skal være det samme som den fysiske størrelsen:
<meta name=»viewport» content=»width=device-width, initial-scale=1.0″>

Virtual viewport

Vi var inne på at viewport på en nettleser på mobil kan være større enn den fysiske skjermen. Dette er det som kalles for “virtual viewport”.

Orientation

På mobil kan man se websiden både i stående og i liggende format. Der er ulike skjermbredder på samme enhet. Dersom vi ikke gjør noe med dette, kan brukeren få to ulike layouts og to ulike bannerpakker på samme side samtidig bare ved å tilte på enheten.

  1. media all and (orientation: portrait) {  
  2.  body div { width: 10%; }  
  3. }  
  4. @media all and (orientation: landscape) {  
  5.  body div { width: 15%; }  
  6. }

Resolution

Levetiden til mobile enheter er typisk mye kortere enn desktop. Kortere levetid og stadige nylaseringer gjør at bildet på populære oppløsninger er i stadig endring. En pixel er ikke en pixel. Selv om en nyere iphone med retina skjerm har en pixeloppløsning på 640 bredde så vil denne bruke samme layout som en 320 pixel skjerm.

@media only screen and (min-width: 321px) and (max-width: 479px) {}

Pølsefinger

For all del, glem ikke touch! Design for tjukk og feit pølsefinger, her er ingen mus med presis navigering.

Design for touch. Det vil si at ingen linker eller knapper eller andre interaktive elementer skal ha mindre enn minimum 44 px trykkflate. Noe mindre blir veldig vanskelig å treffe med fingeren. Det betyr at linklister eller linker som ligger ved siden av hverandre må være store nok, ha stor nok trykkflate og ha tilstrekkelig luft rundt seg til at det ikke blir lett å bomme.  Og nå: les avsnittet om dencity en gang til.

Du kan også legge på skjulte touch interface elementer, eksempelvis To-finger tap.

Fordeler og ulemper med responsiv design

Publisert: 1 Comment

Fordeler og ulemper med å designe etter responsive design prinsippet.

Responsive design er ikke det samme som en «mobil-versjon» av nettsiden din. Responsive design er en fullverdig visning av nettsiden som er tilpasset det miljøet du ser den i.

Istedenfor å lage en layout som skal passe for alle skjermer, lages layouter som tilpasser seg det utstyret hver enkelt bruker sitter med.

Mobildesign handler ikke nødvendigvis om å lage en helt ny brukeropplevelse, men om å levere den samme opplevelsen fintunet for håndholdte enheter. Spørreundersøkelser viser at brukerne slett ikke alltid er på farten når de surfer med håndholdte enheter, majoriteten sitter faktisk mest hjemme og surfer med brett eller mobil, i sofa, på senga, på do.. kjenner du deg igjen? Du begynner kanskje å lese en fagartikkel på desktop, fortsetter å lese neste artikkel på mobilen på toget, og leser ferdig på brettet hjemme i sofan?

Fordeler med responsive design

  • inkluderende
  • en versjon for alle enheter – lettere å vedlikeholde en versjon enn mange versjoner
  • samme brukeropplevelse uanhengig av device
  • selv om browservinduet er nedskalert vil designet fungere
  • mobil først – når en designer for mobil først blir en mer bevist på å fjerne innhold som virkelig ikke trenger å være der. Da blir heller ikke desktop versjonen overfyllt med unødvendig innhold
  • brukerne blir ikke utestengt fra fullversjonens innhold. Mobilversjonen er typisk veldig strippet for innhold.
  • vi velger ikke bort innhold for leseren
  • deling av linker: url er det samme uansett. Du vet ikke hvilken device den du deler linken med er på, deler du m.dt/artikkel med en venn som er på en desktop utgave, vil det se ganske merkelig ut.
  • samme innhold tilpasset devicen. Det lar brukeren fullføre oppgaven. Vi velger ikke bort 90% av brukeroppgavene. Kommer du til dt.no for å gjøre en spesiell oppgave kan det være veldig irriterende om akkurat den oppgaven er valgt bort for deg på mobil.
  • fungerer spesielt bra i nyere browsere
  • samme opplevelsen på tvers av devicer. Mer gjennomgående brukeropplevelse.
  • bærekraftig design – imøtekommer dagens brukerbehov uten å redusere mulighetene for å dekke fremtidens brukerbehov.

Ulemper med å bruke responsive design

  • krever at utviklerne har kunnskap og erfaring med responsive design
  • det er ikke lett! Er teamene klare? Hvor lenge er det til de er klare? Hvor mye prøving og feiling må til.
  • vedlikehold mer komplisert
  • utviklingstid og ressurser – har vi tid til å gjøre det grundig? Responsivt design er komplisert å utvikle.
  • browser kompabilitet – html5 og css3 er gode verktøy for å bygge responsive nettsteder, men det er fortsatt mange issues med disse.
  • vi må ha annonser som kan skalere
  • ytelse/lastetid – Flere kall på grunn av kross browser og kross plattform kompabilitet issues. (IE..) Mer css å laste ol.
  • ulike devicer kan ha behov for å støtte noe ulike brukeroppgaver. Innhold/touch grensesnitt/ mobil har ulike muligheter som gps/ringe/mobilverifisering mobil/desktop ol. Behov for nedkortet innhold på mobil, ikke vise like mye på en gang.
  • må laste ned like mye på mobil som på pc. Kan være en utfordring på avisenes meget innholdstunge forsider. (Kan være ulike tekniske løsninger på dette)