UX, UI og BT – en oppfølger til tanken om bruksteknologi

I forrige innlegg skrev jeg om at IT-begrepet kanskje har blitt for stort, og lanserte tanken om BT – Bruksteknologi som et forslag til et enklere ord for teknologien mennesker faktisk møter og bruker direkte. Der landet jeg på en enkel modell: IT → BT → menneske → oppgave.

Et spørsmål jeg selv satt igjen med etterpå, og som jeg tenker er verdt å ta videre her, er hvordan BT egentlig forholder seg til to fagområder som allerede er godt etablert: UX og UI. Alle som har jobbet med teknologi kjenner igjen problemet BT prøver å sette ord på – et system kan være teknisk perfekt og likevel oppleves håpløst for den som skal bruke det. UX og UI har i flere tiår vært de etablerte svarene på nettopp dette.

Så det jeg har begynt å lure på er ikke om UX og UI dekker dette godt – det gjør de – men om vi mangler ett ord til ved siden av dem: et ord for selve løsningen brukeren står overfor, uavhengig av hvor godt eller dårlig den er designet. Her er tankegangen min videre.

Er det egentlig behov for enda et begrep?

Dette er det første spørsmålet jeg selv stiller meg, og jeg tror det er et rimelig spørsmål å møte med skepsis. Vi har allerede UX, UI, Human–Computer Interaction, End-User Computing og «applikasjonslag» fra klassisk IT-arkitektur. Trenger vi virkelig flere ord for det samme?

Jeg tror ikke BT beskriver det samme som disse begrepene – men jeg forstår godt om noen som jobber daglig med UX eller IT-arkitektur reagerer med et løftet øyebryn. Det er en naturlig reaksjon når noen utenfra foreslår nytt språk for et felt man allerede kjenner godt.

Slik jeg ser det, ligger forskjellen her: for en utvikler eller IT-arkitekt er «applikasjonslag» presist og dekkende. Men for en produksjonsleder, en lagersjef eller en HR-ansvarlig som skal beskrive et problem eller skrive en kravspesifikasjon, er de begrepene lite tilgjengelige. BT er mitt forsøk på et enklere norsk ord for den delen av teknologien folk faktisk møter og bruker – ikke et forsøk på å erstatte fagterminologien til de som allerede jobber med dette.

Med det sagt – la meg vise hvorfor jeg tenker at et skille kan være nyttig.

Kort oppsummert

• BT – Bruksteknologi er selve det digitale verktøyet brukeren møter for å løse en oppgave.
• UI – User Interface er grensesnittet brukeren samhandler med.
• UX – User Experience er den samlede opplevelsen og arbeidsflyten rundt bruken.
• God BT krever normalt både gjennomtenkt UI og god UX.
• En løsning kan være BT selv om både UI og UX er dårlige – kvalitet og eksistens er to forskjellige spørsmål.

Slik ser jeg sammenhengen

En enkel modell for hvordan jeg tenker at delene henger sammen:

IT → BT → UI/UX → menneske → oppgave

• IT er teknologien som lagrer, behandler, transporterer og sikrer informasjon – databaser, API-er, servere, sikkerhet.
• BT er den digitale løsningen brukeren faktisk møter – en app, et skjema, et dashboard.
• UI og UX er disiplinene som former hvordan denne løsningen betjenes og oppleves.
• Mennesket er brukeren.
• Oppgaven er grunnen til at alt dette eksisterer.

Det betyr at UX og UI ikke konkurrerer med BT – de er fagområder innenfor BT som avgjør om bruksteknologien blir god eller dårlig.

To eksempler jeg har tenkt gjennom

Lagerappen. Bak en enkel mobilapp for varescanning kan det ligge ERP-system, database og integrasjoner – det er IT. Selve appen operatøren åpner er BT. Knappen «Skann vare» er UI. Hvor raskt og problemfritt operatøren kommer gjennom registreringen er UX. Alt sammen kan oppsummeres slik: ERP/database = IT → lagerapp = BT → knapper/skjermbilder = UI → enkel arbeidsflyt = UX → operatør registrerer varen.

SmartInstruks, produktet jeg selv har bygget, illustrerer samme prinsipp. Bak løsningen ligger database, webserver og QR-håndtering – det er IT. Det brukeren møter er en QR-kode som åpner riktig instruks på mobilen – det er BT. Navigasjonen og knappene er UI. Hvor raskt brukeren finner og forstår informasjonen, er UX. Målet har hele veien vært at opplevelsen skal være: skann → forstå → utfør. Det tenker jeg er et forsøk på god bruksteknologi.

Et poeng jeg synes er verdt å dvele ved

En løsning trenger ikke være brukervennlig for å regnes som bruksteknologi. Et gammelt, klønete ERP-grensesnitt er fortsatt BT hvis mennesker bruker det direkte for å løse en oppgave – det har bare dårlig UX. På samme måte kan et system ha et polert, gjennomarbeidet grensesnitt og likevel være dårlig bruksteknologi, hvis det ikke passer arbeidsoppgaven. Ni skjermbilder for å registrere tre kontrollpunkter er ikke god BT, uansett hvor fint det ser ut.

Det er derfor jeg tenker at god BT handler om mer enn design alene. Det handler om riktig funksjonalitet, riktig integrasjon og riktig arbeidsflyt for akkurat den oppgaven som skal løses.

Der jeg tror begrepet kan ha en funksjon

Mange bedrifter jeg har vært borti har allerede solid IT: ERP, Microsoft 365, CRM, skyløsninger. Likevel lever Excel-ark og papirlapper videre ved siden av alt dette. Jeg har begynt å tenke at problemet i slike tilfeller sjelden er mangel på IT – det er mangel på et godt lag mellom systemene som allerede finnes og personen som skal bruke informasjonen i praksis. Det laget er det jeg foreslår å kalle bruksteknologi.

Foreløpig konklusjon – eller egentlig bare et spørsmål

Jeg påstår ikke at dette er en ferdigtenkt modell, og jeg er åpen for at fagfolk med dypere UX- eller IT-arkitekturbakgrunn ser svakheter jeg ikke ser selv. Men jeg tenker at et enklere språk for gapet mellom avansert IT-infrastruktur og folk som bare skal få gjort jobben sin, er verdt å sette ord på – uansett hva vi til slutt velger å kalle det.

Uansett begrep sitter jeg igjen med det samme spørsmålet:

Hva er det brukeren faktisk skal få gjort?