Digital Product Development

 

Design av Digitala Produkter

Prolog

Digitala produkter kan vara en website, en e-tjĂ€nst, en bred produkt som ett Ă€rendesystem eller dokumenthanteringsysstem, en smalare produkt som ett CAD-system och levererad som bĂ„de moln eller on-site, en mobiltelefon, ett system för att styra ljuset i ett hem, eller ett elektroniskt musikinstrument. De spĂ€nner över mĂ„nga mĂ€nsklig aktiviteter och olika anvĂ€ndningsomrĂ„den och affĂ€rsdomĂ€ner. Gemensamt Ă€r att det finns ett inslag av digitala lösningar i dessa produkter. SĂ„ vad hĂ€nder dĂ„ nĂ€r produkter fĂ„r mer eller mindre digitala inslag. Alan Cooper frĂ„gar retoriskt 'What do you get when you cross a computer with a car?' 'A computer!' Detta sammanfattar utmaningarna kring hur man bĂ„de utvecklar, producerar och anvĂ€nder produkter som har digitala inslag. PĂ„ samma sĂ€tt kan man sĂ€ga 'Vad fĂ„r du nĂ€r en verksamhet skall anvĂ€nda en digital produkt?' Den digitala produkten tenderar att ta över utveckling, förvaltning, anvĂ€ndande, ledning, styrning, ekonomi, kundrelationer, samhĂ€lle, vĂ€rlden, det tillgĂ€ngliga universum. Detta beror framför allt pĂ„ att digitala produkter innebĂ€r system vilket innebĂ€r komplexitet, som ofta ökar dramatiskt över tid. Men det finns ocksĂ„ nĂ„got som tar över Ă€nnu mer Ă€n de digitala inslagen, och det Ă€r mĂ€nniskor, som skall anvĂ€nda och utveckla dessa digitala produkter. Det komplexa försvĂ„ras av att vi mĂ€nniskor Ă€r benĂ€gna att lösa problem pĂ„ ett linjĂ€rt sĂ€tt, utifrĂ„n att de Ă€r komplicerade och att det gĂ„r att förstĂ„ och sedan lösa. Vi har ocksĂ„ en tendens att inte se system för vad de Ă€r eller hur man skall förstĂ„ dem. Och vi tenderar ofta att underskatta inte bara mĂ€nniskors behov eller varför vi faktiskt tar fram en produkt utan egenskaper som mĂ€nniskokĂ€nnedom, rationalitet och kĂ€nslor, företeelser som empati och respekt eller sociala system Ă€r ofta underrepresenterat i utveckling av digitala produkter. 

Det behövs dÀrför nÄgot annat och ansatsen hÀr Àr att detta finns inom designprocessen som börjar utifrÄn en vision men sedan rör sig mot gradvis realisering och kontinuerligt ÄtervÀnder till tidigare steg. Detta finns ocksÄ inom agila metodiker som ger utrymme kring osÀkerhet, kontinuerlig genomlysning och prioritering av vÀrde. Samt inom lean startup som tillför lÀrande, utforskande och sedan Àven praktisk kunskap som finns pÄ flera olika hÄll. Samtidigt behöver detta arbete existera i det sammanhang verksamheten erbjuder och dessa behöver dÀrför hitta former att fungera ihop.

Design av digitala produkter behöver:

  • dels ramas in sĂ„ att det finns tydlig och fungerande interaktion med projektledning, organisatoriska, bestĂ€llare eller intressenters sĂ€tt att arbeta. 
  • dels förmĂ„gor frĂ„n omrĂ„dena systemutveckling, arkitektur, agila metodiker, design och lean-tĂ€nkande. 
  • dels utgĂ„ frĂ„n att det Ă€r mĂ€nniskor i form av olika roller, anvĂ€ndare, utvecklare osv. Och att t.ex utvecklare Ă€r ocksĂ„ anvĂ€ndare, inte av samma produkt nödvĂ€ndigtvis, men andra.

Det denna site försöker adressera Ă€r hur dessa tvĂ„ delar kan levereras som praktiska verktyg utan att gĂ„ in pĂ„ teorin mer Ă€n vad som behövs, och som kan anvĂ€ndas för att rusta befintliga roller i bĂ„de utvecklande, och anvĂ€ndande/inköpande verksamheter. Det Ă€r alltsĂ„ verktyg som utgĂ„r frĂ„n ett sammanhĂ„llet sĂ€tt som ofta saknas. Dessa verktyg 'Ă€r' inte 'digitalisering', som Ă€r ett brett och svĂ„rdefinierbart begrepp, men 'kan anvĂ€ndas för' digitalisering. Eller i alla andra sammanhang dĂ€r produkter med digitala inslag skall designas.  

