A user journey canvas to map out your design system as a service, and to focus on some of the parts involved in making it truly valuable for your users.

Like to take the pulse of your design system? Or find out what to focus on when working on a new one?

A good starting point is to map out our service and some of the parts involved in making it truly valuable for your users.

This canvas t is divided into the main phases and subdivided into some of the goals of using a design system:

Learning how to use it

Design with it

Collaborating with others

It is made in Miro, and you can copy and edit to make it your own. It would be fun to learn how to improve the canvas, so any feedback to Sergio.haisch@bekk.no or comment in Miro would be much appreciated.

Link to the canvas in Miro 

Good luck!

Design System User journey canvas

Et første forsøk på å beskrive hva en ux'er bør kunne - inspirert av friskt foredrag av Fredrik Matheson på høstens Fryd. 

Er det virkelig sånn at vi ikke har noen klare beskrivelser av hva en ux'ers fagområde består av? Ja, det er det kanskje. Burde vi ha det? Vel, det har vel ofte virket tryggere om noen kunne pekt helt konkret på hva de forventer av oss som ux-designere. 

Ingen fasit, men noen første tanker (som absolutt må itereres videre på) - her er mine 6 ting en designer bør kunne. 

For en drøy måned siden satt jeg i kantina vår i Skur 39 og hørte Fredrik Matheson rante om faget vårt – ux-faget – fra scenen på Fryd. Det er ungt, det er udefinert – og han slengte ut en påstand jeg tok som en utfordring: «vi vet ikke en gang hva vi bør kunne som ux’ere – i hvilket annet fag er det sånn?»

Hm, tenkte jeg. Er det sånn? Vet jeg virkelig ikke hva en ux’er bør kunne? Jeg som ikke så sjelden vurderer folk på intervju, jeg er med på å ta i mot nye kull designere hver høst og gir dem en innføring i jobben deres før de sendes ut til kunder – vet ikke jeg hva en ux’er bør kunne? Og mens jeg satt der og tenkte, sank det i meg. For det er sant, som Fredrik sier (som det jo ofte er), at vi har ingen klare parametere å vurdere kandidatene etter, ingen sjekkliste å krysse av på av de ulike evnene og kunnskapene som trengs i jobben vår, ingen liste vi går igjennom når vi setter opp oppstartsopplegget vårt hver høst for å passe på at alle får den faglige inputen vi mener de trenger for å kunne gjøre jobben sin. Ingen liste i Bekk, og ingen i bransjen vår. Hekk, vi er jo knapt enige om hva ux egentlig innebærer, eller hva som er riktig tittel på oss.

Men, tenkte jeg. Det er jo ikke helt fritt vilt heller. Det er jo ikke hva som helst eller ingenting som definerer oss. Og jeg har jo en følelse, om ikke en distinkt bevissthet, av hva en god ux-designer gjør og er god på. Og typisk nok, når jeg hører Fredrik rumle om fag og filosofi, får jeg en idé.

Jeg burde jo kunne beskrive litt mer eksplisitt, den «følelsen» av hva en designer bør kunne.

Åpenbart ikke som noe forsøk på en objektiv fasit – siden problemet er at vi nettopp mangler det. Men som en subjektiv formening, i en rolle hvor jeg ansetter og oppdrar designere – det bør jeg jo rett og slett ha. Om ikke annet for å bli mer bevisst hva som skal til for å levere det vi trenger å levere. Og som en god designer, har jeg ingen problem med å ta en idé og la den leve litt før jeg låser meg til en løsning! Så her begynner jeg bare på noe, tenker jeg, og så skal jeg la det få småkoke en god stund, og foredles over tid. Nå er tankeprosessen i det minste i gang. Takk, Fredrik!

Min foreløpige liste over de grunnleggende tingene jeg mener en designer* må kunne:

Nummer 1: Brukeradferd

Uten å forstå eller å kunne jobbe med brukeradferd, stopper nesten alt en ux-designer gjør, opp. Det er kjernen i brukersentrering: å kunne kartlegge og tolke brukerbehov, beskrive behov og adferd, og så kunne designe for å dekke behovene og påvirke adferden.

Aktiviteter som styrker forståelse for brukeradferd: 

Planlegge, gjennomføre og oppsummere brukerintervjuer og brukerobservasjon. Både av folk som bruker tjenesten du jobber med og ikke, som utviser adferden du skal påvirke og ikke. Når du oppsummerer funn, øv deg på å syntetisere, ikke analysere – øv deg på å sette enkeltdelene du finner sammen til et helhet, heller enn å liste ut enkeltfunn.

Nummer 2: Affordance

