Ofte setter vi oss selv i situasjoner der vi tenker for komplekst på problemstillinger; vi gjør dem mer komplekse enn det trenger å være. Et enkelt prinsipp kan benyttes for å dele et problemer inn i mindre, mer håndterbare delproblem, som kan bidra til mer analytisk tenking og dermed forenkle problemet.

Hvorfor havner vi ofte ut på en kompleks reise når det kommer til problemløsning?

Barbara Minto skrev i sin bok "The Pyramid Principle: Logic in Writing and Thinking," om et viktig aspekt ved problemløsning og kommunikasjon:



“The problem was the thinking, not the language,” (Minto) says. “People were starting to write without working out their thinking in advance. But how does one go about figuring out one’s thinking in advance?”



Hun understreker at mange begynner på løsningen før de har klargjort tankene sine. Dette fører til unødvendig kompleksitet og forvirrende tanker. Mintos poeng er at utfordringen ligger i å organisere og klargjøre våres tanker før vi kommuniserer dem.

Dette belyser et sentralt punkt i hvorfor vi ofte havner ut på en kompleks reise når det kommer til problemløsning. Minto antyder at løsningen ligger i forhåndstenkning, altså det å strukturere og bearbeide våres tanker før vi prøver å uttrykke eller løse dem.



MECE prinsippet

MECE er et grunnleggende prinsipp når det kommer til problemløsning. MECE står for "gjensidig utelukkende (Mutually Exclusive)", "samlet uttømmende (Collectively Exhaustive)". Dette prinsippet bidrar til klarere tenkning og forenkler komplekse problem ved å dele dem opp i mer forståelige, distinkte deler.



MECE-prinsippet følger to spesifikke regler for å kunne forenkle komplekse problem. Disse to kategoriseringsreglene er:

Gjensidig utelukkende (ME): Et delproblem kan kun være i én kategori om gangen.

Samlet uttømmende (CE): Alle delproblemene må inkluderes i én kategori; kategoristrukturen kan ikke utelate et delproblem.



Dette sikrer et klart og fullstendig perspektiv på situasjonen, hvor alle alternativene blir synlige. "gjensidig utelukkende" garanterer at elementenes uavhengighet forhindrer overlapping, mens "samlet uttømmende" sørger for at ingen dimensjoner eller mulige løsninger blir oversett. Denne helhetlige tilnærmingen gjør at problemet blir delt opp i mindre delproblemer, og gir deg en tydelig oversikt over hele problemet.



Hvordan funker prinsippet i praksis?

For å forstå prinsippet er det nyttig å se på et enkelt eksempel, dette kan vi gjøre ved se på en problemstilling rundt inntekter og kostnader av en bedrift sine ulike avdelinger.



Problemstilling: En leder ønsker å analysere bedriftens inntekter og kostnader

Gjensidig utelukkende (ME): Bedriften deles inn i tydelige avdelinger som Regnskap, Markedsføring, Salg, HR og IT. Hver ansatt blir kun satt til en avdeling for å unngå overlapping.

Samlet Uttømmende (CE): Alle avdelinger i bedriften inkluderes i analysen for å sikre at ingen områder blir oversett, og at alle inntekter og kostnader blir vurdert.



Dette eksemplet viser hvordan MECE-prinsippet kan brukes for å strukturere en kompleks analyse på en klar og oversiktlig måte.



Områder der du kan bruke prinsippet

Bruksområdene for MECE-prinsippet er mangfoldige, spesielt innen organisering og strukturering av data. Her er noen områder der MECE prinsippet er nyttig:



Nedbrytning av komplekse problemstillinger: Del komplekse problemstillinger ned i distinkte hypoteser for enklere analyse og løsning.

Deling av prosjekter i arbeidsstrømmer: Bryt ned prosjekter i separate, klart definerte arbeidsstrømmer for effektiv håndtering og gjennomføring.

Valg av KPI-er: Velg KPI-er slik at hver av de måler et distinkt aspekt, uten at de overlapper hverandre.

Forenkling av data: Reduser lange lister med data til et oversiktlig sett med nøkkelideer, slik at hver idé representerer en unik del av dataen.

Gruppering av informasjon: Organiser informasjon i klart definerte, ikke-overlappende grupper for bedre oversikt og forståelse.

