Affordance – gör design intuitiv

Hector_Giacomelli_-_A_Perch_of_Birds_-_Walters_37963

Affordance är en egenskap hos ett objekt som influerar hur det används.

Vad är det?

Ett föremål är alltid anpassat för vissa specifika användningsområden och funktioner. Saker som har en väl genomtänkt design räcker det att titta på för att vi ska förstå hur de används. Stora platta dörrhandtag är bättre än runda att trycka på, det kallas affordance att plattan inbjuder till att tryckas på. Runda hjul är bättre anpassade än fyrkantiga att rulla, de erbjuder en möjlighet att rullas. Det betyder inte att det är omöjligt att dra i platta dörrhandtag eller rulla fyrkantiga hjul men deras fysiska karaktäristik påverkar hur vi troligtvis kommer att handla.

Som designer kan du styra användarna att göra på ett visst sätt.

I vardagslivet

Affordance märks tydligast när ett föremåls design inte överensstämmer med dess tänkta funktion. Vi kan skylla på låg affordance när vi står och rycker i en dörr för att vi tror att den öppnas åt andra hållet. Många har inte ens reflekterat över att de automatiskt försöker att trycka då dörrhandtaget ser ut som en fyrkantig platta och dra då det ser ut som en stång. Det faller sig naturligt att dra i det cylindriska handtaget då det inbjuder till att dra i.

Ljusarmaturer i städer (t.ex. lysande butiksskyltar) erbjuder ofta utmärkta landningsmöjlighet för fåglar. Eftersom vi inte vill ha dem sittandes över våra huvuden så försöker vi minska skyltarnas landning-affordance genom att montera taggiga konstruktioner. Att göra det bökigare att göra fel är också ett sätt att använda affordance.

Inom webbdesign

Designa sidor och appar så att de erbjuder och inbjuder till rätt handlingar. Ett förståeligt användargränssnitt kan vara skillnaden mellan framgång och misslyckande. Om användarna inte förstår hur de ska använda din sida kommer de istället leta upp någon annan med ett högre användarvärde.
Ett exempel från webben är när den lilla blinkande linjen som poppar fram då du ska fylla i ett formulärfält inte visar sig. Varje gång jag stöter på det tror jag att det är något fel på fältet, eller att det inte går att skriva i det. Helt reflexmässigt antar jag också att ett fält med grå bakgrundsfärg istället för vit är avstängt.

See the Pen fieldaffordance by Kristoffer Darj (@kristofferdarj) on CodePen.

Hur uppnår jag hög affordance?

Det enklaste sättet är helt enkelt att låta vanliga användare testa din site. Med hjälp av tjänster som hotjar.com kan du se hur användarna beter sig på riktigt i verkligheten. Spela in dem, titta på inspelningarna och lös alla de problem du inte ens visste att du hade.
PS. Det är bökigt att översätta affordance rakt av men uppenbarhet kanske kan vara ett förslag till nästa års nyord. Stolen hade hög uppenbarhet. DS.

 

Vad kommer det att kosta?

1C21075320

För några år sen skulle jag köpa en ny klocka hos en urmakare i Visby. Min gamla från Ur och Penn hade levt ett hårt liv. Jag fick den när jag gick ut mellanstadiet för att markera att jag nu var en stor och ansvarstagande ung gosse med eget armbandsur. Sen dess hade jag behövt byta armband två gånger och lämna in själva urverket på reparationen en gång. Den var repad och sliten så det var dags för en ny.

Jag och en vän skulle precis påbörja en en cykelsemester med tält som de fattiga studenter vi var då. Nyanlända till Visby och innan själva cykelturen tog vid var jag fortfarande nyduschad och klädd i skjorta.

Lite som man gör så började jag spana på de riktigt dyra klockorna innan det var min tur att få hjälp. Och där stod jag och fascinerades över hur dyra klockor det finns när den solbrända klockförsäljaren gled upp vid min sida.

Som alla säljare gjorde han givetvis en snabb bedömning av vad jag var för typ av kund och vilka klockor som kunde tänkas passa mig. Det han såg var inte en fattig student på cykelsemester utan någon som såg välstruken ut och som just hade ägnat en god stund åt att titta på premiumsegmentet.