Det mangler vel et godt norsk ord for det, men altså et objekts uttrykk for hvordan det kan bli brukt. Som et dørhåndtak som tydelig viser om du skal dra eller dytte på døra for å åpne den. For alle oss som jobber digitalt, blir det jo spesielt to-dimensjonal visuell affordance vi må være gode på. Og tatt helt ut i det ekstreme kunne man kanskje sagt at på en nettside med perfekt affordance ville man aldri trengt å ha en ledetekst eller label på noenting. Det blir selvfølgelig tullete å si – det er jo ikke som om vi hverken kan eller skal fjerne tekst fra nettsider og digitale løsninger. Men jeg tror det er et symptom på designet ditt at det ikke har god nok affordance, om du tar deg selv i å designe inn mye tekstlig forklaring på elementene en bruker skal interagere med.

Aktiviteter som styrker affordance-evnene dine: 

Brukertesting. Helt standard, formelle brukertester, hvor du lager et testoppsett med oppgaver, observerer opp i mot 10 forskjellige brukere prøve å løse oppgavene, hører hva de sier når du ber dem tenke høyt, og ser hva de sliter med og ikke. På både dine egne og andres løsninger. Sitter du ikke selv og designer på noen løsninger akkurat nå? Velg en hvilken som helst løsning, klikk deg igjennom, gjør deg opp en formening om hva som virker som viktige oppgaver å få løst gjennom løsningen, og kjøre en brukertest. Du kommer til å lære så mye!

Og når jeg først er inne på det med brukertesting: ikke glem å brukerteste for universell utforming. Å krysse av for kravene er en ting…og mange av oss outsourcer det rett til frontend-utviklerne om vi kan. Men du vet like godt som meg at den rampa arkitekten overlot til entreprenøren å fikse, for å etterleve kravene helt i siste liten…den gjør ikke helheten noen tjeneste. Om noen få uker begynner i uu-faggruppa her i Bekk, og det skal være min misjon gjennom 2022 å få brukertestet mer på uu, sånn at jeg virkelig kan lære meg hva som er en godt universelt utformet løsning og ikke.

Nummer 3: Prosess

Ja – du må være god på prosess. Det er sjelden vi jobber med utfordringer som er så enkle at du bare kan se på det, tenke deg litt om, og komme opp med svaret – ferdig. Enkeltproblemer i en løsning eller landskap du kjenner godt, kan helt klart løses gjennom å trekke frem svar fra erfaringsbanken…men tjenestene vi jobber med som helhet – de må vi kunne følge opp prosessuelt. Hva er riktig prosess? Det kommer selvfølgelig an på hva du skal levere, og teamet du jobber med. Men helt generelt vil jeg si, at som designer, må du kunne vite når det er riktig å utvide perspektivet og scopet, og når det er riktig å snevre det inn. Du må ha koll på din egen «double diamond» (som i den kontinuerlige leveranse-verdenen jeg lever i, egentlig er en rekke med ruter som aldri slutter) – du må vite når du skal åpne opp, og når du skal trekke sammen. Og så må du kunne involvere andre i denne rytmen. Dermed blir også fasilitering en del av det å kunne prosess. Igjen – det er sjelden jeg og mine kolleger jobber med oppgaver som er så enkle å løse at det holder at jeg setter meg alene og tenker og designer i vei, og kommer ut med svaret og kan be andre implementere det. Så å få til å få med seg andre på prosess er helt vesentlig for å kunne bidra godt som designer.

Aktiviteter som gjør deg bedre på prosess: 

Tja. Jeg vet faktisk ikke. Vi lærer jo vår isolerte design-prosess på skolen, mange av oss – og den har mye fundamentalt bygd inn i seg som vi får bruk for videre. Men så møter vi jo ofte en utviklingsprosess vi ikke helt har fått innsyn, der noen andres håndverk må styre i vel så stor grad som vårt. Og hva kan vi gjøre da, for å bli flinkere?

Jeg har veldig stor tro på refleksjonens kraft. Å tenke gjennom hva jeg gjør – og burde gjøre. Når jeg møter et team, en utfordring, et selskap, et domene, en oppgave…å tenke gjennom hvordan jeg vil levere på det, og finne frem til en løsning eller et svar, det hjelper meg. Å forestille meg hva jeg skal gjøre – både på kort og lang sikt, det er en slags øving.

Og – jeg tror jeg har fått øvd på prosess gjennom å skrive tilbud på konkrete oppdrag. Når jeg må telle antall folk jeg tror vi må være, liste opp aktiviteter jeg mener vi bør gjøre, og telle uker jeg tror det tar…ja, da får jeg tatt en ny runde på å bli bevisst hva jeg gjør, og hvorfor.

