Tankar kring user experience, service design och effektstyrning

Nu kan du nominera!

Ola Nilsson

Äntligen är det möjligt att nominera till det annorlunda designpriset – inUse Award 2018! Du som nominerar kan också vinna priser!

Syftet med inUse Award är att visa på goda exempel. Vi vill lyfta fram svenska lösningar som gör användarnas vardag enklare och roligare, och som hjälper verksamheterna som står bakom lösningarna att nå sina mål. Fokus ligger på användbarhet och hela upplevelsen istället för enbart på utseendet.

Nominera här, det är enkelt och går snabbt!

Du som nominerar det vinnande bidraget kan vinna en iPad och en biljett till From Business to Buttons 2019 – Europas främsta konferens om hur man skapar den bästa användarupplevelsen.

Vinnaren presenteras på prisutdelningsgalan den 4 oktober på Vasateatern i Stockholm. Vi delar ut två hedersomnämnanden och ett förstapris för den bästa användarupplevelsen, oavsett vilken typ av digital lösning det handlar om. Vinnaren får 25 000 kronor och två biljetter till 2019 års From Business to Buttons.

WCAG 2.1 will improve the user experience for all people. Illustration from the Microsoft’s toolkit for inclusive design.

The new guidelines in WCAG 2.1 explained

Alexander Skogberg

In the Summer of 2018, WCAG 2.0 will be updated to version 2.1 with new guidelines for making websites even more accessible. In this post I’ll try to give simple explanations of these guidelines along with thoughts and advice on how to follow them.

WCAG stands for Web Content Accessibility Guidelines and is an International established set of guidelines for accessible content on the Internet. These guidelines are mainly for people with various disabilities, but also for different devices used for browsing websites.

WCAG is maintained by the World Wide Web Consortium (W3C), the main standards organisation for the Internet. The current version (WCAG 2.0) was published in 2008 and became an ISO standard (ISO/IEC 40500:2012) in 2012.

In the Summer of 2018, WCAG 2.1 is set to be released with seventeen new guidelines that focus on improving accessibility for users with cognitive disabilities and for users who browse websites on mobile devices like tablets and smartphones.

Overview of WCAG 2.0

WCAG 2.0 consists of the following twelve guidelines divided into four different categories:

1. Perceivable

  1. Provide text alternatives for non-text content like images.
  2. Offer captions or text summaries for audio and video.
  3. Structure content to be programmatically identified and write it to be presented in different ways.
  4. Design content to be easy to read and listened to (good contrast, volume control).

2. Operable

  1. All functionality should be available just using a keyboard.
  2. There should be enough time to read content and perform wanted tasks.
  3. Avoid designing content that might cause seizures.
  4. Help users navigate and find content as much as possible.

3. Understandable

  1. Write easy-to-read text with assistive technologies in mind.
  2. Design content and the interface to behave in predictable ways.
  3. Help users to avoid and correct mistakes when entering input.

4. Robust

  1. Provide maximum compatibility with as many web browsers as possible.

Each of the guidelines in WCAG have measurable success criteria divided into the levels of A (lowest), AA and AAA (highest). More A’s equals more demands, but better accessibility when met.

Note: Some guidelines only have one or two levels of success criteria. Some have the levels A and AAA, but no AA.

For more information about these twelve guidelines, have a look at WCAG 2.0 at a Glance by W3C.

New guidelines in WCAG 2.1

Before explaining the new guidelines in WCAG 2.1, you should know that WCAG 2.1 is backward compatible with WCAG 2.0. This means that:

  • The previous categories and guidelines still apply
  • The numbering still applies
  • The basic principles still apply
  • The three levels of success criteria (A, AA, AAA) still apply

So, here are the new guidelines as of February 2018. The detailed documentation from W3C can be found at

1.3.4 Identify Common Purpose (AA)

For following this guideline, the meaning of each input field must be able to be determined programatically. In other words, a piece of code must be able to tell what is expected to be entered by a user or what’s the meaning of a piece of entered information.

Doing this correctly will make it possible for a user’s browser to autofill input fields based on data previously entered by the user. Great! Having to enter less input is always nice.

Technically, this has to be true if:

  • The implementation is done using technologies for identifying expected meaning of input data.
  • The input field uses the Autofill markup like in the following code snippet

<form> <label for="input-email">Email adress</label> <input id="input-email" autocomplete="email" type="email"> <label for="input-password">Password</label> <input id="input-password" autocomplete="current-password" type="password"> <button name="button-sign-in">Sign in</button> </form>

This guideline improves accessibility for users with cognitive disabilities who find it challenging to read and enter text. It’s also improves accessibility for users who don’t know the language of the website that well.

