Hvordan bruke data for å forbedre designløsningene dine?

La hodet ligge litt på blokken før du legger det i bløt!

Tre faktorer som genererer indre motivasjon

«Mamma, det er noe galt med Vipps…

Hjemmekontor til besvær

10 ting jeg skulle ønske noen fortalte meg da jeg begynte å jobbe som utvikler

10 ting jeg skulle ønske noen fortalte meg da jeg begynte å jobbe som designer

Tverrfaglig samarbeid genererer store besparelser

<figure><img alt="Et bilde av en graf i Analytics" src="https://cdn-images-1.medium.com/max/1024/1*LKKO_N-srrgvVB0poFF6bw.jpeg"><figcaption>Photo by <a href="https://unsplash.com/@olloweb?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Agence Olloweb</a> on <a href="https://unsplash.com/s/photos/analytics?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Unsplash</a></figcaption></figure>Det kan være skummelt å dykke ned i dataene for å finne ut av hvordan løsningene dine presterer. Fordi det er jo her man ser resultatet av det harde arbeidet man gjør hver dag. Man stikker liksom fingeren i jorda, og det kan være ubehagelig. Men har man fingeren i jorda er man i alle fall skikkelig jordet, og det er jo smart i tilfelle lynet skulle slå ned!
<h3>Hvor skal man starte?</h3>
Det sies at dersom man skal gjøre de store oppdagelsene må man starte med spørsmål, og ikke med data. Jeg tenker allikevel det er en fordel å ha en idé om hva du kan finne ut med data. Fordi det krever en viss innsikt for å kunne stille de riktige spørsmålene, og å vite hva man kan få svar på.
Det er vanskelig å få konkrete svar på store strategiske spørsmålene gjennom data. Så det gjelder å bryte dem ned. Dersom du lurer på om innholdsstrategien fungerer, vil det være smart å bryte det hele ned til litt enklere spørsmål, for eksempel: «Hvilket innhold gir høyest konvertering?», eller “Gjør kundene det vi ønsker at de skal gjøre?”
<h3>Tenk på hva du prøver å oppnå med løsningen, og om intensjonen samsvarer med kundens forventning og bruk?</h3>
Start med å finne ut hva de mest brukte sidene er. Setter du deg inn i sidevisninger får du et godt bilde av hva som er mest brukt, og da vet du også hvilke sider du vil få mest igjen for å optimalisere.
Finn ut hva kundene gjør når de er på siden. Tracker du brukeradferd/“hendelser” får du et kjapt overblikk over hva kunden er interessert i på siden din. Her kan også heatmaps være nyttige da den visuelle fremstillingen er enkel å forholde seg til. Men man må være litt oppmerksomme når man benytter heatmaps. Et heatmap viser deg et bilde av defaulten av siden, uten pop ups og drop down menyer. Så dersom heatmapen ser litt underlig ut med mange klikk på et sted du ikke har noe innhold, er det sannsynligvis noe som dukker opp, på akkurat det stedet i virkeligheten, som ikke er synlig i heatmapen.
Scrolling heatmaps kan også være et nyttig verktøy dersom du ønsker å se om kundene leser nedover siden. Der man kanskje antok at kunden hadde lest alt, fordi Analytics forteller deg at personen hadde brukt 7 minutter på siden din, kan ikke Analytics vite om kunden var der i 7 minutter fordi de faktisk leste alt, eller ble forstyrret av en kollega, og i realiteten bare leste ingressen.
Finn ut hvordan løsningen din presterer. Hva konverterer og hvor faller kundene av? Frafallstrakter er gull å grave seg ned i dersom løsningen din skal geleide kunden gjennom flere gitte steg for å komme «til et mål».
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*VXg_XmHa5bKa6FXX2UMrPQ.png"></figure>Den enkle visualiseringen gir et kjapt bilde på hvor mange kunder som besøker hvert steg i løsningen. Ser du at dere mister en stor andel kunder på et spesifikt sted i flyten, vet du akkurat hvor du trenger å følge ekstra nøye med når du gjennomfører den neste brukertesten.
<h3>Hva betyr tallene, og hvor viktige er de?</h3>
Da jeg var liten, og spurte «Er det lenge til vi er fremme?», svarte min far: «Neida, det er rett rundt svingen her», mens storesøster nesten samtidig svarte: «Kjempelenge!».
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*r-m7H_5mEKjWv9KoS4hcsA.png"></figure>Jeg lurte da naturligvis på hvem som løy. Da spurte pappa meg; «Syns du 7 er mye?» Jeg husker jeg funderte på det… Hvis det er kroner vi snakker om kan det være lite. Spesielt dersom det er det du får i lønnsjustering på årsbasis. Men hvis 7 millioner mennesker benytter 7 kroner mer hver gang de handler i løsningen du lager. Da er 7 veldig mye. Da er 7 faktisk 49 millioner! Og hvis du har hatt 7 hundre besøkende på nettsiden din den siste måneden, kan det hende du har god grunn til å juble høyt. Men ikke hvis du er Amazon.
Så det er ikke alltid så lett å forstå tallene og vite hva de betyr. Og man må i tillegg ha litt is i magen. For det tar tid å samle data, og alt henger sammen med alt. For eksempel; dersom konverteringen går ned, er det ikke gitt at at det er løsningen din det er noe i veien med. Det kan like gjerne være at markedskampanjer har truffet feil målgruppe. Altså du har fått veldig mange besøk, men av feil folk. De blir sjelden til middag! Så for å forstå tallene må man bli godt kjent med løsningene og vite hva utgangspunktet er. Fordi tall uten kontekst er bare… — ja, siffer ved siden av hverandre.
Bounce rate er noe man ofte hører om. Som om det er en krise dersom en kunde forlater nettstedet ditt etter bare å ha besøkt én side. Men i enkelte sammenhenger kan en høy Bounce rate være helt ok. For eksempel når en kunde søker på google, går inn på foreslått lenke, får svar på det hun trenger og går ut igjen for å fortsette med livet sitt. Det er jo en god ting! Vi vil jo ikke være så selvopptatte at vi på død og liv ønsker at kundene skal valse rundt på hjemmesidene våre i timesvis uten mål og mening? Fant de svaret på akkurat det de lurte på ved første klikk, bygger vi tillit. Noe som øker sjansen for at de faktisk kommer tilbake igjen ved en senere anledning — når de trenger det.
<h3>Bli kjent med brukergruppene</h3>
Har du fått oppgaven; “Bare tegn ut den typiske brukerferden, den som er mest vanlig, liksom”? Helt sikkert. Vanlige folk gjør vanlige ting, så det bør være enkelt. Men sånn er det jo ikke. Helt vanlige folk gjør ikke helt vanlige ting. De gjør veldig mye rart. Så den «typiske brukerferden» finnes kanskje ikke. Og finner du den mest brukte brukerferden, utgjør den kanskje bare 5% av kundene. Så kan vi egentlig kalle disse fem prosentene «typiske» da?
Det du kan se på, er hvilke kundetyper som gjør hva. Da kan du forsøkeå koble personas på målingene, ved å legge på sannsynlige filtreringer gjennom segmenter. Et segment er et utdrag av alle dataene dine som lar deg isolere og analysere mønstre basert på handlingene de har gjort i og før de benyttet løsningen din.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*hUprpquhZBVm8QO0uaelzw.png"><figcaption>Finn et mønster!</figcaption></figure>For eksempel: Er personasen en forsiktig type som er opptatt av datasikkerhet, og er medlem i en bedrift som gir han fordeler i din løsning? Da kan man kanskje anta at han kommer fra en samarbeidspartners side og logger inn i din løsning med BankID. Og her kan man bygge på med antagelser ut i fra beskrevet persona. Man klarer selvsagt ikke å treffe 100% på beskrevne personas, men man kan kanskje få et overordnet bilde på adferden til de forskjellige kundegruppene, og finne ut hvordan man kan jobbe målrettet mot enkelte segmenter.
<h3>Ingen verktøy gjør jobben alene</h3>
Selv om du har vært flink og benyttet analyse for å finne ut hva som skjer, og for hvor mange det skjer, vet du fremdeles ikke hvorfor det skjer. Det er da brukertester og spørreundersøkelser blir virkelig gøy! Når du har identifisert en ekte utfordring, som du vet påvirker mange mennesker. For ingen verktøy gjør jobben alene. Man må benytte flere kilder for å få én sannhet.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*ppJYTUN8dvkQ525H60TZIA.png"><figcaption>Triangulering</figcaption></figure><h3>Videreutvikling og endringer i løsningene</h3>
I brukertester og spørreundersøkelser kan man få mye innsikt i hva som fungerer best for sitt formål, men siden det aldri er to streker under svaret når man brukertester med 10 personer, og fordi vi vet at det kundene sier i spørreundersøkelser ofte ikke samsvarer helt med hva de gjør, er det godt å gå tilbake til dataene igjen. Bestem på forhånd hva du trenger å observere når endringen trer i kraft, og følg nøye med på utviklingen, både på smått og stort. Det er ikke alltid de store strukturelle endringene som gir de største utslagene i konvertering. Den lille hjelpeteksten, eller CTA-teksten kan ofte utgjøre en større forskjell.
Er A/B-testing verdt bryet? I mange tilfeller er A/B testing noe man kan lære mye av. Men ha i bakhodet at dersom du tilbyr én løsning til halvparten av kundemassen din, og halvparten til den andre, betyr det at det tar dobbelt så lang tid å få svaret på om endringer fungerer eller ei enn om du hadde gitt alle samme løsning. Man bør derfor ha et ganske stort volum av besøkende for at A/B-testing skal ha noe for seg, spesielt dersom du trenger svaret fort. En annen faktor er at det er kostbart å utvikle to løsninger av samme sak. Så A/B-testen bør være temmelig spisset, med små konkrete variasjoner mellom løsningene så man sikrer at man måler epler mot epler, ikke epler mot pærer. Dersom designet krever store strukturelle modifikasjoner på informasjonsarkitektur i de forskjellige variantene vil det være umulig å sammenligne, og mest sannsynlig være meget ressurskrevende.
<h3>Skal man alltid stole på alle tallene?</h3>
Tallene lyver sjelden, men hvis du ikke har hentet de riktige tallene kan de gi et feil bilde av virkeligheten. Så om du ser tall som virker for gode eller dårlige til å være sanne, er de ofte ikke det. Tracking settes opp av helt vanlige (stort sett meget kompetente) mennesker. Men de kan også gjøre feil. Og en liten feil i trackingen kan gi ganske store utslag. Har du som UX-designer satt opp målingen selv, kombinert med at trackingen ikke er optimal kan det gi noen rare tall. Så er det noe som virker uriktig, snakk med fagfolk. Forresten; snakk med fagfolk hele veien!
Og til slutt; ikke tenk du at du skal klare å følge med på all data alene.
- For du skal jo tross alt levere et design også.
<blockquote>Lykke til!</blockquote>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=ae458fc2d1f4" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/hvordan-bruke-data-for-%C3%A5-forbedre-designl%C3%B8sningene-dine-ae458fc2d1f4">Hvordan bruke data for å forbedre designløsningene dine?</a> was originally published in <a href="https://medium.com/dfind-consulting">Dfind Consulting</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