Retroer kan også hjelpe. Mange team-retroer handler fort om enkeltpunkter som har fungert bra og dårlig – men de kan også være tid vi tar oss for å snakke mer helhetlig om hvordan vi jobber. Hvordan flyter egentlig en brukerhistorie gjennom boardet vårt? Hva er egentlig ruter-rytmen vår? Diskuterer vi nok, diskuterer vi for mye? Kvalitetssikrer vi? Når og hvordan måler vi effekt?

Snakke om det, og så gjøre det, og så tenke over det. Det tror jeg er viktig.

Å! Og hold workshops! En workshop kan representere en mini-prosess; det finnes en eller annen utfordring som skal løses, det er noen aktiviteter vi må gjøre, og det er et eller annet resultat vi skal ha ut. Øv deg på prosess gjennom å planlegge workshoper – tenke igjennom hvilket resultat vi trenger, kvalitetssikre at det er riktig. Tenk på og test ut hvilke aktiviteter som kan bidra til det resultatet, og hvilke folk som må være med. Planlegg tidsbruk – og reflekter etterpå om det ble riktig, eller hvordan du bør justere det til neste gang. Og kjenn etter, når workshopen er over, og du har levert resultatet av den, om den funka, eller hva du kunne gjort bedre.

Nummer 4: Måle effekt

Du må kunne følge opp løsningen eller tjenesten din når den er tatt i bruk, og se om den faktisk gir det resultatet du trenger. Nei, jeg snakker ikke om brukervennlighet her – jeg mener faktisk endring i folks adferd eller forretning eller resultat. Det er mer konkret enn «folk er mer fornøyd nå enn før», men ikke nødvendigvis å peke på et resultat på en bunnlinje et sted heller. Det handler om å før du går i gang med å designe noe, å vite hvorfor en tjeneste eller løsning skal lages overhodet. Om svaret ikke finnes allerede, må du hjelpe til med å finne frem til det selv. Du må kunne definere hva en løsning skal gjøre – sånn at du kan sjekke etterpå om det gjør det. Et bra design er et design som løser et problem – på en god måte. Så du må ha koll på problemet, og du må kunne sjekke om problemet er løst etterpå, for å vite om du har gjort jobben eller ikke.

I det vi holder på med, er ikke nødvendigvis «problemet løst» ved første prodsetting. Oftere er vi på vei mot god problemløsning (forhåpentligvis), og må jobbe kontinuerlig for å stadig nærme oss et mål langt fremme. Det er for enkelt å «digitalisere» - lage en digital løsning der det før bare var papir, peke på løsningen når den er ferdig og si seg fornøyd. Den faktiske digitaliseringen har skjedd når en kritisk masse faktisk får gjort den effektiviseringen eller kvalitetsheving løsningen skal bidra til – det holder ikke at det bare «finnes en app for det». Er det ingen som bruker appen, er vi like langt.

Å sette effektmål som er relevante, som lar seg måle, og som vi kan styre etter er vanskelig. Det krever øving. Som designer bør du som minimum være bevisst betydningen av effektmåling, og klar over at jobben ikke er gjort før effekten er vist (men det er også bra å vite når det er på tide å gå videre). Du bør sette deg inn i hvert fall ett av de vanligste verktøyene for måling av adferd på nett, og kunne gjøre noen analyser på de viktigste tallene. Hva er de viktigste tallene? Det er her det hjelper å ha satt seg inn i hvilket problem det du lager egentlig skal løse. Svaret ligger der et sted.

Aktiviteter du kan gjøre for å bli bedre på måling av effekt: 

Les litt teori om det. Jeg er egentlig ikke en forkjemper for veldig teoretiske øvelser når det kommer til design – jeg definerer design aller mest som et håndverk som må praktiseres. Men i alle håndverk er det noe teori – og hvordan konverteringsmålinger fungerer, og hvordan trafikk på en digital løsningen måles i de vanligste verktøyene…jupp, det er noe teoretisk kunnskap der du kan lese deg opp på, enkelt og greit.

Les deg også opp på OKR. Bare gjør det. Gjør det sånn at du skjønner hva det er snakk om når produkteieren din sier at de har fått beskjed om at nå skal alle følge det. Gjør det sånn at du har et utgangspunkt for å diskutere hva OKR’ene kunne vært for løsningen eller tjenesten du og teamet ditt jobber med nå. Og ikke gift deg med det konkrete rammeverket OKR. Husk på at det handler om målstyring, som generelt er bra, for det definerer hensikten med det vi gjør – og det trenger du som designer, og at det handler om å måle effekten av det vi gjør – som forteller deg om vi er på vei mot den hensikten.

I tillegg til å utøve det! For det er jo et håndverk. Sett deg noen mål, bittesmå, men konkrete, og begynn å måle dem allerede nå.

Nummer 5: Forretningsmekanismer

