Et første forsøk på å beskrive hva en ux'er bør kunne - inspirert av friskt foredrag av Fredrik Matheson på høstens Fryd. 

Er det virkelig sånn at vi ikke har noen klare beskrivelser av hva en ux'ers fagområde består av? Ja, det er det kanskje. Burde vi ha det? Vel, det har vel ofte virket tryggere om noen kunne pekt helt konkret på hva de forventer av oss som ux-designere. 

Ingen fasit, men noen første tanker (som absolutt må itereres videre på) - her er mine 6 ting en designer bør kunne. 

For en drøy måned siden satt jeg i kantina vår i Skur 39 og hørte Fredrik Matheson rante om faget vårt – ux-faget – fra scenen på Fryd. Det er ungt, det er udefinert – og han slengte ut en påstand jeg tok som en utfordring: «vi vet ikke en gang hva vi bør kunne som ux’ere – i hvilket annet fag er det sånn?»

Hm, tenkte jeg. Er det sånn? Vet jeg virkelig ikke hva en ux’er bør kunne? Jeg som ikke så sjelden vurderer folk på intervju, jeg er med på å ta i mot nye kull designere hver høst og gir dem en innføring i jobben deres før de sendes ut til kunder – vet ikke jeg hva en ux’er bør kunne? Og mens jeg satt der og tenkte, sank det i meg. For det er sant, som Fredrik sier (som det jo ofte er), at vi har ingen klare parametere å vurdere kandidatene etter, ingen sjekkliste å krysse av på av de ulike evnene og kunnskapene som trengs i jobben vår, ingen liste vi går igjennom når vi setter opp oppstartsopplegget vårt hver høst for å passe på at alle får den faglige inputen vi mener de trenger for å kunne gjøre jobben sin. Ingen liste i Bekk, og ingen i bransjen vår. Hekk, vi er jo knapt enige om hva ux egentlig innebærer, eller hva som er riktig tittel på oss.

Men, tenkte jeg. Det er jo ikke helt fritt vilt heller. Det er jo ikke hva som helst eller ingenting som definerer oss. Og jeg har jo en følelse, om ikke en distinkt bevissthet, av hva en god ux-designer gjør og er god på. Og typisk nok, når jeg hører Fredrik rumle om fag og filosofi, får jeg en idé.

Jeg burde jo kunne beskrive litt mer eksplisitt, den «følelsen» av hva en designer bør kunne.

Åpenbart ikke som noe forsøk på en objektiv fasit – siden problemet er at vi nettopp mangler det. Men som en subjektiv formening, i en rolle hvor jeg ansetter og oppdrar designere – det bør jeg jo rett og slett ha. Om ikke annet for å bli mer bevisst hva som skal til for å levere det vi trenger å levere. Og som en god designer, har jeg ingen problem med å ta en idé og la den leve litt før jeg låser meg til en løsning! Så her begynner jeg bare på noe, tenker jeg, og så skal jeg la det få småkoke en god stund, og foredles over tid. Nå er tankeprosessen i det minste i gang. Takk, Fredrik!

Min foreløpige liste over de grunnleggende tingene jeg mener en designer* må kunne:

Nummer 1: Brukeradferd

Uten å forstå eller å kunne jobbe med brukeradferd, stopper nesten alt en ux-designer gjør, opp. Det er kjernen i brukersentrering: å kunne kartlegge og tolke brukerbehov, beskrive behov og adferd, og så kunne designe for å dekke behovene og påvirke adferden.

Aktiviteter som styrker forståelse for brukeradferd: 

Planlegge, gjennomføre og oppsummere brukerintervjuer og brukerobservasjon. Både av folk som bruker tjenesten du jobber med og ikke, som utviser adferden du skal påvirke og ikke. Når du oppsummerer funn, øv deg på å syntetisere, ikke analysere – øv deg på å sette enkeltdelene du finner sammen til et helhet, heller enn å liste ut enkeltfunn.

Nummer 2: Affordance

