After a while, some things just become tradition. That's why we're so excited to bring back our beloved advent calendar for the sixth consecutive year!

This year, like the years of Bekk Christmas' past, we'll share new original articles, podcasts, tutorials, listicles and videos every day up until Christmas Eve. It's all written and produced by us – developers, designers, project managers, agile coaches, management consultants, specialists and generalists, people with decades of experience and months of experience. 

Bekk Christmas is a wonderful blend of everything that's us. We learn by sharing, we talk about things that matter to us, and we do so to make both ourselves and you a bit better every day. We're sure you'll find something new to use in your day-to-day job.

We actually started early this year, meeting up for a full traditional Christmas dinner (with vegan options, this time!) way back in October, together with our beloved 10 meter tall inflatable Santa. We loved getting together to brainstorm, combine ideas or just talk to others about what they should share.

New features!

A new feature this year is that we've implemented a newsletter, to get the content of the day right in your inbox every day (or every week, if you prefer that). Make sure to sign up below!

We're starting to amass quite a few still relevant articles from previous years as well. If you want to go spelunking, check out the new categories view (which also includes a new, neat search feature), which will let you find cool stuff from the last 5 years as well.

So without further ado, we hope you enjoy today's articles, and that you come back a few more times this holiday season. 

Happy holiday wishes from the Bekk Christmas crew! 👋🎅

Welcome back to Bekk Christmas

Denne artikkelen er basert på masteroppgaven “Økonomisk skam og design” som vi skrev våren 2022. 

Når vi jobber med produktutvikling har vi ansvar for tjenestene vi utvikler. Da har vi ikke bare ansvar for å tenke på brukernes funksjonelle behov, men også brukernes følelser. Når vi utvikler økonomiske tjenester er dette ekstra viktig, da økonomi kan være et sensitivt tema for mange. 

Hvordan føler brukeren seg når hen får varsel om ubetalte regninger?  Er ordleggingen i nettbanken vi utvikler med på å forsterke normer som gjør at brukeren føler hen ikke strekker til økonomisk? Kan det være noen av brukerne våre føler på skam knyttet til økonomi, og dermed også føler skam når hen tar i bruk vår tjeneste?



Hva er økonomisk skam?

Begrepet økonomisk skam vil hos mange vekke umiddelbare konnotasjoner til store økonomiske problemer og gjeld. Mange ser kanskje på skam som en altoppslukende vond følelse. Derimot mener vi at økonomisk skam er mye mer nyansert enn dette. Økonomisk skam kan oppstå hos alle, uavhengig av inntekt, formue eller gjeld og kan inkludere mange nyanser av følelser. Skam er den ubehagelige følelsen du får når du snakker med noen om lønn, eller når du må be noen om penger på vipps. Man kan skamme seg for huset man bor i, klærne man går med, avhengighet til tipping, hedonistisk shopping, at man drar på alt for dyre ferier, eller ikke drar på ferie i det hele tatt.



Økonomi og identitet

Den norske økonomiske modellen og samfunnets normer gjør at store deler av vår identitet er knyttet til penger. Når samfunnet rundt oss har de normene og verdiene knyttet til sosial og materiell kapital, gir det mening at det er så vanlig å føle skam rundt sin økonomiske situasjon. Når man føler at man ikke strekker til på det økonomiske planet, trues identiteten, det bildet man har av seg selv, eller av hvordan man ønsker å være, og dette kan føre til skam.

Penger og økonomi er privat, og noe man snakker lite om med andre. Under 50% deler hvor mye de tjener med foreldre og venner, og bare 20% deler det med søsken . Informasjon om vår økonomi er derfor noe vi stort sett holder for oss selv og samtaler om økonomi holder seg ofte på det generelle plan. Det at økonomi, og spesielt økonomiske problemer, er et tabu gjør det vanskelig for oss å snakke om følelsene vi har knyttet til økonomi.


Hva kan jeg gjøre?

