Design engineering: kun muotoilija tekee työtä koodissa

Olen tehnyt muotoilutyötä pitkään kehittäjien kanssa. Olemme pohtineet yhdessä, miten jokin ratkaisu kannattaa toteuttaa, mitä teknisiä rajoitteita voi tulla vastaan, mitä komponentteja design systemissä jo on ja mikä kannattaa tehdä uutena. Työnjako on silti ollut lähes aina sama: minä tein suunnitelman suunnittelutyökalussa, esimerkiksi Figmassa, ja kehittäjä rakensi sen koodiksi.

Tekoälyn myötä tämä työnjako on alkanut muuttua. Voin nyt tehdä osan työstä suoraan koodissa: toteuttaa komponentteja valmiiksi, tehdä koodilla toimivia prototyyppejä ja kirjoittaa koodia, joka viittaa tiimin oikeisiin komponentteihin. Siksi olen alkanut siirtyä kohti design engineerin roolia.

Siirtymä ei ole minulle täysin uusi suunta, vaan paluu sinne, mistä aloitin.

Aloitin koodauksesta, mutta jatkoin muotoilijana

Ensimmäiset projektini olivat fanisivuja lempibändeilleni ja videopeleille. Tein niitä 2000-luvulla, kun omien sivujen tekeminen oli trendikästä ja melko helppoa. Lukion toisena vuonna ystäväni pyysi minut mukaan startupiinsa, koska hän oli nähnyt, mitä olin tietokoneella tehnyt. Hän antoi minulle Adoben ohjelmat käyttöön ja oikeita tehtäviä, ja omat projektini muuttuivat kunnianhimoisemmiksi. Jonkin aikaa pidin myös YouTube-kanavaa ja harkitsin videoeditointia ammatikseni.

Valitsin kuitenkin ohjelmoinnin ja opiskelin web- ja mobiilipalveluiden kehittäjäksi Vaasan ammattikorkeakoulussa. Opin siellä, miten koodi saadaan tuotantoon ja miten kehitystiimit toimivat. Harjoittelun aikana innostuin UX:stä niin paljon, että en kirjoittanut koodia seuraavaan yhdeksään vuoteen.

Nuo vuodet UX-konsulttina eivät silti olleet aikaa poissa kehitystyöstä. Työskentelin kehittäjien kanssa päivittäin design systemien, monimutkaisten asiantuntijatyökalujen ja suurten julkisen sektorin palveluiden parissa. Koodia en vain kirjoittanut itse.

Nyt se on taas realistista, mutta ei niin yksinkertaista kuin voisi luulla. Claude Codea ei voi vain pyytää tekemään verkkosivustoa. Työn taustalla pitää olla toimiva järjestelmä, ja jokaisella tiimillä on jo omat tapansa tehdä asioita. Halusin siksi ymmärtää tarkemmin, mitä design engineerin rooli oikeasti vaatii.

Mikä design engineer on?

Selkein vastaus, jonka löysin, on Peter Bokorilta. Hän on Modeinspectin Founding Design Engineer ja on kirjoittanut kymmenen luvun oppaan design engineeriksi ryhtymisestä. Hänen määritelmänsä mukaan design engineer on tuotesuunnittelija, joka työskentelee tuotteen oikeassa koodipohjassa. Hän ei luovuta kuvia toteutettavaksi, vaan toimittaa työnsä pull requestina eli muutosehdotuksena, jonka kehittäjä tarkistaa ennen kuin se yhdistetään tuotteeseen. Bokor tiivistää asian lyhyesti: "Ship the thing rather than describe it."

Nimike voi kuitenkin olla harhaanjohtava. Englannin kielessä design engineer tarkoittaa myös koneensuunnittelun insinööriä, joka suunnittelee fyysisiä osia ja tuotteita CAD-ohjelmilla ja ottaa huomioon esimerkiksi valmistustoleranssit. Suomeksi tämä rooli on yleensä suunnitteluinsinööri. Sillä ei ole mitään tekemistä ohjelmistokehityksen kanssa. Bokorin mukaan juuri tämä mekaaninen rooli täyttää suurimman osan esimerkiksi LinkedInin ja Indeedin hakutuloksista, jos nimikettä hakee sellaisenaan. Tässä kirjoituksessa puhun ohjelmistopuolen roolista.