Han började passionerat berätta om titanlegeringar och repfria glas i olika grader av perfektion. Han låste upp montrarna och jag fick prova klockor som vägde lika mycket som medelstora hantlar och kostade mer än vad mindre länder har i försvarsbudget varje år. Och där stod jag och frågade och berömde samtidigt som obehaget växte. Jag kunde inte köpa en klocka som kostade mer än hela min samlade studieskuld och någon gång måste sanningen fram.

När försäljningen närmade sig något slags crescendo och försäljaren hoppade upp och ner och kastade klockor kring sig (ok jag överdriver kanske en aning) så var jag tvungen att säga att de här klockorna låg en aning utanför min budget.

– Vad hade du tänkt dig?
– Runt 2000 kr svarade jag och kände mig skamsen.

Men till min stora förvåning och till säljarens stora eloge så började allting om inom rätt budgetramar och han var fortfarande lika exalterad när han sen fick avsluta affären på 2000 kr.

Precis så här blir det ofta inom webbprojekt också. I slutänden kommer det att ske någon finansiell transaktion, det går inte att undvika att prata om pengar så småningom. Vi frågar ofta direkt vad projektet har i budget, något som gör kunder nervösa och obekväma.

Ibland vägrar kunden blankt att berätta med argumentet att vi då bara kommer att säga att det är så mycket det kommer att kosta.

Vilket är delvis sant.

Vi kommer att föreslå den bästa möjliga lösningen inom din budget. Efter det kan vi börja prata om du verkligen behöver allt det här vi föreslår eller om vi ska ta bort något för att hitta en lösning som täcker dina behov och inte tömmer din plånbok.

Alla vet inte vad de har för budget och det är också ok. Då kommer vi att diskutera några förslag som ligger i och under ditt intervall och några som kommer att ligga över. Tillsammans hittar vi rätt nivå.

Men om du vet vad du har i budget, berätta det direkt så slipper vi titta på alla klockor i butiken. Jag är fortfarande oerhört nöjd med min klocka från Jacque lemans. På något sätt känns det bra att kunna ta reda på vad klockan är utan att fiska upp mobilen ur fickan.

Det här är en del i min serie om att beställa webb. Senaste inlägget handlade om hur du blir en bättre beställare.

Det här inlägget publicerades i orginal på minabastapolare.se

7 tips om hur du blir en bättre beställare av webb och hus.

12252B7374

Genom att utbilda dig själv som beställare kommer du undan billigare, får med dig ett bättre slutresultat och blir hyllad av kollegorna för dina insatser.

Det här inlägget är en del i min serie om att beställa webb.
Det förra inlägget handlade om att våga vägra vattenfall.

En av förutsättningarna för att samarbetet mellan byrå och beställare ska gå lätt och smidigt är en bra beställning, att du vet vad du vill och varför. Att bygga webbplatser liknar mer att bygga hus än att köpa färdiga produkter som bilar. Det gäller att du och hantverkarna förstår varandra och är överens.

  • Vilken kulör du vill ha på fasaden?
  • Hur du tänkt använda din fastighet (är det tänkt att vara en affärlokal, ett kontor eller ett boningshus)?
  • Hur mycket det får kosta?
  • När du behöver ha det klart och så vidare.

Som byrå hjälper vi dig gärna att få ihop en bra beställning på samma sätt som arkitekten kan hjälpa dig att tänka på allt inför husbygget. Om du inte vill betala en arkitekt för att rita ett hus som passar just dina unika behov så finns det färdiga modulhus att beställa. Där kan du också göra vissa val som färg på taket, om du ska ha en säkerhetsdörr eller inte och om det ska vara en bänkskiva av trä eller sten i köket. Däremot kan du inte börja flytta runt rummen eller välja fönster som inte är standard.

Modulhuset kan absolut bli bra, det är ett hus trots allt och i det kan du bo och leva gott. Men om du tittar dig runt i området så ser alla andra modulhus rätt likadana ut. De har visserligen svart tak istället för ditt röda men i grund och botten har ni samma hus. Det räcker kanske för dig och det är inget fel med det.

