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

Hvem er jeg?

Citona Marie Rygg

30 år gammel

Kommer fra Oslo

Studerte interaksjonsdesign ved Westerdals og Universitetet i Oslo

Jobbet som designer i 2,5 år

Hvorfor ble jeg designer? Jo jeg har alltid vært veldig glad i teknologi og datamaskiner, men også i design. Som liten drømte jeg om å bli både smykke - og klesdesigner. Men motebransjen fristet ikke sånn veldig. Så da jeg fant ut at jeg kunne kombinere teknologi + design så var jeg solgt.

Akkurat nå jobber jeg med sparing hos SpareBank 1 og det har jeg gjort i 2 år. Det er et veldig spennende domene. Det er jo noe de aller fleste vet at de burde gjøre, men av ulike årsaker ikke helt klarer å komme i gang med. Litt som trening egentlig. Og så er det jo veldig nyttig for meg personlig å lære om, så det er jo en bonus.

Hva gjør jeg?

Arbeidsoppgavene mine er veldig varierte. Jeg jobber med alt fra målsetting, prosess, innsikt, skisser, forankring, atferdsanalyse, samarbeid med utviklere +++ Det er noe av det jeg synes er gøyest med å være ute i arbeidslivet - det er mye som skal være på plass rundt for at man skal klare å levere gode løsninger ut til brukerne. Dette kan tidvis være frustrerende når man bare ønsker å lage gode løsninger for brukerne, men det er så innmari gøy når det funker. Ingenting slår følelsen av når man sammen som team samarbeider, har eierskap og lærer om brukerne. Det er ikke alltid det går, men de gangene vi får det til er det utrolig gøy.

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

Slutt å hopp rett inn i Figma! Selv om jeg vet dette veldig godt fra studie og har masse erfaring med at det ikke lønner seg å gå rett ned i detaljene, tar jeg meg selv i å gjøre det ganske ofte allikevel. Jeg tror det har litt å gjøre med at det er så enkelt å bygge noe der fordi vi har et designsystem, så da skipper jeg ofte enkle wireframes og papirskisser - ikke bra! Det er viktig å huske at skisser egentlig kun er et kommunikasjonsverktøy. Enten det er å kommunisere med brukere for å avdekke deres behov, om det er med forrretning for å få forankret det man skal lage eller om det er med utviklere for å sammen finne ut av hvordan man skal lage det. I veldig mange av disse tilfellene er det raksere og enklere, i min erfaring, å bruke enklere skisser. Da slipper man diskusjoner om detaljer som ikke er viktige og fokusert på det man vil oppnå - enten det er forankring, testing eller utvikling. Jeg tar meg også ofte selv i å bli veldig opphengt i små detaljer, som tar alt for mye tid i forhold til hvilken verdi det gir.

Dagens designtips

Most software processes can be distilled down to a couple of discrete steps:

Gather data

Aggregate to something manageable

Examine the data and decide what actions must be taken

Execute the operations

These steps, or phases, are true for both the smallest and largest processes. A process here is defined as “a series of actions or steps taken in order to achieve a particular end,” and this description holds true for both small pure functions and large business workflows.

More often than not, people don’t actually reflect on these issues and just interleave all the steps. There are, however, good reasons why you might want to extract these to distinct phases, or at least identify them and make use of their properties.

Before we go into details for the steps, we look at how a typical function might be constructed and identify where the boundaries between each steps.

I wrote the function that way to make each step easily distinguishable, although people tend to shorten functions to avoid redundancy and rather writes something like the following.

While it’s a lot terser, the different steps are interleaved, making it more difficult to extract just a portion of the process, identifying the business rules, and so on. As the process becomes more complex, this can often result in difficult to understand code.

Now that we’ve looked at a concrete example, it’s time to describe the steps in more detail.

Gather/collect data: The process of retrieving all the data you need in order to decide what to do. These values can come from function parameters, or they can be fetched from external sources as databases and remote APIs. For many processes, it can even be a combination of data from several sources.

