Alle indlæg af Mads-Peter

Centralisering af webredaktionen

Det er et klassisk dilemma. Skal man have en centraliseret eller decentraliseret webredaktion? Den faglige viden og daglige kontakt med brugerne sker i afdelingerne, mens dem, der virkelig kan skrive, typisk sidder i en web- eller kommunikationsafdeling.

I et CMS som Sitecore, der ikke bare er brugervenligt, men hvor man også har mulighed for at lave roller, der kun har adgang til at redigere enkelte dele af websitet, har man alle værktøjerne for at lave decentrale webenheder, der selv kan administrere deres egen del af websitet.

centralisering af webredaktion eller indholdsstrategi?

Omvendt kan det være svært at sikre konsistens og forretningsdrevet indhold, der er baseret på relevante brugsscenarier – også selvom brugeren skal orientere sig i indhold, der er skrevet af redaktører, der ikke nødvendigvis har samarbejdet.

Content Strategy er kommet på alles læber. Og med et forretningsunderstøttende fokus bliver indhold på et website næsten nødt til at være orkestreret centralt.

Centraliser overblikket – ikke indholdsproduktionen

Men måske er det netop her, der er så mange, der går galt i byen. Man skelner udelukkende mellem central og decentral organisering. Måske bør man i stedet centralisere overblikket og bevare indholdsredaktionen decentralt. Måske bør vi placere en ansvarlig centralt, hvis opgave ikke er at lave indhold, men at have overblikket.

En af nøglerne til godt indhold er, at man ved, hvilket indhold man har, og hvilken rolle det spiller i de brugsscenarier (eller måske ligefrem user journeys), man understøtter på sin platform. Derfor kan det også give god mening at have en central indholdsstrategisk person eller gruppe siddende til at beslutte og sikre

  • hvilket indhold der bør være for at understøtte forretningen
  • hvordan indhold bør skrives/skabes
  • hvilke kanaler der skal anvendes til hvilket indhold
  • de brugsscenarier der skal understøttes
  • den organisatoriske forankring og forretningsdrevne støtte af indholdsproduktion og -vedligeholdelse
  • at de decentrale redaktører har den relevante viden og de mest effektive værktøj til at løse deres opgaver

Selvom godt indhold kræver central styring, giver det stadig god mening, at de enkelte fagområder eller afdelinger kan anvende den viden, de har om netop deres område og deres brugere for at sikre, at indholdet bliver så relevant og anvendeligt for brugerne som muligt.

Klik-optimering i forbindelse med SEO

Måske ligger du højt på Google. Men udnytter du gevinsten af at ligge højt, eller får dine konkurrenter flere besøgende end dig?

Click Through Rates (CTR) betegner andelen af de brugere, der er blevet eksponeret for et link/kampagne/søgeresultat, og faktisk har klikket på det. Hvis jeg har en reklame, der bliver vist for 100 mennesker, og jeg kan få 10 til at klikke, har jeg en CTR på 10%.

Når man taler om CTR, er det typisk i forbindelse med kampagner såsom adwords. Men det kan være mindst lige så relevant at tale om CTR i forbindelse med organisk søgemaskineoptimering.

Fordi de fleste ved, at der er en sammenhæng mellem websitets placering i Googles søgeresultat og trafikken, der drives til websitet, er det nemt at tro, at “jo højere, jo bedre” trumfer alt ift. SEO. Så længe jeg ligger øverst, er alting godt.

Men så tager man fejl.

Det er sandt, at der er en stærk sammenhæng mellem placering og trafik, men placeringen (eller ranking) er bestemt ikke et altdominerende parameter. Hvis du har Google Analytics på dit website, og du har knyttet din Google Analytics sammen med Google Webmaster Tools, så kan du få syn for sagen.

Se hvor du bør forbedre din SEO CTR