Selv om man kanskje vet at økonomisk skam eksisterer, er det kanskje ikke noe man er bevisst på i arbeidshverdagen. Designere mangler verktøy for å ta hensyn til skam i designprosessen. Det er ikke nok å bare ha kjennskap til følelsen, som designere bør man også aktivt se etter den og hvordan den former menneskene man designer for.

Det at økonomi er tabubelagt kan gjøre det utfordrende for brukerne å dele åpent og ærlig. Dette gjør at vi som designere trenger andre teknikker og verktøy for at det skal være komfortabelt å snakke om penger, og for at vi i innsiktsarbeidet vårt skal få troverdige og gode resultater. Her er noen tips, fra oss til dere, for hvordan dere kan komme i gang.



Snakk om hva skam er

Skam kan ha ulike betydninger for ulike mennesker, men ved å diskutere hva skam kan være med andre kan vi enklere konkretisere egen forståelse og også enklere forstå andres synspunkter. For å forstå en følelse bør man sette ord på den, og en måte å forstå skam på er derfor å begynne å snakke om hva skam er. Men å snakke om skam kan i seg selv være skamfullt. Derimot vil det å begynne å snakke mer om skam gjøre at det blir til en mindre skummel følelse, og desto lettere blir det å legge merke til når skam er til stede hos andre. For å få til dette kan man samle teamet man sitter i, og sammen forsøke å komme frem til en felles forståelse, eller en slags definisjon av skam. Hva betyr ordet skam for dere? Inkluderer dere flauhet og ubehag?



Erkjenn egen skam

Man kommer seg ikke unna penger, noe som jo betyr at vi designere (og resten av teamet vårt) har en økonomi. Egen erfaring med penger og økonomi påvirker ens ståsted og utgangspunkt inn i økonomiske prosjekter. Ved å snakke om situasjoner hvor man selv føler på ubehag eller skam kan man fjerne stigma og tabu innad i et team, og gjøre det enklere å oppdage ulike former for skam hos brukerne våre. Teamet kan sette seg ned sammen og tenke over konkrete økonomiske situasjoner som dere selv kan befinne dere i. Hva føler dere når dere glemmer å betale regninger? Hvilke situasjoner er det som fører til ubehag hos dere selv, og hvilke situasjoner er det som fører til sterke følelser, som skam?



Bruk tid på å forstå hele personen

At identitet og økonomi er tett knyttet sammen er viktig for designere å forstå fordi det gjør at man ikke kan forstå en person sin økonomiske skam uten å forstå personens identitet og situasjonen rundt. Ulike personer føler skam av ulike grunner, og uttrykker også denne skammen forskjellig. Dette gjør ikke jobben enkel når man skal prøve å konkretisere hva skam er og grunnene til at man føler det. Man bør derfor akseptere at skam er en kompleks følelse som utarter seg ulikt hos ulike personer, og at for å virkelig forstå hvorfor noen føler skam, så må man forstå hele personen. Her er det også viktig å være bevisst på at skam kan oppstå uavhengig av brukerens økonomiske situasjon.



Reflekter rundt hvordan du er med på å opprettholde normer og regler 

Uskrevne regler og normer er ofte stigmatiserende og skampåførende. Som designere er vi med på å forme hvilke normer som gjelder i samfunnet gjennom det vi lager, og vi er derfor med på å forme hva som anses som skamfullt og ikke. Designere kan påføre skam i mange deler av designprosessen; både bevisst og ubevisst. Dette kan være gjennom måten vi ordlegger oss og møter sluttbrukere, gjennom informasjonen vi formidler, eller gjennom utformingen av selve produktet. Sammen med teamet kan man forsøke å formulere konkrete normer og regler som finnes rundt økonomi i samfunnet i dag. Er det noen av disse som er relevante for tjenesten dere utvikler? Ved å se på hvordan tjenesten man lager er med på å opprettholde normer og regler kan man bevisst ta stilling til om det er noe man faktisk ønsker å gjøre.



En liten oppfordring

