Suunnittelutyökalun ongelma

Yksityiskohtainen kuvaus kahdesta vastakkaisesta kertomuksesta, jotka ilmestyvät suunnittelutyökalutilassa.

Kaavio, joka kuvaa kahta vastakkaista narraatiota, jotka ilmestyvät suunnittelutyökalutilassa.

Suunnittelutyötilassa on kaksi vastakkaista narraatiota, jotka ovat kehittyneet vuosien ajan. Nämä kertomukset heijastavat kahta hyvin erilaista ajattelua, kun on tarkoitus ymmärtää työkalujemme erityistä arvoa ja sitä, mihin suuntaan niitä tulisi johtaa.

Ensimmäisessä kertomuksessa myydään ajatus, että suunnittelun esineet voivat olla ja niiden tulisi olla tuotteen ainoa totuuden lähde ™. Tässä kertomuksessa koodi on toissijainen - sen tehtävänä on toistaa muotoilun esineet mahdollisimman tarkasti. Alustan rajoitukset jätetään useimmiten huomiotta nopeuden ja rajattoman luovuuden hyväksi.

Kutsutaan tätä "aukon kurottamiseksi" -kertomukseksi.

Toinen kertomus keskittyy ajatukseen, jonka mukaan jokainen tuotteeseen liittyvä yhteistyö voi ja sen pitäisi olla osallisena samassa tuotteessa. Tässä kertomuksessa koodi on kaikkea - se on tuote. Alustan rajoituksia kunnioitetaan ja ymmärretään. Päätökset tehdään kontekstissa, ja työkalut kattavat niiden tavoiteväliaineet.

Kutsumme tätä ”yhteistyöhön” perustuvaksi narratioksi.

Joten mistä nämä kertomukset tulivat? Kuinka paljon järkeä jokaisella on? Katsotaanpa tarkemmin.

Kertomus # 1: Kuilun kaventaminen

Niin kauan kuin digitaaliset suunnittelijat ovat käyttäneet suunnittelutyökaluja, meillä on aina ollut polttava halu saada ideat toteutumaan tuotannossa. Suunnitteluprosessin omistaminen ideasta käyttöönottoon on aina ollut pyhä graali. Jos tarkastelemme suunnittelutyökaluidemme evoluutioaikataulua, voit nähdä, että tämä halu ilmenee.

Noin vuonna 2005, kun digitaalisen suunnittelijaurani alkoi, useimmat meistä käyttivät joko Illustratoria tai Photoshopia luomaan vektoripohjaisia ​​kuvia kaikista tuotteistamme, joita suunnittelimme. Tämä pysyi status quoina monien vuosien ajan - useimmat suunnittelutehtävät vaativat sujuvuutta Adoben Creative Suite -sovelluksessa.

Eräänä päivänä, vuonna 2010, Sketch saapui ja pudisti puuta. Luonnos oli yksinkertaisempi, halvempi ja paljon keskittyneempi. Tietenkin, suunnittelijat taistelivat siitä aluksi, mutta lopulta löysivät sen puhtaan käyttöliittymän ja hienostuneen ominaisuusjoukon virkistäväksi.

Sitten viime aikoina Figma saapui. Figma laajensi Sketchin aloittamaa vallankumousta. Ominaisuusjoukko on hyvin samankaltainen, mutta toteutuksen suhteen en usko, että se on lähellä. Lähes kaikki ominaisuudet on toteutettu yllättävän hyvin. Shockingly well, jopa.

Prototyyppityökalut lisäsivät ylimääräisen realistisen tason - ottamalla staattiset kuvat suunnittelutyökalumme vietyihin ja ompelemalla ne yhteen, simuloimalla kosketustapahtumia ja näytön siirtymiä.

Mutta suunnittelu- ja kehitystyön työnkulkujen välillä oli silti havaittavissa oleva aukko. Kuinka voimme ottaa seuraavan askeleen?

Kiistanalainen “Kehittäjän vaihto”, tietenkin. InVision ja Abstract julkaisivat ”Tarkasta”. Avocode, Marvel ja Zeplin julkaisivat ”Vaihdon”. Figma ja Sketch yrittivät viedä CSS: ää. Ideana oli, että kun suunnittelijoilla oli jotain jakamisen arvoista, he voisivat luovuttaa työnsa kehittäjille muodossa, jonka kehittäjät ymmärsivät.

