Designverktygen du använder påverkar hur du samarbetar
Under de senaste åren har många spännande saker hänt kring synen på hur designers bör arbeta med utvecklingsteam. Allt fler inser att olika roller måste samarbeta nära varandra för att skapa bra lösningar. En utveckling jag tycker är mycket positiv, men jag har stött på ett hinder som jag inte tror många överväger: verktygen som vi designers använder kan göra det svårare för oss att vara en del av utvecklingsteamen.
Verktyg för att summera research och skapa insikter
Jag gillar att använda Adobe Illustrator när jag ska visualisera saker, då det är väldigt mångsidigt och ger mig möjligheten att skapa precis den visualiseringen som jag vill. På grund av detta har jag ofta använt Illustrator för att skapa kundresor, personas etc. Jag har dock upptäckt att mitt användande av verktyg riktade mot designers, som har en ganska hög inlärningskurva, får en stor bieffekt – jag involverar inte resten av teamet när jag summerar research och skapar insights. Jag har ofta varit den enda i teamet som kunnat använda Illustrator, vilket har inneburit att de andra medlemmarna inte känt att de också ägde insikterna och var helt beroende av mig för att påverka dem. Ibland hade de andra i teamet också svårt att förstå – eller höll inte med om – mina summeringar (även om de deltagit i användarstudierna).
“Jag har dock upptäckt att mitt användande av verktyg riktade mot designers, som har en ganska hög inlärningskurva, får en stor bieffekt – jag involverar inte resten av teamet när jag summerar research och skapar insights.”
Nuförtiden väntar jag längre med att skapa de ”snygga” visualiseringarna och använder mig först av verktyg som alla teammedlemmar känner sig bekväma att använda (t.ex. post-its, Power Point, Excel etc.) så att hela teamet kan ta del i att skapa summeringarna. Detta har lett till en mycket djupare förståelse och empati för användarna hos alla teammedlemmar. Det har också lett till mer konkreta och faktabaserade diskussioner, då de oftare baseras på vad användarna behöver, snarare än våra personliga åsikter.
Jag tycker fortfarande att ”snygga” visualiseringar har sitt syfte, framförallt för att göra dem lättare att förstå och för att visa externa intressenter. Man bör dock vara säker på att hela teamet känner att de har fått bidra med sina idéer och input innan man gör den ”snygga” visualiseringen.
Jag använder fortfarande verktyg såsom Sketch och Axure, men huvudsakligen när jag ser att en detaljerad specifikation faktiskt behövs – till exempel när flöden är komplexa eller om jag skapar en väldigt unik lösning. Vissa typer av personer gillar också att förhålla sig till detaljerade specifikationer innan de börjar arbeta, så jag anpassar även verktygen jag använder till preferenserna som teamet har.
Verktyg för att bygga wireframes och prototyper av lösningar
Förut brukade jag ofta använda verktyg såsom Sketch för att skapa detaljerade specifikationer till min design för att säkerställa att utvecklarna inte skulle missuppfatta. Jag försökte specificera exakt var varje element skulle befinna sig och skrev utförliga beskrivningar för olika scenarios, skärmstorlekar o.s.v. Jag använde också verktyg såsom Axure för att specificera alla interaktioner. När designspecifikationen var klar så lämnade jag över den till utvecklingsteamet som då implementerade den. När utvecklarna var klara så såg jag att trots mitt hårda arbete så var det saker som skiljde sig åt från min designspecifikation i den implementerade lösningen.
Om jag och utvecklarna istället hade samarbetat mer hade resultatet antagligen blivit annorlunda. Jag tror dock inte att ändring av arbetssätt hade räckt, åtminstone inte för att få en långsiktig förändring, om jag inte också hade ändrat vilka verktyg jag använde och hur. Faktum är att om ett verktyg gör det enkelt för dig att skapa detaljerade specifikationer, är risken mycket högre att du kommer fortsätta göra det istället för att ändra ditt beteende.
Nuförtiden planerar och leder jag oftare idégenereringsworkshops där hela teamet, med hjälp av penna och papper, delar med sig av sina idéer kring vad vi ska bygga och hur vi ska bygga det. Om du inte gjort detta tidigare kommer du bli imponerad av hur många bra idéer som kan komma från utvecklingsteamet, som har ett annat perspektiv än dig.
Jag använder också oftare verktyg som bara kan skapa grova skisser som visar mina övergripande designidéer och utgår från dessa när jag bygger det tillsammans med utvecklarna. Jag använder tid jag tidigare spenderade på att göra detaljerade specifikationer till att istället sitta tillsammans med utvecklingsteamet, för att diskutera och reflektera hur vi bäst kan realisera designen. Om det inte är möjligt så brukar jag åtminstone ha återkommande avstämningar för att kolla hur det går och om de har några tankar eller frågor kring designen.
“Jag använder tid jag tidigare spenderade på att göra detaljerade specifikationer till att istället sitta tillsammans med utvecklingsteamet, för att diskutera och reflektera hur vi bäst kan realisera designen.”
Balansen av samarbete och individuellt arbete
I samband med de stora steg som tagits mot samarbete har det också kommit molnbaserade designverktyg såsom Figma och UXPin, där alla användare kan få full tillgång och arbeta på designen samtidigt. Jag tror att dessa verktyg kan vara kraftfulla och hjälpa att möjliggöra samarbete. Samtidigt finns det en stor risk att för många blir för involverade i designprocessen om man inte tänker igenom hur man använder verktygen och vem som ska ha tillgång till vad.
Så – hur involverade ska de andra teammedlemmarna vara i designarbetet? Jag drar ofta en liknelse till koden som utvecklare skapar. I slutändan är det utvecklarna som skapar koden och har ansvar för den, men de bör kunna göra det tydligt hur de angriper en utmaning och varför. Alla i teamet bör även kunna diskutera deras approach och komma med input. För mig är det samma sak med designarbetet – designers bör ha ansvar för designen av produkten eller tjänsten, men alla i teamet bör kunna förstå hur vi nådde dit och att man har tagit hänsyn till allas input när designen skapades.
Avslutande tankar
Tvärfunktionella team och samarbete är här för att stanna. Det resulterar i teammedlemmar som tydligare kan se hur deras arbete bidrar till att uppfylla ett användarbehov. Det leder även till mer kundcentrerade produkter och tjänster. Verktygen som används behövs dock också anpassas till denna verklighet, för att möjliggöra istället för att vara ett hinder. Tänk igenom hur ni arbetar i er organisation och varför du använder ett visst verktyg.