I Google Analytics skal du under “Aquisition” (eller “Konvertering” på dansk) gå ind under “Search Engine Optimization”/”Søgemaskineoptimering” og derefter åbne “Queries”/”Forespørgsler”.

I screendumpet nedenfor kan du se, hvordan jeg har lavet et avanceret filter, der gør, at kun forespørgsler, hvor CTR er dårligere end 2%, hvor placeringen i Google er bedre end 3, medtages. Med andre ord får jeg en lang række resultater, hvor jeg ligger blandt de øverste i Google, men alligevel kun formår at få to ud af hundrede til at klikke.

Optimer din description for at optimere din traffik fra Google med CTR optimering

 

 

Hvis du samtidig arrangerer efter eksponeringer, får du endda prioriteret din liste, så de forespørgsler, hvor du går glip af mest trafik, kommer øverst.

Du skal anskue denne rapport som din todo-liste. Start fra toppen, og for hver forespørgsel skal du så

  1. Lave en søgning på forespørgslen
  2. Orientere dig om, hvordan dit link præsenterer sig. Hvilken overskrift og hvilken beskrivelse bliver knyttet til dit link i Googles søgeresultat?
  3. Se, hvad de øvrige links i top 5 på søgeresultatsiden gør. Virker deres sider mere relevante? Lokker de bedre? Er der noget, du kan lære?
  4. Optimere din titel og description, så du får det mest indbydende link i søgersultatet.
  5. Vent på, det slår igennem i søgeresultatet.

Hvordan laver man CTR-optimering ifm. SEO?

Uanset hvordan du arbejder med CTR-optimering, er der et princip, der bør dominere: Giv brugeren det, de spørger om.

Lad os sige, vi har en lampeforretning, og vi er i gang med at optimere til søgeforspørgslen “billige lamper”. Så vil det være ærgerligt at bruge de få linjer i titel og description på at fortælle om, hvor vi bor, hvor mange års garanti vi tilbyder, eller hvor hurtigt vi kan levere. I stedet bør vi fokusere på, at man kan købe billige lamper. Prøv derfor at angå descriptions, der er meget passive, som f.eks. “20 års erfaring med designerlamper. Vælg mellem indendørslamper, udendørslamper, …

I vores tænkte eksempel vil det være oplagt at have en description-tekst, der beskriver, hvad man kan opnå. Hvis der et sted i teksten står ordet “billige lamper”, er vi nok på rette vej. Men vi skriver stadig ikke eksplicit, hvad man får ud af at klikke på linket. Et bud kunne være at skrive “Se vores store udvalg af billige designerlamper” eller måske endnu bedre “Køb designerlamper til engrospriser. Gratis levering“.

CTR er ikke kun for SEO

Når man arbejder med web, vil man meget ofte opleve, at man skriver tekster, der har til formål at få brugeren til at klikke på et link. Brancher og brugere er forskellige. Sørg for at få målt på, hvad der virker for dit website, og del din viden med dine kolleger.

Det er ærgerligt at skulle tilbage og rette en masse tekster. Så hvis I samtidig kan opsamle viden om, hvad der får folk til at klikke, kan I måske indarbejde det i jeres arbejdsmetoder og dermed komme på forkant med optimeringen.

God optimeringslyst!

Gæsteindlæg om dyr prioritering

Du kan nu læse mit indlæg på Pentias blog, pentia360.dk, om hvorfor prioritering er vigtigt, selvom det ikke er nemt.

Og med en kamp om at komme først til møllen bliver resultatet mudrede løsninger, hvor brugeren ikke får en klar rute gennem et website.

Det svarer til, at man kommer ind radio/tv-butik for at købe et tv, og inden man er kommet ned til væggen af fladskærme, bliver man angrebet af forskellige sælgere, der vil sælge en nespresso-maskiner, gaming-headsets og serviceaftaler. I nogle tilfælde virker det.

Men personligt ville jeg nok vælge at handle i en anden butik.