Strukturering av presentasjoner: Organiser omfattende presentasjoner i distinkte seksjoner der hver seksjon dekker et unikt tema eller poeng.

Sammenfatning av artikler:Forenkle artikler med mange seksjoner til noen få sentrale hovedtemaer for å fremheve de mest kritiske punktene.

Opprettelse av sammendrag: Lag korte, presise sammendrag av komplekse temaer, hvor hvert punkt dekker et unikt aspekt av temaet.

Utforming av spørreskjemaer for innsikt: Lag spørreskjemaer med eksklusive og uttømmende svaralternativer, slik som å liste alle avdelinger i et avdelingsvalgspørsmål.

Utforming av menyer: Skap menyer der hver del er klart definert og unik, for å gjøre det enkelt å forstå og velge det som er mest relevant.



Dette er et prinsipp som fungerer godt i de fleste tilfeller hvor du står overfor et problem som er komplekst, enten det er i en privat eller profesjonell sammenheng. Ved å bryte ned problemet i mindre deler som er "gjensidig utelukkende", altså at de ikke overlapper hverandre og "samlet uttømmende", der alle relevante aspekter blir inkludert, kan du unngå at viktige detaljer blir oversett. På denne måten sikrer du en grundig og strukturert tilnærming til problemløsning, noe som bidrar til en mer effektiv og oversiktlig håndtering av utfordringen.





Du kan benytte prinsippet overalt, du må bare finne ut når det er riktig for deg ❤️

MECE prinsippet for å forenkle ethvert problem

Simplicity is beautiful. But our world is complex. How can you start with simplicity, defer decisions, and introduce complexity as needed without multiplying the effort?

You've heard it a thousand times; "Keep It Simple, Stupid!", repeated as a mantra when faced with a decision that might introduce complexity. And for good reason; simplicity is often the right choice. But when is it not? And what, exactly, is simplicity?

Our job as developers is to develop solutions to problems. The problems can appear simple:

How can I find the closest free scooter?

Or the problems can appear harder:

Given collected traffic data for the last 5 years, how can I predict where accidents are more likely to happen in the future?

Regardless of the apparent complexity of a problem, experience dictates that:

Problems are always more complex than they seem at first

Problems can always be broken down into smaller problems







Let's introduce an example:

You are making a new web app using ASP.NET Core MVC:

You get a folder for your controllers, one for your models and one for your views. Simple, right? But what happens as you keep adding more controllers, models and views? Pretty soon you'll end up losing control, and will have to refactor your code, perhaps ending up with multiple layers of coupled code.

Instead

Keep it simple, not stupid!

Når er egentlig riktig tidspunkt å forstyrre sidepersonen?

Hvor mange faglige spørsmål har du i løpet av en dag?

Jeg har hundrevis. “Hvordan skrives en dato i C#?”, “Hva er egentlig dependency injection?”, “Hvorfor er skjermen gul — kodeendringen burde jo ikke ha ført til en feil?”.

Hva gjør du med spørsmålene du har?

Jeg stiller dem ofte til teamet. Selv om jeg alltid blir møtt med tålmodighet og gode svar, tror jeg ikke dette er det første du bør gjøre.

Ta eksempelet med å bli møtt med en nettside som kræsjer. Jeg har flere ganger blitt møtt en mystisk feilmelding, og instinktivt spurt andre teammedlemmer om de har sett feilmeldinga før. Det første de gjør er å gjøre et søk på nett, og løsningen står som første resultat.

Andre ganger kan jeg spørre ting som “hva er egentlig dependency injection?”. Så får jeg en forklaring, men forklaringen går rett over hodet mitt. Vosj.

Om du alltid stiller spørsmål til teamet ditt før du prøver selv, tror jeg du taper både mestring og stjeler tid fra både deg og teamet ditt. Jeg tror du gagner mye på å prøve minst 15 minutter på egenhånd.

15-minuttersregelen

15-minuttersregelen innebærer at du ved et hinder venter minst 15 minutter før du ber om hjelp fra teamet. I disse 15 minuttene prøver du selv å løse problemet. Om du etter 15 minutter ikke har noen retning, kan du spørre.

Grunnen til at jeg tror denne regelen kan være nyttig, er at jeg tar meg selv i å stille spørsmål som er veldig googlebare. Om det er et spørsmål med en enkel fasit, kan det være raskere å bruke en søkemotor enn å spørre en person.