Designprocessen för digitala produkter

Översikt designprocess

Designprocessen handlar om att nÄgonting vÀcker ett behov om en förÀndring i verkligheten. Detta Àr ofta komplext och sjÀlva processen innebÀr flera 'Olika steg eller moment'. 'Beskriv varför'. 'Analys och research kring behovet'. 'Utforska olika lösningar'. Vertikalt löper en kadens av att 'Ensa en implementation med behov, förslag pÄ lösning och alla andra egenskaper' som beskrivs av kontexten nedan. Designprocessen Àr nÀstan alltid komplex, till skillnad frÄn komplicerad. Den behöver dÀrför hanteras genom att olika moment reduceras till enklare problem men som Àr tydligt definierade utifrÄn vad, hur eller en ansats, och hur man kan prova denna ansats. Det behövs ocksÄ en 'Styrning' av arbetet dÀr moment utifrÄn att ha provats och ger nya insikter, föder nÀsta moment eller ger en ny riktning, eller en ÄtergÄng dÀr man fÄr göra om.

Det handlar inte om problemlösning, som att laga en trasig apparat eller nÀr Sherlock Holmes löser ett mysterium. I dessa fall ÄtergÄr man till ett kÀnt, tidigare stadium eller har förstÄtt ett mysterium som har en given lösning. Designprocessen Àr det rakt motsatta, det finns ett oÀndligt antal lösningar.

Det Ă€r ocksĂ„ i en 'Kontext'. Design av digitala produkter rör sig kring de material som ingĂ„r i digitalisering, mjukvara, inbyggda produkter men ocksĂ„ sammanhang, socialt, samhĂ€lle, verksamheter och vad de vill uppnĂ„, hur anvĂ€ndare fungerar och vad de vill ha och hur en produkt Ă€r kommersiellt möjlig och egenskaper som tillförlitlighet och sĂ€kerhet. 

Designprocessen behöver ocksÄ 'Ledning' eftersom den alltid existerar i ett sammanhang av att nÄgot skall levereras inom ramen för resurser, personal, tid, pengar. Den kan inte hÄlla pÄ i oÀndlighet. Den kan inte leda till nÄgot som kostar hur mycket pengar som helst.

OmvĂ€nt finns en viktig aspekt att verksamhetens ledning och styrning alltid omger designprocessen som agerar pĂ„  dess uppdrag och leds av linje eller projektledning och sedan skall överlĂ€mna till en produktionsprocess av nĂ„got slag, tillverkning eller devops/produktion av digitala tjĂ€nster. Detta gör att man ofta misstar sig frĂ„n dessa andra sĂ€tt inom en verksamhet och antingen tror att till exempel en projektledningsprocess kan utföra designarbete, eller att projektledning och designprocessen Ă€r likadana. Men dessa Ă€r alla fundamentalt annorlunda Ă€n designprocessen, linjĂ€ra, sekventiella, komplicerade - inte komplexa och 'liquid' som karaktĂ€riserar designprocessen. Detta orsakar ofta att en fungerande designprocess inte hamnar pĂ„ plats, antingen för att den inte anses behövas, eller för att den styrs och leds utifrĂ„n felaktiga antaganden. Det Ă€r dĂ€rför viktigt för en verksamhet att förstĂ„ att designprocessen har en unik karaktĂ€r och ge utrymme för detta, och omvĂ€nt behöver praktiserande designers kunna visa det utrymme som behövs och sĂ€tt att synka emellan.

Avsikt

Avsikten med vad som tillhandahĂ„lls hĂ€r Ă€r inte att beskriva teori bakom design, eller hur man styr en sĂ„dan process eller hur den leds. IstĂ€llet Ă€r avsikten att ta fram och erbjuda praktiska verktyg som kan anvĂ€ndas bĂ„de av de som praktiserar design av digitala produkter, och av de övriga som ingĂ„r i det arbetet sĂ„ att alla kan bygga kunskap gemensamt kring bĂ„de hur man arbetar och kring det som skall tas fram. 

En lagom nivÄ av översikt

Insikt Det Ideala Det Reella

