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

Bli en av oss banner

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

Møt en X banner

European Women in Tech 2022 - Tre takeaways

Help, I’m a proxy product owner!

React Scroll Hook with Shadows

Stop Overusing Console.log in JavaScript

Benefits of Static Site Generation

Hvordan få opp farta på utviklingen med et testpanel

La oss inspirere hverandre og sammen øke kvinneandelen i techbransjen

Hvordan bruke data for å forbedre designløsningene dine?

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

Tre faktorer som genererer indre motivasjon

European 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.
European 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.
<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:
<h4>Rollemodeller</h4>
Et 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.
Microsoft 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.
I 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.
<h4>Bias i kunstig intelligens (AI)</h4>
Bias 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.
“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.
Vi 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å.
For 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>
<h4>“Claim your space!”</h4>
En 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.
Snakk 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?
Delta 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.
Med 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.
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=d3cc717610e8" width="1" height="1" alt=""><hr>
<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.

<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.
The challenge:
<ul>
<li>
Different needs and priority between stakeholders</li>
<li>Great business understanding, but not much experience with analysing insight and breaking it down into product requirements
</li>
<li>
High expectations from the rest of the organisation towards what the stakeholders will “deliver” for their team or department</li>
<li>
Difficult to move forward as a PO as the same discussions are being repeated</li>
</ul>
All 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
Where can this workshop be helpful?
<ul>
<li>A lot of stakeholders with different needs and opinions</li>
<li>Different seniority between stakeholders</li>
<li>Stakeholders not focusing on problems and insight and more on gut feeling</li>
<li>Stakeholders with a strong opinion on solution, but not necessarily the solution to the problem</li>
<li>You find yourself as a proxy PO without mandate</li>
</ul>
<h3>The works</h3>
For a group of about 12 ppl, you probably need two days to allow for discussion. The agenda will look something like this
<ul>
<li>
Homework — Participants need to prepare an “opportunity statement/description” . You will have to send this out a bit in advance.</li>
<li>
Opportunity workshop — Work with the opportunities provided by participants and stakeholders</li>
<li>
Ideation workshop based on opportunities</li>
<li>
Detailing — Work with selected ideas and start to detail in groups</li>
<li>
Afterwork — Still a lot of work to do, but you hopefully have direction and priority</li>
</ul>
To 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.
<h4>Homework</h4>
I 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.
We 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.
<a href="https://docs.google.com/document/d/1N0ZMTle1tBLGzdnsslAJTIbnR8PtRdf_TwwnmtNvZa8/edit?usp=sharing">Download the template</a>
The 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”
<h4>Opportunity statement template</h4>
Title and description — Describe the opportunity. Be as detailed as possible. Remember that the one reading this don’t know what you know.
<ul>
<li>What is occurring? What is the observations made and what is the insight from this?</li>
<li>The objective. What are we going to accomplish?</li>
<li>Who does it affect and where are they affected?</li>
</ul>
Background - Use this section to document your findings and insight
Who is involved - We need to involve them in the verification stage later.
<ul>
<li>Who is involved at your company?</li>
<li>What customer/customer segments are affected?</li>
</ul>
Impact - How big is this opportunity or the problem behind the opportunity?
<ul>
<li>How big market size will it affect?</li>
<li>How many customers are affected?</li>
</ul>
Risk — Challenge your own observations and the opportunity you see
<ul>
<li>Have you made any assumptions?</li>
<li>Why could you might be wrong about the opportunity?</li>
</ul>
<h4>Opportunity workshop</h4>
The day is finally here. It’s workshop time.
Our 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
Agenda
<ol>
<li>Make sure you have printed out the opportunities before start</li>
<li>The opportunity owner presents the opportunity in front of everyone</li>
<li>Feedback, questions and discussion</li>
<li>Repeat 2–3 until your are done or spent the time you have timeboxed</li>
<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>
<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>
<li>You now have a prioritised list of the biggest opportunities for your company</li>
</ol>
<h4>Rephrase</h4>
I 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.
<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
Say 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”
Rephrasing: “How might we improve the licence upgrade process by making it more understandable and easier to find”
Do 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.
<h4>Ideation workshop part 1 — Brainstorming</h4>
Back to workshopping!
Ideation 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.
First 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.
Agenda
<ol>
<li>Kick everything off with a walkthrough of the opportunities and the rephrased version. Place them on the wall in prioritised order.</li>
<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>
<li>Everyone presents their suggestion one by one</li>
<li>Group similar suggestions together.</li>
<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>
<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>
</ol>
<h4>Ideation workshop part 2— Detailing</h4>
This 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
The output of this section should be different concept drafts we can further develop and verify.
A concept draft in this case is a piece of A3 paper split into 4 sections
Description: 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”
Drawings 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
Technical 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.
Verification 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
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*NskqZCQGIdzvrGJ2hmkztg.png"></figure><h4>Afterwork</h4>
This 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..
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=ad1d04982a60" width="1" height="1" alt=""><hr>
<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.

