<figure><img alt="Image of “Design Systems” spelled out with colorful lego bricks, showcasing how legos can be used as an analogy for a design system" src="https://cdn-images-1.medium.com/max/1024/1*JzLRrvtQL1tVMWn6w9GUGg.png"></figure>Design systems have become a crucial part of creating user-centered and visually appealing products. They provide a set of guidelines that designers follow to ensure consistency, scalability and clarity throughout the design process. But where can we find inspiration for these systems? In this article, we explore the design principles of one unexpected source: LEGO. We will delve into how LEGOs can be used as an example of a natural atomic design system and how its design principles can be applied. Let’s dive in, think outside the box and see how LEGOs can inspire your next design system project.
As a designer, I’ve always been fascinated by the principles of design systems. So, when I was assigned to lead the rebranding of a previous employer’s identity, I realized that I had to find the right inspiration. That’s when it hit me: LEGO.
I had always loved playing with LEGOs as a kid, but as I began to study their design principles, I was truly amazed by their level of consistency, modularity, and clarity.
I realized that the iconic little blocks and pieces represent the atoms of a design system. Those atoms come together to form smaller components, which are the molecules, and molecules come together to form organisms, which form products that exist within a theme. The higher up the chain you go, the more specialized things become. This structure is very similar to Brad Frost’s <a href="https://atomicdesign.bradfrost.com/">Atomic Design principles</a>.
I learned a lot from my research and I want to share this knowledge with others. That’s why I decided to write this article, to show how LEGOs can be an excellent source of inspiration for any design system.
<h4>1. Introduction</h4>
<blockquote>A design system is a collection of guidelines, components, and tools used to build and maintain a consistent user experience over time.</blockquote>
LEGO can be used as an analogy to explain design systems. Just as LEGO bricks are used to build structures, design system components (such as colors, typography, and buttons) are used to create interfaces. Like LEGO bricks, design system components are modular and can be used in a variety of ways to create different designs.
In this article, we will explore how LEGO can be used as an analogy to explain design systems, the importance of design systems in creating a consistent user experience and how to implement a design system in your organization.
<h4>2. Building with LEGO vs. a design system</h4>
<figure><img alt="A pile of various colored and shaped LEGO bricks, showcasing the modularity and flexibility of LEGO" src="https://cdn-images-1.medium.com/max/1024/0*hKmTUrlUo7V27Tmm"><figcaption>Photo by <a href="https://unsplash.com/@xavi_cabrera?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Xavi Cabrera</a> on <a href="https://unsplash.com/photos/kn-UmDZQDjM?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Unsplash</a></figcaption></figure>Building with LEGO involves using a variety of different shaped and colored bricks to create structures. These bricks are designed to fit together in a specific way, allowing for the creation of intricate and complex designs. This modularity of LEGO bricks is similar to the modularity of design system components, which can be combined in various ways to create different designs.
<figure><img alt="An image of a detailed replica of the Tatooine Cantina from Star Wars, built entirely out of lego bricks, showcasing the intricate designs and possibilities of lego building." src="https://cdn-images-1.medium.com/max/1024/0*i9RkGl2MFFRJvbGd"><figcaption>LEGOs can be used to create anything you can imagine, as long as you have the right pieces and know how to put them together. Photo by <a href="https://www.flickr.com/photos/tales2astonish/">marvelousRoland</a> on Flickr. (1)</figcaption></figure>In the same way that LEGO bricks have specific guidelines on how they should be used to create stable structures, design system components also have specific guidelines on how they should be used. These guidelines help ensure that the final product is consistent and visually pleasing.
Additionally, LEGO sets come with instructions on how to assemble the bricks into a specific, repeatable design. In the same way, a design system includes instructions on how to use its components to create cohesive designs. This allows for consistency across different designs and projects.
<figure><img alt="“Consistency is one of the most powerful usability principles: when things always behave the same, users don’t have to guess what will happen.” — Jakob Nielsen" src="https://cdn-images-1.medium.com/max/1024/0*z9ye9ZgqD63y9sSE"><figcaption>This quote from Jakob Nielsen highlights the importance of consistency in creating a user-friendly experience, which is one of the key principles of a design system.</figcaption></figure><h3>3. The LEGO Design System</h3>
<figure><img alt="An image of the packaging of a LEGO TIE-Bomber set, showcasing the branding and product design of LEGO." src="https://cdn-images-1.medium.com/max/1024/0*oGa8JGEdlFkRWgCV"><figcaption>A LEGO Star Wars Tie Bomber set, showcasing how LEGO’s design system is used to create consistent and recognizable products across different franchises. Photo by <a href="https://www.flickr.com/photos/tales2astonish/">marvelousRoland</a> on Flickr (2).</figcaption></figure>Just like any other company, LEGO has its own design system which is used to ensure consistency across its products. This design system includes a color palette, typography, and iconography that are used in the creation of LEGO sets, packaging, and other materials.
The LEGO design system is used in the development process of new products, from initial concept to final packaging. It ensures that all products have a recognizable LEGO look and feel, making it easy for consumers to identify them as LEGO products.
The different components of the LEGO design system, such as the color palette and typography, are used in combination to create consistent designs. This consistency helps to strengthen the LEGO brand and makes it easy for consumers to recognize and trust LEGO products.
<h4>4. Implementing a Design System</h4>
Implementing a design system in your organization can help to create a consistent user experience across all of your products and platforms. To begin creating your design system, it is important to involve all stakeholders in the process, including designers, developers, and product managers.
One of the first steps in creating a design system is to establish a set of design principles. These principles will guide the design decisions and provide a framework for the design system components.
Some examples of design principles:
<ol>
<li>
Consistency: The consistent use of design elements across different platforms and devices to create a cohesive user experience and recognizable design (LEGO bricks are designed to fit together in a specific way to create a consistent structure).
</li>
<li>
Modularity: The design of the interface should be modular, with reusable and flexible components, allowing for adaptability and scalability (LEGO bricks can be used in a variety of ways to create different designs).
</li>
<li>
Clarity: The creation of a clear and simple interface that is easy to understand and use, providing a seamless user experience and providing clear instructions (LEGO instructions guide you through the building process).
</li>
</ol>
Next, you should create a set of reusable components such as buttons, forms, and typography. These components should be tested and refined to ensure that they meet the established design principles.
<figure><img alt="An image of a set of basic design elements in a system, including buttons, checkboxes, radio buttons, and input fields." src="https://cdn-images-1.medium.com/max/1024/0*bS7iqLOVzwpjDJXW"><figcaption>An example of a few basic component sets in a design system. Images from Monio Design System.</figcaption></figure>Once the design system is in place, it is important to maintain and evolve it over time. This includes updating components as needed, and making sure that all new designs adhere to the established guidelines. It’s also important to provide training and resources to ensure that all team members are aware of the design system and understand how to use it.
<h4>5. TL;DR</h4>
<ul>
<li>Design systems are essential for creating a consistent user experience across different platforms and devices. The LEGO analogy helps illustrate the importance of using a set of guidelines and modular components to create consistent and recognizable designs.</li>
<li>Implementing a design system in an organization can take some time and effort, but it is worth it in the long run. It will improve the overall user experience and make it easier for the organization to create consistent and recognizable designs.</li>
<li>A design system is like a set of LEGO bricks, when you have all the right pieces and know how to use them, you can build something great.</li>
<li>A design system is a living document: it is important to remember that a design system is not a one-time project, but a living document that should be constantly reviewed and updated to reflect the ever-changing needs of the organization and its users.</li>
<li>So, whether you’re building with LEGO bricks or designing interfaces, the principles of consistency, modularity, and guidelines will always be key to creating something great.</li>
</ul>
Credits
(1) “Blast from the Past: Tatooine Cantina MOC from 2010” by marvelousRoland on Flickr. Used under the Attribution-ShareAlike 2.0 Generic (CC BY-SA 2.0) license. Image source: <a href="https://www.flickr.com/photos/tales2astonish/">https://www.flickr.com/photos/tales2astonish/</a>. License terms: <a href="https://creativecommons.org/licenses/by-nc-nd/2.0/">https://creativecommons.org/licenses/by-nc-nd/2.0/</a>
(2) “LEGO TIE-Bomber packaging” by marvelousRoland on Flickr. Used under the Attribution-ShareAlike 2.0 Generic (CC BY-SA 2.0) license. Image source: <a href="https://www.flickr.com/photos/tales2astonish/">https://www.flickr.com/photos/tales2astonish/</a>. License terms: <a href="https://creativecommons.org/licenses/by-nc-nd/2.0/">https://creativecommons.org/licenses/by-nc-nd/2.0/</a>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=8de430df74d3" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/creating-consistency-how-lego-can-help-us-build-better-design-systems-8de430df74d3">Creating Consistency: How LEGO Can Help Us Build Better Design Systems</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.

Creating Consistency: How LEGO Can Help Us Build Better Design Systems

Dfind Direction er vår satsning på ledelse, arkitektur og rådgiving, enkelt og greit.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*3-u42TfNnSpbbJV5Y8M7zw.jpeg"></figure><h3>Hvorfor?</h3>
Vel, først blir det litt historiefortelling. Det hele startet i 2016. Consulting så dagens lys og i løpet av 2017 hadde de første pionerene blitt med på skuta. Hovedvekten av konsulenter var utviklere selv om man også hadde prosjektledere og arkitekter i tillegg til UX og andre roller. Det har vært en god vekst i selskapet og når vi etter hvert nærmet oss og passerte 150 ansatte ble utfordringene tydeligere. Flesteparten av konsulenter og kunder kjente oss som et konsulentselskap med utviklere og det ble vanskelig å vise mot både kunder og potensielle nye kolleger at vi hadde mange andre bein å stå på. I tillegg så vi at det var forskjellige behov både avhengig av hvilken profil man har, men også også mtp. senioritet. Man er på forskjellige steder i livet rett og slett.
Dfind Direction ble etablert som vår satsning på ledelse, arkitektur og rådgiving med de av våre konsulenter som kjente seg igjen i denne beskrivelsen. Flere har blitt med siden den gang.
<h3>Hvorfor prosjektledere og arkitekter i samme gruppe?</h3>
I bunnen er vi IT-konsulenter alle sammen. Det vil si at vi er prosjektledere, produkteiere, scum mastere, team lead, tech leads og arkitekter i IT-prosjekter. Alle er tekniske i bunnen eller direkte i sin rolle.
I et samfunn som stadig blir digitalisert og hvor nye og kommende generasjoner er født digitale, vil flere og flere selskaper, organisasjoner og offentlige aktører ha alle sine prosesser digitalisert. Conways lov og prinsippet om at organisasjoner vil utvikle IT-systemer som gjenspeiler organisasjonen, viser oss at det er en særdeles sterk link mellom arkitektur og ledelse. På mange måter går de hånd i hånd og det er behov for lik kompetanse i begge leire.
Til sist vil jeg også poengtere at arkitekt og prosjektleder bare er paraplybetegnelser i mine øyne. De favner flere og mer definerte roller slik som jeg har forsøkt å illustrere under. Noen konsulenter har flere av disse hattene, mens noen har gjort et dypdykk ned i én. Det de har til felles er at det kreves en del erfaring og senioritet
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*ErV5_5dCaAqwZm9glCx10A.png"></figure>Erfaringen vi har gjort oss i vekstperioden er at det er krevende å kombinere mange spesialiseringer i samme gruppe. Det er veldig mye man har til felles, men det er også en del unike og egne behov. Det krever et visst fokus og det krever muligheten til å gjøre ting annerledes. Med vår filosofi om autonomitet, selvstyre og et selskap bygget av og for konsulenter, er den naturlige tilnærmingen å starte opp en egen divisjon, så selvstyrt som mulig, og nesten som et eget selskap i selskapet.
<blockquote>Poenget er at det er må være fleksibelt nok til å forme seg i takt med konsulentene i selskapet.</blockquote>
På bakgrunn av alt dette ble Dfind Direction etablert. Vi jobber fortsatt med “å finne oss sjæl”. Dette er kontinuerlig arbeide og aller viktigst; det er noe vi gjør sammen.
<h3>Første strategisamling</h3>
Pandemien gjorde at vi ikke fikk startet slik vi ønsket så når høsten 2021 kom så vi vårt snitt til å samle alle i direction og gjennomføre den første strategisamlingen vår.
Målet var å finne ut hva Direction er for oss og hva som er de viktigste verdiene for alle som er med i Direction.
Workshoppen gikk som følger:
<h4>Halen på grisen, aka hvor er vi i markedet</h4>
For å skjønne litt mer om oss selv var det interessant og også se på andre. På den måten kan vi se hva som var unikt for oss, men også bekrefte enda litt tydeligere hvem vi er.
Vi startet med å definere to akser hvor den ene går fra teknologi til forretning og den andre fra rådgivende til implementerende. Deretter plassere vi oss selv og andre konsulentselskaper i denne matrisen. Det er ikke så interessant hvor andre er, men det vi oppdaget om oss selv er at vi vil være mer implementerende enn rådgivende når det gjelder forretning og mer rådgivende når det gjelder teknologi.
Det er ikke et veldig overraskende resultat for prosjektledere og arkitekter, men det er en fin måte å visualisere det på. Det er også mulig å snakke om hvor man er og hvor man vil være og utvikle en strategi for å bevege seg i den retningen man vil.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/796/1*Ns4Q_Xyp3Yg4MrQb2SNVTw.png"></figure>Her er noen eksempler på konsulentoppdrag og hvordan det ville plassert seg i matrisen
<ol>
<li>Rådgivende/teknologi: Teknisk revisjon</li>
<li>Teknologi/implementerende: Utvikler i et team</li>
<li>Implementerende/forretning: Forretningsutvikler eller produkteier</li>
<li>Forretning/Rådgiver: Markedsundersøkelse/rapport</li>
</ol>
De aller største selskapene har gjerne en fot i alle kvadranter og det blir sånn sett vanskelig å plassere de. Derfor havnet alle i midten
<blockquote>Et svært viktig prinsipp vi fikk ut av denne øvelsen er at de gangene vi har rådgivende roller eller er i en posisjon hvor vi blir spurt om å gi råd, så skal vi også være i stand til å implementere det vi snakker om.</blockquote>
<h4>Cover story</h4>
For å få brukt kreativiteten litt krydret vi med noen “klippe og lime” aktiviteter. Med “Cover story” skal man ha litt vyer og se for seg en tenkt avis eller magasinforside om 15 år. Det skrives om dere. Hva står det?
Gruppa klippet og limte med både hvitt og farget papir. Det ble mye forskjellig, men felles for de alle var at Dfind Direction skulle være et sted hvor folk ønsket å bli værende.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/526/1*CNH74xBBEI_uo3iqaKunrg.png"><figcaption>Et av bidragene</figcaption></figure><h4>Verdibrainstorming</h4>
Kanskje det viktigste aktiviteten for dagen. Den gjennomføres ganske enkelt som en brainstorming med påfølgende presentasjon og diskusjon før vi grupperer like lapper og til slutt stemmer på hva vi mener er viktigst.
For å fokusere på verdier hadde vi noen “knagger” man kunne bruke for å komme i gang:
<ul>
<li>Kollegaer og sosialt</li>
<li>Faglig innhold og utvikling</li>
<li>Verdier og holdninger</li>
<li>Roller og oppgaver</li>
<li>Bli motivert</li>
<li>Kompensasjon</li>
<li>Familie og venner</li>
</ul>
Vi fylte en vegg med post-it lapper og vell så det. I mylderet viste det seg etter hvert at det var noen områder som var viktige for alle sammen
Work/life: Mange har famile eller andre utenomsportslige aktiviteter. Vi ønsker en arbeidsplass som tilrettelegger for at vi yter og utvikler oss så godt som mulig
Fag: Faglig styrke er ikke bare en enorm styrke for selskap og kunde, det er også hvem vi er. Vår stolthet ligger i å gjøre en god jobb, designe gode systemer eller etablere vellykkede team og produkter. Om vi ikke kontinuelig utvikler oss og selv vil vi hverken trives eller lykkes.
Sosialt: Den store utfordringen for de fleste konsulentselskaper hvor vi er hos kunde store deler av dagen er å holde på et sterkt bånd med sine kollegaer. Dette er viktig for oss og vi må jobbe for å skape arenaer som legger til rette for dette.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/455/1*HEPFM5hPRbvyUCNskcohCQ.png"></figure>Til slutt snakket vi om sammenhengen mellom disse. Fag og sosialt må balanseres med work-life. Finner vi balansen mellom disse tre er vi på riktig vei
<h4>Product box</h4>
Den siste øvelsen vi gjorde på denne samlingen var også av det kreative slaget. Her skulle vi se for oss hvordan det hadde sett ut om en Dfind Direction hadde vært et produkt som ble levert i en boks. Hva trekker vi frem som unike egenskaper på innpakningen?
<figure><img alt="" src="https://cdn-images-1.medium.com/max/781/1*vYTha1EYNXavlzSe2rU2Tg.png"></figure>En fantastisk morsom øvelse hvor vi fikk brukt alle kvaliteter vi lærte oss på kunst og håndverk på ungdomsskolen. Skal vi trekke frem noen av de viktigste egenskapene ved Dfind Direction er det (1) Faglig styrke og kvalitet, (2) Familie og work-life balance, (3) likestilling og (4) levere det vi prater om.
Mange av de samme punktene gikk igjen gjennom alle øvelsene. Dette er mye fordi det etter hvert blir forankret i gruppa og gjentar seg selv av den grunn, men også fordi vi lykkes med å finne noe som er viktig for alle. Det er sånn vi skal utvikle oss i Direction. Det er høy kompetanse og folk med såpass lang erfaring at når vi legger hodene sammen så får vi det til.
<h4>Oppsummert</h4>
Om vi skal prøve å oppsummere det som er starten på en strategi for Direction ser det ca sånn ut.
<ul>
<li>Gir solide råd og veileder, men må kunne “walk the walk” og implementere det vi snakker om, både teknologi og prosess for teknologiutvikling.</li>
<li>Vi er sterke på teknologi, men også forretning, siden teknologi i større og større grad driver og definerer forretning og organisasjon</li>
<li>Dette er summen av Direction, hver enkelt konsulent har forskjellig kompetanse, men vi spiller på hverandre og utnytter hverandres kompetanse inn i prosjekt og problemløsning</li>
<li>Vi må legge til rette for fortsatt sterk faglig utvikling og sosialisering med kollegaer slik at det lar seg kombinere med disse andre viktige delene av livet. Og ikke minst gjør alt det andre lettere.</li>
</ul>
Direction har i dag blitt utvidet til alle Dfind Consulting sine kontorer og vi jobber med å definere oss selv som et nasjonalt nettverk på best mulig måte. Denne høsten ser vi på faglig utvikling så vi kan tilrettelegge for at både arkitekter og prosjektledere fortsetter med å styrke sin kompetanse på sine premisser.
Vi skal fortelle hvordan det har gått ved en senere anledning..
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=ea82454942b8" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/hva-er-dfind-direction-ea82454942b8">Hva er Dfind Direction?</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.

Hva er Dfind Direction?