Gjennom produkter og tjenester kan vi ha stor påvirkningskraft på hva brukeren føler. Å forstå skamadferd kan hjelpe designeren med å forklare hvorfor brukere av økonomiske tjenester oppfører seg på måtene de gjør. Vi oppfordrer alle som jobber med økonomiske prosjekter til å tenke gjennom om de har tatt hensyn til skam i sitt prosjekt. Vi tror det kan bidra til ny innsikt og bedre produkter og tjenester for brukerne våre.





Til deg som er ekstra interessert

Resultatet av vår masteroppgave var et metodesett bestående av fire ulike metoder som teamet kan bruke for å begynne å snakke om skam. Metodene skal bidra til bevissthet rundt hva økonomisk skam er, hvordan det påvirker oss selv og brukerne våre, og hvordan samfunnet rundt oss er med på å forme hva som er skamfullt og ikke.

Sjekk ut metodesettet her, og bruk det gjerne i ditt prosjekt!


Økonomi + skam = </3

We have been using React Router for a while at work, across multiple projects and spanning multiple years. React Router is one of, if not the, most popular routing library in the React world, and has been for some time.

One of the many features of React Router is (or was, foreshadowing) the <Prompt> component which you could use to block a navigation happening based on a state, like for example if you have unsaved changes on your page and the user tries to navigate away before saving. It should be noted that this would only blocks navigation made through React Router itself, not standard anchors or browser events like reload. The latter can be blocked by using the beforeunload event on the window object.

React Router v6 was released in November of 2021 after a series of public beta versions. During the betas the <Prompt> component got turned into two hooks, usePrompt and useBlocker. But come the final version, these two hooks got removed from the final release. A GitHub issue got opened to include these hooks back into the framework and at first they said they needed more time to finish this feature. But a year has since passed and still nothing. So what do you do?

First option was to not upgrade. And for a good while, we didn't. The React Router team has stated that v5 is still actively maintained, but at some point that won't be the case anymore and one could only hope that this one feature blocking you from upgrading has made its way into the library by then.

Second option was to use a workaround that somebody figured out. It would hook directly into an unsafe history context object. This worked, and is what we ended up doing to be able to upgrade to v6, up until the release of v6.4.0, where this context stopped being exposed.

Third option mentioned by the React Router team is to develop the website in such a way where you don't need to block the users navigation. Either by saving state in localstorage or autosaving, but this isn't always possible, and for us this wasn't really a viable option.

So now we're stuck on 6.3.0 and have to make sure not to upgrade the library above this version so that we don't break the workaround, because at this point it would be an even bigger job downgrading to v5.

I'm sorry to say I don't have an answer to the question. I feel like we're stuck between a rock and a hard place at the moment, at the mercy of the React Router team. I'm not saying we're without fault ourselves, we chose to upgrade to v6 and use the workaround.

There is a positive here though and that is that it seem like the React Router team is still looking into implementing the feature, even though at some point it looked like they had abandoned it, by their own words. So for now I'm still crossing my fingers, but I'm not holding my breath. 🤞

What do you do when your favourite open source project removes a feature you use?

Create more efficient and accessible interfaces by adding visual redundancy to your UI components!

Image by Deepmind on Unsplash

Create accessible components by making them redundant

Several of the WCAG requirements are built on the concept of "redundancy" – repeating the same information several times through different means.

Redundancy can be providing the user with a text alternative for non-text content (1.1.1), an alternative for time-based content presented through video or sound (1.2.1), and captions for pre-recorded video with sound (1.2.2).

When users scan an interface to make sense of its contents, there are 5 visual "channels" that can be utilized to help in this understanding: shape, colour, texture, motion and depth.

"Visual redundancy" refers to the conveying of information by more than one visual channel, like displaying the meaning of a symbol through both shape and colour.


Example

Three relatively similar icons with different meanings

Redundancy with colour. Will not necessarily make a difference for those with impaired color vision or vision.

Redundancy with form. Will help those with impaired color vision to a greater extent.

Clarification with more color. Will to a greater extent help those with impaired vision.



Redundancy increases search efficiency

