Ett av de viktigaste stegen i en problemlösningsprocess är inte som man kanske kan förledas att tro att hitta lösningar. Det är naturligtvis eftersträvansvärt att faktiskt kunna lösa ett problem, men det är ändå inte den viktigaste punkten i processen. När jag gick på industridesignprogrammet berättade en av mina lärare följande anekdot:

En tvåbarnsfamilj hade anlitat en arkitektbyrå för att ljudisolera ett hus. Det var för stökig ljudmiljö, tyckte föräldrarna. När arkitekterna kom på besök för att kunna ge en offert så höll de med. Det var vekligen en stökig ljudmiljö. Men arkitekterna hade en annan, långt mindre kostsam lösning på problemet än ljudisolering. Istället köptes två par hörlurar till barnen. Problemet var löst. Ungarna hade helt enkelt spelat så hög musik att föräldrarna knappt hörde sig själva tänka.

På samma sätt löstes “hissproblemet”. I USA blev husen bara högre och högre, och hissfärderna längre. Ett hissföretag fick i uppdrag att göra hissarna snabbare. Det finns ju vissa begränsningar för hur fort det kan gå utan att hissfärden blir farlig, men uppdragsgivarna ville fortfarande ha snabbare hissar. En av ingenjörerna kom på en lösning som gjorde hissresenärerna nöjda. Ingenjören satte in en spegel i hissen. Inga fler klagomål hördes.

Det som bägge anekdoterna har gemensamt är att beställarna agerat utifrån vad de tror är problemet och inte det faktiska problemet. I det första fallet var det inte ljudisoleringen som var bristande utan att barnen spelade för hög musik. I det andra fallet var det inte att hissen gick för långsamt, utan att de som åkte med den hade det tråkigt.

Det jag vill komma fram till är att problemet är svårt att lösa om man först inte definierat vilket problem man vill lösa, eller ens vad problemet i grund och botten är. Det gäller egentligen alla uppgifter man tar för sig. Det behöver inte vara ett specifikt område. Om man istället för ordet problem som kan tyckas något negativt laddat istället använder uppgift eller kreativ process blir det hela eventuellt mindre deprimerande. Att kunna formulera vad det är man vill komma åt för funktionalitet är avgörande för slutproduktens kvalitet anser jag.

När du vill göra ett nytt spel, vad vill du då komma åt för spelupplevelse? Hur formulerar du den upplevelsen? Nu när jag börjat skriva på O Quam Cito Transit Gloria Mundi så har jag gjort en “programförklaring” för rollspelet. Det skall bygga på tro, vänskap och politik, och spelarna skall uppleva en konflikt mellan sin egen ambition och den institution de lever i. Därför bygger jag spelmekaniken runt dessa tre pelare – vänskap, tro och politik. Spelarna kan “vinna” och “förlora” baserat på vilken pelare de väljer att utnyttja..

För att hitta problemet, eller för att göra en problemformulering, är det viktigt att ställa frågor. Hur, varför, när, vad, hur mycket etc, är alla viktiga verktyg när jag försöker gå till botten med ett problem.

Det är också viktigt att uttrycka ett syfte. När det finns ett syfte kan man också börja ställa relevanta frågor runt problemet, och när man svarat på frågorna har man kommit närmare en lösning. För mig är den viktigaste frågan sålunda “vad vill jag åstadkomma med det jag gör” och resten av arbetet får följa på det.

Varför pratar jag då om problemformulering just nu? Jo för att i diskussionen om jämställdhet pratas det för tillfället mycket om att män och kvinnor som jag fokuserar för mycket på problemen, att vi bör försöka se lösningar istället. Mitt motargument blir då att ja, vi fokuserar på problemen just nu för att försöka få grepp om dem och förstå dem och för att kunna ställa rätt frågor. Frågor som i slutändan kan få oss att förstå vad lösningen faktiskt är.

Dan Roam har i sin utmärkta bok The Back of the Napkin formulerat följande tabeller. Den första är en bild av SQVID – hur vi vill eller måste visa ett problem för att förstå det.

Den andra bilden tittar på SQVID i kombination med en rad olika frågor, och hur man använder dessa tillsammans för att skapa en förståelse för problemet.

Vid något tillfälle så skall jag se om jag orkar sätta ihop en bloggpost som fokuserar på problemlösningsmetoder, och då kan förtydliga både SQVID-metoden och den metod som jag själv har jobbat mycket med, Synectics.