Sisältö
- Mikä on suunnittelun ja kehityksen ero?
- Ongelmat
- 01. Suunnittelijat, jotka luovat mahdottomia malleja
- 02. Aikaa vievä dokumentaatio
- 03. Pitkät palautesyklit
- Kuinka kuroa umpeen
- 01. Kommunikoi aikaisin, usein, aina
- 02. Ole ketterä
- 03. Puhu toistensa kieltä
Jos olet koskaan joutunut keskusteluun suurimmista ongelmista, jotka vaivaavat verkko- ja digitaalituotekehitystä tänään, olet todennäköisesti kuullut jonkun viittaavan suunnittelun ja kehityksen aukkoon. Tämän maininnassa useat päät todennäköisesti nyökkäsivät notkeasti, ja sitten te kaikki jatkoitte, tyydytte tarkkailemaan ongelmaa välttämättä ratkaisematta sitä. Loppujen lopuksi siihen on todennäköisesti työkalu, eikö? Ehkä emme ole vain löytäneet sitä vielä?
Todellisuudessa suunnittelu- ja kehityskuilun poistamiseksi on olemassa useita työkaluja. Ja kuten useimpien ongelmien kohdalla, on olemassa lukuisia muita mahdollisia ratkaisuja. Puhun monista niistä täällä, mutta ennen kuin ratkaisemme ongelman, varmista, että ymmärrämme sen, eikö niin?
Mikä on suunnittelun ja kehityksen ero?
Yksinkertaisesti sanottuna 'suunnittelun ja kehityksen aukko' viittaa siihen, mitä suunnittelijoiden ja kehittäjien välisessä viestinnässä puuttuu tuotekehitysprosessin aikana. Ongelma osoittautuu kaikkein pelottavimmaksi yrityksissä, joissa vesiputousprosessit hallitsevat, kun suunnittelija yksinkertaisesti 'heittää suunnitelman seinän yli', pölyttää kädet ja sanoo: "No, olen tehnyt sen!"
Kuten kukaan kasvissyöjä, joka on yrittänyt tilata burrito sin carne -yrityksen, voi todistaa, että jaetun kielen puute voi johtaa suuriin ongelmiin
Tällaisessa tilanteessa aukko jättää kehittäjien tulkitsemaan suunnittelijan aikomuksen yksin. Tämä jättää runsaasti tilaa tuotemerkkien ulkopuolisille animaatioille, linkeille, jotka menevät sinne, missä niiden ei pitäisi olla, ja pyöristetyille kulmille, jotka ovat vain pikseliä tai 50 merkin päässä. Ei isoäiti, eikö? Toki - niin kauan kuin et ole henkilö, joka huolehtii alimmasta rivistä, hymyillen projektin tunteja nopeasti hiipuvassa toivossa, että jos katsot niitä hauskiksi, nämä luvut sopivat projektibudjettiin.
Suunnittelun ja kehityksen välinen kuilu ei tietenkään vaivaa vain vesiputouksia. Loppujen lopuksi suunnittelijoiden ja kehittäjien puhuvat eri kieliä - kokemuksen ja jatkuvan, keskinäisen ponnistelun puuttuessa. Ja kuten kukaan kasvissyöjä, joka on yrittänyt tilata burrito sin carne -yrityksen, voi todistaa, että jaetun kielen puute voi johtaa suuriin ongelmiin.
Ongelmat
Tietysti käytettävissä olevan kääntäjän puutteesta johtuvat ongelmat eivät ole ainoita asioita, jotka tekevät suunnittelun ja kehityksen välisestä kuilusta ongelmallista. Tarkemmin sanottuna jotkut yleisemmistä asioista, joihin joukkueet törmäävät, sisältävät seuraavat.
01. Suunnittelijat, jotka luovat mahdottomia malleja
Jokainen, joka on sekoittanut hieman CSS: ää, tietää, että se ei voi tehdä kaikkea. Mutta suunnittelijat, jotka eivät tunne CSS: n vivahteita ja haluavat viedä luovia rajojaan, voivat helposti luoda Sketch- tai Photoshop-malleja, joita ei voida tuoda verkkoon (helposti tai ollenkaan).
Tässä kysymyksessä suunnittelun ja kehityksen välisen kuilun poistaminen tarkoittaa, että suunnittelijat ymmärtävät CSS: n kyvyt tarpeeksi välttääkseen mahdottomien ratkaisujen suunnittelun.
02. Aikaa vievä dokumentaatio
Yksi yleisimmistä työkaluista, joita käytetään suunnittelun ja kehityksen välisen kuilun poistamiseen, on dokumentointi: viivat, spesifikaatiot, komponenttikaaviot ja niin edelleen. Riippumatta siitä, mitä tiimisi heille kutsuu, ne kaikki merkitsevät dokumentaatiota, ja ne tarkoittavat, että huomattava määrä aikaa kuluu työskentelyyn sellaisen kanssa, jota loppukäyttäjä ei koskaan koskaan kokea suoraan. Tämä ei tietenkään tarkoita sitä, että heillä ei ole arvoja - useimmat digitaaliset tuotteet voivat hyötyä suunnittelu-, kieli- ja kehitysdokumentaatiosta.
Mutta niiden arvon ulkopuolelle jäävien kysymysten, viivojen ja muunlaisten asiakirjojen luominen kestää kauan, eivätkä ole erityisen hauskoja kenellekään. Tässä kysymyksessä suunnittelun ja kehityksen välisen aukon poistaminen tarkoittaa nopeamman ja helpomman tavan etsiä teknisiä tietoja.
03. Pitkät palautesyklit
Palaute on väistämätöntä, vaikka suunnittelijat luovat CSS: ää ajatellen ja laativat yksityiskohtaisen dokumentaation. Ja se on aina arvokasta. Mutta siitä voi tulla resurssien kuluminen ja vaikuttaa merkittävästi työntekijöiden moraaliin, kun silmukat jatkuvat liian kauan. Ristiriitainen palaute yhdestä syklistä seuraavalle kasvaa, sidosryhmät mutavat vettä ihmisten välisillä erimielisyyksillä, ja kaikki unohtavat kattavan strategian.
Tässä kysymyksessä suunnittelun ja kehityksen välisen aukon poistaminen tarkoittaa tapojen löytämistä tarpeettomien palautesilmukoiden leikkaamiseksi.
Kuinka kuroa umpeen
Nyt ymmärrämme suunnittelun ja kehityksen aukon luonteen ja ongelmat, joita se voi tuoda prosessiin, puhutaan ongelman ratkaisemisesta. Siellä on ohjelmisto, joka on suunniteltu auttamaan - ja tätä varten tutustu luetteloon 5 työkalusta suunnittelu- ja kehityskuilun poistamiseksi. Mutta on myös joitain ns. Pehmeitä taitoja, jotka voivat auttaa. Koska hei, emme voi odottaa sovellusten ratkaisevan kaikki ongelmamme, eikö?
Vaikka moderni työpaikka luottaa digitaalisiin työkaluihin useimpien ongelmien ratkaisemiseksi, hyvät ihmissuhdetaidot eivät usein korvaa - varsinkin kun ydinongelma on lähinnä viestintä. Ottaen tämän huomioon tarkastellaan kolmea täysin ilmaista tapaa kaventaa suunnittelu- ja kehitystiimien välinen kuilu.
01. Kommunikoi aikaisin, usein, aina
Projektin parissa työskentelevien suunnittelijoiden ja kehittäjien tulisi aina työskennellä yhdessä. Ja se tarkoittaa paljon enemmän kuin kommentoida samoja GitHub-lippuja tai työskennellä jaetuista Sketch-tiedostoista.
Kysy, kuinka kehitystiimi haluaisi sinun välittävän malleja
Se tarkoittaa, ja vielä tärkeämpää, puhumista. Joten, suunnittelijat: keskustele suunnittelijasi kanssa siitä, miten selviydyt nykyisistä haasteistasi. Varmista, että ratkaisusi on toteutettavissa teknisestä näkökulmasta. Pyydä heitä katsomaan mallejasi ja kutsumaan alueita, joilla visuaalisia elementtejä ei voida toistaa. Kysy, rikkooko todellisten tietojen virta muotoilua. Ota selvää, mikä on paras tapa nimetä suunnittelukerroksesi - ihmisiltä, joiden on työskenneltävä niiden kanssa.
Mutta mikä tärkeintä: Kysy, kuinka kehitystiimi haluaisi sinun viestittävän suunnitelmista, vuorovaikutuksesta ja niin edelleen. Kun ymmärrät heidän haluamansa muodot teknisten tietojen ja muutosten välittämiseksi, viestit heti tehokkaammin.
02. Ole ketterä
En ole prosessipoliisi, joten en kerro sinulle, että sinun on työskenneltävä ketterästi tai että sinun on käytettävä GV: n sprintimuotoa. Mutta mielestäni siellä on yksi osa ketterää metodologiaa, jonka jokainen joukkue voi lainata. Nimittäin sen painopiste rajat ylittävissä tiimeissä - mukaan lukien ihmiset, joilla on erilaisia erikoisuuksia.
Tämä varmistaa säännöllisen ja johdonmukaisen yhteistyön suunnittelun ja kehityksen välillä, nippaamalla mahdollisia ongelmia alkuunsa. Suosittelen myös henkilökohtaisesti, että otat ystävällisen paikallisen sisältöstrategin tai copywriterin mukaan toiminnalliseen joukkueeseesi alusta alkaen, mutta se on toinen tarina toiseen viestiin.
03. Puhu toistensa kieltä
Kun suunnittelijoiden tulisi koodata -filosofian kannattajat puhuvat, yksi heidän ydinperusteistaan on yleensä se, että se auttaa heitä ymmärtämään paremmin, mitä heidän dev-kollegansa tekevät, samoin kuin mikä on mahdollista verkossa. Olen siitä täysin samaa mieltä! Haluan kuitenkin huomauttaa, että sinun ei tarvitse pystyä kirjoittamaan koodia ymmärtämään, mikä koodilla on mahdollista. Sama koskee suunnittelua.
Esimerkiksi, en itse ole kovin visuaalinen suunnittelija - mutta kulutan ahneasti kaikkea, mitä voin oppia siitä. Ja se on saanut minut pisteeseen, jossa voin puhua suunnitteluperiaatteista ja parhaista käytännöistä suunnittelukollegojeni kanssa ja tuntea, jos ei sujuvasti, mutta ainakin keskustelijana. Olen myös työskennellyt digitaalisen muotoilun maailmassa riittävän kauan, jotta voin yleensä mitata, mitä kehittäjä voisi tehdä käyttöliittymän kanssa, ja antaa suosituksia siitä, mikä olisi parasta käyttökokemuksen kannalta.
Ei myöskään harjoittelu kooderina ei estä sinua tekemästä yksi tyhmä-yksinkertainen temppuni toteutettavuuden arvioimiseksi: kysyä joku. On hullua, kuinka pitkälle yksinkertainen kysymys vie sinut.
