Jag har suttit med utvecklare som på fullt allvar tyckt att det varit helt okej att ha knappen för att visa en meny på ena sidan av skärmen och låta menyn öppnas på den andra sidan – alltså på den del av skärmen där användaren garanterat inte har sitt fokus. Skyll inte på användaren om du gör ett dåligt jobb som utvecklare och designer.

Jag har suttit med designers som envist hållit fast vid att designen och utförandet är det bästa sedan skivad formfranska trots att just deras design ledde till att över 40 procent av användarna gjorde fel. Skyll inte på användaren om du gör ett dåligt jobb som utvecklare och designer.

Det finns buggar som ställer till det. Tekniska buggar, fel i koden, den typen av fel accepterar de flesta, möjligen då inte användare som inte riktigt förstår att det är en utopi att tro att utvecklare alltid skriver felfri kod. Buggar är en del av vardagen i allt utvecklande. Det gäller att ha en process för att hitta dem och korrigera dem innan användaren släpps in.

Design-buggar

Det finns också design-buggar som kan handla om allt var du placerar en knapp för en funktion, till hur en fråga i ett formulär är skriven. Ponera att du har en knapp som ska tömma ett formulär på all inmatad text för att ge användaren en chans att kunna börja om. Lägger du den knappen längst som den första knappen som en användare ser ut och funktionen för att spara som nummer två så kommer många av de användare som vill spara det de har matat in att göra fel – de kommer att tömma formuläret istället för att spara all text. Förklaringen är enkel – användaren ser knappen för att tömma formuläret som knapp nummer ett. Jag tar det som ett exempel därför att det var ett av mina första misstag som designer och jag var dum, ung och jag skyllde på användarna tills någon med mer erfarenhet och mindre prestige flyttade knapparna. Det löste problemet och det minskade definitivt användarnas ilska med den aktuella lösningen.

Formulär

Ett annat exempel är ett formulär med en illa formulerad fråga. Texten är här buggen och antingen får du felaktiga svar eller inga svar alls. Lösningen är att sätta sig ned med papper och penna, en metod som faktiskt fungerar påfallande ofta i en digital värld och försöka att formulera om frågan på ett enklare och rakare sätt. Kanske kompletterat med en textrad med en förklaring. Det visade ung vara lösningen på ett ganska färskt problem. Ställ frågan på rätt sätt så får du rätt svar, enkelt eller hur?

Det du inte kan göra, per automatik, är att skylla ifrån dig på användaren. Har du byggt något som andra inte kan använda så är felet ditt . och bara ditt.

Cache

Nyligen så ställdes jag inför ett allvarligt problem med den här bloggen och jag var nära, mycket nära att ge upp.

Sex timmar senare – eller hur en blogg hängde på det berömda repet ett tag

Efter sex timmars felsökning, med hjälp av folk som är mycket mera kunniga än jag är så kom de också fram till att problemet var en plugin, WP Rocket. En så kallad cache-plugin som skulle göra Magasin Macken och bloggen snabbare. Resultatet var det rakt motsatta, extrema svarstider och vad som var värre – en negativ påverkan på hela servern – alla våra webbsidor. Lösningen var snabb och enkel – riv ut WP Rocket, avinstallera det program som skulle göra att all skulle rulla på snabbare. Med ens gick servern som den skulle, besökare i hundratals, tusentals började att komma tillbaka inom några dagar.

I kontakterna med de som kan WP Rocket bättre än mig så har jag fått veta att felet var mitt, jag som användare. Jag hade inte installerat WP Rocket på ett korrekt sätt, hette det. Nu ska för tydlighetens skull noga understrykas att det inte var representanter för WP Rocket. Felet var antingen mitt, hur servern var uppsatt och i stort sett alla andra fel än hur WP Rocket är designad, de funktioner som programmet innehåller och hur du installerar och ställer in saker i cache-programmet.

Resonera

Du kan inte resonera på det sättet som utvecklare eller som designer. Har du skapat något som kan sänka en server, påverka ett stort antal kunder så har du också överlåtit åt användaren att försöka att lösa eventuella problem på en nivå som du absolut inte kan kräva av en användare. Du har skapat en allvarlig funktionell bugg som garanterat kommer att leda till en lösning som du inte vill se – ditt program avinstalleras och får taskiga omdömen. Detta oavsett om det kan vara servern i sig, webbplatsen i sig eller användaren. Kan ditt program, det du skapat ställa till med ett smärre helvete så är det ditt fel om du inte vidtagit åtgärder för att varna, berätta och informera om vad en funktion kan ställa till med. Framför allt – slå inte på denna funktion som standard vilket faktiskt är fallet med WP Rocket. Preload är aktiverat som standard och det rekommenderas inte att du slår av funktionen om du får problem med programmet/tillägget.

När jag sedan installerar mitt gamla program, Fastest Cache, så ser jag direkt skillnaden – WP Rocket aktiverar alltså preload som standard, Faster Cache gör det inte och när jag går igenom ytterligare 3-4 cache plugins så visar det ung att WP Rocket är ensamma om att aktivera funktionen som default, som standard.

