It sikkerhet har de siste årene vært et et tema med økt fokus og relevans. Når vi jobber med systemutvikling er det derfor viktig å håndtere tilgangsstyring på en sikker måte, med gode rammeverk og hjelpemidler. Autentisering (hvem er du) og Autorisering (hva har du lov til) er to aspekter som kan håndteres med Duende IdentityServer.


I 2020 gikk identityServer fra å hovedsakelig være et open source produkt, av Dominick Baier and Brock Allen, til å bli tilbudt som et mer komplett produkt fra Duende Software, og benyttes i dag av en rekke store og små it-selskaper.

For tilgangsstyring skiller vi gjerne mellom:

For bruker-til-system access har IdentityServer god støtte for flere typer innlogging. Dette kan for eksempel være brukernavn og passord, eller ved å integrere med IdPorten så brukere kan benytte BankId.
For maskin-til-maskin access gjør api'er kall til IdentityServer for å autentisere seg.

Når det gjørs et vellykket innlogging/autentiseringsforsøk til IdentityServer, blir det sendt et JWT bearerToken i response.

Hvis man vil se innholdet i et Bearer token kan man f.eks benytte 

 som har et grensesnitt for å se innholdet i bearertokens:


For enkelhetsskyld går vi videre med et forenklet eksempel:

Der token inneholder blant annet informasjon om:


= hvilke rettigheter får den som bruker tokenet


Dette gjør det mulig for å sikre apier med bruk av bearer tokens:

Dette vil si at api’et godtar tokens utstedt fra “

”

Og for å opprette en policy, som sier hvilke scopes man krever:

Disse policy’ene kan da benyttes for å sikre controller-endepunkter i API’ene med:

Dette vil resultere i at kall til endepunktet uten token, automatisk gir en 

, siden man ikke har sendt med noe token, og ikke er autentisert.

Kall med token, men som ikke har scope som behøves, vil gi en 

, siden man er autentisert, men ikke har rettigheter til å be om data fra endepunktet.

For å tilgjengeliggjøre at API’er kan hente ut sine egne tokens ved å kalle HTTP POST til connect/Token, må identityServeren konfigureres med tilhørende ClientId, ClientSecrets, og ApiScopes.
Dette kan enkelt gjøres i config, og IdentityServer har støtte for å benytte InMemory, eller for eksempel SqlServer med EF Core, for lagring av clients, scopes og secrets.


Dette medfører at API1 kan gjør HTTP POST til Connect/Token, for å motta Bearer Token, som vil ha Scope “

”

For å gjøre det enda enklere kan stegene med å hente Token fra IdentityServer gjøres automatisk, med en nugetpakke 



I Startup/Program.cs på API 1 kan man registrere en httpClient som automatisk henter og fornyer BearerToken for deg:


Og deretter benytte Client for å hente data fra WeatherApi

Denne typen flyt gjør tilgangsstyring veldig enkelt, sikkert og brukervennlig for utviklere, og vi kan sette opp kommunisering mellom en rekke systemer med tilgangsstyring.

Hvis dette virket interessant for deg, kan jeg på det sterkeste anbefale 

Tilgangsstyring, med Duende IdentityServer

