Kravspesifisering og innkjøp av ny web. Nina Furu 19. Mars 2013

Transkript

1 Kravspesifisering og innkjøp av ny web Nina Furu 19. Mars 2013

2 Nina Furu Jobber med webkommunikasjon og webstrategi Partner i Webgruppen Driver Nettredaktørskolen Styreleder i Webforum Norge Mangeårig portalredaktør Lærebokforfatter Med mer

3 Praktisk Holder på Tar pauser Lunsj Toaletter innerst (ved kjøkkenet) Nettverk: webgruppen gjest Passord: webkurset Kampanje: Vi gir 20 kroner til Redd Barna for hver Facebook-innsjekking

4 Agenda Den strategiske webutviklingsprosessen Brukerorientering Beskrivelse av de nye sidene CMS-løsninger Kravspesifisering Valg og vurdering Oppsummering

5 Den strategiske webutviklingsmodellen

6 Web skal skape verdi for to parter Bedriftens mål Web Brukerens mål

7 Nettredaktørens jobb Bedriftens mål Sikre verdi Brukerens mål

8 Web skal skape verdi for to parter Bedriftens mål Web Brukerens mål

9 Web skal skape verdi for to parter Bedriftens mål Web Brukerens mål Verdi Konsept Innhold

10 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

11 Målsettinger for web

12 Målsetting Bedriftens målsetting Brukernes behov

13 Forretningsmål Hva driver dere med? Hva er selskapets MISJON? Å selge varer? Å levere tjenester? Å yte service? Å fremme ideer?

14 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??

15 Strategi-pyramiden ordan? Strategisk Hvorfor gjør vi noe? Taktisk Hva gjør vi? Hvorfor? Operasjonelt Hvordan gjør vi det?

16 Dine mål bør være SMARTe Specific - konkrete Measurable - målbare Attainable - oppnåelige Results oriented - resultatorienterte Time based tidsbaserte

17 Eksempler på SMARTe mål Vi skal ha 12% økning i salg av lydbøker innen Alle kurspåmeldinger skjer elektronisk fra 1. mai Selvbetjent henting av kundeopplysninger fra lansering av min side 10% reduksjon i behandlingstid fra 1. august

18 Brukerbehov

19 Brukerbehov Bedriftens målsetting Brukernes behov

20 Analyse av brukers behov Webstatistikk Triggerord-analyser Scenarier/personas Brukertesting Brukerundersøkelser Bruker-workshop

21 Verktøy Statistikk Triggerordanalyser og Google Keyword Tool Brukerundersøkelser

22 Personas Arketyper som representerer brukerne dine Fiktive personer du oppretter, gir navn og demografisk beskrivelse

23 Personas Arketyper som representerer brukerne dine Fiktive personer du oppretter, gir navn og demografisk beskrivelse Tips: Steve Mulder, The user is always right

24 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

25 Personas Hvem er de typiske brukerne av ditt nettsted? (Tenk gjerne ut fra de viktigste bruksmønstrene)

26 Å 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?

27 Å lage Personas (1) Nybegynner Utenlandsk bruker Jevnlig bruker Proffbruker - + Kompetanselinje Fredrik Flittig Klara Klok Espen Egenrådig Nina Nøysom

28 Å lage personas (2) Ta utgangspunkt i de forskjellige brukergruppene nettstedet har Lag stiliserte brukergrupper basert på dette

29 Å 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

30 Å lage personas (3) Kilde:

31 Kilde: Webcredible.co.uk

32 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

33 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?

34 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?)

35 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

36 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.

37

38

39 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.

40 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.

41 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.

42 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

43 A og B- scenarier A- scenario B- scenarier B- scenario C-scenarier

44 Definere konsept Bedriftens mål Konsept Brukerens mål

45 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

46 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 )

47 Informasjonsarkitektur

48 Informasjonseiermatrise

49 Relevante regler Hvor ofte skal nyheter oppdateres? Hvordan skal vi sikre informasjonskvaliteten ( innholdsforvaltning / content governance )

50 Informasjon er ferskvare

51 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

52 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

53 Årshjulet

54 Årshjulet

55 Informasjonsarkitektur

56 Informasjonsarkitektur Skille mellom akser Skille mellom nivåer Bruke snarveier om nødvendig brukerbehovet trumfer alt annet!

57 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

58 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 )

59

60 Samme nivå

61 Samme nivå

62 Samme nivå

63 Samme hovedemne

64 Samme hovedemne

65 Samme hovedemne

66 Samme akse