Määritelmässä on kaksi asiaa, jotka ovat suunnittelijan näkökulmasta tärkeitä. Ensinnäkin muotoilija tekee edelleen suunnittelupäätökset, ja tekoälyagentti kirjoittaa suurimman osan koodista. Toiseksi koodikatselmointi (code review) pysyy ennallaan: kehittäjä päättää edelleen, mitä tuotteeseen päätyy. Kyse ei siis ole kehittäjien ohittamisesta vaan uudesta tavasta tehdä työtä yhdessä.

Moni tekee tätä työtä jo, vaikka ei käytä nimikettä. Bokor viittaa Designer Fundin ja Foundation Capitalin AI in Design Report 2026 -raporttiin, jonka mukaan puolet kyselyyn vastanneista suunnittelijoista oli vienyt tekoälyllä tuotettua koodia tuotantoon. Silti vain joka viides kutsui itseään design engineeriksi.

Suunnitelmasta toteutukseen: kaksi vaihetta

Miksi rooli sitten on syntynyt juuri nyt? Modeinspectin artikkeli uusista suunnittelun tikapuista kuvaa perinteisen luovutuksen (design handoff) kahtena vaiheena. Ensin muotoilijan ajatus piirretään auki suunnittelutyökalussa. Sitten piirrokset toteutetaan koodiksi. Kumpikin vaihe vie aikaa, koska samaa asiaa tehdään kahdessa työkalussa, joilla on eri rajoitteet.

Olen omissa projekteissani pyrkinyt tuomaan nämä kaksi vaihetta lähemmäs toisiaan:

• Yhteinen työkalu. Teollisuuden datatyökalussa siirsin komponenttikirjaston Sketchistä Figmaan, jotta muotoilijat ja kehittäjät työskentelivät samassa ympäristössä.
• Yhteinen ymmärrys. Koulutuksen digitaalisessa palvelualustassa pidimme kehittäjien kanssa säännöllisiä tapaamisia, joissa kävimme läpi ratkaisujen taustoja ja kuulimme kehittäjien ideoita.
• Yhteiset komponentit. Yliopiston projektissa tein design systemin komponenteista helpommin löydettäviä ja otin design system -tiimin mukaan aina, kun tarvittiin aidosti jotain uutta.

Design engineering vie samaa ajatusta pidemmälle. Kun muotoilija työskentelee koodipohjassa, suunnitelma ja toteutus ovat sama asia. Artikkeli kuvaa tätä niin, että suunnittelijat ovat "getting their material back". Vähän samalla tavalla, kuin miten teolliset muotoilijat työskentelevät itse materiaalin kanssa, josta tuote lopulta valmistetaan.

Viisi taitoa, jotka ovat koodausta tärkeämpiä

Jos muotoilija ei kirjoita koodia itse, mitä hänen sitten pitää osata? Tärkein taito ei ole koodaus, vaan koodipohjan tunteminen niin hyvin, että osaa ohjata tekoälyagenttia tarkasti. Bokor kuvaa viisi tapaa, jotka avaan tässä omin sanoin.

