Designidé - Bygg om vasaparken!

Efter övning 3 var ett av de två projekt vi arbetade vidare med en idé som vi kallar "Bygg om Vasaparken". Det här är även den idén vi kommer att arbeta vidare med framöver. I det här blogginlägget försöker vi sammanfatta projektidén,  några utvalda delar ur datainsamlingen som ledde oss till det här projektet samt designen så här långt. 

BYGG OM VASAPARKEN    - Designtävling för skolklasser

Tema: Vi har valt att arbeta med det 4:e målet för en hållbar stad: "Till 2030 verka för en inkluderande och hållbar urbanisering samt förbättra kapaciteten för deltagandebaserad, integrerad och hållbar planering och förvaltning av bosättningar i alla länder. Skapa en interaktiv prototyp som kan verka för att öka deltagandet för planering av offentliga platser i Stockholm stad."

Syfte: Inkludera skolelever i stadsplanering

Målgrupp: Skolklasser årskurs 5-6.

Kund: Stockholm Stad

Kort om projektet:

Vi designar en applikation till datorer och surfplattor där barn kan bygga, rita och skapa sin egen version av Vasaparken. Appen ska användas vid ombyggnation av Vasaparken för att samla in idéer och förslag från skolelever på hur Vasaparken ska se ut i framtiden.

Bakgrund till projektet

Nedan sammanfattas några få delar av datainsamlingen som motiverat och inspirerat till vårt projekt.

______________________________________________________

Citat från intervjuer:

• “Vi är för små. Ingen skulle lyssna på oss.” /barn ca 12 år

Det här citatet visar på något som verkar vara en inställning hos många barn. Ofta är barn helt utanför demokratiska processer och stadsplanering. Därför vill vi fånga upp den målgruppen.

• “det är så krångligt. Man måste svara precis på ett sätt som de vill, jag kände mig låst till deras frågor. Det finns alldeles för få alternativ.”

Från citatet ovan och liknande har vi blivit inspirerade till en lösning som där det går att komma med stora och små idéer som inte är låsta till färdiga mallar.

• “Men sen så har vi ju en förslagslåda här också. Det är ju föräldrar och sånt som lägger förslag där, det blir rätt mycket.”

Förslagslådor är alltså uppskattade idag i Vasaparken. Men det är framförallt föräldrar som lämnar förslag där. Vi vill skapa en lösning som fångar upp barnens idéer också.

_____________________________________________________________________

State of the Art

the Center for Urban Pedagogy(CUP):

Vi har inspirerats av en ideell förening, CUP, som arbetar för att utbilda människor om stadsplanering genom att arrangera projekt som för samman just medborgare och ämbetsmän. De har skapat interaktiva verktyg som används för att upplysa människor om plan- och bygglagar samt om översiktsplaner för att öka människors intresse och deltagande för hur de kan påverka och åstadkomma förändringar i stadsplanering.

Stockholm.se/felanmlan:

På Stockholms stads hemsida finns verktyg redan idag för att lämna in synpunkter och felanmälningar. Denna tjänst hade flera av personerna vi intervjuade använt någon gång. Hemsidan är någorlunda fungerande för en vuxen person som vill lämna in en konkret synpunkt. Vi såg dock att den lösning som finns i nuläget framförallt är anpassad för personer som är vana att tycka till och ha åsikter. Av den lilla datainsamling vi gjort har vi haft svårt att hitta sätt att tycka till som är anpassade till barns särskild behov och förutsättningar för påverkan.

________________________________________________________________

Painpoints:

I analys av olika användare av parken och deras möjligheter att påverka kom vi fram till att målgruppen barn är väldigt oinsatta i samhällsbyggnad och påverkansarbete. Det är därför svårt för barn att vara en del av stadsplaneringen. Samtidigt har de en stor vilja att förändra och ett stort teknikintresse, vilket vi drar nytta av i vår designlösning.

________________________________________________________________

Persona Alfred:

Alfred Lindqvist är 10 år gammal

Alfred har två huvudsakliga intressen: sport, främst fotboll, och datorspel. Alfred älskar alla sporter som har med en boll att göra är Vasaparken en av hans favoritplatser, både på sommaren och vintern. Dit går han nästan varje dag efter skoltid för att spela med sina klasskamrater.

Han älskar just Minecraft då det saknar gränser och han kan därför bygga vad han vill och hur han vill.