<h3>Dfind Consulting Internship 2022</h3>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*bIkHM8F11nVKVT1pVOiACQ.jpeg"><figcaption>Jannicke Hamarsnes, Helena Skants, Skjalg Hovland Holtbakk, Eskil Schjølberg, Kavusikan Sivasubramaniam, Thea Kvinnegard, Ida Anseth, Duvara Nishaharan, Elsa Lossius (bak fv.) og Patrick Wulff.</figcaption></figure>Skrevet av Axel Aasen
Dfind Consulting har i år hatt sitt første internship. Over seks uker har ti sommerstudenter hatt ansvar for å lede et prosjekt for selskapet. I løpet av perioden har de utviklet en mobilapplikasjon og en webapplikasjon. Jeg har tatt en prat med sommerstudentene Thea Kvinnegard, Jannicke Hamarsnes og Ida Anseth for å få innsikt i hva de har arbeidet med og lært i løpet av perioden.
Sommerstudentene var delt inn i to team; Team App og Team Admin. Team App hadde ansvar for å utvikle mobilapplikasjonen, mens Team Admin hadde ansvar for å utvikle webløsningen. De to teamene var avhengige av hverandre gjennom hele prosjektet, og samarbeidet på tvers. På denne måten fikk de en realistisk opplevelse av hvordan man som konsulent jobber i prosjekt, med viktigheten av kommunikasjon, forventningsstyring, koordinering, prioritering og hvordan eget arbeid påvirkes av andres. Thea beskriver dette som en av de viktigste erfaringene hun tar med seg fra perioden.
“Å jobbe i parallelle team og se hvordan et slikt samarbeid kan fungere, å faktisk oppleve at det ikke alltid går smidig eller blir helt sånn man hadde tenkt har jeg lært utrolig mye av.”
For best mulig prosessgjennomføring benyttet teamene scrum som metodikk. Med daglig standup, ukentlig sprintplanlegging, demo og retro sikret studentene evaluering og progresjon underveis i prosjektet. Likt for begge teamene var at de rullerte uke for uke på hvem som var Scrum Master, slik at de som ville fikk prøve seg på denne rollen. Av studentene jeg har pratet med mente samtlige at dette var relevant og lærerik erfaring å ta med seg, og Thea beskriver hva hun erfarte i rollen::
“Å få jobbe ordentlig etter scrum-metodikk har vært en stor forskjell fra studiehverdagen til arbeidslivet. Som student er det ikke mulig å benytte slike metodikker fordi det ikke er nok kontinuitet i prosjektene. Det var en øyeåpner å se hvor bra scrum faktisk fungerer — gøy å oppleve.“
Jannicke legger til:
“I en uke hadde jeg hovedansvar for at teamet fulgte arbeidsformen vi hadde blitt enige om, og så til at vi kommer oss gjennom oppgavene som er prioritert. Dette er første gang jeg har fått prøve meg som Scrum Master, så veldig gøy å få prøvd meg på den rollen.”
Gjennom hele internshipet var produkteier og flere konsulenter fra Dfind Consulting tilstede for å bistå og støtte studentene underveis. Dette bidro naturligvis til trygghet for studentene, samtidig som det ga synergier på bakgrunn av mangfoldet de sammen utgjorde. Både Thea, Jannicke og Ida beskriver dette som en av de største forskjellene mellom studiehverdagen og arbeidslivet, og som noe av den viktigste erfaringen de tar med seg.
“Det var en trygghet å ha erfarne konsulenter fra Dfind Consulting i ryggen. Det å ha noen å spørre og sparre med gjør det lettere å komme videre om man står fast.”
“Dette er er jo en bransje som utvikler seg veldig raskt, så det er gøy å få sparre med konsulenter som er aktive i rollen … Vi får både bruke teknologier som er veldig relevante i arbeidslivet òg prøvd oss på de i trygge miljøer.”
Som studentene påpeker har vi sørget for å ta i bruk moderne teknologi som gir studentene relevant og etterspurt erfaring. Mobilapplikasjonen, som Team App hadde ansvar for, var en quiz-løsning som lar brukerne spille quiz live. Applikasjonens frontend ble utviklet i React Native, mens det i backend ble brukt Firebase, hvor Firestore ble brukt som database og Firebase Authentication ble brukt til logg-inn. Det ble også laget Firebase functions, blant annet for å håndtere Push-notifikasjoner. For å lage og administrere innholdet i quizen ble en webløsning utviklet som Team Admin hadde ansvar for. Løsningen ble utviklet i React og hostet på Firebase hosting. Som vi gjorde med mobilapplikasjonen, brukte vi også Firebase som backend i webløsningen.
Basert på tilbakemeldinger fra Thea, Jannicke og Ida, og de andre sommerstudentene i Team App og Team Admin, kan vi trygt si at vi har lykkes i Dfind Consulting sitt første internship. Thea påpeker at vi har bidratt til at hun har funnet sin plass i IT-verden, og med den tilbakemeldingen kan vi ikke konkludere med annet enn at vi har skapt verdi og fått til noe mer enn bare å utvikle et produkt. Vi ser frem til samarbeid med flere sommerstudenter i årene som kommer!
“Jeg føler den viktigste erfaringen jeg tar med meg er at jeg har funnet min plass i et team, men også min plass i IT-verden. Jeg har skjønt at det er her jeg ønsker å være, dette jeg vil jobbe med fremover — at jeg har valgt riktig.“
Er du nysgjerrig på hvilke muligheter som finnes som student i Dfind Consulting? Ta en titt på våre studentsider <a href="https://www.dfindconsulting.no/jobb-hos-oss#internshipArticle">her</a> for å lese mer.
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=9db3fd9222e4" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/dfind-consulting-internship-2022-9db3fd9222e4">Dfind Consulting — Internship 2022</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.

Dfind Consulting — Internship 2022

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*NNpIKZmLZ8bDSz79"><figcaption>Photo by <a href="https://unsplash.com/@vonshnauzer?utm_source=medium&amp;utm_medium=referral">Egor Myznik</a> on <a href="https://unsplash.com/?utm_source=medium&amp;utm_medium=referral">Unsplash</a></figcaption></figure>Did you know we can use Git reference logs to restore Git commit history(?) Often we developers experience challenges when working with Git. We can accidentally force-push commits to the remote main branch, complete a rebase that went bad, delete a branch we wanted to keep or hard reset to the wrong commit. In this post, we will look at git reflog and git reset. We will review some common scenarios on restoring local commits, restoring a deleted branch, and reverting force-pushed changes due to a rebase.
<h3>Git reflog</h3>
<a href="https://git-scm.com/docs/git-reflog">git reflog</a> is a tool that can help us recover almost anything — at least everything we have committed. The tool keeps track of commits that have been created but also discarded ones in a log called the reference log. The reference log is kept on our local computer under the .git directory in a local repository. It contains a list of commits that HEAD has pointed to and keeps track of the entire history of a commit. Besides the reference log for branches, we have a separate reference log for stash.
It’s important to know that reference logs do not track in the remote repository, like pushes, fetches and clones; it is purely local and current to the working environment. Below is two screencaps, the first from Github Codespaces and the second from a local filesystem that initially created all the commits of the main branch in the same repository:
<figure><img alt="" src="https://cdn-images-1.medium.com/max/964/1*L1DTjYe4kiUo01_95hL-dQ.png"><figcaption>Reference log from a workspace in Github Codespaces</figcaption></figure><figure><img alt="" src="https://cdn-images-1.medium.com/max/930/1*d175xjAzVotgtgHlFvjtQg.png"><figcaption>Reference log from local computer where the commits were initially created</figcaption></figure>Records of the history on a branch will expire after 30 days by default. We can change the expiration days running git reflog —expire if we want to keep the history for a longer time or just want to change the duration.
<h3>Git log vs reflog</h3>
<a href="https://git-scm.com/docs/git-log">git log</a> is a command that shows a list of commits related to a branch.git reflog is similar to git log but shows a list of snapshots and times when HEAD was changed. reflog can also reference other types such as stash, branches, rebase, merge and tags. A reference is known as refs, and the syntax for accessing these is name@{qualifier}. Running git reflog is the most basic use case and essentially the equivalent of writing git reflog show HEAD. The output will look like this:
<pre>=&gt; git reflog</pre>
<pre>47efaa2 HEAD@{0}: commit: refactor: remove post schema f243f12 HEAD@{1}: commit: refactor: change author fields 4783ba0 HEAD@{2}: commit: chore: add .env to gitignore a19d142 HEAD@{3}: commit: chore: update readme f5ade9a HEAD@{4}: commit: chore: update yarn.lock 854c08f HEAD@{5}: commit (initial): feat: bootstrap sanity studio</pre>
<h3>Git reset</h3>
<a href="https://git-scm.com/docs/git-reset">git reset</a> is a command we can use to move back to a previous commit, discarding or undoing previous changes. We can run git reset --hard &lt;commit_sha&gt; to move our branch back in the commit history.
<ul>
<li>
A hard reset (git reset --hard) will completely destroy any changes and remove them from your local repository.</li>
<li>
A soft reset (git reset --soft) will keep your changes, and stage them back automatically.</li>
<li>
A mixed reset (git reset --mixed) which is the default, will keep you changes but they will also become unstaged. Even tho it is flexible, you will have to stage the changes manually.</li>
</ul>
<h3>Restore local commits</h3>
<h4>Scenario</h4>
We have made some commits that haven’t been pushed to the remote repository yet. We do a git reset —-hard &lt;commit_sha&gt; to a previous commit, and our local branch is set back to an earlier point and discarded all history after the chosen commit. We then run git log and see that the commits are gone. We cannot pull the changes from the remote repository since we never synced the changes.
<h4>How to restore</h4>
When running git reflog we can see that our changes still are tracked by the reference log; we even have a separate commit for the hard reset that we did earlier:
<pre>f243f12 HEAD@{0}: reset: moving to f243f12 eec6f27 HEAD@{1}: commit: refactor: author should not have image 47efaa2 HEAD@{2}: commit: refactor: remove post schema f243f12 HEAD@{3}: commit: refactor: change author fields</pre>
With this information, we can reset our branch back to the state we discarded by using one of the references in the reflog. We can move our branch to the selected commit by running git reset --hard &lt;commit_sha&gt;:
<pre>=&gt; git reset --hard f243f12 =&gt; git reflog</pre>
<pre>f243f12 HEAD@{0}: reset: moving to eec6f27 f243f12 HEAD@{1}: reset: moving to f243f12 eec6f27 HEAD@{2}: commit: refactor: author should not have image 47efaa2 HEAD@{3}: commit: refactor: remove post schema f243f12 HEAD@{4}: commit: refactor: change author fields</pre>
<h3>Restore a deleted branch</h3>
We can recover deleted branches using SHA’s in the reference logs.
<h4>Scenario</h4>
Not uncommonly, we might checkout a new branch in our local environment. We could have a branch called chore/update-packages and commit a change that adds <a href="https://day.js.org/">dayjs</a> as a package:
<pre>=&gt; git checkout -b chore/add-dayjs-package =&gt; yarn add dayjs =&gt; git add . =&gt; git commit -m 'chore: add dayjs package'</pre>
<pre>5a75042 HEAD@{0}: commit: chore: add dayjs package</pre>
At a later point, we checkout the main branch and deletes the chore/add-dayjs-package branch — maybe we did not need it anymore for some reason:
<pre>=&gt; git checkout main</pre>
<pre>47efaa2 HEAD@{0}: moving from chore/add-dayjs-package to main</pre>
<pre>=&gt; git branch -D chore/add-dayjs-package</pre>
<pre>Deleted branch chore/add-dayjs-package (was 5a75042)</pre>
We will get a confirmation message that git deleted the branch. After a while, we discover that we could need the changes after all, so how do we get them back?
<h4>How to restore</h4>
We can undo these changes with git reflog and git checkout. If we run git reflog we won’t see any references to the deleted branch. We could use the commit SHA provided in the delete message (5a75042) to revert the latest commit on that branch. But if we have lost the message, we need to use the reference log. And if you named your commits well, it should be easy to find the missing commit:
<pre>=&gt; git reflog</pre>
<pre>// deletion of a branch is not logged to reflog 47efaa2 HEAD@{0}: moving from chore/add-dayjs-package to main 5a75042 HEAD@{1}: commit: chore: add dayjs package 47efaa2 HEAD@{2}: moving from main to chore/add-dayjs-package</pre>
We can now checkout the deleted commit SHA and create a new branch from that commit running git checkout -b &lt;branch_name&gt;:
<pre>=&gt; git checkout 5a75042 =&gt; git checkout -b chore/add-dayjs-package</pre>
<h3>Revert force-pushed changes</h3>
<h4>Scenario</h4>
We reset our branch using git reset —-hard to an earlier commit and run git push — force to override any changes that we otherwise could pull from the remote repository. But at some point, we want those changes back.
<pre>=&gt; git reset --hard &lt;commit_sha&gt; =&gt; git push --force</pre>
<h4>How to restore</h4>
We can use git reflog and git reset to restore force-pushed changes.
<pre>=&gt; git reflog f243f12 HEAD@{0}: reset: a19d142 to f243f12</pre>
By the log we can see that the message on HEAD@{0} is reset: a19d142 to f243f12, which means that commit with hash a19d142 was force-pushed by f243f12. That also gives us information about which commit we need to restore, the one with hash a19d142. We can simply do the same procedure as initially to move back to the overriden commit:
<pre>git reset --hard a19d142 git push --force</pre>
Finally, we force-push the new changes to the remote repository. Always be careful and check that you are on the correct branch before doing a force push. Especially to prevent that production code is not being affected or team member code is not being overwritten.
Thanks for reading! I hope you enjoyed this content. Feel free to clap, comment or share.
Code foh shizzle
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=67f7676e902f" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/restore-commit-history-with-git-reflog-67f7676e902f">Git reflog: Restore Version Control History</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.

Git reflog: Restore Version Control History

<h3>Fra student til konsulent — Løft blikket før skredet tar deg</h3>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*TE4iDhsn-kLJC4x4hHptgA.jpeg"><figcaption>Fra Camp Dfind 2022</figcaption></figure>August er alltid en spennende tid hos oss i Dfind Consulting. Sommerstudentene har nettopp blitt offboardet, mens våre nyutdannede kollegaer har sin første arbeidsdag som eksperter i IT. Dette innebærer naturligvis forventninger fra oss som arbeidsgiver, fra kunder og ikke minst fra den nyansatte selv. I dette innlegget skriver jeg om hvordan Dfind Consulting sørger for å møte deres forventninger gjennom vår onboarding-uke. Hensikten med uken er å gi nyutdannede en trygg start på karrieren og samtidig hjelpe dem på veien til å bli gode konsulenter. Slik lykkes Dfind Consulting i å utvikle markedsledende løsninger for våre kunder.
<h4>En nyutdannet sin styrke</h4>
Erfaring, hva har det egentlig å si i IT-bransjen? En erfaren topptur-gåer kan mest sannsynlig gå fortere, gjøre bedre sporvalg og klare seg bedre enn en uerfaren topptur-gåer. Statistikken viser derimot at jo mer erfaren du er, jo mer utsatt er du for å bli tatt av snøskred. Kan man basert på dette anta at jo mer erfaren du er, jo høyere er sannsynligheten for at du følger “kjente spor” i stedet for å se nye løsninger eller legge merke til endrede forutsetninger?
Det er nettopp her de nyutdannede rett fra skolebenken har sin styrke, og dette gjelder spesielt i IT-bransjen. Teknologi, rammeverk og språk endrer seg så raskt at innen du kan kalle deg erfaren, kan forutsetningene ha endret seg, eller det det kan ha kommet en ny løsning på problemstillingen. Derfor mener jeg at nyutdannede med ufargede sinn, er særlig relevante og stiller sterkt for å se de beste løsningene for våre kunder.
Innenfor frontend finnes det flere gode eksempler på hvor raskt teknologi og etterspurt kompetanse utvikler seg. Du rekker knapt å bli erfaren i et rammeverk før det har kommet et nytt og mer “moderne” på banen. Illustrasjonen nedenfor viser endring i popularitet for hvert frontend-rammeverk siden 2016. Dette gjenspeiler riktignok ikke etterspørsel i markedet, men det gir et interessant bilde av hvor raskt det skjer endringer i teknologi, som igjen påvirker etterspørselen av kompetanse.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*jqHJBEkG4TMpemwl"><figcaption>“THE STATE OF JS 2021: FRONT-END FRAMEWORKS AND LIBRARIES”. Alex Ivanovs. 19. februar, 2022</figcaption></figure><h4>Utvikler vs. konsulent</h4>
Våre nyutdannede konsulenter har i løpet av studietiden blitt eksperter innenfor sitt tekniske fagfelt. Dette har vi sikret gjennom grundige screeningprosesser og intervju. Felles for alle er at ingen har hatt “konsulentfaget” på skolen. Konsulent og utvikler er i mine øyne to veldig forskjellige roller. Vi konsulenter går hele tiden på line. Oppgaven vår er å balansere mellom å utfordre kundene våre, og samtidig se at løsningen vi oppfatter som perfekt, nødvendigvis ikke er den som skaper høyest verdi. Det er nettopp her det er så utrolig viktig at vi bruker kompetansen vår til å hjelpe kundene våre i å gjøre gode vurderinger.
Det finnes ingen fasit på hva som definerer en god konsulent. Du har muligheten til å lage din egen definisjon basert på din personlighet, erfaring og kompetanse. En god konsulent er uavhengig av personlighetstrekk. Forskjellen finner vi i hvordan du lærer å bruke disse trekkene sammen med din kompetanse til å spille deg selv og våre kunder gode. Det betyr at jo større mangfold vi har, jo større arsenal tilegner vi oss av fremgangsmåter for å hjelpe kundene våre. Dette er etter min mening, det som virkelig gjør jobben vår til en av de mest givende, utviklende og utfordrende jobbene innenfor IT. Så hvordan utgjøre denne forskjellen som konsulent, uten erfaring? Jo, Camp Dfind.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*chojcC4cbVf1Pd8lIz18lA.jpeg"><figcaption>Det ble luftig på Camp Dfind 2022</figcaption></figure><h4>Camp Dfind</h4>
Vi kan ikke påstå at vi er de eneste i bransjen som har en onboarding-uke for nyutdannede konsulenter. Derimot tør vi påstå at vi har bransjens kanskje mest unike omboardinguke. Konseptet bak Camp Dfind er å trene opp våre egne, av våre egne. De nyutdannede får under trygge forhold bryne seg på typiske fallgruver man som konsulent opplever, og kjenne på presset som kan oppleves ute hos kunde. Samtidig blir de kjent med sine nye kollegaer og ledere på en utflukt ute av byen. Hensikten med Camp Dfind er å gi konsulentene en verktøykasse de kan ta med seg ut til sitt første prosjekt. Dette gjør at våre nyutdannede kollegaer kan senke skuldrene når første kunde står for tur. De vil føle seg tryggere, skape mer verdi og på den måten føle seg mer verdsatt, som til syvende og sist fører til høyere trivsel.
Teknologi og språk er selvsagt også en viktig del av Camp Dfind. Vi har fokus på at konsulentene får tatt i bruk nye spennende språk og rammeverk som de kanskje ikke har vært borti før. Dette gjenspeiler også noen av utfordringene når man går fra skolebenken til konsulent hos en ny kunde. Evnen til å tilegne seg kunnskap i ukjente språk, rammeverk, metodikker og teknologier raskt.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*QYQcyj9GCKA8Sli_xV6jPg.png"><figcaption>Deltakernes beskrivelse av Camp Dfind 2022</figcaption></figure>Camp Dfind er under kontinuerlig utvikling for å sikre våre nyutdannede den beste starten på sin karriere hos oss. Ser du for deg en fremtid som IT-konsulent og har lyst til å vite mer om Camp Dfind? Vi kan dessverre ikke røpe mer om konseptet, men håper du har lyst til å oppleve det med oss. Kanskje vi sees på Camp Dfind?
Referanser
The State of JS 2021: Front-end Frameworks and Libraries. 2022. Hentet fra <a href="https://stackdiary.com/front-end-frameworks/">https://stackdiary.com/front-end-frameworks/</a>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=5cde7e60910" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/fra-student-til-konsulent-l%C3%B8ft-blikket-f%C3%B8r-skredet-tar-deg-5cde7e60910">Fra student til konsulent — Løft blikket før skredet tar deg</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.

Fra student til konsulent — Løft blikket før skredet tar deg