Det er et fryktelig dårlig ord. Forferdelig. Det er så lite presist. Så her må du virkelig bare være med på at denne listen bare er en idé i startgropen, om du skal greie å bli med videre. Det jeg mener, er:

Lær deg å forstå hva markedsdriverne er, for den bransjen selskapet du skal hjelpe. Om du jobber hos en virksomhet i det offentlige: forstå den grunnleggende forvaltningen av den etaten du jobber hos – hva styrer prioriteringene der? Hvordan påvirker politikken din etat? Lær deg å kartlegge – helt overordnet – hva som er de største truslene eller utfordringene for selskapet (uten å glemme at det finnes folk kan det veldig mye bedre enn deg). Ha et (forenklet og overordnet) bilde av hva som driver kostnadene der, og hva som representerer inntjening eller måloppnåelse. Dette vil hjelpe deg å velge ut de ideene som gir mest verdi. Å vurdere hvilke forslag som vil bidra best til det mandatet eller strategien virksomheten styrer etter. 

Aktiviteter som vil hjelpe deg å bli bedre på dette: 

En enkel swot-analyse er ofte veldig opplysende. Om du kan – gjør den med en fra forretningssiden, sånn at du får utvidet perspektivet på hvilke potensielle styrker og svakheter, muligheter og trusler som kan finnes. Dra opp verdikjeden for det du jobber med – og i stedet for å fokusere mest på hva sluttbrukeren ønsker seg, ta innover deg hva det krever av virksomheten å levere. Og ikke minst: snakk med folk i lederroller der du er om det de holder på med og er opptatt av. Ikke hva de ønsker seg av digitale løsninger – men hva de holder øye med, hva de rapporterer på, hva de bekymrer seg over, og hva de feirer.

Nummer 6: Enkel estetikk

Som ux’er må du kunne gjenkjenne helt enkle komposisjonsregler. Gjenkjenne balanse, gjenkjenne proporsjonalitet, gjenkjenne visuelt støy. Og huske på at det er et eget fagfelt. Vi gjør oss selv en bjørnetjeneste som designere når vi prøver å dekke for bredt i stedet for å be om at flere kommer til for bidra med det de kan.

Aktiviteter som trener dette blikket: 

Diskutér det visuelle med en grafisk designer/visuell designer - ofte! Få dem til å beskrive hva de ser, og legg merke til hvilke ting de fokuserer på og kommenterer. Å jobbe med flinke grafiske designere er det som aller mest har hjulpet meg. 

Hva tenker du?

Åkei - her er det altså. Mitt første utkast på hva jeg mener en ux-designer bør kunne. Den må itereres på. Det vet jeg. Det må ideer alltid. Men det har hjulpet masse å bare begynne å tenke på det! Og det neste jeg vet jeg kommer til å trenge nå, er å diskutere det og få innspill. Så: hva tenker du? Hva mener du er kjernekompetanse vi ux-designere må ha?





*Designere kommer i mange ulike varianter – innen for mange ulike fagfelt. De jeg tenker på i denne artikkelen er de som glir mellom rollene tjenestedesignere, ux-designere, strategiske designere, business designere, interaksjonsdesignere og design researchere…du vet, de på det brede spekteret der, som ofte ikke helt vet hva de er.

Hva bør en designer kunne? 

The complicated relationship between design and MVPs 
- and why it’s worth it ❤️





In her song “Hurts so good”, Astrid S describes a complex and confusing love affair. The contradictory feeling is in many ways recognizable for designers working in teams using an MVP approach.



Merging design and MVPs

The Minimum Viable Product (MVP) approach is all about building to learn. You strive to build something that gives some value to users as quickly and efficiently as possible so you can learn and evolve the product. Build, measure, learn, repeat. It is a process of many iterations.

The benefits are many:

Development goes faster

Users get value earlier (more and more features over time instead of nothing until the product is done)

Risk per release is reduced

The team is more flexible to fix bugs or change course







So, only good stuff here. But what happens when you combine an MVP approach with design methodology?



As a designer I am all about user-centered problem solving. To be able to do my job I need to empathize with and understand the users and their needs. I also need to understand the context, ideate, test my hypothesis, and sketch (amongst other things). All time-consuming activities. Time which we in the digital product development world don’t have. I’m currently working in a team where we have just launched an MVP and are now continuously working to improve our product and find out what our next step should be. We are in the beginning stages of our project and we aim to go fast. Learn fast and build fast. Which brings me to why it hurts.




Speed vs. quality

When development speed increases, the designer has less time to design. There is no time to squeeze in a double diamond between each release. You do not have time to do the testing you would like, or gather the desired user insight. Without this insight and understanding, you feel like you will crumble on the first release. Releasing something that maybe only half done (or less) really, truly hurts. Oh my god. It hurts.