Det mangler vel et godt norsk ord for det, men altså et objekts uttrykk for hvordan det kan bli brukt. Som et dørhåndtak som tydelig viser om du skal dra eller dytte på døra for å åpne den. For alle oss som jobber digitalt, blir det jo spesielt to-dimensjonal visuell affordance vi må være gode på. Og tatt helt ut i det ekstreme kunne man kanskje sagt at på en nettside med perfekt affordance ville man aldri trengt å ha en ledetekst eller label på noenting. Det blir selvfølgelig tullete å si – det er jo ikke som om vi hverken kan eller skal fjerne tekst fra nettsider og digitale løsninger. Men jeg tror det er et symptom på designet ditt at det ikke har god nok affordance, om du tar deg selv i å designe inn mye tekstlig forklaring på elementene en bruker skal interagere med.

Aktiviteter som styrker affordance-evnene dine: 

Brukertesting. Helt standard, formelle brukertester, hvor du lager et testoppsett med oppgaver, observerer opp i mot 10 forskjellige brukere prøve å løse oppgavene, hører hva de sier når du ber dem tenke høyt, og ser hva de sliter med og ikke. På både dine egne og andres løsninger. Sitter du ikke selv og designer på noen løsninger akkurat nå? Velg en hvilken som helst løsning, klikk deg igjennom, gjør deg opp en formening om hva som virker som viktige oppgaver å få løst gjennom løsningen, og kjøre en brukertest. Du kommer til å lære så mye!

Og når jeg først er inne på det med brukertesting: ikke glem å brukerteste for universell utforming. Å krysse av for kravene er en ting…og mange av oss outsourcer det rett til frontend-utviklerne om vi kan. Men du vet like godt som meg at den rampa arkitekten overlot til entreprenøren å fikse, for å etterleve kravene helt i siste liten…den gjør ikke helheten noen tjeneste. Om noen få uker begynner i uu-faggruppa her i Bekk, og det skal være min misjon gjennom 2022 å få brukertestet mer på uu, sånn at jeg virkelig kan lære meg hva som er en godt universelt utformet løsning og ikke.

Nummer 3: Prosess

Ja – du må være god på prosess. Det er sjelden vi jobber med utfordringer som er så enkle at du bare kan se på det, tenke deg litt om, og komme opp med svaret – ferdig. Enkeltproblemer i en løsning eller landskap du kjenner godt, kan helt klart løses gjennom å trekke frem svar fra erfaringsbanken…men tjenestene vi jobber med som helhet – de må vi kunne følge opp prosessuelt. Hva er riktig prosess? Det kommer selvfølgelig an på hva du skal levere, og teamet du jobber med. Men helt generelt vil jeg si, at som designer, må du kunne vite når det er riktig å utvide perspektivet og scopet, og når det er riktig å snevre det inn. Du må ha koll på din egen «double diamond» (som i den kontinuerlige leveranse-verdenen jeg lever i, egentlig er en rekke med ruter som aldri slutter) – du må vite når du skal åpne opp, og når du skal trekke sammen. Og så må du kunne involvere andre i denne rytmen. Dermed blir også fasilitering en del av det å kunne prosess. Igjen – det er sjelden jeg og mine kolleger jobber med oppgaver som er så enkle å løse at det holder at jeg setter meg alene og tenker og designer i vei, og kommer ut med svaret og kan be andre implementere det. Så å få til å få med seg andre på prosess er helt vesentlig for å kunne bidra godt som designer.

Aktiviteter som gjør deg bedre på prosess: 

Tja. Jeg vet faktisk ikke. Vi lærer jo vår isolerte design-prosess på skolen, mange av oss – og den har mye fundamentalt bygd inn i seg som vi får bruk for videre. Men så møter vi jo ofte en utviklingsprosess vi ikke helt har fått innsyn, der noen andres håndverk må styre i vel så stor grad som vårt. Og hva kan vi gjøre da, for å bli flinkere?

Jeg har veldig stor tro på refleksjonens kraft. Å tenke gjennom hva jeg gjør – og burde gjøre. Når jeg møter et team, en utfordring, et selskap, et domene, en oppgave…å tenke gjennom hvordan jeg vil levere på det, og finne frem til en løsning eller et svar, det hjelper meg. Å forestille meg hva jeg skal gjøre – både på kort og lang sikt, det er en slags øving.

