Klar, ferdig, design! 39

En designers hverdag:

Mål og brukerkrav for det nye nettstedet er klart definert. Innholdet er nesten på plass. Pulten din er full av papirskisser. Interaksjonsdesigneren har sittet på fanget ditt i noen dager allerede. Og nå er det endelig din tur: Du skal blåse liv i det nye nettstedet.

Men hvor i all verden begynner du?

  • Er ryggmargsrefleksen å åpne Photoshop og begynne på en detaljert design, kanskje av headeren eller en sentral modul?
  • Eller skal du åpne Coda og sette opp grid, plassere sentrale bilder og begynne å leke med typografi, alt i HTML og CSS?
  • Hva med å designe ALT ned til minste detalj i Photoshop, for så å implementere designen i en prototype?
  • Eller skal kanskje hele leveransen være Photoshop-filer?

Som du kanskje har skjønt, jobber jeg mye i prototyper og må derfor ofte legge hånden sist på sluttleveranser. Jeg stortrives i et vakkert sammensurium av design og kode – jeg liker kontrollen det gir meg. Det er innlysende at ikke alle er like komfortable med å jobbe med kode, men under følger et lite eksperiment som kan være interessant både for deg som utelukkende designer i Photoshop og for deg som gjør noe front-end.

Eksperiment: Supereffektiv designprosess

Dette eksperimentet skal avdekke hva som egentlig går raskest: Er det en designprosess utelukkende gjort i Photoshop, eller design direkte i browseren, i en HTML-prototype? Hva gir det raskeste sluttresultatet?

Forutsetninger for eksperimentet er vi som designere BÅDE er stødige i HTML/CSS og kjenner designverktøy som Photoshop og Illustrator godt.

Vi tar på oss hanskene og går inn i test-laben. Før vi setter i gang, må vi finne fram følgende designelementer:

Vi starter stoppeklokka og setter i gang med eksperiment nr 1:

Oppsett av en responsiv design

Check out this Pen!

Knepen seier til Photoshop. Banebrytende forskning viser at det går raskere å sette opp en komplett design i Photoshop enn å designe et nettsted rett i browseren. Ting som tar mye tid å sette opp i en HTML-prototype, som f. eks. grid, kan settes opp forholdsvis kjapt i Photoshop. Å sette opp overordnet typografi går omtrent like raskt i en HTML-prototype som i Photoshop. Men i Photoshop kan man enkelt eksperimentere med former og farger, og det er mye enklere å posisjonere og prøve ut ulike bilder og ikoner. Nok skryt til Photoshop – la oss presentere det vi har gjort for kunden.

Kunden står på tå hev og venter inne på møterommet, og kan nesten ikke vente med å se den nye designen. Blir det slakt, eller hopper kunden i taket av fornøyelse?

Vi presenterer den nye designen for kunden.
Vi presenterer den nye designen for kunden.

Kunden liker det han ser, men kunne tenke seg å gjøre noen endringer. I samråd med kunden blir vi derfor enige om å gjøre noen forandringer i designen. Forandringene innebærer at vi må gjøre små justeringer på ALLE designelementene, deriblant grid, typografi, former og farger, bilder og ikoner.

Vil Photoshop stikke av med seieren i denne runden også? Hva går raskest – endringer i Photoshop eller endringer gjort direkte i HTML-prototypen? Vi forlater møterommet og går inn i test-laben for å sette i gang med eksperiment nr 2:

Endringer i en responsiv design

Check out this Pen!

Ai, ai, ai… Overlegen seier til HTML-prototypen. Å endre store deler av en design i Photoshop er en tidkrevende og frustrerende prosess. Tilsvarende endringer i en prototype er gjort på null komma niks. Nesten, i hvert fall.

Raskere og bedre designprosess

