Opfordring: Snak struktur, før I bygger et nyt website

I springer over, hvor gærdet er nærmest ikke-eksisterende, hvis I styrer uden om at drøfte struktur. Strukturen er nemlig noget af det første og vigtigste at forholde sig til i udviklingen af et nyt website.   

I denne artikel tillader vi os at nørde lidt. Vi kommer med eksempler på, hvordan tid og ressourcer kan blive brugt i blinde – og på det modsatte, når man starter med at tage den vigtige snak om struktur.

Målet er, at du om et par minutter sidder med inspiration til, hvordan I kan styre uden om faldgruberne, når I skal have et nyt website.

Wireframes gør det kommende website visuelt

Vi er i virkeligheden startet lidt midt i det hele. Der er mange opgaver i udviklingsprocessen, før vi kommer til den konkrete struktur: Brugerundersøgelser, UX strategi, user journey mapping, sitemap og UX scope for at nævne nogle af dem. Dem kommer vi ikke ind på her, men du er velkommen til at bladre gennem vores artikler og læse mere.

Vi bruger en god håndfuld redskaber, når vi skal have websitets kommende struktur på plads og før det egentlige kodearbejde kan begynde. Et af de vigtigste redskaber er wireframes, så vi kan se på opbygningen af websitet, før vi går i gang med at designe og kode det.

Wireframes giver et visuelt overblik over, hvad der skal være på sitet. Vi sketcher først en wireframe i hånden. Dernæst sætter vi strøm til. Den gode wireframe indfanger og viser arbejdet med bl.a. sitemap og informationsarkitektur – og den kan sagtens være klikbar. Arbejdet på wireframe indleder som regel en snak om, hvilke funktionaliteter der skal være på sitet, og hvordan disse skal opbygges.

Men hvorfor bruger vi så meget tid på at snakke om strukturen af websitet før vi går i gang? Nogen vil måske tænke: “Det er jo bare en hjemmeside, kan vi ikke bare se at få den i luften?”

Lad os se på et eksempel.

Eksempel: ”Lad os spare tid og droppe de der wireframes”

Det er med websites som med så meget andet. Tid og kvalitet hænger sammen. Når en enkelt del fjernes, så har det konsekvenser. Alligevel er der mange, der kan tænke:

”Vi skal jo bare lige hurtigt have en hjemmeside. Kan vi ikke spare tid ved at springe wireframe-fasen over?”

Jo, det kan vi godt prøve. Vi sætter designeren i gang og han får frit slag til at gøre, hvad han vil. Designet han leverer ligner jo en hjemmeside og det ser ganske flot ud. Så alt er vel fint?

Udviklerne får designet og går i gang med at opsætte det efter designfilerne. I dette eksempel kigger de på designet, da de ikke har wireframes. De kommer derfor selv frem til følgende struktur:

Udviklerne går i gang med at kode websitet, og efter noget tid meddeler de, at de er færdige med at kode det hele. Tiden er moden til at teste og indsætte content.

Indholdsredaktørerne går i gang med at opsætte indhold på websitet. De finder ud af, at de har behov for at kunne indsætte en kontaktformular på artikelsiderne, da disse sider kan bruges til salgsaktiviteter.

Udfordringen er blot at artikelsiden er låst fast, og derfor kan der ikke indsættes moduler. Så udviklerne skal på banen igen.

Læs også: Lær dine brugere at kende og understøt den gode user experience

Den gode løsning versus den hurtige løsning

Der er flere måder at fikse vores opståede udfordring på. Løsningerne kan inddeles i to kategorier: Den gode løsning og den hurtige løsning.

Den gode løsning er at udvikle et fix, der er gennemtænkt i forhold til strukturen. Det gør den oftest mere fremtidssikret, hvis der skulle komme andre ændringer i fremtiden.

I vores eksempel er den gode løsning på nuværende tidspunkt at kode artikelsiderne om, så de i stedet for en låst skabelon består af en dynamisk skabelon i stil med standardsiderne.

Desværre har indholdsredaktørerne allerede været i gang. De har oprettet en masse fedt content, og løsningen betyder, at de ville skulle opsætte alt indhold forfra.

Den hurtige løsning er at løse problemet her og nu, og så tage eventuelle udfordringer i fremtiden. Med den hurtige løsning koder vi kontaktformularen ind i vores artikelside. Så er kontaktformularen altid en fast del af artikelsiden. Indholdsredaktørerne beholder det indhold de allerede har oprettet og skal ikke oprette det forfra.

Med afsæt i den hurtige løsning er alt godt igen. Indholdsredaktørerne kan fortsætte arbejdet og indsætter mere indhold. Efter lidt tid kommer de frem til en ny konklusion:

Det ville være smart, hvis man kunne have en blok med relaterede artikler i bunden af en artikelside. Igen skal vi beslutte, hvordan udviklerne skal forholde sig: Hvilken løsning på det nye problem bør vi gå efter? Den hurtige og kortsigtede eller den gode og langsigtede?

Læs også: Derfor falder tilfredsheden over tid: Det er Kano-modellen, der er på spil

Undgå lappeløsninger med struktur og planlægning

Som eksemplet viser, så ender vi hurtigt i ærgerlige lappeløsningssituationer, hvis ikke vi planlægger og gennemtænker websitets struktur, før vi går i gang.

Vi har ganske vist sparet tid på ikke at wireframe og strukturere vores arbejde, men vi ender i sidste ende med at bruge alt for meget tid på at lappe hullerne som vi ikke tog højde for. Så i stedet for at spare, har vi i virkeligheden brugt langt mere tid end planlagt.

Lappeløsninger er desuden sjældent fremtidssikrede. Det betyder, at det tager længere tid at fikse tidligere fejl og mangler, når vi fx skal lancere version 1.1 af websitet. Flere nye features skal indarbejdes rundt om lappeløsningerne, samtidig med at de ikke skal skabe nye problemer.

Den indledende idé om at spare tid bunder ikke nødvendigvis i uvilje, men i manglende forståelse for, hvad de enkelte dele af udviklingsprocessen betyder for arbejdet, for resultatet og for den efterfølgende drift.

Forestil dig en skrædder, der må klare sig uden saks og symaskine – det har betydning for processen og for det endelige stykke tøj.

Læs også: Tre vigtige overvejelser til UX og design

Et hurtigt eksempel fra egne rækker

Lad os runde af med et eksempel fra vores eget arbejde, hvor en hurtig løsning resulterede i mere arbejde. På vores eget website har vi følgende element i bunden af websitet, der fremhæver vores kernekompetencer:

Indholdsredaktørerne efterlyste muligheden for at indsætte en ekstra tekst, så der er fire på række i stedet for tre. Det var fredag eftermiddag, der var travlt med kundeopgaver og undertegnede tænkte: “Jeg laver da bare lige et hurtigt fiks og så er alle glade”. Resultatet så fint ud:

Jeg gik glad hjem på weekend.

Da jeg kom ind på kontoret mandag morgen var der en ny bugrapport til mig. Gorm.agency har nemlig samme kodebase som tyra.codes websitet, hvor vi fremhæver vores udviklingsarbejde. Mit lille, hurtige fiks gjorde, at TYRAs footer så forkert ud:

Konklusionen er vist til at få øje på.

Tiden jeg sparede på at lave den “hurtige” løsning var spildt, og jeg kunne efterfølgende bruge tid på at bygge den gode løsning, så footer-elementet virkede på begge sites.

Vil du læse mere om, hvordan udviklingsprocessen ser ud her hos GORM Agency? Så finder du det på denne side.