Designprocess eller Utvecklingsprocess

Vi har tills vidare valt att kalla den process som tar fram sätt och system för att stötta verksamheten för ‘designprocess’. Ett alternativ är att kalla det ‘utvecklingsprocess’. Med designprocess vill vi framför allt lyfta fram att det rör sig om designarbete vilket det står mer om nedan och hur det relaterar till vetenskapligt arbete, vilket enligt vår mening ofta är vad som förväxlas när man pratar om utvecklingsarbete. Å andra sidan så kan man säga att den mera generella termen ‘utvecklingsprocess’ och ‘utvecklingsarbete’ kan rymma både ett design och och vetenskapligt sätt att arbeta. Kanske är detta rätt och vi isåfall väljer att ändra oss så att vårt sätt att se utgår från utvecklingsarbete. 

Aktiviteter, process och styrning

Oavsett så behövs det begrepp att utgå ifrån och vi menar att ‘arbete’ är ett sådant begrepp, liksom ‘aktiviteter’. Designarbete innebär aktiviteter/designaktiviteter. Detta behöver formaliseras i en process, en designprocess. Och det behövs ledning, designstyrning/design-management. Samma gäller om vi väljer ‘utveckling’ eller ‘arkitektur’ eller ‘systemutveckling’. 

Men designprocess är mera bred och hämtar mera naturligt in influenser fårn andra områden. Designrörelsen, agila coh lean startup och arkitektur och systemutveckling som har många olika innovativa sätt att arbeta typ devops. Devops i sig är en kultur som också sprider sig upp mot product management och sedan träffar dessa kompetenser andra ideer som kontinuerligt utforskande, iterativt, lean att experimentera sig fram och formar continous product management som en del börjar prata om och prova sig fram kring nu.

Designprocessen hänger alltså ihop med ledning och styrning och utförande av informationsförvaltning. Designprocessen är också något som utförs inte bara i framtagande av nya produkter eller tjänster utan på alla nivåer och områden i en verksamhet, i större eller mindre omfattning och mer eller mindre medvetet. Österlin beskriver detta på ett bra sätt i sin bok där han utgår från hur verksamheter har just detta perspektiv i utformning av vision och riktning och hela vägen ner via marknadsföring, framtagning av produkter och utformning av lokaler, till exempel en restaurang.

Mera fördjupning om designprocessen – en fortsättning på ovanstående

Designprocessen. Vi har valt detta men kunde lika gärna säga utvecklingprocess. Men designprocess är mera bred och hämtar mera naturligt in influenser fårn andra områden. Designrörelsen, agila coh lean startup och arkitektur och systemutveckling som har många olika innovativa sätt att arbeta typ devops. Devops i sig är en kult ur osm också sprider sig upp mot product management och sedan träffar dessa kompetenser andra ideer som kontinuerligt utforskande, iterativt, lean att experimentera sig fram och formar continous product management som en del börjar prata om och prova sig fram kring nu.

Designprocessen hänger sedsan ihop med ledning och styrning och utförande av informationsförvaltning som det st år om på andra ställen här på webben. Så dessa hänger ihop. Vissa saker som att förstå processer och information är en del av designprocessen, det är där det börjar. Och då kan designprocessen både använda vad som kommer ut därifrån coh gå vidare för att närma sig en lösning. Men också omvänt, deisgnprocessen innebär dels ett utforksnade tänkadne som kan användas i proccesskartläggning. Och när man närmar sig en lösning så innebär det också experimenterande vilket behvöer försa tillbkaa till verksamehten för att se om det fungerar där.

Designprocessen behöver också ledning. Detta är ett mycket stort område och sträcker sig i princip ifrån my cket styrda, vattenfallsliknande processer, st andardiserade reglerande arbetssätt till agila, lean utforskande och självorganiserande team som arbetar på ett helt annat sätt. Ofta är det en blandning där drift och förvaltning har ett ramverk och arbetssätt och verksamehter och dess utveckling andra.