Vi upplever dock att våra kunder ofta vill bygga lösvirkeshus med specialanpassningar för att just de ska trivas perfekt. Hade det inte varit roligare med tvåglasfönster med spröjs och ett tak i bandad plåt som glänser i solen. Förresten vore det inte fel med lite snickarglädje och ett platsbyggt skafferi på norrgaveln heller.

Att i det här läget snåla in på kostnaden för arkitekten om du inte är van att skapa husritningar och har koll på alla regler och rekommendationer är inte att rekommendera. I värsta fall finns risken att entreprenören bygger precis vad du skissat. Eller så föreslår entreprenören förbättringar som att du kanske borde dränera kring huset samtidigt som du gräver ut för källaren för att undvika framtida problem. De här ändringarna var ju svåra för dig att förutse redan från början och du inser att det vore bra tokigt att glömma bort att dränera, men att dränera kostar lite extra. Kör till, du vill ju inte ha fuktskador i källaren efter några år.

Men så föreslår de också att du nog borde välja en annat typ av element. Du vet det där gamla bulliga modellen som gör att luften strömmar uppåt och tar bort kallras från fönstren istället för den moderna (men billigare) platta som gör att värmen strålar rakt ut i rummet med effekten att det blir kallt på golvet på kvällar och mornar.

Nu får det faktiskt vara nog. Du ska ju inte bo i huset för evigt och lite kallras har väl ingen dött av. Nänä vi skippar det där med radiatorerna då säger entreprenören. Men borde du ändå inte välja en slamfärg på ytterpanelen du som ändå ska ha ohyvlad panel på utsidan? Det blir nog billigare i längden än den här akrylatfärgen. Tänkt på att du behöver måla om nån gång i framtiden.

Jo ok då men kan vi istället flytta köket till andra sidan huset så att det blir enklare och kortare rördragning? Jo jo det ska väl kanske gå, men nu har vi ju börjat bygga lite på skafferiet redan men visst det skulle ju eventuellt bli lättare med rördragningen så vi kanske sparar några kronor där som vi kan använda till en annan fasadfärg.

När förutsättningarna ändras mitt i är det lätt att lösningarna inte blir så bra som du tänkt ut från början. Det är ju ändå rätt bökigt att behöva springa till skafferiet i andra sidan huset vid varje frukost, speciellt eftersom golvet är så satans kallt varje morgon. Att flytta skafferiet gick tydligen inte heller då hade det ju hamnat på södergaveln och blivit för varmt, typiskt.

Men en dag står det där, ditt nya hus. Till allmänt beskådande. Förhoppningsvis är du stolt som en tupp. Som den goda beställare du är så jobbade du tillsammans med hantverkarna, lyssnade på råd från dem och arkitekten och gjorde anpassningar långt innan huset började byggas. Och det blev inte som du tänkt dig, faktiskt inte ens samma färg på fasaden eller storlek på huset. Det blev annorlunda, du visste inte ens att man kunde bygga hus som anpassar sig efter besökaren på det här sättet. Du kanske till och med kan erkänna för dig själv att huset blev mycket bättre än du hade skissat upp på den där servetten första gången du träffade arkitekten.

Vi som byrå försöker naturligtvis göra allt i vår makt för att påtala eventuella konstigheter och brister så tidigt som möjligt. Vi vill också bygga ditt drömhus, vi har en yrkesstolthet som hantverkare. Vi väljer de kådrikaste tallarna till ditt fönstervirke bara för att vi vet att det blir bäst så.

Vilken tur att du inte gjorde som grannen som envist försökte få sin vilja igenom tvärt emot rim och reson och som nu står med ett halvfärdigt hus som det går att bo i men kanske inte mycket mer.

Ibland stöter vi på beställare som är oerhört bestämda om att de absolut ska ha det på ett visst sätt. Ibland en herrgård till priset av ett modulhus, ibland lösningar som vi sen tidigare vet är lite tveksamma och ibland vet beställaren inte ens om de ska ha en kontorslokal eller en affärslokal eller varför. Ja då kan vi antingen säga blankt nej eller försöka göra så gott det är möjligt utifrån tidsramar och budget.

Skippa inte arkitekten om du inte vet vad du ger dig in på. Arkitekten guidar dig genom beställningsprocessen och ser till att du får det modulhus som blir helt fantastiskt för dig, eller om du har större budget bygger den där specialanpassade lösvirkesvillan som du drömt om sen du hängde hemma hos mormor och morfar på landet som liten.