I større eller mindre grad er vi alle avhengige av tilbakemeldinger fra de rundt oss. Både for å få en bekreftelse når vi gjør noe riktig, og for å gjøre noe bedre neste gang.
Noen fagfelt er vanskelig for andre å mene noe om. Jeg kan for eksempel ikke si «Kjære pilot, jeg ville ikke dratt i den spaken om jeg var deg». Det ville blitt litt dumt tror jeg. Såpass selvinnsikt har man.
Vi som jobber med design, i alle sine former, er vant til å få tilbakemeldinger på alt vi gjør. Fra alle. Hele tiden.
Alle har sin subjektive mening om budskapet du forsøker å formidle. «Jeg tror ikke noen vil trykke på den knappen», «Jeg syns ikke fargen passer» eller «Jeg føler ikke at det sitter 100% enda».
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*w8RCbCtb-K4uPhEqn_aKXg.jpeg"><figcaption>Photo by <a href="https://unsplash.com/@zacharykadolph?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Zachary Kadolph</a> on <a href="https://unsplash.com/s/photos/crying-kid?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Unsplash</a></figcaption></figure>Og så innmari kjipt det kan være å få dårlige tilbakemeldinger på noe du har lagt sjela di i…
Spesielt fra mennesker som overhode ikke har din erfaring. Mennesker som jobber med helt andre ting. De kommenterer på ting som tilhører ditt fagfelt, og du river deg i håret over alle disse innspillene som ikke passer i dine egenoppbygde bias.
Det må du slutte med! Fordi de har all rett til å mene noe. De skal mene noe. Og du skal være evig takknemlig for alle tanker, meninger og innspill uansett hvem det kommer fra.
Jeg husker at det å ha “Fingerspitzgefühl”, (teft, finfølelse og intuisjon) var et stort kompliment for 20 år siden. Hadde du fingerspitzgefühl hadde du “alt”. Det er fortsatt ingen tvil om at noen har et ekstra godt blikk for hva som fungerer visuelt, eller hvordan man kan gjøre et budskap interessant… Så jeg vil nødig tråkke noen på tærne her. Men det å bruke fingerspitzen til å bare designe på gefühlen, er langt fra nok. For hvem er det som skal bestemme om teften eller intuisjonen din er riktig?
Som UX-designer er det bare ett riktig svar: «Kunden bestemmer alt!» En annen fin setning er: “All kommunikasjon skjer på mottakers premisser”. Sier man det, har man liksom skjønt det. Det høres veldig smart ut. Spesielt dersom man tar av seg brillene sine, og benytter dem til å peke på forsamlingen mens man sier ordene, og legger til en selvsikker “…alltid!” på slutten av setningen. Da er det etablert. All kommunikasjon skjer på mottakers premisser.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*Ndt6NLUVtLEPRgRwyxtOzQ.jpeg"><figcaption>Photo by <a href="https://unsplash.com/@sammywilliams?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Sammy Williams</a> on <a href="https://unsplash.com/s/photos/confused?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Unsplash</a></figcaption></figure>Problemet er jo bare at det er så innmari mange mottakere. Og ingen av dem mener det samme. Hadde de gjort det så hadde jobben vært såre enkel. (Og kanskje litt kjedelig…)
Så når enkelte respondenter i brukertesten din sier at “det er for lite informasjon”, kan du være sikker på at andre syns det er alt for mye tekst å forholde seg til. Samtidig mener den meget erfarne kollegaen din, at det beste er å kutte informasjonen helt, og legge inn en knapp som kan lede kunden til et annet sted der du kan få all informasjon, hvis de ønsker det.
Så hva skal man gjøre da, dersom det tross alt bare var én person i brukertesten som snublet over «den rare greia» i løsningen din, når de ni andre ikke møtte det samme problemet? Hvordan kan vi vite at ikke denne ene personen faktisk var den som satte fingeren på hvor skoen egentlig trykker?
Kvantitativ innsikt. Og nå må jeg rope skikkelig høyt:
Analyse kan ikke være en egen avdeling som sender ut generell informasjon på overordnet nivå til produktteamene i et selskap!
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*CcOOGk5m0QXU_x8cSrTwAw.jpeg"><figcaption>Photo by <a href="https://unsplash.com/@jasonrosewell?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Jason Rosewell</a> on <a href="https://unsplash.com/s/photos/megaphone?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Unsplash</a></figcaption></figure>Vi må ha analyse med oss hele veien. Vi må ha hodet langt ned i grøten på massene, slik at vi vet hvilke problemområder som faktisk er viktige når vi gjennomfører brukertesten. Og slik at vi kan vite hvilke oppgaver som bør prioriteres når oppsummeringen av brukertesten foreligger.
Vi må monitorere alt vi gjør. Og vi må kryssjekke resultatene. For hva hjelper det om flere kunder gikk et steg videre i flyten din med det nye designet, eller at flere trykket på den nye knappen, — dersom den totale konverteringen går ned?
Man kan selvfølgelig ikke være ekspert på alt. Og det er nok ingen som forventer at du som designer skal være en Google Analytics ekspert. Men selv om du ikke har tilgang til en dedikert ressurs med inngående kunnskap om analyse på teamet, er det allikevel ganske mye man kan finne ut av selv.
Det krever selvfølgelig litt tid, og mest sannsynlig må du få hjelp av noen som er litt mer kyndig på fagfeltet for å sikre at du ser på riktige tall. Og det er slett ikke sikkert du blir så mye klokere på akkurat det du lurte på i starten. Kanskje fordi det ikke var satt riktig tracking på det du ville sjekke, eller kanskje det ikke finnes et svart/hvitt svar?
Men jeg kan love deg at du finner ut noe!
Kanskje noe helt annet enn det du hadde tenkt på? Noe som gjør at du må parkere din egenoppbygde bias? Kanskje noe som gjør at du må legge fra deg komponenten du har brukt ukesvis på å forbedre med din fingerspitzgefühl, fordi den ikke blir brukt av kundene uansett hvor fantastisk den fungerer i seg selv?
Så ja; det kan være meget smertefullt å legge hodet på blokken.
Men det er helt nødvendig, dersom du skal ha et grunnlag for å legge hodet i bløt, — og ikke i tåke!
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=8cc85275ba5d" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/la-hodet-ligge-litt-p%C3%A5-blokken-f%C3%B8r-du-legger-det-i-bl%C3%B8t-8cc85275ba5d">La hodet ligge litt på blokken før du legger det i bløt!</a> was originally published in <a href="https://medium.com/dfind-consulting">Dfind Consulting</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Arbeidslivet utvikler seg i en retning med høyere krav, tempo og press overfor de ansatte. For å henge med i utviklingen og overleve dagens marked er forventninger til kvalitet og effektivitet i arbeidet som leveres høye. Særlig i tech-bransjen skjer utviklingen i rekordfart, noe som skaper et desto høyere press på IT-konsulentene. Presset kan raskt gjøre arbeidshverdagen for en IT-konsulent svært krevende, og da er det arbeidsgivers ansvar å komme på banen for og sikre et godt arbeidsmiljø og trivsel hos den enkelte. For at dette skal være gjennomførbart er vi nødt til å være proaktive i måten vi jobber på. Å skape et fundament hvor behov som gir indre motivasjon dekkes bidrar til å skape trivsel på arbeidsplassen. Dette omhandler behovet for autonomi (selvbestemmelse), tilhørighet og kompetanse. Er disse behovene dekket, går resten av seg selv — konsulenten har indre motivasjon til å prestere i jobben.
I Dfind Consulting jobber vi kontinuerlig med å tilrettelegge for økt indre motivasjon for alle ansatte. I Great Place to Work 2021 nådde vi andreplassen. Gjennom tilbakemeldinger visste vi allerede at vi var gode, men å motta dette kvalitetsstempelet ble enda en bekreftelse på at vi gjør så mye riktig. I rapporten fremkommer det at de beste arbeidsplassene blant annet er særlig gode på å skape tilhørighet og fellesskap, å involvere og lytte til samt å være fleksible, vise tillit og støtte overfor hver enkelt. Resultatene skiller seg sterkt ut fra gjennomsnittsbedriften. Dette arbeidet skal vi i Dfind Consulting selvfølgelig fortsette med!
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*6tZ9qha4HcQm-PzIo0iO_A.jpeg"><figcaption>Foto av <a href="https://unsplash.com/@priscilladupreez?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Priscilla Du Preez</a> fra <a href="https://unsplash.com/s/photos/motivated?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Unsplash</a></figcaption></figure>Autonomi. Muligheten til selvbestemmelse, det å selv kunne styre egen arbeidshverdag i størst mulig grad. En som har innvirkning på egen arbeidssituasjon opplever tilfredshet i større grad enn en som ikke har det. Fokuset vårt er hele tiden å finne oppdrag konsulentene selv ønsker seg inn i. Alt som kreves er en tilgjengelig arbeidsgiver som lytter til den enkeltes ønsker og behov før konsulenten settes i prosjekt. Ved å gjøre dette vil den enkelte føle på økt motivasjon og få en naturlig indre drive til å utføre arbeidsoppgavene på best mulig måte. Dette øker produktivitet, gir bedre resultater som igjen påvirker egen mestringsfølelse og trivsel. Konsulenten befinner seg i en spiral av positive effekter, noe som øker sannsynligheten for at både konsulent og kunde blir fornøyd.
Tilhørighet handler om følelsen av å være en del av noe større. Dette handler om tilknytningen en har til kollegaer, men også tilknytningen en har til selskapet. Jo sterkere tilknytning jo større blir ønsket om å bli værende i selskapet Men hvordan får man dette til når konsulenten tilbringer mesteparten av sin arbeidstid ute hos kunde? Det sier seg selv at dette er mer utfordrende i konsulentselskaper enn i andre selskaper. Å bygge relasjoner mellom ansatte for å skape fellesskap innad i selskapet er viktig, hvor kultur er et nøkkelord. Å skape kultur for sosiale sammenkomster som appellerer til alle er krevende når behovene er ulike — arrangementene skal treffe både de som ønsker fotballturnering og de som vil løpe holmenkollstafetten, de som ønsker sjakkturnering og de som vil spille poker. Covid-19 har lært oss at følelsen av tilhørighet kan skapes og opprettholdes hjemme i stua, enten gjennom digitale kaffeprater eller virtuell lønningspils. Det er likevel ikke til å legge skjul på at vi ser frem til å kunne møtes mer fysisk fremover nå som samfunnet gradvis gjenåpnes. Hos oss har vi lyktes i å etablere et arbeidsmiljø i selskapet der hver ansatt føler seg som en del av fellesskapet. Årshjulet er fylt med sosiale eventer av både sportslig og festlig karakter, inkludert utenlands- og hytteturer.
Følelsen av tilhørighet i form av tilknytning til selskapet er også viktig. Føler du deg som en liten brikke i et digert puslespill, eller som en nøkkelperson som er avgjørende for å drive selskapet fremover? I et stort selskap kan man fort føle seg usynlig. I et mindre selskap er det enklere å ivareta en personlig profil der hver enkelt blir sett og satt pris på. Flat struktur og det faktum at “alle kjenner alle” gjør muligheten for å påvirke betydelig større, noe som igjen styrker den enkeltes tilknytning til selskapet. Kort vei til beslutning og mulighet til å påvirke egen karriereutvikling opplever vi at styrker følelsen av å være en viktig bidragsyter for selskapets utvikling.
Kompetanse innebærer følelsen av å mestre arbeidsoppgaver og å utvikle egen kompetanse. Det er viktig at forventningene til arbeidet som utføres samsvarer med kompetansen du som konsulent innehar. Ingenting er vel mindre motiverende enn å føle at du ikke strekker til eller ikke leverer resultatene som forventes av deg? Hos oss jobber konsulentene tett med et salgsteam som lytter til ønsker og behov for å finne riktig kunde og prosjekt. På den måten sikrer vi samsvar mellom forventninger, ønsker og kompetanse. Men hvor går egentlig grensen til hva som skaper mistrivsel som følge av manglende mestringsfølelse og hva som utfordrer deg såpass at du føler på kompetanseutvikling. Dette er en hårfin balanse. Kompetanseutvikling er det andre aspektet ved kompetanse som genererer indre motivasjon. For å fremme kompetanseutvikling er det viktig med utfordringer. Å få bryne seg på utfordringer en ikke har jobbet med før, komplekse arbeidsoppgaver og lignende er avgjørende for å oppnå indre motivasjon. Da er det arbeidsgivers ansvar å legge til rette for at utviklingen går smidig, at det er rom for å feile og mulighet til å være en del av et team du kan lære av. Særlig viktig er dette i tech-bransjen hvor utviklingen skjer i rekordfart. Sterkt fagmiljø innad i selskapet og mobilisering av kompetanse er viktige faktorer for å fremme kompetanseutvikling. Gjennom fagkvelder kan kunnskap, erfaringer og kompetanse deles med hverandre slik at man sammen utvikler seg. Mulighet for å kunne delta på foredrag og seminarer, ta de sertifiseringene man ønsker, og ha tilgang på nødvendig utstyr for å best mulig kunne utføre jobben sin er også viktig for å fremme kompetanseutvikling. Uten utfordringer og tilskudd til egen kompetanse vil mange føle på stagnasjon og kjedsomhet. Likevel er det viktig å huske at menneskers behov er ulike. Selv om én utvikler motiveres av komplekse, “umulige” arbeidsoppgaver, vil en annen motiveres av forutsigbarhet og rutine.
For å oppsummere viser empiri at ved å legge til rette for autonomi, tilhørighet og kompetanse på arbeidsplassen øker de ansattes motivasjon og tilfredshet. De tre faktorene er nært knyttet til hverandre. Følelse av tilhørighet gjennom relasjonsbygging skaper trygghet som for mange gjør det enklere å fremme forslag, å diskutere uten å være redd for mottakerens respons og lignende. Samtidig vil flat struktur og kort vei til beslutning gjøre det enklere å i det hele tatt komme i kontakt med rett person for eventuelle beslutninger. Følelse av tilhørighet påvirker med andre ord også autonomi. Tilsvarende vil tilrettelegging for kompetanseutvikling øke følelsen av autonomi, og vise versa. Å generere indre motivasjon krever dermed ikke nødvendigvis så mye innsats fra arbeidsgiver. Ved å være oppmerksom og lytte til de ansatte er mye gjort. Arbeidsgleden den enkelte da føler vil øke den enkeltes kapasitet og produktivitet. Sånn blir effektene en oppadgående spiral som gagner både den enkelte, kunden og selskapet. Konsulentenes trivsel er alltid prioritet nummer èn — vi er et konsulenthus av konsulenter, for konsulenter.
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=c4de4a359c91" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/tre-faktorer-som-genererer-indre-motivasjon-c4de4a359c91">Tre faktorer som genererer indre motivasjon</a> was originally published in <a href="https://medium.com/dfind-consulting">Dfind Consulting</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