However, as soon as the first release is out you immediately have real users, and get real data. The learning begins. You learn from actual use of the MVP. User insight expires quickly, as our users are evolving in line with the digital development. Having short feedback loops results in current and continuous user insight. In addition, small releases leads to more accurate insight from tracking, testing and interviews because the changes between releases are smaller. So, on the good side, if your half-finished work was a total disaster you will see it real quick. PLUS, you will most likely know exactly what needs to be done to fix it.




Flexibility and immediate value

In digital development it is important to be able to adjust course quickly. Working with MVPs encourages short-term planning. By focusing on the next iteration, and not planning half a year in advance, allows the team to be flexible for changes and fixes. So your half finished work from before can be edited quickly. But, designing for the short term can result in a fragmented solution. It is therefore important to balance between quick and small iterations, and look up and ahead from time to time. When working in the digital world we not only have the possibility to be flexible, but also have the opportunity to create immediate value for the user. The MVP will not be exactly what the users wanted, but it will bring them one step closer to solving their problem. Instead of waiting a long time for the potentially perfect solution, you create small bits of help along the way to the full product.

So, let us head back to my project. My team and I are working on a possible digital service in relation to a physical product. We already have a digital product for the same target group. Our first step was defining our MVP. What would create user value and give us real feedback? Well, maybe informing our users about this physical product existence, and describe how it works. Just adding text in our digital product. Super easy and low effort, and enables us to track the effect this information has on the use of the real product. It is not even close to the digital service we might end up with - but, at this point we do not know if it is a digital service we should be making either!



…


Many designers are afraid their work will fall apart when forced into an MVP approach. But done right I believe your work as a designer can flourish and become more accurate. However, creating an MVP is not always the correct approach in digital product development. My point here is that even if such an approach may conflict with design methodology, it is not necessarily wrong. As designers we need to adapt our workflow and methods to the increasing speed of the digital world. Even though it hurts to release something that your gut tells you is not ready, it might be the best thing to do for the product and your users. We learn and grow the most when we go out of our comfort zone, so the pain is not necessarily bad, even though it hurts (so good).




So, let us sum this up:

You will have to feel the pain of letting go of something that is not even half of what it should have been.

You have to think short-term, day-to-day in some cases, even when your brain is screaming “IT’S ALL CONNECTED! I CAN’T BREAK IT INTO BITS AND PIECES!”




… but on the other hand

You will always have up-to-date user insight

You will have more granular knowledge about the use of your product

You will be able to make changes fast (fix bugs, tweaks ect.)

You will create value for your user earlier..




And, before you throw yourself out there. Here are some must haves when working with MVPs

A team who values user centered development

Logging: Tracking is key to learn as much as possible. Know your products numbers.

Iterations: Anyone on board in this process need to understand that there will be rapid iterations. Without iterations, logging and a user-centered approach your product will stand alone as a far from finished and not an MVP.

Do a more qualitative, thorough research from time to time. It helps on the holistic evaluation of the product, and trigger the long perspective.





…

A big thank you to Ola, Jens Andreas and Sonja for help along the way!





Hurts so Good

Trenger man egentlig designer og forretningsutvikler i produktteam?

I Bekk snakker vi mye om viktigheten av å jobbe kontinuerlig i tverrfaglig team og hvilken verdi det gir produktene vi jobber med. Denne artikkelen handler om det motsatte, da en interaksjonsdesigner og jeg som visuell designer, kom inn på prosjekt for å jobbe med en ny funksjonalitet alene, og utviklerne på teamet var satt til å jobbe med forvaltningsoppgaver. 




Samtidig gjorde denne erfaringen det mulig å få med kunden til å snu den organisatoriske skuten mot en tverrfaglig og kontinuerlig leveranse. Vi ønsker å dele hvordan vi jobbet i de ulike prosessene, hvilken effekt de har hatt på motivasjonen i teamet og hvilken verdi det har gitt produktet og brukerne. Det skal sies at vi i skrivende stund står midt i endringen, og vi holder fortsatt på å justere og iterere på de forbedringene vi har iverksatt.






Litt om kunden og systemet.

Systemet er et digitaliseringsprosjekt som automatiserer behandling av oppgjør. Dette blir brukt av ca 30 brukere som sitter spredt rundt i hele Norge. Disse brukerne er gruppert inn i 4 regioner: Nord, Sør, Øst, Vest. Og for hver region finnes det en spesifikk bruker som er utnevnt til representant (og kalles heretter: representanter). Ansvaret til representantene er å forankre endringsønsker som kommer fra brukerne til produktteamet og å være brukernes talerør.






Tidligere fossefallsprosess, hindringer og feilskjær.


Etter å ha reflektert rundt denne erfaringen er det noen deler av arbeidsmetodikken som utpeker seg som bidragsytere til at det som skulle bli en suksess, ble et feilskjær.