_____________________________________________________________________

Designidé och prototyp

Nedan beskrivs själva idén, dess användningsområde och designen.

Användningsområde

Vi vill skapa en produkt som möjliggör för kommuner och beslutsfattare att inkludera barn och unga i medborgardialog kring stadsplanering. Applikationen kan användas när en park eller annan offentlig plats ska byggas om och beslutsfattare vill ha dialog med boende i området kring vad som önskas på platsen. Vanligtvis sker den typen av medborgardialog i ett sent skede när färdiga förslag redan finns. Medborgardialog inom kommunpolitik är ofta också utformad på ett sätt som passar framförallt vuxna personer. Vår idé är att skapa en lösning som dels involverar medborgare tidigt i beslutsprocessen men även är framförallt utformad för att passa barn.

Applikation är tänk att användas som en del av ett helt projekt (som vi hittat på) som kallas "Bygg om Vasaparken". Stockholms Stad ansvarar för projektet som syftar till att inkludera barn i stadsplanering. En designtävling utlyses som riktar sig framför allt till skolklasser i årskurs 5-6 i grundskolan. Skolor får delta och låter därmed elever arbeta med projektet och bygga egna förslag, själva eller i grupper, som lämnas in som designförslag på hur Vasaparken ska utformas. Sedan hålls omröstningar mellan de olika förslagen där det vinnande förslaget till slut blir till verklighet.

Vårt projekt syftar till att utveckla Vasaparken men vi ser gärna att applikationen utformas på ett sådant sätt att den lätt kan anpassas till olika syften och kontexter.

Design

Vår idé är en applikation för datorer och surfplattor. Programmet ska möjliggöra för användaren att fritt redigera i Vasaparken och bygga ett eget förslag på hur parken ska utformas. Vi har fått inspiration från spel såsom Minecraft, The Sims och Rollercoaster Tycoon där spelaren får bygga sin egen värld. Vi vill att applikationen ska vara lättanvänd och tydlig men samtidigt ge väldigt fritt utrymme till användare att skapa som den vill. Detta är en svår avvägning som vi arbetar vidare med. Som en tidig låg-nivå prototyp har vi tagit fram skisser på applikationens utformning.

Ovan syns startsidan när en börjar arbeta i ett projekt i applikationen. En karta över vasaparken syns som av användaren kan delas in i mindre områden(A-H på bilden) för att redigera separat. På sidan om kartan ligger en verktygslåda med olika färdiga objekt som kan dras från verktygslådan in över vyn i parken för att placera objektet.

Redigering i applikationen sker ofta i en inzoomad vy över ett mindre område. På bilden ovan syns en lekplats under ombyggnad. Det går dels att dra och släppa färdiga objekt där en vill att de ska placeras ut. Det går till viss del att ändra de färdiga objektens färg och egenskaper. Men det är även möjligt att klicka sig in i en särskild editor för att skapa en egen design. Där kan en rita och bygga ett eget objekt att sedan placera ut i parken.

Designprocessen är i sin startfas och vi har framförallt fokuserat på konceptuell design hittills och diskuterat funktionalitet, kravspecifikation och vad användaren ska kunna göra. Vi har långt kvar tills vi vet hur programmet kommer att se ut i slutändan men gruppen är pepp och jobbar på bra! :)

Efter SEM 2

Gruppen gick tillsammans igenom de olika läsavsnitten där vi i logisk ordning tog upp nyckelord som vi identifierat och så klart nyckelord (HCI-teori) som vi fått som riktmärken inför seminariet. Vi samtalade och diskuterade kring de olika termerna och avsnittens syfte och nytta för oss i det här projektarbetet - för att bland annat försäkra varandra om att vi förstått innehållet och hjälpa & uppmuntra varandra att omsätta så mycket nyttigt som möjligt i projektet.

Vi började med kapitel 13 där vi ansåg huvudfokus var delat mellan vad, var, varför, hur saker kan utvärderas och betoningen av att alltid återgå, reflektera och bygga vidare på det som vi gjort i projektet tidigare - alltså implementera och att dra nytta av en iterativ process.