Aggregate/calculate data: When we have all the data we need, we need to massage it to make it more manageable by combining datasets, filtering, converting, cleaning, calculating and so on. We do this to make the next step easier easier to read, write and reason about.

Decide: Once data is in a format that’s easy to process, we can look at it and decide what to do. This is the business rules, e.g. “if this then that”. This is the actual important part, while the other steps is just necessary cruft to make the decision possible and to put it in effect.

Act/execute: Given that we have decided what to do, we need to actually perform the operation. This typically involves writing to databases, sending emails, calling external APIs and so on.

Describing the above steps should come as no surprise, and most experienced developers will probably go “well, duh!”. Many will probably also state that it’s not that simple in the real world as we need to do error handling, performance optimization and so on – And I totally agree. This post is to reflect on the distinct phases in a process and their properties to help us develop, refactor and test such processes.

We could describe any process with the following function:

While most type systems don’t allow us to describe many properties of these functions, we can discuss them in prose.

gather: Often a mix of pure and impure; things that is already fetched (like parameters) are pure, while things we need to fetch from other sources is impure. In general, we’ll say that this step is impure. On the other hand, it will never mutate any data, only read data. You should be able to call this function with all possible parameters, ignoring all results, and the world still looks exactly the same.

aggregate: Combines values to a more actionable format. Given the same data, it will always return the same result. The step is pure, and can be memoized for instance. This is why I like to think of gather and aggregate as distinct phases. Pure functions are easy to reason about and test, so the more you’re able to encode as pure functions, the better.

decide: Only looks at the aggregated data and never writes any data, and is thus a pure function. This is also where most domain logic/business rules reside. Reducing this to a single pure step makes it trivially testable. Nothing has to be mocked, and the core of the domain becomes very understandable. As this is the main part that is of interest to the outside, keeping it pure, separate, tested and documented is great for communicating with users of the system.

act: Performs the decided operations and is definitely not pure. This is the only part of the process which mutates data. It will only use data which is added by the prior decision step, and it will execute the effect.

To summarize: gather : queries the world, no effects on the world aggregate: pure – no contact with the world decide: pure – no contact with the world act: doesn’t query the world, only executes decided effects, no side-effects

Testing gather requires us to mock the sources it fetches data from. But it might be easier to test gather >> aggregate rather than gather alone, and that’s fine – testing aggregate alone doesn’t always give much benefit. Similarly, testing act requires us to mock the sources which is mutated. Testing decide is “trivial” as it doesn’t read or write to the outside world.

Since aggregate and decide are pure functions, you might just have one function which does both, or you might not have any of them at all… A function which doesn’t do anything and just returns the value passed into it is called the identity function. We can use this to “skip” steps where we don’t need to look at or change the data

You can run gather >> aggregate >> decide until hell freezes over, and you won’t have had any effect on the world! This is a really nice property.

Let’s look at some silly examples to show that our makeProcess is able to describe regular functions.

Let’s look at how we could split these steps out of sendVotingReminder, but first we need to convert it to F#.

Encoding the possible decisions as a closed set is good both for documentation and robustness.

Remember that act shouldn’t query the outside world, so the only information it has available is what is available in Action. We could drop the NoActionBecauseUserTooYoung by using an Option if we need 0 or 1 action, or support 0 to many actions by returning a list of actions.

Sometimes it makes sense to let aggregate return more information to decide like the fact that a user is too young. But having a “no-op” case is often a very useful feature (like the NullObject pattern in OOP, the identity function or empty for Monoid), so we’ll leave it in.

We can start by creating inner functions for the parts we wish to extract

This is still the same function, and we can now reduce it to just its parts

Just looking at the types, we can pretty much guess what’s going on. It’s pretty easy to describe decide to business users, and pretty easy to test in isolation. It’s actually pretty easy to test each part in isolation as necessary if the impure steps accepts functions for communication with their dependencies.