<h3>JavaZone 2022 — Key takeaways</h3>
<h4>JavaZone er en av verdens største samfunnsdrevne konferanser og tar for seg ulike temaer innenfor teknologi, sikkerhet, UX og ledelse. Konferansen gikk over to dager med fullpakket program og mange interessante foredrag.</h4>
Skrevet av <a href="https://medium.com/@mathias.hartveit">Mathias Hartveit</a> og <a href="https://marius-ibsen.medium.com/">Marius Ibsen</a>
Som alle tidligere år ble JavaZone holdt i Oslo Spektrum. Konferansen hadde mer enn 3200 deltakere, over 100 foredrag og foredragsholdere.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*wSQSpqbrXGVXOyQuJoQMCQ.jpeg"><figcaption><a href="https://www.instagram.com/p/CiQCSulKngJ/?utm_source=ig_web_copy_link">https://www.instagram.com/p/CiQCSulKngJ/?utm_source=ig_web_copy_link</a></figcaption></figure>Vi har tatt med oss mange erfaringer fra årets JavaZone som vi syntes er viktig å belyse. Erfaringene og kompetansen vi har tatt med i år handler hovedsakelig om mennesker.
<h3>Utvikling handler om mennesker</h3>
Utviklere blir mer og mer tilknyttet flere deler av organisasjonen og tar valgene som tidligere ble tatt av personer uten innsikt eller kunnskap om faget. Dette kommer nok av at man forstår bedre hva utviklerrollen er og at den kan flettes inn med de andre fagdisiplinene i organisasjonen.
På JavaZone i år delte flere foredragsholdere om egne erfaringer som ikke nødvendigvis hadde hovedfokus på kode. Det handlet også om mennesker, forventninger til utviklere og at utvikling ikke alltid trenger å være så seriøst.
Hva betyr det å være en god utvikler? Christin Gorman fra Kodemaker mener at vi må oppdatere hvilke forventninger om hva programmering egentlig er; dette snakket hun om i foredraget<a href="https://2022.javazone.no/#/program/a28cd1fa-9696-4a1f-97b0-ce1c0bbad6dc"> What makes a good developer?</a>. Det som forventes av en utvikler i dag er gode mattekunnskaper og å kunne skrive algoritmer. Programmering som fag blir ofte fremstilt som en idyllisk verden hvor det ikke oppstår problemer eller utfordringer men dette stemmer ikke overens med virkeligheten. Utviklere opplever utfordringer i hverdagen slik som i andre jobber, vi løser bare ulike utfordringer og har andre behov.
Forventningene som stilles i dag er nesten irrelevant og langt ifra hva en utvikler faktisk jobber med. Utviklere flest bruker svært lite matematikk i det daglige, og de færreste av oss skriver en algoritme. Det er hverken nødvendig med gode mattekunnskaper eller å kunne skrive algoritmer for å være en god utvikler. Christin mener vi bør fokusere på andre egenskaper som er mer nødvendige og relevante for det arbeidet vi driver med. Hvordan man jobber med mennesker og forstå problemene vi må løse for menneskelige behov er av viktigere art; en utvikler programmerer hovedsakelig løsninger for å løse menneskelige utfordring. Christin nevner tre egenskaper man bør se etter når man skal rekruttere nye talenter:
<ul>
<li>De viktigste egenskapene en utvikler må ha er tålmodighet og utholdenhet.</li>
<li>Jo mer vi kan av det grunnleggende desto bedre valg kan vi ta i fremtiden.</li>
<li>Vi trenger mer menneskelig interesse. Vi må bry oss om menneske vi lager løsninger for, og vi må forstå utfordringene brukerne våre opplever.</li>
</ul>
Stian Veum Møllersen fra NRK tok oss med på en <a href="https://2022.javazone.no/#/program/8c383c4d-e6ab-44f0-a5a2-ae0782d20e9f">røverhistorie om Popcorn og klokker</a>. For noen år siden startet han et moro-prosjekt for å gjenskape låten Popcorn, en meme-låt fra 1969. Prosjektet gjorde at man måtte løse ulike problemstillinger og finne riktige datastrukturer for å håndtere tid og lyd synkront i nettleseren. Utfordringene han måtte løse gjorde at han fikk innsikt i flere av nettleserens verktøy, som blant annet setInterval, setTimeout, requestAnimationFrame og WebAudio-klokka. En annen foredragsholder, Vegard Veiset fra Bekk, viste frem sin hjemmesnekra spillmotor laget i Kotlin. Spillmotoren hadde han laget fordi han ville forstå hvordan en spillmotor fungerer, ikke for å faktisk lage spill. Prosjektet hadde han jobbet med i over fire år på hobbybasis.
Både Stian og Vegard lagde noe med interesse for å løse andre problemer enn det de vanligvis støttet på. De trengte ingen spesiell grunn eller mening de ville bare gjøre noe gøy for å lære seg ny kunnskap. Det vi lager trenger ikke være seriøst eller nyttig, ei heller profesjonelt for å være lærerikt. Det viktigste er at man får noe ut av det man lager
Nina Bakken, designer i NAV, hold innlegget <a href="https://2022.javazone.no/#/program/77ba7dac-424f-401f-ac34-2539aeba2807">Fart, flyt og hyppige leveranser = bedre brukeropplevelse</a> hvor hun delte erfaringer om det å lære et team å arbeide sammen i smidige prosesser. Essensen av smidig utvikling handler om å gjøre små ting, ofte. Ved å gjøre dette, vil man redusere risiko ved store lanseringer. Smidig utvikling handler også om kontinuitet, og at man jobber med små porsjoner som kan lanseres hele tiden. En typisk designmetodikk går gjennom flere steg — ide, konsept, testing og utvikling. Utviklere jobber gjerne etter en kortere prosess hvor de “slipper unna” de stegene som ikke har med utvikling å gjøre og feil fikses ofte umiddelbart. Hvis man får alle de ulike fagdisiplinene til å arbeide sammen som et team, så er det ikke noe i veien for at alle de tverrfalige rettningene kan jobbe slik utviklere gjør. Det bør ikke være separate faser men noe som skjer kontinuerlig. Innsikt, konsept, testing, utvikling og videreutvikling er noe man alltid må gjøre uansett.
Inkludering av de tverrfaglige fagrettningene i hverandres prosesser vil etter hennes mening gi økt fart, flyt og hyppigere leveranser. Åpenhet om kode og design vil skape mindre usikkerhet i teamet. Det er viktig å kunne vise frem og snakke om uferdig arbeid for å unngå tap av innsikt og læring. Hun trekker frem noen tilnærminger som har fungert bra for deres team, blant annet parprogrammering, par-design og datadreven utvikling.
Samlingen av disse foredragene og tilnærmingsmåtene danner et bilde av en norsk industri i vekst hvor fokuset på den tekniske og den organisatoriske og menneskelige siden av utvikling blir mer sammenflettet.
<h3>Fremtiden er Sosio-Teknisk</h3>
Norske bedrifter og organer har over lengre tid hatt fokus på en digitaliseringsprosess av deres tjenester og produkter. Denne prosessen ser ut til å ha ført de fleste opp mot en felles problemstilling. Hvordan skaper man og vedlikeholder IT-baserte team, programvare og prosesser som er bærekraftige, langsiktige og stabile for medlemmer, produktet og brukere?
Dersom man spør 10 bedrifter får man nok 10 forskjellige svar, og derfor er det veldig givende at mange av Norges IT-kjemper deltar på JavaZone for å dele sine erfaringer og anmodninger om hvordan nettopp de oppnår sine mål — uten å slite ut både teknologien og menneskene involvert.
Vipps utforsker sine utfordringer, opplevelser og erfaringer i foredraget <a href="https://2022.javazone.no/#/program/5a831bdc-03be-4142-9e47-ec24dd95713c">Hva er digital produktutvikling? En historie fra Vipps.</a> Moquan Chen og Marit Andreassen understreker viktigheten av å danne tverrfaglige og myndiggjorte team. Et myndiggjort team dannes når medlemmene har autonomi til å ta de valgene fagpersonene mener er best for å oppnå målet definert av ledelsen. For mye styring ovenfra fører til mikrostyring, noe som ofte fører til teknisk dårligere produkter og mindre eierskap for selve laget som utfører oppgavene. Man ønsker å teste teorier og hypoteser så tidlig som mulig i prosessen frem mot et produkt for å luke ut hvilke muligheter teamene har fremover.
<a href="https://2022.javazone.no/#/program/85187a21-c215-43f8-90e8-88989b7a945d">Einar W. Høst fra NAV</a> mener at moderne utviklere og it-systemer er “sosio-tekniske” fenomener. Organisasjonens krefter påvirker utviklingen av programvare, som igjen påvirker arbeidsmåten til organisasjonen. Utviklere som ønsker å påvirke organisasjonen må være mer enn bare teknisk dyktige, de må også være sosialt dyktige. I foredraget tar Einar oss gjennom de personlige utfordringene som kan oppstå individuelt og internt i team som blir mer og mer myndiggjort i dagens landskap.
Det eneste som ser ut til å være sikkert i tverrfaglige, teknologiske og myndiggjorte team er at landskapet rundt endrer seg kjapt, og det endrer seg ofte. Dette gjelder både teknisk med tanke på teknologiske utfordringer og muligheter som åpner for nye løsninger, men også samfunnsmessige endringer. Lover og regler, fokus på nye brukergrupper eller endringer i brukernes daglige behov kan slå inn på hva fremtiden til teamet skal se ut som. Desto viktigere er det at teknologene er fokusert på å bygge bærekraftige løsninger. Med bærekraftige løsninger menes det tekniske løsninger som tåler endring og vedlikehold over lang tid, med skiftende fokus og landskap.
<a href="https://2022.javazone.no/#/program/b0d4acb2-2255-48db-acf0-f1268017b49e">Kristofer Giltvedt Selbekk</a> deler sine erfaringer fra 10 år med design systemer og frontend komponentbibliotek for å belyse hvordan man designer React komponenter med fokus på den fremtidige utvikleren. <a href="https://2022.javazone.no/#/program/8a2fd154-b7d0-466c-99b4-ffce79cc6e2f">Vegard Haugstvedt</a> forteller om NAVs pågående arbeid med å digitalisere alle sine søknader. Til nå estimerer de at de har digitalisert om lag 300 søknader på 3 år! Teamet må underveis ta hensyn til flere lag med brukere, samt endringer i lover og regler, endringer i nav-kunders behov og ikke minst ønsker om å kunne bruke tjenesten utenfor den digitale sfæren.
Som deltaker på JavaZone 2022 har det vært svært givende å delta i diskusjonene og erfaringene som deles av mange av Norges fremste teknologiske bedrifter. Dette er utfordringer som er universelle for alle team i alle sektorer, og byr på et spennende blikk inn i fremtiden for mange “sosio-teknologer”.
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=b344a33962f9" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/javazone-2022-key-takeaways-b344a33962f9">JavaZone 2022 — Key takeaways</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.

JavaZone 2022 — Key takeaways

<h3>Agile 2 — Agile har blitt oppgradert?</h3>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*QczHI4JoE5yrlGfjIyTqdQ.png"></figure>Nylig leste jeg en bok som heter <a href="https://agile2.net/">Agile 2 — The next iteration of Agile</a> og la meg starte med å si at det er ikke en oppgradering, men en gjennomtenkt nytenkning av det opprinnelige Agile manifestet. Men først en liten tur ned memory lane.
I februar 2001, hadde 17 meget dyktige mennesker samlet seg på et hotell i Utah. Her ble det gjort et stykke arbeid, som endret arbeidshverdagen for mange mennesker til det bedre og enklere. Det var på det hotellet i Utah det Agile manifestet så sitt dagslys.
Det Agile manifestet er et bygd opp på <a href="https://agilemanifesto.org/iso/no/manifesto.html">fire verdier</a> og <a href="https://agilemanifesto.org/iso/no/principles.html">tolv prinsipper</a> for hvordan man bør jobbe med agil programvareutvikling.
<ol>
<li>Personer og samspill fremfor prosesser og verktøy</li>
<li>Programvare som virker fremfor omfattende dokumentasjon</li>
<li>Samarbeid med kunden fremfor kontraktsforhandlinger</li>
<li>Å reagere på endringer fremfor å følge en plan</li>
</ol>
De som laget verdiene over, er også tydelige på at verdiene både på venstre og høyre side er viktige, men at verdiene på venstre side av “fremfor” bør verdsettes høyere.
Nå tenker du kanskje, dette høres fornuftig og logisk ut, og jeg er helt enig. Det er nok også en veldig stor grunn til at agil programvareutvikling har blitt såpass utbredt som det er i dag. Men, det har skjedd mye innenfor agil programvareutvikling på de 20+ årene som har gått siden de så dagslys. Det er det boken Agile 2 — The next iteration of Agile tar for seg. Boken er skrevet av <a href="https://agile2.net/about/">15 personer</a>, med omfattende erfaring innen agil programvareutvikling fra hele verdenen.
Forfatterne av Agile 2 er veldig tydelige på at de ikke har laget et rammeverk for prosess, for som de selv påpeker i boken, er at det er ikke noen prosess i det agile.
I boken tar de for seg det som er positivt med det Agile manifestet. Og at intensjonen med Agile 2 er ikke å erstatte Agile, men å foredle og utvide. Men også på noen områder å justere noen av de opprinnelige ideene som kanskje nå i etterpåklokskap, har vær litt for enkle, ekstreme eller at de passer til alle typer problemstillinger.
Apropos det enkle, så mener forfatterne av Agile 2 at det Agile manifestet forenklet en del ting og ikke tok hensyn til ledelsesteori, atferdspsykologi og kognitiv kunnskap.
Som et eksempel så tar boken for seg hvordan man i det agile fokuserer på team i veldig stor grad. Her mener forfatterne at man har gått litt for enkelt til verks, og at hvert enkelt individ i et team har blitt glemt litt oppi det hele. I boken bryter de ned til et så banalt eksempel som det daglige rituale mange agile team kjører, bedre kjent som stand-up. Se for deg et gitt eksempel med at du jobber som utvikler og teamet ditt har en daglig stand-up kl 08:45. Du kommer kanskje på jobb rundt kl 08:00 og du vet hva du skal jobbe med å løse denne dagen. Og her kommer allerede et viktig poeng i boken, og det er at å skrive kode er ikke noe man bare gjør på stående fot, men at det til tider kan være et ganske krevende tankearbeid. Så når du da har satt deg ned på plassen din og du vet at det er i underkant av 45 minutter til stand-up, så er det kanskje ikke hensiktsmessig å starte på dette tankearbeidet, for du vil bli avbrutt når du skal på stand-up. I stedet henter du deg kanskje noe å drikke, samt at du muligens snakker litt med en kollega om noe. Deretter kommer du til stand-up, hvor alle på tur går igjennom hva de har jobbet med dagen før, hva de skal jobbe med i dag og evt om de har noen problemer.
Her kommer Agile 2-boken inn på enda et viktig poeng som kanskje har blitt neglisjert litt i oppi iveren etter det agile. Hvor mye verdi/interessant er egentlig denne informasjonen for de andre i teamet? Hvor viktig er det å vite hva kollegaen din har jobbet med dagen før eller skal jobbe med om det faktisk ikke påvirker deg eller ditt arbeid? Kanskje det kan løses på andre måter, hvor man likevel får delt nødvendig informasjon med teamet, uten at man trenger å kjøre tradisjonell stand-up?
Men nå tenker du kanskje, ja men da har man jo god tid etter stand-up til å jobbe? Igjen, så kommer har forfatterne av boken et godt poeng og jeg tror de av oss som har jobbet noen år vil kjenne seg igjen i dette. Som oftest er ikke dagen møtefri etter stand-up, men består gjerne av både planlagte og uforutsette møter som bryter opp dagen i mange biter. Så når skal man egentlig komme seg i en flytsone og få tid til tankearbeidet? Dette og mye annet ønsker Agile 2 boken å belyse, men den kommer også med forslag til hvordan kan løse de ulike problemstillingene på en god måte.
Dersom du har lest ned helt hit, så kanskje du har blitt litt nysgjerrig på boken selv? Jeg vil absolutt anbefale deg å lese boken, den er et friskt pust til det agile. Selv satt jeg igjen med en god del nyttige aha-opplevelse og nyttige refleksjoner for hvordan jeg selv har arbeidet med agile.
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=98a407be3070" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/agile-2-agile-har-blitt-oppgradert-98a407be3070">Agile 2 — Agile har blitt oppgradert?</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.