och framför allt måste man börja där man står. Utifårn verksamehtens förutsättningar. Det är vad vi vill hjälpa til med här. Vi är agnostiska vad gäller metodiker och ramvekr. Vi rekmomenderar sådant vi tycker är bra men vi vill föra diskusisonen och presentationen också mot metodker och mindset så att verksamheter, roller och personer kan rustas, det är inte alltid man behöver hyra in en konsult eller anställa en ny kompetens. Samma med det som finns, nyttoanalsy, innovationstänkande osv. i verksamehten där vill vi visa på hur man kan ansluta, rusta, använda vad som finns, stärka coh utveckla sin förmåga och sedan när man vet vad man vill ha utöka med nya personer och roller och sätt.

Kortfattad beskrivning: Designprocessen

1. Leverera lösningar som motsvarar användars behov och verksamhetens impact och inom ramen för kostnad, säkerhet osv.

2. Men hela tiden är det balans mellan dessa olika delar. Utvecklingstid mot tid till marknaden. Säkerhet mot användbarhet. 

3. Förstå vad behov är och hitta en lösning som passar.

4. Kvalitetssäkring och spårbarhet. I tid. Rätt produkt. Produkten rätt. I linje med verksamhetens övriga system. I linje med verksamhetens övriga förmågor som samma sätt att hitta eller lagra.

5. Iterativt är ett sätt men som oftast inte fungerar i komplexa situaitoner. En kontinuerligt utforskande approachering är normalt det som fungerar bättre och som hela tiden tar sig fram lärande via praktiska experiment. Detta kan bli en konflikt i innovationsmetodiker som är för linjära, dubbeldiamnaterna eller Design Sprints är exempel på sådana.

Mera fördjupning om designprocessen

Designprocessen är egentligen vad det handlar om. Det är den generella sättet att skapa saker. Ursprunget är mycket gammalt. Mera läsning om detta finns framför allt i Design Way som handlar om mänskligt skapande och teoriering bakom detta.

Designprocessen är generell och innehåller alltid samma steg även om de kallas olika saker. Den kan sedan utföras på olika sätt beroende på vad den adresserar, industridesign, arkitektur, mjukvara. Det första steget som handlar om att förstå problem avgör också hur den fortsatta processen ser ut, enkla problem, komplicerade eller komplexa problem. Dessa olika problemtyper kan man läsa mer om i boken ’Conceptual blockbusting’ samt hur man adresserar dem beskrivs i metodiken som kallas Cynefin och som är en del av systemteori.

Den grundläggande designprocessen har följande steg: Förstå och definiera problemet. Förstå behov hos användare, verksamhet, omgivning. Föreslå en eller flera lösningar. Bygg, implementera. Testa. Leverera och förvalta.

En av de mer spridda företeelserna av en designprocess rör industridesign och i viss mån grafisk och kläddesign. Roller som utför detta kallas designers och processen kan ibland beskrivas som innovation eller en kreativ process. Grunderna är dock densamma och förutsättningarna och hur processen går till är mycket beroende av vad det rör sig om, kläder, bilar, hushållsmaskiner, trycksaker utför i grunden samma steg men har olika ledtider, olika möjlighet att experimentera och prova sig fram liksom kostnad för materialet.

Detta ger ytterligare en dimension. Designprocesser har alltid olika begränsningar. Kostnad för utveckling och tillverkning av färdiga produkter. Säkerhet, prestanda, kulturella aspekter. Det finns en mängd och en viktig del i designprocessen är att balansera, eller kompromissa, och hitta en så bra lösning som möjligt, givet förutsättningarna. I boken ’Design i fokus’ skriver Österlin om det han kallar ’Det fria fältet’ som är en talande bild för designprocessens begränsningar.

Alla designprocesser behöver, liksom informationsförvaltning, någonslags ledning och styrning. Man brukar prata om ’design management’.