Sitter man i Photoshop og forsøker å designe for ulike skjermstørrelser, gjerne 3-4 ulike formater, må man opprette nye elementer for hvert enkelt format og forsøke å tilpasse disse på best mulig måte. Før man vet ordet av det har man et utall dokumenter, enda flere layers og en fantasillion piksler å forholde seg til. Og da er det “just great” når kunden sier: “Kan du ikke bare endre litt på de fargene her, justere disse fontstørrelsene og gjøre denne kolonnen litt bredere?” Joda, tilbake om 2 timer.

Til sammenligning er det en drøm å gjøre tilsvarende endringer og justeringer i en HTML-prototype. Justeringene kan noen ganger gjøres så raskt at jeg i enkelte kundemøter har gjort justeringer LIVE – til kundens store overraskelse og fornøyelse.

I en responsiv HTML-prototype opererer man med de samme elementene, uavhengig av flate, og eksperimenterer enkelt med ulike skjermbredder og stilregler. Å jobbe responsivt i Photoshop er rett og slett tungvint, og designen er vanskelig å prøve ut på de ulike enhetene. Og jeg vil ikke engang snakke om hvor ufordragelig Photoshop kan være når det kommer til arbeid med tekstlig innhold…

Når det er tid for leveranse av dine Photoshop-skisser må du skrive side opp og side ned med dokumentasjon, og for sikkerhets skyld henge over skulderen til stakkaren som skal utvikle nettstedet – ting som tar mye tid. Og alt dette gjør du bare for å oppdage, sammen med kunden, at designen ikke ble akkurat som i Photoshop-skissene dine, men har “ubetydelige” avvik her og der. Leverer man en HTML-prototype er den i de fleste tilfeller så selvforklarende at man knapt behøver å skrive dokumentasjon, og koden kan implementeres direkte. WYSIWYG!

Konklusjon

Min påstand og konklusjon er derfor: Når man skal designe et responsivt nettsted går det raskere, sammenlagt sett, å gjøre mye av designen “rett i browseren” og levere designen som en HTML-prototype. Og ærlig talt: Hva liker kundene best? Flate Photoshop-skisser i alskens formater liggende utover bordet, eller en vaskekte prototype som de kan se, ta og føle på, kanskje på sin egen tablet eller mobil?

Hva mener du?

Axel Ferdinand Giæver

Flere artikler av Axel Ferdinand CV