Og – jeg tror jeg har fått øvd på prosess gjennom å skrive tilbud på konkrete oppdrag. Når jeg må telle antall folk jeg tror vi må være, liste opp aktiviteter jeg mener vi bør gjøre, og telle uker jeg tror det tar…ja, da får jeg tatt en ny runde på å bli bevisst hva jeg gjør, og hvorfor.

Retroer kan også hjelpe. Mange team-retroer handler fort om enkeltpunkter som har fungert bra og dårlig – men de kan også være tid vi tar oss for å snakke mer helhetlig om hvordan vi jobber. Hvordan flyter egentlig en brukerhistorie gjennom boardet vårt? Hva er egentlig ruter-rytmen vår? Diskuterer vi nok, diskuterer vi for mye? Kvalitetssikrer vi? Når og hvordan måler vi effekt?

Snakke om det, og så gjøre det, og så tenke over det. Det tror jeg er viktig.

Å! Og hold workshops! En workshop kan representere en mini-prosess; det finnes en eller annen utfordring som skal løses, det er noen aktiviteter vi må gjøre, og det er et eller annet resultat vi skal ha ut. Øv deg på prosess gjennom å planlegge workshoper – tenke igjennom hvilket resultat vi trenger, kvalitetssikre at det er riktig. Tenk på og test ut hvilke aktiviteter som kan bidra til det resultatet, og hvilke folk som må være med. Planlegg tidsbruk – og reflekter etterpå om det ble riktig, eller hvordan du bør justere det til neste gang. Og kjenn etter, når workshopen er over, og du har levert resultatet av den, om den funka, eller hva du kunne gjort bedre.

Nummer 4: Måle effekt

Du må kunne følge opp løsningen eller tjenesten din når den er tatt i bruk, og se om den faktisk gir det resultatet du trenger. Nei, jeg snakker ikke om brukervennlighet her – jeg mener faktisk endring i folks adferd eller forretning eller resultat. Det er mer konkret enn «folk er mer fornøyd nå enn før», men ikke nødvendigvis å peke på et resultat på en bunnlinje et sted heller. Det handler om å før du går i gang med å designe noe, å vite hvorfor en tjeneste eller løsning skal lages overhodet. Om svaret ikke finnes allerede, må du hjelpe til med å finne frem til det selv. Du må kunne definere hva en løsning skal gjøre – sånn at du kan sjekke etterpå om det gjør det. Et bra design er et design som løser et problem – på en god måte. Så du må ha koll på problemet, og du må kunne sjekke om problemet er løst etterpå, for å vite om du har gjort jobben eller ikke.

I det vi holder på med, er ikke nødvendigvis «problemet løst» ved første prodsetting. Oftere er vi på vei mot god problemløsning (forhåpentligvis), og må jobbe kontinuerlig for å stadig nærme oss et mål langt fremme. Det er for enkelt å «digitalisere» - lage en digital løsning der det før bare var papir, peke på løsningen når den er ferdig og si seg fornøyd. Den faktiske digitaliseringen har skjedd når en kritisk masse faktisk får gjort den effektiviseringen eller kvalitetsheving løsningen skal bidra til – det holder ikke at det bare «finnes en app for det». Er det ingen som bruker appen, er vi like langt.

Å sette effektmål som er relevante, som lar seg måle, og som vi kan styre etter er vanskelig. Det krever øving. Som designer bør du som minimum være bevisst betydningen av effektmåling, og klar over at jobben ikke er gjort før effekten er vist (men det er også bra å vite når det er på tide å gå videre). Du bør sette deg inn i hvert fall ett av de vanligste verktøyene for måling av adferd på nett, og kunne gjøre noen analyser på de viktigste tallene. Hva er de viktigste tallene? Det er her det hjelper å ha satt seg inn i hvilket problem det du lager egentlig skal løse. Svaret ligger der et sted.

Aktiviteter du kan gjøre for å bli bedre på måling av effekt: 

Les litt teori om det. Jeg er egentlig ikke en forkjemper for veldig teoretiske øvelser når det kommer til design – jeg definerer design aller mest som et håndverk som må praktiseres. Men i alle håndverk er det noe teori – og hvordan konverteringsmålinger fungerer, og hvordan trafikk på en digital løsningen måles i de vanligste verktøyene…jupp, det er noe teoretisk kunnskap der du kan lese deg opp på, enkelt og greit.