67 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.

68 Emnemeny

69 Attributter som seleksjonskriterier

70 Attributtmeny

71 Hygienefaktorer

72 Wireframes

73 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)

74

75

76

77

78 Hva trenger du?

79 Verktøy Papir/blyant Powerpoint Mock-up-software

80

81

82 Elementer til wireframe Logo Menyer globale og lokale Nyheter? Varslinger? Markedsføringsfelt? Innholdsfelt Hva er A-scenariene?

83 Hvor mange wireframes? Forside Seksjonsforside Innholdsside Utlistingsside

84 Webpublisering

85 Hva trenger du for å lage en webside? Domene Webhotell (serverplass) HTML-kode

86 Hvordan får du til HTML-koden?

87 Hvordan får du til HTML-koden? Skrive for hånd Bruke en HTML-editor Bruke et publiseringsverktøy

88 1. Skrive for hånd

89 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.

90

91

92

93

94 Lyst til å lære HTML?

95 2. Bruke en HTML-editor

96 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.

97

98 Online HTML-editor Generator.aspx grei hvis du bare ønsker et lite stykke HTML på kjappen

99

100

101

102

103 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)

104 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)

105 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

106 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

107 CSS CSS er nå del av websidekoding, enten du gjør det manuelt eller via en publiseringsløsning Publiseringsløsning = CMS = Content Management System

108 3. Content Management Systemer

109 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

110 Pris for CMS Episerver, Sharepoint, 1 mill ++ Keyteq, Idium Portal Server, Designbyrå (lite/mellomstort), One.com, Idium Web, Wordpress, Joomla, Drupal gratis

111 Pris for CMS Episerver, Sharepoint, 1 mill Keyteq, Idium Portal Server, Designbyrå (lite/mellomstort), One.com, Idium Web, Wordpress, Joomla, Drupal gratis 2 9 Funksjonalitet s-poeng

112 Gratisløsningene Wordpress Joomla Drupal Lavest brukerterskel: Wordpress

113 Det kommersielle markedet

114

115

116

117

118

119

120

121

122

123

124

125

126 Adressene

127 Kravspesifikasjonen

128 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

129 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)

130 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.

131 Funksjonalitet Hva er relevant funksjonalitet?

132 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

133 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.

134 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.

135 C. Eventuelle migreringsbehov Hvordan skal innhold flyttes fra gammel til ny løsning? Hvis du har for eksempel 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.

136 D. Informasjonsarkitektur og wireframes Vis hva du har tenkt!

137 E. Krav til søkemotoroptimalisering Validert kode Overskrifter inn i title-tag Ingresser inn i meta-description Plattform/versjonsuavhengighet Mer..?

138 /

139

140 F. Krav til mobiltilpasning

141 Relevante mobilstrategier Responsive design Egne mobilsider Apps

142 Responsive design

143 Egne mobilsider

144 Apps

145 Apps For transaksjonsorienterte oppgaver For oppgaver som gjentar seg For oppgaver der mobil/nettbrett er naturlig verktøy

146 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.

147 F. Eventuelle wireframes Hvis du alt har tegnet wireframes, så legg dem ved kravspesifikasjonen. Det hjelper leverandøren å se hva du har tenkt.

148 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.

149 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

150 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.

151 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

152 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

153

154 A. Identifiser mulige leverandører Ambisjonsnivå og budsjettrammer? Eksisterende rammeavtaler? Eksisterende kundeforhold? Foreliggende positive og negative erfaringer? Referanser?

155 B. Send ut kravspesifikasjon Husk å sette en frist for anbud Vær forberedt på at noen ikke har tid og anledning til å besvare

156 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)

157 D. Sammenlign tilbud Sett om en sammenligningsmatrise med utgangspunkt i din kravspesifikasjon Beregn gjerne funksjonalitetspoeng Beregn gjerne kost per funksjonalitetspoeng

158 Sammenligningsmatrise

159 Sammenligningsmatrise med funksjonalitetspoeng

160 Kost per funksjonalitetspoeng (KPF) Pris Antall funksjonalitetspoeng = KPF

161 Utdrag fra saksframlegg, tilbudsevaluering for kunde

162 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)

163 F. Informer vinner og tapere Det er greit om også de som ikke vant anbudet får beskjed om at leverandør er valgt.

164 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!

165 Informasjonseiermatrise

166 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

167 7. Vedlikehold og så var det alt det andre arbeidet

168 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

169 Presentasjonen

170 Lykke til, og takk for meg! Nina Furu Mobil