Slutsats: WP Rocket slår på en funktion som menligt kan påverka hela din server, som standard.

Det är dålig design.

OnyX

Programmet OnyX är ett kraftfullt underhållsverktyg för macOS. Det är en räddare i nöden som kan återställa den mest bångstyriga installation av macOS till funktionellt körbart skick. Det är också ett program som kan ställa till med ett veritabelt helvete om du inte vet vad du gör och exakt vad du gör. För att undvika det så innehåller OnyX information och varningar och en serie standardinställningar. Du väljer standardinställningarna så kommer OnyX att fungera utan att ställa till det. De mer avancerade funktionerna finns där för folk som vet mer och bättre och som kan använda dem. Enkelt eller hur, lotsa användaren förbi vallgravarna och fällorna så kommer det att fungera.

Slår du på en av dessa mer avancerade funktioner så säger OnyX ifrån och du får en varning.

Det är god design.

Styr användaren

Det hör också till avigsidorna med många inställningar, avancerade funktioner och bristande lotsning (dålig design) av användaren. Du som utvecklare och designer kommer inte ens att få chansen att rätta till det som ditt program kan ställa till med.

Det av två anledningar:

Tid och verkligheten – två faktorer som en del utvecklare och designers ibland helt glömmer bort. I det här fallet så är det användarens tid och verklighet. Ta en våg med två vågskålar – i den ena lägger du ett program som ska lösa ett problem. I den andra vågskålen lägger du alla de problem som samma program orsakar – om det installeras på ett felaktigt sätt.

Du försätter användaren i en sits där ditt program lett till omfattande problem som dessutom påverkar andra användare. Lösningen är att antingen lägga ned tid och pengar för att hitta de rätta inställningarna för just din funktion – eller att riva ut, avinstallera och hitta en annan mera lättanvänd lösning. Problemet här är att alla tester, alla försök att rätta till saker påverkar ett rätt betydande antal andra användare. Eventuella lösningar kan inte heller testas på en annan server i en annan miljö därför att det inte kommer att bli rättvisande. En eventuell lösning måste testas, köras i realtid – vilket riskerar att negativt påverka en rad andra användare och en helt installation. Ursäkta om jag är tjatig men du som utvecklare och designer kan aldrig räkna med att lösningen blir någon annan att det du skapat åker ut.

Är du med? För att få ordning på programmet så kan det krävas tester, omstarter och med en uppenbar risk att allt det du gör påverkar en rad andra användare. I värsta fall så tvärnitar en hel server.

Lösningen

Argumentera dig gärna tills du tappar all luft och blir blå för att detta är användarens fel. Lösningen kommer ofelbart bli att ditt program åker ut. Därför brydde jag mig inte om att ta kontakt med WP Rockets support och be om hjälp. Det hade tagit för lång tid och under tiden påverkades andra användare negativt. Jag gjorde ett försök för att se över servern i sig, anlitade kunnigt folk som konstaterade att servern var uppsatt som en server ska sättas upp och de konstaterade också var felet var, liksom föreslog lösningen så som rationellt tänkande människor gör – radera det felande programmet.

Du kan inte skylla på användaren.

I genomgången och letande efter felkällan så misstänkte vi också att detta kunde vara en kollision mellan installerade säkerhetslösningar, övervakningslösningar och lösningar för att säkerhetskopiera webbplatser. Det är möjligt att det var så men här väger vågskålen med övervakning, säkerhet och backup blytungt. Det finns inte på kartan att vi skulle sitta ned och byta lösningar som fungerat i många år och som visat sig mycket pålitliga mot en cache-programvara som visar sig kunna sänka en hel server. Det är verkligheten som alla designers och utvecklare måste ta hänsyn till – användarens verklighet.

Jag har en regel när jag testar program, appar och tjänster – har jag inte fattat hur saker fungerar efter 15-30 minuter, kan jag inte se vilken nytta jag skulle kunna ha av app, program eller tjänst så åker det ut. Detsamma gäller om ett program eller app har en ”farlig” funktion påslagen som standard.

Det är dålig design.

Antennagate

Låt mig ta ett sista exempel – Apples Antennagate.

Höll du en iPhone på ett visst sätt, lät du en större del av handen greppa runt telefonen så tappade iPhone en stor del av sin antenn-kapacitet. Steve Jobs och Apple försvarade sig med ”håll inte telefonen på det sättet” – felet var användarens. Till saken hör att i stort sett alla marknadens smarta telefoner hade samma designproblem. Greppade du en Nokia, en Ericsson, en Samsung på samma sätt så tappade antennen kontakten med operatörens närmaste mast – du fick sämre mottagning.

Idag är uppenbarligen våra smarta mobiler designade på ett annat sätt, de kanske innehåller andra antenner, vad vet jag, men de uppvisar i alla fall inte samma problem. Det var alltså inte användarens fel – det var designen eller den tekniska lösning som användes på den tiden.

Skyll inte på användaren – påfallande ofta så är felet ditt som utvecklare och designer.