11 tips for å gjera overgangen frå design til utvikling så smertefri som mogleg

12. Hold kontakten og følg opp utvikleren.

Uansett hvor lang huskeliste du har, vil det alltid dukke opp noe du har glemt, noe som kan være uklart eller som utviklerne rett og slett overser. Hvis du ikke sjekker innom og hører hvordan det går, blir det ofte til at utviklerne gjetter eller i beste mening gjør det de tror du mente. Det er viktig å skape et miljø hvor utviklerne føler det er naturlig å ta kontakt ved den minste tvil.

Måten man dokumenterer på har også innvirkning på hvorvidt man får kommunisert hva som trenger å kommuniseres. En skriftlig sidebeskrivelse i tillegg til kommenterte funksjons- eller designskisser gjør at man blir tvunget til å sette ord på hva som er formålet med siden og de forskjellige elementene og hvordan de skal oppføre seg. Da blir det lettere å fange opp om man har glemt noe. I tillegg utfyller de to dokumentene hverandre og øker forståelsen av dem begge. En herlig liten symbiose: Beskrivelsen gjør at skissene gir vil fremstå klarere, og skissene hjelper å forstå beskrivelsen bedre. Men husk å holde kontakte med utviklerne….

Dette er gode tips som designerne bør ha på pulten sin mens de jobber. Men jeg syns du svarer på litt feil spørsmål (hvis jeg forstår deg rett). Fremfor å gjøre design og så overføre til en utvikler er det mye bedre om utvikleren og (grafisk) designer jobber delvis parallellt. Designet må selvsagt ligge i forkant, men tettere samarbeid mellom designeren og utvikleren er ofte en nøkkelfaktor til et suksessfullt prosjekt.

Noe av det mest irriterende jeg vet er design som ikke er pixel-perfect.
* Marginene er ikke konsistente
* Kolonner er ikke like brede
* Alt anna som er 1px unna å være logisk

Det betyr at jeg må sette meg ned å redefinere masse elementer i designet, noe som ikke er bare bare på større designprosjekter.

Ikke rettet mot en spesifikk designer, mer generellt

Sebastian: Her er jeg faktisk litt uenig med deg. Jeg syns det er bortkasta tid for en designer å pikselflikke i photoshop. Sålenge designeren har en god overordnet plan og et godt grunnlag (grid osv) er det helt ok for meg at ikke alle elementene til enhver tid er 100%.

Dette er selvsagt individuelt og understreker poenget mitt med at samarbeid mellom designer og utvikler er veldig viktig, spesielt fordi hvilke ting som er viktige varierer fra person til person.

Torstein og Christian: Ja – det er veldig gode poeng. Det aller beste er om ein kan samarbeida tett. Kanskje er lista like gjerne noko som den grafiske designaren og utviklaren bør sjå på saman for å finna den beste løysninga.

Ta med en skriftlig liste over hvordan utviklerene kan verifisere at alt arbeid er gjort.
Krav som skal være innfridde før det kan godkjennes.

Andreas

Avpasning til situasjonen og menneskene man jobber med nok også noe man kan huske på. Hvorvidt man har utviklerne rett nedi gangen eller om de sitter i India, gjør spesifikasjonsbehovene høyst forskjellige. Flat struktur og lav terskel for å stille spørsmål gjør at en utvikler som sitter nedi gangen er mer tilbøyelig til å gjøre selvstendige vurderinger og stille spørsmål ved mangler eller når noe ikke henger på greip. Jeg tror det kan være overkill å sette opp en detaljert sjekkpunktliste, og at ressursene er bedre brukt på å samkjøre forståelsen av produktet som skal lages. Har man jobbet med utvikleren tidligere, vet man gjerne også hvilket dokumentasjonsnivå som er tilstrekkelig for et godt resultat. Dette er en av fordelene ved å jobbe med norske utviklere. Man slipper å bruke unødvendig mye ressurser på dokumentasjon, og kan heller fokusere på forståelse og utveksling av forbedringsforslag. Utviklere er stort sett veldig smarte, logiske og detaljfokuserte. Det er synd hvis man betrakter dem som roboter som skal fullføre en strikt sjekkpunktliste, og ikke som oppegående fagfolk som er istand til å se forbedringsmuligheter underveis.