Alle spørsmål er ikke like enkle. Noen ganger kan det du lurer på være uklart, så du vet ikke engang vet hva du skal spørre om. Du vet du skal sette opp dependency injection, men vet ikke hva dependency injection er. Du mangler noen knagger.

Uten knagger kan det være vanskelig å forstå forklaringer eller stille spørsmål. Løsningen kan være å bruke hinderet som en læringsmulighet. Tillat deg hvert fall 15 minutter på å danne noen knagger. Les deg opp på dokumentasjon, bloggposter eller se en YouTube-video på temaet. Det er litt greiere å sparre om oppsett av dependency injection, om du først har funnet ut hva greia med dependency injection er.

15-minuttersregelen innebærer ikke at du må bli ferdig innen 15 minutter. Å sette opp dependency injection, og sjekke om det er rett, kan jo ta timesvis. Det kan også hende at du er på vei mot en løsning etter 15 minutter, men heller ikke da må du be om hjelp. Det viktigste etter 15 minutter er å ha en retning. Om du ikke har det, bruk teamet rundt deg.

Men hvordan ber du om hjelp?

Hvordan ber du om hjelp?

Hvem av disse er det enklest å hjelpe?

Aksel:

Kan du hjelpe meg med å åpne syltetøyglasset?

Bård:

Kan du hjelpe meg med å åpne syltetøyglasset? Jeg har prøvd å holde lokket med en hånd og vri glasset med den andre.

Bård kommer med ting han allerede har prøvd, så jeg vil hvert fall ikke foreslå det. Her sparer vi begge tid. Jeg kan foreslå uprøvde ting, som å sette lokket under varmt vann. Jeg tror det også kan være lettere å sparre med Bård om løsninger, siden han har forsøkt noen løsninger og dermed har noe bakgrunnsinformasjon.

Etter å ha fått til vane å liste opp hva jeg har prøvd, blir 15-minuttersregelen trigget om jeg skriver et ensomt spørsmål på Slacken. Noen ganger glemmer jeg rett og slett å sjekke åpenbare løsninger, som å google en feilmelding. Så om jeg ser meg selv stille et ensomt spørsmål, prøver jeg hvert fall 15 minutter, og ser om jeg får noe retning.

Mange ganger er jeg Aksel.

Jeg ønsker å åpne et syltetøyglass, men vet ikke hvor jeg skal starte. Kan du hjelpe meg med en retning?

Jeg syns også det å spørre om retning kan være et fint spørsmål. Du viser hva du ønsker å løse, og du viser at du er villig til å jobbe mot å finne løsningen. Du trenger bare litt hjelp med å starte.

Avsluttende ord

Mitt mål med å formidle 15-minuttersregelen er todelt:
1) å oppfordre de som spør ved første hinder til å se etter en løsning selv først.
2) å oppfordre de som jobber for lenge på egenhånd, å ta kontakt med den store ressursen teamet deres er.

15-minuttersregelen har hjulpet meg med å finne svar på ting jeg lurer på. Jeg tillater meg mer tid på å forstå rundt problemet, så jeg får mer helhetsforståelse. Det gir meg mestring å oftere finne svaret på egenhånd, selv når det bare innebærer å google en feilmelding. Jeg får også mestring av å være en aktiv part i sparringen.

For 15-minuttersregelen handler ikke om å slutte å spørre om hjelp. For all del, utnytt kompetansen teamet ditt sitter med. De har møtt på lignende problemer, så de kan hjelpe deg. Og når du finner løsningen, er andre interessert i svaret. Kunnskapsdeling er bra for et team.

Det er noen scenarioer hvor 15-minuttersregelen ikke er relevant, som når du sitter og jobber tett sammen med en annen. Du trenger heller ikke å vente 15 minutter om du parprogrammerer med en annen. Eller at du vet at en annen nettopp har løst samme problem. Teamarbeid handler ikke om å bare gi svar til hverandre, men også å diskutere løsninger.

Jeg håper denne posten kan hjelpe deg å ta et hinder som en utfordring. Jeg håper du først prøver å løse problemet på egenhånd og tar deg tid til å lese deg opp om temaet rundt problemet. Også håper jeg du ikke venter for lenge med å spørre om hjelp når du står fast.