1.3.5 Identify Purpose (AAA)

This guideline says that the purpose of interface components, icons and certain sections must be able to be identified programmatically.

For example: The user should not just understand that a button is a button. He or she should understand what the button does, what its purpose is.

HTML should always be written correctly, so that assistive technologies like screen readers can do things like:

  • Identify sections like header, navigation, main content area and so on for easier navigation.
  • Provide text alternatives to icons, which otherwise can sound weird when being read to users.
  • Differentiate between different subheadings like H2, H3 and H3 subheadings for finding wanted content faster.

Following this guideline will improve accessibility for users of assistive technologies like screen readers.

1.4.10 Reflow (AA)

This guideline states that users must be able to browse a website using a 320 pixel wide screen without having to scroll horizontally. In other words, your website must be responsive.

Why a width of 320 pixels? Probably because this is the smallest device width of a lot of popular smartphones.

Screenshot of the websites of the Swedish police.

The Swedish police has a non-responsive website that fails at this guideline (even if they offer another website just for browsers on mobile devices). Screenshots were taken on an iPhone 5S that has a 320 pixel wide display.

Tip: Curious about what screen sizes are popular? Check out

Following this guideline will improve accessibility for all users visiting your website on a smartphone. It will also benefit users with visual impairment who definitely will zoom in (up to 400 % ) on desktop browsers.

Note: It’s acceptable to allow horizontal scrolling for content that often requires it like maps, data tables with many columns and wide diagrams.

Screenshot of the Google Maps website.

Horizontal scrolling for content like maps is fine. For example, when you’re browsing Google Maps on a smartphone’s browser. Here on Mobile Safari on an iPhone 5S in landscape mode.

1.4.11 Non-text contrast (AA)

Having high contrast between pieces of text and their backgrounds is one of the best and most important things you can do to ensure great accessibility on your website.

In this guideline the requirement for high contrast extends from regular page text, to text on interface components (buttons) as well as for colors used in non-text content (infographics and diagrams).

Tip: For measuring contrast, I recommend Lea Verou’s excellent tool at

Lea Verou's website for measuring contrast.

Measuring color contrast at Make sure to keep those contrast values high enough to reach the AAA level.

Following this guideline will improve accessibility for all users with different kinds of visual impairment.

1.4.12 Text spacing (AA)

For following this guideline, distances between paragraphs, rows, words and characters must be able to be increased to certain values without leading to loss of functionality or loss of content.

Failing at this could result in pieces of text overlapping, hence becoming unreadable. It could also result in components (links or buttons) being moved into places where they can’t be interacted with (outside the viewport or behind other elements).

Tip: Avoid setting fixed heights on elements containing text. When text needs more space, it has to be able to grow vertically and push down content below.

Following this guideline will improve accessibility for users with visual impairment and dyslexia.

1.4.13 Content on hover or focus (AA)

This guideline states that if users trigger content in the form of a modal window, tooltip or a similar component, they must be able to:

  • Dismiss the content without moving the mouse cursor or the current keyboard focus (for example by pressing the Esc key).
  • Scroll to the content (thereby moving the mouse cursor) without making the content disappear (when the cursor is moved).
  • Dismiss the content solely on their own terms.

Following this guideline will improve accessibility for users with visual impairment. Especially for those users who are likely to zoom in when browsing a website and have to scroll to content that shows up outside of the viewport.

2.2.6 Timeouts (AAA)

For following this guideline, users of your website must be informed if any period of inactivity could lead to loss of data. However, users don’t have to be informed of this if data is saved for more than 20 hours after their last interaction.

Following this guideline will improve accessibility for users with cognitive disabilities who need more time to complete wanted tasks.

2.2.7 Animation from Interactions (AAA)

This guideline states that animations triggered by interaction must be able to be turned off unless the animations are essential for the functionality or the content being presented.

Screenshot of train travel website MTR Express.

Although not triggered by user interaction, the moving video background of could cause discomfort among users sensitive to motion on websites. Sadly, it can’t be turned off.

Following this guideline will improve accessibility for users who are susceptible to seizures due to motion.

2.4.11 Character key shortcuts (A)

This guideline says that if a website supports keyboard shortcuts in the form of single characters like letters, symbols, numbers or punctuations one of the following three conditions must be met:

  1. The shortcuts can be turned off
  2. The shortcuts can be changed to also require pressing keyboard keys like Ctrl, Alt and Cmd
  3. A shortcut for a certain element is only active when that element has focus

Following this guideline will improve accessibility for people who use speech input for browsing a website. It will also improve accessibility for users who have hand tremors and easily press wrong keyboard keys.