Læs hele mit blogindlæg om prioritering ifm. informationarkitektur på Pentia360.

Responsive Design er ikke vigtigt

I Pentia har vi over de seneste år 2-3 år lavet et hav af websites, der tilpasser sig den enhed, brugeren besøger sitet med – en mobiltelefon, en tablet eller en af de efterhånden mange former for computere, der er på markedet.

Der er ingen tvivl om, at Responsive Web Design (RWD) har betydet meget for, hvordan vi i Pentia laver websites. Det har haft betydning for vores designproces. Det har tvunget os til (igen) at tænke over båndbredde og performance. Det minder os om, at prioritering er vigtigt.

Men når vi taler om Responsive Design, kommer vi også ofte til at tale om Adaptive Design. Der findes mange definitioner på begge dele. Jeg tror, de mest almindelige er følgende:

Adaptive Web Design

Et webdesign, der tilpasser sig klientens skærm. Udtrykket knytter sig også til udtryk som progressive enhancement. I daglig tale bliver Adaptive Web Design (AWD) typisk brugt om sites, der anvender media queries og dermed er tilpasset et fast defineret antal skærmopløsninger (f.eks. skærme mindre end 480px, skærme mindre end 768px og skærme mindre end 1280px).

Responsive Web Design

Ethan Marcotte beskriver RWD som brugen af et fleksibelt grid, fleksible medier og brugen af media queries.

Sat lidt på spidsen kan man sige, at hvor man med Adaptive Design tilpasser sit website til flere skærmstørrelser, er ambitionen med RWD at tilpasse sig alle skærmstørrelser.

Og alle de pragmatiske mellemting …

Kan man kombinere teknikkerne? Fluid grid og fluid media giver rigtig god mening på de mindre skærme, hvor skærmpladsen er meget værdifuld, fordi der er så lidt af den. Men hvorfor ikke kombinere dette med et sæt pragmatisk valgte prædefinerede media queries til de større skærme, hvor det måske ikke betyder så meget, om siden vises med 100px margin i hver side?

Vi behøver ikke nødvendigvis at anvende fuldstændig den samme teknologi for alle skærmstørrelser.

Men er det så ægte RWD?

Responsive Design-bølgen har fået os til at orientere vores webdesigns mod en stadig stigende mængde af device-typer. Men i sidste ende er det ikke så afgørende, om du laver et responsive design eller et adaptive design. Ikke fordi der ikke er fordele ved RWD. Og ikke fordi AWD ikke i mange tilfælde er mere pragmatisk. Men fordi det ikke handler om, hvad vi kalder det.

Er dit website ægte RWD? Det er ikke vigtigt.

Tager du højde for, hvilke devices dine brugere anvender til at tilgå dit indhold? Det er vigtigt.

Død over topmenuen

Brugerne besøger ikke dit website for at navigere. De kommer for at løse et problem.

Menuerne er et levn fra infosites

Alt for mange af os, der arbejder med web, anskuer websites som biblioteker. Altså et sted, hvor man kan lede efter viden.

Vi har vænnet os til, at alt vores materiale skal være til rådighed online, så brugerne kan finde hvad som helst. De store mængder information gør det nødvendigt at strukturere indholdet i hierarkier, som man efterfølgende kan navigere igennem.

Vi er blevet dygtige til at organisere vores indhold, så vi kan placere det i menuer. Men måske er menuerne kommet til at fylde for meget?

Fokus på at løse problemer

I vores forsøg på at gøre vores indhold overskueligt, pakker vi vores indhold ind i megamenuer, venstremenuer og fat footers. Men måske er vores udgangspunkt forkert. Måske kommer vores brugere ikke ind for at søge og lede information. Måske kommer de blot for at løse deres problem.

Selvom Bill Gates sagde “content is king“, er det ikke velstruktureret, organiseret indhold, der driver folk til websites. Det er den hjælp, de får til at løse deres problem.