1. Viittaa komponentteihin niiden oikeilla nimillä. Koodissa jokaisella komponentilla on nimi, esimerkiksi Button, Card tai TextField. Jos pyydät agenttia "tekemään tästä mockupin näköisen", se joutuu arvaamaan, ja joskus se voi alkaa rakentamaan kokonaan uutta painiketta. Kun pyydät sen sijaan "käytä lomakkeen lähetyspainikkeena Button-komponenttia ja kenttien välissä spacing-md-tokenia", agentti käyttää sitä, mitä tiimillä jo on.
2. Tiedä, missä tiedostot sijaitsevat. Koodipohjaa ei tarvitse osata kirjoittaa uudelleen. Pitää kuitenkin tietää, missä kansiossa komponentit ovat, mitä niiden nimet ovat ja mitkä niistä kuuluvat varsinaiseen design systemiin. Vasta silloin komponenttiin voi viitata nimellä.
3. Pilko työ vaiheisiin. Älä pyydä agenttia rakentamaan koko näkymää kerralla, vaan etene pienissä osissa. Jos teet esimerkiksi kirjautumislomaketta, pyydä ensin pelkkä asettelu eli kenttien ja painikkeen paikat. Sen jälkeen pyydä tilat (states), kuten miltä kenttä näyttää aktiivisena, virheellisenä tai pois käytöstä. Seuraavaksi pyydä validointi eli mitä tapahtuu, jos sähköpostiosoite on väärin. Lopuksi pyydä responsiivisuus, eli miltä lomake näyttää puhelimella. Tarkista jokainen vaihe suunnitelmaa vasten. Yksi laaja ja epämääräinen pyyntö tuottaa helposti paljon koodia, joka näyttää valmiilta mutta ei ole sitä.
4. Lue, mitä agentti teki. Logiikkaa ei tarvitse ymmärtää, mutta tyylit kannattaa tarkistaa. Käytettiinkö tokenia vai kovakoodattua väriä? Onko painike oikea painikekomponentti vai painikkeen näköiseksi muotoiltu div? Tekoäly saattaa myös luoda useita lähes samannäköisiä painikkeita, joista yksikään ei ole design systemin oma. Visuaalinen tarkkuus on muotoilijan vastuulla, ja tässä kohdassa se tarkistetaan.
5. Vie muutos katselmointiin. Riittää, että osaa pull requestin työnkulun: luo uusi haara (branch), tee muutos, tallenna se (commit), avaa pull request ja vastaa katselmoijan kommentteihin.

Kaikki viisi taitoa nojaavat samaan asiaan: tiimin oman sanaston tuntemiseen. Vaikeinta design engineerin roolissa ei siis ole koodin lukeminen, vaan eri tiimien toimintatapoihin ja sanastoon pääseminen. Se täytyy opetella uudelleen jokaisessa tiimissä, ja parhaiten sen oppii tekemällä työtä yhdessä kehittäjien kanssa.

Hyvin rakennettu design system tukee työtä

Design engineering toimii parhaiten, kun tiimillä on hyvin rakennettu design system. Silloin agentille on jo valmiina oikeat komponentit, tokenit ja nimet, joihin viitata. Sen ei tarvitse arvata tai keksiä uutta, ja tulos noudattaa tiimin tapaa tehdä asioita.

Design system tukee työtä kahdessa tilanteessa:

• Uusia näkymiä rakennettaessa. Kun komponentit ja tokenit ovat selkeästi nimettyjä ja helposti löydettäviä, uuden näkymän voi koota niistä pienissä vaiheissa. Näkymä on alusta asti yhdenmukainen muun tuotteen kanssa.
• Vanhaa näkymää parannettaessa. Kun näkymää muutetaan toimivammaksi, design system kertoo, mitä on jo olemassa. Muutos voidaan tehdä käyttämällä valmiita komponentteja, ja kehittäjän on helpompi katselmoida pienempi ja tutumpi muutos.

Design system on siis sama sanasto, josta puhuin aiemmin. Mitä selkeämpi se on, sitä helpompi muotoilijan on ohjata agenttia ja sitä vähemmän kehittäjän tarvitsee korjata katselmoinnissa.

Miten muotoilija voi tukea kehittäjiä?

En näe design engineerin roolia niin, että muotoilijan ratkaisut olisivat valmiita ja niitä pitäisi vain noudattaa. Oma periaatteeni on, että asiat suunnitellaan ja mietitään yhdessä. Koodi on minulle uusi tapa osallistua siihen keskusteluun, ei tapa ohittaa sitä.

Käytännössä tarkoitan neljää asiaa:

• Komponentin ensimmäinen versio. Voin tehdä komponentista ensimmäisen version koodiin. Kehittäjä katsoo sen, ja päätämme yhdessä, miten se sopii kokonaisuuteen.
• Koodilla toimivat prototyypit. Prototyyppi, joka käyttää tiimin oikeita komponentteja ja dataa, vastaa kehittäjien kysymyksiin usein paremmin kuin kuva. Siinä näkyvät esimerkiksi latautuminen, virheet ja tyhjät tilat, joita staattisesta kuvasta on vaikea päätellä.
• Käyttöliittymän osien toteutus. Voin toteuttaa osan käyttöliittymästä itse, esimerkiksi näkymän asettelun, tilat tai visuaaliset korjaukset, ja tarjota sen kehittäjille pull requestina. Kehittäjä katselmoi muutoksen ja päättää, yhdistetäänkö se tuotteeseen. Näin kehittäjillä jää enemmän aikaa logiikkaan, rajapintoihin ja muihin teknisiin kysymyksiin.
• Yhteinen sanasto. Käytän koodin nimiä kaikkialla, missä puhun kehittäjien kanssa: keskusteluissa, tehtävänkuvauksissa ja Figmassa, jos tiimi sitä käyttää. Kun puhun Button-komponentista enkä "oranssista painikkeesta", kehittäjän ei tarvitse arvata, mitä tarkoitan.

Missä olen nyt

Modeinspectin tikapuumallissa on kolme porrasta. Ensimmäisellä ovat muotoilijat, jotka työskentelevät Figmassa. Toisella ovat ne, jotka tekevät tekoälyllä prototyyppejä, jotka kehittäjät rakentavat myöhemmin uudelleen. Kolmannella ovat design engineerit, joiden pull requestit yhdistetään tuotteeseen. Modeinspectin haastattelemilla suunnittelijoilla ensimmäinen hyväksytty pull request syntyi 2–8 viikossa siitä, kun he saivat pääsyn koodipohjaan. Työ tehtiin tavallisen suunnittelutyön ohessa.

Asiakastöissä olen tähän asti ollut ensimmäisellä ja toisella portaalla: työskentelen Figmassa ja teen prototyyppejä. Design engineering on se, mihin haluan tähdätä, ja kolmatta porrasta harjoittelen omissa projekteissani. Rakensin esimerkiksi portfolioni Claude Coden kanssa, ja jokainen muutos kulkee oman haaran ja esikatselun kautta. Tämäkin kirjoitus päätyi sivustolle hyväksytyn pull requestin kautta. 😉

Rooli ei silti sovi kaikille muotoilijoille. Mehmet Baytaş, joka teki design engineerin työtä markkinointitiimissä, on varoittanut, että kokeneemmissa rooleissa työ voi olla paljon enemmän ohjelmistokehitystä kuin suunnittelua, erityisesti jos design engineer vastaa myös tuotannosta.

Yhteenveto

Design Engineerin tarkoitus ei ole korvata kehittäjän työtä, vaan rooli mahdollistaa sujuvamman yhteistyön muotoilun ja kehitystyön välillä.

Jos olet muotoilija ja mietit samaa siirtymää, aloita pienestä. Avaa tiimisi koodipohja ja etsi komponentti, jonka olet piirtänyt monta kertaa. Opettele sen oikea nimi ja katso, mitä vaihtoehtoja sillä on. Esimerkiksi:

• Painike voi olla koodissa Button, jolla on vaihtoehdot variant="primary" ja variant="secondary", eikä kaksi erillistä komponenttia.
• Figman "Spacing / Medium" voi olla koodissa token nimeltä spacing-md tai Tailwindin luokka gap-4.
• Modaali voi olla Dialog, ja sen otsikko, sisältö ja painikkeet omia alikomponenttejaan.

Kun tunnet nämä nimet, voit käyttää niitä seuraavassa suunnitelmassasi ja seuraavassa keskustelussa kehittäjän kanssa.

Lähteet

• Peter Bokor: What does a design engineer do? The software role, explained. Modeinspect, 16.9.2026.
• Modeinspect: The New Design Ladder: Why Design Engineers Are the Only Designers Who Ship. 15.9.2026.
• Peter Bokor: Becoming a Design Engineer. Modeinspect, 2026.
• Designer Fund ja Foundation Capital: AI in Design Report 2026, Bokorin mukaan.