Design av digitala produkter Ă€r att förstĂ„ behov som ger insikter, hitta en ideal lösning och sedan nĂ€rma sig en reell produkt. Detta Ă€r designprocessen. Mest reducerad Ă€r den: fĂ„nga ’the Ideal’ och gör ’the Real’ real.

Med formulera och judgement

TvÄ moment till behövs. Experimentet behöver formuleras och utfallet behöver beskrivas. Resultatet behöver sedan bedömas. Samma gÀller för prototypen, det behöver beskrivas hur den skall förbÀttras och resultatet bedömas.

Fram och ÄtergÄende

Det finns ocksÄ en rörelse tillbaka, sÄ att designarbetet görs i inkrement. Dessa kan gÄ olika lÄngt, arbetat kan ta en ny riktning vid varje bedömning eller dÄ det planeras. Huvudriktningarna Àr att fortsÀtta, att gÄ tillbaka, att vÀlja en av flera möjligheter.

En lagom nivÄ av bakgrund

Det sÀtt att designa digitala produkter som redovisas hÀr utgÄr frÄn designprocessen, IT-arkitektur, agila arbetssÀtt och systemutveckling, dÀrför att vi tror att en kombination av dessa behövs. ArbetssÀttet innehÄller dÀrför en rad moment och aktiviteter, arbetssÀtt, relationer till andra förmÄgor och roller, inom projektarbete, linjearbete, systemutveckling. Dessa Àr ibland helt annorlunda och ibland överlappande eller sÄ Àr de till och med i princip lika.

De huvudsakliga momenten Àr:

  • Syfte och vision och hur man kommer fram till vad verksamheten och dess anvĂ€ndare faktiskt behöver.
  • ArbetssĂ€tt i teamet och mot övriga organisationen. Även detta följer pĂ„ vision och syfte och Ă€r grunden för det fortsatta arbetet. Grunder Ă€r i korthet 'fail fast', 'fail safe' och begreppet 'holding environment'.
  • Planering och prioritering.
  • FörstĂ„else, research, analys, clustring av vad det Ă€r man behöver, hur verksamheten fungerar, tekniska möjligheter.
  • Utforskande av insikter och behov som fĂ„ngas och hur de kan lösas och realiseras.
  • Leverans. Som en sista del skall nĂ„got sĂ„ riktigt som möjligt hela tiden levereras. Som prototyp, mockup eller en första, iterativ och inkrementell produkt, en MVP.

De huvudsakliga arbetssÀtten och principerna Àr:

  • LĂ€rande Ă€r det som driver arbetet, i vĂ€l avgrĂ€nsade inkrement och med medveten granskning och beslut om nĂ€sta lĂ€rande.
  • Praktisk kunskap. Det finns traditionellt och historiskt ett överskott och övertro pĂ„ att man kan analysera och specificera fram lösningar pĂ„ behov. Det finns samtidigt en gryende motrörelse frĂ„n olika hĂ„ll som visar att detta inte fungerar. Det Ă€r dĂ€rför viktigt att hitta sĂ€tt som kan introducera praktisk kunskap som smidigt verktyg genom olika och genomgĂ„ende sĂ€tt att anvĂ€nda modeller och prototyper. 
  • Att varje inkrement har en tonvikt, som vision, research eller designförslag men att alla andra moment fĂ„r ett visst utrymme. Ett rekursivt sĂ€tt, att stĂ€ndigt Ă„terkomma till, i moment sĂ„ att allt frĂ„n syfte och vision till leverans Ă€r med oavsett denna tonvikt. 
  • Att arbete det Ă€r delat med team, bestĂ€llare och andra intresenter. Grunder Ă€r 'delad', 'gemensam', 'tydlig'.
  • Att alla inkrement valideras, rĂ€tt produkt, och verifieras, produkten rĂ€tt. Oavsett moment. FrĂ„n visionen till leverans.
  • Att alla inkrement sammantaget bildar nĂ„got som nĂ€rmast liknar 'The Design Squiggle' men som över tid Ă€ndĂ„ drar sig frĂ„n de klassiska faserna 'Define', 'Elaborate', 'Implement' och 'Test'. Samt rörelsen frĂ„n Design Thinking kring 'diverge/converge'. Detta gör ocksĂ„ att en designprocess Ă€r kompatibel med linjĂ€ra projekt eller agila genom exempelvis 'staggered sprint' eller 'rolling wave'-förfarande.
  • Praktisk förstĂ„else för hur mĂ€nniskor fungerar, bĂ„de som anvĂ€ndare och utvecklare. HĂ€r finns mycket att hĂ€mta frĂ„n UX och tjĂ€nstedesign men Ă€ven ergonomi, behavioural economics och ramverk som Sociocracy, Teal och andra.
  • Att presentera verktyg och metodiker utifrĂ„n verksamhetens förutsĂ€ttningar, domĂ€nspecifikt, och den kultur som rĂ„der. Inom rimliga grĂ€nser.