Når syns du at man bør be om hjelp fra teamet?

Når bør du be om hjelp fra teamet ditt?

We must become more aware of how we potentially pollute the data we collect from users.



I love conducting user interviews and user tests! But I don't really know what I'm doing. Through our education, designers learn how to collect user data. The methods we learn are mainly based on interviews, testing, workshops etc. But we are not trained well enough in how the data we receive must be obtained as cleanly as possible. We need to be more aware of how we potentially "contaminate" the data we collect. We ask leading questions, we suggest what they should do, and we interpret their actions in the best sense.

More than once I have caught myself saying something like "Yes, you probably knew that was where you were supposed to press". And I have probably more than once set up an user interview where I actually already know what I want the user to answer. Give me a UX researcher who can set up good moderated interviews and tests. Or a data analyst who knows how to handle data and how it should come in straight from a production environment, without me having had the opportunity to pollute that data. Because the data I bring in through interviews and tests is tainted by my own biases.



Original illustration made by DeeKay Kwon


It gets messy

I am not asking that anyone else retrieve that data for my own sake, but for everyone else's. I really enjoy conducting user tests, while getting to confirm or disprove my own assumptions. But the data is and remains dirty. It will be like bringing a child to bake buns. It gets messy, and there is always a bit of snot in the dough. It may taste quite good, but there is still a bugger in that bun.

Before an interview or a test, the team should have made themselves aware of which biases they potentially bring with them and how we can be as neutral as possible. Perhaps you can even retrieve the data you are looking for right from a production environment? Then you can rather use interviews and tests to obtain data on things that cannot be obtained directly from prod. The result of a good user interview or a good user test should be a set of data that we have jointly reviewed and checked that we have not mixed our own biases or interpretations with what the user actually said or did.


So let someone else obtain that data

Include me in the interview and the user test, and include me in the process, but there are others who are more qualified to guide the user through. Include me in the work of setting up measurements for production data, but let someone who knows which biases can affect the data take the lead.

I may not be the best at obtaining clean, untainted data, but what we designers are actually good at is analyzing that data and processing it into insights that are understandable to others, and that can be used as a knowledge base for further decisions in the team. Together let's boil it all down to insights that we can use. I think we often get a truer picture of reality by getting good data straight from prod, rather than conducting interviews and user tests all the time. Let someone else obtain that data.

🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥

What did you feel while reading? Did it spark something in you? Do you agree or disagree? Join the discussion on UX Norge's slack (Norwegian) or share this article with your colleagues and start a debate! Remember that the goal of Brannfakler is to start discussion!

Someone else can obtain that data

Universell utforming. Vi vet alle hva det er, vi vet alle at det er superviktig - og riktig! - å få til, og vi snakker om det hele tiden. Og den aller vanligste måten å jobbe med det på, er fremdeles som tunge skippertak en gang i mellom. Hvordan får universell utforming til å bli en del av teamhverdagen? 

Det åpenbare svaret - som jeg også hører fra designere og utviklere når jeg spør om hvordan de håndterer uu i løsningen sin i hverdagen - er at "de må tenke på det på hver oppgave, og hver gang de slipper noe ut i prod: har vi sikret uu på dette?"

Og det høres så såre enkelt ut. Men hadde det vært så enkelt, så hadde vel ikke løsninger likevel vært så mangelfulle på når det kom til universell utforming? Så hva er det som kommer i veien for at vi faktisk sikrer det løpende?

Jeg har to hypoteser:

1. Tverrfaglighet smerrfaglighet
Det jeg synes jeg hører absolutt oftest fra designere når vi snakker om uu, er: "...men det er liksom utviklerne som må gjøre det". Og så vaskes det hender overalt ut i fra det. Og ja - opprettholdelsen av uu krever riktig koding. Men hva ved brukeropplevelse gjør vel ikke det?

Og så er jo tverrfaglighet i seg selv fremdeles vanskelig i mange team. Jeg ser fortsatt boards hvor design basically har sin egen kolonne, eller egne "brukerhistorier", og designere som sukker over at de blir sittende uten så mye å gjøre "fordi utviklerne utvikler". Det er ordentlig vanskelig å spenne over faggapet - eller egentlig å fylle det, sånn at det ikke oppleves som et gap. Måten man snakker sammen på, og deler ansvar og utfører ting sammen på, krever konstant øvelse. Og når det er vanskelig for oss i de fagene vi er så godt kjent med - da er det ikke så rart, kanskje, at det blir vanskelig med uu, som vi vel alle er ganske usikre på, alle sammen.