…pengene kom ikke inn, selv om du Vippset allerede da jeg sto heeelt bakerst i køen på Starbucks.» - sier min 11-årige datter.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*jqBrRYeP8RLBMqKnYIrDiA.jpeg"><figcaption>Photo by <a href="https://unsplash.com/@manunalys?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Maria Lysenko</a> on <a href="https://unsplash.com/s/photos/kid-unhappy-phone?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Unsplash</a></figcaption></figure>«Neivel, men de har kommet inn nå ikke sant?» -spør jeg. Jada, det hadde de. Pengene var på plass! Det var ikke noe som helst galt med Vipps. Kanskje en treghet i systemet bare (eller mest sannsynlig en treghet hos mor, uten at jeg innrømmer det for henne selvfølgelig).
Og den gangen iPhonen og Apple Watchen ikke snakket sammen var de heller ikke «ødelagte» eller «dårlige».
Det krevde bare en ørliten omstart, eller en programvareoppdatering.
Så hva er det jeg vil frem til her?
At unger er bortskjemte og verken burde få lov til å ha iPhoner eller Apple Watcher hvis de ikke lærer seg å sette skikkelig pris på det? Eller at barna ikke burde få penger Vippset mens de står i køen på Starbucks?
Neida. Jeg skal ikke mene noe om hva barn bør få og ikke, selv om mange av dem sikkert har mye mer enn de trenger (…inkludert min egen, så ingen pekefingre her!).
Men, det jeg imidlertid har lyst til å dele — er min frykt for denne generasjonen. De som har vokst opp med swipe, scroll og zoom og forventer at alt er på stell hele tiden. Ja, jeg blir egentlig litt stressa jeg, på vegne av alle oss som jobber med brukeropplevelser og utvikling av digitale tjenester.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*Td5FVYQrSkwyKdwh_zwJRw.jpeg"><figcaption>Photo by <a href="https://unsplash.com/@ilumire?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Jelleke Vanooteghem</a> on <a href="https://unsplash.com/s/photos/kids-technology?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Unsplash</a></figcaption></figure>Min mor pleide alltid å skylde på seg selv når ting ikke fungerte som det skulle. «Jeg har nok trykket på feil knapp», sa hun. I rake motsetning til min datter, som utelukkende klandrer Showbie når leksen ikke har blitt lastet opp i tide.
Joda, det er klart det er noen forskjellige personligheter inne i bildet her… Men, jeg tror ikke vi kan stikke under en stol at holdningen og forventningene til digitale tjenester hos disse 11-åringene er skyhøye.
Selv er vi vel midt i mellom. Vi har stått i kø i banken for å overføre penger, og vi ble født i en tid der vi måtte vente til dagens avis kom ut i butikken for å lese siste nytt. Så selv om vi anser oss selv som meget digitalt oppegående og effektive, har vi kanskje allikevel fått en dose mer tålmodighet i morsmelka.
Og det er altså vi, vi med tålmodigheten i blodet og forståelsen for at feil kan forekomme, som skal lage løsningene for denne generasjonen når de snart skal ut å gjøre “viktige voksenting”.
Hvordan skal vi klare å holde på oppmerksomheten deres i mer enn 1 minutt for å forklare hva man trenger av forsikringer eller sparekontoer, når de er indoktrinert av TikTok? Og hvordan skal vi klare å gjøre e-signering, innlogging med BankID, og kjøpsløsninger like intuitive som SnapChat?
Joda, vi utvikler nok oss i takt med tiden vi også.
Men vi må jaggu følge med i svingene!
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=76d551421533" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/mamma-det-er-noe-galt-med-vipps-76d551421533">«Mamma, det er noe galt med Vipps…</a> was originally published in <a href="https://medium.com/dfind-consulting">Dfind Consulting</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*dwzD4nSclN7niVbyBmkPZA.jpeg"><figcaption>Photo by <a href="https://unsplash.com/@frantic?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Alex Kotliarskyi</a> on <a href="https://unsplash.com/s/photos/open-office-plan?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Unsplash</a></figcaption></figure>Opprinnelig publisert på <a href="https://www.kode24.no/kodenytt/hjemmekontor-passer-darlig-for-ledere-som-liker-micromanagement/73637916">kode24.no</a>
Daglig leder i Alv, Marcus Sahlin Pettersen, skal i hvert fall ha skryt for å våge å gå mot strømmen når han skriver at han <a href="https://www.kode24.no/kodenytt/konsulent-sjef-vil-ha-utviklerne-sine-i-apne-landskap/73623233">vil ha utviklerne sine i åpne landskap</a>. Veldig mange utviklere opplever hjemmekontor positivt, og mange går så langt som å si at de <a href="https://www.kode24.no/nedetid/uaktuelt-a-sitte-i-apent-landskap-noen-gang-igjen/73542449">aldri vil tilbake på kontorene fem dager i uka som før</a>.
Han sender et sterkt og tydelig signal om hva som er viktig for han, og legger inn et spark til utviklerne — “Hvordan kan det ha seg at de samme utviklerne som i årevis har ropt høyt om at de ikke involveres i stor nok grad eller tidlig nok, nå uttaler seg over fortreffeligheten av hjemmekontor?”
Uten å gå inn på hvor ansvaret for å involvere ansatte ligger, så vitner dette på at Sahlin Pettersen ikke har fulgt med i timen det siste året, mens mange andre har innsett realiteten; at vi må forberede oss på en fremtid med distribuerte team.
Selvfølgelig er ikke hjemmekontor uten problemer, og han har nok rett i mye av det han sier; det kan være vanskelig å fange opp små signaler, og det kan være effektivt å sitte sammen når man skal løse en del type problemer — men er det slik at vi etter et år på hjemmekontor ikke har maktet å gjøre disse tingene?
At han ønsker god oppfølging av juniorer og andre medarbeidere er selvfølgelig bra, men hva da med senioren som tar på seg de støydempende hodetelefonene og irriterer seg over alt maset eller utvikleren som er langt nede i en vanskelig problemstilling og blir avbrutt fordi noen spør om han vil ha kanelbolle eller spille bordtennis?
Å ha distribuerte team krever naturligvis endringer, både i hvordan vi samarbeider, men også i ledelsesstil og personaloppfølging — det passer dårlig med hjemmekontor for ledere som liker micromanagement eller som føler de mister kontrollen når de ikke kan se alle sitte sammen.
Nå har både ledere og utviklere fått erfare hvordan det er å ha hjemmekontor i over ett år, og om det er mange som foretrekker dette så ville det vært rart å ikke ha det som en mulighet. Her er det kanskje til og med er en mulighet her for arbeidsgivere som våger ta steget fullt ut, som legger til rette for de som ønsker det, og ikke bare må ha folk på kontoret bare fordi det var slik det ble gjort før og ikke greier å håndtere at verden endrer seg.
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=9e896f453356" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/hjemmekontor-til-besv%C3%A6r-9e896f453356">Hjemmekontor til besvær</a> was originally published in <a href="https://medium.com/dfind-consulting">Dfind Consulting</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

