Post on 19-Oct-2019
Kravspesifisering og
innkjøp av ny web
Nina Furu
19. Mars 2013
• Jobber med webkommunikasjon og webstrategi
• Partner i Webgruppen
• Driver Nettredaktørskolen
• Styreleder i Webforum Norge
• www.nettredaktor.no
• www.websuksess.no
• www.ninafuru.no
• Mangeårig portalredaktør
• Lærebokforfatter
• Med mer
Nina Furu
• Holder på 9-15.30
• Tar pauser
• Lunsj 11.30
• Toaletter innerst (ved kjøkkenet)
• Nettverk: webgruppen gjest
• Passord: webkurset
• Kampanje: Vi gir 20 kroner til Redd Barna for hver
Facebook-innsjekking
Praktisk
• Den strategiske webutviklingsprosessen
• Brukerorientering
• Beskrivelse av de nye sidene
• CMS-løsninger
• Kravspesifisering
• Valg og vurdering
• Oppsummering
Agenda
Den strategiske webutviklingsmodellen
Web skal skape verdi for to parter
Brukerens
mål
Bedriftens
mål
Web
Nettredaktørens jobb
Brukerens
mål
Bedriftens
mål
Sikre verdi
Web skal skape verdi for to parter
Brukerens
mål
Bedriftens
mål
Web
Web skal skape verdi for to parter
Brukerens
mål
Bedriftens
mål
Web
Verdi
Konsept
Innhold
Web skal skape verdi for to parter
Brukerens
mål
Bedriftens
mål
Web
Verdi
Konsept
Innhold
skapes av
som kan konkretiseres i
som formidles i flere kanaler
Målsettinger for web
Målsetting
Bedriftens
målsetting Brukernes
behov
• Hva driver dere med? Hva er selskapets MISJON?
• Å selge varer?
• Å levere tjenester?
• Å yte service?
• Å fremme ideer?
• …
Forretningsmål
• Hva er det bedriften mest av alt ønsker at kunden skal
gjøre på nettstedet?
• Kjøpe noe?
• Finne informasjon?
• Ta kontakt?
• Drive selvbetjening?
• Lese siden?
• Søke jobb?
• …?
Hovedmål for websiden
Strategi-pyramiden
Strategisk
Taktisk
Operasjonelt
Hvorfor gjør vi noe? Hvordan?
Hvorfor?
Hva gjør vi?
Hvordan gjør vi det?
• Specific - konkrete
• Measurable - målbare
• Attainable - oppnåelige
• Results oriented - resultatorienterte
• Time based – tidsbaserte
Dine mål bør være SMARTe
• Vi skal ha 12% økning i salg av lydbøker innen 31.12
• Alle kurspåmeldinger skjer elektronisk fra 1. mai
• Selvbetjent henting av kundeopplysninger fra lansering
av min side
• 10% reduksjon i behandlingstid fra 1. august
Eksempler på SMARTe mål
Brukerbehov
Brukerbehov
Bedriftens
målsetting Brukernes
behov
• Webstatistikk
• Triggerord-analyser
• Scenarier/personas
• Brukertesting
• Brukerundersøkelser
• Bruker-workshop
Analyse av brukers behov
Verktøy
• Statistikk www.google.no/analytics
• Triggerordanalyser www.google.com/trends og
• Google Keyword Tool
• Brukerundersøkelser www.surveymonkey.no
• Arketyper som representerer brukerne dine
• Fiktive personer du oppretter, gir navn og demografisk
beskrivelse
Personas
• Arketyper som representerer brukerne dine
• Fiktive personer du oppretter, gir navn og demografisk
beskrivelse
• Tips: Steve Mulder, The user is always right
Personas
• Karakteristikk som baseres på faktaopplysninger
• Et hjelpemiddel til å redusere usikkerhet rundt
problemstillinger
• Kan gjøre det lettere å ta beslutninger i utviklingen
• Gjør at vi kan fokusere på detaljer – vi går fra det
generelle til det spesifikke
• Distanserer seg fra sine egne meninger
Personas
• Hvem er de typiske brukerne av ditt nettsted?
• (Tenk gjerne ut fra de viktigste bruksmønstrene)
Personas
• Se på hvilke transaksjoner som gjøres på din web
• Hva kjennetegner de som gjør de ulike transaksjonene?
• Hva slags erfaring har en slik bruker med web?
• Hva kan en slik bruker om ditt fagområde?
• Hvordan vil de ulike personasene ønske å benytte din
web til å gjennomføre de ulike transaksjonene?
Å lage Personas
Å lage Personas (1)
Fredrik
Flittig
Klara
Klok
Espen
Egenrådig
Nina
Nøysom
Proffbruker Jevnlig bruker Utenlandsk
bruker Nybegynner
Kompetanselinje - +
• Ta utgangspunkt i de forskjellige brukergruppene
nettstedet har
• Lag stiliserte brukergrupper basert på dette
Å lage personas (2)
• Ta utgangspunkt i de forskjellige brukergruppene
nettstedet har
• Lag stiliserte brukergrupper basert på dette
Å lage personas (2)
Harald Håndverker
Bestemor Brita
Kreative Kåre
Å lage personas (3)
Kilde: http://wiki.openusability.org/kivio/index.php/Personas
Kilde: Webcredible.co.uk
• Involver alle i å skape personas
• Bruk blader, klipp og lim
• Fortell historien til den enkelte persona
• La personaene bli noen man snakker om og refererer til i
web-arbeidet
Personas-prosess i bedrift
• Lag personas som folk husker og kan relatere til
• Ikke lag alt for mange personas (3-5 er ofte nok)
• Gi dem tydelige navn
• Bruk dem i webutviklingen
• Bruk dem til mental testing: ”Hva vil Kåre syns om
dette?”
Personas
• Ja, fordi de hjelper deg å tenke scenarier
• Men du kan også tolke deg fram til scenarier direkte, for
eksempel ut fra statistikk (mest besøkte sider, mest
klikkede lenker …) eller brukerundersøkelser (”hvilket
innhold er du mest interessert i på våre sider?”) erfaring
med dagens nettside (hva ringer bruker til oss for?)
Er personas viktig?
• Bruker kommer til nettstedet av en grunn
• Det bruker kommer for = brukers scenario
• Brukers mål = oppfyllelsen av sitt scenario (”task
completion”)
• Scenariet har ofte et navn i brukers hode; et triggerord
Scenarier
• Forsiden er forretningskritisk!
• Nettstedet skal tilfredsstille både bruker og deg.
• Oppfyllelse av de viktigste brukerscenariene bør være
tilgjengelig rett på forsiden.
Tenk på brukerscenariene på web
• A-scenarier = de 1-3 viktigste tingene som de langt fleste
brukerne kommer for.
• B-scenarier = det resten av brukerne kommer for.
• C-scenarier = det bruker ikke nødvendigvis etterspør,
men som noen har lyst til å si.
A-, B- og C-scenarier
• A-scenarier = de 1-3 viktigste tingene som de langt fleste
brukerne kommer for.
• Forside, meny, dyplenking/søk
• B-scenarier = det resten av brukerne kommer for.
• C-scenarier = det bruker ikke nødvendigvis etterspør,
men som noen har lyst til å si.
A-, B- og C-scenarier
• A-scenarier = de 1-3 viktigste tingene som de langt fleste
brukerne kommer for.
• Forside, meny, dyplenking/søk
• B-scenarier = det resten av brukerne kommer for.
• Meny, dyplenking/søk
• C-scenarier = det bruker ikke nødvendigvis etterspør,
men som noen har lyst til å si.
A-, B- og C-scenarier
• A-scenarier = de 1-3 viktigste tingene som de langt fleste
brukerne kommer for.
• Forside, meny, dyplenking/søk
• B-scenarier = det resten av brukerne kommer for.
• Meny, dyplenking/søk
• C-scenarier = det bruker ikke nødvendigvis etterspør,
men som noen har lyst til å si.
• Dyplenking/søk, eventuelt egne felter
A-, B- og C-scenarier
A-
scenario
A og B-
scenarier
B-
scenario
B-
scenarier
C-scenarier
Definere konsept
Brukerens
mål
Bedriftens
mål
Konsept
• Et begrep
• En betegnelse på brukeropplevelsen
• En ”kortformsforklaring” av hva siden er ment å være og
for hvem
• ”Nettavis”
• ”Digitalt servicekontor”
• ”Verktøykasse for prisfastsetting av eiendommer”
• ”Presentasjon av bedriften og våre produkter”
Konseptet
Webkonseptet må konkretiseres
• I informasjonsarkitektur (hvilke sider skal vi ha) – som blir
til menyer
• I wireframes (hvilket innhold skal vi ha på hvilke sider) –
som blir til design
• I regler og rutiner (hvem har ansvar for hva, hvor ofte
skal man publisere …)
Informasjonsarkitektur
Informasjonseiermatrise
• Hvor ofte skal nyheter oppdateres?
• Hvordan skal vi sikre informasjonskvaliteten
(”innholdsforvaltning”/”content governance”)
Relevante regler
Informasjon er ferskvare
• Ha en innholdseiermatrise, så alle vet hvem som har
ansvar
• Ta en runde med fjerning av gammelt rask ved
omlegging (men ikke fjern så mye at det skader deg på
Google)
• Legg opp til gode rutiner ved nyproduksjon
Informasjon er ferskvare
1.Dagsaktuelle saker – gis utløpsdato, går til sletting/arkiv
2.Saker som trenger vedlikehold – tidsstyrt tilbake på desk-
funksjon
3.Statiske saker – gis ingen utløpsdato, kan eventuelt
oppdateres manuelt ved ekstern hendelse
Skill mellom tre typer saker
Årshjulet
Årshjulet
Informasjonsarkitektur
• Skille mellom akser
• Skille mellom nivåer
• Bruke snarveier om nødvendig – brukerbehovet trumfer
alt annet!
Informasjonsarkitektur
• Produktmeny (stoler, bord, sofaer …)
• Målgruppemeny (privatkunde, bedriftskunde …)
• Funksjonalitetsmeny (søk jobb, velg språk …)
• En og samme meny skal ikke kombinere innhold på
forskjellige akser
Akser
• Epler og grønnsaker er ikke på samme nivå
• Frukt og grønnsaker er på samme nivå
• Epler og gulrøtter er på samme nivå (men under
forskjellige ”mammakategorier”)
Nivåer
Samme nivå
Samme nivå
Samme nivå
Samme hovedemne
Samme hovedemne
Samme hovedemne
Samme akse
Emner vs attributter
• Emner er tematiske operanter – det er det jeg leter etter
når jeg leter etter informasjon
• Emnebetegnelser = triggerord = substantiver
• Attributter = egenskaper ved det enkelte emne (for
eksempel pris, merke eller lignende)
• Man kan ha attributtseleksjoner eller til og med egne
attributtmenyer (for eksempel kart), men attributter og
emner skal aldri blandes i samme meny.
Emnemeny
Attributter som seleksjonskriterier
Attributtmeny
”Hygienefaktorer”
Wireframes
• Prototyper; tegninger av hvordan det kommer til å bli
• Skisser som lar andre se hva du har tenkt
• Skisser kan avsløre fundamentale feil før du bruker
programmerertimer
• Du kan brukerteste på en papir-prototype (vis bruker
skissen, beskriv en oppgave og spør hvordan brukeren
ville gå fram for å få dette gjort)
• Du kan brukerteste på en prototype på skjerm (bruker
kan klikke seg rundt og vise hvordan bruker vil gå frem)
Wireframes
Hva trenger du?
• Papir/blyant
• Powerpoint
• Mock-up-software
Verktøy
• Logo
• Menyer – globale og lokale
• Nyheter?
• Varslinger?
• Markedsføringsfelt?
• Innholdsfelt
• Hva er A-scenariene?
Elementer til wireframe
• Forside
• Seksjonsforside
• Innholdsside
• Utlistingsside
Hvor mange wireframes?
Webpublisering
Hva trenger du for å lage en webside?
• Domene
• Webhotell (serverplass)
• HTML-kode
Hvordan får du til HTML-koden?
Hvordan får du til HTML-koden?
• Skrive for hånd
• Bruke en HTML-editor
• Bruke et publiseringsverktøy
1. Skrive for hånd
1. Skrive for hånd
• Skriver tekst og kode i tekstbehandlingsprogram for ren
tekst
• Legger fila på webserver (via FTP)
• Åpner fila i nettleser
• Vips: Web-side!
• Flatkodede sider er billig, men krever kompetanse.
Lyst til å lære HTML?
• http://www.w3schools.com/
2. Bruke en HTML-editor
2. Bruke en HTML-editor
• Et program som hjelper deg å huske HTML-koder
• WYSIWYG-editorer
• Eksempler: Front Page, First Page, Dreamweaver
• Fortsatt billig, og du slipper å huske på alle kodene.
Online HTML-editor
• http://www.spiderweblogic.com/HTML-Tag-
Generator.aspx
• … grei hvis du bare ønsker et lite stykke HTML på
kjappen
Det store MEN:
• Både håndkoding og editorer lager flate sider
• Det betyr at form og innhold er ett
• (Ønsker du å skifte bakgrunnsfarge på siden, må du inn
på hver enkelt side og gjøre en endring)
Det store MEN:
• Både håndkoding og editorer lager flate sider
• Det betyr at form og innhold er ett
• (Ønsker du å skifte bakgrunnsfarge på siden, må du inn
på hver enkelt side og gjøre en endring)
•
Det store MEN:
• Både håndkoding og editorer lager flate sider
• Det betyr at form og innhold er ett
• (Ønsker du å skifte bakgrunnsfarge på siden, må du inn
på hver enkelt side og gjøre en endring)
• Håkon Wium Lie
CSS
• Gjør det mulig å behandle form og innhold separat, også
på flate sider
• Refererer alle innholdssider til et felles stilsett, slik at
globale endringer kan gjøres på ett sted
• Nå del av HTML-standarden
• HTML 5 og CSS 3
• http://www.queness.com/post/4105/13-amazing-
examples-of-html5-and-css3
CSS
• CSS er nå del av websidekoding, enten du gjør det
manuelt eller via en publiseringsløsning
• Publiseringsløsning = CMS =
• Content Management System
3. Content Management Systemer
3. Content Management Systemer
• Programmer for å håndtere produksjon og oppdatering
av websider
• Adskilt form og innhold
• Nettbasert (ikke lokalt på PC)
• Mulig for flere å jobbe på samme løsning
• Mulig med separate oppgaver
Pris for CMS
• Episerver, Sharepoint, 1 mill ++
• Keyteq, Idium Portal Server, 50 000 – 500 000
• Designbyrå (lite/mellomstort), 25 000 – 100 000
• One.com, Idium Web, 1000 – 10 000
• Wordpress, Joomla, Drupal – gratis
Pris for CMS
• Episerver, Sharepoint, 1 mill ++
• Keyteq, Idium Portal Server, 50 000 – 500 000
• Designbyrå (lite/mellomstort), 25 000 – 100 000
• One.com, Idium Web, 1000 – 10 000
• Wordpress, Joomla, Drupal – gratis
10
7
3
2
9
”Funksjonalitet
s-poeng”
Gratisløsningene
• Wordpress
• Joomla
• Drupal
• Lavest brukerterskel: Wordpress
Det kommersielle markedet
Adressene
• www.episerver.no
• http://sharepoint.microsoft.com/
• www.ez.no
• www.frontkom.no
• www.idium.no
• www.wordpress.com
• www.wordpress.org
• www.webnodes.no
• www.fanbooster.no
• www.pagemodo.com
Kravspesifikasjonen
Kravspesifikasjonen
• Dokumenterer ønsket løsning
• Er grunnlag for anbudsinnhenting og innkjøpsprosess
• Er grunnlag for videre teknisk prosess
• Er grunnlag for videre designprosess
• Er grunnlag for implementering
Hva bør en kravspesifikasjon inneholde?
A. Ønsket funksjonalitet
B. Eventuelle integreringsbehov
C.Eventuelle migreringsbehov
D. Informasjonsarkitektur og wireframes
E. Krav til søkemotoroptimalisering
F. Krav til mobiltilpasning
G.Eventuelle tekniske krav til hosting/drifting
H.Forventet antall admin-brukere (hvis veldig høyt eller
spesielt differensiert)
A. Ønsket funksjonalitet
• Hvordan skal sidene fungere? Beskriv gjerne hvordan
funksjonaliteten opptrer.
• Si for eksempel: ”Når man klikker på flagget for engelsk språk,
skal man komme til den siden man allerede er på i engelsk
versjon. Man kan så klikke seg rundt i de engelske sidene, og om
man klikker tilbake til norsk, kommer man tilbake til den siden
man er på i norsk versjon”.
• Dette kan også formuleres som ”parallelle språkversjoner” (i
motsetning til ”separate engelske sider” hvor man alltid kommer
til engelsk forside, og nettstedene ikke er like med unntak av
språk), men det forutsetter at man vet at leverandøren definerer
disse begrepene på samme måte.
Funksjonalitet
• Hva er relevant funksjonalitet?
1. Artikkelbehandling
2. Menybehandling
3. Malbehandling
4. Bildebehandling
5. Skjemabehandling
6. Brukerbehandling
7. Sosial funksjonalitet
8. Metadata
9. WAI / Universell tilgjengelighet
10.Språk
Typer av funksjonalitet
B. Eventuelle integreringsbehov
• Skal websidene dynamisk vise data som hentes fra
andre kilder? I så fall må dette beskrives i detalj.
• For eksempel: ”Brukeren skal ha tilgang til å administrere
egne brukerdata, som ligger i SuperOffice. Ved
pålogging skal informasjon om navn og adresse hentes
fra SuperOffice og vises på siden ”Min Profil”. Når bruker
gjør endringer i disse dataene, skal den nye versjonen
sendes tilbake til SuperOffice og oppdatere oppføringen
der.”
• Tips: Husk at det er
mye enklere å hente
data ut fra de
underliggende
systemene, enn å
legge inn data til
dem.
Tegn gjerne en portal-modell
websidene
Ag
re
sso
Sup
erO
ffic
e
Log
istik
k
Pe
rson
al
Do
k.a
rk
iv
C. Eventuelle migreringsbehov
• Hvordan skal innhold flyttes fra gammel til ny løsning?
• Hvis du har for eksempel 10 000 sider som skal
overføres, er dette en viktig vurdering.
• Tips: Alle leverandører sier at dette lar seg gjøre
automatisk. Det er som regel tilfelle for kanskje 50 % av
innholdet, resten må flyttes for hånd.
D. Informasjonsarkitektur og wireframes
• Vis hva du har tenkt!
• Validert kode
• Overskrifter inn i title-tag
• Ingresser inn i meta-description
• Plattform/versjonsuavhengighet
• Mer ..?
E. Krav til søkemotoroptimalisering
F. Krav til mobiltilpasning
• Responsive design
• Egne mobilsider
• Apps
Relevante mobilstrategier
Responsive design
Egne mobilsider
Apps
• For transaksjonsorienterte oppgaver
• For oppgaver som gjentar seg
• For oppgaver der mobil/nettbrett er naturlig verktøy
Apps
G. Eventuelle tekniske krav til drifting
• Planlegger du å drive websidene på din egen server? I
så fall må du si tydelig fra – det gir helt andre rammer for
prisingen.
• Ofte er en slik modell dyrere og dårligere – men det kan
hende du har sikkerhetsvurderinger som gjør det
nødvendig.
• Hvis du skal drifte selv, må du si hva slags servere og
driftsmiljø du har.
• Hvis du skal integrere med andre programmer, må du
oppgi navn, versjon etc.
F. Eventuelle wireframes
• Hvis du alt har tegnet wireframes, så legg dem ved
kravspesifikasjonen. Det hjelper leverandøren å se hva
du har tenkt.
H. Forventet antall admin-brukere
• Spesifiser gjerne litt rundt hvor mange admin-brukere du
ser for deg (2? 20? 200? 2000?).
• Si fra hvis du har behov for differensierte roller (standard
= journalist + redaktør + superadmin)
• Si fra hvis du trenger å kunne sette tilgang på enkelte
mapper eller seksjoner
• Si fra hvis du trenger å kunne definere privilegier fritt.
For din egen del, inkluder også
• En indikasjon på ambisjonsnivå
• Need-to-have vs nice-to-have
• En buffer i tid og penger som ingen vet om
Need-to-have vs nice-to-have
• Når det beste blir det godes fiende
• Når små detaljer fordobler kostnaden
• Når alle får lov til å ønske seg funksjonalitet fritt
• Vær tydelig på hva du absolutt MÅ ha, og hva du
eventuelt kan klare deg uten hvis det blir for dyrt eller for
komplisert.
• Lag eventuelt en førsteversjon og definer
”påpluggingsmoduler” etter hvert.
Hva bør du forvente?
• At tilbudet ikke inneholder overføring av eksisterende
innhold
• At tilbudet ikke inneholder innlegging av nytt innhold
• At tilbudet ikke inkluderer design
• At tilbudet ikke inneholder mer enn én visningsmal (med
mindre du spesielt har bedt om det)
• At tilbudet ikke omfatter kostnaden fom år 2
• At tilbudet ikke er skrevet spesielt for deg
Innkjøpsprosessen
A. Identifiser mulige leverandører
B. Send ut kravspesifikasjon
C.Motta tilbud
D.Sammenlign tilbud
E. Velg leverandør
F. Informér vinner og tapere
A. Identifiser mulige leverandører
• Ambisjonsnivå og budsjettrammer?
• Eksisterende rammeavtaler?
• Eksisterende kundeforhold?
• Foreliggende positive og negative erfaringer?
• Referanser?
B. Send ut kravspesifikasjon
• Husk å sette en frist for anbud
• Vær forberedt på at noen ikke har tid og anledning til å
besvare
C. Motta tilbud
• Sammenstill de innkomne tilbudene (vær forberedt på
noen korte og noen lange, noen trykte og noen
elektroniske, noen tilpassede og noen standard)
D. Sammenlign tilbud
• Sett om en sammenligningsmatrise med utgangspunkt i
din kravspesifikasjon
• Beregn gjerne funksjonalitetspoeng
• Beregn gjerne kost per funksjonalitetspoeng
Sammenligningsmatrise
Sammenligningsmatrise med funksjonalitetspoeng
Kost per funksjonalitetspoeng (KPF)
Pris
Antall funksjonalitetspoeng
= KPF
Utdrag fra saksframlegg, tilbudsevaluering for kunde
E. Velg leverandør
• Se på kostnad
• Se på kostnad per funksjonalitetspoeng
• Se på referanser
• Prøv løsningen! (”Hands-on brukervennlighet” er ikke
alltid lett å måle kvantifiserbart)
F. Informer vinner og tapere
• Det er greit om også de som ikke vant anbudet får
beskjed om at leverandør er valgt.
5. Implementering
• Migrering tar tid!
• Automatisk migrering er ofte ikke mulig
• Klipp-og-lim tar også mye tid og krefter
• Jobb utfra en informasjonseiermatrise, og involvér
informasjonseierne!
• Implementering er en god måte å bli kjent med CMS’et
på
• Benytt anledningen til å kvalitetssikre informasjon
• Husk opplæring!
Informasjonseiermatrise
6. Lansering
• Markér lanseringen
• Ære den som æres bør!
• Ha en fest
• Men ha gjerne en ”soft-launch” i forhold til ekstern
oppmerksomhet
7. Vedlikehold • … og så var det alt det andre arbeidet …
Oppsummering
• Kravspesifikasjon skal beskrive den løsningen du ønsker
deg
• ”Som man spør får man svar”
• Skill gjerne mellom need-to-have og nice-to-have
• Legg tid og arbeid i forberedelsene, så sparer du penger
senere
• Ta deg bryet med å teste en løsning før du kjøper
Lykke til, og takk for meg!
Nina Furu
www.webgruppen.no
Mobil 92208015
nina@webgruppen.no