Vi ansåg att vi hela tiden jobbat på det här sättet då vi vanligtvis börjar de olika träffarna (övningar, seminarier, egna träffar) med att briefa alla om vad vi gjorde sist. Det här har två syften: info till den som eventuellt inte kunde vara där & för att korta ner dödtiden i början/accelerationssträckan till dess att vi börjar driva projektet framåt och vidare igen.

Vi reflekterade även lite över In-the-wild observationer/utvärdering eftersom det upplevdes vara det mest relaterbara för oss, på grund av intervjuerna (vår främsta input-källa utöver det kursen erbjudit) vi genomförde på plats i Vasaparken.

Kapitel 15 hade ett gäng ord och koncept som vi lade tid på att förstå/utreda. Det främsta exemplet var ‘Heuristik’ (Heuristics) som vi översätter till accepterade principer med erkänt mätbart resultat.

Vi tyckte också att det var spännande hur det lades fram att det inte nödvändigtvis krävs så många experter/testare för att ändå upptäcka en stor del av befintliga problem i användargränssnitt och/eller olika människa-dator system. Enligt en del i kapitlet går det med tre till fem personer att uppmärksamma ca 75 % av användarproblemen - och det känns väldigt bra och inspirerande då det antalet testare inte är så svårt att uppnå. Då kan det tillochmed vara möjligt för oss att vara lite kräsna i urvalet av testare istället för att bara välja några random personer som råkar vara i närheten (undvika “bocka av en uppgift från en lista”-mentalitet). Vi känner ju nu lite olika personer på KTH eller i Stockholm (Vasaparken) som kan testa, identifiera och ge svar/lösningar till olika förutspådda & nya problempunkter.

Vi pratade lite kort om metoden inspektion - alltså att utan direkt anknytning till användaren analysera & utvärdera vad det nu handlar om - och att blanda in experter som genom deras erfarenhet vet eller kan förutspå ungefär vad som kan gå fel och/eller olika användares beteénden. Det som boken kallar för predictive methods.

I samband med det kom vi även in på Analytics & statistics (kartlägger användningen utan att användaren blandas in eller i vissa fall vet om det) och pratade lite om vi - i och med det egna projektet - har möjlighet/rättighet att logga beteénden eller åsikter då det är barn det handlar om och i viss mån möjligtvis även politiskt-kopplade åsikter.

Kort bakgrund: vi har mellan ÖVN 3 och SEM 2 haft en träff där vi beslutade att gå vidare med ett koncept där vi tänker ta fram en mjukvara för att barn & skolklasser skall kunna planera, bygga & ge förslag till förbättringar av  nya eller befintliga parker.

Vi ansåg att, eftersom huvudsyftet för vår produkt är att involvera yngre i stadsplanering och utformningen av parker, vi därför inte direkt gör större intrång på deras integritet. Det går ju så klart även att inkludera en terms & agreement ruta så användaren får godkänna (i samråd med sina föräldrar/lärare om så krävs). Alternativt att användaren kan välja att vara anonym.

Slutligen för det här kapitlet pratade vi några minuter om Fitts' law. Det mest nyttiga vi sade här var att det är lämpligt att vi exempelvis placerar nästkommande knapp (i menyer eller mellan sidbyten) på samma ställe så det direkt blir en logisk koppling och den ytan “ägs” av samma funktion som på föregående sida.

Angående ISO 9241-210 så pratade vi om de olika direkta fördelarna med att hålla fokus på human-centered design under framtagningsprocessen. Vi återkopplade till ett föreläsningsexempel där skillnaden mellan user-centered och human-centered lätt identifierades genom en mjölkningsmaskin. I user-centered ligger fokus på kossan medan i human-centered ligger fokus på människan/människorna kopplade till det här scenariot (vilka i det här fallet annars blir andrahandsanvändare).

Förutom att Human-centered approachen sparar/tjänar in pengar för projektet & kunden så skapas även bättre och trevligare förutsättningar kopplade till den sociala delen. Genom att exempelvis produkten/tjänsten mer troligt blir ganska trevlig att använda.

Vi gick igenom definitionen av usability; “extent to which a system, product or service can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use” och pratade om effectiveness och efficiency, hur de orden översätts till svenska (till synes samma ord effektivitet) men hur effectiveness framförallt utgår från i vilken mån målen uppnås och efficiency är kopplat till mängden resurser som förbrukas relativt uppfyllandegraden av målen.

Vi listade de sex grundprinciperna för användarcentrerat projektarbete