Agile 2 — Agile har blitt oppgradert?

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*NcYlXOfb8Wdwa_jP"><figcaption>Photo by <a href="https://unsplash.com/@zacdurant?utm_source=medium&amp;utm_medium=referral">Zac Durant</a> on <a href="https://unsplash.com/?utm_source=medium&amp;utm_medium=referral">Unsplash</a></figcaption></figure>Sometimes I see developers define variable names such asisNotSelected, hasNoData and shouldNotInclude. I avoid writing variable names like this as much as possible. Declaring variables like so focuses on the negative outcome. Variables written in a non-active, negative or reversed way give a feeling that the returned value is something we don’t want or that is not positive and good. Instead, writing code that focuses on something active, positive, or forwarding will make the code-reading experience more efficient and less frustrating.
<h3>Variable naming: positive vs negative</h3>
We force our brains to think reversely when naming variables based on the negative outcome. Doing so is more strenuous than thinking in an active or forward way.
The code we are producing should be easy to read and make sense. Naming our variables on the positive outcome is better for a developer’s reading experience because it feels active and valuable. If we eventually want the opposite outcome, the non-active or negative, we invert it when necessary. In my opinion, It’s easier to think that something is active and inactive instead of in-active and not in-active. Let’s make a comparison:
Negative named variable:
<pre>const isNotActive = true isNotActive // true</pre>
Positive named variable:
<pre>const isActive = false isActive // false</pre>
<h3>Inverting</h3>
The exclamation mark (!) is almost ubiquitous in programming languages and is a suitable replacement for words like no, not and doesn’t. For instance, we can turn a boolean state to the opposite by using an exclamation mark.
Use exclamation marks to turn positive to negativ (or the other way). In When we see an exclamation mark on a variable that is initially based on something active or a positive outcome, developers generally know that the condition will turn to the opposite value. In the code example below, we could prepend exclamation marks to isNotActive and isActive. Still, the isActive variable would be easier to read for the common eye because it has an active state in the first place. On the other hand, when we initially base our variable name on the negative outcome, the results are not quite so clearly.
Negative named variables:
<pre>const isNotActive = true const hasNoData = true if(isNotActive &amp;&amp; hasNoData) { // not active } if(!isNotActive &amp;&amp; !hasNoData) { // active }</pre>
Positive named variables:
<pre>const isActive = false const hasData = false if(!isActive &amp;&amp; !hasData) { // not active } if(isActive &amp;&amp; hasData) { // active }</pre>
Working with arrays could be another example. Let’s say we have an array of vegetables and want to be sure that it does not contain carrots. We could make a couple of variables named doesNotContainsCarrots or containsCarrots and wrote the code like so:
Negative named variable:
<pre>const vegetables = ['potato', 'salad'] const doesNotContainsCarrots = vegetables.some(v =&gt; v !== 'carrot') if(doesNotContainsCarrots) { // does not contain carrots, no chopping } if(!doesNotContainsCarrots) { // contains carrots, chop chop }</pre>
Positive named variable:
<pre>const vegetables = ['potato', 'salad'] const containsCarrots = vegetables.some(v =&gt; v === 'carrot') if(!containsCarrots) { // does not contain carrots, no chopping } if(containsCarrots) { // contains carrots, chop chop }</pre>
Like previous examples, it’s easier to read and think that something exists and invert it if we want the opposite outcome (positive to negative).
<h4>Consistency Throughout the codebase</h4>
We write code that should function, exists and work. Refactoring will become easier if the naming of variables follows a specific format. How we name variables, functions, enums or types in our code should be consistent throughout the codebase to avoid confusion. Naming things both positively and negatively in the same file or within the same scope should also be avoided. If that is the case, we should choose to go for either the positive or negative naming style since mixing is confusing. But in the end, I guess you will choose to go with positive and active naming simply because it feels more natural.
<h3>Summarize</h3>
Writing code that focuses on the active state and should return a positive outcome in our variable increases readability. By doing so, we don’t have to think in reverse. The state would be easier to revert since you always turn something active to not active, and lastly, we will focus more on what we need in our code instead of what we don’t need. Finally, our code would be easier to keep consistent because we follow a specific format for naming variables (and functions, types, etc.) Code must be easy to read, and we should write variable names with that in mind.
Code foh shizzle
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=b42328d51e9c" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/about-writing-positive-and-negative-variable-names-b42328d51e9c">About Writing Positive and Negative Variable Names</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.

About Writing Positive and Negative Variable Names

Som teamleder må du legge til rette for godt samarbeid i teamet ditt. En måte å samarbeide på, eller å komme i gang med samarbeid på, er å ha workshops (/arbeidsmøter).
Det som er fint med workshops er at det krever involvering fra de som deltar. Å ha en workshop uten at alle er med, er kun et vanlig møte. Når vi gjør noe, lærer vi bedre. Benjamin Franklin sa “Tell me and I forget, teach me and I remember, involve me and I learn”. Og som gruppe kan vi få til mer enn når vi er alene, spesielt om vi er tverrfaglige.
Jeg skal kort gjennomgå noen tips til hvordan arrangere morsomme og interessante workshops.
Tillit
For å få folk til å komme med de beste idéene, er det viktig med tillit. En måte å skape tillit på er å starte workshopen med en «Ice breaker», — en uhøytidelig øvelse før man begynner. I Dfind Consulting brukte jeg nylig «ett ord i gangen»-øvelsen, hvor hver deltaker sier ett ord hver, i tur og orden, og til slutt blir ordene til en setning. Det skapte latter og det fikk folk til å slappe av. Resultatet ble, til min store overraskelse, fornuftig: «Inspirerende samarbeid er kult og alle bør være sammen om hverandres idé». 12 personer blir til 12 ord i en setning.
En annen viktig sak er å få etablert regler om hvordan vi skal være mot hverandre, såkalt etikette. I mindre sammensveisede miljøer er det lurt å tenke på regler som beskytter mot at noen blir krenket, for eksempel kan en generell regel være «Vi behandler kollegaer, kunder og ledere likt». En slik regel skal bidra til å fremme likebehandling og redusere konflikter.
Regler som inkluderer mangfold og inkluderingstankegang kan være:
<ol>
<li>Snakk fra din egen erfaring i stedet for å generalisere.</li>
<li>Unngå å ugyldiggjøre en annens historie med din vurdering av deres innspill.</li>
<li>Målet er ikke å alltid være enig, målet er å få en bedre forståelse.</li>
<li>Vær bevisst på kroppsspråket ditt og ikke-verbal respons.</li>
</ol>
I tillegg bør man ha vanlige regler som at «hvert innspill er et godt innspill» og «store og sprø idéer er velkommen», slik at folk ikke blir redde for å si det de tenker.
For å være sikker på at alle får sagt det man mener, må man dele inn i mindre grupper, gjerne helt ned i 3 per gruppe. Gruppene bør ha en avtale på at alle skal si noe, og i den sammenheng kan man for eksempel bruke en penn. Den som har penna snakker, og penna går på rundgang. I virtuelle «breakout» rom, må man ha en talestyrer som passer på at alle sier noe.
<figure><img alt="Morsomt med “Ice breaker”" src="https://cdn-images-1.medium.com/max/1024/0*oZkoNbaZjlhyFnM7"></figure>Forandring fryder
Det er mange forskjellige teknikker å bruke når man skal kjøre en workshop. Min erfaring er at forandring fryder. Hvis teamet ditt er vant med at alt foregår på skjerm, er det fint å variere med en workshop der man bruker fysiske ting som en vanlig tavle eller en «white board». Og motsatt, er man vant med å bruke whiteboard og papir, bruk Miro på PC.
<figure><img alt="Flytt ut av PC’en til tavla." src="https://cdn-images-1.medium.com/max/1024/0*gKOit8M1K1MgnvLd"></figure>Nylig flytta jeg jira-tavla over på en fysisk tavle med én oppgave per post-it, som vi oppdaterte hver dag i en uke. Målet var å få flest mulig lapper over til høyre side (til status «Ferdig»). Dette hjalp på motivasjonen i teamet. Mange av de involverte likte å flytte lapper fysisk. Det krever selvsagt en del manuell oppdatering av fasilitator/meg å holde Jira-tavla og den fysiske tavla i synk, men det er også en glimrende mulighet for fasilitator/meg å se det man holder på med i et nytt perspektiv.
Typer workshops
Ellers er det haugevis med tips på nett til forskjellige workshop-teknikker. Men jeg anbefaler:
<ul>
<li>Bryt opp og gjør noe annet, som for eksempel: flytt Jira-oppgaver (eller oppgaver i et digitalt verktøy) over på post-its og oppdatér tavla fysisk.</li>
<li>
<a href="https://cynefin.io/wiki/Future_backwards">«Future backwards»</a>, for å legge en strategi framover eller lage en plan. Ha god tid.</li>
<li>
<a href="https://theworldcafe.com/">«The world café»</a> for å få gode samtaler og produsert noe konkret, for eksempel lage et utkast til en ny applikasjon med bruk av papir og teip etc.</li>
</ul>
<figure><img alt="Det er avslappet stemning på kafé." src="https://cdn-images-1.medium.com/max/1024/0*oDPEiGpUUh-LJTmJ"></figure><ul>
<li>
<a href="https://www.qualitativemind.com/projective-techniques/">Projisering</a>: Finn et bilde som for eksempel representerer hvilken opplevelse brukere skal ha av tjenesten vi skal utvikle og la gruppene diskutere og argumentere for hvorfor de har valgt seg det og det bildet. Kjernen i øvelsen er samtalene rundt bildene.</li>
<li>Og ikke minst, et forslag til virtuelle workshops: bruk «Tre små griser» som retrospektiv iblant. <a href="https://www.funretrospectives.com/three-little-pigs/">«Three little pigs»</a> er en morsom retrospektiv-metode som får frem litt andre poeng enn de vanlige typene retrospektiv: «Hus av strå», «Hus av pinner» og «Hus av mur» i stedet for «Hva var dårlig?», «Hva kan forbedres?» etc.</li>
</ul>
Det viktigste kommer likevel til slutt: etterarbeidet og tiltak. Det man kommer fram til i workshopen skal brukes videre. Tiltak skal gjennomføres av team-deltakerne og teamleder må sørge for det. Det er viktig at teamleder tar hovedansvaret og sørger for at tiltak blir gjennomført.
Oppsummering
Oppsummert blir dette:
<ul>
<li>Start med en «Ice-breaker»</li>
<li>Bestem regler for oppførsel</li>
<li>Del inn i grupper på 3 personer, også virtuelt i «break out rooms», og pass på at alle får sagt sin mening</li>
<li>Bruk en workshop-teknikk som er en variasjon i teamet sin hverdag</li>
<li>Teamleder sørger for at alle tiltak blir gjort</li>
</ul>
Om du har spørsmål eller tanker, kontakt meg på <a href="mailto:heidi.hundala@dfind.no">heidi.hundala@dfind.no</a>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=df389a9088f5" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/workshops-og-samarbeid-df389a9088f5">Workshops og samarbeid</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.

Workshops og samarbeid

Vi som jobber med UX har mye fokus på hvordan vi skal kommunisere for å nå brukerne på best mulig måte. Hvordan skal vi få sagt alt riktig? Hvordan skal vår kommunikasjonsstrategi være, og hvordan skal vi prioritere?
Vi voksne bruker så mange ord. Så store ord, og kanskje til og med litt vanskelige ord. Ord som viser hvor veltalende vi er. Vi glemmer kanskje at mottakeren burde kunne det samme for å forstå det vi prøver å si? For det er vel egentlig målet? At de som tar imot skal forstå?
Hva hadde vi gjort om vi bare kunne noen få ord? Om vi ikke kunne si eller skrive det vi ønsket å formidle?
I vår satt jeg i stua med sønnen min som lekte sykehus. Han kom med noe til både meg, og til pappaen sin. Det var et brettet ark med et plaster på. Han er fem år, og kunne ikke skrive annet enn sin egen forbokstav. Men jeg var aldri i tvil om hva det var jeg fikk i hendene. Det var helt selvsagt en innkalling til sykehuset hans.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*fJGApaHmlhworwdVl67UaQ.png"><figcaption>En femårings innkalling til sykehus</figcaption></figure>UX designeren i meg ble så imponert, stolt og nesten litt rørt over hans evne til å kommunisere hans mål på en så tydelig og enkel måte uten ord. Og dette satte virkelige tankene i spinn!
Ord for overlevelse I ettertid har jeg opplevd flere og flere øyeblikk som har endret måten å skrive på. Min toåring har også fått meg til å tenke. Hun lærer seg stadig nye ord, og det fascinerer meg hvilke ord hun lærer først. De første ordene som kommer er de ordene hun trenger mest for å overleve. “Mamma” og “pappa” for trygghet. “Tørst”, “mer”, “banan” for ikke å sulte. Og så skader det jo ikke med litt “bø” og “tittei” på veien for å skape sosiale relasjoner.
Hun bruker ordene som trengs mest for å dekke hennes behov på raskest mulig måte. Hun bruker ordene som vi selv bruker for å nå inn til oss, og ord som har gitt viktig respons når hun tidligere har brukt de. Når hun må tisse så roper hun “Tisse!”. Men hva gjør jeg da? Jo, jeg begynner med masse fuzz og spørsmål om hun har tissa i bleia frem til hun avbryter meg med å rope “Potte”! Tisse. Potte. Du får det ikke mer klart. Et behov, to enkle ord. Greit… jeg forstår!
Når hun fikk vannkopper ropte hun “Au”, og “mau”! Og siden vi er i samme stamme så vet jeg at mau betyr maur. Men jeg vet også at hun ikke kan ordet klø, men at å klø kan kjennes ut som å ha en maur krypene oppover.
Hvordan kan vi lære noe av måten barn snakker på? Nå er det sjeldent vi kan bruke kun to ord i vår kommunikasjon, og dette er jo slettes ikke verken barseltreff eller mammaforum. Så hvorfor tar jeg opp dette, og hvordan kan vi lære noe av nok en mamma som snakker om barna sine?
Jo, vi kan forenkle og forbedre måten vi skriver og kommuniserer på. Vi kan bruke enkle ord. Ord som sterkt dekker et behov, hvor det ikke er tvil. Ord som alle forstår, og ord som brukerne selv lærer oss. Vi kan bruke symboler som alle forstår, som har et klart budskap. Vi kan finne frem barnet i oss, gjøre det enkelt. Når ble vi så kompliserte? Hvor mange ganger har du ikke tenkt «årh.. hva er nå ordet for dette». Kanskje trenger du ikke det ordet… kanskje trenger du bare å beskrive hva du skulle finne et ord for. Kanskje er beskrivelsen av ordet lettere å forstå for alle andre også, og i tillegg vil en beskrivelse kunne åpne opp for enda mer følelser. Det er jo også ofte slik vi kommuniserer med andre som snakker et annet språk enn oss selv. Da bruker vi ordene vi begge forstår for å beskrive det vi egentlig mener.
Så kan vi kanskje ikke gå til en barnehage hver gang vi skal skrive for en målgruppe. Og det trenger vi heller ikke. Men vi kan gå til målgruppen. Vi kan lære deres språk, deres ord, deres stammespråk og deres tydeligste ord som dekker deres viktigste behov. Og vi kan bruke deres egne beskrivelser om ord og begrep.
Vi er inne i høysesong for dager hjemme med sykt barn. Nyt tiden med de små UX designerne, lytt, le og bli inspirert.
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=90e5450c9a43" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/snakk-som-et-barn-90e5450c9a43">Snakk som et barn?</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.

Snakk som et barn?

\nEuropean Women in Tech er Europas største tech-arrangement for kvinner, og tar for seg temaer innen teknologi, ledelse og karriereutvikling. Etter to år med pandemi var en gjeng på femten ansatte fra Dfind Consulting sultne på kompetanseutvikling og networking — og dette fikk vi. Etter to inspirerende konferansedager med flere av techbransjens mest innflytelsesrike kvinner har vi plukket ut tre takeaways vi nå ønsker å dele med fler.\nEuropean Women in Tech fant sted på det velkjente konferansesenteret RAI midt i Amsterdam. Konferansen gjestet over 250 speakers, hadde over 250 sesjoner og workshops, og over 4000 deltakere.\n<figure><img alt=\"\" src=\"https://cdn-images-1.medium.com/max/1024/1*x5OL_HU_PGVA2bEyGJV9xg.jpeg\"><figcaption>Dfind Consulting på European Women in Tech 2022</figcaption></figure>Den viktigste kompetansen vi tar med oss og ønsker å belyse:\n<h4>Rollemodeller</h4>\nEt av de mest fremmende tiltakene for å øke kvinneandelen i techbransjen er å eksponere unge jenter for rollemodeller som inspirerer og viser at det er mulig å få en spennende karriere innen teknologi.\nMicrosoft gjennomførte en studie med flere enn seks tusen kvinnelige deltakere i alderen ti til tretti år. Av studien fremkom det at interessen for STEM (science, technology, engineering, mathematics) nesten dobles når de har en rollemodell som inspirerer dem, hvor foreldre og lærere her ble trukket frem som aktuelle rollemodeller. Studien viste at sannsynligheten for at jenter vil studere datateknologi og informatikk øker med 81 % dersom en forelder oppmuntrer til en STEM-utdannelse, sammenlignet med en som ikke oppmuntres.\nI stor grad handler det om å i det hele tatt prate om og kommunisere STEM som et alternativ til valg av studieretning, og samtidig bryte tabuer om at jenter ikke mestrer realfag like godt som gutter. Studien viser at 91 % av unge jenter regner seg selv som kreative, og at hele 72 % ønsker arbeid som hjelper verden. Vi som jobber i bransjen vet jo hvor fantastisk store muligheter det er for kreativ utfoldelse og arbeid med samfunnsnyttige løsninger — dette må prates om! Vi må bidra til økt bevissthet og kunnskap rundt de faktiske mulighetene som finnes ved å jobbe i techbransjen. “If you cannot see it, you cannot be it”. For at foreldre og lærere skal kunne være gode rollemodeller, må også vi som arbeider i bransjen ta ansvar og være rollemodeller gjennom kompetansedeling og bevisstgjøring.\n<h4>Bias i kunstig intelligens (AI)</h4>\nBias i AI er et reelt problem med potensielle alvorlige konsekvenser. Algoritmer er ikke objektive, men virker ut fra det som defineres av den som lager algoritmen. Det er sannsynlig at vi mennesker tar med oss våre biaser inn i koden. Samtidig vil også datagrunnlaget som algoritmen lærer av og baserer sine resultater på, kunne ta med seg biaser. Dette er to viktige faktorer til at bias i AI forekommer i utgangspunktet.\n“One size doesn’t fit all”. Techbransjen må være en sann representasjon av mangfoldet som finnes i samfunnet, slik at mangfoldet også blir representert når ny teknologi utvikles. Konsekvensene av en teknologisk utvikling som ikke er representativ sees allerede, som ved talegjenkjenning som ikke gjenkjenner pronomenet “hers”, men gjenkjenner “his”. Eller ansiktsgjenkjennings-programvarer som ikke klarer å skille personer med mørk hud.\nVi har fortsatt en vei å gå innenfor teknologi for å unngå bias i AI. Mye av følgene som sees er skapt av manglende mangfold eller allerede samfunnsdefinerte forutantakelser. Ved å tilføre mer mangfold og ikke minst ta høyde for at bias i AI kan og vil oppstå er vi allerede et stykke på vei for å unngå konsekvensene det kan få.\nFor mer informasjon og flere tips til hvordan vi unngår bias i AI, les innlegget European Women in Tech har postet om tematikken: <a href=\"https://www.europeanwomenintech.com/blog/bias-in-ai\">https://www.europeanwomenintech.com/blog/bias-in-ai</a>\n<h4>“Claim your space!”</h4>\nEn siste og generell oppfordring vi tok med oss og mener er viktig å bringe videre, er å våge å ta plass og ta kontroll over egen karriere. Dette var en fellesnevner ved flere av foredragene, og samtlige av foredragsholderne delte sine historier om hvordan deres karriere skjøt fart eller endret kurs den dagen de tok et valg om å ta plass.\nSnakk høyt om egne ambisjoner, fremhev og vis hva du kan. Vit din verdi og be om det du fortjener, med en antagelse om at ingen kommer til å gi deg noe gratis. Det handler om å synliggjøre seg selv og vise hva du er god for. Hvordan skal ellers din leder eller mentor kunne støtte deg og påvirke din faglige og personlige utvikling for å nå dine karrieremål?\nDelta i og inkluder alle i diskusjonen. Prat med de med andre synspunkter enn deg selv, også de personene du vet du får en utfordrende samtale med, eller den som vanligvis ikke inkluderes i diskusjonen. Med en oppriktig nysgjerrighet overfor alle perspektiver utvikler du deg. Å skape nettverk som både inkluderer de som kan støtte, rådgi og utfordre deg kan åpne fantastiske utviklings- og karrieremuligheter. Ved å tørre å ta denne plassen, fremme egne meninger og kompetanse samtidig som andre også inkluderes, skapes perspektivbevegelighet og synergier. Det skaper en arena for å selv kunne utvikle seg og motta andres respons.\nMed det håper vi å ha inspirert flere kvinner og menn der ute til å være gode rollemodeller og utfordre seg selv til å ta litt større plass. Vi mener at European Women in Tech-konferansen er like relevant for menn som kvinner, og oppfordrer alle menn til å engasjere seg på tilsvarende arrangementer, selv om det inkluderer “women” eller “kvinner” i tittelen. Som vi nå har presisert — hvordan skal kompetansedeling og endring skje om ikke alle inkluderes i diskusjonen og kunnskapsdelingen? Vi i Dfind Consulting fortsetter i hvertfall vårt arbeid med å dele kompetanse, og håper vi har bidratt til å belyse viktigheten av mangfold i techbransjen.\n<img src=\"https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=d3cc717610e8\" width=\"1\" height=\"1\" alt=\"\"><hr>\n<a href=\"https://medium.com/dfind-consulting/european-women-in-tech-2022-tre-takeaways-d3cc717610e8\">European Women in Tech 2022 - Tre takeaways</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.\n

European Women in Tech 2022 - Tre takeaways

\n<figure><img alt=\"\" src=\"https://cdn-images-1.medium.com/max/1024/1*BF2vA6dM2PHRFyaMoWq8kQ.jpeg\"></figure>Some years ago, I was working as a facilitator or coach, if you like, for a team of product owner. It was a complex organisation and the product we were working on had many stakeholders from different parts of the organisation. All with different needs and priorities. It is often difficult to do propper, customer centric product development in this situations as it often end up in a discussion about who should get their way and the features they want.\nThe challenge:\n<ul>\n<li>\nDifferent needs and priority between stakeholders</li>\n<li>Great business understanding, but not much experience with analysing insight and breaking it down into product requirements\n</li>\n<li>\nHigh expectations from the rest of the organisation towards what the stakeholders will “deliver” for their team or department</li>\n<li>\nDifficult to move forward as a PO as the same discussions are being repeated</li>\n</ul>\nAll of this resulted in us not being able to move forward and no-one getting what they wanted. We came up with a workshop concept to takle this challenges and be able to continue with everyone more or less on board\nWhere can this workshop be helpful?\n<ul>\n<li>A lot of stakeholders with different needs and opinions</li>\n<li>Different seniority between stakeholders</li>\n<li>Stakeholders not focusing on problems and insight and more on gut feeling</li>\n<li>Stakeholders with a strong opinion on solution, but not necessarily the solution to the problem</li>\n<li>You find yourself as a proxy PO without mandate</li>\n</ul>\n<h3>The works</h3>\nFor a group of about 12 ppl, you probably need two days to allow for discussion. The agenda will look something like this\n<ul>\n<li>\nHomework — Participants need to prepare an “opportunity statement/description” . You will have to send this out a bit in advance.</li>\n<li>\nOpportunity workshop — Work with the opportunities provided by participants and stakeholders</li>\n<li>\nIdeation workshop based on opportunities</li>\n<li>\nDetailing — Work with selected ideas and start to detail in groups</li>\n<li>\nAfterwork — Still a lot of work to do, but you hopefully have direction and priority</li>\n</ul>\nTo run a smooth workshop, you might also want to add a bit of motivation and warmup before you kick off the opportunity part. Personally I have had good results talking about the overall product development process and product lifecycle and I can also recommend running a short brainstorming about expectations from all participants.\n<h4>Homework</h4>\nI find it very helpful to give the participants some homework. It helps to get the right focus going into the workshop and also to control the scope a bit. The workshop itself can also be done in shorter time.\nWe ask all participants to fill in as many “Opportunity statements” as possible. You will probably get one or two from each. The name “opportunity” is chosen because it’s not related to the solution at all. We don’t commit to anything, but it’s rather a positive upside we can address. The solution will come later to address the opportunity.\n<a href=\"https://docs.google.com/document/d/1N0ZMTle1tBLGzdnsslAJTIbnR8PtRdf_TwwnmtNvZa8/edit?usp=sharing\">Download the template</a>\nThe template also encourage the writer to think about insight and reasons for why this opportunity is valid. E.g “X% of our user base spend on average 30 minutes for each task. By making this easier, we can save them 8 hours of work each day”. “This and that competitor have this feature and X% of the market. We also got this feature, but our customers doesn’t use it”\n<h4>Opportunity statement template</h4>\nTitle and description — Describe the opportunity. Be as detailed as possible. Remember that the one reading this don’t know what you know.\n<ul>\n<li>What is occurring? What is the observations made and what is the insight from this?</li>\n<li>The objective. What are we going to accomplish?</li>\n<li>Who does it affect and where are they affected?</li>\n</ul>\nBackground - Use this section to document your findings and insight\nWho is involved - We need to involve them in the verification stage later.\n<ul>\n<li>Who is involved at your company?</li>\n<li>What customer/customer segments are affected?</li>\n</ul>\nImpact - How big is this opportunity or the problem behind the opportunity?\n<ul>\n<li>How big market size will it affect?</li>\n<li>How many customers are affected?</li>\n</ul>\nRisk — Challenge your own observations and the opportunity you see\n<ul>\n<li>Have you made any assumptions?</li>\n<li>Why could you might be wrong about the opportunity?</li>\n</ul>\n<h4>Opportunity workshop</h4>\nThe day is finally here. It’s workshop time.\nOur main purpose for this section is for everyone to get an understanding of the different opportunities from all stakeholders and a priority for what to cover in the next sections\nAgenda\n<ol>\n<li>Make sure you have printed out the opportunities before start</li>\n<li>The opportunity owner presents the opportunity in front of everyone</li>\n<li>Feedback, questions and discussion</li>\n<li>Repeat 2–3 until your are done or spent the time you have timeboxed</li>\n<li>Grouping of similar opportunities. This step is important as you hopefully start seeing synergy across the organisation. Things that might have been lost because everyone have been so busy focusing on their own problems.</li>\n<li>Prioritization vote — Use red dots. Give each participant 3 dots each, they can place all on one opportunity (group) or spread the votes between different ones.</li>\n<li>You now have a prioritised list of the biggest opportunities for your company</li>\n</ol>\n<h4>Rephrase</h4>\nI didn’t mention this earlier, but you actually have some more work to do. Before starting the ideation part of the workshop, you need to rephrase the opportunity as a challenge. By doing this you frame it as a question it is easier to answer and and you will get more precise suggestions.\n<figure><img alt=\"\" src=\"https://cdn-images-1.medium.com/max/1024/1*liMtxIzzGp0UtP3pD696Mw.png\"><figcaption>Rephrase the opportunity into a challenge before going into ideation</figcaption></figure>Example\nSay that you have a Saas solution. Your opportunity could be something like: “70% of revenue comes from customers upgrading their licenses. By improving the software license upgrading process, we should be able to see 15% increase and reduce churn by X%. Customer feedback indicate that they don’t know what licence model they should use and they find it hard to find the upgrade section in the Saas dashboard”\nRephrasing: “How might we improve the licence upgrade process by making it more understandable and easier to find”\nDo this with every opportunity or grouped opportunity. Write it out on a piece of paper and mention what opportunity it addresses as bullet points on the same paper.\n<h4>Ideation workshop part 1 — Brainstorming</h4>\nBack to workshopping!\nIdeation come in many forms. Some will probably think that this approach is too rigid and doesn’t foster creativity. You are probably right as the purpose of the following activities is to gather as much input as possible from stakeholders. PO and product designers still need to spend time iterating to further improve the suggested solutions.\nFirst we want to do an activity with all participants. We do this because we need buy-in and consensus about the priority going into detailing. We also get to hear everyones voice about all issues before continuing in groups.\nAgenda\n<ol>\n<li>Kick everything off with a walkthrough of the opportunities and the rephrased version. Place them on the wall in prioritised order.</li>\n<li>Start with the first on. Brainstorm individually for 5 minutes. “What ca we do to address this opportunity”. It should be very high level as we will go into details later. If we go back to the SaaS licensing case it could be “Create a tutorial video explaining the licensing modell” or “Redesign the licensing tier packages”</li>\n<li>Everyone presents their suggestion one by one</li>\n<li>Group similar suggestions together.</li>\n<li>Prioritization vote — Use red dots. Give each participant 2 dots each. They can place all on one suggestion or spread the votes between different ones.</li>\n<li>Repeat step 2–5 until you have 1–3 top ideas for each opportunity. Don’t do too many opportunities as you will get too much ideas to detail. Its better to run the workshop more often than to cover too much during each workshop</li>\n</ol>\n<h4>Ideation workshop part 2— Detailing</h4>\nThis next and last part of the workshop is detailing, and it is done in groups. I suggest to split into groups of three. PO or product designer and maybe a tech-lead or architect can move between groups and help out if needed\nThe output of this section should be different concept drafts we can further develop and verify.\nA concept draft in this case is a piece of A3 paper split into 4 sections\nDescription: Describe the concept/solution. For our SaaS example it could be: “Redesign the license upgrade page so the user sees what licence they are currently on and how many free seats they have. All levels should be shown and the diff in cost and functionality should be clearly stated. We should also give a small discount if the user pay annually and not monthly to nudge them into making a bigger commitment”\nDrawings and wireframes: A picture say more than a thousand words. It’s always easier to communicate your thinking with some visuals. It also help you better understand your own suggestion and identify any pitfalls or issues. This section can also be used to sketch out a simple data model, or flow diagram for the more tech savvy participants\nTechnical aspects: This sections is for writing down all technical aspect that you need to consider or verify as part of the concept. If our concept is a brand new licensing model where users pay for each feature, we might need to consider a complete redesign of our software architecture to encapsulate features and toggle on or off on a user level. Capabilities the system might not have today.\nVerification and validation: What to we do to verify the concept, what is the criteria, market, segment etc. This should go all the way back to the opportunity and it is key for the success of this workshop. If we don’t do propper verification and agree on the criteria we might as well just follow the anti-pattern of key stakeholders having their ideas implemented, not focusing on customer value\n<figure><img alt=\"\" src=\"https://cdn-images-1.medium.com/max/1024/1*NskqZCQGIdzvrGJ2hmkztg.png\"></figure><h4>Afterwork</h4>\nThis is your time to shine PO or product designer. You hopefully have the mandate, anchored in some insight and data, to further develop the concept drafts into propper concepts, verify them, build the MVP and iterate with many version after that. Good luck..\n<img src=\"https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=ad1d04982a60\" width=\"1\" height=\"1\" alt=\"\"><hr>\n<a href=\"https://medium.com/dfind-consulting/help-im-a-proxy-product-owner-ad1d04982a60\">Help, I’m a proxy product owner!</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.\n

Help, I’m a proxy product owner!

\n<figure><img alt=\"\" src=\"https://cdn-images-1.medium.com/max/1024/1*ml53jqb5uYA704hbuPiK5A.jpeg\"><figcaption>Photo by: <a href=\"https://unsplash.com/@asci_en\">https://unsplash.com/@asci_en</a></figcaption></figure>Have you ever thought of spicing up your scrollable content with nice-looking shadows? Yes, all browsers have the scroll bar, but we can make our content shine even better and, at the same time, improve usability. I think shadows add a smooth and excellent feel to our content and help by showing the users that “there is more content down here” or “there is more content up here”.\n<blockquote>TLDR: You will find the final source code at the bottom of the article</blockquote>\n<h3>The Scroll Hook</h3>\nRecently, I’ve been working on a hook that adds inner shadows when scrolling an element with overflowing content. It is not very complicated, and it’s fun to make. We’ll break down the code throughout the post, look into how it works, and finally use it in our code.\n<a href=\"https://medium.com/media/154ecf87431923f99747b31da71175d4/href\">https://medium.com/media/154ecf87431923f99747b31da71175d4/href</a><h4>Handling scroll events</h4>\nFirst, let’s go through the roll logic part of the hook. It’s not complicated, and I did not have to create three separate states for each event. But it is done for simplicity instead of holding an object with all the values.\n<a href=\"https://medium.com/media/360751a2658643353a36a8f419148277/href\">https://medium.com/media/360751a2658643353a36a8f419148277/href</a>onScroll is a React property that we can get on any scrollable HTML element for listening on scroll events, such as a div. It takes a function and returns an event of the target element. In native JavaScript, this would be somewhat equivalent to:\n<pre>element.addEventListener(‘scroll’, (event) =&gt; /* do something*/)</pre>\nThe onScrollHandler-method (exported from the hook) we can pass as the value to the onScroll-property of our element. When scrolling the element, the onScroll-property fires and the onScrollHandler-method triggers. Then we can pick the properties scrollTop, scrollHeight and clientHeight from the event target and set them as values for their respective states.\nThe onScrollHandler-method (exported from the hook) we can pass as the value to the onScroll-property of our element. When scrolling the element, the onScroll-property fires scroll events, and the onScrollHandler-method receives these events. We can then pick the properties scrollTop, scrollHeight and clientHeight from the event target and set them as values for their respective states.\n<figure><img alt=\"\" src=\"https://cdn-images-1.medium.com/max/570/1*cB16NN2s7k_3f-nW8smY_g.png\"><figcaption>Illustration of scrollHeight and clientHeight on an element with overflowing children elements</figcaption></figure><ul>\n<li>\nclientHeight (visible content) is the inner height of an element, including padding. We can calculate it by CSS height + CSS padding. If a horizontal scrollbar is present, the inner height includes the height of the scrollbar.</li>\n<li>\nscrollHeight (visible + hidden content) is the height of an element’s visible content, including hidden content not visible on the screen for an overflowing element.</li>\n<li>\nscrollTop is the number of pixels scrolled vertically on the content of an element. Measuring the value takes the distance from the top of an element to the topmost of visible content.</li>\n</ul>\n(Read more about <a href=\"https://developer.mozilla.org/en-US/docs/Web/API/Element/scrollTop\">scrollTop</a>, <a href=\"https://developer.mozilla.org/en-US/docs/Web/API/Element/scrollHeight\">scrollHeight</a> and <a href=\"https://developer.mozilla.org/en-US/docs/Web/API/Element/clientHeight\">clientHeight</a> on MDN)\n<h4>Calculate shadow position</h4>\nWe have to do some calculations to determine if and when we should show shadows on the top, bottom, or both. We want to show shadows concurrently when we’re neither at the top of the scroll nor the bottom.\n<a href=\"https://medium.com/media/9fcc6ca9c4c03ea3f8bfcfbb8aeb724c/href\">https://medium.com/media/9fcc6ca9c4c03ea3f8bfcfbb8aeb724c/href</a><ul>\n<li>\nisBottom is true when the inner height of the visible element equals the total height of the visible and hidden content minus (-) pixels scrolled from the top of the element.</li>\n<li>\nisTop is true when we’ve not scrolled yet, or scrollTop equals 0 pixels.</li>\n<li>\nisBetween is true when we’ve scrolled more than 0 pixels from the top, and the inner height of the visible element is less (&lt;) than the visible plus (+) hidden content height minus pixels scrolled from the top.</li>\n</ul>\nWe can show this by example: we could have an element that has 400 pixels inner height [clientHeight], that is scrolled 150 pixels from the top [scrollTop]; we should then get that isBetween is true:\n<a href=\"https://medium.com/media/b3d88c31a4c5a1d12774709b7da81f28/href\">https://medium.com/media/b3d88c31a4c5a1d12774709b7da81f28/href</a><h4>Determine shadow type based on the calculated position</h4>\nOur getBoxShadow()-function handles the logic for determining and returning the correct CSS box-shadow value as a string. This value we want to set to the target element reactive as we scroll. We’re here using the variables — isBottom, isTop and isBetween —from earlier to determine which shadow to use:\n<a href=\"https://medium.com/media/dd244c457001664fff144489f9a1b027/href\">https://medium.com/media/dd244c457001664fff144489f9a1b027/href</a>We want to add shadow to the edge with overflowing content because it makes sense to the eye watching it. So, if we are at the top of the element, we show shadow at the bottom. If we are between (as we calculated in the previous code example), we want to show both top and bottom shadows, or else if we are at the bottom of the element, we want to show the top shadow.\n<figure><img alt=\"\" src=\"https://cdn-images-1.medium.com/max/894/1*1vDIJ5_pf17kz1tifdaBCw.png\"><figcaption>Illustration of inner box shadow top and bottom on an element with overflowing children elements</figcaption></figure><h3>Using the Scroll Hook</h3>\nSince this is a React hook, we need to create a component that can use it, and it should be straightforward since as there is to do is connect the props to the target element.\nIn the code block below, we have a component called App. We import the useScrollWithShadow-hook, destruct the onScrollHandler()-method and the boxShadow variable. We pass onScrollHandler() as the value of the div’ onScroll property and set boxShadow as an inline style.\n<a href=\"https://medium.com/media/d5502fbcba53852feaf3e18921c672a5/href\">https://medium.com/media/d5502fbcba53852feaf3e18921c672a5/href</a>Without some content that overflows the element, this would not look or work very well. All it is left is to add some content to the div and maybe some static height so we can get an overflow. We could also add CSS transitions for even more smoothening. But from here on, I will leave the rest to your imagination.\nLook at the final result for the styled solution with content and source code on Codesandbox.\n<h3>Final result</h3>\nHere is the final result. Click “toggle shadows” to switch between with and without shadows (<a href=\"https://codesandbox.io/s/upbeat-sun-zgyyo5\">source code on Codesandbox</a>):\n<a href=\"https://medium.com/media/0539ccf83b2c50d23410531b216ea8aa/href\">https://medium.com/media/0539ccf83b2c50d23410531b216ea8aa/href</a>Thanks for reading! (feel free to clap and share if you liked this article)\nCode foh shizzle\n<img src=\"https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=9ba2d47ae32\" width=\"1\" height=\"1\" alt=\"\"><hr>\n<a href=\"https://medium.com/dfind-consulting/react-scroll-hook-with-shadows-9ba2d47ae32\">React Scroll Hook with Shadows</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.\n

React Scroll Hook with Shadows

\n<figure><img alt=\"\" src=\"https://cdn-images-1.medium.com/max/1024/1*UXGeBLBT2vMnr4mmF_cWwQ.jpeg\"><figcaption>Photo by National Cancer Institute on Unsplash</figcaption></figure>Vi hadde brukt 10 måneder på å lage et nytt design for vår digitale tjeneste. Endelig kunne vi gjennomføre brukertestene, <a href=\"https://medium.com/dfind-consulting/hvordan-bruke-data-for-%C3%A5-forbedre-designl%C3%B8sningene-dine-ae458fc2d1f4\">følge med på dataen</a>, og få svar på hvordan tjenesten faktisk fungerte.\n– Men, 10 måneder? Hvorfor i alle dager hadde det tatt så lang tid?\nAv <a href=\"https://medium.com/u/71882bf4de0a\">Ida Kalfoss</a>\nVi jobber i en stor organisasjon med en løsning som retter seg mot (travle!) bedriftskunder. Man skulle jo tro at det var oppskriften for langsom utvikling, men det kunne vi ikke skylde på. For sannheten var at teamet faktisk hadde stor frihet til å styre prosessen, og lett tilgang til brukere når vi trengte tilbakemeldinger. Allikevel hadde det altså tatt 10 hele måneder.\nDet var ikke ledelsen som stilte krav til raskere utvikling, eller mer effektivitet i arbeidet. De var godt fornøyde med lanseringen. Men internt i teamet opplevde vi at fallhøyden ble veldig stor pga. tidsbruken, og ikke minst kjente vi på at den langtekkelige prosessen ble demotiverende for oss. Veldig demotiverende!\nFinne balansen i et tverrfaglig team På teamet var vi en utvikler, en UX-designer, en innholdsdesigner, en produkteier og en teamleder. Vi jobbet godt sammen, men likevel var det noe som skurret. Det første vi så var at balansen/arbeidsfordelingen mellom rollene var skjevfordelt. Vi var to på design/UX, to administrative roller, men kun en utvikler. Med måten vi jobbet på så ble det i perioder mye alene-koding for utvikleren, uten noen å sparre med, og det var verken effektivt eller inspirerende. Så den første endringen vi gjorde var å utvide teamet med enda en utvikler.\nDa hadde vi skaffet oss et velbalansert tverrfaglig team, som kjente hverandre, og som var få nok til å raskt kunne gjøre avklaringer og fordele oppgaver, men mange nok til å alltid ha én innenfor sitt fagfelt å sparre med. Men det løste ikke automatisk utfordringen med den langsomme utviklingen.\nVi ble Inspired På dette tidspunktet så hadde vi en boksirkel der vi alle leste Inspired av Marty Cagan. Han skriver om hvordan noen av de store produktorganisasjonene brukte referance customers, i et customer discovery program. Dette var noen få reelle brukere som ble brukt som referansegruppe gjennom en utviklingsprosess. Gruppen bistod som sparringspartnere, testere og gav kontinuerlige tilbakemeldinger på løsningene. I tillegg var referansegruppen en viktig del av organisasjonenes markedsføring, ved at de hadde et sterkt eierskap til produktene, og på den måten ville spre det gode ord etter lansering. Formålet med en slik gruppen er å ha enkel tilgang til relevante brukere, slik at de kan gi raske tilbakemeldinger på nye ideer på noe de selv hadde lyst (eller trenger) å bruke. Dette var jo akkurat det vi hadde behov for!\nFinne de rette folka til testpanelet Siden vi var et lite team bestående av seks personer, var det ikke langt fra ønske til handling, og i løpet av en uke hadde vi vi satt i gang rekruttering av brukere til vår egen referansegruppe, eller testpanel, som kanskje er mer beskrivende for vårt bruk.\nVi gjorde dette ved å legge inn et spørsmål i slutten av vår digitale tjeneste, der vi spurte om de hadde lyst til å være med på å forbedre løsningen vår. Ved at spørsmålet lå på siste steg i løsningen, sikret vi at brukerne vi rekrutterte hadde et reelt behov. I tillegg sikret vi at de var motiverte, da de aktivt måtte sjekke av for å vise interesse. Etter kort tid hadde vi seks brukere i vår testpanel!\nTestpanel for å få opp farta Endelig kunne vi kjapt teste ut nye ideer og konsepter. Teste og feile kjapt. Så fort vi hadde en ny idé eller konsept så kalte vi inn brukerne fra testpanelet. Vanligvis rekrutterte vi brukere gjennom et eksternt byrå, og det fungerte fint når vi skulle ha brukertester, men det tok ofte lang tid når vi bare ønsket en rask avklaring. I tillegg er det ikke bærekraftig å gå gjennom en lang og dyr rekrutteringsprosess, for så å teste en bitteliten detalj (mock-up). Men med testpanelet så kunne vi teste allerede samme uke!\nNå kunne vi raskt teste enkle prototyper og små mock-ups. Hensikten var å få tilbakemeldinger på om noen av våre hypoteser stemte og prioritere hvilke ideér vi skulle bearbeide i neste iterasjon..\nHver test tok ca 20 til 30 minutter, og vi samlet testene til en dag. Vi var to personer fra teamet og en testperson, som sammen så på skissene. Deltagerne i testpanelet er travle bedriftskunder, derfor ble testene gjennomført digitalt. Dette senket også terskelen for å bli med. Dermed ble det enkelt for resten av teamet å være med som observatører med kamera og mikrofon av.\n<figure><img alt=\"\" src=\"https://cdn-images-1.medium.com/max/531/0*rZv6W5TJoFt7KMiv\"><figcaption>Testingen med testpanelet, eller mock-up testing, er en god måte å komplettere andre metoder (triangulering) for å skaffe seg innsikt om et produkt/løsning.</figcaption></figure>– Men hjalp det da? Ja. Og ja! Nå kunne vi teste ut de rareste ideene nesten samtidig som de oppstod. Og fremfor alt kunne vi forkaste dem like kjapt! Vi brukte eksempelvis 15 min på å skisse opp ulike måter å vise en prisindikasjon på. Særlig den ene ideen, et slags kakediagram, syntes vi alle var helt genialt og utrolig intuitivt (nå hadde vi nailet det!). Brukerne i testpanelet var dog ikke like begeistrede (– heh? Tre kvarts full? Sammenliknet med hva?). Javel, nailet ikke den. Men brukte heller ikke mange minutter på å finne ut av det.\nDet å involvere brukerne tidlig i designprosessen gav oss mulighet til å få kvalifiserte tilbakemeldinger på små deler av løsningen. Dette gjorde at vi fikk litt mer tro på det vi lagde, og lanserte mindre deler av løsningen iterativt, istedenfor å samle opp til en stor lansering til slutt. Da var alle roller aktive til hver tid, istedenfor å gå fra først en langvarig designperiode til en lang utviklingsperiode. Noe som føltes mer givende og motiverende for alle på teamet!\nHvorfor vi digget testpanelet · Det ga oss enkel tilgang til brukere · Vi hadde brukere som hadde brukt vår løsning — gir oss relevante tilbakemeldinger · Brukeren føler seg komfortabel i å si hva de tenker, ettersom de lærer kjenne oss over tid (og bonus: det er sykt hyggelige samtaler!) · Vi kunne holde møtene korte — trengte ikke bruke tid på introduksjon · Teste en idé/konsept kjapt — feile kjapt. Blir ikke like hardt å «kill your babies».. · Tidseffektivt · Fremdrift — fikk oss å til å bevege oss raskere\nHva vi har lært av hva som fungerte — og ikke fungerte — for oss · Tre personer i samtale under testene gir god dynamikk (vi pleier ellers å kun være en fra oss sammen med brukeren, når vi gjennomfører brukertester) · Det å rekruttere personer som har vært igjennom løsningen vår, gir oss brukere med et reelt behov å løse · Vi fikk brukere som var motivert av problemløsning, ikke penger (de fikk «kun» 500kr etter fire tilfeller) · Hold møtene korte — test heller færre ting ettersom man ikke rekker å gå i dybden på kort tid, men vi ville heller ikke skremme vekk brukeren med lange møter som spiser av arbeidsdagen deres · Brukes ikke for å validere en idé, men for å få kvalifiserte tilbakemeldinger · Brukeren er mer som en sparringspartner — blir mer ledende spørsmål enn i for eksempel en brukbarhetstest (usability test). Dette var noe vi måtte ha i bakhodet når vi gikk i gjennom innspillene etterpå. · Skal ikke brukes istedenfor andre metoder, men som en komplementerende metode · Dediker en person til oppfølging av testpersonene. Vi trengte å bruke mer tid på å følge opp testpanelet, enn når vi rekrutterte gjennom eksterne rekrutteringsbyråer. I tillegg var det viktig å holde testpersonene «varme» over tid · Det er en team aktivitet, og fungerte best når hele teamet var involvert i hva vi skulle teste, gjennom testene, og i oppfølgingen etter testene. Ikke for å forankre eller inkludere interessenter.\nSå hvis du eller ditt team også er en av dem som sliter med å holde motivasjonen oppe gjennom litt vel langtekkelige utviklingsprosesser — finn dere en relevant og motivert gjeng som har bruk for løsningen deres, og sett i gang med litt mock-up testing! Ikke bare er det effektivt og motiverende, det er faktisk utrolig hyggelig i tillegg.\n<img src=\"https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=9369fa2af030\" width=\"1\" height=\"1\" alt=\"\"><hr>\n<a href=\"https://medium.com/dfind-consulting/hvordan-f%C3%A5-opp-farta-p%C3%A5-utviklingen-med-et-testpanel-9369fa2af030\">Hvordan få opp farta på utviklingen med et testpanel</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.\n

Hvordan få opp farta på utviklingen med et testpanel

\nav <a href=\"https://medium.com/u/e30b5da9a1ad\">Kristine Helle-Andresen</a> og <a href=\"https://medium.com/u/33d36f229662\">Emilie Haugen</a>\n<figure><img alt=\"\" src=\"https://cdn-images-1.medium.com/max/700/0*Mo-0gqIfXXaoakcs.jpeg\"><figcaption>Foto av <a href=\"https://unsplash.com/@giuvicente\">Giu Vicente</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>Gratulerer med kvinnedagen, alle sammen!\nI dag ønsker vi å sette fokus på alt det gode arbeidet som gjøres for å øke kvinneandelen i techbransjen, av aktører på alle nivåer. De siste årene sees det en positiv endring med økt fokus på å få flere kvinner til å studere og jobbe i techbransjen. Det starter med 5.klassinger som utfolder seg på Girl Tech Fest-arrangementer over hele landet. Ungdomsskole-elever som besøker techselskaper på inspirasjonsdagen «Girls Day in Tech». Andelen jenter som velger teknologi-relaterte studieprogram øker. De positive trendene er mange, og på en dag som denne er det på sin plass å framsnakke alle som jobber målrettet med å øke kvinneandelen i techbransjen.\n<h3>En trygg og bærekraftig fremtid for alle</h3>\nDfind Consulting har latt seg inspirere av selskaper som deler åpent om positive erfaringer med bevisst arbeid rundt mangfold, og har bestemt oss for å målrettet arbeide med å øke kvinneandelen i selskapet og i techbransjen forøvrig. Hvorfor er dette arbeidet så viktig? En kan umiddelbart tenke seg åpenbare etiske årsaker til hvorfor det bør rettes fokus mot dette, med verdier som likestilling i arbeidsmarkedet, like muligheter uavhengig av kjønn og så videre.\nMen hva er egentlig konsekvensene av et arbeidsmarked uten likestilling mellom kjønn? Om ikke kvinners perspektiver inkluderes i kartlegging, planlegging, gjennomføring og implementering av fremtidens løsninger tilpasses de ikke deres anatomi og behov. Konsekvensen er at teknologien i større grad tilpasses menn og ikke kvinner. Et eksempel er smarttelefoner — de største og gjerne beste telefonene er ofte alt for store for kvinnelige hender. Mens ved AI-teknologi ser man for eksempel at Siri responderer raskere og mer “to the point” når menn prater enn kvinner. Eksemplene virker uskyldige, men med samme trend i utviklingen risikerer man at teknologi innenfor blant annet medisin og sikkerhet har samme følger. For å skape en trygg og bærekraftig fremtid må alle inkluderes.\nFor det enkelte selskap finnes det også gode grunner til å øke kvinneandelen. Forskning viser nemlig at mangfold kan generere kreativitet og innovasjon som et resultat av ulike perspektiver og potensialer (Hoffman 1959; Hoffman og Maier 1961; Watson et al. 1993). Med flere kvinner i bransjen øker mangfoldet, og kan dermed berike og gi fordeler basert på elementære ulikheter mellom mann og kvinne. Eksempler er ulik problemløsning, ulik utførelse av oppgaver og andre perspektiver ved diskusjon basert på ulik persepsjon. Når dette fungerer skapes en arena for kreative og innoverende løsninger — og det er jo dette bransjen vår lever av!\n<h3>Inkludering og kultur som nøkkelord</h3>\nVi ønsker å bidra til en trygg og bærekraftig fremtid for alle. For å gjøre dette må aller inkluderes. Hos oss sees fokuset på mangfold i alt vi gjør; fra rekrutteringsprosessen, til oppfølging av konsulenter, utviklingsmuligheter, aktivitetstilbud og ansatte i ledelsen.\nEn sunn og åpen kultur er vårt fundament og gjør oss til et attraktivt selskap, også for kvinner. Med gode og lett tilgjengelige kommunikasjonskanaler skaper og deler vi kunnskap og bevissthet rundt tematikken, samtidig som det sikrer involvering ved å legge til rette for å kunne kommunisere ønsker og behov. Dette har bidratt til engasjement og samhold om å ta vare på kvinnene vi har og øke kvinneandelen hos oss ytterligere. Det åpner også muligheten for å revidere og skape et aktivitetstilbud som appellerer mer til kvinner basert på deres ønsker. For å bidra til rekruttering av fremtidens kvinner til techbransjen er det også viktig å være engasjert på utdanningsnivå. Dfind Consulting er partnere med Ada-nettverket til NTNU, i tillegg til flere andre samarbeid med universiteter og høyskoler. Vi samarbeider også med andre institusjoner og skal i fremtiden være med å arrangere “Girls Day in Tech” og “Girl Tech Fest”. For å sikre engasjement i bransjen generelt legger vi opp til deltagelse på initiativer arrangert av andre institusjoner ved å tilrettelegge for felles aktiviteter før, under og etter arrangementene. I juni drar tolv stykker fra Dfind Consulting, både menn og kvinner, sammen til konferansen European Women In Tech i Amsterdam. Mange av oss er selvsagt også å finne på ODA’s inspirasjonsdag 2022 — vi gleder oss!\nVi er i gang, men reisen har bare såvidt begynt. Alle er tjent med mangfold. I kjønn, i etnisitet, i religion, i livssyn, i alder. Ulike perspektiver skaper løsninger som appellerer og fungerer til ulike mennesker. Og er det noe vi vet, så er det at teknologi er kommet for å bli. Vi håper våre tanker og innspill kan bidra til å belyse en viktig utfordring i en helt sentral bransje for samfunnets utvikling, og være til inspirasjon for flere — både som selskap og enkeltmenneske.\n<img src=\"https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=f4d7607f5068\" width=\"1\" height=\"1\" alt=\"\"><hr>\n<a href=\"https://medium.com/dfind-consulting/la-oss-inspirere-hverandre-og-sammen-%C3%B8ke-kvinneandelen-i-techbransjen-f4d7607f5068\">La oss inspirere hverandre og sammen øke kvinneandelen i techbransjen</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.\n

La oss inspirere hverandre og sammen øke kvinneandelen i techbransjen

\nThe web browser console gives us more options than just the console.log()\n<figure><img alt=\"\" src=\"https://cdn-images-1.medium.com/max/1024/1*qbSBSYYEKTSCfXF5gKz6qQ.png\"><figcaption>Image of a road sign containing the text: Watch out! overuse detected</figcaption></figure>OK, I admit it, and I’m not very a fan of it. Mostly I use console.log() for troubleshooting, checking that the arguments of a function get the correct values or that a function returns what I expect it to do. Sometimes I take shortcuts using the built-in browser method console.log() to clarify the result of some piece of code. On infrequent occasions, instead of rendering a ReactJS-component to the Graphical User Interface (GUI), I may print the component to the console to examine its properties.\nI’ve seen many developers are using the web console in similar ways as I do. We developers should stop overusing the console.log() and instead draw advantages from what we can do with the web console than just reading simple logs.\nI want to discuss some common issues and bad habits that we usually do and some solutions for using the console better.\n<h3>Issues and bad habits</h3>\nHow often do we think about why we use the console.log() method, and in what contexts? Is it just purely automatic that we use it? Why do we always have to do all this logging, especially with console.log()?\nIn many of these situations, instead of reading and understanding the code, we make guesses and try to help ourselves by logging stuff to the console. All this time we spend on logging can be very time-consuming (sometimes it can even make us even more confused), and we probably “learn” slower.\n<h4>Unnecessary logging = less confidence</h4>\nAn unnecessary amount of logging to the console makes us less confident. Developers often log to the console in many parts of the code — especially if functions are deeply chained — to “test” our code is reliable.\n<h4>Using the console for “confirmation”</h4>\nIn far too many cases, we also accept that when logging something to the console, we get an indication that “everything works fine.” We can prevent building agents or scripts from breaking if we read and understand the code thoroughly instead of relying on the “confirmation” that the console may give us.\nWe often use this “confirmation” to check whether something is wrong or not, whether an object is undefined or an array has a length. I would say that “confirmation” is OK when our code breaks, and there are no other options.\n<h4>Debugging is time-consuming</h4>\nDebugging in the console may be time-consuming. Sometimes we can sit for days logging things to the console, taking away the focus on understanding how the code “actually” works and other options that we could have tried instead of just logging stuff.\n<h4>Logs may end up in production</h4>\nLogging to the console can be deployed in production, which is not always that great — especially if we log critical information that should not be available to “everyone” on the web.\n<h3>How we should use the web console</h3>\nWhat is essential to know is that the console also is a <a href=\"https://en.wikipedia.org/wiki/REPL\">REPL</a>. That means we can interact with JavaScript on the page we’re inspecting. Using the REPL is a great way to play with and learn JavaScript.\n<figure><img alt=\"\" src=\"https://cdn-images-1.medium.com/max/1024/1*IJD_qI9I0EBnjxkcxUvlAw.png\"><figcaption>Using the console REPL to add textContent to an HTML element with a wordmark CSS-selector. Here we add a string “Hello” above the Firefox logo.</figcaption></figure><h4>Useful console methods</h4>\nThe overusedconsole.log() is just one of many methods we may call on the console object. console.error(), console.info(), and console.warn() may be better in cases where we will separate different states of messages. And, to get a better representation of our data in the console we can use methods like console.group() and console.table().\nconsole.error(): Prints an error message to the console, where the printed content will have a red colour. Most browsers also displays an error icon beside the console message.\nconsole.error(‘Something is wrong’)\n<figure><img alt=\"\" src=\"https://cdn-images-1.medium.com/max/1024/1*tYcFUWNQmHoWvGFQL6geeA.png\"></figure>console.warn(): Prints a warning message to the console, where the printed content will have a yellow color. Most browser also displays an warning icon beside the console message.\nconsole.warn(‘Heads up! This is a warning’)\n<figure><img alt=\"\" src=\"https://cdn-images-1.medium.com/max/1024/1*urjiiFrNXm3I2S_pYvVhBw.png\"><figcaption>Illustration: console.warn example in Firefox. console message with a yellow triangle containing an exclamation mark</figcaption></figure>console.group(): Prints a group of console methods executed within the group. Such logging is usable when we need to do more than a single log in different files which is not related. We can also open and close groups in the console.\n<pre>console.group(‘feature’) console.warn(‘Heads up! This is a warning’) console.error(‘Something is wrong’) console.groupEnd(‘feature’)</pre>\n<figure><img alt=\"\" src=\"https://cdn-images-1.medium.com/max/1024/1*rMwm77JyiXtzVsSljonvtQ.png\"><figcaption>Illustration: console.group example in Firefox. console messages grouped within a console group called “feature.”</figcaption></figure>console.table(): Prints a table representation of the data provided. The method accepts objects and arrays.\nconsole.table([{ a: 1, b: 2 }])\n<figure><img alt=\"\" src=\"https://cdn-images-1.medium.com/max/1024/1*DB4_roBRCsKjULq_zPce-A.png\"><figcaption>Illustration: console.table example in Firefox. console messages are displayed in a table representation</figcaption></figure><h4>Some final words</h4>\nIt’s not uncommon [for JavaScript beginners and professionals] to just print strings that say “works” or “done” or something similar and then use them to “confirm” that our code works as expected. I’ve seen far too many uses of console.log() in different places in a codebase simultaneously during a pair programming session.\nBrowser consoles are great tools, and we should use the great utils they provide to our benefit; testing JavaScript methods or extracts, playing with Document Object Model (DOM) or objects in our code. We can do much more with the console than log simple strings, numbers, or lengths on a list.\nWe should focus on understanding the underlying code and using the console for its benefits and not as a tool for confirmation; then, we will learn faster, become more confident and write better code in the future.\nThanks for reading\nCode foh shizzle\n<img src=\"https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=ff4b85df5268\" width=\"1\" height=\"1\" alt=\"\"><hr>\n<a href=\"https://medium.com/dfind-consulting/stop-overusing-console-log-in-javascript-ff4b85df5268\">Stop Overusing Console.log in JavaScript</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.\n

Stop Overusing Console.log in JavaScript

\nArbeidslivet 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.\nI 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!\n<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.\nTilhø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.\nFø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.\nKompetanse 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.\nFor å 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.\n<img src=\"https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=c4de4a359c91\" width=\"1\" height=\"1\" alt=\"\"><hr>\n<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.\n

Tre faktorer som genererer indre motivasjon

\n…pengene kom ikke inn, selv om du Vippset allerede da jeg sto heeelt bakerst i køen på Starbucks.» - sier min 11-årige datter.\n<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).\nOg den gangen iPhonen og Apple Watchen ikke snakket sammen var de heller ikke «ødelagte» eller «dårlige».\nDet krevde bare en ørliten omstart, eller en programvareoppdatering.\nSå hva er det jeg vil frem til her?\nAt 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?\nNeida. 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!).\nMen, 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.\n<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.\nJoda, 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.\nSelv 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.\nOg 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”.\nHvordan 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?\nJoda, vi utvikler nok oss i takt med tiden vi også.\nMen vi må jaggu følge med i svingene!\n<img src=\"https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=76d551421533\" width=\"1\" height=\"1\" alt=\"\"><hr>\n<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.\n

«Mamma, det er noe galt med Vipps…

\n<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>\nDaglig 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>.\nHan 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?”\nUten å 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.\nSelvfø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?\nAt 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?\nÅ 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.\nNå 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.\n<img src=\"https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=9e896f453356\" width=\"1\" height=\"1\" alt=\"\"><hr>\n<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.\n

Hjemmekontor til besvær

\n<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>\nav <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>\n<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.\nFinn 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.\n2. 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.\nMange 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å.\n3. 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.\nFokuser 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å.\n4. Google og stack overflow er enhver utviklers aller beste venn\n<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?\n5. 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.\nPrat 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!\n6. 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.\n7. 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.\n8. Noen dager vil se slik ut:\n<ol>\n<li>Du stanger hodet i veggen fordi du ikke klarer å løse et problem</li>\n<li>Du tråler internett og stack overflow for å se om NOEN andre i hele verden har hatt samme problemstilling…</li>\n<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>\n<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>\n</ol>\n9. … 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!\n10. 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.\n60% 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.\n11. Å 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.\n… Og med dette gjenstår det bare å ønske deg masse lykke til i arbeidslivet!\n<img src=\"https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=974fb21592e\" width=\"1\" height=\"1\" alt=\"\"><hr>\n<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.\n

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

\nAv: <a href=\"https://medium.com/u/8fb5525e0684\">Eirik Gihle</a> og <a href=\"https://medium.com/u/cbae7ec46d93\">Karianne Tørum</a>\n1. 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å.\n2. 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.\nJeg tror jeg ville senket skuldrene litt, og kanskje turt å være mer utforskende dersom dette var kommunisert litt tydeligere da jeg begynte som designer.\n<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.\nSiden 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å:\n4. 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!\n5. 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».\n6. 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!\n7. Å 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!”\n<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>\n9. 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.\nHvordan 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?\nSelv 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.\n10. 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!\nLykke til!\nHåper vi sees en dag :)\n<img src=\"https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=99d5720b9af4\" width=\"1\" height=\"1\" alt=\"\"><hr>\n<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.\n

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

\n…pengene kom ikke inn, selv om du Vippset allerede da jeg sto heeelt bakerst i køen på Starbucks.» - sier min 11-årige datter.\n<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).\nOg den gangen iPhonen og Apple Watchen ikke snakket sammen var de heller ikke «ødelagte» eller «dårlige».\nDet krevde bare en ørliten omstart, eller en programvareoppdatering.\nSå hva er det jeg vil frem til her?\nAt 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?\nNeida. 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!).\nMen, 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.\n<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.\nJoda, 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.\nSelv 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.\nOg 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”.\nHvordan 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?\nJoda, vi utvikler nok oss i takt med tiden vi også.\nMen vi må jaggu følge med i svingene!\n<img src=\"https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=76d551421533\" width=\"1\" height=\"1\" alt=\"\"><hr>\n<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.\n