We’ll look at a final example with just the end result. We create an API which returns dummy data for our example.

Now we’re ready to build our process, and the first step is to gather all the data needed.

After all data is gathered, we need to process it. It is often useful to create a new structure to hold our information. This is pure, so given the same arguments, it will always return the same result, and it will never have any effects on the outside world.

When we have our data, we’re ready to make decisions about what to do. Making the decision, the important business logic, is pure, and all possible outcomes are typed in the result of the function.

Pure functions doesn’t actually “do” anything, so given our decisions, we need to modify the world. Everything we need to execute the decisision should be stored in the data passed to our execute function from the decision.

And finally, we’ll create our process. Our process will then have the type userId: int -> actionResult: string

Let’s test our code

All this might look like complete overkill, and in many cases it is. But recognizing that processes, from the smallest + function, to the largest business processes, all share the same general steps with the same properties is powerful knowledge. It makes it easier to extract parts that can be reused by other processes, parts that should be tested more thoroughly and so on.

In many cases you only want to extract a single part for some reason, like the business logic. The important thing is to remember that these are common boundaries that are often quite natural to extract and often yields some benefits as processes becomes more complex. Just having these distinct blocks in functions can be beneficial as it’s easier to reason about and reduces spaghetti code.

Gather, Aggregate, Decide, Act

Digital nudging can sure be used for great evil, but it can also be used to help your users. Ensure positive effects for all of your users by universally designing your digital nudges!

Digital nudging is explained as guiding a user's behavior and choices through user-interface design. It can be used for many purposes, e.g. making a user add the correct items to their online shopping cart or to make an application form easier to navigate. This could be accomplished by using for example wording, colors or placement and sizing of elements. Digital nudging can help the user reach better and faster decisions. It could also ease normally demanding tasks by for example reducing the completion time. It can therefore be of great value for the user to be nudged.

There are several ways to navigate online. Most common is seeing what is in front of you on the screen, and using your keyboard and mouse to navigate. Alternatives to visual navigation exist. For example will a user with vision impairments likely use a screen reader, which is used to interpret the information on the screen into audio. Not all visual information is possible to effectively or precisely interpret and is therefore not possible to pass on to the user. Consequently, digital nudges do not necessarily benefit all users if they rely on, for example, vision, to be effective.

Example

Imagine you are a designer in charge of a website that deals with several types of applications and forms. Then, imagine this hypothetical scenario:

There are three different applications that might be relevant for the user: application 1, application 2 and application 3.

It is difficult for the user to navigate and determine which application they should submit. In many cases, users submit the wrong application.

You have collected data which tells you that application 1 will be the correct option for 97.5% of the users.

Based on this, you would like to nudge the users towards application 1, and you start composing two different sketches. Disclaimer: you might find several choices that you, possibly an actual designer, would not make, but it will have to do for illustration purposes. Also, for the sake of keeping scope, this example will focus on screen readers and a limited amount of nudging techniques.

Sketch 1

Focusing on a screen reader as the mean to navigate the website, there are some things to take note of:

The application 1-button will be presented first for the user both visually and by screen reader.

Information about color will not be communicated by a screen reader. The user will not know that one button is greener and more inviting than the other.

We will have more of a listing of options, and there are few elements that separate the three options from a screen readers’ perspective. This means that the first button will not be much more prominent than the others.

The text itself could also be used to nudge, but seeing that it is a lot of text and all put together, it could lead to information overload or that the user does not bother to read all of it. 


Sketch 2

Some things one can take note of from sketch 2, also here from a screen readers' perspective:

The application 1-button is more separated from the other options by using text, which could make it more prominent. 

The text itself could also be used to nudge the user through wording and tone of voice. The separation of it might lead to the user not being as overwhelmed and taking the time to read it (compared to sketch 1).

The application 1-button is made visually bigger than the others. As with sketch 1, it is also here important to remember that a screen reader will not provide information about the size or color of the button.