2. Universell utforming er et "sjekkpunkt"
Jeg tror uu er litt som måling: i et halvmodent team, så snakker vi om det, og minner oss selv på at "det må vi gjøre" - men så er det forbanna vanskelig å likevel gjøre det. Det blir stående som en egen oppgave eller aktivitet - og dermed kan den også prioriteres opp eller ned.

I et team som er modent på måling, er måling helt integrert i teamets hverdag. Da er det ikke et eget punkt på en liste, og hvert fall ikke en egen kolonne i et board - for teamet prater om det hele tiden, det er selvsagt at ting måles, og hver funksjonalitet bygges med målingsbehovet i tankene. Det blir en del av flyten. Det kan fortsatt prioriteres opp eller ned, men det prioriteres integrert med funksjonalitesprioriteringen. Jeg tenker at uu er litt det samme. I ordentlig modne team på uu, er ikke "uu" på et område en oppgave som må assignes noen. Det er ikke noe som må stå på en liste som må krysses av. Det er mer som måling eller sikkerhet - når du utformer løsningen som designer, er det en integrert del av arbeidet du gjør, og når det implementeres i kode, er det en integrert del av tankene du gjør deg. Og det diskuteres sømløst som en del av utforming og utvikling av funksjonaliteten - ikke som en separat greie.

Hva tror dere?
Stemmer hypotesene? Eller er det noe helt annet som kommer i veien?

Hvordan får vi universell utforming til å bli en del av teamhverdagen?

Ragnhild thinks we should put detailed prototypes to rest, and rather get our designs out to the public faster.



Hi there! Did I catch you in the act of making an ultra-complex, clickable prototype in Figma? If that’s the case, it’s time to stop right now and think anew!

The intention is good

While studying design at university, we learned that a traditional design process usually starts with some preliminary research which – after some analysis – leads to a concept phase where we can think of solutions. Often, this concept phase culminates in the creation of a prototype and accompanying user test. The goal is to check whether our ideas are understandable and usable for our future users.

At first glance it’s easy to applaud this approach because we are working to limit risk by testing our ideas before we spend resources developing them. I’ll admit that the intention is good – but one doesn’t get very far with good intentions when they end up wasting our time and giving us unreliable insight.


A time thief

Because yes, we open Figma, switch over to prototyping mode, and start the hairsplitting process of creating micro animations and hover effects. After a long while, we unravel the ultra-complex flow charts necessary to make sure all buttons are clickable wherever and whenever. And when the job is done, we’re left with a false product which in all likelihood – despite all the hours spent – doesn’t work exactly as it should. The weeks have flown by.

This is where all the alarms go off… We’ve got to stop spending several weeks sitting alone and nitpicking on something that soon will gather dust in a digital drawer.

Our mission as designers is to create value – for the end user, the organization we work for, and society. Creating a false version of a service in Figma with just a small new feature isn’t value creation. If your team is organized well and you have an agile approach, you’re hopefully only testing out a small part of a bigger totality. If so, it’s a waste of time making a half-good pretend variant of the service in Figma just to test a small piece. Get it out in the real world at once! Learn from real interaction. Collect insight from real behavior to understand how the service is actually used.


Insight we can’t trust

Talking about insight. User tests, which is usually the end goal of prototyping, gives us a potentially false understanding of the usability of said prototypes. Here’s what we’re doing: We’re testing a fictional service – which doesn’t work as it should – in a fictional environment. Furthermore, we’re asking questions which are unavoidably biased by the pride and ownership we’ve grown for the masterpiece we’ve spent so many hours creating. And this affects us, whether we like it or not.

So let’s just bury the complex Figma prototype today and instead do our testing out in the actual service. Test where people interact in their natural environment without the disturbance from weaknesses in the prototype, bias, or the pressure of feeling observed. Today, we’ve got amazing opportunities to collect and analyze behavioral data from every interaction people have with the stuff we make.



Is it necessary?