De huvudsakliga kompetenserna Àr:

  • Arkitektur. HĂ€r avses IT-arkitektur i bred mening. Detta adresserar egentligen allt i en verksamhet, affĂ€rens arkitektur, produkter och hur de fungerar i sammanhang och förstĂ„else för kunder och anvĂ€ndare. Hur detta arbete utförs av olika arkitektroller och vilka metoder, ramverk och leverabler Ă€r. 
  • Design. HĂ€r avses designtĂ€nkande generellt och mera specifikt 'tjĂ€nste', 'service'-design och omrĂ„den kring anvĂ€ndbarhet. Men Ă€ven generell produktdesign och industridesign.
  • Systemteori. En del av bĂ„de arkitektur, design och agila metodiker, men sĂ„ fundamental att förstĂ„else för hur system fungerar mĂ„ste vara en egen kompetens. Ett problem Ă€r att systemteori kommit att beskrivas sĂ„ olika beroende pĂ„ vem man lĂ€ser och vilken domĂ€n det gĂ€ller. Det viktiga att förstĂ„ Ă€r att mer Ă€n man kanske först inser, Ă€r system och att system sĂ€rskilt nĂ€r de pressas mot en grĂ€ns, uppvisar o-intuitiva, alltsĂ„ komplexa eller kaotiska beteenden och dĂ€rmed inte kan adresseras analytiskt utan bara via 'probe/sense'.
  • Systemutveckling. Allt frĂ„n hur man utifrĂ„n krav, vĂ€ljer designlösningar, plattformar och utvecklingsverktyg till att verifiera(produkten rĂ€tt) och validera(rĂ€tt produkt) samt hur man levererar inklusive emballage, anvĂ€ndarmanualer och support.
  • Agil utveckling och Lean-tĂ€nkande. Agil verksamhet och systemutveckling och lean produktutveckling, inklusive 'Continous Product Management'. I bred mening.
  • FörstĂ„else av mĂ€nniskor, deras beteende och hur sociala system fungerar. (tbd stĂ€rk detta. vad Ă€r det so mbehövs, Teleios, Conway, Westrum osv.)

NÄgot om 'varför' i designarbetet

Det kanske viktigaste Àr ocksÄ varför vi gör nÄgonting. Att nÄgonting skall gÄ att sÀlja Àr givetvis inte alltid svaret. Att vi emellanÄt tappar bort 'varför' har olika orsaker. Cargo cult eller att vi egentligen inte tar reda pÄ det frÄn början eller tappar riktningen nÀr vi trasslar in oss i komplexitet och att över huvud taget fÄ nÄgot att funka och ut genom dörren. Egentligen Product Management Àr det ett Äterkommande tema i design och arkitektur men som samtidigt fÄr förvÄnansvÀrt lite praktiskt fokus. Det Àr dÀrför viktigt att hitta sÀtt att stötta bestÀllare genom att ge perspektiv pÄ, samt givetvis sjÀlv bedöma om ett uppdrag Àr vÀrt att fortsÀtta.

DÄ sÄ

Mera bakgrund blir det inte hĂ€r utan huvudsyftet med denna site Ă€r att tillhandahĂ„lla praktiska verktyg, avsedda att anvĂ€ndas av en mentor som Ă€r hemmastadd i den bakgrund verktygen bygger pĂ„, men som i mĂ„nga fall Ă€ven kan anvĂ€ndas av vem som helst i en verksamhet. Verktygen kan ocksĂ„ fungera som stöd för andra roller men som kĂ€nner igen sig i problemstĂ€llningar de stĂ€lls inför. Det finns dock en rubrik 'Fördjupningar' dĂ€r en del bakgrund utvecklas vidare. 

Disclaimer

Detta arbete Ă€r under utveckling och förĂ€ndras hela tiden utifrĂ„n erfarenheter frĂ„n praktiska prov i olika verksamheter, genom granskning och kritik frĂ„n olika samarbetspartners. 

Utveckling av olika initiativ redovisas pÄ 'Initiativ.log'.