<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*Ja-0F899xqTLKqLss_jr8g.png"></figure>Design systems are an essential aspect of modern web and software development. They help teams create consistent and cohesive user experiences across different platforms and devices. However, building a design system can be a challenging task, particularly when working with a small team. In this article, we will explore some of the challenges and solutions I’ve used when building a design system with a small team.
If you’d like an easy intro to understanding design systems, <a href="https://medium.com/dfind-consulting/creating-consistency-how-lego-can-help-us-build-better-design-systems-8de430df74d3">check out this article</a> where I explore the concepts and use a relatable analogy of LEGO to explain the building blocks of a successful design system.
So, what should you keep in mind? Here’s a little list I’ve prepared, based on my own experiences.
<figure><img alt="“If you wish to make apple pie from scratch, you must first invent the universe.” A quote by Carl Sagan. Image of the ingredients of an apple pie, in the style of Andy Warhol" src="https://cdn-images-1.medium.com/max/1024/1*Bvp-Gqp_n5wP2uoZsjnXlw.png"><figcaption>To make something great, you need to understand and know everything that goes into it, just like making an apple pie from scratch needs all the ingredients and a instructions on how to make it. Image by <a href="https://www.linkedin.com/in/henriknyqvist/">Henrik Nyqvist</a></figcaption></figure><h3>1. Don’t Reinvent the Wheel</h3>
<figure><img alt="1. Don’t reinvent the wheel. Image of a yellow wheel, in the style of Andy Warhol" src="https://cdn-images-1.medium.com/max/1024/1*oBKXg7J0EVqkt_kGo1UHKQ.png"><figcaption>Image by <a href="https://www.linkedin.com/in/henriknyqvist/">Henrik Nyqvist</a></figcaption></figure>As a designer, it’s easy to go down the long winding road of trying to innovate anything and everything you touch, at least that’s the case for me. And that’s pretty time consuming when trying to build a design system, given how many challenges you’ll need to conquer. So, it is important to remember that many of the design problems we encounter have already been solved by others. It’s essential to take inspiration and even steal ideas from existing design systems.
<figure><img alt="Image of the well-known quote “good artists copy, great artists steal” by Pablo Picasso, with an image of a banana replicating an album cover designed by Andy Warhol." src="https://cdn-images-1.medium.com/max/1024/1*3xkFshSf4TQapTECTPiPBw.png"><figcaption>Andy Warhol created a series of artworks inspired by existing commercial images and products, like the famous cover for The Velvet Underground depicting a banana. Image by <a href="https://www.linkedin.com/in/henriknyqvist/">Henrik Nyqvist</a></figcaption></figure>The well-known quote “good artists copy, great artists steal” by Pablo Picasso highlights the importance of taking inspiration from other sources and incorporating it into one’s own work. A good artist may simply copy the work of others, but a great artist takes inspiration from multiple sources and creates something new and unique.
So, take inspiration from other design systems, and save time building your own. Instead of starting from scratch, find out what already works, learn from the successes and failures of others, and adapt your findings to your own team’s specific needs and goals. (Something I wished I’d thought of before I started my first project)
<h3>2. Know Your Limits</h3>
<figure><img alt="Image of a woman with a measuring tape, in the style of Andy Warhol" src="https://cdn-images-1.medium.com/max/1024/1*XIXva4ExpIJzM-vbN1oq6Q.png"><figcaption>Image by <a href="https://www.linkedin.com/in/henriknyqvist/">Henrik Nyqvist</a></figcaption></figure>When working in a small team, be aware of the time constraints and the capacity of your team members. Building a design system is a long-term project and it’s not possible to do everything at once. Therefore, it’s important to start with the most critical elements of the design system, such as buttons, forms, colours or typography. So start small and prioritize low-hanging fruit.
It’s essential to identify who you need help from, and who is available to help you, whether it’s internal or external resources. This could be a developer, a designer, or an accessibility specialist. By bringing in new team members with different skills and perspectives, you can expand your resources and capabilities.
Some design systems also include code snippets and documentation, which is the ultimate goal, but also requires a lot of development time. Therefore, it may be wise to wait until the team becomes a bit larger before tackling the more complex components.
<h3>3. Find Out What Already Exists</h3>
<figure><img alt="Images of color schemes, typography and grids from Monio Design System" src="https://cdn-images-1.medium.com/max/1024/1*AhXPGrrIbpJpNqDI6_xDWw.png"><figcaption>Images from Monio Design System</figcaption></figure>Before starting to build a design system, it’s important to understand what already exists, what’s working well already and what’s not working and needs changing. A UI audit is a great way to do that, in which you evaluate the user interface of a website or application, identify issues and areas for improvement. This includes documenting existing styles, colours, typography, spacing, and other design elements. By conducting a UI audit, your team can identify what’s working well and what’s not, and make informed decisions about what to keep and what to change.
Ask a developer in your team with good knowledge of the code base and find all existing patterns, naming conventions, styles and components, and identify any inconsistencies. Involving technical resources early in the process can help build ownership of the project. They can also help to identify any technical constraints that need to be taken into account when building the design system.
<h3>4. Create Reusable Components</h3>
<figure><img alt="Images of buttons, checkboxes and input fields from Monio Design System" src="https://cdn-images-1.medium.com/max/1024/1*aytEZ2dMiFJMRbYbKvlU8w.png"><figcaption>Images from Monio Design System</figcaption></figure>A design system is a living project, it’s never “done”. Therefore, it’s essential to start with the basics and create reusable components that can be easily updated and maintained, which can save time and effort in the long run.
This could include designing a set of standardized buttons, forms, and other UI elements that can be used across different pages and platforms. This will not only save time in both the design and development processes, but also make it a lot easier to spot inconsistencies and maintain a uniform design language across all products and pages.
<h3>5. Be Organized</h3>
<figure><img alt="Images of custom Figma project covers from Monio Design System" src="https://cdn-images-1.medium.com/max/1024/1*6FQ0Xro68gpCmdW6XxKTCA.png"><figcaption>Small things like organizing design files in Figma by using custom covers that reflect the content and category can make it easier for others to find the right documents at the right time. Images from Monio Design System</figcaption></figure>It’s important to avoid “quick and dirty” solutions. While it may be tempting to take shortcuts and skip steps, in the long run, it’s more efficient to take the time to organize. This means establishing clear naming conventions, keeping design files and assets organized, and maintaining a consistent file structure across the design system. This can reduce communication errors and the need to go back and fix things later on, as well as reduce time looking for files.
Naming Conventions
Naming conventions are a critical aspect of organization and maintaining consistency in a design system. They help to standardize the names of design elements, such as buttons, forms, and other UI elements, across different pages and platforms.
Having a clear and consistent naming convention can improve the overall usability of the design system. It makes it easier for team members to understand the design elements and how they are used. It also makes it easier to update and maintain the design system in the future.
Read more about naming conventions in <a href="https://www.invisionapp.com/inside-design/naming-conventions/">this article</a> by InVision.
<h3>6. Be accessible</h3>
<figure><img alt="An image of a diverse group of people, to reinforce the idea that accessibility and inclusiveness in design benefits everyone, in the style of Andy Warhol, with the text “6. Be Accessible”." src="https://cdn-images-1.medium.com/max/1024/1*48nshEOhqWEtzhYqcYO4dg.png"><figcaption>Image by <a href="https://www.linkedin.com/in/henriknyqvist/">Henrik Nyqvist</a></figcaption></figure>Designing an accessible design system is crucial for creating inclusive and user-friendly products that cater to a wide range of users, including those with disabilities. Accessibility not only enhances the user experience but also provides a competitive advantage for businesses. According to the <a href="https://www.ssb.no/statbank/table/12760/">AKU survey</a> (Arbeidskraftundersøkelsen) conducted by the Norwegian SSB, the number of people with disabilities varies from year to year, and is between 15% and 18% of the population from 15 to 66 years old. In 2020, the proportion was 18%, which corresponds to approximately 636,000 people. People with disabilities face challenges in using technology such as difficulty lifting or grasping objects, cognitive or emotional impairments, vision or hearing impairments, and more.
Design systems help to streamline the process of creating accessible products by providing a baseline for accessibility. The baseline includes components such as colours, typography, spacing, and sizing, and helps to take decision-making away from designers so they can focus on the design itself. However, it is still necessary to conduct additional testing of the design system, interfaces, navigation, and user flows to ensure accessibility.
Testing tools can assist in evaluating the accessibility of design systems. Some essential tools are colour contrast checkers that evaluates UI components against WCAG standards for AA and AAA levels (if you use Figma — try out the <a href="https://www.figma.com/community/plugin/1149686177449921115/Use-Contrast">Use Contrast</a> or <a href="https://www.figma.com/community/plugin/733159460536249875/A11y---Color-Contrast-Checker">A11y</a> plugin) and a colour blindness simulator that allows designers to experience user interfaces from a colour blindness perspective. For MacOS users, you can use the <a href="https://support.apple.com/guide/mac-help/use-color-filters-mchl11ddd4b3/mac">built-in Colour Filters</a> under Accessibility settings which can be really helpful.
Implementing an accessible design system can be a time-consuming process, but it is essential to ensure that the final product is inclusive and usable by a wide range of users. You can make this task manageable by breaking it down into smaller, more manageable tasks and prioritizing the most critical elements first. For example, you could start by establishing clear accessibility guidelines and conducting an initial <a href="https://uxdesign.cc/getting-started-with-web-accessibility-testing-1c85c97f21b9">accessibility audit</a>. You could then focus on implementing the most important changes, such as ensuring that text has enough colour contrast, before moving on to more complex changes, such as improving keyboard navigation.
<h3>7. Test &amp; Validate</h3>
<figure><img alt="Image of a man looking at an iPad, in the style of Andy Warhol" src="https://cdn-images-1.medium.com/max/1024/1*rfrEanK_6X0gEDovrvNIQw.png"><figcaption>Image by <a href="https://www.linkedin.com/in/henriknyqvist/">Henrik Nyqvist</a></figcaption></figure>A design system is not complete until it has been thoroughly tested and validated by real users. This means conducting user research, usability testing, and gathering feedback from the team and stakeholders.
User research and usability testing can help to identify any issues or areas for improvement in the design system. This can be done by recruiting a small group of users to test the design system, and gather feedback on the usability and overall experience. This feedback can then be used to make adjustments to the design system, and ensure that it meets the needs of the users.
<h3>8. Monitor and Improve</h3>
<figure><img alt="Image of a man with glasses, a pencil and a drawing board, in the style of Andy Warhol." src="https://cdn-images-1.medium.com/max/1024/1*Hvp6I6U3oXYFw-Cn6uUG-A.png"><figcaption>Image by <a href="https://www.linkedin.com/in/henriknyqvist/">Henrik Nyqvist</a></figcaption></figure>A design system is a living project and it should be continuously monitored and improved over time. This means regularly reviewing and updating the design system, and keeping it aligned with the overall goals and objectives of the project.
It’s important to regularly review and update the design system to ensure that it remains relevant and effective over time. This includes monitoring the usage of the design system, gathering feedback from users and stakeholders, and keeping it aligned with the latest design trends and best practices, so that it remains relevant and effective over time.
<h3>TL;DR</h3>
<figure><img alt="Text saying “Too much to chew? Here’s the summary” with an image of a man with a huge sandwich in his hands that he can’t chew, in the style of Andy Warhol." src="https://cdn-images-1.medium.com/max/1024/1*AvPgEudpIPolSFS1PFrF1g.png"><figcaption>Image by <a href="https://www.linkedin.com/in/henriknyqvist/">Henrik Nyqvist</a></figcaption></figure>In conclusion, building a viable design system as a small team can be challenging, but it’s not impossible. By following a few key principles and best practices, even a small team can create a design system that is efficient, easy to use, and easy to maintain.
<ul>
<li>Don't reinvent the wheel — borrow, steal or get inspired by other design systems and solutions</li>
<li>Know your limits and prioritize resources</li>
<li>Find out what already exists and build on strengths and address weaknesses</li>
<li>Create reusable components and be organized</li>
<li>Use a step-by-step approach to successfully implement accessibility guidelines when you’re short on time and resources</li>
<li>Test and validate with real users</li>
<li>Continuously monitor and improve over time</li>
<li>Tailor the design system to the specific needs and goals of the team.</li>
</ul>
Sources
<ul>
<li><a href="https://www.ssb.no/statbank/table/12760/">https://www.ssb.no/statbank/table/12760/</a></li>
<li><a href="https://www.invisionapp.com/inside-design/naming-conventions/">https://www.invisionapp.com/inside-design/naming-conventions/</a></li>
<li><a href="https://www.uxpin.com/studio/blog/design-system-accessibility/#h-summary">https://www.uxpin.com/studio/blog/design-system-accessibility/#h-summary</a></li>
</ul>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=a4b36ed16b95" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/designing-efficiently-how-to-build-a-design-system-with-limited-resources-a4b36ed16b95">Designing Efficiently: How to Build a Design System with Limited Resources</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.