Side-note: The order of the elements will for the screen reader depend on how the HTML code is structured. In these examples, it is assumed that the different elements (HTML-tags and other relevant attributes) produces the same order for the screen reader as described in the image caption. 

Conclusion

When not benefitting from the positive effects of nudging, some users might find themselves in additional shortcomings in their everyday lives compared to others. This highlights the importance of universal design also in the context of digital nudging - it is important to design nudges that will have favorable effects despite disabilities or impairments. 

To finalize, i would like to emphasize that the point of this article is not to tell you that you should not use colors or size to nudge; it simply means that it is important to be aware that for some users, wording, tone of voice and order would have greater impact. Hopefully, this new knowledge will make it somewhat easier to give this area some attention in upcoming projects. Good luck!

Digital nudging + universal design = <3

Det meldes jevnlig om nye sikkerhetshendelser, og det er ingen tvil om at sikkerhet har fått fast plass på dagsorden. Likevel kan det være utfordrende å få prioritert sikkerhet i hverdagen. Som et steg i riktig retning, må vi begynne å bevege oss bort fra at sikkerhet ses på som en "av-og-til"-aktivitet og mot at det jobbes med kontinuerlig. 

I tidligere artikler har vi i sikkerhetsmiljøet i Bekk snakket om farene ved uhåndtert sikkerhetsgjeld og uansvarlig produktutvikling. Som en ledd i dette vil vi slå et slag for tverrfaglige team, som inkluderer en sikkerhetsutvikler! 

Få sikkerhetskompetanse inn i teamene

Over lengre tid har Bekk jobbet i tverrfaglige team, og har observert fordelene med å kombinere ulike fagområder og kompetanser for å løse problemer på best mulig måte. Dagens stadig voksende trusselbilde innenfor sikkerhet krever at det settes av dedikert tid til sikkerhetsoppgaver i teamet og at sikkerhetskompetanse blir en større del av det tverrfaglige samarbeidet. Det å ha sikkerhetskompetanse i teamene og ikke bare som en ekstern ressurs, tror vi ...

hjelper teamet å tenke på sikkerhet allerede i begynnelsen av utviklingsprosessen og dermed blir løsningene sikrere.



fører til bedre sikkerhet fordi de som jobber med løsningene hver dag har best oversikt over hvilke utfordringer løsningen har og hvordan man sikrer den best.



sørger for bedre oppfølging og enklere kommunikasjon rundt sikkerhetstiltak i tjenestene ved at de involverte kjenner til koden, infrastrukturen og domenet.



sørger for høyere autonomitet og raskere respons ved eventuelle sikkerhetshendelser.


Ved å gjøre en sikkerhetsutvikler til en del av teamet skaper man fokus og bevissthet rundt dette i hverdagen. Vi mener at alle som jobber som utviklere i dag også kan bli en sikkerhetsutvikler:



“En sikkerhetsutvikler er en utvikler som tar ansvar og eierskap til sikkerhet og personvern i teamet.”



Sikkerhetsgjeld i tjenester må nedbetales jevnlig

Tradisjonelt har ikke sikkerhet vært jobbet med kontinuerlig. Vi utviklere snakker ofte om teknisk gjeld og hvordan vi må jobbe kontinuerlig for å redusere dette. Men vi snakker ikke nok om sikkerhetsgjeld, og hvordan en årlig sikkerhetsgjennomgang eller risikovurdering ikke er tilstrekkelig for å opprettholde god kvalitet og sikre systemer. Derfor er det viktig at sikkerhet prioriteres jevnlig, og ligger i backlogen. 

Oppgaver som en sikkerhetsutvikler kan ta for seg er mange: sørge for sikkerhetstiltak rundt kodebasen, sikre verdikjeden til produktet, jobbe med sikker programvareutviklingsprosess, sørge for innebygd personvern i produktet, med mer. Målet er å spre god sikkerhetskultur og generelt øke bevisstheten på sikkerhet i alle deler av utviklingsprosessen og i organisasjonen.