Att anlita en arkitekt några timmar för att skapa en bra beställning är billigare än att leja fyra hantverkare en månad extra för att göra om de där sakerna som blev bortglömda när det inte fanns någon riktig ritning.

Här kommer några snabba om vad vi vill ha svar på

  • Vad ska du ha din webbplats till?
  • Vad har du för syfte med webbplatsen?
  • Vad har du för mål med webbplatsen? (tips: syfte och mål är inte samma sak)
  • Vad vill du uppnå?
  • Vilka ingår i målgruppen?

 

Och några tips på vad du inte ska göra

  • Ändra dig mitt i processen. Har du sagt ok till att bygga på ett visst sätt så måste det vara ok även en vecka senare.
  • Låtsas som du förstår om du inte gör det. Ibland glömmer vi bort att prata så folk förstår; Vi snackar om konvertering, USPar, plattformar och hosting. Fråga för tusan, vi vill ju bara att det ska bli rätt. Om du inte förstår så förklarar vi dåligt och ingenting annat.
  • Ge icke-konstruktiv feedback. Att du inte gillar något hjälper oss inte så mycket. Varför gillar du inte? Har du exempel på något annat du gillar osv.

Vi på Mina Bästa Polare har faktiskt byggt ett par hus men framförallt kan vi hjälpa dig med att bygga fantastiska digitala lösningar. Har du en affärsprocess som skulle kunna digitaliseras så hjälper vi dig mer än gärna. Om du har funderingar på hur du skulle kunna bli mer digital, kom in och snacka med oss, vi kan vara både din arkitekt och dina hantverkare.

Och de där sju tipsen? Jag vet inte hur många det blev men ojämna tal i rubriker drar många klick. Du kom ju hit eller hur!

Det här inlägget publicerades i orginal på minabastapolare.se

Väga vägra vattenfall

IKDNT0YH2N

Att skapa digitala strategier, design och kod kan göras på mer eller mindre lyckade sätt. Jag har lärt mig en del knep och metoder på vägen och sett några skräckexempel på hur man inte ska göra. Den vanligaste och (för kunden) dyraste modellen är vattenfallsmodellen som har sina rötter i tillverkningsindustrin. Här måste allt ske i steg, A innan arbetet går vidare till B. De flesta förespråkar istället(men lever inte upp till) agil utveckling som är en modern motreaktion mot allt det som inte fungerade med vattenfallsmodellen.

Vattenfallsmodellen

Vattenfallsmodellen har till uppgift att med näbbar och klor försöka motverka ändringar i ett sent skede. Den hade sina poänger innan tillverkningsindustrin fick tillgång till datorer och snabba prototypverktyg som 3D-skrivare. Idag är det mest en rest som hindrar digitala produkter från att nå sin fulla potential.

I vattenfallsmodellen sker allt i kronologisk ordning. Först en analysfas, därefter jobbar man fram en kravspecifikation, sedan sker designarbetet. När designen är godkänd och klar börjar implementationen som sedan går till test och lansering. Om beställaren godkänt skisserna på en webbsida så finns ingen möjlighet att komma med förbättringar i ett senare skede. Det blir i såna fall ett nytt projekt efter den första lanseringen, eller i vissa fall en tilläggsbeställning.

Den här modellen kan fungera i riktigt små projekt där risken för ändringar är liten eller minimal och alla krav och förutsättningar är kända redan innan projektet drar igång. Eller i andra ord, nästan inga projekt.

Dessutom finns en användbar produkt först efter att hela projektet är avslutat. Tills slutleveransen har skett är produkten inte testad och inte redo att skeppas ut. Man vet heller inte om det man bygger är rätt produkt. Det finns en risk att fel sak byggs när det inte snabbt kommer ut till test.

Agil utveckling

Ett sätt att motverka det här kallas agil eller iterativ utveckling. Då byggs istället en liten bit helt färdig innan nästa bit påbörjas.

Om en kund till exempel beställt en ny webbsida av en byrå så jobbar byrån och kunden först fram en digital strategi för att reda ut så att alla vet vilket syfte och mål den nya hemsidan ska uppfylla. Det här ska inte bli något långt statiskt styrdokument utan ska snarare vara en kortfattad, lättläst och levande text.