<h4>Systemutvikling er et erfaringsbasert yrke. I utdanningen vil en utvikler tilegne seg mye teoretisk kunnskap, som absolutt er verdifull, men dessverre samsvarer den ikke alltid med arbeidslivet. Dermed er det ikke uvanlig at ferske utviklere får seg en skikkelig overraskelse når man endelig skal ta på seg voksen-buksene og ut i sin første jobb. Fra oss til deg, for å gjøre overgangen fra skolebenk til jobb litt enklere; her er 10 ting vi skulle ønske noen fortalte oss da vi begynte å jobbe som systemutviklere</h4>
av <a href="https://medium.com/u/e30b5da9a1ad">Kristine Helle-Andresen</a>, <a href="https://medium.com/u/d689599ad372">Mathias Hartveit</a>, <a href="https://medium.com/u/a33bd707f3e8">Malin Milford</a> og <a href="https://medium.com/u/81f56aee65a2">Martin Andersen</a>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*J0VBsMLGezdqwX9uBJ7J4A.jpeg"><figcaption>Photo by <a href="https://unsplash.com/@frantic?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Alex Kotliarskyi</a> on <a href="https://unsplash.com/s/photos/programming?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Unsplash</a></figcaption></figure>1. Å stille spørsmål betyr ikke at du er dum Utviklere har ofte et ønske om å “kunne alt”. Som ny i en bedrift er det lett å føle at en aldri vil bli god nok i visse teknologier eller fagområder. Da er det viktig å tidlig innse at man blir ikke bedre uten å stille “dumme” spørsmål.
Finn en god kollega, enten i utviklingsteamet eller i konsulentfirmaet ditt, som du føler du kan spørre. Husk at alle har vært der du er nå, og vil kjenne igjen de problemene du nå støter på. For dem vil det jo bare være en påminnelse om hvor langt de har kommet, og for deg er det mye hyggeligere å sitte sammen med noen og løse problemer.
2. Du kommer til å gjøre feil. Det er en del av hverdagen til en utvikler. Systemutvikling er vanskelig. I større bedrifter er det ofte mange små bevegelige programvare-deler som skal fungere i harmoni, og da er det lett å gjøre feil. Det viktigste er å danne seg rutiner for å lære av feilene sine. Har du introdusert en ny bug i kodebasen? Skriv en test som reproduserer feilen og du vil være sikker på at dette ikke skjer igjen.
Mange team praktiserer også retrospektiv-møter hvor medarbeiderne gjennomgår arbeidsmetoder og hvordan teamet kan forbedre seg fra uke til uke. Dette er en ypperlig arena for å ta opp utfordringer du har støtt på.
3. Du kommer aldri til å forstå hele kodebasen. Som konsulent og nyutdannet er det ofte man kommer inn i et eksisterende prosjekt, og det kan fort bli overveldende å sette seg inn i kodebasen. Det kan være fristende å studere så mye som mulig av koden for å oppnå forståelse, men dette er feil bruk av tid.
Fokuser på å opparbeide en forståelse av systemet og hva det utfører. Hvilke behov skal systemet dekke for brukerene? Hvorfor har vi en “DTO-Service-Bus” modul og hvorfor er den koblet til API-et? Snakk med seniorutviklere og få dem til å tegne eller vise deg grafiske representasjoner av hvordan systemet henger sammen. Dette gjør det enklere å opparbeide seg kontekstuell informasjon til den gangen du må gjøre en endring. Det er mye enklere å forstå koden i en spesifikk klasse når man på forhånd vet hva den skal oppnå.
4. Google og stack overflow er enhver utviklers aller beste venn
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*qRiA-U0xIEh3vsgpjezSsg.jpeg"><figcaption>Photo by <a href="https://unsplash.com/@wocintechchat?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Christina @ wocintechchat.com</a> on <a href="https://unsplash.com/?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Unsplash</a></figcaption></figure>Det er urealistisk å forvente at du skal huske svaret på hvert eneste problem du noen gang har truffet på. Ikke vær redd for å lene deg på andre folks løsninger, hvis det sparer deg for mye tid og hodebry. Likevel bør du tenke deg litt om før du kopierer kode direkte fra en nettside. Forstår du hva koden gjør og hvordan den påvirker systemet ditt?
5. Kommuniser med medarbeiderene dine Det er utrolig viktig å ha god kommunikasjon og arenaer hvor utviklere (deg) kan få oversikt over hva produkteier og bruker har som behov, hva designere ønsker å formidle og hvordan ønsker kan løses teknisk.
Prat og avklar så mye som mulig om en oppgave før du begynner. Dermed unngår du mange tidkrevende iterasjoner når du eller andre medarbeidere misforstår hva som egentlig skal gjøres. Iterasjoner vil det bli, men desto flere avklaringer dere gjør i forkant, desto større er sannsynligheten for at dere holder antallet nede. Det er alle tjent med!
6. Tør å komme med innspill og ideer, selv om du er ny! Perspektivene til nye utviklere er ofte gull verdt for et team; kanskje har man gjort noe unødvendig komplisert? Kanskje kunne man løst noe på en annen eller ny måte? Teknologien kan bevege seg raskere enn mange i arbeidslivet får med seg. Nye personer med erfaring fra andre teknologier kan ofte gi nye muligheter man ellers ville gått glipp av.
7. Perfect is the enemy of done I smidig utvikling har du som utvikler et mål om å fullføre en spesifikk oppgave innen en gitt tid. Da er det er fort gjort med scope creep. Enten det er at du finner bugs underveis, innser at noe burde omskrives, eller at en variabel burde hete noe annet og du finner ut at du skal endre dette i hele kodebasen. Det vil alltid være noe som kan gjøres bedre. Det er alltid noe som kan perfeksjoneres. Husk hva oppgaven din opprinnelig var og lag forbedringsoppgaver på det du finner underveis. Om du skal gjøre alt perfekt så blir du nemlig aldri ferdig.
8. Noen dager vil se slik ut:
<ol>
<li>Du stanger hodet i veggen fordi du ikke klarer å løse et problem</li>
<li>Du tråler internett og stack overflow for å se om NOEN andre i hele verden har hatt samme problemstilling…</li>
<li>Før du går for dagen pusher du tre linjer med kode, som knekker hele bygget, og det var det du gjorde den dagen… Happy times.</li>
<li>Det du må gjøre da, er: gå hjem, sov, løp deg en tur, og la underbevisstheten jobbe. 9/10 dager kommer du på jobb dagen etter og bruker 10 minutter på å fikse det som ikke fungerte.</li>
</ol>
9. … Men, andre dager skriver du tre linjer med kode som fikser alt! Faktum er at størstedelen av tiden som utvikler går med til å fikse feil, som du noen ganger selv har introdusert. Så, når du fikser feilene er det desto viktigere å nyte suksessen før du kaster deg over neste feil. Ta en kort pause og vær stolt over hva du har fått til!
10. Ikke vær redd for å si “nei” Som utvikler i en bedrift er det din jobb å kjenne til mulighetene med teknologien, men også begrensningene. En medarbeider vil sette pris på at du som fagperson stiller kritiske spørsmål til utvikling av systemer og løsninger. I teorien er alt mulig innen IT, men det er din jobb å vite hva kostnaden av å utføre det blir. Det er like viktig at man ikke sier ja til alt, akkurat som at man ikke sier nei til alt.
60% av utviklere rapporterer at de <a href="https://www.kode24.no/kodelokka/60-prosent-jobber-overtid-hver-uke/71078276">jobber overtid</a>. Du kan ofte bli spurt om du “bare kan fikse denne lille ekstra tingen?”. Kvaliteten på det du skal gjøre kan fort bli dårlig dersom du alltid påtar deg ekstra arbeid eller jobber for raskt. Det er viktig å sette grenser for deg selv når det kommer til ansvar og overtid.
11. Å sprekke på et estimat er ikke verdens undergang ;) Å bomme på estimat er noe både nye og erfarne utviklere opplever hele tiden. Det viktige er å tilegne deg verktøy og erfaring som lar deg melde ifra tidlig. Jo tidligere et team melder i fra om at en leveranse overgår estimatet, jo større spillerom har alle involverte i prosjektet.
… Og med dette gjenstår det bare å ønske deg masse lykke til i arbeidslivet!
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=974fb21592e" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/10-ting-jeg-skulle-%C3%B8nske-noen-fortalte-meg-da-jeg-begynte-%C3%A5-jobbe-som-utvikler-974fb21592e">10 ting jeg skulle ønske noen fortalte meg da jeg begynte å jobbe som utvikler</a> was originally published in <a href="https://medium.com/dfind-consulting">Dfind Consulting</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Av: <a href="https://medium.com/u/8fb5525e0684">Eirik Gihle</a> og <a href="https://medium.com/u/cbae7ec46d93">Karianne Tørum</a>
1. Det er ingen andre på kontoret som sitter med fasiten når det gjelder design! De rutinerte har selvfølgelig erfaringer som er verdt å ta med seg, og de kjenner fallgruvene fra tidligere prosjekter. Men,- det er ikke det samme som at de har fasiten for neste prosjekt. Verden forandrer seg fort! Det som var riktig og viktig før trenger nødvendigvis ikke være verken riktig, eller viktig nå.
2. Vi er ikke hjernekirurger! (og heldigvis for det…) Jeg tror det er viktig å ha perspektiv på hva vi som designere faktisk kan oppnå. Et godt og gjennomtenkt design kan gjøre at produkter og tjenester selger eller fungerer bedre. En god strategi og et tett samarbeid med forretningsutvikling og utviklingsmiljøene kan også bidra til at vi evner å lage produkter som betyr noe for brukergruppene. Og det er topp når det funker! Men det er faktisk litt alright å tenke på at, — så lenge du ikke designer en hjertestarter eller utvikler et nytt varslingssystem for nødsituasjoner er det ingen som dør. Ingen! Vi som designer en merkevare, en applikasjon eller en nettside har rom for å lære gjennom å feile. Og det syns jeg er skikkelig digg å tenke på… samtidig som jeg får veldig stor respekt for de som må ta de virkelig store avgjørelsene, som påvirker livene til folk på en helt annen skala enn designet på Zalando gjør.
Jeg tror jeg ville senket skuldrene litt, og kanskje turt å være mer utforskende dersom dette var kommunisert litt tydeligere da jeg begynte som designer.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*d0-mmUDnZZpqscbjnAizzw.jpeg"><figcaption>Photo by <a href="https://unsplash.com/@mimithian?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Mimi Thian</a> on <a href="https://unsplash.com/s/photos/listening?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Unsplash</a></figcaption></figure>3. Lytt mer enn du prater! Dette var en av tingene jeg faktisk ble fortalt, — av en meget klok kollega jeg hadde noen år tilbake. For å bruke hans egne ord, (Correct me if I´m wrong Frank Myrseth): “Det er en grunn til at vi har to ører og bare én munn”. I vår iver etter å overbevise om at man har designet en fantastisk løsning, kan man lett gå glipp av verdifulle perspektiver, dersom man ikke stopper opp og tar i mot innspill fra utsiden. Dessuten er jo nøkkelen til et godt design å faktisk forstå hvilket problem som skal løses.
Siden verden har forandret seg mye siden jeg tok min utdanning og startet i min første jobb, er det ting som selvsagt ingen kunne ha forutsetning for å si, men som jeg håper blir sagt nå:
4. Tenk som en utvikler! Å jobbe strukturert har alltid vært en god ting. Men nå, når vi designer løsninger som skal fungere på fler og fler formater, der brukerne egentlig i praksis selv kan styre mye av hvordan de ønsker å få presentert et innhold, blir det viktigste av alt å utvikle et solid bunnsystem som kan fungere godt på alle flater. NB: Dersom du f.eks. designer et bokomslag kan du se bort fra dette punktet. Da kan du velte deg i fantastisk typografi som bare passer for akkurat det ordet du skal skrive og bruke ditt skarpe visuelle blikk til å tilføre en unik stil der du har latt deg inspirere av akkurat de du vil!
5. Jobben er aldri ferdig! Ingenting av det vi gjør er hugget i stein, og det kan det ikke være heller. Vi må tørre å lansere ting, selv om det ikke er perfekt. For perfekt blir det aldri. I samme øyeblikk som man lanserer noe, begynner man å lære hva som fungerer og ikke. Og nye ting kommer inn fra sidelinja, hele tiden. Dette gjør at vi må tenke nytt og justere systemet vårt kontinuerlig. Så jeg må gjenta meg selv fra punkt 1, bare med en kortere tidshorisont denne gangen: Det som var riktig og viktig «i går» trenger nødvendigvis ikke være verken riktig eller viktig «i dag».
6. Aksepter at du aldri får full kontroll! Design er et håndverk, og vi elsker når alt sitter. Men siden alt er i endring, som nevnt i forrige punkt, må vi tåle å ikke ha full kontroll over alt. Det er for mye for en person. Så enkelt er det. Man bør selvfølgelig klamre seg fast i den røde tråden, og ta høyde for så mange eventualiteter man kan komme på. Men, med et slikt utall av flater og formater vi har i dag, skal du ikke bli lei deg hvis en komponent fikk et merkelig linjefall på én av flatene, i én av nettleserne. Da fikser du det i morgen. Hvis det er viktig nok!
7. Å feile er ikke feil! Det er faktisk ikke det. Vi prøver, vi seirer, vi feiler og vi lærer… og vi utfordrer! Vi må aldri bli så redd for å feile at vi ikke tør å utfordre. Det er bedre å feile litt på veien, dersom man har lært hvordan man kan flytte på noen barrierer, enn å ha gjort alt etter boka… og stå på stedet hvil. Som en leder jeg en gang hadde sa så fint: “Siden vi lærer så mye av å feile, må vi feile oftere, og vi må feile mye fortere!”
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*maurjo94aWjtzeoMZKkncA.jpeg"><figcaption>Photo by <a href="https://unsplash.com/@johnschno?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">John Schnobrich</a> on <a href="https://unsplash.com/s/photos/collaborate?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Unsplash</a></figcaption></figure>8. En ide blir mer verdt når den deles! Uansett hvor mye du har satt deg inn i et tema, og hvor mye du kan, klarer du ikke å se ting med andres øyne. Kommunikasjon er alltid på mottakers premisser. Og jo flere mottakere du klarer å involvere, jo større er sjansen for å lykkes. Man kan selvfølgelig føle seg sårbar ved å dele uferdige idéer, og det er helt normalt. Men det er fort glemt når gevinsten i den andre enden er at man har alle på lag, og konseptet er bunnsolid. Les gjerne; <a href="https://medium.com/dfind-consulting/tverrfaglig-samarbeid-genererer-store-besparelser-62b9f6225d7b">“Tverrfaglig samarbeid genererer store besparelser”</a>
9. Vær bevisst ditt samfunnsansvar! Skal man lykkes med konseptene sine, må man som sagt involvere brukere. Da er det også viktig å huske at en bruker kan ha mange ansikter. Jeg snakker selvfølgelig om universell utforming, eller “design for alle”. UU kan ikke være noe man bare “legger på” på slutten. Fordi det handler ikke bare om skriftstørrelser og kontraster og at man kan tab´e seg gjennom løsningen. Det handler også om hvordan man prioriterer innhold i grensesnittet sitt.
Hvordan oppleves designet for en person med konsentrasjonsvansker, hvor lett er det å forstå for en person med Alzheimer, og hvilke overskrifter blir lest opp for svaksynte som benytter skjermleser?
Selv om det finnes mange gode føringer, kan man ikke lese seg til alt! Så inkluder alle mennesketyper som kan finne på å bruke løsningen din. Inkluderende design ja, det var det ordet jeg lette etter.
10. Du er flink! En slik kommentar fra en leder eller kollega betyr mer enn det koster å si. Er du opptatt av det du gjør, jobber hardt og interesserer deg i oppgaven, gjør du mest sannsynlig en god jobb. Og får du den kommentaren, er sannsynligheten stor for at du fortsetter å være akkurat det, — flink… og kanskje bli enda flinkere!
Lykke til!
Håper vi sees en dag :)
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=99d5720b9af4" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/10-ting-jeg-skulle-%C3%B8nske-noen-fortalte-meg-da-jeg-begynte-%C3%A5-jobbe-som-designer-99d5720b9af4">10 ting jeg skulle ønske noen fortalte meg da jeg begynte å jobbe som designer</a> was originally published in <a href="https://medium.com/dfind-consulting">Dfind Consulting</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