Viimeisin lovi tällä aikajanalla on ollut uudenlainen työkalu, joka lupaa muuttaa staattiset kuvat tuotekoodiksi. Supernova Studio, Rapid UI, PageDraw, Teleport, Sketch2React ja Anima Launchpad ovat vain kourallinen aloittelijoista, jotka johtavat tätä maksua.

Ensi silmäyksellä et ehkä huomaa mitään epätavallista tässä aikajanassa. Työkalumme ovat juuri parantuneet räjähdysmäisesti, kuten voidaan odottaa. Niistä tulee entistä suorituskykyisempiä, vankempia ja monipuolisia. Jos rajaat näkymäsi viimeiseen 10 vuoteen, tämä kaikki näyttää luonnolliselta etenemiseltä.

Mutta palaa vain vähän pidemmälle ja huomaat jotain hyvin omituista.

Palataan hetkeksi takaisin tilanteeseen, jolloin painatus oli markkinointiviestinnän ensisijainen muoto. Se oli yksinkertaisempi aika. Loputtomia keskusteluja työkaluista tai kehyksistä pidettiin minimissä. Joskus jotkut nousut mainitsivat QuarkXPressin, mutta kapina ei koskaan kestänyt kauan. Useimmat suunnittelualan ammattilaiset käyttivät Illustratoria, Photoshopia ja InDesignia. Adobe hallitsi juurikaan ja se oli se.

Erityisesti suunnittelijat suunnittelivat lopputuotetta, ei sen jäljitelmiä - lopputuotteena olivat paperitavarat, julisteet, kirjat, tuotemerkki-identiteetit, esitteet ja muu painotuotanto. Suunnittelijoilla oli suora vaikutus tuotteisiin, joita he suunnittelivat.

Tämä oli mahdollista, koska painosuunnittelijoilla oli (ja vielä on) hyvä hallita suunnittelumateriaalia. Tulo- ja lähtörajoitusten välillä oli läheinen korrelaatio.

Esimerkiksi painosuunnittelijat tiesivät, että väreissä voi olla pieniä eroja siinä, kuinka värit voidaan tuottaa paksulle kartongille, kun taas kevyemmällä, 120 g / m kirjelomakkeella. Suunnittelijat olivat vastuussa 3 mm: n poisto- ja leikkausmerkkien lisäämisestä tulostimen kohdistuksen epätarkkuuksien huomioon ottamiseksi. Suunnittelijat olivat tietoisia läpimenoajoista - he tiesivät, että hienojen vaikutusten, kuten jäljennöksen poistaminen tai kuuma foliointi, tuottaminen on kalliimpaa.

Varsinkin kun digitaalisen painetun vallankumouksen saapuminen saapui, monet suunnittelijat alkoivat investoida aikaa ja rahaa oppiakseen niin paljon kuin mahdollista tulostusmateriaalista. Tulostuksen suunnitteluohjelmisto omaksui välineen ja palveli sitä.

Sitten jossain vaiheessa web-suunnittelusta tuli pääpaino ja miljoonista painosuunnittelijoista tuli web-suunnittelijoita yön yli.

En lyö tätä painopisteen muutosta. Itse muutin tulostamisesta digitaaliseen. Monet graafisen suunnittelijan opinnoista ovat siirrettävissä muille toimialoille, ja rakastan nähdä ihmisten laajentavan näköaltaan.

Kysymys oli siitä, että meillä oli nyt hyvin vähän tietoa uudesta välineestä, jota suunnitimme. Sen sijaan, että viettäisimme aikaa ymmärtää tätä uutta tietovälinettä, yritimme kesyttää sitä. Tämä tuli ilmeiseksi, kun yritimme sovittaa kaiken 960px-säilöön, jota kutsuttiin rajapinnoiksi ”sivuiksi” ja kokonaistermejä, kuten ”esiteverkkosivusto”.

Useimmat suunnittelijat eivät osaa kirjoittaa koodia, joten teimme mitä pystyimme: piirtimme kuvia. Tätä varten käytimme asiaa, joka oli palvellut meitä jo vuosikymmeniä aikaisemmin: graafisen suunnittelun ohjelmistoa.