Jeg vil starte med organisasjonsstrukturen og kulturen hos kunde(se modell 1). Den la noen føringer på hvordan informasjonsflyten gikk fra brukerne, som første ledd, til utvikler og designer, som siste ledd. Informasjonsflyten hadde likhetstrekk med en formell hviskelek. Når et endringsønske oppsto formidlet en bruker dette til sin regionale representant. Deretter gjenga representanten dette ønsket videre i et ukentlig møte med kunden, som igjen videreformidlet dette til oss i et neste mulige møte. Ved spørsmål til endringsønskene, gikk feedback-loopen tilbake til brukerne i de samme stegene via de samme møtene.



En annen ting som utpeker seg er at design og utvikling jobbet med helt ulike oppgaver. Designoppgavene var nyutvikling av systemet og utviklerne jobbet med forvaltningsoppgaver, men vi hadde jevnlige, men i grunn for få, møter hvor vi kunne diskutere og revidere nyutviklingsarbeidet. Ved at vi jobbet på ulike oppgaver var ansvaret rundt det å lage det riktige produktet også kjempestort. I perioden hvor designerne jobbet med utarbeidelsen av designet til ny funksjonalitet var ansvaret kun på våre skuldre, og utviklerne fikk både den massive overleveringen i tillegg til ansvaret på sine skuldre i etterkant. Det var mye ansvar i ulike perioder for begge, og stafettpinne konseptet ga ikke trygghet for noen av oss. Fordi utviklerne ikke var tett nok på arbeidet med å utforme designet fant de noen uoppdagede tekniske utfordringer i det de skulle i gang med implementasjon, og utviklerne satt med flere spørsmål til en designressurs som ikke var tilgjengelig på det tidspunktet. Usikkerheten om at de løste faktiske behov gjorde at implementasjon av designendringene ble utsatt.


En tredje faktor er at vi ikke fikk deploye til produksjon selv. Så når et endringsønske endelig hadde nådd frem til oss, blitt tolket og bearbeidet, designet, utviklet og testet, måtte den gjennom nok et ledd før den faktisk ble tilgjengelig for brukerne.


Resultatet av disse faktorene var lang delay fra endringsønsker til realisering av behov, og i noen tilfeller ble ikke funksjonaliteten brukerne trengte implementert i det hele tatt.




Det vi lærte av feilskjæret:

Direkte kontakt med brukerne minimerer risiko og tidsbruk

Det er viktig å finne ut i prosjektoppstarten hvem som har mandat til å kunne endre kurs på prosjektet, eller som produktteamet må ta hensyn til, og inkludere alle i prosessen

Vi må ha tydelige mål helt fra starten av, og sammen bli enige om hva det riktige produktet vi skal lage er, og hvorfor

Viktigheten av å forventningsstyre omfang og scope ned oppgaver slik at designer også er tilgjengelig i implementasjonstiden

Designrelaterte oppgaver må inn i prosjekttavlen og være en del av teamet

Det er stor sjanse for at designet må etterjusteres på grunn av tekniske avhengigheter

Design og utviklingsressurser må være tilgjengelig om brukergrensesnittet skal endres på

Alle fagområdene skal være representert og har ansvar for nyutvikling og justering av systemet

Design er ferskvare som fort går ut på dato






Starten på prosessendringene.


Vi har gjennom årene på prosjektet opparbeidet oss mye tillit hos kunden og vi har tatt ansvar utover egen rolle på prosjektet. Dette har bidratt til at vi har hatt god oversikt over historikken, vi har kunnet samle erfaring rundt suksesser og feilskjær, og vi har hatt kunden med på laget. I år startet jeg igjen på prosjektet sammen med en interaksjonsdesigner med mål om å jobbe med forbedring av arbeidsprosessen i teamet. Det var tydelig at vi måtte gjøre noen endringer (se model 1), og vi ønsket å jobbe mer kontinuerlig og ha designer tilgjengelig i implementasjonsperiodene. Sammen med interaksjonsdesigneren planla og fasiliterte vi workshops for å sette nye mål, revidere samarbeidet med interessenter og brukere, og forbedre produktutviklingsprosessen. Videre jobber vi med å følge opp prosessendringene som teamet ble enige om i retroer, og med å skaffe brukerinnsikt og designe forbedringer på selve grensesnittet ut fra de nye målene.




De store effektene

Resultatet av denne endringen er først og fremst at vi er blitt et produktteam (kunde og bekkere), vi får ut små og verdifulle endringer ut i produksjon, og vi har anledning til å iterere på dem sammen.