\nI 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.\nNoen 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.\nVi som jobber med design, i alle sine former, er vant til å få tilbakemeldinger på alt vi gjør. Fra alle. Hele tiden.\nAlle 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».\n<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…\nSpesielt 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.\nDet 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.\nJeg 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?\nSom 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.\n<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…)\nSå 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.\nSå 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?\nKvantitativ innsikt. Og nå må jeg rope skikkelig høyt:\nAnalyse kan ikke være en egen avdeling som sender ut generell informasjon på overordnet nivå til produktteamene i et selskap!\n<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.\nVi 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?\nMan 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.\nDet 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?\nMen jeg kan love deg at du finner ut noe!\nKanskje 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?\nSå ja; det kan være meget smertefullt å legge hodet på blokken.\nMen det er helt nødvendig, dersom du skal ha et grunnlag for å legge hodet i bløt, — og ikke i tåke!\n<img src=\"https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=8cc85275ba5d\" width=\"1\" height=\"1\" alt=\"\"><hr>\n<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.\n

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

\n<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!\n<h3>Hvor skal man starte?</h3>\nDet 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å.\nDet 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?”\n<h3>Tenk på hva du prøver å oppnå med løsningen, og om intensjonen samsvarer med kundens forventning og bruk?</h3>\nStart 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.\nFinn 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.\nScrolling 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.\nFinn 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».\n<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.\n<h3>Hva betyr tallene, og hvor viktige er de?</h3>\nDa 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!».\n<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.\nSå 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.\nBounce 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.\n<h3>Bli kjent med brukergruppene</h3>\nHar 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?\nDet 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.\n<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.\n<h3>Ingen verktøy gjør jobben alene</h3>\nSelv 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.\n<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>\nI 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.\nEr 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.\n<h3>Skal man alltid stole på alle tallene?</h3>\nTallene 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!\nOg til slutt; ikke tenk du at du skal klare å følge med på all data alene.\n- For du skal jo tross alt levere et design også.\n<blockquote>Lykke til!</blockquote>\n<img src=\"https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=ae458fc2d1f4\" width=\"1\" height=\"1\" alt=\"\"><hr>\n<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.\n