Suunnittelijat eivät enää suunnitelleet lopputuotetta, vaan sen jäljitelmiä.

Tätä paradigmamuutosta ei ollut osoitettu pitkään aikaan, koska kuvapohjainen suunnittelu oli silti hyvin tärkeä osa verkkosuunnittelua. Monet teistä muistavat mielellään valtavien sprite-arkkien luomisen hakkerointiin kuten kaltevuudet ja pyöristetyt kulmat. Kääntöpainikkeet, kukaan?

Siirry kuitenkin nopeasti eteenpäin tänään, ja CSS on täysin syrjäyttänyt kuvapohjaiset hakkerit. Jopa rasterikuvien käyttö viestinnän muodossa on parantumassa suorittavien ja / tai syventävämpien kohteiden, kuten CSS-animaatioiden, SVG-kuvien ja videon, hyväksi.

Nykyään verkon ja tulosteen välinen korrelaatio on suunnilleen yhtä lähellä kuin verkon ja arkkitehtuurin välinen korrelaatio.

Valitettavasti työkalumme eivät ole sopeutuneet tarpeeksi nopeasti. Nykyinen digitaalisen suunnittelun työkalumme on suurelta osin tulostussuunnittelutyökalujen jatko-osa. Nuoret suunnittelijat oppivat innostuneesti digitaalista suunnittelua staattisten piirtotyökalujen linssin kautta.

Toki, joitain vaikuttavia parannuksia on tapahtunut, mutta suurin osa niistä on silti vain vektoripohjaisia ​​piirtotyökaluja, jotka on optimoitu havainnollistamiseksi. Tästä syystä työkaluistamme puuttuu kontekstit ja vivahteet, jotka ovat tarpeen tietoisten suunnittelupäätösten tekemiseksi.

Narrative # 2: Yhteistyö

Sen sijaan, että rohkaistaan ​​lopputuotteen jäljitelmien piirtämistä, tämä kertomus puoltaa koodin ottamista ja helpottamista sulamista, jotta kokonaiset joukkueet voivat tehdä yhteistyötä sen suhteen.

Kummallista, että molempien kertomusten alkuperä voidaan jäljittää suunnilleen samaan aikaan. Adobe Dreamweaver, pahamaineinen WYSIWYG-visuaalikoodieditori, saapui näyttämölle vuonna 1997. Softpress Freeway saapui vuotta aikaisemmin vuonna 1996 ja Microsoft Frontpage vielä aikaisemmin vuonna 1995, vain viisi vuotta Photoshopin jälkeen ja yli vuosikymmen ennen Sketchiä.

Valitettavasti nämä työkalut olivat usein enemmän haittaa kuin apua. Ne optimoitiin vientiin tuotantoon, mikä teki niistä liian hankalia suunnitteluprosessille.

Vähitellen suunnittelijoiden aalto, mukaan lukien minä, ohjasi WYSIWYG-toimittajat vähemmän rajoittavaan suunnittelutyökaluun: tekstieditoriin.

Koodin kirjoittaminen oli pitkään aika melko vaaleaa. Mutta ajan myötä terveellinen työkalujen ekosysteemi alkoi itää koodin ympärille, vähentäen merkittävästi pääsyn esteitä. Nykyään meillä on koodipohjaiset suunnittelutyökalut, jotka eivät vaadi mitään koodaustietoa.

Katsotaanpa tarkemmin koodipohjaisten suunnittelutyökalujen kehitystä tähän mennessä.

Koodin muotoilu ja syntaksin korostaminen olivat ensimmäisiä “työkaluja”, jotka keskittyivät koodin sulavaksi tekemiseen. Värien ja rakenteen käyttäminen paransi luettavuutta ja skannautuvuutta. Viime aikoina Prettierin kaltaiset työkalut ovat automatisoineet tämän.

Esikäsittelyprosessorit ja mallikielet saapuivat vuoden 2006 ympäri. Työkalut, kuten Haml, Sass, LESS, CoffeeScript ja muut, paransivat koodin hallittavuutta entisestään kannustamalla lyhyisyyttä, poistamalla osa visuaalisesta monimutkaisuudesta ja automatisoimalla joitain yleisimpiä tehtäviä.

