Ketterät menetelmät ja digitaalinen design
Ketterät ohjelmistokehityksen menetelmät, kuten Scrum, on tarkoitettu koodaajien työn organisointiin. Siinä ne onnistuvat hyvin – tuskin kukaan kaipaa enää takaisin pitkien vesiputousprojektien aikaan. Sen sijaan tavat, joilla designerit osallistuvat ketteriin projekteihin, eivät ole lainkaan vakiintuneet.
Kun ketterien menetelmien peruskirjaa, agile manifestoa, kirjoitettiin, designerit eivät olleet paikalla. Siksi on ymmärrettävää, että tästä kulttuurista ponnistavat menetelmät eivät ota designereiden työtä huomioon. Kaikki kuitenkin ymmärtävät, että designerit ovat välttämättömiä, jotta sovellukset ja palvelut saadaan erinomaisina tai vähintäänkin kelvollisina asiakkaiden käsiin.
Kaikki näkemäni kehitysprojektit tuskailevat designin yhdistämisestä ketterään sovelluskehitykseen. Voidaankin sanoa, että design on agileen kantapää.
Olemme kaikki vastuussa lopputuloksesta
Lähtökohtaisesti ketterät menetelmät toimivat vain sopivan pienissä tiimeissä, jotka pystyvät itsenäisesti ottamaan vastuuta lopputulemista. Softaprojekteissa tämä tarkoittaa sitä, että tiimi saa säännöllisesti ulos valmiita tuoteversioita, jotka ovat sekä teknisesti että designiltaan laadukkaita ja toteuttavat niille asetetut liiketoimintatavoitteet.
Tärkein tekijä kehittäjien ja designereiden yhteistyössä onkin yhteisvastuu. Kun designerit ovat koodaajien kanssa vastuussa siitä, että tiimi saa tuotettua julkaisukelpoista koodia, heidän täytyy oman suunnittelutyönsä yhteydessä miettiä, miten designit pilkotaan sopiviin toteutettaviin ja julkaistaviin palasiin.
Designereiden täytyy samalla kuunnella kehittäjiä. Näin he voivat ymmärtää, ovatko heidän hienot suunnitelmansa toteutettavia ja saavat ideoita siitä, miten jotkin designit voisivat olla helpompia toteuttaa ilman, että esimerkiksi helppokäyttöisyydestä tarvitsee tinkiä.
Leiriytymisen sudenkuopat
Jos yhteisvastuuta ei ole, vaan designerit vastaavat vain suunnittelusta ja kehittäjät koodaamisesta, alkaa leiriytyminen. Designerit saattavat piirtää idealistisia suunnitelmia, joita on hidasta tai virhealtista toteuttaa. Koodarit jupisevat, etteivät design-kuvaukset ole tarpeeksi tarkkoja. Designerit vastaavasti kiroilevat keskenään, etteivät koodarit seuraa designeja tarpeeksi tarkasti. Tällaista vastakkainasettelua kannattaa välttää kaikin keinoin.
Siksi kehitystiimien kannattaa miettiä scrum-käytäntönsä huolellisesti. Suosittelen, että kaikki työ ohjataan yhdessä samalla kanban-taululla tai Jira-boardilla ja yhteisillä tiketeillä, joista designeri ja koodari vastaavat yhdessä. Erillistä työn suunnittelua, erillisiä design- ja toteutustauluja tai dual-track -systeemejä en suosittele.
Designin organisoinnin yksi perinteinen kysymys on: pitäisikö design-osaaminen keskittää yrityksissä yhteen paikkaan, vai pitäisikö se hajauttaa eri yksiköhin, tiimeihin ja projekteihin.
Edellä mainittuun yhteisvastuuseen viitaten kannatan ehdottomasti hajautettua organisaatiota: designereiden on oltava siellä, missä muu tiimi on. Keskitetty design-organisaatio johtaa aina leireihin, tarpeettoman yksityiskohtaiseen designien dokumentointiin ja virhealttiisiin hand-overeihin.
Mitä on DesignOps?
Hajautetussa design-organisaatiossa on haasteensa. Kuinka designerit pitävät yllä ammatillista osaamista, designin laatua, designin yhtenäisyyttä sekä kollegojen välistä yhteisöllisyyttä? Tätä varten on DesignOps.
DesignOps Handbook kiteyttää DesignOpsin tällä tavalla: “Tools, infrastructure, workflow, people, and governance.” Designereiden pitää siis yhdessä sopia työkaluista ja ympäristöstä, työnkuluista ja prosesseista, ihmisten ohjaamisesta sekä hallintomallista.
Omassa ympäristössämme VR:llä olemme vielä melko alussa design-toimintojen kehittämisessä. Jotkin asiat ovat kuitenkin jo hyvässä järjestyksessä ja parantavat ja nopeuttavat toimintaamme.
Design-työkalut ja työtavat VR:llä
Olemme yhtenäistäneet design-työkalumme. Käytämme Sketch-Invision-Abstract -kolmikkoa suunnitteluun, nopeaan prototypointiin ja tiedostojen jakamiseen designereiden kesken. Päivittäiset nopeat keskustelut käydään HipChatissä. Formaalimpi projektien työnhallinta ja dokumentointi yhdessä koodareiden kanssa tapahtuu Confluencessa ja Jirassa.
Emme ole vielä kehittäneet varsinaista Design Language Systemiä (DLS), mutta Abstractin kautta meillä on käytössämme yhteiset tyylikirjastot. Tämä nopeuttaa ja yhtenäistää designia. Esimerkiksi yhden designerin suunnitellessa juuri oikeanlaisen ja brändiin sopivan webbipainikkeen, se on saman tien kaikilla muilla suunnittelijoilla käytössä Abstractin kautta.
Tuotetiimien työskentelytavat tulevat lähtökohtaisesti softapuolelta, mutta se tapa, jolla design yhdistetään softan kehittämiseen, on samanlainen kaikissa tiimeissä. Lisäksi meillä on design-käytäntönä tehdä käytettävyystestejä tai asiakashaastatteluita työn alla olevista ominaisuuksista viikottain: näin saamme välitöntä palautetta oikeilta asiakkailta ja voimme korjata mahdollisesti löytyvät ongelmat samantien.
Vieläkin tärkeämpää palautetta saamme siinä vaiheessa, kun julkaisemme palvelujen esiversion kokeiluun valikoidulle koematkustajajoukolle. Silloin näemme, kuinka palvelumme toimivat tositoimissa ja voimme vielä hioa käyttäjäkokemusta paremmaksi ennen niiden avaamista suurelle yleisölle.
Kriittistä uudistumista
Designin työtapojen ihanne on malli, joka periytyy Human-Centered Design -prosessista tai sittemmin onnistuneesti uudelleen brändätystä versiosta “Design Thinking”. Malli on jo nelisenkymmentä vuotta vanha ja perustuu vaiheistettuun vesiputousmalliin, joka on hidas ja jäykkä. Ohjelmistopuoli siirtyi pois tästä mallista käytännössä kokonaan jo vuosikymmen sitten.
Vaikka itse koenkin olevani yleensä designereiden puolella, tässä kohdassa voin vain ihmetellä, kuinka paikalleen design-prosessien kehittäminen on jämähtänyt. Kokeilepa googlata “design process” niin näet, kuinka kaikki prosessiehdotukset ovat kuin samasta muotista (pienillä mutta epäoleellisilla variaatioilla). Milloin designista tulee oikeasti ketterää?
Ketterän kehityksen ja designin yhteensovittamisen ongelmat juontavat osittain juurensa tähän suureen filosofiseen eroon. Ei ihme, että designerit, joiden työtavat ovat aivan erilaiset kuin koodareiden, kokevat vaikeaksi yhdistää omaa työtänsä valmiiseen agile-malliin. Suosittelenkin kaikille designereille ja design-työtä ohjaaville avoimen kriittistä suhtautumista vallitseviin malleihin. Sen sijaan että otat valmiin prosessin, templaten tai canvasin ja pakotat projektisi tähän malliin, mieti ensin itse, mikä prosessi ja mitkä työtavat sopivat juuri tähän tilanteeseen.