Hvordan bruke data for å forbedre designløsningene dine?

\nI 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.\nAv: <a href=\"https://medium.com/u/cbae7ec46d93\">Karianne Tørum</a> og <a href=\"https://medium.com/u/8fb5525e0684\">Eirik Gihle</a>\nTakket 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.\n<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.\nØ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.\nEffektive 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!\n<img src=\"https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=62b9f6225d7b\" width=\"1\" height=\"1\" alt=\"\"><hr>\n<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.\n

Tverrfaglig samarbeid genererer store besparelser

\n<figure><img alt=\"\" src=\"https://cdn-images-1.medium.com/max/1024/1*nbN27RdqN2KqpTZGCjWUAA.jpeg\"><figcaption>Think of a static website as if we were sitting at a sushi belt in a restaurant. Instead of waiting for the good pieces to come past use at our seat, we can choose precisely the sushi pieces we want right away, ready served. Photo by: <a href=\"https://unsplash.com/@kyleunderscorehead\">https://unsplash.com/@kyleunderscorehead</a></figcaption></figure>Single-Page Applications (SPA’s, or dynamic) and server-based, also called Server Side Rendered (SSR) applications, are probably the most popular ways to create websites these days. But also Static Site Generation (SSG) has become very popular in the past years.\nWhen we need a fast, simple, secure, and cheap website, our next project should be using Static Site Generation.\n<h3>Static vs. dynamic websites</h3>\nTo begin with, we should clear up what the main differences between a static generated website and dynamic websites are:\nA static website is pre-built (on the server) and fetched once on the client without a server.\n<ul><li>Static-generated sites are just a bunch of HTML files. The site may be updated and re-build when publishing new content through a Content Delivery Network (CDN) or when pushing new features. With static site generation, websites become fast; they are easy to publish and secure! We will drill deeper into these benefits later on.</li></ul>\nA dynamic website is when files are changed on the server and fetched on the client on each change.\n<ul><li>Dynamic sites consist of a backend with servers and databases. The site’s content changes dynamically and needs to interact with a database to generate the files “on the fly.” Also, the site needs to fetch the content every time someone revisits the site. Dynamic sites are harder to maintain and less reliable.</li></ul>\n<h3>Benefits of Static Site Generation</h3>\nDynamic and statically generated websites are suitable for different types of applications. Static Generation has unique features for creating a website with few dependencies, and suites better when meeting business goals is crucial.\nWe will look at eight benefits that SSG provide, whereas dynamic websites are not quite as good:\n<h4>No need for a backend developer</h4>\nWe won’t need a backend developer to make an SSG website. Content Administrators and Writers can maintain a Content Management System that stores and have manageable content. Also, a Content Delivery Network (CDN) is a great place to upload our static files.\n<h4>Better reliability</h4>\nWe won’t receive irritating error messages like “500 Internal Server Error.” on an SSG website. The only possible time we will get errors is when the hosting provider gets issues, which rarely happens. Besides that, our website will not have downtime or be unavailable. We will also not need to worry about dynamically scaling our servers or databases.\n<h4>Simplicity</h4>\nWith Static Site Generation comes simplicity. They require no servers or databases. Some JavaScript frameworks, like React-based ones NextJS or GatsbyJS and SvelteJS, provide build-in support and help us generate, minify, and bundle static HTML files at build time. The static files can easily change or move from one hosting service to another.\n<h4>Performance</h4>\nStatic Site Generation gives excellent performance and is fast. We won’t need to wait for many spinners [or skeletons] to tell the user that something is on the way and will replace it at some point.\nThink of a static website as if we were sitting at a sushi belt in a restaurant. Instead of waiting for the good pieces to come past use at our seat, we can choose precisely the sushi pieces we want right away, ready served.\n<h4>Security</h4>\nWe will have excellent security since we don’t need a database or servers running, and they are vulnerable to security breaches. Compilation of source code and content ahead of time (AoT) makes it impossible for hackers to access our databases, CMS, or servers. Since there are no servers involved, the site is also more resilient to DDoS attacks.\n<h4>Lower costs</h4>\nWe may choose to upload our static content to services like Netlify, Vercel, Amazon S3, Google Cloud Platform, and Microsoft Azure; these services are also entirely free. Hosting static content is cheap and requires less bandwidth. And since our site will be less vulnerable to security breaches, we may use that left-over-money for other essential business goals instead of thinking of security monitoring.\n<h4>Improved SEO</h4>\nDynamic sites can be complex when we want to optimize our website for search engines. And if it’s crucial for our site and content. The most common problems with dynamic sites are that these are fast at first page-load, but most critical content is fetched and displayed asynchronously.\nWe get well-optimized content for SEO with pre-rendered content and fast page load. Good SEO optimization will give a low or decreased “bounce rate,” which is the proportion of visitors leaving the website. It also improves search traffic, better lead generation, and customer engagement.\n<h4>Scalability</h4>\nStatic Site Generation provides excellent scalability; we cannot always say the same with dynamic sites. So let’s take a scenario where we may have scalability issues with a dynamic site:\n<ul><li>We have a website that a few visitors typically use. At one point (maybe just a few minutes), the site can be used by thousands of users simultaneously. Maybe we’ve published something that has gone viral — such as news — or a DDoS attack. Such an event can be costly, grow rapidly in volume and take down our servers in the worst case. Such events can cause an unexpectedly large number of server requests and will potentially generate dynamic content for each of the thousands of unexpected users.</li></ul>\nStatic content and SSG are different: The website is pre-generated, with styles and content. Users only need to download the page’s content that they are visiting.\n<h3>Conclusion</h3>\nWe should use Static Site Generation when making a blog, landing page, newspaper, hotel booking service, or e-commerce store. On some occasions, we may even combine dynamic and static content, where our public pages as static pre-rendered content and internal or user-oriented pages are dynamic.\nWhen running an online newspaper, combing dynamic and static content might be a good choice. The front pages can be of static content presented on the page to the users as soon as they enter, with main headlines and images, and videos can have a generated GIF instead of loading in a preview. Articles can then be fetched by an identifier (id) in the URL and rendered in a separate application or on a different route on the website that dynamically retrieves the content.\nStatic Site Generation should be considered over dynamic SPA’s if any of the abovementioned points are crucial for our organization, whether costs, user experience, or performance.\nThanks for reading!\nCode foh shizzle\n<img src=\"https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=5fb187d1ffe6\" width=\"1\" height=\"1\" alt=\"\"><hr>\n<a href=\"https://medium.com/dfind-consulting/benefits-of-static-websites-5fb187d1ffe6\">Benefits of Static Site Generation</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.\n

Benefits of Static Site Generation

Nysgjerrige folk med forskjellig kompetanse gir nye perspektiver og styrker oss som selskap. Du bør ha relevant utdanning og minimum tre års erfaring som utvikler, UX eller UI-designer, systemarkitekt eller prosjektleder. Ta kontakt og bli med på laget!

Bli en av oss banner

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

Møt en X banner

Vi jobber med brukeropplevelser (UX), systemutvikling, prosjektledelse, rådgivning og arkitektur. Les noen av våre Medium blog posts her!

Bloggen - Dfind Consulting

Aase Thuestad

Adrian er en strukturert og løsningsorientert fullstack utvikler som brenner for backend. Hans spisskompetanse ligger i komplekse backend-løsninger og integrasjoner med bruk av JavaScript, .NET, Microsoft Azure, SQL, REST og SOAP. Adrian trives godt i alle faser av systemutvikling, særlig når han får mulighet til å samarbeide tett med kunden. Han har jobbet som utvikler med komplekse leveranser, men også som teknisk arkitekt hvor han har måtte balansere mange ulike ønsker og behov. Videre har han tilegnet seg betydelig erfaring med prosjektgjennomføring, arkitektur, design, testgjennomføring og filosofi, kravspesifikasjon og implementering. Han har jobbet med en mengde varierte og utfordrende API-er og datagrunnlag. Adrian er meget fremoverlent og proaktiv. Han jobber meget selvstendig, samtidig som han trivdes godt i samarbeid med andre, både kunder og kolleger. Samtidig jobber han utrettelig for å imøtekomme kundens ønsker.

Adrian Severin Jensen