JSX on Facebookin kehittämä JavaScript-syntaksilaajennus, joka ei eroa liian paljon sen edeltäneistä mallikieleistä. Reaktin komponenttiliittymä auttaa myös edistämään uudelleenkäyttöä ja abstraktia visuaalista monimutkaisuutta, mikä taas auttaa syytämme tehdä koodista sulavampaa ja helpompaa käyttää.

Viime aikoina näemme, että työkalut poistavat pääsyn esteet, kuten joudutaan määrittämään kehitysympäristöt ja asettamaan komento komentorivillä jne. Compositor ISO ja SEEKin Style Guide Sandbox tekevät täällä hämmästyttävää työtä.

Compositor ISO- ja SEEK Style Guide -hiekkalaatikko, jossa voit prototyyppiä käyttää JSX: tä ilman, että rakennusasetuksia tarvitaan.

Modulz (rakennuksen suunnittelutyökalu) ja UXPin tekevät myös koodista helpompaa saatavuuden poistamalla pääsyn esteet. Nämä työkalut visualisoivat JSX: n, käyttämällä tuttuja kerroksia edustamaan sitä ja graafista käyttöliittymää komponenttien rekrytointiin.

Modulz - koodipohjainen suunnittelutyökalu käyttöliittymän visuaaliseen säveltämiseen.

Polypane rakentaa älykästä suunnitteluympäristöä, jossa voit esikatsella mallisi monilla selaimilla, laitteilla ja näkymäporteilla. Toinen esimerkki työnkulusta, joka ottaa huomioon kohdeväliaineen koko kontekstin.

Polypane - älykäs selain reagoivaan suunnitteluun ja kehittämiseen.

Nämä visuaaliset koodieditorit ovat yksinkertaisesti seuraava askel koodin helpottamisen kirjoittamisen etenemisessä. Kaikki tämä innovaatio on järkevää ja mahdollista, koska valtava osa käyttöliittymäkehityksestä on luonnostaan ​​visuaalista.

Spoilerihälytys: Olen samaa mieltä Jasonin ennusteen kanssa. Selaimen kehittämistyökalut ovat jo alkaneet siirtyä tähän suuntaan, ja tarjoavat graafisia käyttöliittymiä CSS-tyylien, kuten siirtymien, varjojen ja värien, visuaaliseen manipulointiin.

Joukko graafisia käyttöliittymiä koodin visuaaliseen manipulointiin Google Chromen dev-työkaluissa.

Tietysti selaimen dev-työkalut toimivat käännetyllä koodilla, mutta samat visuaaliset työkalut voivat koskea myös esikäännettyä koodia. Compositor Lab ja Modulz Editor helpottavat React-komponenttien muokkaamista visuaalisesti.

Modulz Editor - työkalu React-komponenttien visuaaliseen suunnitteluun.

Xcode on erittäin aliarvioitu työkalu, jonka avulla joukkueet voivat suunnitella, kehittää, testata ja debugtaa tuotteitaan yhdistämällä koodinkäsittely ja suora manipulointi.

Airbnb's Lona on yksi lupaavimmista visuaalisen koodin toimittajista, joita olen nähnyt. Lona Studio tarjoaa graafisen käyttöliittymän komponenttijärjestelmien rakentamiseen, uusien näytöiden mallistamiseen olemassa olevista komponenteista, mallien esikatselusta todellisella datalla, kokeilun useiden näyttökokojen kanssa ja paljon muuta.

Sama eteneminen voidaan havaita myös muilla toimialoilla, kuten pelisuunnittelussa, musiikin tuotannossa, arkkitehtuurissa, videon editoinnissa jne. Maya, Unity, Cubase, Logic Pro ja Final Cut tarjoavat työkaluja suoraan manipulointiin, jotta kokonaiset joukkueet voivat tehdä yhteistyötä sama tuote.

Vaikka jokainen näistä työkaluista toimii erilaisella abstraktion tasolla, niillä kaikilla on sama tavoite: tehdä koodista sulavampaa, hallittavissa olevaa, visuaalista ja helpommin saatavana laajemmalle yleisölle.

Vaikka nämä työkalut saattavat näyttää hyvin erilaisilta, taustalla oleva käsite pysyy vakiona. Perinteisen paradigman muutosta ei ole. Työtä ei ole päällekkäistä. Ei hukkaan ponnisteluja. Ei ole vääriä simulaatioita tai epätarkkoja renderöintejä. Asiayhteydestä ei ole puutetta. Siinä on vain koodi monissa muodoissa.