39 kommentarer

  1. Ofte blir dessverre design preget av verktøyet, dette gjelder veldig ofte design som lages “rett i browseren”. Det er ofte ingen enten/eller her. Etter å ha skisset mye for hånd, liker jeg å lage grunnrammene i Photoshop, før jeg bygger det i HTML/CSS.

    Så, om det er detaljer jeg vil fikse på senere, tar jeg ofte et skjermskudd av detaljen, printer ut og noterer meg det jeg syns er galt og hva som burde fikses på. Så drar jeg skjermskuddet inn i Photoshop, fikser det grafisk – eller om det er noe veldig enkelt så gjør jeg endringen rett i SASS/CSS.

  2. Spot on! Photoshop blir mer og mer et verktøy for viderekomne moodboards og statiske stilark. Det du beskriver er slik vi løser flere og flere prosjekter, til stor glede for kunde og samarbeidspartnere.

  3. Gøy eksperiment og fin fremstilling! Helt enig med konklusjonen. De aller første skissene/wireframene mener jeg likevel bør lages i kjappe wireframes-verktøy som Axure, e.l. Men når det kommer til design er det erfaringsmessig definitivt en fordel å jobbe direkte i browseren. Dessverre er det få grafiske designere som er komfortable med frontend-kode.

  4. Mye fine tanker her – det som bekymrer meg med tanke på denne diskusjonen er at man ofte blir satt veldig i en boks(bokstavelig talt) når man designer i browseren. Og ikke minst så ender hjemmesider opp med å se veldig like ut.

    Kommer man til det nivået at designere blir like gode som fullblods front-end utviklere tror jeg derimot at vi har mye fint å se frem til. Men frem til da, så vil jeg påstå at det ikke er “bare og bare” å designe i browseren for designere.

  5. Veldig godt innhold, og kjenner meg godt igjen i prosessen. Erfaringsmessig klarer jeg meg ikke uten Photoshop tidlig i prosessen, men mest for å være kreativ og “leke” meg fram til stil. For min del skulle jeg gjerne sett en verdig konkurrent til Photoshop, med mer fokus på design, og mindre “bloatware” bilderedigering (så kan fotografene holde på med Photoshop).

    Mitt største problem hittil, i hvert fall tidligere, har likevel vært at en del backend utviklere (og kunder) insisterer på å få jobben oversendt i psd format, og ikke som prototype.

    Ellers veldig enig med Tor også, grunnrammene er ofte best å ta for hånd og i Photoshop!

  6. @Tor Bollingmo: Enig i at det kan være en god idé å lage grunnrammene i Photoshop/Illustrator, skjønt jeg foretrekker å lage gode og detaljerte papirskisser med kommentarer før jeg setter i gang med prototypen. Design på detaljnivå lager jeg som regel alltid i Illustrator, men så snart dette designet er overført til prototypen gjør jeg alle videre endringer direkte i prototypen.

  7. Blir ikke dette som å spørre om du skal tegne med blyant eller tusj?
    Hvem har sagt at man MÅ bruke en av delene? Gode designere finner en god kombinasjon av både photoshop/illustrator/fireworks og html/css.

    Kun å bruke photoshop eller kun å bruke html/css gir vel sjeldent den beste løsningen uansett.

  8. @Emil Bonsaksen: Glede – et stikkord jeg også forbinder med denne måten å jobbe på! Jeg vil si en designprosess i HTML/CSS er mer effektiv, og ikke minst kommuniserer en prototype mye bedre enn flate skisser, noe alle parter får utbytte av.

  9. @Anders Drage: Hvilken kompetanse man sitter på, er selvfølgelig avgjørende i denne sammenhengen: Man må bruke verktøy man behersker godt for å få gode resultater. Jeg tror at alle som jobber med web i dag vil ha stor nytte av å lære seg grunnleggende front-end, og at vi som designer for web bør prøve å bli dyktige i front-end – på denne måten kan vi få full kontroll over designen, og designen vil kommunisere mye bedre til alle som er involvert (kunder, utviklere osv.)

  10. Hva med Indesign? Har forsøkt det et par ganger. Det har enkelte fordeler som at det bla er lett å endre fonttyper om man benytter tekststiler. Raskt og effektivt. Man kan også lett opprette flere sider og eksportere dem til PDF med aktive lenker.

  11. @Mia Holte: Takk! Jeg personlig bruker Illustrator (som digitalt verktøy) tidlig i prosessen, og leker meg med farger og typografi for å få en “feeling” av hvordan designen skal bli. Ellers er jeg stor tilhenger av å lage detaljerte papirskisser før jeg blåser liv i designen. Min erfaring med Photoshop VS prototype overfor kunder, er at når kunden først har sett og følt en prototype (særlig responsive!) elsker de denne formen for presentasjon og ser verdien av det.

  12. @Johannes Hoff Holmedahl: Det hender aldri at jeg KUN designer i HTML/CSS – jeg bruker alltid verktøy som Photshop og Illustrator parallelt. Men derimot er det mange designere som KUN designer i Photoshop, noe jeg mener er mindre effektivt om man sitter på front-end-kompetanse. Jeg er helt enig i at en kombinasjon av gode verktøy gir de beste resultatene, og man må finne en designprosess man selv (og kunden!) er komfortabel med.

  13. @Knut Gangåssæter: InDesign er et utrolig bra program som jeg har brukt mye, og som du er inne på kan man få til mye med typografi. Jeg har av og til brukt InDesign til moodboards, men jeg har tilgode å bruke programmet når jeg designer for web.

  14. Hvis man snakker om design som man lager i InDesign eller Illustrator som du gjør Axel, så ser jeg ingen grunn til å ta det innom Photoshop – men med engang du begynner på en annen stilretning som innebærer glossyness, texturer osv osv. Da blir det plutselig svært inneffektivt og upraktisk med en design i browser metode. (dog, hvis noen har andre erfaringer med dette så er jeg lytter øre).

    For min del tror jeg at det har mye med hvilket design det er som skal gjøres. Noen stilarter funker rett og slett veldig dårlig når det kommer til å designe i browser. Overbevis meg gjerne om noe annet :)

  15. Som ikke-designer, men mer den stakkaren du nevner så vidt på slutten her:
    “Når det er tid for leveranse av dine Photoshop-skisser må du skrive side opp og side ned med dokumentasjon, og for sikkerhets skyld henge over skulderen til stakkaren som skal utvikle nettstedet – ting som tar mye tid. Og alt dette gjør du bare for å oppdage, sammen med kunden, at designen ikke ble akkurat som i Photoshop-skissene dine, men har “ubetydelige” avvik her og der. ”
    … må jeg si at jeg lenge har hatt designere langt, langt opp i halsen.

    De sitter i møter med kunden og presenterer flotte tegninger og alle klapper, og så forventer de pixel-perfect leveranse når dette skal presenteres med html/css.
    Mye har heldigvis skjedd med css siden jeg dreiv særlig med det, men fortsatt er det et utall browsere, skjermoppløsninger, vindusstørrelser osv å forholde seg til.
    Når designeren har laget en nydelig tegning der alle overskrifter er nøyaktig 14 tegn lange, og alle tekster har fem avsnitt a 8 linjer, og man så skal implementere dette i den virkelige verden, der noen av overskriftene bare er et par bokstaver, mens andre kan framstå som en novelle i seg selv, noen av tekstene er lange som vonde år, og har både tabeller, inlinebilder og i det heletatt, mens andre artikler ikke inneholder annet enn den tidligere nevnte overskriften, da blir rett og slett utviklingsjobben helt umulig.

    Nå finnes det sikkert designere og design som tar høyde for alt dette, men min erfaring er i alle fall at det er nok av designere som ikke har anelse om hvordan produktet som til slutt skal leveres – html og css på en gazillion forskjellige skjermer – oppfører seg.

    “Det ser flott ut på skjermen min, her er PDFen, da har jeg gjort jobben min, og du har jo bare jobben med å lage websider av det”. Jatta, det er jo den ENKLE jobben…

  16. @Anders Drage: Photoshop er uten tvil nyttig til sitt – vi er helt enige der. Og du har helt rett, det handler mye om hvilket design en skal lage. Men helhetlig sett er jeg personlig mer komfortabel med å gjøre brorparten av designen direkte i en HTML-prototype, parallelt med at jeg bruker Photoshop til deler av designen.

  17. @Ola Thoresen: Interessant innspill! Jeg er helt enig med deg; mange designere som designer for web har for lite kunnskap om HTML/CSS, og etter min mening burde alle som designer for web ha grunnleggende front-end-kunnskaper.

  18. God sak, hvis målet er å kunne justere kjapt. Men er det egentlig et mål? Burde man ikke heller sørge for å etablere kriterier for “riktig design” først, og få kunden med på at designerens fagkompetanse faktisk er god nok? Perfekt blir det uansett aldri (det vet til og med kunden). Men dyrt, ja det blir det når kunden stadig får anledning til å endre litt her og der.

  19. @Asbjørn Floden: Som regel gjør vi endringer på basis av ting som dukker opp i brukertester, men også ved gjennomgang med kunde som kjenner virksomheten – det kan f. eks. være forretningslogikk som taler for en endring. Etter gjennomgang med “peers”, f.eks. i en pluralistic walkthrough, kan det også bli nødvendig med endringer (http://iallenkelhet.no/2011/10/31/mer-uenighet-takk/). Og iterasjoner er bra, man treffer sjelden blink på første forsøk. Da er det bra å ha flere iterasjoner, og da er det viktig at det er enkelt å gjøre endringer underveis. Det blir som regel bedre resultat for hver iterasjon!

  20. @Marianne Røsvik: Takk for det! Personlig lager jeg sjelden wireframes og har knapt brukt Axure og andre wireframes-verktøy, men jeg vet mange har nytte av å gjøre det. Jeg kom over en litt interessant bloggpost om wireframes, som setter ting litt på spissen og som egentlig deler mitt syn: Why I don’t wireframe much.

  21. Bra blogginnlegg. Det er mange veier til Rom. Men det er to viktige ting vi designere ikke må glemme, og det er kundene og utviklerne. Man bør jo alltids se an prosessen og verktøyet man bruker for å presentere designskissene, enten om det er blyant og papir, trådskisser, photoshop, proto.. Men desto mer ferdig en skisse er, desto mindre føler kunden rom for innspill. Vi vil jo ha de med i loopen. (Og ja, der er f.eks prototypen gull til å gjøre raske endringer med).

    Selv om vi elsker pixel-perfect og alt ut til fingerspissene, så er jeg enig med @Ola Thoresen. Det å tørre å designe ærlig. “Dette er flott, men hvordan vil det egentlig se ut når vi er inne som redaktører?”, kan kunden si. Show’em the bad stuff? Uææ.. skummelt. Men kanskje ikke så dumt. Det vil gi utvikleren mindre hodebry og alt i alt et lettere samarbeid, OG kunden får ikke bakoversveis når alt er live.

    Uansett: alle verktøy har sin funksjon i en prosess, men skal man jobbe med digitale flater er det viktig å snakke (til en viss grad) samme språk som utviklerne.

  22. @Julie Erika Lorch-Falch: Takk, hyggelig at du liker innlegget! Det er utrolig viktig å designe “ærlig” – det er derfor vi unngår lorem ipsum for enhver pris, og forsøker å bruke reelt innhold så tidlig som mulig i prosessen. I en prototype er det lett å eksperimentere med innhold, og en prototype kommuniserer godt til kunder så vel som utviklere. Man kommer mye nærmere sluttresultatet og unngår de store overraskelsene!

  23. @Axel: Ja, det er selvfølgelig bra å kunne endre kjapt – forutsatt at det er det man skal gjøre, altså når forutsetningen for endringen er rimelig (brukertest, forretningslogikk, etc.). Introen øverst her ga imidlertid inntrykk av et litt annet utgangspunkt for endringene, og med det som bakteppe mener jeg (fortsatt) at man heller bør redusere behovet for endringer enn å optimalisere for dem.

  24. @Asbjørn Floden: Ser poenget ditt, og jeg er enig i at det man leverer bør være så bra at det ikke er nødvendig med mange endringer. Men iterasjoner behøver ikke nødvendigvis være sammen med en kunde som hele tiden vil endre ting; jobber man i team med flere designere, interaksjonsdesignere og innholdsfolk spiller man ball igjennom hele designprosessen, og man må foreta endringer/justeringer fortløpende. I en slik designprosess ser jeg det som en stor fordel å arbeide i en prototype da endringer kan gjøres raskt og effektivt, og mye av innholdet kan styres av interaksjonsdesignerne og innholdsfolkene parallelt, forutsatt at de sitter på den rette kompetansen.

  25. Ser at ingen har nevnt Sketch fra Bohemian Coding. Har brukt det i dag, og ser nok ut som jeg kan bytte ut Photoshop med denne lettere og mer elegante appen. Herlig, anbefales! http://bohemiancoding.com/sketch/

  26. @Tor Bollingmo: Takk for tips! Likte at den er vektor-basert; det er også en av grunnene til at jeg bruker Illustrator mer enn Photoshop når jeg designer. Skal teste Sketch!

  27. Veldig digg, særlig ift. eksportering av 2x-grafikk automatisk. Mye annet snacks også.

  28. Takk for bra innlegg, og for å belyse eit høgaktuelt tema :)

    Som frontender er det ikkje så viktig kva format ein prototype blir levert i, det er opp til interaksjonsdesigner/designer å avgjera kva som er rett format og verktøy i det einskilde prosjektet. Eg ser heilt klart fordeler med å kunne vise kunden ein prototype som er meir levande enn bileter av eit design.

    Eg syns det ikkje kjem fram av teksten kva prototypen skal brukast til. Skal den brukast til å presentere interaksjonsdesign og design for kunden og prosjektet, eller er prototypen ferdig HTML som er klar for implementering inn i eit CMS? Dersom sistnemnte er tanken er eg skeptisk til å lage prototypen på “kjappast mogeleg måte”. Rekk ein då levere HTML av god kvalitet, som er testa i ulike flater og ulike nettlesere?

    Dersom eg som frontender skulle designe nettsider fordi eg har kjennskap til design, trur eg mange kundar ville blitt missfornøgde :) Det tek kanskje kortare tid for meg å lage design og HTML/CSS samtidig, men designet vil mest sannsynleg ikkje bli så bra og heilt sikkert kjedeleg. Kvifor ikkje bruke den best kvalifiserte personen til jobben, slik at ein kan utnytte den tverrfaglege kompetansen ein ofte finn i webprosjekt? Kvalitet i alle ledd, er etter mi meining den viktigaste ingrediensen for at eit webprosjekt skal lukkast. Det innebærer også at frontend er av best mogeleg kvalitet.

    Det er viktig at me brukar minst mogeleg tid i prosjekta, men kan det då gå på bekostning av kvalitet? Dersom ein lagar ein prototype i HTML ferdig for implementering så kjapt som råd, får ein då teste og feilrette løysinga i ulike flater, ulike nettleseren? Å gjera slike ting i ettertid, kan fort koste meir enn det smakar.

  29. @Aud Marie Hauge: Takk for godt innspill! Noen ganger lager vi en prototype som kun har til hensikt å illustrere funksjonalitet, og front-end (av høy kvalitet!) er ikke en del av leveransen og blir overlatt til dedikerte personer. Men i utgangspunktet ønsker vi å levere front-end av høy kvalitet – kode som kan implementeres direkte i et CMS. For at koden skal være av høy kvalitet kan den ikke, som du antyder, lages i hastverk. Den må kvalitetssikres og tilfredsstille minimumskrav som god semantikk, ha høy tilgjengelighet og fungere på alle devices. For at en designer skal kunne ta hånd om denne oppgaven, i tillegg til designen, er det en viktig forutsetning at han/hun har den riktige kompetansen. Og min mening er at alle som designer for web som et minimum bør ha grunnleggende front-end-kunnskaper, men aller helst være dyktige på front-end. På denne måten kan de kommunisere designen de lager på en optimal måte, for alle parter, og de kan designe mer effektivt ved å ha flere strenger å spille på – flere verktøy. Min erfaring er at designprosessen blir mer harmonisk om jeg hopper inn og ut av Photoshop/Illustrator og hovedsaklig bygger designen i HTML/CSS.

  30. @Axel: En liten ting til som kan være verdt å ta med er at kode som skal inn i et CMS (eller i en skreddersydd løsning for den del) bør generaliseres så mye som mulig, og gjerne gjøres modulbasert på et vis.

    Har sett tilfeller der hver eneste sidemal reimplementerer de samme tingene (f.eks en overskriftstil) på samme måte, eller at hver sidemal er implementert med helt tydelig ulike “arkitekturer” i markupen. Skal ikke mange slike til før du har en løsning som er helt umulig å håndtere småendringer på.

  31. @Arve Systad: Et godt tips! Personlig har jeg pleid å bygge opp prototyper med PHP og laget selvstendinge moduler av all markup som skal brukes mer enn én gang. I det siste har jeg gjort noen forsøk på å modularisere CSS ved hjelp av SCSS og “@import”-featuren, men jeg lander nok på å samle CSS og kun modularisere HTML-markup da jeg ikke følte jeg fikk den oversikten jeg ønsket meg.

  32. @Arve @Acel Eit godt tips for modularisert CSS er http://smacss.com/ :)

  33. @Aud Marie: Leste denne boken i påsken faktisk – en utrolig bra bok! Det jeg mente med modularisering av CSS var å lage egne SCSS-dokumenter for hver eneste modul, organisert i en mappestruktur, litt a la BEM – en metodikk jeg synes blir litt overkill. SMACSS-metodikken er imidlertid noe jeg forsøker å følge.

  34. @Anders Drage:

    – men med engang du begynner på en annen stilretning som innebærer glossyness, texturer osv osv. Da blir det plutselig svært inneffektivt og upraktisk med en design i browser metode. (dog, hvis noen har andre erfaringer med dette så er jeg lytter øre).

    Har du sjekka ut csshat? Det er en relativt fiffig ps plugin som lar deg hente ut css3 kode fra photoshop layers. Som igjen betyr at du på en enkel måte kan ta med deg glossyness, texturer osv inn i en html/css prototype med minimal innsats > http://csshat.com/

  35. Et interessant innspill i debatten fra Jason Fried:

    1. “You can’t interact with a photoshop mockup.”
    2. “Get as close to Real as possible, as early as possible. That way, you’re in front of the real thing as long as possible. You’ll have more time to make decisions.”
    3. The Christopher Alexander example in the video: “You never know what’s real until you’ve actually built it”. “You’ll never know a building is any good until you’re inside.”

    http://www.davegrayinfo.com/2010/11/19/180/

  36. Jeg skrev ned mine notater fra analysen min av problemet:

    http://magnemg.tumblr.com/post/71417102316/should-you-go-straight-from-paper-prototypes-to-html

    Innspill verdsettes.

  37. @Magne Matre Gåsland: “You can’t interact with a photoshop mockup.” – mitt favorittargument for hvorfor interaktive prototyper kommunsierer design bedre enn flate Photoshopskisser. Designen kan testes og prøves og “føles” i en prototype. Og når man designer for web, er det helt klart en fordel at designen testes i det respektive mediet den skal brukes.

    Du har gjort en grundig analyse av prototyping vs. Photoshop på bloggen din – mange gode argumenter for og imot det å gå rett fra papirskisser til en HTML-prototype, skjønt brorparten av argumentene er i favør av HTML og CSS som designverktøy.

    Personlig mener jeg at alle som mestrer HTML og CSS, og designer for web, bør benytte HTML og CSS i designprosessen – ikke bare i etterkant, som et verktøy for å “konvertere” design fra Photoshop til HTML/CSS. Det gir mange fordeler underveis i prosessen, og sluttresultatet blir skremmende likt prototypen (som er en bra ting!).

    De som derimot ikke mestrer HTML og CSS så godt, men er noen ninjaer i Photoshop o.l. verktøy, bør helt klart benytte det verktøyet som er mest effektivt. Men det hadde ikke skadet om de i tillegg lærte seg HTML og CSS, slik at de i framtiden kan kommunisere sin design slik designen er tenkt brukt – i browseren. Det er en prosess mange parter kan nyte godt av, ikke minst kunden.

  38. Pingback: → Designprosess – en tid for alt — iAllenkelhet
  39. Pingback: → Frontend-utvikler med øye for design — iAllenkelhet

Skriv en kommentar

  • *

XHTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>