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

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

«Mamma, det er noe galt med Vipps…

Hjemmekontor til besvær

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

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

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