Jatkamalla tätä kerrontaa voimme altistaa käyttöliittymäsuunnittelijat suunnittelemiemme välineiden todellisuudelle piilottamalla kaiken merkityksettömän monimutkaisuuden, jolloin pystymme tekemään tietoon perustuvia suunnittelupäätöksiä.

Dilemma

Muotoilutiimit, yritykset ja sijoittajat ovat investoineet valtavia määriä aikaa ja rahaa rikkoutuneen suunnitteluprosessin tukemiseen: perinteiseen kuvapohjaiseen työnkulkuun.

Tähän järkyttävään pohjaan on rakennettu koko ala: työkalut kuvien piirtämiseen, työkalut vuorovaikutuksen lisäämiseen kuviin, työkalut versiokuviin, työkalut kuvien tallentamiseen, työkalut tietojen poimimiseen kuvista. Jokainen heistä yrittää saada nämä staattiset jäljitelmät näyttämään enemmän todelliselta tuotteelta - ikään kuin kerrostamalla simulaatioita simulaatioiden päälle voisimme jollakin tavalla silittää mahdotonta etäisyyttä vektorigrafiikan ja interaktiivisen ohjelmiston välillä.

Nykyään digitaaliset tuotteemme kattavat yhä monimutkaisempia tekniikoita: mikrovuorovaikutukset, animaatiot, AR, VR, äänitulot, äänilähtö, video, useita pikselitiheyksiä, rajattomat näyttökentän mitat, kirkkauden havaitseminen jne. Suunnittelijoiden tutkiessa näitä uusia alueilla, vektoripohjaiset piirtotyökalut paljastetaan edelleen niiden puutteiden vuoksi.

Mieti, miten suunnittelumaisema voi muuttua seuraavan viiden vuoden aikana. Kuinka kukin näistä narraatioista soi? Jotta saadaan tarkka käsitys, mielestäni on parasta palata takaisin perusteisiin ja kysyä itseltämme vaikeita kysymyksiä.

Mitä tarkoittaa digitaalisten tuotteiden suunnittelu tänään? Mitkä suunnittelun näkökohdat pitäisi suunnittelutyökalun nopeuttaa, automatisoida tai yksinkertaistaa?

Muistan edelleen, kuinka yksi kaikkien aikojen suosikkisuunnittelijoistani Rebekah Cox määritteli, mitä tuotesuunnittelu tarkoitti Quoralla varhaisina aikoina.

”Käyttöliittymä on suunnittelun tuote. Suunnittelu on joukko päätöksiä tietystä tuotteesta. ”- Rebekah Cox

On kulunut melkein vuosikymmen sitten, kun luin ensimmäisen muotoilumääritelmän, mutta se pysyi kanssani kaikki ne vuodet. Se oli ensimmäinen kerta, kun ymmärsin, että käyttöliittymä on seurausta suunnittelusta, ei itse suunnittelusta. Suunnittelu on joukko päätöksiä, jotka johtivat tuotteeseen.

Joten jos muotoilu on joukko päätöksiä, mitkä päätökset menevät tämän päivän digitaalisten tuotteiden suunnitteluun? Tässä on pieni näyte pääni yläosasta:

  • Kuinka painikkeen tulisi toimia, kun se käännetään, painetaan, tarkennetaan tai poistetaan käytöstä?
  • Kuinka tämän käyttöliittymän tulisi toimia, kun sen asuttamiseksi ei ole tietoja?
  • Kuinka tämä käyttöliittymä selviää, kun täynnä poikkeuksellisen pitkiä tietojonoja?
  • Missä järjestyksessä elementtien tulisi keskittyä, kun välilehtiä tehdään?
  • Pitäisikö mitään pikanäppäimiä olla käytettävissä vuorovaikutuksessa tämän käyttöliittymän kanssa?
  • Pitäisikö mitään äänikomentoja olla käytettävissä vuorovaikutuksessa tämän käyttöliittymän kanssa?
  • Pitäisikö mitään ääniä toistaa, kun käytät tätä käyttöliittymää?
  • Kuinka tämä väri tai fontti näyttää kaikissa selainten, selainversioiden ja käyttöjärjestelmien yleisimmissä permutaatioissa?
  • Kuinka pieni painoskomponentin muutos vaikuttaa tuotteen muihin alueisiin?
  • Kuinka x-komponentin tulisi toimia, kun sen tietoja ei ole vielä ladattu?
  • Kuinka x-komponentin tulisi toimia sen tietojen latautuessa?
  • Kuinka tämän asettelun tulisi mukautua verkon äärettömään joukkoon mahdollisia näkymiä, sivusuhteita ja pikselitiheyttä?