When we combine the features of several channels, we give users the opportunity to perform a visual search in more than one way. This allows the user to search more effectively with their eyes, see the difference between elements more clearly and find the information they are looking for more quickly.

Visual searches are fast, and redundancy makes a search go just a fraction faster. Meaning the effects of redundancy are more apparent when there are many elements to search, as in information-dense interfaces.

It is beneficial for those with impaired vision or colour vision to have alternatives that are comprehensible to them. Hence requirements 1.4.1 “Do not use presentation based solely on color”) and 1.3.3 “Instructions must not rely solely on shape, size, visual location, orientation, or sound to be understood”. Clarification also lowers the risk of errors due to cognitive load or cultural differences in colour perception.

So what are you waiting for?
Make your UI components visually redundant, today!


Visual redundancy

Why has Rust been voted the most beloved programming language – seven years in a row, ever since it got released? What’s the hype about? Read along to get a glimpse of Rust, without having to read boring documentation. We’ll introduce Rust, bit-by-bit, by writing a simple CLI program that parses a list of HTTP requests and executes them.

Introduction to Rust

This article is for developers that’s interested in learning Rust or would like to learn what it has to offer. We’ll write a simple CLI program used as a motivating example. This program takes an input file containing a list of HTTP requests that a user wants to send, parses them, and then runs the requests.

But first, what is Rust and why should you use it?

What is Rust?

Released in 2015, Rust is a general-purpose programming language initially developed by Mozilla in the early 2010’s. It’s a strongly and statically typed language designed for “performance, reliability and productivity”. Rust uses an ownership model to manage its memory, in contrast to garbage-collected languages like C# and Java, and the manually managed C and Zig. This allows Rust to keep track of how long the values should be allocated and ensures that you don’t mistakenly misuse or mutate values when you’re not supposed to. Its main goal is to enable you to write robust software, free of memory-safety bugs causing security vulnerabilities, like buffer overflows and use-after-free. This memory safety is achieved by using a unique ownership model and not allowing arbitrary pointer accesses. By combining these language features, Rust achieves compile-time safety from data races and safely parallelizing tasks.

Want to try it yourself? The recommended way to install Rust and the relevant tools is from its version manager "Rustup", found here.



Why Rust?

Rust has seen an increase in use and popularity in the recent years. It has won “Most loved programming language” in the StackOverflow Developer Survey seven years in a row – once a year since its release! The language has won by a mile and lies considerably ahead of the other languages in the survey.



Recently, several big players in the tech world are noticing the benefits of Rust. For instance, Microsoft Azure CTO, Mark Russinovich, tweeted that all new projects written in C/C++ at Microsoft should instead be written in Rust, and NSA urging people to use memory safe languages, one of which is Rust.

The main reason for this is that memory-related bugs such as buffer overflows are still serious security issues, as many areas require maximized performance and use languages such as C or C++, which aren't memory safe. Also, just recently the widely used OpenSSL library announced a critical vulnerability caused by a buffer overflow. These types of errors are the ones Rust is specifically designed to prevent, effectively eliminating most of them if the code compiles. 



Motivating Example

To showcase some features of the language we will create a CLI program that takes an input file containing descriptions for HTTP requests and executes them. To start, the requests will be very limited and will have the form:



That is, either GET or POST, a url, and a potential body in the POST case.



To start off, we set up our project using Rust built in package manager: Cargo

This will create the following file structure

Cargo.toml is a file containing all configuration metadata and information about the project, such as its authors, and version number; but it also specifies dependencies and compiler flags. The main.rs file is the main entry point of our program.

Downloading dependencies and running code made with Cargo can be done with the run command:


cargo new generated an implementation of "Hello, world!" for us, so we can skip right past writing "Hello, world!" in Rust. Pretty neat!



Now, to finally start writing our CLI program, we'll begin by defining a data structure to encapsulate a request. We could do all parsing and executing inline, but that would quickly become a mess. All our HTTP requests will all contain an URL and a method, and in the case of POST, a body. We could define our structure like this:



