I nästan alla upphandlingar av webbplatser finns det krav på att dokumentation ska finnas. Det finns egentligen inga andra krav än just att dokumentation ska finnas. Vilket är ett stort problem.
I webbprojekt brukar det finnas två olika typer av dokumentation, det är Systemdokumentation och Användardokumentation. När man i upphandlingen skriver att det ska finnas dokumentation så är min erfarenhet att kunden ofta menar Användardokumentation. Tyvärr tolkas det oftast inte så, utan det som ofta levereras är en systemdokumentation. Det är inget fel på systemdokumentation, den behövs ofta den också. Det tråkiga är om kunden förväntar sig en användardokumentation och inte får det för att man varit vag och upphandlat “dokumentation”.
Många gånger känner jag att både utbildning och dokumentation är något som alla “vet” att man ska ha, men få har funderat på vad det ska leda till. Många tycker att det räcker att man har en dokumentation och att redaktörer har gått en utbildning. Om utbildningen har gett ny kunskap eller om dokumentation är användbar så att den leder till ny och bibehållen kunskap, det är mindre viktigt. Man vill snarare kunna sätta en bock i kanten, istället för att titta på uppnått resultat. Det finns stor risk att det leder till att man kastar pengarna i sjön. Varför ska 10–30 personer lägga en dag på utbildning, som inte ger dem den kunskap som de behöver?
När vi på 7minds jobbar med Användardokumentation så lägger vi extra stor vikt vid att den ska lösa de problem som man som redaktör ställs inför. Den ska vara lösningsbaserad istället för en lista över funktioner i ett system. Majoriteten av all användardokumentation som skapas idag är snarare en beskrivning av varje funktion i en apparat eller ett program. Vad spelar det för roll om jag kan läsa mig till vilken knapp jag ska trycka på om jag inte förstår vad jag ska ha funktionen till.
För oss består en bra användardokumentation av följande delar:
- En inledande beskrivning av varför en viss funktion ska användas. Ofta baserad på scenario där man ska lösa en viss uppgift eller ett problem. Det kan innebära att vi involverar flera funktioner.
- En bild på vad resultatet av scenariot kommer att resultera i.
- En steg för steg-beskrivning på hur man ska göra för att uppnå resultatet. Råkar det vara så att man behöver tre funktioner för att uppnå scenariot finns hela vägen beskriven.
- En film som visar hur man gör de olika momenten.
Många av de användardokumentationer som vi sett på anpassade webbplatser byggda på EPiServer innehåller enbart de anpassade delarna. De beskriver normalt de mallar som är byggda för lösningen, men helt utan koppling till standardfunktioner. En mall består oftast av en massa standardfunktioner, såsom exempelvis länkar, bilder och dokument. Vad ska jag som redaktör göra om det står i den anpassade dokumentationen att jag ska lägga till en bild i visst fält, när jag inte har en aning om hur man laddar upp en bild? Då hänvisas redaktören normalt vidare till den produktspecifika dokumentationen.
För att en enskild redaktör ska kunna hitta rätt hjälp för ett visst problem så behöver denne därför veta vad som är standard och vad som är anpassat. Det är en mer eller mindre en omöjlig uppgift för en redaktör som enbart sett en lösning. Har man fler produkter såsom ImageVault, Siteseeker, Composer, EPiServer Mail osv. så blir det ännu svårare. Hur ska man veta i vilken dokumentation man ska söka information om man inte vet att det är olika produkter?
För oss är det en självklarhet att man har en samlad dokumentation för alla produkter, som är uppdelade efter de problem som de löser, inte efter vilken produkt som de utförs i.
Vi tycker att upphandlingar runt nya webbplatser ska förändras. Mjuka frågor såsom effektstyrning, redaktörsfunktioner, utbildning och användardokumentation behöver inte alls ha med teknik att göra. Det finns ingenting som säger att den som är bra på att utveckla webbplatser är bra att utbilda redaktörer. Idag är det många som tar en byrå som gör design och en annan för att göra teknik i form av integrationer och annat, men utbildningsfrågan får ofta lösas av samma leverantör. Det finns självklart dem som gör det bra, så det är inget fel med det. Det viktiga är att du som gör upphandlingen ställer krav på innehåll, kvalitet och vilka effekter dokumentationen och utbildningen ska uppnå! Då tror jag att ditt urval av lämpliga leverantörer kommer att minska.