Tällaisia ​​päätöksiä digitaaliset tuotesuunnittelijat tekevät päivittäin. Paitsi, että meidän on tehtävä nämä päätökset, meidän on myös testattava niitä, valvottava niitä, ilmoitettava niistä ja myytävä.

Mutta tällaisia ​​vivahteja sisältäviä tuotepäätöksiä ei voida vangita vektorikokoelmaan edes päällekkäin olevien vuorovaikutusten kanssa.

Aiemmin viittasin ”kehittäjän vaihtoon” kiistanalaiseksi. Minulla oli seuraava: voimakkaasti edistetyllä työnkululla, joka liittyy siirtymiseen staattisista muodoista koodiksi, ei ole mitään järkeä ottaen huomioon kahden median väliset valtavat erot.

"Kehittäjän vaihdon" ongelma ei ole nimessä. Myöskään toteutus ei ole ongelma. Jopa käsitys suunnittelijoista, jotka siirtävät työnsä tuotantolinjaa pitkin, on käsitteellisesti hyvä.

Ongelmana on, että ”vaihtoon” ei ole mitään hyödyllistä. Tietojen saaminen vektoreista ei ole vaikeaa. Rehellisesti, suurin osa siitä on joka tapauksessa hyödytön. Se saa tarvittavat tiedot haasteeseen. Tästä syystä vektoripohjaiset piirtotyökalut eivät sovellu hyvin käyttöliittymäsuunnitteluun. Vektorigrafiikka ei fyysisesti kykene hallussaan sellaista tietoa, jota tarvitaan digitaalisen tuotteen suunnittelulle riittävien tietojen saamiseksi.

Mutta vaikka voisimme jotenkin pakata nämä päätökset vektorigrafiikkaan, havainnollistamistyökalut eivät tarjoa ympäristöä, jolla voidaan tehdä digitaalista tuotetta koskevia keskeisiä päätöksiä. Et voi tehdä tietoisia tuotesuunnittelupäätöksiä ympäristössä, jossa ei ole mitään suunnitellun välineen kontekstia.

Nämä ovat päätöksiä, jotka tekevät tai rikkovat digitaalisia tuotteita. Jos haluat tehdä nämä päätökset, sinun on perehdyttävä moniin ympäristöihin, joissa tuotteesi on olemassa.

”Tuotantokoodi on korvaava päätöksentekovallassa. Tuotantokoodi on totuuden lähde. Se on kaikkien keskustelujen, kaikkien päätösten, kaiken politiikan reaaliaikainen summa ... se on kaikki. Kuka ajaa koodia tuotantoon, se johtaa tuotetta. Kaikilla muilla on vain vaikutusvaltaa. ”- Rebekah Cox

Rebekah ehdottaa, että ihmiset, joilla on eniten päätöksentekovoimaa, ovat lähinnä koodia.

Jos suunnittelutyökalujemme tarkoituksena on tarjota meille samantasoinen tuotevaikutus, kuin kehittäjät ovat nauttinut yksinomaan vuosikymmenien ajan, heidän on siirryttävä eteenpäin menneiden hajotettujen työnkulkujen edestä ja jatkettava tulevaisuuden interaktiivisten välineiden omaksumista.

Jos olet kiinnostunut Modulzista, uudesta suunnittelutyökalusta, jonka parissa työskentelen, postitamme säännöllisesti päivityksiä Twitteriin. Jos haluat keskustella työkaluista tai järjestelmistä, ota rohkeasti yhteyttä minuun sähköpostitse tai Twitterissä.

Huuto Dave Feldmanille, Adam Morselle, Scott Raymondille, Patrick Smithille, Michael Lelle, Kilian Valkhofille, David Tuitelle ja muille avustamisesta editoinnissa.