This has a few obvious drawbacks. For one, it allows us to set illegal and nonsensical request methods such as "CRASH" or "BURN". It also allows GET requests with bodies.

This problem can be solved by making types that only allows valid states. We are essentially making Rust's strong type system guarantee the correctness for us. Error-handling will happen when we parse the file, which makes the important part of the code clearer.

To design our structure better, we will make use of Rust's enums (sometimes called sum-types or algebraic data types):

This creates a new type Method which is either the value Get, or the value Post with a field named body carrying a string. This way, we prohibit GET requests with bodies and other invalid methods just by using this type, and the intent is clearer too.

Using our newly created type, we can define the improved HttpRequest to be:

To parse the input file, we will read each line of the supplied input file and try to parse it into a HttpRequest. We start by creating the method that will parse the each line. The function signature looks like this:

Now, you might notice that we wrote &str and not String here, which is because we want this function to simply read from the string, and it does not need to write to it. By writing the ampersand (&), we specify that the function wants a reference to a string, which is called str, so we get &str. Rust cares a lot about who "owns" values, as they are required to clean up after them (deallocating them). How this works happens automatically and at compile time, and is part of how Rust achieves its strong compile-time safety. For now, don't worry about it too much.

Result is one of Rust's built in enum types. Its source code definition (stripping some details for brevity) is:

This definition tells us that a result can either be Ok with T, or Err with an E. The T and E in this case are generic types, so that any type can be used in conjunction with the Result type. Rust doesn't support exceptions, so using Results are the conventional way of dealing with fallible functions. In our case the Ok type T is a HttpRequest and the error is a HttpParseError, which is yet another enum type, that we define to be:

(A quick sidenote: although all of our enum examples have had two variants, any number of variants are allowed.)



Let's parse the input file and implement the parse_line function:

Now, let's break down the code. On the first line, we split the line (e.g., "POST foo bar") on spaces, and then collect it into a vector (Rust's lists) of strings (so we have["POST", "foo", "bar"]). 

Then we pattern match on the vector as a slice – a view into an array.

When the compiler sees a match expression, it matches the value with the list of patterns and stops when encountering the first pattern that matches. Each branch has the form of SomePattern => some_expression(),. For example, in the first case, if the vector has a pattern of an array starting with "GET" followed by some other string which we will call url, then the branch is executed and the others are not matched. It's essentially a compact version of chained if-else-if statements, but it also returns the value of the branch that is executed, making it a match expression and not a match statement. The value from the expression is also returned from the function itself. Method::Get just means create the variant Get in the type Method.

In the second pattern, we check for the pattern starting with "POST" and some url, followed by any number of words. body @ .. just means: name a variable body, which binds to (@) the rest of the slice (..), if it's empty or not. Since we split the line on " " (space), we'll just join the body parts (hehe) back together using a space by writing body.join(" ").

Interestingly if we encounter the pattern [header, ..] meaning, the vector has, first, some string header, and then anything ( .. means the rest of the slice) after our two first patterns, then we know the line contains something different than GET or POST. We consider this an UnrecognizedMethod error, and return one accordingly. Another possible error we can match for is the pattern ["POST", url] which corresponds to a POST method without a body.

Finally, when creating the HttpRequest structs, we have to use .to_string() on the url and body, which turns a stack-allocated string (&str) into a heap-allocated string (String). We have to do this to prevent us from potentially accessing a dangling pointer sometime later, i.e., a pointer which points to an invalid object. In our case, the stack-allocated string might have been deallocated if we try to use it later in our program. Returning the stack-allocated string from the function is also possible, avoiding the allocation entirely, where the new string is just a slice of the other string in memory. However, to do that we need to understand Rust's concept of lifetimes, which is a more complex concept to deal with later. For now we can definitely afford the allocations 🤓

Oh, and the last line in the match-expression just says to match whatever (the underscore _), and return an error saying we encountered an unrecognized format.

Testing, testing, 123?

Does it work? Let's print a parsed request to see:

println is also a macro, which prints things, "{:?}" is a format string specifying that we should print the result of the parse_line function call as a debug representation.

