Sonja Porter thinks we should be more critical towards what we hear in user interviews, and instead use methods that don't ask users to lie.

As designers, our job is to make sure our team really understands their target audience. We have many questions we want to answer: What needs do our customers have? How do they complete the task today? Why do they make those decisions, and act that way? Do they like our product? Will they use this new feature?

To answer these questions, we turn to one of many methods we have stolen from social science, simplified the nuances out of and used outside of their intended context: User interviews. Unfortunately, the answers you get during a user interview will not give you a trustworthy solution to these questions – they will mostly just generate lies and half-truths. This is because of, amongst other things, two weaknesses with the method:

Weakness #1: You can’t trust people’s memories.

Every time we “remember” we retrieve a memory by reconstructing it. The product of this reconstruction is affected by both how the question was asked in the moment, and any new information we have received after the memory was first created that could affect our understanding of it. Even memories as important and emotional as how people first heard the news of a catastrophe are often misremembered. When researchers have studied these “Flashbulb memories” (for example how Americans heard about the Challenger disaster or the 9/11 attacks), they found that people are very sure they remember exactly how they heard the news – even years later. But in reality, they remembered only about half of the details correctly when compared to their own accounts taken only a few days after the catastrophe took place.

If people don’t remember the details around such an important experience, how can we expect them to remember exactly how they went about changing suppliers or using a service five years ago?

Weakness #2: People don’t know why they did or chose something.

The vast majority of choices we make are unconscious. That means that if you ask someone five times why they did something, they really don’t know the answer themselves. In most cases, the choice they made or action they completed happened without conscious thought. Most people are terrible at introspection and have little to no insight into their own thought processes – let alone be able to communicate to you what those processes actually were.

That doesn’t mean that they won’t give you an answer though – partially because there is a social expectation to answer when asked a question, and perhaps that gift card you promised in compensation gives them extra motivation to keep talking… The “answers” given are often a rationalization after the fact to justify their behavior and maintain a consistent self image when our unconscious actions go against our conscious values. We want to view ourselves and rational, thoughtful people, so we make up a thought process that never happened.

Asking people if they will use or buy something in the future is pointless for the same reason. For example, when Storebrand asked their customers if they wanted a world of sustainable investment options they got a clear yes. Customers loved the idea and said they wanted to invest immediately. But when they launched, few ended up actually buying the new products.

So… what should we do instead?

First and foremost, be realistic with what you can get out of a user interview. We can learn something about an individual's preferences – or at least how they would express them to a stranger. If we can catch them just after they did a task we can get a decent description of how it was executed – or at least that person’s perception of the fraction of the situation that they paid attention to. You will NOT, however, get the whole truth of how it happened, an answer to how most people would do it, and especially not trustworthy insight as to why they chose what they did or reacted the way they did.

Instead, prioritize direct observation and measurements. Be inspired by ethnography and field studies – get out to where your target audience is to observe what they are doing and ask questions in the moment. Set up measurements in your product to see what users are actually doing. Become a user or customer yourself! Buy the product, experience the service or attempt to solve the task yourself – but always remember your own bias and that you are but one of many diverse users. And if you find out that user interviews are the best you can do with the constraints you have – schedule them as close as possible to the event you want to learn about, do the interview in the context where users would naturally do the task, and take everything they say with a grain of salt.




🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥

Did this article spark something in you? Do you agree or disagree? Join the discussion on UX Norge's slack (Norwegian) or share this article with your colleagues and start the debate! Remember that the goal of Brannfakler is to start a discussion.

User interviews generate lies

Having sufficient contrast in your website is one of those things which are very important but still very boring to fix—especially if your site uses multiple background colours. Well, be bored no more! color-contrast() is (hopefully soon) here to save us! Let's learn what it does. 

Contrasty text automagically!

Making sure your text is readable isn't always easy. However, with the use of some color-contrast() magic, you can make sure your text always passes WCAG AA standards. Let's look at a simple example on how to use it:

Simple example 

Let's say we have a very simple site which consists of a heading, a paragraph, and a background.