I 2004 skjedde det noe som fikk store konsekvenser. Det var da vi fikk deltagerdrevne interaktive tjenester, også kjent som web 2.0. Vår intelligens ble koblet sammen i samtid og vi kunne jobbe sammen innenfor samme rammer, ikke lenger bare løsrevet på egenhånd.
Av: <a href="https://medium.com/u/cbae7ec46d93">Karianne Tørum</a> og <a href="https://medium.com/u/8fb5525e0684">Eirik Gihle</a>
Takket være denne innovasjonen kan vi i dag diskutere, gi og få tilbakemeldinger på eget og andres arbeid i samtid og vi kan designe løsninger sammen med andre, løsrevet fra sted og tid. Konseptet der enkeltindivider opererer som «kreative genier» har gradvis gått forbi (– og takk for det)! Det faktum at digitale produkter og tjenester er komplekse har ført til en erkjennelse av at selve prosessen og produktet blir bedre når flere fagfelt jobber sammen mot et felles mål. Med gode digitale samarbeidsverktøy har det blitt enklere å involvere flere i designprosessen, også fra andre fagfelt.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*0IX5b7kLQw-m0-wq"><figcaption>Photo by <a href="https://unsplash.com/@homajob?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Scott Graham</a> on <a href="https://unsplash.com/s/photos/work?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Unsplash</a></figcaption></figure>Design Collabration Før i tiden var det vanlig å sette navnet sitt på alt man hadde laget. Spesielt innen design. Man satte gjerne eget navn på illustrasjoner, eller firmaets logo dersom et produkt var utviklet av et byrå. Designmanualer som ble trykket var forbeholdt ansatte i selskapet, og designmanualer på nett var gjerne passordbeskyttet. Vi var opptatte av «åndsverksloven», og at ingen skulle stjele idéene våre. Og tanken var god, den gang. Alle skulle få noe igjen for arbeidet sitt, og alle skulle bli anerkjent for det de hadde utviklet. Det vi imidlertid ikke hadde like mye av var effektiviteten og standardene. Som bruker av en tjeneste ønsker vi forutsigbarhet. Ikke nødvendigvis at alt skal se likt ut, men vi ønsker ikke å bruke tid på å vurdere om knappen kan trykkes på, eller på hvilken måte man kan zoome inn på et bilde. Faste mønster gjør det lettere for alle, og et selskap alene kan ikke stå for opplæringen av et helt samfunn. Derfor kopierer vi hverandre, — med god grunn! (Det hadde forresten også vært ganske slitsomt å reise rundt i verden om alle verdens T-banekart så helt forskjellige ut.) Teknologi og design går i dag hånd i hånd, og det er ikke bare mellom designere det deles. Design Collaboration er en tilnærming til design hvor man erkjenner avhengigheten av andre fagfelt for å kunne flytte en abstrakt idé til et ferdig produkt. Et slikt samarbeide bringer flere perspektiver inn i utviklingsfasen og man ser en utfordring fra flere vinkler, og kan vurdere ideer fra ulike faglige perspektiver. Å tørre å slippe designet sitt, for å la andre bygge videre på idéene man har, bidrar ikke bare til å sikre et mer robust konsept, men kan i tillegg gi et langt større markedspotensiale. Det å kunne diskutere idéer og la andre bygge videre på dem gjør dem robuste med et større markedspotensial.
Økonomisk perspektiv Vi designere i skandinavia er veldig flinke til å plassere brukere og deres behov i sentrum, men vi er også avhengig av å forstå og inkludere det økonomiske aspektet tidlig i utviklingsprosessen. Det koster å utvikle og forvalte en tjeneste, og tjenesten som utvikles må generere penger i form av inntekt fra sluttbruker eller besparelser ved at tjenesten overtar for eksisterende løsning og frigjør kapital. En god designmetodikk koblet med analytisk tilnærming er derfor nødvendig. Et eksempel på økonomisk besparelse ved hjelp av god metodikk kan være samarbeide mellom designere og utviklere tidlig i designprosessen for å sikre at man tar høyde for de tekniske mulighetene som er tilstede og kartlegge eventuelle begrensninger. Dermed elimineres potensielle dyre tekniske sperringer allerede tidlig i utviklingsfasen. Det er også begrenset hvor mye personer fra ett fagfelt klarer å arbeide alene når man skal vektlegge brukerbehov og definere produktmål. Andre tiltak som gir økonomisk gevinst er endringen fra designmanualer til åpne designsystemer. Slike designsystem utvikles gjennom Design collaboration og genererer enorme besparelser da ferdiglagte komponenter og kodebibliotek gjenbrukes, både i skissefaser og utviklingsfaser, på tvers av hele applikasjonen. Det sikrer også en helhetlig og enhetlig profil og, ivaretar merkevaren på alle flater og kanaler.
Effektive verktøy For å gjennomføre effektive prosjektsamarbeid, er det viktig at man har gode verktøy som legger til rette for samarbeid. Slike samarbeidsverktøy fjerner flere barrierer for de involverte parter ved at det er enkelt å få tilgang til det som lages og man kan designe sammen i sanntid. Det hjelper til å holde fokus på rett sted, og man kan samarbeide om design og flyt uten å ødelegge en “original”. Før var vi avhengig av verktøy som gav oss grunnleggende versjonskontroll i steden for effektiv samarbeid. En hver designer satt på sin versjon og lastet for eksempel en sketch-fil opp i dropbox. Et annet team-medlem måtte så laste det ned, gjøre sitt arbeid for så å laste det opp igjen. Det å gjøre kjappe endringer var vanskelig siden et annet teammedlem kanskje satt og arbeidet med filen. Denne versjonskontrollen gjorde et effektivt samarbeid vanskelig, tidkrevende og lite motiverende. Nå har designerne fått nye samarbeidsverktøy som for eksempel Figma. Her kan de involverte jobbe i samme fil på samme tid, kommunisere med hverandre i samtid og involverte stakeholders som for eksempel jurister eller produkteier. Man kan chatte, lage prototyper, gjennomføre brukertester, og generere CSS og html til frontendutviklerne. Rett og slett ganske så flott og på tide!
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=62b9f6225d7b" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/tverrfaglig-samarbeid-genererer-store-besparelser-62b9f6225d7b">Tverrfaglig samarbeid genererer store besparelser</a> was originally published in <a href="https://medium.com/dfind-consulting">Dfind Consulting</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Nysgjerrige folk med forskjellig kompetanse gir nye perspektiver og styrker oss som selskap. Du bør ha relevant utdanning og minimum 3 års erfaring som utvikler, designer, arkitekt eller prosjektleder. Bli med på laget!