Hvis vi i stedet begynder at fokusere på de problemer, vi prøver at hjælpe brugeren med at løse, og mindre tid på at sikre, at man til alle tider kan skifte retning på websitet, ville vi måske få nogle mere fokuserede websites. Måske kunne vi bruge pladsen på at hjælpe brugeren mere?

Har dit site overhovedet brug for menuer?

Menuer er næppe en døgnflue – men måske er det også blevet en vane, at vi skal have en menu. En vane, der måske ikke altid er en god vane.

Service-orienterede sites har længe prioriteret handling over navigation. Se for eksempel på et site som airbnb.com, hvor fokus er på at finde en lejlighed. Havde de gjort som alle andre, havde de måske haft en topmenu med menupunkterne Find lejlighed, Bliv medlem, Priser, Vilkår, Min side, mv. I stedet har de erstattet topmenuen af et enkelt søgefelt og et par servicelinks.

Airbnb er ikke designet omkring end menu, men omkring søgning

I stedet for alle menuerne har Airbnb valgt at fokusere på sitets hovedformål, som er at hjælpe brugerne med at finde et sted at bo.

Et andet eksempel på et brugervenligt website, der ikke har nogen menuer, er det omdiskuterede website gov.uk. Gov.uk er vel det nærmeste, man kommer på en britisk pendant til borger.dk. Her har man valgt at bygge sitet op af navigationssider. På den måde bliver det muligt at knytte navigationen tættere sammen med indholdet.

Overblik eller engagement?

Det er klart, at man ofrer overblikket ved at fjerne menuerne fra sit website. Og med off-canvas menuer og andre snedige strategier behøver de ikke at fylde ret meget på vores websites. Så hvorfor så overhovedet denne diskussion?

Pointen i dette indlæg er ikke, at menuer er af det onde, eller at man absolut skal prøve at undgå dem. Pointen er at sætte spørgsmålstegn ved, hvordan vi bedst griber informationsarkitekturen an.

Måske skal vi fokusere mindre på, hvordan vores indhold er struktureret (eller hvordan det kommunikeres, at det er struktureret) og mere på, hvad det er for et problem, vi prøver at hjælpe vores brugere med at løse.

I stedet for at jagte det perfekte overblik skal vi måske se på, hvordan vi øger relevansen for den enkelte bruger. Hvis vi kan det, hvis vi virkelig mestrer at have fokus på brugerens motivation, så behøver vi ikke give dem et overblik. For så formår vi måske at imødekomme deres behov, før de orienterer sig i menuen.

Er IA design?

Paul Rand har sagt det så elegant:

“Design is the method of putting form and content together. Design, just as art, has multiple definitions, there is no single definition. Design can be art. Design can be aesthetics. Design is so simple, that’s why it is so complicated.”

Således er informationsarkitektur også design. Men pas på med at blande IA og grafisk design sammen – for der er forskellige roller, der skal varetages. En del af designprocessen handler om at prioritere og gøre enkelt – en anden handler om at fremhæve følelser og skabe samhør.

Det kan være en stor fordel for dit projekt, at der er plads til at designeren og informationsarkitekten kan være uenige. Smukke, anvendelige og effektive løsninger udspringer oftere af diskussioner end af åbenbaringer.

Mobile brugere overhaler desktop i webstatistik

Hvor mange mobile besøg får et dansk website? Hvis man leder efter et gennemsnitstal, skal man passe på – for tallene peger ikke entydigt i samme retning.

Antallet af mobile brugere har været stigende i mange år. Hvornår stabiliserer tallene sig? Efter at have kigget tallene fra januar igennem, er jeg begyndt at se et mønster tegne sig: Vi skal nok ikke forvente, at tallet stabiliseres. Tvært imod kan vi begynde at ane en stigende diversitet.