För mjukvara kallas designprocessen ofta ’mjukvaruutvecklingsprocess’ eller ’utvecklingsprocess’. Den omfattar från början främst det som kallas ’systemutveckling’ alltså att ta fram mjukvaru eller digitala eller elektroniska applikationer, tjänster och produkter. Digitalisering är ett relativt sent begrepp, det finns inte med i SAOB och SAOL har en mycket smal beskrivning. Digitalisering har dock kommit att handla om en bred form av designprocess som innefattar användare, verksamheter, olika digitala produkter och tjänster som löser behov eller erbjuder tjäsnter och även hur användare, verksameheter och hela samhällen transformeras.

Utveckling av digitala lösningar har några speciella egenskaper som särsklijer från många andra designprocesser. Materialet är oerhört flexibelt. Produktionskostnaden är i det närmaste noll när det gäller rena mjukvarulösningar, eller kan vara mycket hög när det gäller digitala produtkter. Utvecklingskostnaden är däremot ofta hög, tar lång tid och innefattar många personer och roller. Utvecklingen stannar nästan aldrig utan fortsätter under produktens livstid. Ett köksföremål är statiskt när det väl producerats. Bilar börjar närma sig rena mjukvaruprodukter. Men framför allt är digitals lösningar normalt mycket komplexa. Jämförelse med flygindustrin visar att den är bättre på att få produkter att fungera vid ett första försök än ett mjukvarusystem. Vad som å andra sidan är likt andra designprocesser är förutsättningar och begränsningar, det fria fältet. Digitala lösningar är mycket beroende av driftplattformar, säkerhetskrav, kostnad vad gäller licens eller hårdvara. 

En annan egenskap vid digital utveckling är att problemen ofta är komplexa, snarare än komplicerade. Komplicerade problem är sådana som kan utredas, analyseras, förstås och sedan lösas. Det är en relativt linjär process. Komplexa problem å andra sidan, även kallade wicked problems, går inte lösa så, där måste man utforska, prova praktiskt coh göra om.

Vad vi vill adressera i denna del handlar om hur man tar de metodiker coh ramverk som beskrivs kring informationsförvaltning till praktiska digitala lösningar. Man kan säga att flera av de steg som beskrivs, processanalys, informationskartläggning är sådant som faller inom ramen för en designprocess. Alltså designprocessen har redan börjat där. Detta är också normalt inom digitala lösningar och systemutveckling, att gränserna mellan olika aktiviteter, ollika roller i en verksamhet hänger ihop.

Hur vi vill adressera här är praktiska metoder, sätt och verktyg som hjälper verksamheter att hantera en designprocess för digitala lösningar, för digitaliesring. Det finns stora ramvekr att hämta, som SAFE, det finns också ett mycket brett utbud av olika metodiker för faser som behovsanalys, mjukvaruutveckling, testning. Vi tror dock att verksamheter ofta har hög kompetens och stora möjligheter och att de kan rustas och stärkas och att det är där man bör börja, med en förståelse av vad som behövs. Sedan kan man välja att köpa in verktyg eller anställa nya roller.

Ännu mera fördjupning om designprocessen

Så varför börjar vi med designprocessen. Därför att designarbete är all mänsklig aktivietet där vi förändrar verkligehten på ett medvetet sätt. Detta sätt kan då ha varierande grad av ledning och styrning och operativa sätt att utföra. Men deisgn pågår hela tiden. Vi menar att det förekommer i alla delar av en verksamhet

Det designmetodiker, roller och verktyg tillför är att reducera komplexitet, lyfta fram och tydliggöra förhållanden inför den del av designprocessen som är grundläggande; att granska och göra val. Hela cykeln, sammanfattas på olika sätt men i grunden är det ’research & inquiry’(Design Way) och i en lite mera utvidgad form, ’build measure learn’(Lean Startup) och den klassiska utvecklingsmodellen som är ’förstå problem – formulera behov – ta fram lösningsförslag – bygg – test – inför’, (RUP m.fl).