Bli en av oss banner

Møt en X banner

Vi elsker teknologi og løsninger vi kan lage for både den private og offentlige sektor. 

I dag kreves det kontinuerlig nye funksjoner i applikasjoner for å være konkurransedyktige, derfor er vi en smart samarbeidspartner som innehar kompetanse innen flere ulike frontend rammeverk, kunstig intelligent, maskinlæring, skytjenester, DevOps og solid backend kompetanse.

Systemutvikling artikkel

Systemutvikling

UX design handler om totalopplevelsen, selve brukeropplevelsen en bruker har i et møte med en digital tjeneste, system eller produkt. 

Våre designere lytter og utvikler krav basert på innsikt, lager prototyper, tester og itererer til tjenesten tilfredsstiller brukeren og bedriftens krav. Vi jobber tverrfaglig med grafisk-, tjeneste- og interaksjonsdesignere for å lage løsninger med høy brukskvalitet og gode bruksopplevelser. Våre design-konsulenter har lang erfaring og jobbet med mange kunder i privat og offentlig sektor. Vi har særdeles god kompetanse på smidige brukersentrerte designprosesser og universell utforming.


Mange lurer på hva som er forskjellen på UX og UI-designer. En interaksjonsdesigner jobber gjerne med selve flyten i en tjeneste og hvordan ulike systemer skal samarbeide optimalt slik at brukeren av tjenesten får en god opplevelse (UX), mens en grafisk designer lager utseendet/grensesnittet.  Det vil si alt fra hvordan knapper er utformet, bredde, høyde, former og farger på tekstfelter, objekter og bilder, til hvilket  til hvilke animasjoner man skal bruke (UI). 