Hvis du har lyst til å ta et skritt nærmere mer hands-on sikkerhet i 2023 — prøv deg som sikkerhetsutvikler!

Bli en sikkerhetsutvikler!

Det finnes hovedsaklig tre måter å utvikle digitale løsninger for mobil på:

Native apputvikling med Swift (iOS) eller Kotlin (Android)

Kryssplattform, f. eks React Native eller Flutter

Hybridapper, med mobiltilpassede webløsninger i et nativeskall

La det være ingen tvil. Native mobilapplikasjoner gir, på sitt beste, knallgode brukeropplevelser.

Dessverre er det også dyrt og relativt komplisert.

Altfor ofte velges native teknologi ukritisk der kryssplattform eller hybridapper kunne gitt en billigere og raskere vei til mål.

I denne teksten ønsker jeg å rette søkelys på noen problematiske sider ved nativeutvikling som vi snakker for lite om.

Fart og flyt

Utviklingsfart er ikke en kvalitetene nativeutvikling kan skryte av. Både web- og backendutvikling har hatt langt mer tid på å modnes og har følgelig kommet lenger i utviklingen. Feedbackloopene er kortere, det er flere etablerte konvensjoner og arbeidet går rett og slett mer effektivt.

I tillegg har vi det kvelende faktum at det må utvikles separat til hver plattform. Se for deg at du trengte et webteam med én Chrome-utvikler, én Safari-utvikler, en Firefox-utvikler?

Senest forrige uke hørte jeg i en presentasjonen at «denne funksjonaliteten blir nok i et webview — da vi ikke har tid til å lage det i native» (implisitt at det tar lenger tid).

At tech-gigantene Google og Meta satser hardt på sine kryssplattformløsninger Flutter og React Native er også verdt å merke seg.

Tilgang på kompetanse

Nativeutvikling bruker dedikerte kodespråk og IDE-er. Dette er spesialistkompetanse som en liten andel av det norske utviklermarkedet besitter. Som i bransjen forøvrig, er det rett og slett for mange jobber og for få kvaliserte folk.

Skal du rekruttere dyktige iOS- eller Android-spesialister på det åpne markedet bør du dermed ha stor lommebok eller en helt rå merkevare — eller helst begge deler.

Jeg har selv snakket med teknologiledere i store, norske virksomheter som strever med å finne kvalifiserte apputviklere. Det oppleves som enda vanskeligere enn den allerede krevende rekrutteringssituasjonen i bransjen for tiden.

iOS-utvikler vs Android-utvikler vs apputvikler

I tillegg er det gjerne ofte slik at mobilutviklere er gode på enten iOS- eller Android-utvikling, og svært sjelden behersker begge plattformer.

Det resulterer ofte i dedikerte utviklingsteam for hver plattform. Dette gir flere konsekvenser:

For å unngå høy trikkefaktor trenger du en kritisk mengde utviklere på hver plattform. Det er dyrt i drift, og krevende bemanningsmessig.

Hver feature blir utviklet av minst to forskjellige personer.

Det er ikke nødvendigvis sånn at funksjonaliteten blir sluppet samtidig på begge plattformer.

Du risikerer forskjeller i oppførsel mellom plattformene. Plattformene er forskjellige og appen bør selvfølgelig tilpasses lokale forhold, men oftere enn man skulle tro ender man opp med forskjeller også i forretningslogikk.

I min erfaring er også ofte sånn at mobilspesialistene verken har motivasjon for eller kompetanse til å gjøre web- eller backendarbeid. Da er du avhengig av at organisasjonen din har en konstant strøm av mobiloppgaver for å unngå periodevis tomgang.

Akkurat som bransjen bør bort fra dedikerte backend- og frontendutviklere som ikke ønsker eller evner å se helheten vi som utviklere leverer — bør vi bort fra spesialiserte mobilutviklere som kun bryr seg om den dyre duppedingsen kunden har i lomma.

Hvordan implementere produktteam?