2.4.12 Label in Name (A)

For succeeding with this guideline, text that is shown on interface components like buttons must be able to be:

  • Read to users of assistive technologies like screen readers
  • Triggered by voice commands by users who take advantage of speech recognition software

This is easy to succeed at if you use HTML elements like anchor tags and buttons correctly and write explanatory text labels.

Tip: If you replace text with an icon on an interface component, you can still make a screen reader read text to its user with the help of the aria-label attribute.

<button aria-label="Search"> <span class="icon-search"></span> </button>

Following this guideline will improve accessibility for people with visual impairment who use screen readers. It will also improve accessibility for users who use speech input for browsing a website.

2.5.1 Pointer gestures (A)

This guideline states that actions performed using complex gestures like pinch zooming and swiping must also be able to be performed using simpler gestures like single taps, double taps and long presses.

Screenshot of Flexslider 2.

When using the image slider Flexslider 2, you can go back and forth between images by swiping to the left and to the right. However, you can do the same thing with simpler gestures like tapping the arrow icons or the image thumbnails.

Remember: Even if users have great motor skills, the possibility to perform complex gestures might not be obvious to them.

Following this guideline will improve accessibility for users with limited motor skills or not enough fingers (!) for multi-touch gestures.

2.5.2 Pointer Cancellation (A)

This guidelines says that when you interact with a screen by clicking, tapping and long pressing at least one of the following statements must be true:

  1. The triggered functionality doesn’t happen on the down-event.
  2. The functionality is triggered on the up-event and it’s possible to either cancel it before the up-event occurs or undo it afterwards.
  3. The up-event cancels what happened on the down-event.
  4. Triggering the functionality on the down-event has to occur for some important reason.

An example of point 2: If you’re using a mouse and press down on a button for deleting a file on Dropbox, you should be able to move the mouse cursor away from the button and release it and nothing should happen.

2.5.3 Target Size (AAA)

For succeeding with this guideline, a clickable element must have a height and width of at least 44 ⨯ 44 pixels. However, it can be smaller if:

  • Its functionality can be achieved through another clickable element of 44 ⨯ 44 pixels.
  • It’s located in a block of text, like a regular underlined link.
  • Its size is determined by the device and browser the user is using (radio buttons, checkboxes).
  • It must have this look and size in this particular context in order to make sense.

Following this guideline will improve accessibility for people who have hand tremors, large fingers and use mobile devices with touch input (especially with just one hand).

2.5.4 Concurrent Input Mechanisms (AAA)

This guideline states that you must never disallow users to use, switch between or add and remove different mechanism for input like mouse, keyboard, stylus, touch input or voice input. Even if it means ignoring the most common mechanism for interacting with a certain piece of content.

Following this guideline will improve accessibility for people with limited motor skills who prefer or must use a certain input mechanism even when it’s uncommon. For example: Using a keyboard or mouse when operating a tablet.

2.6.1 Motion Actuation (A)

For following this guideline, functionality that is triggered by moving one’s mobile device must also be able to be triggered by interacting with interface components like buttons and sliders.

Responses to (accidental) motion must also be able to be turned off, unless:

  • The motion is supported through an accessible interface.
  • The motion is essential for the functionality.

The shake to undo feature used on native iOS and Android apps could be very troublesome if you have hand tremors. Luckily, I haven’t seen it be used on any websites.

Following this guideline will improve accessibility for users who mount their tablets and smartphones to their wheelchairs or have trouble moving them due to limited motor skills or because their hands are busy at the moment.

2.6.2 Orientation (AA)

This guideline states that you must not force users of mobile devices to hold their devices in or rotate them to a certain orientation in order to take part of a website’s content.

Just like 2.6.1 Motion Actuation, following this guideline will improve accessibility for users who mount their tablets and smartphones to their wheelchairs or have trouble rotating them due to limited motor skills or because their hands are busy at the moment.

Screenshot of the website for Svenska Spel.

Swedish state-owned gaming company Svenska Spel fails at this guideline on their website The text translates to “Please turn your device back to standing position”.

3.2.6 Status changes (AA)

For following this guideline, content that is updated dynamically must be notified to users of assistive technologies (like screen readers) without getting visual focus.

For example: You’re browsing a news website with a Twitter feed at the top of the site. It would be infuriating if every time a new tweet appears, you would automatically be scrolled back up to the top to see the new tweet.

A great way to solve this for users of screen readers is to use ARIA Live Regions. Here are three code snippets explaining how it works:

<div role="status" aria-live="off"> When this text is updated, users with screen readers will not be notified at all. </div> <div role="status" aria-live="polite"> When this text is updated, users with screen readers will be notified if they aren't doing anything else. </div> <div role="status" aria-live="assertive"> When this text is updated, users with screen readers will be notified immediately regardless of what they're doing. </div>

Following this guideline will improve accessibility for users with visual impairment, especially for those who use screen readers and are likely to zoom in on a website.

Wrapping up

Phew, that was the last of the new guidelines for WCAG 2.1. Is my post not updated or contains some mistakes? Please, let me know in the comment section and I’ll correct it.

Finally, remember that having great accessibility on your website will improve the user experience for all users.

FBTB was a blast!

Ola Nilsson

The meeting place for everyone who wants inspiration, and hands-on advice, on how to maximize business value by creating great user experiences. Simply: From Business to Buttons. It's was a blast!

Lots of pictures at the FBTB Facebook!

The world’s greatest UX and Service Design speakers at Cirkus in Stockholm. FBTB18! The atmosphere was electric directly from when the first talk started at 09:00 a.m.  

It was Jared Spool who launched the day with his talk: Beyond The UX Tipping Point. The founder of UIE and co-founder of Center Centre – and a world class speaker.

Then we saw an highly topical talk – UX Design for Trust: Protecting Privacy in a Connected World – by Ame Elliott. And Namrata Mehta followed up with a broadening perspective for folks in the west: The Dual Opportunity of UX in India.

– More people in India have access to a mobile phone than a toilet, says Namrata Mehta.

Great networking!

One speaker from inUse this year, Director of Service Design Pontus Wärnestål. He held a well-informed talk called Get Your Gear in Order – Building a Toolbox for the Future. Some pretty good advice and reflections.

– We install tools – apps – to hinder us from using our productivity tools, phones,  in order to make us more productive. That is bordering insanity, says Pontus Wärnestål.

After that it was time for lunch – and a walk in the fantastic areas of Djurgården, in fantastic weather.

Kellee Santiago (look at the top picture) – the creator of Journey, and game, app and VR producer at Google – was interviewed on stage, when the conference continued. She explained that they wanted to invite the players to an experience with Journey, not to punish them.

– There is no timer, no pressure, she says.

The next speaker got many laughs. One while saying:

– I am always surprised when people have worked more than five years in one company.

It was Maria Giudice's quote, in her talk The Life of a Change Maker — Lessons from the Battlefield. She finished her talk with another qoute to remember.

– Quit or fight, dont be mediocre.

Before the last break, Alla Weinberg – professionally certified coach specializing in leadership and organizational coaching – held her talk Culture Design. She made everybody in the room do a relaxation exercise (!) to find their "culture body". Magic!

Dana Chisnell picked up from FBTB17 when she entered the stage for her talk Democracy is a design problem.
– Hi, I’m Dana and I’m here to do a sequel to Mike Monteiro’s talk from last year, she says.

The final speaker is Tony Ulwick – Put Jobs-To-Be-Done Theory Into Practice With Outcome-Driven Innovation. Tempo, dynamic, experience – one hour of brilliance.

– You have to know what the entire job is, says Tony Ulwick.

All about FBTB18!

Våga lyssna på dig själv

Alva Mårdsjö

Ett av de bästa knepen för att bli bättre på att intervjua när det är dags för användningstester är att lyssna. På sig själv. Men det kräver sin skämskudde...

Vi har alla läst tipsen om hur man blir bättre på att intervjua; man ska aktivt lyssna på den du pratar med, att ta in och uppmärksamt ställa öppna frågor som kan leda vidare till diskussion, fånga upp trådar och nysta vidare. Ställa fram kaffe och skapa en inbjudande atmosfär, ha allt material redo, inte minst presentkorten som är tack för besväret. Detta för att komma djupare än att bara skrapa på ytan och hitta behov och krav du annars inte hade hittat.

En av de bättre böckerna jag läst i ämnet är Steve Portigals Interviewing Users How to Uncover Compelling Insights” Det är nog så viktigt att vara med i samtalet och inte bara vänta på en paus tills man själv kan prata men… har du lyssnat på dig själv någon gång? Har du utvärderat vilka förbättringspunkter du har som intervjuare?

Nästa gång du ska intervjua, be om lov att få spela in samtalet, antingen bara ljud eller också video. Efteråt, förutom att ta fram allt värdefullt material du har fått från den du intervjuat, så ska du också kolla på dig själv. Steg 1 är att ta fram skämskudden, för det här kommer antagligen bli lika bekvämt som när David Brent (engelska The Office) kör danssolo på julfesten. Steg 2 är att släppa på prestigen och faktiskt sänka skämskudden igen och ta en ärlig titt på dig själv.