Designing Efficiently: How to Build a Design System with Limited Resources

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*EgsCn4V61NW3AYRs"><figcaption>Photo by <a href="https://unsplash.com/@marvelous?utm_source=medium&amp;utm_medium=referral">Marvin Meyer</a> on <a href="https://unsplash.com/?utm_source=medium&amp;utm_medium=referral">Unsplash</a></figcaption></figure>I hele min karriere har jeg vært opptatt av å skape et nært bånd mellom design og utvikling. Ofte jobber man i team mot de samme målene, og er avhengig av hverandre for å nå dem. Ved å ha et åpent og transparent arbeidsmiljø, vil man kunne lære en hel om og av andre, som alltid vil komme til nytte. I mine år som utvikler, har jeg opplevd og blitt kjent med mange ulike kunder, prosesser, team og mennesker. Om det noe viktig jeg har lært, så er det at samarbeid på tvers av fag, og tett kommunikasjon, er helt nødvendig når man jobber i tverrfaglige team.
Men hva syntes jeg har fungert bra og hva har fungert mindre bra? Og hva må til for at et team skal føle at de er på bølgelengde? Mine tanker rundt disse spørsmålene og noen egne erfaringer skriver jeg om i innlegget. Innholdet er like relevant for designere og utviklere, som ledere, forretning- og domeneekspeter.
<h3>Transparens og åpenhet</h3>
Et team som er transparent, er et team som kommuniserer åpent og ærlig om arbeidet og prosessene de har. Når man vet hva alle de andre i teamet ditt jobber med og hvilket ansvar de har, og samtidig vet at alle de andre har motivasjonen for å ville levere like bra som deg, og du vet hvem du kan snakke med om ulike problemstillinger, da vet du at teamet er på samme bølgelengde.
<h4>Èn av ni løsninger</h4>
I et møte hos en tidligere kunde ble jeg plutselig overrasket. Det jeg ble vitne til da, var to avdelinger som knapt kommuniserte med hverandre. La oss kalle dem for avdeling A og B — begge avdelingene var eid av samme selskap, A var bruker og B jobbet med utvikling. Avdeling A holdt et innlegg for avdeling B om hvordan de jobbet i sin avdelingen, og hvilke verktøy de brukte. De brukte èn av ni verktøy som avdeling B hadde laget for dem. De åtte gjenværende verktøyene løste ikke lengre de utfordringene som avdeling A hadde. Avdeling A forklarte hva som var problemet med de åtte verktøyene og hadde sjeldent noe positivt å si om dem. Den niende løsningene ble derimot sett på som det eneste brukbare, som fra Avdeling B sin side var et utdatert, usikkert og dårlig lagd system. Uten å ha kommunisert utfordringene tidligere, kjøpte og brukte avdeling A andre verktøy og løsninger, og la til side de som ikke ble brukt uten å si noe til Avdeling B. Vel uvitende jobbet avdeling B med optimalisering og forbedring av verktøyene som ikke ble brukt. Grunnen til at kun èn av ni løsninger ble benyttet var hovedsakelig mangelen på kommunikasjon mellom avdelingene. Ingen av partene var åpne om systemenes tilstand eller tok initiativ til å diskutere fremtidige behov og utfordringer. Ingen av partene var heller så interresert i hva den andre parten gjorde eller jobbet med, enda de satt vegg i vegg med hverandre.
Selv om historien over ikke handlet om det tverrfaglige teamet, er poenget det samme. Dersom man unngår å holde hverandre informert om utfordringer, kan lignende situasjoner oppstå. Man bør ikke komme til det punktet hvor man bare leter etter feil, før man forsøker å kommunisere eller løse de utfordringene man allerede har.
<h4>Synliggjøring</h4>
Åpenhet kommer tydelig frem når man synliggjør hvem som er ansvarlig for hva. Den personen som starter med en oppgave, er sannsynligvis den mest kompetente til å løse den i starten — mens andre kan bli mer kompetente på sikt. Synliggjøring av kompetanse og ansvar gjør at teamet blir bedre på å delegere arbeid og teammedlemmene vet hvem man kan spørre om hjelp for ulike problemstillinger. Samtidig bidrar synliggjøring til at informasjon ikke holdes skjult, men det er heller en strøm av ressurser og ideer som flyter mellom medlemmene. Synliggjøring er med på å skape tillit i teamet og styrker hvordan man samarbeider i sin helhet.
<h4>Oppsummering: Transparens og åpenhet</h4>
Jeg tror at team som er transparente har mindre utfordringer og at problemer løses raskere. Grunnen kan være at i transparente team, vil man jevnlig snakke om utfordringer, feil man har gjort og bekymringer. Medlemmene kjenner hverandres styrker og svakheter. Strømmen av informasjonen som flyter rundt i teamet gjør det tydelig hvem som har ulikt ansvar, oppgaver og kompetanse. Teammedlemmene har stor tillit til hverandre. De er ikke redd for å dele, få tilbakemeldinger eller motta kritikk, fordi teamet i utgangspunktet deler med hverandre. Dersom vi tørr å snakke om feilene vi gjør, vil vi unngå at andre gjør dem også. Vi må godta at andre kan gjøre feil, og gi dem ros når de deler erfaringene med oss.
<h3>Kunnskapsdeling</h3>
Kunnskap er ferskvare, mens erfaring får man jo mer man anvender kunnskap. Når man deler kunnskap, bidrar man til at andre kan utforske den samme kunnskapen og bygge mer erfaring. Deling er en kritisk forutsetning for personlig og andre sin utvikling. Noen ganger har vi behov for å få andres perspektiver, gjennom tilbakemeldinger, innspill og konstruktiv kritikk for å utvikle oss.
<h4>Deling mellom designere og utviklere</h4>
Det viktigste et tverrfaglig team gjør for å holde hverandre oppdatert, er å dele kunnskap. Team som jevnlig deler kunnskap vil kunne diskutere kompleksitet i mye større grad, på tvers av fagområder, enn team som ikke gjør det.
La oss ta for oss noen fordeler som utviklere og designere kan få ut av å dele kunnskap: Utviklere kan få bedre innsikt i hvordan designere arbeider og verktøyene de bruker. Man vil oppdage feil og mangler lettere. Man får bedre forståelse for informasjonsarkitektur, brukertesting, universiell utforming og kontraster, for å nevne noe. Dette gjør det mulig for utviklere å ta egne avgjørelser og gjøre endringer i grensesnittet uten å være avhengig av en designer til enhver tid. Designere kan få bedre innsikt i hvordan komponentene (samspillet mellom koden og designet) oppfører seg i brukergrensesnittet. Skisser og prototyper kan utvikles med dypere teknisk innsikt når man skal lage nye eller videreutvikle eksisterende løsninger. Designeren blir mer bevist på hvordan data prosesseres og flyter mellom systemene – fra backend via frontend til sluttbrukeren – og kan sammenligne kode og design.
Jo mer designere og utviklere vet om hverandres fagområder, desto bedre vil man kunne diskutere forandringer i utseende, tekniske utfordringer, prioriteringer, ytelse og testing m.m. Det vil være enklere å holde kode, design og dokumentasjon synkronisert. Designsystemer kan være svært nyttig til dokumentering, og er et fint verktøy for å samle, synkronisere, strukturere og organisere informasjon i èn felles platform (en såkalt «single source of truth»). Designere og utviklere som er synkroniserte tar bedre avgjørelser, alene og i fellesskap.
<h4>Oppsummering: Kunnskapsdeling</h4>
En ting jeg husker spesielt godt, fra et tidligere prosjekt, var da jeg og en designer gjorde par-programmering og par-design for å dele kunnskap. De gangene vi leste kode, forklarte jeg hvordan koden og elementene i grensesnittet — designet — hang sammen. Andre ganger satt vi i Figma og diskuterte hvilke tekniske utfordringer vi måtte tenke på når designet skulle utformes. Designeren inviterte meg stadig med på brukertesting for å observere hvordan brukerne opplevde å bruke applikasjonen i den stegvise utviklingen over seks uker. Det viste seg å ha stor verdi for løsningene vi lagde i ettertid. Personlig har det også vært en svært nyttig erfaring for løsninger jeg har bidratt med å lage i andre prosjekter. Når man lærer bort trenger det ikke alltid være noe nyttig, det viktigste er at man får noe ut av læringen. Lær bort det du vet kan være nyttig for andre. Det finnes utallige måter å dele kunnskap på og det kan skje i mange ulike forum. Whiteboard med notislapper, verktøy som Trello, Figma eller discussions i Github er noen eksempler.
<h3>Frihet og eierskap</h3>
I tiden vi lever i nå, hvor endringer skjer utrolig raskt, er bedrifter helt avhengig av å fornye seg for å henge med. Kreative prosesser, eierskap og frihet under ansvar er derfor nødvendig for at vi skal lykkes med å skape nye ideer og nyttige resultater.
<h4>Frihet under ansvar</h4>
Selskapene som fanger interressen til dagens designere og utviklere, er de som har og gir stor frihetsfølelse. Det er også de selskapene som gir rom for egne perspektiver, der det er høyt under taket og lite byråkratisk ledelsestruktur. Når man hele tiden blir fortalt hva man kan gjøre og hva man ikke kan gjøre, er det vanskelig å kunne være kreativ og bidra med sine beste ideer. Når man har fagkomptetente mennesker som jobber for seg, er det også snodig når en høyt oppe i systemet skal ta tekniske valg fordi de mener de har god magefølelse. Å gi de ansatte større frihet til å velge selv, når de skal jobbe, hvordan og hvor de skal jobbe — om de vil delta på kontoret eller i møter — vil det mest sannynlig resultere i lykkeligere ansatte. Det å stole på sine ansatte, og vite at de har kompetansen som trengs, er like viktig da de jo faktisk er profesjonelle på det de gjør. Der teamene har frihet under ansvar, kommer også lojalitet, produktivitet, fleksibilitet og effektivitet som et naturlig resultat.
<h4>Eierskap</h4>
At team tar eierskap for det man skaper, har sterk innvirkning på kvaliteten og arbeidsinnsatsen for sluttproduktet. For at teamet skal få følelsen av eierskap, må selskapene tørre å gi team og medlemmene ansvar. Ansvar betyr å gi teamet selvstendighet til å eie produktet ved å bestemme egne prosesser, metodikk, leveranser og teknologi. Med eierskap blir teamene mer selvdrevne og eksperter innenfor sitt domenet. Utviklerne og designerne kan fokusere på færre prosjekter, og de slipper å sjonglere mellom mange ulike domener, kontekster, prosesser og avhengigheter (møter, planlegging, standups) som ikke har noe med hverandre å gjøre. Eierskap gir mer trygghet, og dypere forståelse for det man jobber med, fordi man kan fokusere og bli ekspert på mindre deler av et prosjekt, domene, brukergruppe eller produkt.
<h4>Oppsummering: Frihet og eierskap</h4>
Jeg jobbet en gang i et team hvor en rekke utviklere og designere hadde fult eierskap til flere løsninger innenfor et bestemt domene. Dersom en avhengighet utenfor domenet måtte løses, ble et annet team koblet på for å løse avhengigheten i det respektive domenet — fordi det var deres ansvarsområdet og ekspertområde. Jeg jobbet også i et annet team for ikke så lenge siden – der jeg kom helt fersk inn i domenet og selskapet –, hvor alle utviklerne kunne plukke utviklingsoppgaver fra mange ulike domener. Det var ikke så nøye hvem som gjorde hva, men oppgavene skulle løses. Utfordringen med å jobbe på denne måten, var at ingen fikk spesiell kompetanse på noen av domenene. Samtidig kunne du jobbe med enten SvelteJS, NextJS, NodeJS eller ren ReactJS, CSS, SCSS, CSS Modules eller StyledComponents. Personlig har jeg hatt en god opplevelse når det kommer til Frihet under ansvar. Men jeg tror at de teamene som har ansvar for få prosjekter, har lettere for å ta et større eierskap fordi de kan gå i dybden og konsentrere seg om færre ting. For mye eierskap kan gjør at man ikke kjenner godt nok til et domene. Dersom man er innom mange oppgaver og prosesser samidig i ulike prosjekter, kan delegering av arbeid og ansvar fort føre til at man får mindre eierskap og oversikt for de enkelte prosjektene.
<h3>Individuell og kreativ tenking</h3>
Mange utviklingsteam jobber etter smidige prosesser som Scrum eller Lean. I smidige prosesser samles gjerne teamet en gang i blant for å snakke om ideer, progresjon, mål, oppgaver, ansvar og trivsel. Under samlingene, er målet som regel å arbeide og tenke som ett lag. Men, det kan også handle om å finne roller og styrker i teamet eller meningen med hvorfor du og teamet eksisterer.
<h4>Retrospektiv</h4>
Retrospektiv er en ganske vanlig teknikk som benyttes i smidige prosesser. Teamet refkleterer sammen om hva som har fungert bra, og hva man kan forbedre i utviklingssyklusen. Dette er ofte kalt sprinter. En gang jobbet jeg med et team bestående av utviklere, designere, testere, devops, prosesseier og produkteier. Teamet var opptatt av å få med alle sine meninger, for det var viktig at alle ble hørt. Hver og en av oss tok en bunke post-it lapper og tusj. Vi fikk ti minutter til å skrive ned tanker og ideer i stillhet. En og en fra teamet fikk så henge opp sine post-it lapper på veggen og snakke om hva den handlet om foran de andre. På denne måten fikk alle formidle sine tanker og ideer som ble delt med resten av teamet. Til slutt hadde vi avstemning. Hvert teammedlem fikk tre røde prikker som kunne klistres på de lappene man syntes burde diskuteres videre eller fortjente å være med videre til neste syklus.
<h4>Hvorfor?</h4>
Vet du meningen bak hvorfor akkurat du og teamet ditt eksisterer? Hvorfor dere skal løse de utfordringene dere er tildelt, og hvorfor du og dine egenskaper er viktig for å løse dem? Jeg husker godt da teamet mitt benyttet teknikker fra Simon Sinek’ <a href="https://www.amazon.com/gp/product/B005JZD3B4/ref=kinw_myk_ro_title">bok</a> og <a href="https://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action">TED foredrag</a>, <a href="https://www.amazon.com/gp/product/B005JZD3B4/ref=kinw_myk_ro_title">Start with Why</a>. Simon har laget en model han kaller “The Golden Circle”, der han snakker om hvordan store ledere verden over inspirerer til innovasjon og definerer suksess; svaret er å starte med “Why”:
<ul>
<li>”hvorfor eksisterer vi som team i denne virksomheten?”</li>
<li>“hvorfor er jeg i teamet og hva kan jeg bidra med?”</li>
<li>“hvorfor er vi viktig for virksomheten, brukerne eller kundene?”</li>
<li>“hvorfor eksisterer produktene våres?”</li>
<li>“hvorfor skal kundene bruke produktene vi lager?”</li>
</ul>
Modellen fokuserer på hvorfor, fremfor hva og hvordan.
<h4>Oppsummering: Individuell og kreativ tenking</h4>
Selv tror jeg, at når enkeltmenneske kan reflektere og tenkte individuelt, vil man få frem utrolig mange ulike ideer, meninger og følelser. Jeg tror også at det skapes flest ideer, og at de beste beslutningene blir tatt, når man får flest mulig perspektiver inn i diskusjonene, og hver person kan tenke for seg selv uten forstyrrelser. Det er viktig å finne ut hvem man selv er i teamet, og hvor man kan bidra med sine styrker. Simons Sinek’ modell, hjalp teamet mitt med å få et godt overblikk på hver enkeltes bidrag, ansvaret de hadde og hvorfor vi individuelt og teamet eksisterte. Retrospektiv er en veldig god aktivitet for alle mulige team, men jeg tror det er spesielt nyttig der teamene er tverrfalige. De ulike fagrettningene kan oppleve forskjellige utfordringer og kan dele de med resten av teamet. Mange teknikker i smidig utvikling handler om å prate og jobbe sammen som ett lag. Og det er jo fint det, men jeg har også opplevd når man jobber i workshops, at det er lett for at personene som har flest ideer eller de som snakker mest, ofte sitter med fasiten. Retrospektiv muliggjør for at alle kan tenke frem sine ideer og dele de med hele teamet. Fordi alle ideene, meningene og menneskene blir tatt seriøst, og er like viktige.
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=3243f38daab8" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/erfaringer-fra-arbeid-i-tverrfaglige-team-3243f38daab8">Erfaringer fra arbeid i tverrfaglige team</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.