En annen utfordring flere større organisasjoner sliter med er hvordan man unngår et sentralt appteam som mottar bestillinger fra andre produktteam.

Det er en seriøs torpedo i siden på strategien om tverrfaglige, autonome produktteam dersom all utvikling ut mot sluttbrukerne dine skjer i et separat team som fokuserer hovedsaklig på kanalen (appen) og ikke produktet.

De fleste er enige at det ikke er heldig med et webteam som konsumerer endepunkter laget av backendteamet, som igjen leverer bestillinger til databaseteamet.

Sånn jobber vi ikke lenger. Det er vi ferdige med. Men i mobilverdenen blir det likevel ofte sånn.

React Native som alternativ

I noen tilfeller kan det være riktig å likevel velge nativeutvikling. Caset styrkes f.eks hvis du har helt unike krav til ytelse eller brukeropplevelse (les: du skal lage en ny Snapchat, Tik-Tok eller Candy Crush). Eller hvis du har så store budsjetter at økonomi og fleksibilitet i teamriggen ikke spiller noen rolle.

For oss andre finnes det heldigvis gode alternativer.

Selv har jeg gode erfaringer med React Native. La oss se litt på utfordringene nevnt over, sett i kontekst av kryssplattformutvikling med JavaScript og React Native:

Fart
I min erfaring sparer man nærmere 45% av arbeidet med React Native. Man må fremdeles påregne noe plattformspesifikk kode, men hoveddelen av arbeidet kan nå gjøres én gang og ikke to.

Besparelsen i både tid og penger som dette utgjør med et stort utviklingsteam over tid er vanskelig å overdrive!

Tilgang på kompetanse
Det er dramatisk mange flere i markedet med kompetanse på JavaScript/TypeScript og React. Med en langt større pool av ressurser blir rekrutteringen enklere. Mange webeksperter uten mobilerfaring synes kanskje det er et spennende karrieresteg å prøve seg på mobilutvikling, uten å måtte omskoleres totalt..?

Jeg har personlig onboardet et titalls webutviklere til mobilutvikling på denne måten og sett på kloss hold hvor raskt folk kan bli produktive i det som tross alt er et helt nytt univers.

Spesialister vs generalister
Når en habil utvikler kan bli effektiv på mobilplattformen på uker og dager, medfører det en praktisk fleksibilitet inn i teamriggen. Trenger man litt ekstra krutt på mobil et halvår? Kanskje finnes det et team som kan avse en utvikler en periode.

Det er også fordelaktig at dem som utvikler appfunksjonalitet også har erfaring fra andre applikasjoner i sjappa. Kanskje den samme personen kan skrive både frontend- og backendkoden?

Produktteamorganisering
Når mobilutvikling bare blir enda en disiplin den moderne utvikler kan beherske, kan i teorien hele teamet bidra på mobilutviklingen heller enn at separate utviklere gjør dette alene.

Avsluttende ord

På mitt forrige oppdrag, bidro 25 utviklere på tvers av 5 team inn i en felles appkodebase. React Native som verktøy bidro til høyere utviklingsfart, mer kompetansedeling, enklere onboarding og rekruttering. Kort sagt, var det som teknologi avgjørende for at vi lykkes med digital produktutvikling.

I den norske tekniske debatten har det de senere årene blitt skrevet noen kritiske tekster om kryssplattform generelt og React Native spesielt. Felles for disse innleggene er at skribenten ofte kommer fra spesialiserte nativeapp-miljøer. Disse selskapenes forretningsmodell står og faller på at det er store behov for dyr og treg nativeutvikling i markedet.

Det er uheldig når teknologien i seg selv blir et middel, heller enn å velge riktig verktøy for å oppnå sine mål på en tids- og kostnadseffektiv måte.

Det taper vi alle på.

22-Dec

Today's posts

Dagens designtips

Gather, Aggregate, Decide, Act

Digital nudging + universal design = <3

Bli en sikkerhetsutvikler!

Har du råd til native mobilutvikling?