Därefter skapar vi en struktur och design för en liten enskild bit av den totala webbplatsen. Kanske bara en enskild sida. När designen känns good enough tar utvecklarna vid och börjar bygga. Ett av målen är att snabbt få ut en användbar, om än begränsad, produkt.

Snabbt som rackarns försöker byrån att få ut sidan till test för att kunden ska kunna känna och klämma på produkten. Om det som byggts håller måttet lanseras det i de fall det är möjligt, och bara en liten bit i taget. I annat fall görs raskt ändringar och samma lilla bit av kakan kommer ut till test igen.

Ofta är det först när det verkligen finns något att testa som frågorna uppstår. Skulle vi inte kunna göra så här? Tänk om vi skulle kunna ändra den här tankegången hit istället? Byrån ser till att hjälpa kunden att hålla fokus på målet (ökat sälj oftast) och tillsammans jobbar de sig vidare genom utvecklingsprocessen. Agil utveckling kräver täta och snabba kontakter mellan byrå och kund. Risker tas upp och hanteras gemensamt långt mycket tidigare än vad vattenfallsmodellen tillåter.

Agil utveckling handlar inte om att göra någonting slarvigare, tvärt om byggs mindre delar fullt ut tills de är klara. Med agila utvecklingsprocesser går det istället att undvika att en slutprodukt känns lite småhafsig överallt. Varje liten del som släpps kommer att vara putsad och de ändringar som gjordes direkt i början kommer givetvis inte att behöva göras om överallt som om de hade upptäckts sent i vattenfallsmodellen.

Slutprodukten blir bättre, alla inblandade blir mer nöjda och som en bonus blir priset ofta lägre.

Varför gör vi som vi gör?

Så varför används vattenfallsmodellen fortfarande i branchen trots att riskerna är större, priset högre och resultatet sämre? Delvis för att många byråer inte har utvecklat sina arbetsprocesser. Men också för att agil utveckling kräver ett större engagemang och mod från kunden.

Det här är en bloggpost jag först publicerade på minabastapolare.se
Här är den i något omarbetad form igen på min egen sida.

Useful color variables in Sass or Less

I read a post from David Walsh and got inspired to build upon his thoughts and write how his way could be merged with my way.

Our goal is to have a good naming convention for our sass or less color variables. Something that makes things less messy, is expandable and easy to change and use. Therefore I define my color variables in two steps. First i declare all the colors, then separately where they are used. It makes it really easy to switch colors without having to do so in multiple places. Search-replace across an entire project often ends in unintended changes in my experience. It’s way better to use unique variables for each module. Have a look at this.


@color-white:    #FFF;

//Reds
@color-monza:      #C80B0E;
@color-tamarillo:  #901618;

//Turquoise
@color-hippieBlue: #49A3A1;
@color-paradiso: #297775;

//Greys
@color-aquaHaze: #F0F4F6;
@color-shark: #27282D;

//================ Usage ====================
@color-text:   @color-white;

//Links
@color-link: @color-hippieBlue;
@color-linkHover: @color-paradiso;

//Navigation
@color-navbarLink:      @color-monza;
@color-navbarLinkHover: @color-tamarillo;

//Footer
@color-footerBackground: @color-shark;
@color-footerText:       @color-white;
@color-footerBorder:     @color-aquaHaze;

That way I won’t up with color variables named like this after a while.


@color-darkGrey
@color-grey
@color-lightGrey
@color-lighterGrey
@color-lightestGrey
@color-lightedestGrey
@color-almostWhite

And it’s way better than this


@color-color1
@color-color2
@color-color2.5
@color-color3
...
@color-color14

Which is also really hard to remember. To be expandable each color needs a unique name.
Get them at name that color. They individually give names to 1500 colors. If two colors gets the same name, either merge them together, (they are almost indistinguishable anyway) or use functions in sass or less such as darken(@color-monza,10%);

All of this resides in my _colors.less file and the in my main.less i simply do something like this.


.searchForm {
background-color: @color-searchFormBackground;
}

Found this useful? Check out my entire css convention.

Powered by kittens and brainpower.