Sitter utviklerne i Asia eller Østeuropa, må man ta høyde for at der er en annen kultur for hierarki, kritikk og stolthet i enkelte land. Språk, tidsforskjell og lite personlig kontakt gjør at kommunikasjonen ikke flyter like lett og hyppig. Detaljnivået og presisjonen i dokumentasjonen må som oftest bli noe høyere. Men kjenner man de man jobber med, kan nivået selvfølgelig avpasses til personene også i outsourcede prosjekter. Skype er forresten et fantastisk verktøy for å smidiggjøre internasjonale prosjekter.

Jeg kan forøvrig sterkt anbefale denne presentasjonen fra Cooper som nettopp går på samarbeidet mellom designere og utviklere, og om smidighet vs fossefall: http://www.cooper.com/journal/agile2008/

Flott liste! Den bør absolutt sitte i ryggmargen på alle som jobber med design på nett.

Punkt 5 har en herlig blanding av brukervennlig og brukerfientlig utforming. Menyen hos Twitter, som endrer innhold ettersom man er logget inn eller ut, er et godt eksempel på noe brukervennlig. I tillegg er det ofte et skille at brukerne selv har konfigurert bakgrunnsbilde og/eller farger. Dette kan slå heldig og uheldig ut

På den brukerfientlige siden, tar jeg meg stadig i å nøle når jeg skal logge inn. Luften mellom «Login» og «Join Twitter» er så lik ordmellomrommet i «Join Twitter» at jeg stopper unødvendig opp for å klikke på riktig punkt. Heldigvis finnes det egne gode programmer som gir en bedre brukeropplevelse av Twitter.

Nå som Douglas Bowman har forlatt Google til fordel for Twitter, er det kanskje rom for forbedring?

Fin liste! Mange nyttige punkter.

Men er xhtml- og css-programmering utvikling? Eller er det egentlig design det også?

Jeg mener at man bør kunne forvente at en designer som jobber med web idag har en rimelig god kjenskap til xhtml og css. De fleste punktene i lista blir enklest løst nettopp slik. En designer som har forståelse for hvordan web-programmering fungerer, vil tenke på dette gjennom hele designprosessen, og det vil syns på resultatet. Det er tross alt ikke så vanskelig. grunnleggende xhtml og css lærer man seg på et par dager. (men det tar lang tid å virkelig mestre.)

Min erfaring er at veldig mange “kvalitetsproblemer” på nettsider oppstår nettopp fordi overgangen mellom design og programmering håndteres for dårlig. Ofte blir utviklerene av programvaren som driver sidene satt til å “programmerer utseende”, uten å ha de nødvendige forutsettningene for å gjøre den jobben godt. Hverken de eller designeren har den nødvendige kunnskapen om xhtml og css, og brukerene blir skadelidene ved at kvaliteten blir dårlig.

Ebdesign blir også bedre av at designeren har skikkelig kunnskap om mediet de jobber i. Hva er mulig typografisk i css? hvordan blir timingen rikitig på dette javascriptet? etc. etc. De dyktigste designerene på nettet i dag, som f.eks. Andy Clarke og John Hicks, gjør også det meste av xhtml’en og css’en sin selv.

Vis hvordan besøkte, ubesøkte, aktive og fokuserte lenker skal formatteres, både i brødtekst, overskrifter, bildelenker og i navigasjon. La utvikler ta minst mulig kreative vurderinger. Her bør designet har kjennskap til universell utforming slik at fargekontrastene blir gode nok.

Design alle HTML-elementene som kan bli brukt på nettstedet – overskrifter i flere nivå, skjema, punktlister, tabeller osv. Igjen, ikke la utvikler ta kreative valg.