Denna långa variant av processen har en tendens att bli bli linjär och förväxlas med ett vetenskapligt arbetssätt, det är lätt att vi tror att om vi bara utreder och förstå behov och utifrån detta tar fram en lösning så hamnar vi autoamtiskt rätt. Men då har vi missförstått problemställningen. Designproblem kan inte lösas med vetenskapliga tillvägagångssätt. Erfarenheten visar att det kan fungera men det innebär stor osäkerhet och graden av misslyckanden ligger utanför konfidensintervallet, särskilt påtagligt är detta arbetssätt och resultaten tydliga vid offentliga upphandlingar. Arbetssätt som agila metodiker och Lean Startup har inspirerats från tillverkningsindustring med rötter ifrån Deming och Andra Världskriget via frmaför allt Toyota och tagit fram metodiker inom ramen för den agila rörelsen och Lean Startup.

Så vart vill vi komma med detta resonemang. Det är flera saker:

– Designarbete är av en särskild typ och skiljer sig från vetenskapligt arbete och som det ofta förväxlas med. Men dessa är i grunden olika; designarbete är att metodiskt hitta en lösning på behov och som behöver utforskas för att bli praktiska men som har i principe en oändligt antal varianter/ lösningar. Vetenskapligt arbete är att metodiskt arbetssätt komma fram till en från början given sanning. 

– Designarbete behöver en designprocess och design management eller ’Ledningsystem för designarbete’.

– Designarbete förekommer på alla områden och alla nivåer i en verksamhet. Att besluta om verksamehtens inriktning, om hur lokaler skall utformas, och givetvis om produkter och tjänster. I många fall är inslaget av designarbete litet, som givna processer och sätt exempelvis en väl reglerad löneprocess.

– digitala produkter handlar egentligen om en desigprocess, ’produkt design av digital art’ skulle man kunna säga. Eller ’digital produkt-design’ där dubbeltydigheten måste förklaras ’design av digitala produkter’ och ’digital deisgn av digitala produkter’

– designarbete pågår i en verksamhets alla delar. Detta innebäär alltså att 

Det är också viktigt att göra en distinktion i vad designarbetet tillför utifrån den breda mening vi vill se. Inte fullödigt men exmepel:

– I grunden handlar designarbetet om att bygga rätt produkt(mera ansvar), bygga produtken rätt(mindre ansvar), inom ramarna för tid, resurser, kostnad, säkerhet, (bredd/att passa in i en ekologi av liknande delar/att naturlig och smidigt ingå i ett flöde av aktiviteter)

– Det handlar i grunden alltså om balans – tid och att leverera mot rätt produkt och proudkten rätt. Säkerhet mot användbarhet. Osv. 

– Ett antal grundprinciper som hög kohesion och låg koppling

– Balansen är nära kopplad till granskning och beslut. Därför är en viktigt del när behov eller olika lösningsförslag förståtts, att också kunna tyldiggöra, lyfta fram, för en bredare grupp, eller besltusfattare. Här kommer olika typer av modeller. För att förtydliga finns också inslagen av experiment. Experiment kan vara med riktiga lösningar eller olka typer av prototyper, mockups och även modeller. Vad som behöver tydliggöras är egentligien i alla delar av arbetet, för förståelse av behov, för att tydliggöra hur produken passar in i verksamhetens övriga delar, säkerhetsmässigt, proudktionsmässigt, aävndarmässigt.

– Detta har med riskhantering att göra. Vi granskar och fattar beslut för att balansera lösningar och för att göra detta med så låg risk som möjligt bheövs bra underlag som är tydliga och kan förstås av den grupp, ofta så bred som möjligt, för att minimera risk att vi hamnar fel, att vi missat något.

Några ord om ’granskning’. Detta ord kan lätt missuppfattas som kritik. Det är också ett ord som används i designbranschen på engelska men där man använder en förkortning ’crit’ för att visa att det är något annat än ’critisicm’ t.ex. Att använda svenskans ’genomgång’ blir för otydligt och inte tillräckligt kraftfullt. Vi använder därför ’kritik’