Forenklet kan man si at UX handler om hvordan en nettside eller digital tjeneste fungerer, mens UI er det grafiske uttrykket i tjenesten eller på websiden. 
Både UX og UI er essensielle når man utvikler og lager digitale tjenester eller produkter. Fungerer UX og UI optimalt får du en god brukeropplevelse.

Våre konsulenter har lang erfaring innen både tjeneste-, interaksjon- og grafisk design og har løst mange utfordringer for store nasjonale aktører. 

skumring

Design artikkel

UX design

Et digitalt produkt skal fungere på flere platformer og enheter uten at kunden opplever at kvaliteten forringes. Det krever derfor god prosjektledelse som ser helheten og samtidig de enkelte komponentene i et utviklingsmiljø.

Våre prosjektledere/teamledere fungerer som rådgivere for våre partnere. Vi er smidige og tilpasser oss våre kunders behov og skalerer prosjektene ut fra omgivelsene, eksisterende rammeverk og krav. Vi er oppdatert og kjenner til ulike metoder som passer best til forutsetningene, om man sikter mot en MVP som skal itereres eller et rammeverk som skal forvaltes på en hensiktsmessig måte. Våre konsulenter ser helheten i systemporteføljen og sikrer god informasjonsflyt mellom de involverte parter.

Prosjektledelse artikkel

Prosjektledelse

En systemarkitekt sørger for at en utviklingsprosess tar hensyn til allerede eksisterende infrastruktur og hvordan ulike tjenester og produkter samhandler best mulig for å oppnå ønsket mål.

Våre arkitekter ser helheten i infrastrukturen og sørger for at en agil utviklingsprosess kan gå så smertefritt som mulig. De beskriver hvordan ulike tjenester og produkter samhandler best mulig for å oppnå ønsket mål, uten nedetid for øvrige funksjoner.  

Arkitektur artikkel

Arkitektur

Vi jobber med systemutvikling, brukeropplevelser (UX), prosjektledelse, rådgivning og arkitektur.

Prosjektledelse og rådgivning

Siste blogginnlegg

Tre faktorer som genererer indre motivasjon

«Mamma, det er noe galt med Vipps…

Bli en av oss

Les om hvordan det er å jobbe hos oss