• djup förståelse av användare, uppgift, miljö
• involvera användare
• design drivs av utvärdering - användare
• processen bör vara iterativ
• design tar hänsyn till hela användarupplevelsen (“start” till “stäng av”)
• arbeta med personer som har olika färdigheter och olika bakgrund/perspektiv

När seminarieledaren kom förbi för att checka av gruppen satt vi och diskuterade Open-source och hur det direkt svarar på många av ovanstående punkter (och även tidigare teori). Hanna sa att Open-source mycket riktigt är vanligt vid utveckling av tjänster/till utvecklingsverktyg men att det samtidigt ju kan bli vad som helst av det - svårt att kontrollera resultatet vilket direkt i de flesta fall av projekt (såväl vårt) är önskvärt.

Om ISO 9241-11 pratade vi först om sätt att mäta användbarheten och hur det för att göra detta och väga in många aspekter krävs att mål, användningssammanhang & målgrupp är bestämda och detaljerat beskrivna.

Mål skall vara kopplade till målvärden som kan jämföras mot befintliga värden och även här finns tre områden att utvärdera

• grad av tillfredsställelse (‘frånvara av obehag’)
• exempelvis genom hur länge användaren stannar på sidan eller hur långt ner användaren scrollar
• eller kort personlig utvärdering efter användingen, typ tummen upp/ner eller olika smiley-symboler som en skala.
• ändamålsenlighet
• effektivitet

där det minst bör finnas ett mål per område/grej  (“användaren skall minst klara av … på X sekunder/minuter/…”).

Det andra som vi gjorde här var att gå igenom ett par nyckelord.

Praktisk utvärdering - hur mäter man användbarhet

Några exempel som vi kom på var: är folk sjuka mycket, vilket resultat uppvisas, vilken tid tar det.

Jämförande utvärdering - jmf produkter/tjänster

Hur betygsätts de olika (från användare, från oss som utvecklare, från …)

Vi gick igenom dokumentet Key principles for user-centred systems design och de 12 punkterna som där togs upp men upplevde inte att vi hade något ytterligare att kommentera, som vi inte redan precis tagit upp.

Slutligen så gav vi tid åt diskussionsfrågorna som vi tagit med oss till seminariet.

En fråga var Vilken/vilka utvärderingsmetod/er är mest rimlig och relevant för oss?

Vi tyckte att öppen utvärdering (alltså okontrollerad) skulle fungera bra och att utvärderingen kan implementeras direkt i produkten genom lite mer finurlig form av rate this-funktion (något som går fort och inte känns för krystad eller påtvingade). Ett bra exempel som vi uppmärksammade och kan ha som förebild är Facebook messenger som efter varje telefonsamtal ber att du väljer antal stjärnor (1-5) hur bra du upplever ljudkvaliteten var - detta tar upp hela skärmen och går typ fortare att fylla i än att kryssa bort + att frågan känns relevant för användaren då det ger skenet av att företaget anstränger sig för att leverera bättre kvalite och höja användarupplevelsen.

En annan fråga var Hur kan vi göra tjänsten självförklarande?

Vi pratade om hur vi kan utforma gränssnittet så användaren inte behöver kolla igenom massa tutorialvideor för att överhuvudtaget kunna börja använda produkten. Vi gjorde återkopplingar till bland annat Fitts' lag  och kommentarerna vi gjort kring det: ikoner med samma funktion på samma plats. Dessutom så kan vi med goda skäl anta att användaren är van att hantera olika datortjänster/ipad- eller smartphone-appar då vi riktar in oss på unga/skolelever (som med största sannolikhet har en egen telefon/dator/… och varit i nära kontakt med en stor mängd olika IT-tjänster). Vi får helt enkelt se till att ta efter och likna det som gjorts bra i andra tidigare applikationer som vi uppskattar och sedan utföra tester på diverse lämpliga användare.

En tredje fråga som vi tog upp - som vi även varit inne och snuddat på tidigare var Är det ok att vi samlar in åsikter eller data från användare? då det i viss mån/vissa fall kan ses som politiska åsikter och det främst är minderåriga vi riktar in oss på. Vi anser att det inte hindrar användandet (och därför framtagningen av tjänsten/projektet) men att hyfsat enkla åtgärder kan tas för att undvika att det ser ut som att vi är ute efter att samla in information om och från barn.