Vi er ikke helt i mål med informasjonsflyten et endringsønske tar, men produktteamet tar oftere direkte kontakt med brukerne for å diskutere dem. Vi jobber også med å få opprettet et brukerforum i slack, hvor vi kan stille kjappe spørsmål, dele små endringer og hvor de kan dele erfaringer på tvers av kontorer og regioner. I dag kaller vi inn til digitale møter via mail, og erfaringsmessig er feedback-loopen for lang og det tar unødvendig mye tid å organisere.


Vi har opprettet en ny kanban-tavle med fokus på mål som gjør at vi har en tydeligere plan enn hva vi hadde tidligere. Brukerne, representantene, kunden og bekkere jobber mot det samme målet, og det gjør det både lettere å samarbeide og det er mye mer motiverende når alle tar del i retningen produktet skal ta. Det er givende å se at vi leverer verdi til brukerne sammen, og dette igjen styrker samholdet i teamet. Alle fagområder er inkludert i de ulike møtepunktene og kommunikasjonsverktøyene, og det har gjort utviklerne og designer(ne) tryggere i kundemøter når vi vet at hvert fagfelt er representert. Ikke minst tar vi del i prioriteringsmøtene med kunde og representantene. Hver måned har vi også retroer, ett med produktteamet og ett hvor vi også har med representantene. I produktteam-retroen går vi også gjennom prosesstiltak og følger opp dem.


Vi deployer selv! Nå har vi mulighet til å rulle ut nye endringer når vi vil, samt trekke de tilbake. Ulempen med færre deploys er at vi kan glemme hva som ble lagt ut og sjansen er større for å ikke kunne klare å rette opp i eventuelle feil som oppstår. Når vi har raske deploys kan vi legge ut endringer når vi (utviklere og designere) er klare, og være mer på hugget til å fikse ting.


Utviklingsteamet har også i denne perioden jobbet med et felles designbibliotek og satt designet i system. Selve designet har også utviklet seg og tilnærmet seg i større grad hvordan komponenter bygges i kode. Ved at jeg har hatt et tett samarbeid med utviklerne har vi sammen funnet bedre måter å bygge designet på. Verdien av dette er at utviklerne og designerne nå snakker det samme språket, og det blir enklere å forutse noen av de tekniske avhengighetene og vi får en felles forståelse av prinsippene til designet og koden.


→ Neste nye på listen er teambuilding i februar med produktteamet og de regionale representantene, og det gleder vi oss til.




Stor takk for bidrag til artikkelen av Håkon Teigen Lund, Niklas Molnes Hole, Maia Elisabeth Sirnes og Ingrid Hjulstad!

Fra fossefall til kontinuerlig leveranse

Drypp er en lavterskel podcast fra Bekk.

En liten gjeng samlet inn heftige påstander og inviterte til Drypp-innspillingskveld på Trondheimskontoret - med julebrus, godis og god stemning. Resultatet ble seks episoder med brannfakler. God lytt.

Brannfakkel - Er design nødvendig da? (Del 1 av 6)

This is a short story where you learn about bad UX, defining problems, and Norman doors. Nah... It is actually just a story about how I hacked the main door to the apartment building I live in. It does not necessarily have anything to do with design, but more about my experiences of everyday things, in particular keys.

    

I’m going to start with the Norman doors.
Because this article is not about Norman doors. But I wanted to give Donald Norman a little homage for his focus on everyday problems. A focus that’s often forgotten. We are so used to bad UX that we don’t even bother to complain or fix it. One of his examples is doors that do not tell you whether they are push or pull, later called Norman doors. Why have we not fixed it? Nobody bothers, or have we just forgotten that they are shitty designed? I don’t know… But last year I had an experience that made me think about Donald Norman again.


The problem: shrinking keys
A year ago, I moved into my brand-new apartment. I had been waiting for 2 years, following the construction work, and choosing the customizable additions that were available. One thing I paid extra for was a keyless door. What a dream it would be to live a life without keys!

The one thing that made me believe that the wizarding world existed was this phrase from J. K. Rowling’s Harry Potter:

Sell them a key that keeps shrinking to nothing so they can never find it when they need it. …Of course, it's very hard to convict anyone because no Muggle would admit their key keeps shrinking — they'll insist they just keep losing it.

I’m pretty sure that someone has shrunken my keys several times, and obviously, Rowling and all other muggles feel the same way. Never again!


The good news is that you’ll get this RFID tag instead of a key!
So, I walked into my new apartment, it was wonderful, a code was everything I needed. Or at least I thought so… The main door to the building fucked it all up. It was smart and techy, but they said: “Codes are not safe enough, but the good news is that you’ll get this RFID tag instead of a key!”.
Someone just shrank my keys down to a tiny plastic piece that is bound to disappear, it does not even have enough weight to stay in the bottom of my pocket!