But oh no, this does not work! The compiler spits out an error message (which had beautiful colors, but which we cannot show here):

Wow, quite a descriptive message. It might seem like a lot, but if we had the colors, we would quickly see the first part saying that the request type cannot be printed as a debug representation because it doesn't implement the Debug trait. A trait is similar to an interface in other languages, meaning something that a type can implement. Luckily, the error message contained out a help-message at the bottom with the exact code change we need to fix our code! 

The suggested code change is a derive macro, which we place on top of our type, meaning we say to the compiler: "just implement the most basic implementation of Debug that works for this type for me". Let's add the line to the top of all of our types HttpRequest, Method and HttpParseError:



Now let's try to run our code again and test that the output is correct:

Nice! Our parse_line-function worked. However, we don't want to have to run our code, read the output and then manually ensure it is correct with every code change. It would be nice if we could test it somehow. Luckily, Rust has a simple and easy test framework built in! In the same file, main.rs, we can simply write the following:

#[test] is a macro which generates the test harness needed. assert_eq is a macro that errors if the two values do not match. Unfortunately, once again, this will fail to compile because our types cannot be compared yet, as they do not implement PartialEq (short for a partial equivalence relation), and once again the compiler suggests to implement it using the derive macro. We'll modify all our types so they now look akin to this and implement PartialEq:

All right, now it doesn't complain (we can check it using cargo check 😏). So how do we run our test? Well, cargo run runs our code, so maybe cargo test tests it?

Wohoo! Success! Also, the compiler loves colors, but our blog does not, so you cannot see the nice green colors of success 😔

And by the way, how nice is it that Cargo just works the way we expect it to? cargo run, cargo check, cargo test? What's next, cargo fix my code? Well, actually yes... But surely it cannot fix broken code? Well, Cargo strikes once again, with cargo fix --broken-code 😎Although obviously this doesn't always work, or we would be out of work!

Let's write a couple of more tests to ensure it works as expected:

Alright, and now let's test them using cargo test again:

Great success!



Reading from a file

There are several ways to read from a file in Rust. The simplest one (in our opinion), and the one we'll use is Rust's built-in function read_to_string, found in the fs module in the standard library module std. read_to_string takes in a file path, tries to read the file into a String and returns a Result<String, std::io::Error>. In our case, we'll be reading from a hardcoded file we know exist, so we only care about the Ok case. Since this is supposed to be a short post and we know our file exists, we can just convince Rust that we know the Result is Ok and unwrap the value inside Ok using the function unwrap(). Note that, if our assumption that the value is always Ok were wrong, the code will panic and stop running. We don't recommend doing this in production code.



To parse each individual line, we will split the content of the string on the newline character (\n):

Like so. Now, what we haven't said yet, is that split actually returns an Iterator! Well, some type that implements the trait Iterator, which is a trait for.. well.. iterating things! There are a myriad of available methods for iterators, the simplest being next, which simply returns the next element in the iterator, or the previously seen collect which we've seen neatly creates a vector from the iterator. The method we are interested in is map (which is also common in lots of other languages), taking a function that transforms values from a type T, to a new type U as a parameter. In our case, we want to transform each line in the file to a Result<HttpRequest, HttpParseError>. Finally, having mapped each line, we want to call our good friend  collect to give us a vector. Putting everything into a function read_requests we get:



Clean. 

Notice that we use our parse_line function from before. Let's create a test for the function. For brevity, we assume there is a file named test_input which contains:

The test looks like this:

Running the test again, we get.. 

Great!



Executing HTTP Requests

Since we have done most of the work up until this point, sending the actual HTTP requests is the easy part. We will not implement the HTTP protocol ourselves (sorry to disappoint anyone), we will instead use one of Rust's excellent community libraries: reqwest. We've seen a pattern of Cargo having intuitive commands, so let's try adding it using... cargo add? Well, almost, we can add it using cargo add reqwest --features blocking. This will add reqwest as one of our dependencies while also enabling the blocking API. This will update our Cargo.toml file to be:

