Besøkende danner seg en mening om et nettsted eller et produktgrensesnitt i løpet av millisekunder. Googles forskning på visuell kompleksitet og prototypikalitet hjelper med å forklare hvorfor de første signalene i grensesnittet betyr så mye. Før brukerne sammenligner funksjoner, vurderer de klarhet, tillit og innsats.
Dette førsteinntrykket får direkte følger for leveransen i produkt- og utviklingsteam. Et forvirrende brukergrensesnitt øker frafallet, men det skaper også omarbeid: flere spesialtilfeller i utviklingen, mer engangshåndtering av innhold i CMS-et og flere henvendelser til support etter lansering. Jeg har sett det samme mønsteret gang på gang i WordPress- og headless-prosjekter. Team godkjenner attraktive skjermbilder og oppdager så at designsystemet ikke lar seg overføre ryddig til komponenter, redaksjonelle arbeidsflyter eller ytelsesbudsjetter.
Gode UI-designtjenester minsker dette gapet mellom skisser og produksjon. Arbeidet handler ikke bare om farger, avstander og knapper. Det fastsetter hvordan et grensesnitt skal oppføre seg på tvers av maler, enheter og tilstander, og om disse valgene kan implementeres effektivt i den tekniske stacken din. For bedrifter som planlegger WordPress-løsninger for store virksomheter, betyr dette skillet noe tidlig, fordi designvalg påvirker blokkarkitektur, gjenbruk av komponenter, omfanget av kvalitetssikringen og langsiktige vedlikeholdskostnader.
Hvorfor UI-designtjenester er et tema for ledelsen
Ledergrupper får øynene opp for UI når det begynner å påvirke inntekter, leveransekostnader og risiko på samme tid. Et tydeligere grensesnitt kan bedre konverteringen, redusere behovet for support og korte ned friksjonen i salget, men det viktigste poenget er operativt. Valg i grensesnittet avgjør hvor effektivt et produkt blir bygd og hvor pålitelig det fungerer etter lansering.
Styrer vurderer ikke knappestiler. De vurderer om laget kunden ser, støtter forretningsmodellen.
Det betyr noe fordi UI ligger der merkevareløftet møter den tekniske virkeligheten. En bedrift kan investere tungt i posisjonering, prising og kundeanskaffelse og så miste farten på skjermen der en potensiell kunde prøver å be om en demo, sammenligne abonnementer eller fullføre et kjøp. I WordPress- og headless-prosjekter ser jeg ofte det samme feilmønsteret. Team godkjenner polerte konsepter og støter deretter på manglende komponenter, inkonsekvente CMS-regler og frontend-oppførsel som koster mer å implementere enn forventet.
Hva ledelsen egentlig kjøper
Bedrifter henter vanligvis inn UI-designtjenester for å løse ett eller flere av disse forretningsproblemene:
- Friksjon i veksten: Trafikken når produktet eller nettstedet, men grensesnittet leder ikke brukerne tydelig nok mot neste handling.
- Operativ bremse: Mønstre er ikke godt definert, så utviklerne lager vanlige elementer på nytt i ulike maler og funksjoner.
- Inkonsekvent merkevare: Markedsførings-, produkt- og innholdsteamene sender ulike signaler gjennom grensesnittet.
- Manglende samsvar med plattformen: Den ønskede opplevelsen passer ikke med begrensningene i CMS-et, designsystemet eller frontend-arkitekturen.
I praksis er det derfor UI blir et tema for ledelsen og ikke en post i markedsføringsbudsjettet. Hvis et designsystem lar seg overføre ryddig til gjenbrukbare komponenter, går utviklingen raskere, kvalitetssikringen blir mer avgrenset og fremtidige versjoner gir mindre risiko. Hvis ikke, betaler bedriften to ganger. Én gang under byggingen og én gang til under vedlikeholdet.
For team som planlegger WordPress-løsninger for store virksomheter, utvider UI-diskusjonen seg som regel raskt til styring, redaktørkontroller, ytelsesbudsjetter og langsiktig eierskap. Det samme gjelder i headless-oppsett, der designvalg påvirker API-payloads, komponentbiblioteker, arbeidsflyter for forhåndsvisning og innholdsmodellering. Godt UI-arbeid setter regler som utviklingsteamet kan bruke.
UXMagics UI-guide for nybegynnere gir et nyttig utgangspunkt, men på ledernivå er spørsmålet smalere. Kan grensesnittet støtte vekst uten å skape kaos i leveransen?
Derfor betyr sterke UI-designtjenester noe for ledelsen. De reduserer uklarhet før byggingen starter, knytter visuelle valg til tekniske begrensninger og gjør prosjektresultatene mer forutsigbare.
UI-designtjenester uten moteordene
De fleste kunder hører «UI-design» og tenker på skjermbilder, farger og knapper. Det er en del av det, men kjernefunksjonen er smalere og mer nyttig. UI-designtjenester definerer de visuelle og interaktive reglene som gjør et produkt forståelig ved første øyekast og brukbart under reelle forhold.
En enkel sammenligning hjelper. Tenk på en fysisk butikk. UX er hele handlereisen: hvor inngangen er, hvordan gangene går, hvor raskt noen finner kassen og om besøket føles frustrerende eller naturlig. UI er det synlige og interaktive laget i denne reisen: skiltingen, hylleetikettene, belysningen, avstandene, betalingsterminalen og hvert signal som forteller kunden hva hun skal gjøre videre.
Hva UI-designtjenester faktisk omfatter
Godt UI-arbeid dekker vanligvis tre lag samtidig:
- Visuelt språk: Farger, typografi, avstander, hierarki, ikoner, bilder og styling av komponenter.
- Interaksjonsatferd: Hover-tilstander, tilbakemeldinger i skjemaer, menyer, valideringsmeldinger, filtre, faner og responsiv oppførsel.
- Tilgang for alle: Kontrast, tekstskalering, tastaturnavigasjon, etiketter i klarspråk og robuste mønstre for forhold som ikke er perfekte.
Det siste laget blir ofte oversett. Mange byråer presenterer fortsatt UI som visuell identitet lagt over skjermbilder. I praksis må grensesnittet også tåle dårlig nettforbindelse, eldre enheter og innhold som legges inn av folk som ikke er designere.
Der kjøpere blir forvirret
Forvirringen starter som regel når leverandører samler UI, UX, merkevarebygging, frontend og produktstrategi under ett begrep. Det gjør kjøpet vanskeligere, ikke enklere. Kundene må vite om de betaler for utforskning, grensesnittsystemer, prototyping, kvalitetssikring av design eller leveranser som er klare for implementering.
Som en kortfattet grunninnføring er UXMagics UI-guide for nybegynnere nyttig. Når du kommer forbi dette nivået, blir kjøpsspørsmålet mer praktisk: Hvem definerer gjenbrukbare komponenter, hvem tar hensyn til begrensningene i CMS-et, og hvem sørger for at grensesnittet kan vedlikeholdes etter lansering?
Et UI som ser gjennomarbeidet ut i statiske skisser, kan likevel feile hvis redaktørene ikke klarer å bruke det og utviklerne ikke kan skalere det.
Derfor betyr også designverktøyene noe. Team som sammenligner Figma og Sketch for WordPress-prosjekter, diskuterer ikke bare preferanser. De bestemmer hvordan overlevering, komponentbiblioteker, tilbakemeldinger og disiplin i implementeringen skal fungere i hverdagen.
Anatomien til et UI-designprosjekt: de viktigste leveransene
Team merker vanligvis kostnaden ved manglende designdetaljer i utviklingen, ikke i gjennomgangsmøtene. Et skjermbilde kan se godkjent ut og likevel la utviklerne gjette seg til tilstander, innholdsgrenser eller hvordan CMS-et oppfører seg. Det er i denne gjettingen at tidsplaner strekker seg og budsjetter begynner å skli.
Tidlige leveranser som reduserer risikoen i byggingen
Et godt drevet UI-prosjekt starter med å definere hva produktet må gjøre, før teamet bestemmer hvordan det skal se ut. Det betyr vanligvis en oppsummering av research, kartlegging av krav og brukerflyter. Disse leveransene avdekker hull tidlig, særlig når flere interessenter forutsetter ulike regler for den samme funksjonen.
Deretter kommer wireframes. De fungerer som strukturelle planer for layout, hierarki og oppgaveflyt. Dette er også punktet der team kan avklare praktiske spørsmål som påvirker utviklingskostnaden, for eksempel om en side trenger én gjenbrukbar mal eller flere innholdsspesifikke varianter.
Interaktive prototyper og detaljerte skisser følger. Her blir oppførsel, visuelt hierarki og responsive intensjoner konkrete nok til gjennomgang med interessenter og teknisk estimering. I WordPress- og headless-prosjekter bør denne fasen også vise hva som er en gjenbrukbar komponent, hva som er et mønster styrt fra CMS-et, og hva som er en engangsløsning som vil koste mer å vedlikeholde.
Her er leveransene kunder bør forvente i et seriøst UI-oppdrag:
| Leveranse | Hvorfor den betyr noe |
|---|---|
| Brukerflyter | Avdekker manglende veier, godkjenningstrinn og spesialtilfeller før skjermbildene blir mange |
| Wireframes | Fastsetter struktur og prioritering av innhold før den visuelle finpussen starter |
| Interaktiv prototype | Lar interessenter teste logikken i oppgavene og reduserer subjektive tilbakemeldinger |
| Detaljerte skisser | Definerer hierarki, visuelle regler og responsiv oppførsel tydelig |
| Designsystem | Gir utviklerne gjenbrukbare komponenter og standarder i stedet for isolerte filer |
| Overleveringsdokumentasjon | Gjør designintensjonen om til byggeregler som teamet kan implementere konsekvent |
Team som planlegger et redesign, sammenligner ofte leveransene med budsjettet for tidlig. Et bedre utgangspunkt er om pakken gir utviklerne nok informasjon til å bygge uten å tolke. Det avgjør som regel om et tilbud er realistisk. For team som budsjetterer et CMS-drevet prosjekt, er denne gjennomgangen av faktorer som påvirker prisen på WordPress-webdesign et nyttig referansepunkt.
En kort gjennomgang av prosessen kan hjelpe kunder med å se for seg hvordan arbeidet går fra konsept til lansert produkt:
Leveranser mange byråer hopper over
Hullene som skaper problemer, viser seg sjelden i skisser av forsiden. De viser seg i tomme tilstander, valideringsfeil, lastetilstander, søk uten treff og lange tekster som redaktører legger inn et halvt år etter lansering.
En brukbar UI-pakke bør definere responsive tilstander, komponentvarianter, feilhåndtering og innholdsregler. I WordPress-prosjekter betyr det også blokkoppførsel, rekkverk i redigeringsverktøyet og tydelige regler for hva som skjer når forfattere legger til mer tekst, bytter bildeformat eller endrer rekkefølgen på moduler. I headless-prosjekter gjelder den samme disiplinen på skjema- og komponentnivå. Designet må kunne overføres ryddig til strukturert innhold, ellers blir fleksibiliteten i frontend til redaksjonell forvirring.
Universell utforming hører hjemme blant kjerneleveransene, ikke i en gjennomgang etter godkjenning. 71 % av brukere med funksjonsnedsettelser forlater nettsteder som ikke er universelt utformet (UX Magazines artikkel om design for underbetjente lokalsamfunn). Den samme artikkelen argumenterer for testing på enklere enheter, hensyn til lav båndbredde og design sammen med underbetjente lokalsamfunn i stedet for å behandle universell utforming som en egen sjekkliste.
Hva overleveringen bør gi utviklerne
Godkjente skjermbilder er bare en del av overleveringen. Utviklere trenger regler for implementeringen.
Etter designgjennomgangen bør de sitte igjen med:
- Komponentdefinisjoner: Tilstander, avstandsregler, typografi-tokens og bruksnotater
- Notater om oppførsel: Logikk for hover, fokus, feil, lasting, suksess og deaktivert tilstand
- Responsive regler: Hva som stables, brytes, kortes ned, skjules eller endrer rekkefølge
- Innholdsbegrensninger: Tegngrenser, bildeformater, reserveløsninger og redaksjonelle unntak
- Retningslinjer for CMS: Hva redaktører trygt kan styre, og hva som bør ligge fast i koden
Når disse detaljene er dokumentert, kan utviklerne estimere med trygghet og bygge raskere. Når de mangler, fyller teamet hullene under utviklingen. Det betyr som regel ekstra runder med kvalitetssikring, inkonsekvente komponenter og endringer som burde vært løst i designfasen.
Prosess, tidsplaner og prismodeller
Tidsplaner for design sklir av en forutsigbar grunn. Godkjenningen kommer før teamet er enige om hvem som bestemmer hva, hvordan tilbakemeldinger samles og hvilke antakelser som fortsatt er åpne. Når det skjer, ser tilbudet fast ut på papiret mens det faktiske omfanget fortsatt er i bevegelse.
Riktig prismodell avhenger av hvor stabil produktdefinisjonen er, ikke av hva som føles enklest å kjøpe.
| Modell | Fungerer best når | Ulempe |
|---|---|---|
| Fastpris | Omfanget er stabilt og leveransene er tydelig definert | Endringsønsker kan skape friksjon |
| Medgått tid (time and materials) | Retningen for produktet kan endre seg under kartlegging eller testing | Krever tettere oppfølging av budsjettet |
| Løpende avtale (retainer) | Teamet trenger kontinuerlig designstøtte gjennom flere versjoner | Mindre egnet for enkeltstående, tett avgrensede prosjekter |
Et brosjyrepreget markedsføringsnettsted med godkjente maler passer som regel til fastpris. Et SaaS-produkt med uavklarte arbeidsflyter, rollebaserte tilganger eller pågående brukertesting passer som regel til medgått tid. En bedrift som leverer månedlige forbedringer på tvers av produkt, innhold og vekstarbeid, får ofte bedre kontinuitet med en løpende avtale.
Antall sider er sjelden den viktigste kostnadsdriveren.
Tilbudene øker når grensesnittet har flere tilstander, flere unntak og flere begrensninger i implementeringen. Skjemaer i flere trinn, tilganger, lokalisering, styring av innhold og responsiv oppførsel øker tiden til design og gjennomgang. I WordPress- og headless-prosjekter vokser kompleksiteten ytterligere, fordi designet må tåle reell komponentlogikk, innholdsmodellering og redaktørenes oppførsel etter lansering.
Dette betyr enda mer for team som bygger AI-nettsteder med headless CMS. Slike prosjekter kombinerer ofte dynamisk innhold, flere frontender og hyppige iterasjoner. Et flatt estimat basert på sider bommer på det reelle arbeidet, fordi kostnaden ligger i gjenbrukbare mønstre, reservetilstander, API-drevne moduler og reglene utviklerne trenger for å implementere dem konsekvent.
Billige tilbud utelater som regel de vanskelige delene. Feilhåndtering, tomme tilstander, tilganger, innhold som renner over og mobilvarianter forsvinner ikke fordi de ble hoppet over i estimatet. De dukker opp igjen i utviklingen, der endringer koster mer og tidsplaner er vanskeligere å kontrollere.
Prioritering hjelper med å holde den første versjonen realistisk. En nyttig metode kommer fra denne forklaringen av konkurransebasert UX-benchmarking og Value Density Score: Value Density Score = (User Value + Business Value) / Implementation Effort. En score over 2,0 markerer i det rammeverket et punkt med høy prioritet. Jeg ville ikke brukt formelen mekanisk, men den er en praktisk måte å sammenligne en svært gjennomarbeidet idé med en rimeligere forbedring med tydeligere forretningsverdi.
Planlegging av tidslinjen fungerer bedre med godkjenningsporter enn med én lineær tidsplan. I praksis beveger prosjekter seg i rykk og napp. Interessenter går gjennom, utviklerne peker på begrensninger, innholdet endres, og så justeres designet. Gode planer tar høyde for dette i stedet for å late som om hver uke går uten endringer.
En gjennomførbar rekkefølge ser vanligvis slik ut:
- Kartlegging: Samle krav, begrensninger, interessenter og suksesskriterier.
- Struktur: Bli enige om flyter, maler og sentrale interaksjonsmodeller.
- Visuelt system: Ferdigstille komponenter, tokens, responsive regler og retningen for universell utforming.
- Overlevering og støtte: Gå gjennom implementeringsdetaljer, svare på spørsmål fra utviklerne og kontrollere versjoner i testmiljøet.
I budsjetteringen bør hver fase ha et tydelig sluttkriterium. Kartleggingen er ferdig når teamet er enige om begrensninger og prioriteringer. Strukturfasen er ferdig når de viktigste flytene er godkjent. Det visuelle designet er ferdig når komponentoppførsel og responsive valg er avklart godt nok til at utviklerne trygt kan estimere byggeinnsatsen.
Hvis du priser WordPress-design og -utvikling samlet, er denne gjennomgangen av priser på WordPress-webdesign et nyttig referansepunkt, fordi den knytter budsjettet til valg i leveransen, kompleksiteten i CMS-et og omfanget av implementeringen i stedet for å behandle design som et frittstående produkt.
Slik integrerer du UI-design med WordPress og headless CMS
Et sterkt grensesnitt kan likevel falle fra hverandre under implementeringen hvis det ignorerer publiseringssystemet bak. Det er her mange UI-prosjekter mister kvalitet. Skissene gir mening, men CMS-modellen, komponentarkitekturen eller redaktøropplevelsen gjør det ikke.
Klassiske temaer, blokktemaer og headless-prosjekter
I et klassisk WordPress-tema bygger UI-implementeringen ofte på maler, egendefinerte felt og logikk på temanivå. Det kan fungere godt for kontrollerte nettsteder, men redaktørene kan bli svært avhengige av utviklere når layouter må endres.
I et prosjekt med Gutenberg eller Full Site Editing må UI-et bli et sett med blokker og mønstre med tydelige regler. Det endrer designbriefen. Du designer ikke lenger bare sider. Du designer det redaktørene trygt kan sette sammen uten å ødelegge hierarki, avstander eller innholdsflyt.
I et headless-oppsett blir utfordringen enda større. Det samme designspråket kan måtte støtte et nettsted, appvisninger, landingssider for kampanjer og API-drevne innholdsmoduler. En løs visuell stilguide er ikke nok. Du trenger et ekte designsystem med tokens, gjenbrukbare komponenter, definerte tilstander og forståelse av innholdsmodellen.
Hva utviklerne trenger fra designteamet
UI-designtjenester hjelper enten utviklingen, eller de skaper gjeld.
I WordPress- og headless-arbeid bør designteamet definere:
- Komponentgrenser: Hva som er en gjenbrukbar blokk, et kort, et banner eller et skjemamønster.
- Tilstandslogikk: Varianter for lasting, feil, tom tilstand, suksess, deaktivert og tilgangsbaserte varianter.
- Begrensninger i redigeringsverktøyet: Hvilke felt som er valgfrie, hvor lang teksten kan være, og hvilke medieformater som er trygge.
- Ytelsesbevisste valg: Måtehold med animasjoner, bildeoppførsel og mønstre som ikke straffer renderingen.
For team som utforsker moderne arkitekturer, er MeshBases oversikt over hvordan man bygger AI-nettsteder med headless CMS et nyttig supplement, fordi den beskriver innholdsmodellering og fleksibilitet i frontend i praktiske termer.
Det oversette laget er redaktøropplevelsen
Et design kan være visuelt utmerket og likevel svikte menneskene som drifter nettstedet hver dag. Markedsteam trenger moduler de kan gjenbruke. Innholdsredaktører trenger rekkverk som hindrer at layouten sklir ut. Utviklere trenger konsistens, slik at de kan bygge én gang og gjenbruke med trygghet.
Det er én grunn til at team sammenligner plattformer før de ferdigstiller designsystemet. Et prosjekt som veier WordPress og Strapi mot hverandre, velger ikke bare et CMS. Det velger hvordan komponenter, arbeidsflyter, styring og ansvar for frontend skal fordeles.
Hvis designet ignorerer redaktøren, arver produktteamet problemet etter lansering.
Det beste UI-arbeidet oversetter designintensjonen til mønstre som kan bygges og styres. Det er dette som hindrer at en polert lansering blir til et rotete andre kvartal.
Slik velger du UI-designpartner: en sjekkliste for leverandører
Valget av leverandør betyr noe fordi designkvalitet hoper seg opp over tid. Det samme gjør designgjeld. Ifølge UI Things’ oversikt over statistikk om UI-design kan investering i profesjonelt UI/UX-design gi 9 900 % avkastning (ROI), eller 100 dollar for hver investerte dollar. Det gjør valget av partner mindre likt kjøpet av en kreativ tjeneste og mer likt ansettelsen av en strategisk aktør.
Spørsmål det er verdt å stille i første samtale
En portefølje betyr noe, men samtalen betyr mer. Still spørsmål som viser hvordan byrået tenker når det står overfor begrensninger.
- Hvordan kobler dere designarbeidet til forretningsresultater? Du vil ha svar om konverteringsveier, fullførte oppgaver, friksjon i support eller styring av plattformen, ikke bare om stil.
- Hvordan håndterer dere implementering i WordPress eller headless? Sterke partnere kan snakke om blokker, maler, komponenter, API-er og detaljer i overleveringen uten å vifte det bort.
- Hva omfatter leveransene deres utover skisser? Lytt etter designsystemer, responsiv oppførsel, spesialtilfeller, universell utforming og støtte i kvalitetssikringen.
- Hvordan håndterer dere tilbakemeldinger og godkjenninger? Uklare godkjenningsløkker er en av de raskeste måtene å miste tid og budsjett på.
- Hvordan tar dere hensyn til innholdet slik det faktisk er? Et seriøst team designer for ekte tekst, lengre tekster etter oversettelse og redaktører som bruker løsningen feil.
Gode tegn og faresignaler
Dette er mønsteret jeg stoler på etter mange år med gjennomganger av overleveringer.
Gode tegn
- Teamet spør om målene for produktet før de spør om visuelle preferanser.
- De vil se CMS-et ditt, analysekonteksten og den nåværende designgjelden.
- De snakker tidlig om tilstander, universell utforming og implementering.
- De kan forklare hva som bør standardiseres, og hva som bør forbli skreddersydd.
Faresignaler
- De lover ferdig visuelt design med en gang.
- De viser bare hero-seksjoner og blanke landingssider.
- De unngår å snakke om tekniske begrensninger.
- De behandler universell utforming som en sen etterlevelsesoppgave i stedet for et designkrav.
Et mindre, men viktig punkt i due diligence er lisenser. Fonter, ikoner, stockmateriale og bruksrettigheter skaper ofte friksjon mellom byråer og kunder etter lansering. Font Checker Pros innsikt om fontlisensiering er verdt å gå gjennom før kontrakter signeres, særlig hvis merkevaresystemet ditt omfatter flere produkter eller regioner.
Slik høres en sterk partner ut
«Vi må forstå den tekniske stacken din, arbeidsflyten for innhold og hva suksess betyr for dere, før vi snakker om skjermbilder.»
Et slikt svar er vanligvis mer verdifullt enn en dramatisk konseptpresentasjon. Den rette partneren lager ikke bare et attraktivt grensesnitt. Den reduserer samtidig uklarheten for produkt-, innholds- og utviklingsteamene.
Måling av suksess: onboarding og avkastning
Den egentlige testen starter etter godkjenning. Hvis overleveringen er svak, gjetter utviklerne. Hvis utviklerne gjetter, glir det lanserte produktet bort fra den tiltenkte opplevelsen. God onboarding betyr felles komponentbiblioteker, implementeringsnotater, kontrollpunkter for gjennomgang og en prosess for å løse spesialtilfeller før de når produksjon.
Suksess krever også målinger som løfter samtalen ut over smak. Mazes guide til UX-benchmarking peker på tid per oppgave og feilrate som sentrale mål, og for interaktive applikasjoner fremhever den INP og TBT som kritiske tekniske indikatorer knyttet til hvor flytende opplevelsen er.
Hva du bør måle etter lansering
- Tid per oppgave: Hvor raskt brukerne fullfører en sentral handling.
- Feilrate: Hvor de nøler, klikker feil eller mislykkes.
- INP og TBT: Om grensesnittet føles responsivt ved reell bruk.
- Oppgavespesifikke resultater: Fullførte kjøp, fremdrift i skjemaer, bruk av dashbord eller oppdagelse av innhold.
Disse målingene betyr noe fordi de kobler UI-valg til forretningsresultater uten å redusere samtalen til meninger. Hvis et redesignet skjema ser ryddigere ut, men brukerne bruker lengre tid på å fylle det ut, har ikke designet gjort produktet bedre.
En god rytme etter lansering er enkel. Sammenlign versjonene i produksjon med designsystemet, samle friksjonspunkter fra support og analyse, prioriter rettelser og hold grensesnittet konsekvent etter hvert som innhold og funksjoner utvides. UI-designtjenester legger grunnlaget. Løpende måling viser om grunnlaget gjør jobben sin.
Hvis teamet ditt trenger UI-design som holder i reelle WordPress- eller headless-leveranser, kan IMADO ta den tekniske siden av ligningen med skreddersydde temaer, Gutenberg- og FSE-prosjekter, headless-implementeringer, utvikling med vekt på universell utforming og strukturerte overleveringsprosesser som bevarer designintensjonen i produksjon.