In this site, we want to make sure the text colour always has enough contrast to be legible—regardless of what our background colour is. We could, of course, check our colours on a contrast-test site but that is too much work. Let's instead use color-contrast():

Let's see … Now, what does that last styling do? Well, color-contrast() is, simply put, a function that returns a colour. The returned colour is based on two things: the colour to compare contrast against and a set of colours to choose from. In this example, --bg-colour, or navy, is what to compare against, and black and white are the colours to chose from.  The result is what you see below:

We can see our text is in a nice and contrasty white. And all this was done without us knowing if black or white had the most contrast againts navy. Great!

AA level contrast against a palette

In the previous example, the text colours to choose from was either black or white as this will always achieve the highest contrast level. However, in the real world you might need to follow a palette of colours while also achieveing WCAG AA level contrast. Again, color-contrast() has us covered!

Also this time, we have our simple site:

But this time, we want our background colour to randomly change on each load. Let's magically🪄 add some javascript to randomly set the background to either navy, lightseagreen, orange or grey. We also want our text colour to be navy or lightseagreen, as long as it doesn't violate AA-level contrast. 

To do this, we only need to change a few characters in our :is(h1, p) selector:

This simple change does two things: It tells color-contrast() to pick between navy and lightseagreen, and, due to to AA, it also says the selected colour needs to satisfy AA-level WCAG. Since navy and lightseagreen alone are not guaranteed to do this, this option also adds black and white as fallback colours. Pretty neat. You can see the result below. Each change happens when the page is reloaded:

 

Buuuut … Support isn't great 😅

Before you go out and implement this in your site I unfortunately need to tell you that this is still an experimental feature; at the moment of writing it's actually so experimental that only Safari supports it, and even there it is behind a feature flag. But, hopefully soon, more browser will add support, and testing text contrast might be a thing of the past! See MDN Web Docs for more information on how to enable it, and try it out with the links to the given examples!

Links to examples

First example 🔗*

Second example 🔗*

* You need Safari with the color-contrast() feature flag enabled to run this

Contrast is boring—can't someone else do it?

We present a family of discrete regularization operators, suitably adapted to remove noise from time series data. The operators are discrete analogues of their continuous mollifier counterparts, which are well-known in the literature on partial differential equations for producing smooth approximations of irregular functions. In this article we demonstrate the utility of the noise reduction filters on electrocardiographic data, after which a technical discussion is presented in part two of this two-part series.

Time series

Time-dependent data may only be sampled at discrete points in time, thus producing a discrete sequence of observations. Such a time-sampled sequence is usually referred to as a time series.

Examples of time series include electrocardiograms (ECG) from hospital patients and name popularity trends over time, the first of which is discussed in more detail below. Other examples include digital audio signals, the evolution of stock prices, et cetera.

Noise

Sampling continuous phenomena over time is not always smooth sailing. The famous Shannon–Nyquist theorem is a classical example providing sufficient conditions on the sampling rate of a signal, that is, the number of samples per second, to avoid such effects as aliasing; it tells us that sampling at a rate twice that of the highest frequency occuring in the signal will be sufficient.

Another challenge presented to us is noise. Even if the underlying phenomenon being sampled is of a continuous, or even smooth, nature, the procedure of sampling a signal generally introduces noise as an artefact on top of the true signal which one wants to capture – measured data which is not really there.

It is therefore natural to ask if it is possible to remove the noise and recover the true, underlying signal. Many such techniques do indeed exist, and the noise reduction filters presented here were developed by the author when he was working as a summer intern on the Pacertool project at Simula Research Laboratory in the summer of 2019.

Removing noise from electrocardiographic (ECG) signals

During the summer of 2019 at Simula Research Laboratory, the author was tasked with the creation of tools for automated analysis of ECG signals. This entailed in part the automatic detection of QRS complexes in such signals.

An ECG signal is produced by placing electrodes on the patient's limbs and chest to record the electrical activity of their heart, thereby producing a waveform of the type which is here exemplified by public data from WFDB:

An algorithm for automatic QRS detection in ECG signals must be able to precisely pinpoint the onsets (Q) and offsets (S) of the complex, a task which is readily seen to be complicated by the presence of noise. Indeed, signal spikes produced by the noise may fool the algorithm into premature onset or offset detection, or even into thinking there is a QRS complex where there is none.

A common remedy is to preprocess the signal by smoothing out noise before pinpointing the complexes, here achieved by the discrete mollifier transform to be studied in more detail in part two of this series:

Conclusion

There are plenty of situations where noise reduction of time series data is desirable, and the techniques for doing so are well within reach for anyone with minimal programming experience. Here we had a brief look at situations where noise reduction is beneficial. In the next article, we take a mathematical and technical look at how the particular class of discrete mollifier transforms used above are defined, implemented, and how they relate to other common regularization operators. See you there!

Smoothing Out Noisy Signals Using Discrete Mollifier Transforms

Produktet du ikke vedlikeholder er en voksende sikkerhetsrisiko som fort kan utvikle seg til å bli en kostbar affære.

Produktet du ikke bruker penger på lenger har likevel en skjult kostnad

De siste årene har antallet “oh shit”-store sikkerhetsfeil økt. Det er produkter som har millioner av installasjoner og finnes i alle bransjer, som Log4Shell, Spring4Shell, og Big-IP. Å utnytte feilene er dessverre relativt lett, og det har potensielt fatale konsekvenser. Vi må være rigget for å reagere raskere enn noen gang på disse hendelsene.

Teknisk gjeld påvirker to ting; hvor fort du kan utvikle ny funksjonalitet og hvor fort du kan rette feil. Den siste her er skummel da sikkerhetsproblemer dukker brått opp, og det er viktig å reagere raskt.

Hvis du må oppdatere mange andre avhengigheter, eller skrive deg vekk fra en teknologi som inneholder sårbarheter, krever det mye forarbeid slik at man ikke introduserer nye feil. En applikasjon som ligger urørt over lengre tid bygger opp en sikkerhetsgjeld, men i motsetning til Sentralbanken som prøver å være forutsigbare i rentehevingene sine, kan gjelden din akselerere fra lav til skyhøy over natten.

Hva er sikkerhetsgjeld?

Som all gjeld opparbeider sikkerhetsgjeld seg over tid og svinger i hvor raskt den øker. Vi kan peke på sikkerhetsgjeld og definere det ved å gjøre noen observasjoner: hvis dine tjenester for eksempel benytter utdatert kode som inneholder kjente sikkerhetshull og sårbarheter, eller hvis den inneholder manglende fokus på beste-praksis innen sikkerhet, eller teamet lider av en svak sikkerhetskultur — da har man sikkerhetsgjeld!

Pakkebrønner som NPM og NuGet lar deg bygge programvare i et stadig høyere tempo med gjenbrukbare kodebiblioteker, men økende grad av avhengigheter til tredjeparter har en kostnad. Hva når rammeverk man bruker har avhengigheter til sårbar kode? Tredjepartsbiblioteker har blitt landminer hvor små sikkerhetsfeil har stort skadepotensiale. Her befinner det seg potensielt mye skjult sikkerhetsgjeld og verdikjedene våre må gjennomgås stadig grundigere med sikkerhetsbrillene på.

I kontrast til teknisk gjeld, er det rentenes uforutsigbarhet som skiller sikkerhetsgjeld fra teknisk gjeld.

Risiko øker over tid

Mye av grunnen til at risikoen øker har å gjøre med at terskelen for å finne og utnytte sårbarheter blir lavere etterhvert som sikkerhetsoppdateringer blir lansert og sårbarhetene de fikser blir offentliggjort. Det som tidligere krevde masse ressurser å oppdage og utnytte blir etterhvert lavthengende frukt via åpent tilgjengelige verktøy eller kildekode. Det tar som regel ikke veldig lang tid fra sårbarheter blir kjent til det finnes ferdige programmer man kan laste ned for å finne og utnytte dem. Sårbarheten som førte til dataangrepet på Stortinget i 2021 ble hyppig utnyttet globalt bare dager etter at Microsoft selv vaslet om problemet.