När vi nu börjar närma oss just digitala lösningar och ’digital produktdesign’ alltså design av digitala produkter, och digitaliseirng och IT-branschen som generell domän så är det några saker vi vill frmahålla:

– Digitala åprodukter är,som vi tidigare skrivit om, av en lite särsklid art med låg materialkostnad, i princpi oändliga produktionskvantiteter till mycket låg produktionskostnad och framför allt abstrakta. 

– Vi tror därför att det finns ett särskilt behov av att tänka i att digiala produkter behöver få en form. Det är inte riktigt som med produktdesign att det vi tar fram kommer att få en fysisk form. Det är svårt att relatera till tidigare produkter, känna på dem, uppleva dem fysiskt. Men många av metodikerna som finns inom industridesign eller arkitektur, modeller, skisser fungerar lika bra och bör användas än mer, inklusive protoyper och modeller i papper, kartong, foamboard – detta är något som vanlgitvis inte förekommer. IT-branshen brukar stärcka sig till digitala skisser, och Post-its på enwhiteboard men vi tror det finns en mögjlieth att utforksa mera pågatliga modeller och även inspierras av grafisk och boardgame-design för att nämna några exmepel,.

– Sedan hur vi nu nämrmatö oss designarbete, designprocee oh management av den, dsamt hur digitala produkter deisnasg så kommer vi också till domänen, informationsförvaltning, informationshanteirng och dokumenthanteirng.

En avslutande förklaring kring hur vi närmar oss detta:

– Vi tror inte det gå ratt beskriva den designprocess för digitala produkter inom informationsförvlatning – fullödigt, från början, som är klar och försåelisg för användare och som ger praktiska resultat i deras olika respektive verksamehter.

– Vi närmar oss istället detta genom att:

  – Beskriva och ta framen plattform här på webben för ett provande, utforskande, eperimenterande sätt att beskriva detta. Det innefattar dessa artiklar men även diskussionforum, blog och praktiska resurser att ladda ner och prova. Vi har även ambitionen att kunna träffas i olika former, un-conference liknande fomrer som ’Lean Coffee’ ’är vad vi tänker oss att börja med.

– Vi skapar också en struktur där vi börjar nämrma oss ämnet. Vi försöker använda och beskriva begrepp så vi pratar om samma sak. Vi försöker positinoera deisgnarbete/process, digital produktdesign och domänen kring informationsförvaltning. Samt de olika delarana i designarbetet; arkitektur, deisgnarbete/UX, systemutveckling, agila metodiker. Samt inom dessa olika verktyg som framför allt utgår från var i processen man befinnner sig, problemförståelse, behovsfångst men även utifrn var i lösningen man beifnner sig dvs verksamhetsnivå, lösningsnivå, infrastruktur ohc perspektiv som mål vision syfte, process, informatoins, säkerhets ovs. Perpsektiv – dteta utgår fårn Zachman/Sundblad & Sundblads ramverk. Vi utgår också fårn att deifniera rolelr och vad dessa gör och leverera samt hur de samverkar – här utgå vi fårn ’Svenska IT-arkitektroller’ IASA.

Rekommenderad läsning är ’Design i fokus’ och ’Design management’, Kenneth Österlin och ’Design Way’, Stolterman

’Out of the crisis’, Deming

Kommunikation och dialog och lärande

Kommunikation och dialog är grunden eftersom i grunden handlar systemutveckling om lärande. Det osm flyter i processen är kunskap. Det handlar därför om kommunikation och relationer. Det är i slutändan mskor som skall använda, leda och styra det som tas fram. Det är mskor som skall förstå och bygga och få på plats lösningen. Det är därför det kanske allra viktigaste att få igång dialogen mellan dessa mskor. För det behövs organisation, sätt, verktyg, roller. Det är därför det finns så många olika sätt och därför de mera o-tekniska inslagen i utvecklingsarbete är både framträdande och fundamentala, som agila metodiker, scrum, designtänkande och problemlösning, team och hur de organiseras, tydliga regler och protocols(kommunikation osv.)