Hvorfor UX-designere bør kunne innholdsmodellering
Innholdsmodellering gjør innhold gjenbrukbart og øker brukervennligheten. Det forenkler arbeidet for redaktører, åpner for nye funksjoner, og forbedrer samarbeidet mellom designere og utviklere, noe som gir mer effektive og intuitive digitale løsninger.
Innhold
Fordelene med en god innholdsmodell
Hva er innholdsmodellering?
Ulike innholdstyper i en modell
Hvem bør modellere?
Kom i gang
Fordelene med en god innholdsmodell
- En god innholdsmodell gir mer brukervennlige publiseringsløsninger for innholdsredaktører, slik at de enklere kan produsere bedre innhold for sluttbrukere.
- Bruksverdien av innholdet øker ved å konvertere innholdet til strukturert data som er tilgjengelig og gjenbrukbart i flere relasjoner, kontekster og flater.
- Riktig strukturert data åpner opp for nye funksjoner og tjenester for systemets brukere, og skaper unike strategiske fordeler ved å opprette nye relasjoner mellom eksisterende innholdstyper.
Hva er innholdsmodellering?
Vår definisjon av innhold
Når vi snakker om innhold i et digitalt system, som for eksempel en nettbutikk, tenker vi først og fremst på bilder, beskrivelser, priser og annen generell informasjon – all informasjon som er lagt ut på nettsiden for å hjelpe deg med å få oversikt over produktene og gjøre kjøpsbeslutninger. Men innhold er mer enn det.
Innholdet inkluderer også den mer skjulte informasjonen, som produkt-ID, eksakt lagerbeholdning, nettleseren din sin posisjon, og når du sist var innlogget på nettstedet. Innhold omfatter også alle de visuelle elementene som utgjør selve brukergrensesnittet på nettbutikken, fra hovedmenyen og brødsmulestien til bildekaruseller, knapper, merkelapper, informasjonstekst og alle andre elementer du ser og samhandler med.
Dette innholdet er nøye utvalgt av noen, og i mange tilfeller kan det kontrolleres og endres av redaktører på nettsiden – og til og med av sluttbrukerne selv, som på sosiale medieplattformer som Instagram eller Facebook.
For å prøve oss på en litt mer teknisk definisjon: Innholdet i et digitalt system består av alle datapunkter og visuelle elementer som utgjør både front-end (sluttbrukergrensesnitt) og back-end (administrasjonsgrensesnitt) av systemet.
Hva er modellering?
En modell er en realistisk gjengivelse av noe. "Modellering" er prosessen med å planlegge og utforme denne gjengivelsen. I vår sammenheng, innholdsmodellering, handler det om å skape en representasjon av hvordan innholdet er strukturert i systemet – en gjengivelse som helst bør speile den virkelige verden.
Troverdige gjengivelser, basert på virkeligheten, er et grunnleggende prinsipp i innholdsmodellering. Målet med modelleringen av innhold er å organisere det på en måte som er meningsfullt for folk flest, og å tydeliggjøre forholdet mellom ulike typer innhold. Derfor er det avgjørende at modelleringen tar utgangspunkt i noe vi alle kjenner godt, som den faktiske verden rundt oss, fremfor å fokusere kun på databasestrukturer eller annen teknisk logikk i det verktøyet innholdet skal implementeres i (se Forskjell på innholdsmodell og datamodell).
Modellering er med andre ord designprosessen hvor innholdet i et digitalt system (informasjon og visuelle elementer) blir strukturert og organisert slik at det gir mening for alle brukere av systemet, både sluttbrukere og administratorer.
Forskjell på innholdsmodell og datamodell
Der hvor innholdsmodellen bør ta utgangspunkt i den virkelige verden slik at den blir forståelig for folk flest, vil en datamodell ofte være mer optimalisert for en effektiv databasestruktur som ivaretar dataintegritet og tekniske krav. Nøkkelen ligger i å skape modeller som ikke stikker kjepper i hjulene for hverandre, men speiler hverandre i størst mulig grad.
Videre vil en datamodell som regel ha flere attributter, eller egenskaper, enn innholdsmodellen – det motsatte er ikke mulig. La oss ta et eksempel: innholdsmodellen til et bilde vil typisk ha følgende attributter:
Den tilsvarende datamodellen kan se slik ut:
Som vi ser, har innholdstypen “Bilde” flere attributter i datamodellen enn i innholdsmodellen. I dette eksemplet kan man velge å trekke inn flere av attributtene fra datamodellen til innholdsmodellen, slik som f.eks. opprettelsesdato eller filstørrelse, dersom det gjør systemet bedre og/eller lettere å bruke.
Ulike innholdstyper i en modell
En innholdsmodell består som regel av innholdstyper, deres attributter/egenskaper, samt relasjonene mellom dem. Vi opererer som regel med tre innholdstyper; objekter, sidetyper (dokumenter) og komponenter. Det kan ofte være en overlapp mellom de ulike typene og det er ikke alltid åpenbart hvilken type som passer best for det aktuelle innholdet du jobber med.
Teknisk sett er det heller ikke noen forskjell på de ulike innholdstypene (ofte omtalt som schema blant utviklere), da de er bygget opp av de samme grunnsteinene. Å skille mellom disse typene er forøvrig ofte nødvendig fordi plattformen systemet skal utvikles på (for eksempel Sanity) krever at utvikleren velger en spesifikk innholdstype når den opprettes. Derfor bør også typen defineres tydelig i modellen.
Sidetyper
Dette er en innholdstype som speiler innholdet på en spesifikk side på et nettsted eller en applikasjon. Den enkleste måten å bygge opp innholdsmodellen for en sidetype er å skissere ut hvordan du vil at siden skal se ut, og deretter gi navn til alle elementene på siden. Her er et eksempel på hvordan innholdsmodellen til en artikkel kan se ut.
Objekter
I eksempelet over ser vi at det refereres til fire andre innholdstyper; Bilder, Forfattere, Kategorier og Merkelapper. I vårt tilfelle er det ingen av disse fire innholdstypene som skal presenteres som en egen side. Disse innholdstypene kan vi derfor kalle for objekter.
Objekter er innholdstyper som inneholder informasjon som brukes rundt omkring i systemet, som egenskaper til andre objekter og sidetyper, uten å ha en definert måte informasjonen vises på. En tommelfingerregel er at dersom en egenskap til en innholdstype skal benyttes flere ganger i andre sammenhenger, så kan det skilles ut som et eget objekt. På den måten unngår man å måtte oppgi den samme informasjonen flere ganger i samme system.
En objekttype brukes nesten alltid som en referanse til andre innholdstyper, og vil i de fleste tilfeller være meningsløs uten å settes i sammenheng med noe annet. For eksempel er Merkelapp (tag) en innholdstype som benyttes for å kategorisere og gruppere artikler, bilder, produkter etc. Merkelappen isolert sett er ikke alltid meningsbærende, men satt i sammenheng med et produkt eller artikkel så gir den mening.
Tenk for eksempel merkelappen “bærekraft”. Denne merkelappen kan benyttes for å gruppere et bilde av et gjenvinningsanlegg, en bukse laget av organisk bomull og en artikkel om sirkulærøkonomi. Ved å benytte det samme objektet hver gang noe skal merkes med “bærekraft” åpner man muligheten for å filtrere og presentere innhold på spennende og relevante måter for brukerne.
Objekter kan være enkle, med kun én egenskap eller to, slik som objekttypen Merkelapp (kun tittel). Andre objekter kan være mer omfattende, slik som forfatter:
Komponenter
Ordet “komponenter” brukes om forskjellige ting i ulike sammenhenger. I vår sammenheng benytter jeg “komponenter” om visuelle elementer som utgjør byggeklossene for det grafiske grensesnittet i den digitale løsningen.
Det å trekke visuelle komponenter inn i en innholdsmodell er nok ikke veldig vanlig, men det viser seg svært nyttig. Årsaken til det er todelt: For det første forenkler det implementeringen av det grafiske grensesnittet (front end) fordi modellen bidrar til å forklare hvordan den grafiske komponenten fungerer, hvilke varianter den har og hvor informasjon hentes for å fylle komponenten med innhold.
For det andre bidrar modelleringen til å gjøre det enklere å lage et logisk grensesnitt og god brukervennlighet for redaktørene i publiseringsløsningen.
En typisk komponent kan eksempelvis være et kampanjebanner som skal benyttes ulike plasser på et nettsted. Innholdsmodellen til et slikt banner kan se slik ut:
Hvem bør modellere?
Standard arbeidsflyt i arbeidet med å designe og utvikle nye digitale løsninger skjer ofte på følgende måte:
Designeren skaffer seg innsikt om oppdragsgiver og deres kunder (sluttbrukerne) og jobber sammen med oppdragsgiver for å definere hvilke oppgaver løsningen skal hjelpe brukerne med.
Basert på denne innsikten starter utforming av den digitale løsningen som vanligvis resulterer i en serie med skjermbilder som viser hvordan den digitale løsningen skal se ut. I mange tilfeller settes skjermbildene sammen til en klikkbar prototype som både sluttbrukere og oppdragsgiver kan teste før designeren overfører prosjektet til utviklerne for implementering.
Parallelt med designarbeidet har utviklerne på sin side kartlagt tekniske spesifikasjoner, behovet for integrasjoner med tredjepartssystemer, etc. De har som regel definert hvilken teknisk plattform systemet skal bygges på og begynt arbeidet med å sette opp rammeverket for valgt plattform og eventuelle integrasjoner/API’er.
Når utviklerne mottar ferdige designskisser starter arbeidet med å dekode designen og komponentene, forstå hvor data som presenteres skal hentes fra, kartlegge alle varianter en komponent kan ha og finne en god måte å gi innholdsredaktører og administratorer redigeringskontroll over innhold og komponentvarianter.
Dette er ingen enkel jobb. Særlig dersom designeren ikke er tilgjengelig for spørsmål og sparring. Ofte kan det ende med en gjettelek hvor utvikleren ser seg nødt til å anta hva som er designerens intensjon, og i svært mange tilfeller må designen endres litt for å få den til å passe med plattformens datamodeller og eventuelle begrensninger.
Designer kan ha ansvar for innholdsmodellen
For å unngå gjetteleken hvor utvikleren bruker tid på å tippe hva designeren har tenkt, kan jeg sterkt anbefale at designeren bidrar i stor grad på innholdmodelleringen. Dette har tre åpenbare fordeler:
Den første grunnen til at designeren bør jobbe med innholdsmodellering er at det gir designeren bedre forståelse for kompleksiteten som mange utviklere står i hver dag. Vi designere har en tendens til å utforme komponenter og logikk som ikke alltid er effektivt og/eller hensiktsmessig sett fra en utviklers ståsted. Ved å jobbe med innholdsmodelleringen får vi et blikk inn på den andre siden, og dermed øke vår evne til å ta hensyn til hvordan det hele skal henge sammen.
For det andre forenkler det kunnskapsoverføringen fra designer og utvikler. Når designer beskriver et grafiske grensesnittet ved hjelp av innholdsmodeller, blir det lettere å kommunisere funksjonalitet som ikke ligger implisitt i det grafiske grensesnittet. Det blir rett og slett mindre informasjon “lost in translation” og mye mindre gjetting for utvikleren
Det tredje punktet handler om brukervennlige publiseringsverktøy. Selv om mange utviklere behersker den nærmest umulige balansegangen med å både skrive effektiv kode som snakker godt med datamaskiner, og samtidig utvikle administrasjonsverktøy som er enkle å bruke for ikke-tekniske redaktører, så ligger egentlig design av administrasjonsverktøy midt i kjernen av hva UX-designere skal ha ansvar for. Innholdsmodellering er uten tvil den øvelsen som har størst betydning for logikken og brukervennligheten i systemadminstrasjonen, og ansvaret kan derfor med fordel ligge i designerrollen.
Utviklere har ansvar for datamodellering
En av grunnene til at innholdsmodellering tradisjonelt sett ikke har vært et designeransvar, kan ha sammenheng med at utvikleren i alle tilfeller må gjøre datamodellering. Datamodellene skal imøtekomme de tekniske kravene til de teknologiske løsningene som benyttes og har derfor ikke menneskelige behov som første prioritet. Det betyr selvsagt ikke at datamodeller ikke er forståelig for mennesker, men at datamodellen viktigste oppgave er å ivareta forretninglogikken, ikke sluttbrukeren.
For designeren som jobber med innholdsmodellene er det viktig å kommunisere godt med utviklerteamet slik at datamodeller og innholdsmodeller følger mer eller mindre samme logikk, og at den ene modellen ikke setter kjepper i hjulene på den andre.
Brukerne vet best
Til syvende og sist er det verken designerne eller utviklerne som skal bruke systemet vi jobber med. Brukerne av systemene sitter alltid på fasiten om hvilken logikk som må ligge til grunn, hvilken informasjon som må være synlig eller skjult og hvilke relasjoner man må ta høyde for. Jeg forsøker å involvere oppdragsgiver og redaktører underveis i innholdsmodelleringen for å få en forståelse for hvordan de tenker om innholdet, terminologi, logikk og hvilke oppgaver de trenger å få løst.
Samarbeidet mellom designer, utvikler og redaktør bidrar til å forme robuste og skalerbare innholdsmodeller. Modeller som gir fleksible og brukervennlige publikasjonsløsninger, strukturerer data effektivt og åpner muligheten for å benytte data på nye, innovative måter.
Kom i gang
9 spørsmål før du begynner
- Hvilke data har vi fra før og hvor kommer det fra?
- Hvilket type innhold har vi lyst til å lage, samle inn eller skaffe?
- Hvilket type innhold og funksjonalitet har sluttbrukerne behov for?
- Hvordan jobber redaktørene og innholdsprodusentene?
- Hvilke mentale modeller har innholdsprodusenter og sluttbrukere?
- Hvordan skal innholdet redigeres?
- Hvilken struktur/modell gir best fleksibilitet? Hva er egenskaper og hva er relasjoner?
- Finnes det eksisterende innholdsmodeller vi må forholde oss til?
- Gir teknologien vi skal bruke noen føringer for utforming av modellen?
Start med den viktigste innholdstypen
Det er mange måter du kan starte innholdsmodelleringen på. Noen ganger er det nyttig å starte med å lage bokser med alle innholdstypene du har funnet i innsiktsarbeidet ditt. Disse boksene kan du deretter kategorisere, flytte rundt på og tegne relasjoner i mellom. Når dette er på plass kan du deretter gi egenskaper til hver enkelt innholdstype.
Min foretrukne måte å modellere innhold på er ikke å kartlegge alt før jeg legger til egenskapene og relasjonene, men heller starte med systemets viktigste innholdstype. I store komplekse system vil det nok ikke alltid være så enkelt å si hva som er viktigst, men som regel stikker det seg ut en type innhold som føles riktig. Det er forøvrig ikke veldig viktig hvilket innhold du starter med, så lenge du kommer i gang.
La oss ta et eksempel. Du skal lage en digital «hva skjer»-kalender for kommunen der du bor. Det viktigste innholdet i en slik kalender er sannsynligvis aktivitetene eller hendelsene i kalenderen. La oss kalle innholdstypen «Aktivitet». Videre kan vi, basert på vår kunnskap om aktivitetene som skal inn i kalenderen, definere noen fellestrekk for alle aktiviteter. De har en Arrangør, en Type arrangement, Tid for aktivitetsstart og et Sted hvor aktiviteten skal avholdes. Videre trenger aktiviteten en Beskrivelse, et Bilde og mulighet for Lenke til billettsalg.
Innholdsmodellen for Aktivitet ser foreløpig slik ut:
Og det er nå moroa begynner. Når vi nå ser på de ulike attributtene, ser vi at flere av dem med fordel kan være egne objekter. Arrangør, Type arrangement og Sted er attributter som vil kunne brukes på flere aktiviteter. Så la oss starte med Arrangør. Vi vet at arrangørene skal ha en eget presentasjonsside på den digitale løsningen hvor alle deres aktiviteter er samlet. Derfor trengs litt utfyllende informasjon
Neste innholdstype er Sted. De fleste aktiviteter foregår på steder som leies ut til ulike aktiviteter og det derfor nyttig å ha en egen innholdstype for disse slik at informasjonen blir konsekvent og at administratorer ikke trenger å legge inn all informasjon på nytt hver gang.
Til slutt ønsker vi at Type aktivitet skal være strukturert, altså at administratorene ikke legger inn type aktivitet med fritekst hver gang, og dermed fratar systemet muligheten til å filtrere og kategorisere på Type. Her er det to måter å gå fram. Vi kan lage en egen innholdstype for Type aktivitet eller vi kan la typen aktivitet kun være en unik egenskap i innholdstypen Aktivitet. Det siste alternativet vil fjerne muligheten for at andre innholdstyper kan benytte kategoriseringen. I dette tilfellet er det greit å la Type aktivitet være en unik egenskap i stedet for en referanse til et eget objekt.
Aktivitet med refererende innholdstyper vil da se slik ut:
Når du har jobbet litt med modelleringen kan du med fordel gå over til å skissere ut enkle trådskisser av det grafiske grensesnittet. Ved å hoppe fram og tilbake mellom arbeidsmetodene blir det lettere å komme seg videre i arbeidet. Personlig pleier jeg å skifte metode når jeg ikke lenger klarer å jobbe i flyt.
Etterhvert vil det dukke opp behov for å få mer innsikt for å komme videre. Da er det viktig å ikke jobbe basert på dine egne antakelser, men faktisk trekke inn nødvendig kompetanse, enten fra oppdragsgiver, sluttbruker eller utvikler. Og i noen tilfeller alle på en gang. Ikke vær redd for å vise fram uferdig arbeid. Det er da det er enklest å gjøre endringer og forbedre løsningen.
Lykke til med modelleringen!
Har du kommentarer, spørsmål eller trenger hjelp til å komme i gang? Ta kontakt med daglig leder og rådgiver Morten M. Wikstrøm
Hva kan vi hjelpe deg med?