Responstid er kritisk

Dette gjør seg spesielt gjeldende når nulldagssårbarheter oppdages. I et kappløp mellom trusselaktørene og oss som forvalter tjenestene, er det å kunne agere raskt for å patche systemene våre stadig viktigere. Det kan fort bli vanskelig å gjøre i tide for applikasjoner som ikke aktivt forvaltes lenger. Hvis det ikke er noen utviklere som kan teknologien eller den tekniske riggen ikke fungerer lenger, mister man dyrebar tid i dette kappløpet. Så selv om en app ikke har noen kjente sårbarheter i dag, kan den ha et kritisk sikkerhetshull i morgen og da gjelder det å kunne agere raskt.

Veien inn i nettverket

Manglende vedlikehold av en applikasjon utgjør også en risiko for andre applikasjoner og tjenester i nettverket ditt. Selv om den utdaterte applikasjonen isolert sett ikke inneholder noe viktig informasjon kan den brukes som en vei videre inn i nettverket. Det at tjenester ikke er direkte eksponert på internett kan derfor ofte gi en falsk trygghet.

Større cybertrusler krever ansvarlig produktutvikling

Man kan nok enes om at å ikke betale renter på et lån er uansvarlig. Vi mener at å ikke betale rentene på ditt produkts sikkerhetsgjeld er like uansvarlig!

Sikkerhetsgjelden øker over tid

Sikkerhetsgjelden i produktet ditt øker over tid fordi nye sårbarheter oppdages hver dag. Ditt produkts verdikjede inneholder en rekke avhengigheter som også er eksponert for denne risikoen. Manglende vedlikehold øker også risikoen. Forskning har vist at nulldagssårbarheter tar i snitt 7 år fra de blir oppdaget, og utnyttet av en hacker, til de blir offentlig kjente og kan mitigeres med en programvareoppdatering. Dermed er det behov for årvåkenhet og å drive forebyggende sikkerhetsarbeid kontinuerlig, slik at man kan forhindre de som utnytter ikke-kjente sårbarheter som ditt produkt kanskje inneholder.

Vi mener derfor at sikkerhetsgjeld må få større fokus fremover!

Hvordan unngå å havne i sikkerhetsfella

Betal den dyreste gjelden først

Hvilke tjenester du vier oppmerksomheten din burde ikke utelukkende være styrt av ny funksjonalitet du skal levere. Gå jevnlig gjennom tjenesteporteføljen du har ansvar for og oppdater riskovurderingene dine. Oppgaver relatert til tjenester det er lenge siden noen har tatt i burde prioriteres høyere, da rentene på sikkerhetsgjelden her er størst.

Metrikker som indikerer hvor lenge siden det er siden forrige endring kan synliggjøre hvor skoen trykker.

Betal ned raskere med et produktteam

Måten du kvitter deg med sikkerhetsgjelden raskere på er å la et produktteam selv organisere hvordan de ønsker å jobbe med vedlikehold og nyutvikling. Det blir en vektskål hvor målet er balanse enn at en dominerer for mye. Bærekraftig forvaltning av et produkt vil si at man kontinuerlig tar unna sikkerhetsgjeld, samtidig som man tar unna teknisk gjeld og øvrige oppgaver som medfølger av å ha ansvar for et produkt og dets funksjonalitet over tid.

Tør å kvitte deg med produktet

“Kill your darlings” betyr at du skal ikke være redd for å kvitte deg med kode. Fordi det var vanskelig å skrive, tok mye tid og krefter eller fordi du løste et problem på en kul måte, betyr ikke at den har livets rett. Det er lett å tenke at en applikasjonen laget for lenge siden, som fortsatt tjener noen få kroner i året har verdi fordi man tilbyr kundene flere produkter.

Den skjulte kostnaden ved å sitte på sikkerhetsgjelden kan være stor. Ta avgjørelsen; kvitt deg med produktet eller gi den oppmerksomheten den krever.