Albert Ohrem Larsen er fullstack-utvikler med kompetansetyngde på .NET og C# i backend, samt flere rammeverk som Angular, Vue, React, TypeScript og JavaScript i frontend. Han har solid kunnskap om SQL databaser ved bruk av ORM verktøy. Han har sin bransjeerfaring fra Integrerings- og mangfoldsdirektoratet og Luftfartstilsynet. Albert holder seg stadig oppdatert på det siste innen Microsoft .NET rammeverk og verktøy. Albert har erfaring med å utvikle frontend sammen med backend i sømløse mikrotjenester med REST api arkitektur. Han er opptatt av dokumentasjon og testing. Han har også god kunnskap om kontinuerlig leveranser og integrasjoner ved bruk av Azure DevOps (CI/CD). Albert har i alle sine prosjekter utført med smidig metodikk og synes at det beste løsningene løses i et tverrfaglig team. Albert er utdannet som Dataingeniør ved NTNU

Albert Ohrem Larsen

Aleksander har fire års erfaring som Java backend- og DevOps-utvikler. Han har god erfaring fra større smidige utviklingsprosjekter, og jobber med kontinuerlig leveranse og integrasjon, utvikling av infrastruktur ved f.eks bruk av Ansible og Kubernets, logghåndtering, deployment, monitorering.

Som DevOps-utvikler har Aleksander jobbet med å skape utviklingsmiljøer som fører til kortere time to market, større grad av automasjon og enklere deployment. Applikasjonene han har jobbet med har hovedsakelig vært utviklet i Java Spring og Python.

Aleksander Jacobsen

Aleksander er en utvikler med en unik forståelse for samspillet mellom teknologi og design som elsker å skape engasjerende brukeropplevelser med elegante og moderne tekniske løsninger. Hans mastergrad innen design, bruk og interaksjon underbygger hans forståelse for dette.

Aleksander har sin fagkompetanse innen programvareutvikling, brukeropplevelse og design med over 5 års erfaring innen utvikling for blant annet web og mobil. Han motiveres av å jobbe i tett samarbeid med designere slik at han kan bidra til å løfte brukeropplevelsen gjennom gode tekniske og brukersentrerte løsninger.

Aleksander har fått bred erfaring fra prosjekter innen systemutvikling, webutvikling, apputviking, interaksjonsdesign, forskning og produktutvikling, og bred bransjeerfaring fra blant annet offentlig sektor, telecom og finans. I tillegg har han erfaring som blant annet frontendutvikler samt backendutvikler i et javamiljø.

Aleksander Rem

Aleksander er en fullstack utvikler med erfaring innen Data Science og maskinlæring, med fokus på Python og Tensorflow. Han har erfaring med bruk av Docker og Kubernetes. Aleksander har bransjeerfaring fra maritim sektor og ecommerce gjennom prosjekter i DNV og Gurusoft AS. Gjennom tidligere prosjekter har Aleksander jobbet med bygging av maskinlæring ved bruk av automated pipelines og Docker. Han har jobbet i team og alene i prosjekt, og det har vært daglige statusmøter i prosjektene. Aleksander har en master i Datateknologi og Finansiell økonomi ved NTNU Trondheim.

Aleksander Scherman Olsen

Alexander er en erfaren fullstack systemutvikler med allsidig erfaring fra C#.NET og Javascript med både Angular og React. Han har jobbet som .NET-utvikler i ulike prosjekter hos Gjensidige Forsikring og samtidig opparbeidet seg erfaring på front-end-utvikling og agil arbeidsmetodikk. Det siste prosjektet han jobbet på var en webapplikasjon for fornyelser av forsikringer hos Gjensidige. Applikasjonen fjernet behovet for manuell innhenting av kundedata og førte til store tidsbesparelser for de ansatte i divisjon Næringsliv.

Alexander Kingdon

Anders har spisskompetanse på Java, Kotlin og Kafka. Han har tung erfaring med komplekse systemer og fungerer utmerket i agile team og trives godt med forvaltning samt nyutvikling av applikasjoner.

Han er opptatt av å utvikle kode som enkelt kan overvåkes. Anders har stor interesse for å automatisere hverdagen til utviklingsteamet og organisasjonen ved å utvikle enkle og robuste løsninger (CI/CD).

I prosjekt er han opptatt av å skape entusiasme og god fremdrift. Anders er en humørspreder og utpreget lagspiller som byr på seg selv. Anders er opptatt av de små detaljene samtidig som han ser også det store bildet.

Anders har en master i Kybernetikk og Robotikk fra NTNU.

Anders Brevik

Anders har en bachelorgrad som dataingeniør fra Høgskolen i Bergen, og master i programvareutvikling fra Universitetet i Bergen og Høgskulen på Vestlandet. Har har for det meste jobbet som backend-utvikler med Java og Kotlin, og har erfaring både med nyutvikling ved bruk av moderne skyteknologi, og vedlikehold og modernisering av legacy-applikasjoner.

Anders Flemmen

Anders Ranvik er frontend-utvikler og Technical Account Manager med kompetanse i React, JavaScript og TypeScript, samt Node i backend. Han er ekspert i å utvikle felles frontend komponent-biblioteker. Han har sin bransjeerfaring fra SpareBank1, Handelsbanken, Finansavisen, Sbanken, Norne, E24 og Schibsted. Anders har god kompetanse og erfaring med å portere over eldre legacy webløsninger over til ny selvstendige arkitekturer. Med dette har han mange ganger forankret og utviklet ny felles frontend komponent-biblioteker fra bunnen av, slik at teamene får raskere fremtidige leveranser (ci/cd) ved bruk av frontend-biblioteket. Anders er nøye med testing og har god erfaring med Enhet, Komponent, Ytelse og Ende-til-ende testing, skriver ofte testene først (TDD). Han er også opptatt av at applikasjonene får en helhetlig preg og at applikasjonene inkluderer alle i samfunnet med god brukeropplevelse ved å følge WCAG retningslinjene for Universell Utforming. Anders har i alle sine prosjekter arbeidet etter smidig metodikk i tverrfaglig miljø. Han kan også arbeide selvstendig og er opptatt av delingskultur. Han er kjent for å ha høy arbeidskapasitet og gode evner til å arbeide med parallelle prosesser. Anders er utdannet i Informatikk ved Høgskolen i Oslo og Akershus

Anders Ranvik

Anders er en dyktig og engasjert fullstack-utvikler med spisskompetanse på .NET, .NET Core og Azure. Han trives i hele stacken og bidrar med alt fra backend og oppsett av Azure DevOps til frontendutvikling på digitale flater.

I tillegg har Anders erfaring med JavaScript, Angular, ASP.NET, Xamarin og kryssplatform utvikling på digitale flater noe som gjør at han har god oversikt over hva som kreves for å levere en god brukeropplevelse.

Anders trives godt i team, han er ikke redd for utfordringer og liker å bidra til at prosjektet har god fremdrift. Han er en sosial person og er ikke fremmed for å dele av sin kunnskap til resten av teamet.

Anders Rommetvedt Malmo

Andreas Børhaug er backendutvikler med kompetanse i Java og Spring Boot. Han har også god kontroll på ulike meldingskøer Kafka, ActiveMQ/JMS eller Camunda samt Elasticsearch. Han har god erfaring ved å bryte ned monolitter inn i mindre selvstendige mikrotjenester med Rest API via JSON. Dette har ført til at Andreas har fått god kunnskap om kontinuerlig integrasjoner og leveranser (CI/CD) for utvikling, monitorering og vedlikehold ved bruk av teknologier som OpenShift, SonarQube, Nexus, Jenkins, RedHat og Docker. I alle prosjektene til Andreas har han utvikling i et smidig team ved bruk av kanban. Andreas har en M.Sc. i Ingeniørvitenskap & IKT ved NTNU Trondheim med spesialisering innenfor IKT & Produktutvikling.

Andreas Børhaug

Andreas Hanssveen er en seniorutvikler med erfaring fra utvikling, spesifikasjon, design, produksjonsettinger og drift. I hele sitt arbeidsliv har han jobbet med problemløsning, både fra oppveksten på gård, fagbrev som Automatiker og som utvikler. Han har erfaring med små og større team, og har god kompentase fra integrasjoner med store datasett, hvor ytelse er viktig. Andreas er god til å løse problemer og liker en utfordring. Som person er han positiv, løsningsorientert, inkluderende og opptatt av å styrke teamet han er del av. Han har blitt omtalt som et sosialt bindeledd og er en motivator i teamet. Han har sin styrke i backend C#.NET, men har også erfaring fra frontend teknologier som JavaScript og TypeScript. Han er interessert i mikrotjenester og har erfaring med å jobbe mot REST APIer. Andreas har en bred forståelse for IT, er god til å lese mennesker og setter seg raskt inn i kunders behov og problemstillinger.


Andreas Hanssveen

Andreas er en dyktig backend-utvikler, som også har god erfaring med frontend-utvikling. Han brenner for å lage gode løsninger sammen med kunden, slik at et godt sluttresultat oppnås. Andreas er opptatt av at koden som leveres skal være lesbar, samt at den enkelt skal kunne forvaltes og videreutvikles.

Gjennom hans tid som utvikler har han fått erfaring med mange forskjellige teknologier, og han holder seg alltid oppdatert på det som skjer innenfor hans fagfelt. I prosjekter har Andreas fått erfaring med vedlikehold og videreutvikling av eldre kodebaser, men han har også jobbet med det siste tilgjengelige innen teknologi, og har god kompetanse på skyløsningene til MS Azure. 

Andreas Lilleskare

André er en strukturert og erfaren systemutvikler med spisskompetanse innen React, AngularJS, .NET stacken, MSSQL og MySQL. André har bred erfaring med både frontend og backend utvikling og er komfortabel i rollen som fullstack utvikler. Han har holdt på med programmering siden barneskolen, og med hans over 15 år lange arbeidserfaring styrker han ethvert utviklingsteam på flere nivå. André har alltid hatt fokus på kundedialog i de rollene han har hatt. Han deler gjerne av sin kunnskap for å løfte teamets generelle kunnskap, samt at han bistår gjerne dersom noen skulle møte utfordringer. André har erfaring fra flere bransjer, blant annet fra olje- og gass industrien. Her var han blant annet involvert i planlegging og utvikling av AVEVA sitt nye flaggskipprodukt for håndtering av operasjonell risiko ved utføring av arbeidsordrer - AVEVA Control of Work- og Safe Job Analysis-løsning. Denne løsningen ble utviklet i Microsoft Visual Studio / C# i back-end og AngularJS-rammeverket for front-end.

André Nordstrand

André har god kompetanse innen Data science med Python og R. Han har god erfaring med å delta og drive prosjekter fra start til slutt, fra analyse og utforming av kravspesifikasjon til implementasjon av ferdig produkt.I tillegg har André solid kompetanse som systemutvikler, med spisskompetanse på Java.

André har stor interesse og erfaring innen dataanalyse og maskinlæring, og benytte både ustrukturert og strukturert data for å finne bruksmønstre i dataen. Han benytter gjerne data til å trene opp modeller for å gjøre diverse prediksjoner (tekstanalyse,anbefalingsmodeller, etc.)

André Orten

Anita Ilieva er frontend-utvikler med kompetanse i React, TypeScript og JavaScript, samt Node, Express, Java Spring Boot i backend. Hun har god kompetanse med ulike SQL teknologier som Oracle/PLSQL, Postgresql og Mssql. Hun har sin bransjeerfaring fra Sparebank 1, Ikano Bank, Ruter, Brønnøysundregistrene og Oslo universitetssykehus. Anita har flere ganger utviklet og forvaltet felles frontend design komponentbibliotek. Hun har solid erfaring ved å skape en god brukeropplevelse og er opptatt av å utvikle applikasjoner som inkluderer alle i samfunnet. Hun er sertifisert i Universell Utforming og Sikkerhet. Anita har mange ganger lagt arkitekturen for rest mikrotjenester, med større integrasjoner mot tredjepart og CMS-systemer. Hun er opptatt av testdrevet utvikling (TDD) og skriver alltid testene først. Hun er kvalitetsbevisst og har flere ganger fått roller som leveranseansvarlig til produksjon i ulike samfunnskritiske aktører. Anita har i alle sine prosjekter arbeidet etter smidig metodikk og synes at de beste løsningene løses sammen i et tverrfaglig team. Hun deler gjerne sin kompetanse, og trives med delingskultur. Anita er utdannet i Informasjonsteknologi ved Westerdals Oslo ACT (NITH).

Anita Ilieva

Arild er en allsidig systemutvikler som også kan påta seg både frontend og backend-roller. Han har arbeidet i virksomhetskritiske prosjekter innen lotteri- og spillvirksomhet, eiendomsmegling og i det offentlige, han har utviklet applikasjoner som har over 500 000 unike brukere ukentlig og som omsetter for 38 milliarder kroner årlig.

Arild behersker teknologier som react, redux, nodejs, kotlin, java og databaser. Med en tilleggs bachelor i UX vet han godt hvordan man skal utvikle i henhold til etablertestandarder for universell utforming og design.

Arild behersker alle faser i systemutvikling, fra spesifisering av krav, analyse/design, utvikling til testing og videreutvikling/forvaltning. Han er meget strukturert, engasjert og selvstendig. Arild får stadig gode tilbakemeldinger på sitt arbeid og som person frakunden.

Som konsulent er Arild opptatt av å holde seg faglig oppdatert, dette praktiserer han ved å bruke fritiden sin på hobbyprosjekter og generelle egenstudier.

Arild Birkeland

Arisa er en fullstack-utvikler med kompetanse i react Arisa er utdannet dataingeniør ved Høgskulen på Vestlandet i Bergen. Hun har gjennom studiet opparbeidet seg et bredt kunnskapsgrunnlag med fag innen programvareutvikling, datastrukturer, databaser og maskinlæring. Arisa begynte å arbeide som programvareutvikler høsten 2020 og har siden tilegnet seg variert erfaring innen design, frontend- og backend-utvikling. Som utvikler arbeider Arisa målrettet og effektivt. Hun er opptatt av å skrive robust og lesbar kode, og engasjere gjerne kollegaer til diskusjon om tilnærminger og løsningsforslag. Arisa er opptatt av å utvikle et verdiskapende produkt som tilfredsstiller sluttbrukernes behov. Med ekstra fokus på kommunikasjon, brukeropplevelser, ytelse og gjenbrukbar kode går hun i møte med nye teknologier og problemstillinger som måtte møte henne. Arisa har to års arbeidserfaring som konsulent, og har deltatt i prosjekter i ulike bransjer. Prosjektene hun har deltatt i har gitt henne muligheten til å arbeide med mange ulike teknologier og brukere. Det er viktig for Arisa å forstå brukernes behov og helhetsbildet av prosjektet hun deltar i. 

Arisa Seljestokken

Arne Daniel Iselvmo Bjerk er frontend-utvikler med spisskompetanse i React, Angular, TypeScript, JavaScript og NgRx. Han har god erfaring med å utvikle frontend-komponenter for å ivareta WCAG-prinsippene og universell utforming. Arne har også erfaring med backend-utvikling ved bruk av Java, Spring og ulike SQL teknologier. Arne har sin bransjeerfaring fra Tietoevry. Arne har flere ganger vært med på å utvikle applikasjoner som har utviklet seg fra idé til forvaltning. Han har derfor god erfaring med å forholde seg til økende kompleksitet ved ulike arkitekturer og API'er som Rest, mikrotjenester og webservices. Arne har god forståelse av feilhåndtering og er derfor opptatt av god og riktig testdekning. Arne har i alle sine prosjekter utviklet i tverrfaglige, smidige team. Arne har en bachelorgrad i informatikk fra Universitetet i Sørøst-Norge.

Arne Daniel Iselvmo Bjerk

Arnfinn er en engasjert systemutvikler som brenner for teknologi og kode. Han har erfaring både innen frontend og backend, med en klar tyngde på backend. Arnfinn har hatt flere ansvarsområder, men den siste tiden har han jobbet primært som utvikler og Scrum-master. I prosjekter har han jobbet med Java og Javascript samt vært innom Swift. Arnfinn oppleves av sine kolleger som engasjert, teknisk dyktig, hyggelig og behjelpelig.

Hos Distribution Innovation jobbet Arnfinn som utvikler i et funksjonelt team. Her jobbet han med kart og ruteoptimalisering og dette prosjektet brukte Java 11, Docker, AWS og andre spennende teknologier.

Arnfinn har tidligere erfaring fra Møller Mobility Group, hvor han jobbet på flere prosjekter. Han har jobbet i alt fra små prosjekter med et par utviklere, til mange års-prosjekter med rundt ti utviklere. Han har vært med i prosjekter fra en tidlig fase og hatt en sentral rolle også i den tekniske arkitekturen og spesifikasjonsfasen. Han har erfaring fra å jobbe med store legacy systemer, men også nyutviklingsprosjekter med moderne teknologier. Han har også her jobbet som Scrum-master.

I prosjektet «Just in time» jobbet han med å forbedre deleflyten på lagrene til Møller. Der laget de integrasjoner på tvers av mange interne legacy systemer og eksterne lager- og bestillings-systemer. I tillegg laget man en frontend-applikasjon for varemottak. Systemet ble laget i Java 8, med Spring Boot. Apache Kafka, i tillegg til REST, ble brukt for kommunikasjon. Frontend ble laget i React.

Arnfinn er en god prosjektdeltaker som fungerer godt i grupper. Han tar tak i utfordringer som oppstår og sørger for at prosjektet kommer seg i mål.

Arnfinn Gjørvad

Asim er en fullstack utvikler med fokus på C#, .NET i backend og Angular, Typescript i frontend. Han har erfaring med forskjellige tjenester på Azure platformen, blant annet har han gjennom prosjekt erfaring med Azure Kubernetes Service (AKS). Asim har sin bransjeerfaring fra både offentlig og privat sektor i prosjekter hos KS Kommunesektorens Org og Norconsult Informasjonssystemer AS. Gjennom tidligere prosjekter har han fått erfaring i å utvikle etter Domain Driven Design, samt å jobbe med CI/CD pipelines i Azure DevOps. Gjennom arbeid med .NET 5 Web API i backend har han erfaring med å lage REST API-er. Asim har i prosjekt utviklet i Angular11 hvor han har jobbet med Material UI komponenter, samt utvikling av egne gjenbrukbare komponenter. I prosjektene Asim har jobbet tidligere har det vært smidige team med Scrum som metodikk. Asim har en master i Datateknologi ved NTNU Trondheim.

Asim Abazi