Les deg også opp på OKR. Bare gjør det. Gjør det sånn at du skjønner hva det er snakk om når produkteieren din sier at de har fått beskjed om at nå skal alle følge det. Gjør det sånn at du har et utgangspunkt for å diskutere hva OKR’ene kunne vært for løsningen eller tjenesten du og teamet ditt jobber med nå. Og ikke gift deg med det konkrete rammeverket OKR. Husk på at det handler om målstyring, som generelt er bra, for det definerer hensikten med det vi gjør – og det trenger du som designer, og at det handler om å måle effekten av det vi gjør – som forteller deg om vi er på vei mot den hensikten.

I tillegg til å utøve det! For det er jo et håndverk. Sett deg noen mål, bittesmå, men konkrete, og begynn å måle dem allerede nå.

Nummer 5: Forretningsmekanismer

Det er et fryktelig dårlig ord. Forferdelig. Det er så lite presist. Så her må du virkelig bare være med på at denne listen bare er en idé i startgropen, om du skal greie å bli med videre. Det jeg mener, er:

Lær deg å forstå hva markedsdriverne er, for den bransjen selskapet du skal hjelpe. Om du jobber hos en virksomhet i det offentlige: forstå den grunnleggende forvaltningen av den etaten du jobber hos – hva styrer prioriteringene der? Hvordan påvirker politikken din etat? Lær deg å kartlegge – helt overordnet – hva som er de største truslene eller utfordringene for selskapet (uten å glemme at det finnes folk kan det veldig mye bedre enn deg). Ha et (forenklet og overordnet) bilde av hva som driver kostnadene der, og hva som representerer inntjening eller måloppnåelse. Dette vil hjelpe deg å velge ut de ideene som gir mest verdi. Å vurdere hvilke forslag som vil bidra best til det mandatet eller strategien virksomheten styrer etter. 

Aktiviteter som vil hjelpe deg å bli bedre på dette: 

En enkel swot-analyse er ofte veldig opplysende. Om du kan – gjør den med en fra forretningssiden, sånn at du får utvidet perspektivet på hvilke potensielle styrker og svakheter, muligheter og trusler som kan finnes. Dra opp verdikjeden for det du jobber med – og i stedet for å fokusere mest på hva sluttbrukeren ønsker seg, ta innover deg hva det krever av virksomheten å levere. Og ikke minst: snakk med folk i lederroller der du er om det de holder på med og er opptatt av. Ikke hva de ønsker seg av digitale løsninger – men hva de holder øye med, hva de rapporterer på, hva de bekymrer seg over, og hva de feirer.

Nummer 6: Enkel estetikk

Som ux’er må du kunne gjenkjenne helt enkle komposisjonsregler. Gjenkjenne balanse, gjenkjenne proporsjonalitet, gjenkjenne visuelt støy. Og huske på at det er et eget fagfelt. Vi gjør oss selv en bjørnetjeneste som designere når vi prøver å dekke for bredt i stedet for å be om at flere kommer til for bidra med det de kan.

Aktiviteter som trener dette blikket: 

Diskutér det visuelle med en grafisk designer/visuell designer - ofte! Få dem til å beskrive hva de ser, og legg merke til hvilke ting de fokuserer på og kommenterer. Å jobbe med flinke grafiske designere er det som aller mest har hjulpet meg. 

Hva tenker du?

Åkei - her er det altså. Mitt første utkast på hva jeg mener en ux-designer bør kunne. Den må itereres på. Det vet jeg. Det må ideer alltid. Men det har hjulpet masse å bare begynne å tenke på det! Og det neste jeg vet jeg kommer til å trenge nå, er å diskutere det og få innspill. Så: hva tenker du? Hva mener du er kjernekompetanse vi ux-designere må ha?





*Designere kommer i mange ulike varianter – innen for mange ulike fagfelt. De jeg tenker på i denne artikkelen er de som glir mellom rollene tjenestedesignere, ux-designere, strategiske designere, business designere, interaksjonsdesignere og design researchere…du vet, de på det brede spekteret der, som ofte ikke helt vet hva de er.