Ja, det ÄR jobbigt att höra sin egen röst och att se sig själv på video. När du pratar både hör du ljudet och känner vibrationerna från stämbanden, i inspelat format får du bara ljudet. På video ser du dig rättvänt, som alla andra ser dig, men du själv har bara sett dig själv i spegeln, i speglat format. Inte konstigt att det är märkligt att höra och se dig själv inspelad, men det är också ett ypperligt sätt att lära sig och bli bättre.

Jag har spelat in mig själv otaliga gånger, och därför också lyssnat på mig själv otaliga gånger, vid tillfällen då det passar bättre att ta anteckningar efteråt än under tiden. I en optimal värld är man såklart fullfjädrad på att intervjua från början, men ärligt talat, vi kan alla lära oss att bli bättre. Och man blir bättre för varje gång man tar en utvärderingsrunda på sig själv.

Är du redo? Här kommer några av mina insikter av vad jag har gjort:

  • Hummat när jag håller med om vad en person säger, trots att hummandet kommer mitt under deras uttalande (SKÄMSKUDDE)
  • Använt uttrycket ”ja precis” på ett nästan ticks-mässigt sätt både när jag fyller på, och när jag är redo för nästa fråga.
  • Tagit vid nästa fråga lite för snabbt. Det är så viktigt med pauser och tystnader, att ge samtalspartnern en chans att fundera och komma på mer att säga.
  • Totalt missat helt uppenbara följdfrågor.
  • Missat dinglande trådar som bara väntar att nystas i

Numera är min röst en röst som alla andra (nästan), och jag behöver inte plocka fram skämskudden lika ofta. För varje genomlyssning blir jag lite duktigare på att hitta de där frågorna redan under intervjun, får ett bättre kroppsspråk, och undviker det där hummandet.

Har du spelat in dig själv – och vad lärde du dig? Lämna gärna en kommentar!

Boktips: Interviewing Users How to Uncover Compelling Insights av Steve Portigal


Elin Fallenius Head of IT Demand & BRM på ÅF.

Hemma hos på ÅF gav mersmak

Ola Nilsson

Ett populärt koncept för inUse Academys kurser, workshops och föreläsningar är hemma-hos-varianterna. Nyligen körde inUse en Effektkartläggningsworkshop hos ÅF i Solna.
– Workshopen var superbra för oss och jag hoppas att våra medarbetare får energi och vilja att jobba på ett nytt sätt, säger Elin Fallenius på ÅF.

Det finns många fördelar med att få en kurs på hemmaplan. Man sparar tid, man kan hålla ihop gruppen, frågorna blir relevanta för alla medverkande och så vidare. Tillgången till inUse kurser fanns såklart redan innan, men efter att inUse blev en del av ÅF blev det uppenbart enklare.

– Jag har kommit i kontakt med inUse och Mikael Sköld – kursledare och User Experience Strategist & Designer – tidigare. Jag har känt till inUse, och nu efter förvärvet känns det naturligt att ta in kunniga personer internt, säger Elin Fallenius Head of IT Demand & BRM på ÅF.

– Konceptet med Effektkartläggning känner jag själv till sedan tidigare, men jag vill att min grupp ska lära sig konceptet och börja använda det.

Vad är det för team?

– Det är en grupp med Business Analysts, kravanalytiker, som jobbar nära ÅF:s stabsfunktioner och divisionerna. De är länken mellan användarna och utvecklingsteamen och ska förstå verksamhetens processer och behov och omvandla det till IT-lösningar. Vårt mål är att vi göra vardagen lättare för de som jobbar på ÅF, det ska vara lätt att ta ut sitt CV, tidrapportera med mera.

Mer inbokat framöver

Att inUse är till nytta för ÅF och vice versa är på många sätt givet. Nu var det ÅF som fick en rejäl dos användarfokus.

– Jag tror alla fick med sig att ha ett stort fokus på effekterna av de förbättringar vi gör, vad vill vi uppnå, viken skillnad det ska göra för våra användare. Det handlar om att göra skillnad för slutanvändare, inte enbart leverera en funktion.

Mikael Sköld.

Och Effektkartläggnings-nedslaget gav en fortsättning direkt.

– Vi har fortsatt samarbete, Mikael Sköld coachar två av dem i teamet i ett uppdrag nu.

Det är dessutom fler hemma-hos-tillfällen för inUse redan spikade på ÅF. 

– Vi har fler tillfällen inbokade, Jonas Söderström ska komma och prata om Jävla skitsystem!, exempelvis.