Kapittel 3 – Design prosessen

3.2 Organisert design rettet mot brukervennlighet

• Design er en prosess, det er ikke en tilstand og kan ikke bli fullgod uten utvikling.
• Design prosessen kan ikke gjøres fra topp til bunn i et grensesnitt. Det totale bildet må passe på alle måter.
• Design involverer alltid oppdagelser av nye mål.

3.3 Designets tre pilarer

De tre pilarene kan hjelpe systemarkitekter til å gjøre gode idéer til suksessfulle systemer.

3.3.1 Retningslinjer og prosesser

En del av Apple’s suksess med Macintosh var systemets tidlige retningslinjer for design av standardkomponenter på tvers av mange programmer. Hvert system har forskjellige behov, men retningslinjer for standardisering bør lages for:

• Ord og ikoner
• Terminologi (objekter og handling)
• Skrifttyper
• Ikoner, grafikk og tykkelse på linjer
• Bruk av farger, bakgrunner, fremheving ved valg, og blinking
• Layout av skjermen
• Menyer, skjemaer, dialogbokser
• Prompt, tilbakemelding, feilmelinger
• Justering, tomme områder, marger
• Format på inndata og utdata
• Bruk og innhold i topptekster og bunntekster
• Innenheter og utenheter
• Tastatur, skjermoppløsning, pekerbruk
• Lyder, tilbakemeling med lyd
• Responstiden på de ulike oppgavene
• Handlingsrelatert design
• Direkte manipulasjon, klikk, dra og slipp
• Syntaks på kommandoer, semantikk
• Programmerbare funksjonstaster
• Feilbehandling og gjenopprettingsprosedyrer
• Opplæring
• Online hjelp og tutorials
• Opplæringsbøker og referansemanualer

3.3.2 Verktøy for design av brukergrensesnitt

Et problem med design av interaktive systemer er at brukerne ikke vet hvordan systemet vil se ut når det er ferdig. Siden systemene av og til er ukjente, er det ikke sikkert brukerne forstår bruken av ulike teknikker. Dessverre er det vanskelig, tidkrevende og dyrt å endre et brukergrensesnitt når systemet først er ferdig.

3.3.3 Vurdering av eksperter og test av brukervennlighet

Før et system legges ut for salg, må det testes av eksperter og gjennomsnittsbrukere.

3.4 Metoder for systemutvikling

LUCID står for Logical User-Centered Interactive Design Methodology.

1. Utvikle et produktkonsept
2. Utfør undersøkelser og bruksanalyser
3. Lag designprototyp av grensesnittet
4. Utfør design av grensesnittet fullt ut
5. Implementer programmeringen
6. Utvikle support for systemet

3.5 Etniske observasjoner

Forberedelser

• Forstå politikk og arbeidskulturen
• Gjør deg kjent med systemet og historien
• Lag mål og forbered spørsmål
• Få tilgang og lov til å observere systemet og intervjue

3.9 Spørsmål om lover

Under en prosess av systemutvikling må man ta hensyn til lover og regler. Datasystemer skal ofte behandle konfidensielle data. Det er viktig at dataene kan lagres og brukes under sikre omstendigheter. Flysystemer og kjernekraftsystemer må også være svert pålitelige.

For at en systemutvikler skal kunne tjene penger, må han ha kopirettighetene til systemet. Men ikke alt materiale er egne for kopibeskyttelse. Materiale som farge, skrifttyper, linjer og bokser kan ikke kopibeskyttes. Dersom man ikke kan få kopirettigheter til et brukergrensesnitt, kan det være en mulighet å ta patent på det. Mange mener at brukergrensesnitt ikke bør kopibeskyttes, men heller delt med andre slik at standarder på grensesnittene kan oppnås.