Kravspesifisering og innkjøp av ny web Nina Furu 19. Mars 2013
Nina Furu 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
Praktisk 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
Agenda Den strategiske webutviklingsprosessen Brukerorientering Beskrivelse av de nye sidene CMS-løsninger Kravspesifisering Valg og vurdering Oppsummering
Den strategiske webutviklingsmodellen
Web skal skape verdi for to parter Bedriftens mål Web Brukerens mål
Nettredaktørens jobb Bedriftens mål Sikre verdi Brukerens mål
Web skal skape verdi for to parter Bedriftens mål Web Brukerens mål
Web skal skape verdi for to parter Bedriftens mål Web Brukerens mål Verdi Konsept Innhold
Web skal skape verdi for to parter Bedriftens mål Web Brukerens mål Verdi skapes av Konsept som kan konkretiseres i Innhold som formidles i flere kanaler
Målsettinger for web
Målsetting Bedriftens målsetting Brukernes behov
Forretningsmål Hva driver dere med? Hva er selskapets MISJON? Å selge varer? Å levere tjenester? Å yte service? Å fremme ideer?
Hovedmål for websiden 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??
Strategi-pyramiden ordan? Strategisk Hvorfor gjør vi noe? Taktisk Hva gjør vi? Hvorfor? Operasjonelt Hvordan gjør vi det?
Dine mål bør være SMARTe Specific - konkrete Measurable - målbare Attainable - oppnåelige Results oriented - resultatorienterte Time based tidsbaserte
Eksempler på SMARTe mål 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
Brukerbehov
Brukerbehov Bedriftens målsetting Brukernes behov
Analyse av brukers behov Webstatistikk Triggerord-analyser Scenarier/personas Brukertesting Brukerundersøkelser Bruker-workshop
Verktøy Statistikk www.google.no/analytics Triggerordanalyser www.google.com/trends og Google Keyword Tool Brukerundersøkelser www.surveymonkey.no
Personas 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)
Å lage 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 (1) Nybegynner Utenlandsk bruker Jevnlig bruker Proffbruker - + Kompetanselinje Fredrik Flittig Klara Klok Espen Egenrådig Nina Nøysom
Å lage personas (2) 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 Harald Håndverker Bestemor Brita Kreative Kåre
Å lage personas (3) Kilde: http://wiki.openusability.org/kivio/index.php/personas
Kilde: Webcredible.co.uk
Personas-prosess i bedrift 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 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?
Er personas viktig? 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?)
Scenarier 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
Tenk på brukerscenariene på web Forsiden er forretningskritisk! Nettstedet skal tilfredsstille både bruker og deg. Oppfyllelse av de viktigste brukerscenariene bør være tilgjengelig rett på forsiden.
A-, B- og C-scenarier 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 og B- scenarier A- scenario B- scenarier B- scenario C-scenarier
Definere konsept Bedriftens mål Konsept Brukerens mål
Konseptet 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
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
Relevante regler Hvor ofte skal nyheter oppdateres? Hvordan skal vi sikre informasjonskvaliteten ( innholdsforvaltning / content governance )
Informasjon er ferskvare
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
Skill mellom tre typer saker 1. Dagsaktuelle saker gis utløpsdato, går til sletting/arkiv 2. Saker som trenger vedlikehold tidsstyrt tilbake på deskfunksjon 3. Statiske saker gis ingen utløpsdato, kan eventuelt oppdateres manuelt ved ekstern hendelse
Årshjulet
Årshjulet
Informasjonsarkitektur
Informasjonsarkitektur Skille mellom akser Skille mellom nivåer Bruke snarveier om nødvendig brukerbehovet trumfer alt annet!
Akser 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
Nivåer 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 )
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
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)
Hva trenger du?
Verktøy Papir/blyant Powerpoint Mock-up-software
Elementer til wireframe Logo Menyer globale og lokale Nyheter? Varslinger? Markedsføringsfelt? Innholdsfelt Hva er A-scenariene?
Hvor mange wireframes? Forside Seksjonsforside Innholdsside Utlistingsside
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-amazingexamples-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 ++ 10 Keyteq, Idium Portal Server, 50 000 7500 000 Designbyrå (lite/mellomstort), 25 000 3100 000 One.com, Idium Web, 1000 10 000 Wordpress, Joomla, Drupal gratis 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?
Typer av 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
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.
Agresso SuperOffice Logistikk Personal Dok.arkiv Tegn gjerne en portal-modell websidene Tips: Husk at det er mye enklere å hente data ut fra de underliggende systemene, enn å legge inn data til dem.
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!
E. Krav til søkemotoroptimalisering Validert kode Overskrifter inn i title-tag Ingresser inn i meta-description Plattform/versjonsuavhengighet Mer..?
www.straliasoft.no / www.straliasoft.com
F. Krav til mobiltilpasning
Relevante mobilstrategier Responsive design Egne mobilsider Apps
Responsive design
Egne mobilsider
Apps
Apps For transaksjonsorienterte oppgaver For oppgaver som gjentar seg For oppgaver der mobil/nettbrett er naturlig verktøy
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
Presentasjonen www.ninafuru.no/krav
Lykke til, og takk for meg! Nina Furu www.webgruppen.no Mobil 92208015 nina@webgruppen.no