Oppsummering

Hold applikasjonsporteføljen oppdatert, og få oversikt over hva du trenger å vedlikeholde. Måten man får bukt med sikkerhetsgjelden på er på mange måter den samme måten som med teknisk gjeld, det er bare viktigere å betale den ned før renten plutselig vokser eksponentielt. Noen ganger er også løsningen å kvitte seg med hele appen, og dermed også gjelden den har.

Luksusfellen for utviklere er å ignorere sikkerhetsgjeld

Dagens designtips er en artikkelserie hvor forskjellige designere fra Bekk snakker om jobben de gjør, hvilke utfordringer de møter på, og kanskje kommer med et lite tips

Hvem er jeg?

Sigvart Bretteville-Jensen

26 år

Fra Røa i Oslo

Master i interaksjonsdesign på UiO, med fokus på store og komplekse informasjonssystemer

Jobbet deltid i Bekk i ett år før jeg startet fulltid for åtte måneder siden


Min interesse for design startet egentlig i 12-13 årsalderen da jeg begynte å interessere meg for alt som hadde med PCer å gjøre. Jeg kunne sitte timesvis på Youtube og lære meg det jeg på den tiden så på som “hacking”. I praksis var det å kopiere inn windows-kommandoer i Notepad, lagre dem som .bat-filer og få CD-rommet på PCen til å åpne og lukke seg. Med tiden innså jeg  (tross min store interesse for hackerfaget) at min kreative, høyre hjernehalvdel var mer dominerende enn min venstre. Samtidig hadde ikke 12 år gamle Sigvart sine drømmer om å bli hacker forsvunnet helt. Derfor ble interaksjonsdesign et perfekt utspring for å kunne jobbe med begge interessene mine, design og teknologi!



Hva gjør jeg (og hvordan)?

Siden jeg startet fulltid i Bekk i mars har jeg jobbet hos Finanstilsynet sammen med en veldig ålreit gjeng med Bekkere. Teamet består av en team lead, syv utviklere, to produkteiere fra Finanstilsynet og meg selv. Til daglig jobber teamet vårt med å videreutvikle alle fagsystemene som brukes internt av de ulike fagavdelingene på huset. Fokuset vårt er å lage IT-løsninger som best mulig støtter disse fagavdelingene i å passe på at banker, revisorer, regnskapsførere, eiendomsmeglere, fondsforvaltere ++ følger loven.

Skal jeg trekke frem én ting jeg synes har vært ekstra spennende å få være med på, må det nok være innføringen av OKR og målstyring i teamet. Som designer var jeg først litt skeptisk til hvordan kvantifisering og tall skulle bidra inn i mitt og teamets arbeid, men den usikkerheten har forsvunnet mer og mer over tid. Det å definere fokusområder og tallfeste mål gir både motivasjon og en felles forståelse av retning, som er verdifull for folk både i og utenfor teamet. Samtidig vil jeg si at det som har vært mest spennende også har vært noe av det mer utfordrende. OKR virker i utgangspunktet som et veldig enkelt og greit rammeverk, men har vist seg å være noe mer krevende enn først antatt (Ref. Jøran sin post noen dager tilbake). Likevel er jeg OKR- optimist, for skal vi tro OKR-guru Christina Wodtke så er det nesten ingen som får til OKR’er på første forsøk, og det er fin motivasjon for å fortsette arbeidet i teamet.



Hvilket tips ville jeg gitt meg selv i starten?

I et stort og komplekst domene er det lett å bli stresset over manglende kontroll og innsikt. Stort sett holder det å forstå og fokusere på det som er viktig akkurat nå, så danner du deg bedre forståelse av helheten med tiden.




12-Dec

Today's posts

User interviews generate lies

Contrast is boring—can't someone else do it?

Smoothing Out Noisy Signals Using Discrete Mollifier Transforms

Luksusfellen for utviklere er å ignorere sikkerhetsgjeld

Dagens designtips