Asle begynte å jobbe i Bouvet i januar 2019. Parallelt fullførte han sin bachelorgrad i data ved UiS.Han startet som utvikler med webapplikasjonen Spekter, hvor han jobbet med hele stacken som inkluderer Postgres, React m/ Typescript, Redux og Node/Express. Asle har hatt hovedansvaret for utvikling og forvaltning av Spekter. I denne rollen har han hatt et overordnet teknisk ansvar. Det innebar blant annet et ansvar for kvalitet gjennom codereviews, og at koden testes tilstrekkelig før den blir satt ut i produksjon. I desember 2019 gikk Asle inn i et nytt team hos Lyse. De har hatt ansvar for å forvalte og videreutvikle [lyse.no](http://lyse.no/). I Lyse teamet har det vært mye fokus på at alle skal ha en forståelse av alle delene av applikasjonen, å følge standarder og ha god kvalitet på code reviews. Asle har et variert sett med arbeidsoppgaver, men har sitt hovedfokus på frontend med React, Typescript og Next JS, samt utvikling av CMS'et Sanity.

Asle Berge

Audun er en frontend- og web-utvikler med genuin interesse for å levere løsninger som fungerer og er tilgjengelige for alle. Han har et utpreget fokus på brukervennlige løsninger. I tidligere prosjekter har han jobbet aktivt sammen med designere, prosjektledere og utviklere for å heve kunnskap om universell utforming. Med hans bakgrunn er han flink til å samarbeide med flere forskjellige roller, se helhetlige løsninger, samt tenke på sluttbrukers opplevelse av løsningen.

Han har den siste tiden jobbet mye med React og Vue, samt Redux og Vuex for å organisere data. Audun fikk hos SpareBank1 en sentral rolle i utforming av prosesser rundt implementering av god brukervennlighet. Her holdt han presentasjoner for utviklere for å øke kunnskapen rundt universell utforming og semantisk HTML for de andre utviklerne.

For VG satt han brukervennlighet på agendaen for hele utvikleravdelingen, prosjektlederavdeling og testere. Ved å holde workshops og presentasjoner for utviklere og prosjektledere fikk han ansvaret for å sjekke all HTML som ble levert i prosjektet for god semantikk. Koden som ble levert hadde enhetstester Mocha og integrasjonstester som kjørte på Browser Stack.

Som person er Audun en omgjengelig problemløser som trives med teamarbeid.

I prosjekter har han et pågangsmot som effektivt sørger for god fremdrift.

Audun Skjelvan

Audun Skjervold har jobbet som konsulent siden 2015, og har utviklet seg til en meget dyktig konsulent innen Vue.js, React og på .NET-plattformen. Den siste tiden har Audun jobbet med fokus på webutvikling hos Nordea Direct. Her har rollen vært front-end-utvikler på deres prosjekt med å skape verdens beste boliglånsplattform. Han har tidligere vært i prosjekt hos PayEx, hvor han som tech lead hadde hovedansvar for å løfte deres kortadministrasjonsløsning over på en moderne Vue.js front-end med en .NET Core back-end. Han har også erfaring med utvikling i AngularJS og KnockoutJS på front-end og Scala på back-end gjennom prosjekter hos Gyldendal og Oslo kommune, og har erfaring med automatisering av manuelle prosesser og opplæring av nyansatte.

Som person er Audun nysgjerrig og løsningsorientert og han liker å utforske nye teknologier. Han er svært interessert i brukerinteraksjon og brenner for kodekvalitet. Han jobber godt i team og er ikke redd for å ta ansvar der han ser det trengs. Han er alltid vennlig og imøtekommende, og tar imot utfordringer med et smil.

Audun Skjervold

Audun er en allsidig designer med 14 års erfaring. Han er nysgjerrig og energisk. Han er flink til å kommunisere med forskjellige typer mennesker og elsker å lære om og sette seg inn i nye fagområder. Audun har både dybde- og breddekompetanse innen innhenting av brukerinnsikt, testing og utvikling av prototyper. I flere prosjekter har han vært ansvarlig for flere designdisipliner. Som interaksjonsdesign, tjenestedesign og grafisk design. Audun har jobbet med prosjekter i både kommunal og privat sektor. I bransjer som spenner fra Olje og Gass, Telecom, Forsvar, Helse, Kommune og Stat til Bank og Finans. Han har jobbet med alt fra å utvikle og validere konsepter til å fornye eksisterende løsninger. I tillegg til de vanlige “designoppgavene” som å fasilitere workshops, foreta intervjuer og lage brukerreiser, skisser og prototyper har han også jobbet tett med forretningsutviklere. Han holder et høyt kompetansenivå på relevant programvare, og liker på holde seg oppdatert på nye verktøy.

Audun Skjevling Bratrud

Beate er prosjektleder med over 15 års erfaring. Hun har ledet en rekke digitale prosjekter fra start til slutt innen ulike bransjer, både offentlig og privat. 
Beate er en tydelig og stødig leder som evner å se helheten og skaper god samhandling og kommunikasjon på tvers av team og organisasjoner. 
Hun er sertifisert Agile Coach, Scrum Master og Scrum Product Owner og jobber med smidig gjennomføring i alle prosjekt hun leverer. 
Tidligere har Beate jobbet som webdesigner og webmaster, og har blant annet utdanning innen Produksjonsledelse, Multimedia og Bedriftsøkonomisk Analyse.

Beate Helene Thunes 

Bendik er opptatt av å benytte den teknologien som gir riktig gevinst for en organisasjon og applikasjon(er). Med dette som tilnærming har han opparbeidet seg en bred kompetanse med ulike verktøy, rammeverk og programmeringsspråk samt kan utføre oppgaver i alle arkitektoniske lag. Bendik er også Scrum sertifisert.

Bendik har spisskompetanse på backend-utvikling, både offentlige samfunnskritiske systemer så vel som store avanserte private distribuerte systemer. Utdannelsen har trent Bendik på å bryte ned og forstå komplekse problemer ved hjelp av matematikk, datasimuleringer og numeriske modeller.

Bendik er kjent for å være avbalansert og med gode kommunikasjonsferdigheter. Han er informasjonssøkende og alltid en lagspiller.

Bendik er utdannet som Sivilingeniør, innenfor Marin Teknikk ved NTNU.

Bendik Stavelin

Benjamin er erfaren utvikler som mestrer alle arkitektoniske lag i en applikasjon. Han er opptatt av å utforme den koden som gir mest verdi for det agile teamet og organisasjonen i sin helhet. Benjamin har 8 års erfaring med store java API integrasjoner og frontend utvikling i offentlig sektor.

I siste prosjekt hos Landbruksdirektoratet (LDIR) hadde Benjamin rollen som techlead. Typisk teknologi er typescript React/Redux mot mikrotjeneste REST api Java Spring Boot via JSON. (Microservices)

Samspillet mellom teknologi, mennesker og organisasjon har gjort Benjamin opptatt av «clean code principles». Med fokus på «kost-nytte» skriver han alltid tester først (Test Driven Development), og er tilhenger av domene drevet arkitektur (Domain Driven Development).

Bygg og deploy står også sentralt, uten de rette verktøyene (f.eks maven, travis, sonar, github osv) er det svært utfordrende å opprettholde kodekvalitet over tid. I alle sine prosjekter har han vært med å sette opp og fasilitere disse verktøyene og retningslinjene.

Med sine pedagogiske egenskaper er han en konsulent som er opptatt av å dele sine kunnskaper med andre og bistår alltid kunden med å definere og prioritere oppgaver i riktig rekkefølge. Han er kjent for å være en pådriver med gode kommunikasjonsevner.

Benjamin trives i mindre og større agile teams, der metodikken Scrum med Kanban regler står sentralt. Benjamin er sertifisert Scrum Master.

Benjamin Johansson

Bjørge er en kreativ og erfaren UX Designer med stort engasjement for utvikling av brukervennlige og intuitive tjenester og produkter. I over 15 år har han hatt ledende roller innen design og forvaltning av produkter og tjenester av variert karakter. 

Bjørge er en engasjert og proaktiv ressurs gjennom hele verdikjeden til et produkt eller tjeneste, og har god erfaring med å arbeide etter tjenestedesignprinsipper. Med sine evner til å raskt sette seg inn i nye fagområder, identifisere den viktigste informasjonen og brukerbehovet, skaper han gode og helhetlige brukeropplevelser. Dette gjør ham til et verdifullt prosjektmedlem, både ved utforming av nye eller forbedring av eksisterende tjenester og produkter. Bjørge jobber selvstendig og har god leveransekapasitet, samtidig som han setter pris på å jobbe i team og ha tett dialog med både brukere, fagpersonell og utviklingsressurser. Han har variert erfaring fra ulike bransjer, blant annet fra arbeid med kunder som Semine, UiA/UiT, Skatteetaten, Phonero/Telia og Kongsberg Digital.

Bjørge Stølen

Bjørnar Holmvik

Bjørnar er fullstack-utvikler med kompetanse på Golang, C# og .NET i backend, samt React, Redux, Typescript, Vue og Angular i frontend. Han har også erfaring med utvikling av mobilapplikasjoner i Flutter og tjenester hostet på Google Cloud Platform og Kubernetes. Bjørnar har sin bransjeerfaring fra både offentlig og privat sektor gjennom prosjekter hos Barne-, ungdoms- og familiedirektoratet, KS og ulike startups. Bjørnar har gjennom tidligere prosjekt fått erfaring med React og Redux hvor også komponent-biblioteket Material UI ble brukt. Gjennom prosjekt hos Highered har han fått erfaring med utvikling av mikrotjenester i en Kubernetes-basert løsning. Han har erfaring med integrasjon mot eksterne systemer og biblioteker, .Net Core Entity Framework. Bjørnar har også jobbet med kontinuerlig integrasjon og kontinuerlig leveranse (CI/CD) ved bruk av Github Actions. Bjørnar har i tidligere prosjekter jobbet i smidige team med Scrum som metodikk, og han har dessuten hatt eneansvar for hele utviklingsprosjekter. Han er dermed vant med arbeid og ansvarsområder som omfatter hele tech-stacken. Bjørnar har en master i Datateknologi fra NTNU Trondheim.

Bjørnar Østtveit

Brian Dale

Bård Kristian Haaland-Sørensen er fullstack-utvikler med spisskompetanse i Kotlin, C#, Java, Spring Boot, samt React, TypeScript og JavaScript og ulike meldingskø-teknologier i backend. Han har også solid erfaring med ulike SQL teknologier som Oracle DB, MSSQL og MySQL. Bård Kristian har sin bransjeerfaring fra bank / finans og helsesektoren. Bård Kristian har flere ganger portert monolitter over til mindre selvstendige rest mikrotjenester. Han har også utviklet domene drevet arkitekturer som er integrert til forskjellige komplekse apier som BankID, Buypass, Banktjenester og ulike Helseregistre. Han har derfor god kompetanse med integrasjoner, transaksjoner og sikkerhet samt forstår verifisering-protokoller. Bård Kristian har i alle sine prosjekter utført smidig metodikk, og synes at det beste løsningene løses sammen i et tverrfaglige team. Bård Kristian deler gjerne sin kompetanse med sine teammedlemmer. Bård Kristian er utdannet ved Universitetet i Bergen.

Bård Kristian Haaland-Sørensen

Camilla er en produktiv, ryddig og resultatbevisst designer som liker kreative prosesser. Hun er veldig nøye med å opprettholde mappestrukturer og ha et generelt godt og ryddig overblikk over prossess og mål. Hun blir inspirert av å kommunisere historier og informasjon gjennom design.

Camilla har erfaring med smidig tilnærming til oppgaver og mener de beste resultatene oppstår i tverrfaglige samarbeid der teknologi møter design. Hun er alltid nøye med å ivareta og opprettholde selskapets og kundens visuelle profil, og liker godt å dra elementer videre inn i nye løsninger på tvers av kanaler. Camillas design for digitale flater etterlever kravene i WCAG 2.0 (UU) og hun har spesielt god innsikt i kravene som gjelder til farger og kontrast. Camilla er nøye med at produktet som leveres skal være helhetlig, gjennomtenkt og utstråle god brukeropplevelse. Hun har utarbeidet komponentbibliotek og site-maps, og hun følger opp implementering direkte med front-end utviklere. Hun har også kjennskap til Bootstrap, CSS, HTML5, Umbraco og Javascript. Camilla har også arbeidserfaring fra salg- og servicebransjen og har blant annet utført behovsanalyser, administrative oppgaver, gjort kundeoppfølging ogutviklet en god forståelse for tilpasning av design til sluttbrukers behov og ønsker.

Camilla Tallarico

Carl Otto Steen er en fullstack utvikler med kjernekompetanse innenfor Java Spring Boot i backend og Angular i frontend. Han har også erfaring med Azure skyteknologi, og hans mastergrad med spesialisering i Databaser og søk gjør han særdeles kompetent innenfor databaseteknologier. 

Carl Otto har erfaring med utvikling av komplekse systemer med høye krav til sikkerhet, blant annet gjennom prosjekter for FHI og NorgesGruppen. Carl Otto har ved flere anledninger arbeidet med nyutvikling, oppgradering og forvaltning, samt migrert løsninger fra on-prem til sky. 

Han er opptatt av å følge SOLID-prinsippene og Clean Code, og brenner for å skrive testbar kode. Carl Otto er vant med smidig arbeid i tverrfaglige team, og har god erfaring med testdrevet utvikling (TDD). Han trives med ansvar i prosjekt, og har flere ganger vært med på løsningsutforming og tatt designavgjørelser i prosjektene han har vært en del av. Carl Otto er utdannet sivilingeniør fra NTNU, med spesialisering innen databaser og søk. 

Carl Otto Steen

Cecilia er utdannet Master of Science i Kommunikasjonsteknologi fra Norges teknisk-naturvitenskapelige universitet (NTNU) med spesialisering innenfor informasjonssikkerhet. Hun har kjennskap til flere moderne frontend og backend teknologier, og er opptatt av sikker, oversiktlig og logisk kode.

Hun trives i dynamiske miljøer og med utfordrende oppgaver. Gjennom en lederutdanning på befalsskolen i Forsvaret har hun tilegnet seg evnen til å være svært løsningsorientert og tilpasningsdyktig.

På fritiden deltar Cecilia på ulike kurs for å bli bedre kjent med nye teknologier, som Kotlin og Firestore. Hun er faglig nysgjerrig og har stor interesse for bredden i teknologi.

Cecilia Peinert

Christel Renée Bjerkreim

Christian er en dyktig og løsningsorientert frontend utvikler med nærmere 3 års arbeidserfaring, som også har erfaring med backend. Hans hovedkompetanse er JavaScript, Typescript, React, C#, .Net Core, Less, Durendal og Knockout.js.

Christian har fullført en bachelorgrad i IT og Informasjonssystemer ved Universitetet i Agder, og har igjennom studiet blitt kjent med Java og Python. Under studiene drev han sitt eget enkeltmannsforetak hvor han jobbet med grafisk design og utvikling av nettsider for mindre bedrifter. Blant annet utviklet han hele applikasjonen av et dekkhotell hvor han brukte Java med MySQL database og JavaFX som brukergrensesnitt.

Personlig har Christian en rolig og hyggelig væremåte. Han liker å sette seg inn i nye teknologier og holder seg oppdatert med ulike hobbyprosjekter. Christian trives med å få ansvar og dele kompetanse med andre. Han har blant annet vært ansvarlig for oppfølging av nye juniorutviklere, og var også hjelpelærer i ulike fag ved UIA. 

Christian Moen

Christian er fullstackutvikler som behersker alle arkitektoniske lag. Hans spisskompetanse er frontend og testing med teknologiene React, RxJs og Node. Hans lidenskap er å utvikle ren og skalerbar kode som er enkel å vedlikeholde, teste samt utvide med ny funksjonalitet.

Christian er opptatt av semantisk html slik at universell utforming blir ivaretatt. For å bevare riktig tidsriktig arkitektur er det viktig å utforme domene drevet arkitektur via Rest API.

Christian har også god kompetanse og kapasitet til å lede et eller flere agile kryssfunksjonelle team samtidig som han selv er utvikler. Christian er veldig engasjert i sitt fag og brenner for teknologi og smidig metodikk. Han har bred erfaring med private og offentlige aktører som hver sitt innehar samfunnskritiske systemer samt komplekse domener rundt dette

Christian er utdannet ved Universitetet i Sør-Øst Norge (USN)

Christian Svenkerud

Christian er en erfaren fullstack systemutvikler som har fokus på å oppfylle sluttbrukerens behov. Hans hovedkompetanse er Angular, JavaScript, Typescript, C#, .Net Core, Azure, og Web Security. Christian har tilegnet seg en dyp forståelse og et bredt spekter innen informasjonssikkerhet, og tar med seg denne kompetansen inn i et hvert systemutviklingsprosjekt. Hans lidenskap for cybersikkerhet og hans inderlige interesse for programvareutvikling gir ham enorm innsikt i å finne sårbarheter i nett- og stasjonære applikasjoner.

Gjennom flere prosjekter har Christian fått erfaring med webutvikling og end-to-end-systemer for frivillige organisasjoner i tillegg til veletablerte kunder. Mens han jobbet som utvikler fikk han erfaring med bruk av Git og smidig utvikling SCRUM. I tillegg har Christian jobbet som driftstekniker i telekombransjen, noe som har gitt ham en rik erfaring innen kundekommunikasjon og feilsøking av et stort offshore telekommunikasjonsnett.

Christian Sørseth

Christopher er fullstack-utvikler med kjernekompetanse innen java, mikrotjenester og test automatisering. Han har bred erfaring i å utvikle og forvalte samfunnskritiske applikasjoner samt anerkjente streamningstjenester.

For å ivareta god testdekning og kvalitet i det fleste ledd er han opptatt av å automatisere test-pipelinen slik at det smidige autonome teamet oppnår best mulig kontinuerlig integrasjoner og leveranser.

Han er kjent for å være kreativ og løsningsorientert person som alltid ser helheten. Han holder seg faglig oppdatert ved å lese på teknologi på fritiden samt dele sin kunnskap med sine kollegaer, gjenre i form av fagkveld med presentasjon.

Christopher Olsen

Colin har mer enn 27 års erfaring med digital produktutvikling, innovasjon, design og ledelse. Sterk på analyse, idé og konseptutvikling med fokus på UX/UI og tjenestedesign. Han har god teknisk forståelse og jobber svært godt med utviklere, prosjektledere og prosjekteiere, særlig i forhold til håndtering av logistiske utfordringer innen det digitale fagfelt. Som en mangeårig designer har han jobbet innen et bredt spekter av oppdrag, men trives aller best når han kan fordype seg i komplekse utfordringer der mennesker og teknologi forenes til innovative løsninger. Colin er svært opptatt av tverrfaglig samarbeid og ser høy verdi av at prosjektteamene har et rikt mangfold av kompetanse. 

Colin McMahon

Daniel er fullstack utvikler og har den siste tiden jobbet som javautvikler hos Toyota Norge. Der arbeider han med "Kaikaku-prosjektet" som omhandler en radikal endring av hele deres kodebase. Det jobbes med å bygge apper RESTful APIer dokumentert med Swagger, oppsett av moduler med Maven og bygging av applikasjoner med Spring. Daniel har tidligere erfaring som utvikler i mindre team hvor han jobbet på tvers av stacken og på flere plattformer. Han har jobbet med å utvikle kjernestrukturen i C#, webløsninger og API i .NET Core, mobilapper med Xamarin, samt databaser i MongoDB og Entity Framework. I tillegg har Daniel fått god erfaring gjennom utviklingsverktøyet Azure DevOps. Prosjektene har også inneholdt diverse .NET teknologier, hovedsakelig .NET Core. Som person er Daniel en omgjengelig problemløser og setter seg raskt inn i ny kunnskap. Han viser stor nysgjerrighet og engasjement for nye idéer og teknologier.

Daniel Dutta

Daniel Engebretsen er fullstack utvikler som kan forvalte og ny-utvikle i alle arkitektoniske lag med frontendkompetanse i JavaScript og React samt backendkompetanse i Java, Kotlin, Node og ulike meldingskø teknologier skrevet i Kafka, ActiveMQ og RabbitMQ. Daniel er også god på cloud teknologier.

Daniel er opptatt av tidsriktig arkitektur samt kontinuerlig utvikling og leveranse, og som et ledd i dette bryter han alltid ned applikasjoner inn i mindre selvstendige java spring boot rest mikrotjenester ut i skyen. Videre er det viktig med testdrevet utvikling for å ivareta god testdekning, samt bruk av Docker, Kubernetes, Grafana og Kibana for monitorering, logging og bygg og deploy for å oppnå stabilitet for alle APIer og integrasjoner

Daniel er selvstendig og har tro på at de beste løsningene blir gjort i samarbeid med alle andre i ett tverfaglig autonomt smidig team. Daniel er opptatt av delingskultur.

På fritiden trives Daniel med å holde seg i form, samt holde seg faglig oppdatert.

Daniel Engebretsen

Daniel er en erfaren systemutvikler og applikasjonsdrifter med mange års erfaring innenulike plattformer og teknologier. Han har en bachelorgrad i informatikk og harspesialisert seg på utvikling og drift av applikasjoner basert på Java-plattformen, i tilleggtil å ha jobbet med teknologier basert på JavaScript. Han har arbeidet innenfor mangeulike bransjer som bank & finans, energi og transport. Daniel er en god problemløser somhar en analytisk tilnærming, og trives godt med oppgaver hvor han kan løse praktiskeproblemer for kundene. Han er stadig nysgjerrig på nye teknologier og lærer nye tingsvært raskt. Daniel har et rolig lynne og godt humør som gjør ham til en utmerketlagspiller. I tillegg har han en god evne til å arbeide selvstendig.

Daniel Viken

Dean Lozo er en allsidig konsulent og bidrar som utvikler, techlead, og arkitekt. I den siste tiden har hatt fått en stor interesse for skyteknologi, og spesielt AWS. Han ønsker å bruke skybasert løsninger for å levere bedre produkter, samt gjøre hverdagen bedre for kunden og deres brukere.

Dean er lidenskapelig opptatt av teknologi og relasjon mellom produkt og bruker. Dean innehar en evne til å se løsninger fremfor problemer. Han ser helheten av løsningene, fremfor å stå fast på små detaljer. Han trives veldig godt i rollen som konsulent, og får meget gode suksessmål fra tidligere kunder. Han kommuniserer godt og er flink til å sette seg inn i andres utfordringer.

Dean Lozo

Didrik er en fullstack-utvikler med hovedfokus på Kotlin og React. Han har også fått erfaring med DevOps og Cloud i form av Docker, Kubernetes, GCP og Amazon sin cloud. Han har sin bransjeerfaring fra Entur, Statens pensjonskasse, byggforalle.no og Direktoratet for forvaltning og IKT. Didrik har forvaltet, videreutviklet og utviklet flere selvstendige mikrotjenester. Når det kommer til teknologi er det JVM-stacken han er mest komfortabel med, der fokuset er på å lage REST-applikasjoner med Spring sammen med Java eller Kotlin. Didrik er proaktiv og trives med å jobbe i team, samt at han jobber godt selvstendig. Han har en interesse for personlig utvikling og kommunikasjon, og dette tar han med seg inn i prosjekter. Didrik har en master i Informatikk fra NTNU

Didrik Aalen Pemmer

Didrik er utdannet programvareutvikler ved Universitetet i Bergen, med spesialisering innen informasjonssystemer. Han er frontend-utvikler med hovedkompetanse innen Typescript, React og React Native. Han har deltatt i flere utviklingsteam, både som frontend- og app-utvikler. Gjennom sin rolle som utvikler har Didrik opparbeidet seg en sterk kjennskap til å arbeide tverrfaglig, sette seg inn i komplekse problemstillinger i domenetung sektorer og vist seg lærevillig på tvers av fagdisipliner og som en lagspiller som heier på de rundt seg. Han har god erfaring med både forvaltning, videreutvikling og nyutvikling. Tar stor stolthet i at teamet leverer bra og har et sterkt fokus på detaljer og kvalitet. Didrik er strukturert i arbeidet sitt og stiller høye krav til løsningene han lager. Han er en hardtarbeidende fagperson som tar utfordringer på strak arm og legger et stort engasjement i alle oppgavene han får. I tillegg til hans talent og faglige håndverk, har han en sosial tilstedeværelse og et humør som smitter.

Didrik Kvanvik

Egil Uggerud er frontend-utvikler med spisskompetanse i React. Han er ekspert med Universell utforming og brukervennlighet vedrørende WCAG standarden. Han har sin bransjeerfaring fra Utdanningsdirektoratet, Luftfartstilsynet, Forsvarets forskningsinstitutt og Norsk institutt for luftforskning. Egil har flere ganger utviklet og forankret Felles Frontend komponentbibliotek ved å strukturere arkitekturer ved bruk av JavaScript og CSS. Han har flere ganger portert over eldre legacy frontend rammeverk inn til ny arkitektur. Videre har disse blitt forvaltet og videreutviklet. Arkitekturen han har lagt til grunn har vært sømløst mot mikrotjenester Rest API eller CMS løsninger. Han er opptatt av å utvikle responsive løsninger som fungerer på de fleste digitale flater. Egil synes at det beste løsningene løses sammen i ett tverfaglig smidig team, men han trives også med selvstendig arbeid. Han er opptatt av delingskultur. Egil er utdannet i informatikk, interaksjonsdesign, spill og læringsteknologi ved NTNU