Erfaringer fra arbeid i tverrfaglige team

<figure><img alt="Scrabble bricks floating" src="https://cdn-images-1.medium.com/max/1024/1*zgxTpdSxw3M7wROIh0MS2g.jpeg"><figcaption>Photo by <a href="https://unsplash.com/@tot87?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Piotr Łaskawski</a> on <a href="https://unsplash.com/photos/gL7oJLJOb_I?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Unsplash</a></figcaption></figure><h3>Introduksjon</h3>
Det kan være svært frustrerende og tidkrevende å navigere gjennom en mengde tekst for å finne det vi leter etter uten en klar og tydeliggjort syntaks. I dette innlegget vil vi se på hvilke grep designere kan gjøre for å forbedre den opplevelsen. Design-grep som kontraster, avstander, tykkelser og størrelse er blant tingene vi skal snakke om.
<h3>Bakgrunn</h3>
Folk scanner tekst etter triggerord, det vil si at de har en mental modell av hva de ser etter og scanner teksten etter dette. Hvordan vi kan gjøre dette så enkelt som mulig for brukeren? Gjennom en god syntaks. Så, hva menes med syntaks? Syntaks er måten ord og setninger er satt sammen på for å formidle noe. Det kan også beskrives som en semantisk struktur, altså at et budskap blir formidlet på tydeligst mulig måte ved bruk av færrest mulig ord, uten å bli upresis. Dårlig tydeliggjort syntaks kan føre til forvirring, misforståelser og i verste fall, feil handlinger. Derfor er det meget viktig å ha en klar og tydelig syntaks for å sikre en god brukeropplevelse.
<h3>Design-grep</h3>
<figure><img alt="Tools laying on a table" src="https://cdn-images-1.medium.com/max/1024/1*GZiMQGsuVd5ZyKkA_Areyg.jpeg"><figcaption>Photo by <a href="https://unsplash.com/@dancristianpaduret?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Dan Cristian Pădureț</a> on <a href="https://unsplash.com/photos/noOXRT9gfQ8?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Unsplash</a></figcaption></figure>Et av de viktigste grepene man kan gjøre for å tydeliggjøre syntaksen i et budskap er ved å bruke kontraster. Det handler om å strukturere et logisk hierarki som gjør det enkelt for brukeren å forstå hva som er overskrift, ingress og brødtekst. Får man til det vil det gå veldig raskt for en bruker å identifisere hvor de skal lete etter den informasjonen de søker. Noen er kun ute etter essensen, og vil derfor søke etter ingressen. Dersom ingressen ikke skiller seg visuelt fra brødteksten, er den også vanskelig å identifisere. Måten man kan gjøre dette på er ved å bruke forskjellige fonter, farger eller skriftstørrelser for å skille mellom viktige deler av budskapet. Avstander kan også brukes for å skille mellom forskjellige elementer og gjøre det lettere å navigere gjennom teksten. Tykkelsen på skrifttypen kan også justeres for å fremheve viktige ord eller setninger.
Det finnes mange gode prinsipper å følge i UX-verdenen som kan hjelpe oss å skape gode brukeropplevelser. Derfor er det viktig å forstå disse. Et av dem er Gestalt prinsippene. Gestalt prinsippene tar for seg hvordan hjernen vår tolker visuell informasjon for å skape mening og forståelse. Her er noen av disse:
<ol>
<li>
Nærhet: Tendensen å oppfatte ting som nært relatert hvis de er plassert i nærheten av hverandre.</li>
<li>
Likhet: Tendensen til å se ting som ligner hverandre som relatert.</li>
<li>
Lukking: Tendensen til å fullføre figurer eller mønstre, selv om de er ufullstendige.</li>
<li>
Symmetri: Tendensen til å se symmetriske figurer som mer organisert og harmonisk.</li>
<li>
Kontinuitet: Tendensen å se kontinuerlig og jevnt flytende linjer som beslektet.</li>
</ol>
“Nærhet” og “Likhet” brukes ofte for å skape mening og sammenheng i et budskap. For eksempel kan lignende elementer grupperes sammen for å vise at de hører sammen, mens elementer som ikke er relatert kan plasseres fysisk lenger fra hverandre. Disse gestalt-effektene er grunnleggende prinsipper for hvordan hjernen vår organiserer og forstår visuell informasjon, og er noe vi burde tenke på når vi designer for å skape mer effektive og engasjerende opplevelser.
<h3>Ting å huske på</h3>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*DMW8ftvY8Sk8yXNnOZhxQw.jpeg"><figcaption>Photo by <a href="https://unsplash.com/@brett_jordan?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Brett Jordan</a> on <a href="https://unsplash.com/photos/ofpr9Cw8Rj8?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Unsplash</a></figcaption></figure>Det er viktig å ikke overdrive bruken av design-grepene nevnt over. Det vil fungere i mot sin hensikt. Teksten vil da bli forvirrende og vanskelig å lese. En annen ting man må huske på er at man må sørge for at de blir brukt konsekvent gjennom hele teksten. Er man ikke det vil innholdet bli mye vanskeligere å fordøye for brukeren. Hold det enkelt og vær konsekvent. Dette vil føre til gode opplevelser. Helt til slutt, husk å test med brukere for å sikre at det er tydelig og lett å forstå.
<h3>Konklusjon</h3>
For å avslutte, ved å bruke design-grep som kontraster, avstander, tykkelser og gestalt-prinsipper, kan vi tydeliggjøre syntaksen i et budskap og forbedre brukeropplevelsen. Det er viktig å ikke overdrive bruken av disse for å sørge for konsekvent bruk for å unngå forvirring. Husk å alltid teste med ekte brukere for å sikre at det er tydelig og lett å forstå.
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=bce7165e0cd2" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/tydeliggj%C3%B8ring-av-syntaksen-i-et-budskap-bce7165e0cd2">Tydeliggjøring av syntaksen i et budskap</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.

Tydeliggjøring av syntaksen i et budskap

<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

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?

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

<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

<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?

<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>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

<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>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

\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

\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 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!

\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…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

\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

\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.

UX Design

Prosjektledelse

Systemarkitektur

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