Why does this product even exist? If you look at the problem we are trying to solve, one thing is obvious, replacing a key with a tiny plastic piece is NOT solving anything!





Let's solve the problem, at least for me!

Define the problem: Shrinking keys.

Define the goal: No need for keys.

User journey: Drawing of a normal life with more space in my pockets, and no lost-my-key-again-situations.

As a designer, I did my research and found some useful insights. The door could be opened from my doorbell answering unit. I had WIFI in my apartment, and the user (me) always have his phone with him. I skipped the sketching and went with my first and best idea, prototyping with Arduino!

I had to test this several times to get it to work. In short, it's a touch pen that mechanically pushes down onto the open-door button on my answering unit. Then I made a simple app on my phone using Blynk. I have no idea how to make an app, but Blynk was easy. Connected it with my Arduino design, and whoops! Just flick the Alohomora button on my phone anywhere in the world (if I have an internet connection) and the main door on my building opens.








Do not accept bad UX
Did I solve the problem? Yes! Did I make the world a better place? Yes, but only for myself. Has anyone solved this problem before? Probably, but I think people, in general, are so used to being annoyed about everyday things like this, that the value of fixing these problems is so low that they won’t be prioritized.

My hope is that people designing apartments, or anything else, look at the whole service and experience of the user. Prioritizing to fix these everyday problems. But since everybody expects it to be bad, it won’t have any influence, people buy apartments either way. The worst is that they are tricking us into paying extra just to be able to have a code in addition to the key. No problem solved, just a lot of money used.

So please, everybody that has endured this little story, do not accept bad UX and prioritize problems 🙏


--- 

“The Design of Everyday Things” by Donald Norman

Blynk for everyone interested in Arduino

How many designers do you need to open a door?

Taking on the multifaceted role of facilitator can be intimidating. Get started by playing to your strengths.

Quick – Conjure up an image of a “facilitator.” What pops into your head first? As a UX designer, my image is heavily influenced by the era of the “Google Design Sprint.” I see a thoroughly planned workshop, with post-its covering every surface available. And the facilitator herself? Whiteboard marker in hand, she is a commanding presence in the front of the room and a major participant in discussions.



But facilitation is so much more than just this. Though a post-it wielding workshop leader is one very visible form of facilitation, facilitation as a tool that can be used in a wide variety of situations and take many forms. Unfortunately, many people shy away from facilitation because they do not feel comfortable with this traditional style – even though their teams desperately need the help.

The goals of facilitation

If you have a great team with high psychological safety and impeccable communication skills, you may be able to get by without a facilitator on your team. For the majority of us however, facilitation skills are a necessity as there are a couple of things that tend to go awry when groups of people work together. Have you ever scheduled a meeting to land a direction, discussed the issue for an hour, but left with no clear answer? Or been in a water cooler discussion with a colleague where you thought you disagreed, but found out that you were actually talking about the same thing? What about when a workshop is taken over by a strong personality, or even worse – people don’t share their opinions because there is a HiPPO in the room.


It is in these situations a facilitator can really shine. They can help to guide a group’s output, help participants understand each other’s viewpoints, create alignment and shared ownership, and moderate discussions so that everyone can participate. But there are many ways to do this, not all of which look like the typical sprint facilitator.

Like leadership, facilitation has many different styles.

Because facilitation has such a wide variety of goals, it can take a variety of forms. A facilitator can be the focal point at the front of the room, or working in the trenches. They can focus on creating engagement and participation, or ensuring useful output. Generally, facilitation falls into four “styles”:



The Energizer: Motivates people to think creatively and participate. Has a contagious energy.

The Driver: Keeps everyone on schedule, and maintains forward progress. Focuses on landing decisions or getting to the finish line.

The Diplomat: Builds trust, good will, and collaboration within the group. Tuned into individual needs and attitudes in the group.

The Interpreter: Reveals hidden connections and sees the big picture. Picks up on the essence of ideas and translates participants’ loose thoughts into clear terms.


Know your style: Play to your strengths and know your weaknesses.

An experienced facilitator switches between these styles to meet the needs of the group and situation. They put on their Energizer hat when motivation is low, but just as easily take a step back into the Interpreter when the conversation demands it. For most facilitators just getting started however, one or two of these roles comes more naturally than the others. Don’t try to be an Energizer just because that is what a typical Design Sprint facilitator looks like. Like leadership, facilitation works best if you play off of your strengths, personality and style. Weak on getting participation? Ally yourself with a participant who is good at cracking jokes and putting everyone at ease. Weak on ensuring outcomes? Display a digital timer on the board, or give a participant responsibility to watch the clock. By knowing your facilitation style, you can better play to your strengths and find ways to work around your weaknesses to step up in a big way for your team.


Happy facilitating!

Design