Before I round off, I'd like you to reflect on the following: Is your design really so complex, groundbreaking, different, and revolutionary that you have to test it before people out there get to try it out? With all likelihood, the answer is “no”. Plenty of smart people have walked this path before you. And I’m pretty sure your design intuition is good enough to test ideas live. The “worst” that could happen is that you’ll need to iterate if the design didn’t work 100 % the first time around. And that’s a valuable lesson too!

So please: Don’t waste valuable time sitting alone and creating beautiful, complex prototypes in Figma. Work with your team, be agile, and test things live. Let’s kill the prototype.

🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥

What did you feel while reading? Did it spark something in you? Do you agree or disagree? Join the discussion on UX Norge's slack (Norwegian) or share this article with your colleagues and start a debate! Remember that the goal of Brannfakler is to start discussion!

Let's kill the prototype

Hvordan spenne beina på et IT-prosjekt? (Del 3 av 3) - Abstraksjoner

Hvordan spenne beina på et IT-prosjekt? (Del 2 av 3) - Motstridende forretningsmål

Hvordan spenne beina på et IT-prosjekt? (Del 1 av 3) - Hyppige endringer av kravspekken

En klassiker i forbindelse med jobbsamlinger er teambuilding-aktiviteter. Enten det er kickoff eller juleavslutning, er teambuilding et kjent og kjært innslag på programmet. Jeg vil slå et slag for at teambuilding er en unik mulighet som bør utnyttes. 

Siden 2016 har jeg hatt teamlederansvar. Det har blitt en del runder med teambuilding og sosialisering. Begge har sin plass, men jeg synes begrepene ofte sauses sammen. Jeg mener det er en betydelig forskjell: Teambuilding handler om å lære hvordan man er som person og fungerer sammen med andre, mens sosialisering er hyggelig samvær. Min hypotese er at man med noen få, enkle grep kan sørge for at de "myke aktivitetene" man gjør i jobbsammenheng blir effektfulle. La oss ta en titt på utviklingen til et team og hva som kjennetegner høytpresterende team for å få en kontekst.

Å bli kjent som team krever innsats

Å komme sammen som en ny gruppe oppleves ofte som en litt klein greie. Kanskje har man noen som byr litt på seg selv og bryter isen. Kanskje er det en empatisk person som sakte men sikkert varmer opp gruppa med nysgjerrige, genuine spørsmål. Som oftest går det ikke veldig lang tid før man blir litt tryggere på hverandre. Da kommer som regel våre styrker tydeligere frem, spesielt de av oss som er mer selvhevdende enn andre. I min erfaring kan det ta tid før folk finner sin plass i teamet. Bruce Tuckman lanserte en modell for et teams livssyklus i 1965 (wikipedia). Denne har over tid blitt de facto standard for å beskrive et teams utvikling. Fasene jeg beskrev over tror jeg de fleste kjenner seg godt igjen i. Tuckman beskriver disse som forming og storming: Alle er på sin beste oppførsel, før man sakte men sikkert blir tydeligere på hva man mener og hvordan man vil jobbe. 

Jeg skal ikke gå i dybden på denne modellen, det har utallige folk gjort før meg på en bedre måte enn jeg ville fått til her. Poenget er at et team nødvendigvis går gjennom disse fasene før man presterer høyt i fellesskap. Heldigvis kan vi, ved å kjenne til disse fasene, ta målrettede grep for å komme dit raskere. På den måten kan vi akselerere utviklingen til teamet, slik at kalendertiden som går før man presterer høyt sammen, reduseres. 

Medlemmer i høytpresterende team er trygge på hverandre

Et stort buzzword i teamsammenheng anno 2021 er psykologisk trygghet. At det har fått så mye plass ser jeg på som en naturlig motreaksjon mot klassisk ledelse: Her ble man ansett som ressurs heller enn menneske. Jeg opplever at motreaksjoner ofte er emosjonelt drevet og lite fundamentert i rasjonalitet. Det kunne ikke stemt dårligere for psykologisk trygghet! De senere årene har en solid mengde arbeid slått fast hvor viktig dette er for prestasjon i team. Som eksempel vil jeg trekke frem Google. De har i årevis jobbet systematisk for å finne ut hva som gir høy effektivitet. I tråd med hva de finner endrer de praksisene og prosessene sine. Dette initiativet heter re:Work (link), og som del av re:Work publiserte de i 2015 resultatene fra Project Aristotle. Navnet kom fra Aristoteles' sitat: "Helheten er mer enn summen av dens deler". Som navnet tilsier var fokuset deres på team, mer spesifikt hva som kjennetegner høytpresterende team. De konkluderte med at det er fem faktorer, hvor psykologisk trygghet er den viktigste:

Psychological safety was far and away the most important of the five dynamics we found

Du kan lese mer om resultatene deres her. Psykologisk trygghet handler i bunn og grunn om å være trygge på hverandre. Takket være lærdommen og delingskulturen til Google kan vi nå slå fast at dette er en svært sentral faktor for høytpresterende team. Hvis du har to og et halvt minutt til overs vil jeg anbefale følgende video som tar for seg prestasjon vs tillit:

Teambuilding er en unik mulighet til å bygge tillit

Det fine med teambuilding er at vi typisk har koblet oss av det vi ellers gjør på jobb. Vi har satt av tid til å bli bedre kjent. Vi er rett og slett ganske fri fra distraksjoner, noe som i mitt tilfelle er ganske sjeldent i jobbsammenheng. Hypotesen jeg innledet med var at vi med noen enkle grep kan ivareta teambuilding. Med bakgrunn fra Google re:Work vet vi at et av hovedmålene våre her er å bygge trygghet og tillit i teamet. Hvordan gjør vi dette?

Aktiviteter som tar sikte på å bygge trygghet og tillit blir typisk personlige. For at de skal gi verdi må deltakerne være investert: De må ha lyst til å dele. Jeg vil påstå at suksess er når folk gleder seg til disse aktivitetene. Kanskje gruer de seg også litt, for det er jo skummelt å dele. Som klisjeen sier så er det utenfor komfortsonen magien skjer. Du kan tilrettelegge for dette ved å gå foran som et godt eksempel: Vær åpen og personlig, vis at du er sårbar og gi de andre din tillit. Det er en fordel om noen™ har tenkt litt gjennom i forkant hvor teamet befinner seg (ref. Tuckmans modell), samt hva deltakerne er komfortable med. Utvalget av konkrete øvelser og aktiviteter bør reflektere dette. Som teamleder har denne noen™ en tendens til å bli meg, men her vil jeg presisere at dette er et delt ansvar og noe alle kan gjøre. Jo flere som bidrar med åpenhet og deling, jo lettere blir det for resten. 

Sosialisering har absolutt sin plass. Noen ganger kan det være helt perfekt å bowle, eller kanskje dra på MegaZone og skyte hverandre med laserpistoler. Eksempelvis kan dette være en feiring av noe teamet har oppnådd, hvor man ønsker å dra ut et sted og gjøre noe hyggelig sammen. Jeg mener teamet, og teamleder spesielt, er tjent med å ha et bevisst forhold til hva man gjør når, og hvorfor. Mange gode muligheter for teambuilding går tapt når man ikke tenker gjennom hva man vil oppnå og hvordan man bør gjøre det. 

"Dessverre" er det ingen silver bullet for teambuilding. Det finnes ingen konkret oppskrift hvor du gjør A-B-C slik at teamet oppnår høy psykologisk trygghet. Vi kjenner til hvilke momenter vi må ha fokus på, men utover dette er det høyst situasjonsavhengig hva som er hensiktsmessig. Jeg tenker dette er litt av utfordringen og det som er givende med å være leder: Du må bruke den kunnskapen og innsikten du har for å komme opp med gode løsninger. En konkret aktivitet jeg har kjørt et par ganger, gjerne i en tidlig fase for et team, er 36 questions that lead to love (les om bakgrunnen i New York Times: link). Det høres kanskje malplassert ut, men grunntanken er at disse spørsmålene fostrer tillit og skaper trygghet mellom personer. Naturligvis tar jeg ut de mer date-sentriske, men spørsmål som "For what in your life do you feel most grateful?" kan gi svært gode samtaler i min erfaring. 

Mitt håp med denne artikkelen er at du sitter igjen med en bevisst tanke om hva du gjør når og hvorfor med teamet. Kanskje har du også fått litt inspirasjon til å utforske nye aktiviteter? 








Bygger du teamet, eller sosialiserer dere?

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

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 godt eksekvert fossefall bedre enn dårlig eksekvert smidig? (Del 3 av 6)

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