Hva bør en designer kunne? 

Compound component is a react design pattern popular in UI libraries such as Chakra, Reach, Semantic and Material. It allows us to write a declarative and flexible API for complex components that implicitly share a state. Today we'll look at an introduction and a slightly more complex example of the patthern

I first discovered this pattern when attempting to create a customizable and reusable accordion component. Up until then, I'd usually see them implemented with an api similar to this:

With this component I was faced with two problems: I needed an icon in my header, not just text and I needed to style my header differently than its base styling. For the latter, I could always inspect the component and style the class directly, but I feel that's breaking into the encapsulation of the api. This is a common occurence when designing reusable react components: one component with multiple parts each with its own demand for customizability. What I did need was a pattern where each part of a component was exposed for customization. Something like this:



To achieve this my components had to share state and communicate. In particular, clicking the header had to open and close the panel. This is already functionally similar to a basic html component:

Which also has an implicitly shared state between the components, clicking one will affect the others. 

This can be achieved in numerous ways, the two most common being React.cloneElement and the Context api. The latter of which I'd recommended and is what we'll look at now:



Let's go over it:

1. We define a shared context containing the state of the component and possible actions. This can be extended to share more state, like component id's for aria-properties.

2. We define a "provider" component, one that has to wrap all other components and supply the context. Usually this component contains most of the logic and handles the orchestration of state. In more complex components we could also define a reducer. It wraps all children in a Provider for the context. This means that on their own, Header and Panel don't function.

3. We create a context hook to simplify it's use and handle undefined context in case someone forgot to wrap their components in Accordion. This is a common and recommended practice. (Check out  Kent C. Dodds' article if you'd like to read more)

4. We define our two compound components, each of which consume the context. The Header has an onClick flipping the state. And the Panel either shows or hides its content depending on the state.

We use it like so:

However for a "proper" accordion we should support multiple accordions, and keep track of which ones are open and not. That can't be too hard right? Let's attempt to create a component with an API looking like this:

For the astute reader you may have noticed this is not a trivial extension. Our AccordionGroup (which is the new level of Provider component) needs to keep track of how many Accordions it has as children, wether they are open or not, and each child must have a way to know if it should be open or not and toggle itself. To solve this we'll attempt a subscription based design.

For this we need a hook for each Accordion, which will alert the AccordionGroup that it has rendered within the Context and should add it to the list of Accordions. This hook should also supply the Accordion with some way of knowing wether it should be open or not. This hook should alert the AccordionGroup if it un-renders from the page, so the Group can remove it. Lastly we need a list of all Accordions within the AccordionGroup, and logic to keep track of which Accordion is open.

We'll start by defining the state we'll need

Now we could have simply had an "accordion" and "setAccordion" to control all the state, but I prefer to abstract such logic away from subcomponents as much as possible and supply simple functions. In this case, accordions will be a list of accordions with id's and wether or not they are open. (I'm aware that a simpler implementation exist where you only keep a list of open accordions, but just roll with it aight? ). We also add the usual context hook.

What I've also added here are subscribe and unsubscribe functions that subcomponents can run when mounting and unmounting the DOM. These functions will add and remove accordions from the list so that at any point we will know exactly how many accordions there are as children, and their respective state.

Now that we've defined the context, we will, like last time, also add a Provider component, whos responsibility will be state logic and the context provider:


A bit more happening here. This is where we abstract handling of the state away from subcomponents, and only supply helper-functions with minimal interface.

Now finally, where most of the magic happens. We need a hook to handle the subscription and unsubscription of each child. As we will also see, it will abstract away even more of the state logic to clean up the Accordion components.


In this hook we leverage the useEffect hook with an empty dependency array to only run the hook on render. We also return a lambda from useEffect, which is ran when the component unmounts, also called a clean-up function. Doing this a component using this hook can add itself to the list upon mounting, and remove itself upon unmounting. Also added to this hook is further abstraction away from the raw context state and id, so that all it returns to the component are functions only capable of the actions it needs. 

Lastly, we replace the old state of the Accordion component with a call to the new hook:

Et voila! We have now looked at an introduction to compound components. At first we created a basic component based on a pattern you can reuse for a wide array of more complex use cases. We've seen how it exposes internal components and allows us to more directly customize them, rather than having them locked behind a high-level definition. We also looked at a more complex pattern. Where sharing the existence of separate components was important. We looked at how we could use useEffect to subscribe and unsubscribe components, how to leverage hooks to abstract complex state logic and how to allow for communication across components.

Compound components is a very powerful tool, and something anyone wanting to create components made for reusability and future-proofing should have in the toolbox.



Here is the full code

https://codesandbox.io/s/react-subscription-compound-component-w6926?file=/src/App.tsx

Subscription pattern with Compound components in React

Hvordan spenne beina på et IT-prosjekt? (Del 1 av 3) - Hyppige endringer av kravspekken

Have you heard about load testing but never really got started? Maybe you’re deploying an app to Kubernetes and have to fill out “cpu and memory requirements” and don't know how to recreate user activity? Or you’ve implemented a new feature but you’re unsure how your API handles it?

Load testing is here to save you! Here's a simple quick start guide to locust to get you started. 

What is locust?

Locust is a nice load testing tool using python. It can swarm your app with TONS of request or fewer easily. And it has a nice web UI!

Installing locust

pip install locust 🤷‍♂️

https://docs.locust.io/en/stable/installation.html



Hello World

First we create a locustfile.py, which locust automatically picks up.

I’ve filled mine with:

from locust import HttpUser, task

class HelloWorldUser(HttpUser):
@task
def hello_world(self):
self.client.get("/")
self.client.get("/thisismy404")

We then boot up locust by running the command locust from the same folder as the locustfile. in the output i get a localhost address for the UI, mine showed: http://0.0.0.0:8089. I open this in my browser and BAM!

I input some webserver I use for testing and see what I get when I press “start swarming”.

WARNING! This will spam your endpoint aggressively. Maybe use a local api to test.

Press STOP to stop it.



Here we see how many successful requests we got. There are also tabs here which contains some nice graphs, an overview of different error messages and much more. Pretty neat!



We can also stop it, press “new test” and for example spawn 1 user per second with up to 20 concurrent users. When that runs for a few seconds, the graph looks like this:

Fancy!

Control rate

Next up, a very useful feature is to control how many requests are spawned. The easiest way to control this is by setting the locust `wait_time` variable in the class.

This makes each “user” wait between 1 and 5 seconds between each request. Much more controllable!

Some different requests

Locust functions start a microthread per user. The user then picks a function decorated with @task at random, executes that, waits the wait_time and then picks another random task. You can however weigh them.



Let’s set up another task that is twice as likely to get picked. We want locust to test each of these:



Example:



We restart locust to reload the config and run it. My output looked like this:

Pretty cool! We technically now have everything we need to do some decent testing of endpoints.

Start and stop functions

I wanted to show another useful little thing. You can define an on_start and on_stop method, which will be executed once per user. Very useful!

For example:



ran with 10 users for a few seconds, gives this output on my webserver:

Wohoo!

Last trick, random queries

Just a last little trick if you need to get some random requests! Remember that this is just standard python, so you can for example create a task like:

(remember to import random and import string). 

It's just an example of how we can leverage python in our locust setup, but it's quite useful.

The End

I hope this helps you get started on load testing! Sure, it’s not automated and integrated into every CI-pipeline, but it’s a lot better than just throwing stuff into prod and see what happens.

Locust has tons more of awesome stuff. including a good command line interface. Check out the docs at https://docs.locust.io/en/stable/writing-a-locustfile.html# and the homepage at https://locust.io/.

Getting started with load testing through locust

Er du av typen som liker å gestikulere med henda mens du presenterer? Synes du det er forstyrrende å holde en dings i henda mens du presenterer? 



Da er presentasjonshansken for deg! Den passer som hånd i hanske og gir en sømløs opplevelse for deg som presenterer!

20-Dec

Today's posts

Hva bør en designer kunne?

Subscription pattern with Compound components in React

Hvordan spenne beina på et IT-prosjekt? (Del 1 av 3) - Hyppige endringer av kravspekken

Getting started with load testing through locust

Presentasjonshansken