FDIM offentliggør statistik fra deres medlemmer på deres website. Tallene er ikke repræsentative for alle danske websites, men det er en samling af nogle af de mest besøgte mediesites i DK. På den måde kan det give os en idé om, hvor mange der anvender mobil vs. tablet vs. desktop på nettet i Danmark.

Gennemsnitligt 35% besøg fra smartdevices i DK

Tager man gennemsnittet af mobil- og tabletbesøg, er tallet rigtig nok i stigning. For januar er det gennemsnitlige tal for besøg ca. 35% for smart devices (visits for mobil og tablet).

Grafen viser at 19% af sidevisninger kommer fra mobilen og 16% kommer fra tablets.
Grafen viser, at 19% af besøgene kommer fra mobilen og 16% kommer fra tablets.

Men mere interessant er det, at der er stor spredning – de sites med færrest mobilbesøg har under 10% mobile besøgende (visits ekskl. tablets), mens siderne med flest mobile besøg har over 50%.(visits ekskl. tablets),

Flere mobil- end desktopsbesøg

Det er særligt interessant, at vi nu ser adskillige websites, hvor mere end halvdelen af besøgene er fra mobile brugere. Ud af top 250 er der 34 af websites, hvor under halvdelen af besøgene vises på desktop (jf. FDIMs statistik fra januar 2014).

Det site, der har den største andel af mobile besøg, er voresborn.dk, hvor 57% i januar besøger websitet på mobilen (visits, resten på desktop og tablet).

Mobile First: Tre forskellige forståelser

I Pentia, hvor jeg er UX arkitekt, har vi dygtige mennesker til at lave design og frontend. Og vi taler ofte om Mobile First. Men sandheden er, at vi ikke er enige, når vi taler om Mobile First.

Vi kan hurtigt blive enige om, at Mobile First er et buzz word. Og lige som Big Data, Responsive Design og User Journeys er der omtrent lige så mange definitioner, som der egoer. Men i Pentia er vi også enige om, at selvom det er et buzz word, så er det et vigtigt et af slagsen. Men det er vigtigt at forstå, hvilke forskellige konsekvenser der følger af ordet, afhængigt af om det er en frontend-udvikler, en designer eller en UX’er der siger Mobile First.

For at kaste lidt lys over de mange definitioner, vil jeg her forsøge at beskrive, hvordan de forskellige fagligheder taler om Mobile First i Pentia.

UX’erens definition af Mobile First

Når en UX’er arbejder med Mobile First i Pentia, er det med henblik på at designe den mobile løsning, før man går i gang med desktop-versionen. Stort set alle de projekter, vi har lavet over de sidste to år, har været Responsive Design-projekter. Vi ved, at vi skal lave noget til både desktop og mobil.

Jeg plejer at sige, at udfordringen ikke er at gøre et enkelt website responsive. Det er at lave et enkelt website.

Der skal prioriteres hårdt, når man arbejder med mobile løsninger. Og en hård, skarp og fokuseret prioritering skader sjældent et desktop-design. Så med fokus på at lave den hårdeste prioritering først, lægger UX’eren ud med at designe til den mindste skærm.

Tænker man ikke Mobile First i designprocessen, ender man hurtigt med at skulle skærpe sin prioritering flere gange undervejs i processen. Det er en øvelse, der både kan være svær og uhensigtsmæssig at dele op i for mange bidder. Starter man derimod med den svære prioritering, bliver det en gave at få lov at folde den ud på en større skærm.

Helt kort er Mobile First et princip, UX’eren kan bruge til at tage de sværeste beslutninger tidligst i processen.

Frontend-udviklerens opfattelse af Mobile First

Dygtige frontendere vil ligesom UX’eren altid forsøge at løse de sværeste problemer først. Og hvor UX’eren og designeren er fokuserede på den meget mindre skærm, er frontenderen typisk fokuseret på den meget mindre båndbredde og den noget mindre processorkraft, der findes i bærbare enheder.