Vi laget nettopp et prosjekt helt uten automatiske tester. Hvordan gikk det?

Hvis vi går tilbake noen år var det svært vanlig å drive såkalt testdrevet utvikling. Testene skulle skrives først, så koden som fikk testene til å passere.

På den måten skulle du tvinges til å tenke gjennom alle scenarier som skulle oppstå, blant annet ved at hjørnetilfeller kom frem i lyset så fort som mulig.

Mange av oss fikk dette inn, om ikke med morsmelken, så enten i starten av karrieren, eller som en av mange introduksjoner til programmering når vi var på ett av mange programmeringskurs noen år tilbake. Et av de mest populære eksemplene var Uncle Bobs Bowling Kata


Man kan argumentere for at dette hadde sin verdi når det gjelder å løse et helt spesifikt problem med rigide regler.

Å kjøre samme tilnærming på et avgrenset område, f.eks. beregning av helligdager eller virkedager, kan vi på samme måte se nytten,
men når det gjelder størstedelen av produktene vi arbeider med dag-til-dag, er å skrive tester først kanskje ikke den beste tilnærmingen.

Mer unntaket enn regelen har vi ikke helt klart for oss hva vi skal lage, og i alle fall ikke hvordan det skal implementeres.

For oss som var med på større prosjekter var det også vanlig med verktøy som Sonar eller Jacoco som automatisk målte testdekning, der det gjerne var et krav om at dette skulle ha en viss, gjerne svært høy prosentandel av koden som var skrevet.

Konsekvensen var ofte at man skrev tester som i seg selv ga liten verdi, men testet kode som hittil var utestet, og ga uttelling på testrapporter.

Siden vi stort sett har beveget oss i mer smidig retning, hvor så hyppige produksjonssettinger som mulig er et uttalt mål, er naturlig nok også koden som blir lagt ut til brukere langt mindre i volum. Det vil derfor være kort vei til å kunne rette eventuelle feil som blir oppdaget i miljøet der de reelle brukerene tross alt oppholder seg.

Tester trenger også vedlikehold som alt annet. Det er ikke bare selve kodebasen man må forholde seg til, hver eneste bygging på utviklermaskinen vil typisk kjøre samtlige tester for å forsikre utvikler om at alt fortsatt er i vater.

Vi bygget nettopp en helt ny applikasjon der vi droppet å skrive en eneste test. Under utvikling opplevde jeg sjelden som utvikler at jeg var usikker på om det jeg hadde endret på ville føre til utilsiktede endringer.

Det skal sies at applikasjonen vi laget var forholdsvis enkel, med få krav til ytelse og skalering. Vi endte med en backend med noen få REST-endepunkter, og et funksjonelt språk til frontenden. Det var aldri et prinsipp for oss ikke å ha tester. Hadde vi sett verdien av det hadde vi innført tester der det var behov for umiddelbart.

Til nå har vi, bank i bordet, ikke fått noen feilrapporter fra første prodsetting.

En av de viktigste grunnene til å ha tester, er at en utvikler skal kunne være trygg på at endringene hennes ikke fører til sideeffekter.

Det vi har funnet ut har vært verdifullt på vårt prosjekt, har vært å fokusere på å teste applikasjoners oppførsel.
Finn ut hva som er det mest kritiske for din applikasjon og begynn der. Tilbyr applikasjonen betaling, begynn med å teste at den viktigste funksjonaliteten fungerer som den skal. At ordrenummer, varenummer, betalingsreferanser o.l. faktisk ikke lager kjipe
situasjoner for brukerne er en selvfølge å få avdekket tidlig i utviklingsprosessen, men skal også sørge for at de som utvikler applikasjonen skal få en god forståelse av systemet.

Mye av den helt vanlige vaniljefunksjonaliteten til en applikasjon er derimot ofte såpass rett frem at man kanskje ikke trenger all verdens tester.

Som med alt annet blir også dette en kost/nytte - vurdering. Som utvikler bør du begynne med det som er mest sårbart og kritisk, eller det som åpner for at andre utviklere kan trå feil.

Merk her at jeg bare snakker om automatiske tester. Brukertesting, sikkerhetstesting, og ytelsestesting blir en helt annen skål!

Det er ofte en god ting å slette kode når man er inne i refaktorering av en applikasjon, tester burde heller ikke være fredet.




Methodology