To keep the article simple we will use reqwest's blocking API instead of its asynchrounous flavor. Leaving async/await for another article. We can now (finally) start writing our main function! Let's go through all the HTTP-request instructions that we've parsed:

This reads the requests from the input file and iterates over it, because read_request returns a vector of Results so we can iterate over it. There are many ways to handle the error cases. In our case, we'll simply ignore them. There are many ways to do this, such as using the continue loop construction if the value was an error, or doing a pattern match; however, the cleanest and coolest way is probably to use Iterators 😎. Turning a vector into an iterator can be done using the into_iter function. From there, we can use flatten which simply discards error values and unwraps the Ok values, making the iterator iterate over the values within the Ok. This is also not how we would do it if this was a real program. It would be nicer to give user feedback that the instruction is incorrect and will be ignored.

To execute each request, we'll just pattern match on each request's method and call the corresponding function in the library we added:

Here we create a client that we will be using for every request. We then iterate over each request and use the match expression to either send a GET request or a POST request. Finally, since it's an expression, we can call send on the expression which sends the request and returns a Result which we blindly assume is always Ok,  and print the text (which we also blindly assume is text) stored in the response.



Results

Running our program with GET example.com in our input file, we get..

Et voilà!

It runs the GET request, and print the result!

Final remarks

Although our introduction to Rust has been quick (at least that's what we hope it felt like), we hope that you have gotten a decent taste of the Rust programming language. If you are still interested in learning more, there are plenty of good resources. A good place to start is "The Book", as the official and free book on Rust is known in the community or The Rust Programming Language.



We hope you enjoyed this article and we hope to see you again in another 👋





Introduction to Rust

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?

Thomas Bråthen Fjeldberg-Norheim

34år gammel

Fra Bamble i Telemark, Norges vakreste fylke

Studerte ved Høgskolen i Østfold og Högskolen i Dalarna

Jobbet som designer i 10 år

Jeg valgte å bli designer fordi jeg ville skape. Men for å skape, må du lære deg flere språk. Jeg snakker designsk, men må også forstå flytende kunde og det språket folk flest prater seg i mellom, i ulike kanaler. Jeg er medfødt nysgjerrig og elsker å lage ting, hvis du kombinerer de to tingene med en barndomsdrøm om å bli oppfinner, så blir du designer.

Akkurat nå jobber jeg hos Nordea Finance som ux designer, og er der på bakgrunn av min designerfaring fra FinTech og store komplekse organisasjoner. Mer spesifikt jobber jeg med 5 ulike tjenester, bla. auksjonen og kundeportalen. Kundeportalen får nå full overhaling av kode og grensesnitt.

Hva gjør jeg?

Jeg jobber som en translatør mellom brukere av våre tjenester og ledelsen hos kunden. Det er veldig motiverende å ta et komplisert domene og forenkle det så mye at hvem som helst skjønner det og kan bruke det uten opplæring, verstehen sie?

Kunden har ofte en mening om hva som fungerer bra, og ikke fungerer bra. Men de vet ikke hva de ikke vet, og jeg vet ikke hva de ikke vet. Jeg vet hva jeg ikke vet, og jeg vet hvordan jeg kan få vite det jeg ikke vet. Kunden har ofte en mening om hva de ønsker og i hvilken retning de ønsker å ta sitt produkt, men stemmer dette med kundenes ønsker og behov? Min oppgave er å sette disse opp mot hverandre, måle og undersøke, for så å teste, måle og undersøke igjen, og teste igjen. Alt dette med virkelige brukere, brukerbehov og tjenester!

Hvilket tips ville jeg gitt meg selv i starten av oppdraget?

Vær deg selv og vær nysgjerrig, spør hvorfor og tør å utfordre etablerte “sannheter” basert på, vi vil ha det slik fordi slik var det i den gamle løsningen.

1-Dec

Today's posts

Welcome back to Bekk Christmas

Økonomi + skam = </3

What do you do when your favourite open source project removes a feature you use?

Visual redundancy

Introduction to Rust

Dagens Designtips