Frontend-udvikleren vil derfor typisk fokusere på at lave en løsning, der først og fremmest spiller godt på de mobile enheder – fordi de oftest er udsat for den dårligste forbindelse og den mindst hurtige processor.

Et af de værktøjer, frontenderen tager i brug, er Progressive enhancement. Det betyder i korte træk, at man vælger, hvad der skal læses ind i et worst case scenario (dårlig forbindelse, lille skærm, gammel browser) og at de øvrige elementer læses ind efterfølgende i det omfang, det giver mening.

Et eksempel på progressive enhancement vil være at indlæse en sides overskrift og brødtekst som det første, og først bagefter indlæse pyntebilleder og grafikker, der får siden til at se ekstra flot ud. Når alt det essentielle er indlæst, kan man – hvis der ser ud til at være nok båndbredde – vælge også at indlæse eksempelvis reklamer og videoer, eller at preloade indhold fra øvrige sider.

På den måde sikrer frontenderen, at brugeren altid får den bedst mulige oplevelse så tidligt som muligt, mens siden loader. Og fordi man har defineret et “worst case scenario”, har man altid noget meningsfuldt og pænt at vise dem, der har en lille, gammel mobiltelefon.

Designerens bud på Mobile First

Interessant nok har designeren et helt tredje sæt udfordringer at forholde sig til end UX’eren og frontenderen. Men såfremt de to andre fagligheder har gjort deres arbejde ordentligt, er det faktisk ikke det, at det er mobilen, der er en udfordring for designeren. Her er udfordringen nærmere at skulle levere et design, der kan tilpasse sig en skærmstørrelse og stadig give mening.

Designerens opgave bliver at lave en løsning, hvor brand og brugeroplevelse er konsistent, selvom størrelsen på skærmen og layoutet af elementerne ændres fra besøg til besøg.

Designeren fokuserer derfor på at lave legoklodser, der kan fungere i forskellige størrelser og sammenhænge – til touch og til mus.

Kundens forståelse af Mobile First

Men vi mangler en vigtig interessent. I Pentia spiller vores kunde en afgørende rolle ifm. Mobile First. Hvis ikke kunden fra starten køber ind i processen med at bygge til mobiltelefonen, før man bygger til tablet og desktop, løber man hurtigt ind i problemer.

I Pentia har vi flere gange oplevet, at “Mobile First” i virkeligheden opfattes som “og så skal det også virke på mobilen”. Når man i sådanne tilfælde viser kunden et mockup af et website på en mobiltelefon, er den første reaktion typisk: Men hvad med det “rigtige website?”

Hvis kunden ikke kan se fordelene i at tage de sværeste beslutninger først, og ikke anser besøgende fra mobil og desktop som ligeværdige, så kan det godt være, at Mobile First ikke er den rigtige vej. For i sidste ende er det en proces – og processer er til for at skabe bedre produkter. Og selvom man kan skabe fede, fokuserede og gennemtænkte produkter ved at tænke Mobile First, er den bedste proces den der inddrager kunden.

Brugerens handling er et godstog

I et indlæg på Wired.com fortæller Luke Wroblewski (a.k.a. Mr. Mobile First) om erfaringer med at bygge apps til mobilen.

Jeg kunne især godt lide denne passage:

We can no longer just worry about how to fit more controls on a small screen. Now, we have to focus on where the action is — on people’s primary flow through an app.

Think of that flow as a speeding freight train. Outside of Hollywood blockbusters, getting in the way of a train usually doesn’t end well. It takes a lot of effort to shift the course of something with that much momentum. So instead of trying to divert people’s attention from their primary task, mobile designers should just hop on board and use the train’s momentum towards their — and their users’ — goals.

Når vi designer digitale løsninger, skal vi ikke prøve at give brugerne mulighed for at skifte retning hele tiden. Vi skal hjælpe dem med at gennemføre deres handling, og fokusere vores tilbud til dem omkring denne handling.