<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”.
If you’ve had the same thought (I’ll guess so since you’re already reading this) but have not figured out a solution yet, you should read on.
<blockquote>TLDR: You will find the final source code at the bottom of the article</blockquote>
<h3>The Scroll Hook</h3>
Recently, I made this 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 finaly use it in our code.
<a href="https://medium.com/media/154ecf87431923f99747b31da71175d4/href">https://medium.com/media/154ecf87431923f99747b31da71175d4/href</a><h4>Handling scroll events</h4>
First, 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.
<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:
<pre>element.addEventListener(‘scroll’, (event) =&gt; /* do something*/)</pre>
The 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.
The 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.
<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>
<li>
clientHeight (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>
<li>
scrollHeight (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>
<li>
scrollTop 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>
</ul>
(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)
<h4>Calculate shadow position</h4>
We 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.
<a href="https://medium.com/media/9fcc6ca9c4c03ea3f8bfcfbb8aeb724c/href">https://medium.com/media/9fcc6ca9c4c03ea3f8bfcfbb8aeb724c/href</a><ul>
<li>
isBottom 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>
<li>
isTop is true when we’ve not scrolled yet, or scrollTop equals 0 pixels.</li>
<li>
isBetween 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>
</ul>
We 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:
<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>
Our 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:
<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.
<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>
Since 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.
In 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.
<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.
Look at the final result for the styled solution with content and source code on Codesandbox.
<h3>Final result</h3>
Here 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>):
<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)
Code foh shizzle
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=9ba2d47ae32" width="1" height="1" alt=""><hr>
<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.

The web browser console gives us more options than just the console.log()
<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.
I’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.
I want to discuss some common issues and bad habits that we usually do and some solutions for using the console better.
<h3>Issues and bad habits</h3>
How 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()?
In 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.
<h4>Unnecessary logging = less confidence</h4>
An 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.
<h4>Using the console for “confirmation”</h4>
In 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.
We 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.
<h4>Debugging is time-consuming</h4>
Debugging 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.
<h4>Logs may end up in production</h4>
Logging 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.
<h3>How we should use the web console</h3>
What 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.
<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>
The 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().
console.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.
console.error(‘Something is wrong’)
<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.
console.warn(‘Heads up! This is a warning’)
<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.
<pre>console.group(‘feature’) console.warn(‘Heads up! This is a warning’) console.error(‘Something is wrong’) console.groupEnd(‘feature’)</pre>
<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.
console.table([{ a: 1, b: 2 }])
<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>
It’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.
Browser 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.
We 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.
Thanks for reading
Code foh shizzle
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=ff4b85df5268" width="1" height="1" alt=""><hr>
<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.

<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.
When we need a fast, simple, secure, and cheap website, our next project should be using Static Site Generation.
<h3>Static vs. dynamic websites</h3>
To begin with, we should clear up what the main differences between a static generated website and dynamic websites are:
A static website is pre-built (on the server) and fetched once on the client without a server.
<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>
A dynamic website is when files are changed on the server and fetched on the client on each change.
<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>
<h3>Benefits of Static Site Generation</h3>
Dynamic 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.
We will look at eight benefits that SSG provide, whereas dynamic websites are not quite as good:
<h4>No need for a backend developer</h4>
We 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.
<h4>Better reliability</h4>
We 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.
<h4>Simplicity</h4>
With 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.
<h4>Performance</h4>
Static 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.
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.
<h4>Security</h4>
We 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.
<h4>Lower costs</h4>
We 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.
<h4>Improved SEO</h4>
Dynamic 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.
We 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.
<h4>Scalability</h4>
Static 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:
<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>
Static 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.
<h3>Conclusion</h3>
We 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.
When 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.
Static 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.
Thanks for reading!
Code foh shizzle
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=5fb187d1ffe6" width="1" height="1" alt=""><hr>
<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.

<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.
– Men, 10 måneder? Hvorfor i alle dager hadde det tatt så lang tid?
Av <a href="https://medium.com/u/71882bf4de0a">Ida Kalfoss</a>
Vi 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.
Det 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!
Finne 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.
Da 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.
Vi 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!
Finne 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.
Vi 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!
Testpanel 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!
Nå 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..
Hver 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.
<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.
Det å 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!
Hvorfor 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
Hva 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.
Så 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.
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=9369fa2af030" width="1" height="1" alt=""><hr>
<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.

av <a href="https://medium.com/u/e30b5da9a1ad">Kristine Helle-Andresen</a> og <a href="https://medium.com/u/33d36f229662">Emilie Haugen</a>
<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!
I 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.
<h3>En trygg og bærekraftig fremtid for alle</h3>
Dfind 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.
Men 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.
For 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!
<h3>Inkludering og kultur som nøkkelord</h3>
Vi ø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.
En 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!
Vi 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.
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=f4d7607f5068" width="1" height="1" alt=""><hr>
<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.

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

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

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