Kuolema prosessikoneille!

Löydä ihanteellinen suunnitteluprosessisi pitämällä kiinni muutamasta yksinkertaisesta periaatteesta jäykän käsikirjoituksen sijasta.

Kuulet paljon erilaisia ​​neuvoja siitä, kuinka oikea ja väärä tapa on suunnitella sovellus tai verkkosivusto.

"Sinun pitäisi käyttää Sketchiä."
”Suunnittelujärjestelmät tai GTFO.”
"Oikeat suunnittelijat suunnittelevat 100% koodina."
"Lankakehykset ovat ajanhukkaa."
"Jos et tee prototyyppejä, et tee sitä oikein."
"Sinun on aloitettava paperilla."

Luulet, että oikeasta suunnittelutavasta ei ole päästy sopimukseen, mutta on yksi asia, josta on pääosin riitaa - prosessin tulisi olla lineaarinen.

Klassinen lineaarinen lähestymistapa näyttää noin:
tutkimus → luonnos → viirakehys → staattiset komponentit → prototyyppi → koodi

Se on tavallaan kuin ne Rube Goldberg -esque -valmistuskoneet, joita he käyttävät Doritosin ja Ding-Dongin valmistukseen. Pudota idea prosessikoneeseen ja saatuaan hieta ja muovaamalla muotoon, kun se kulkee vaiheiden läpi, lopputuote ponnahtaa ulos toiselta puolelta! Ennustettavissa! Tehokas!

Eräänlainen.

Prosessikoneet toimivat, mutta vain kun ne toimivat. He eivät sopeutu, ja se tekee heistä hauraita. Tarvitsee vain yhden pienen Sabot-prosessin koneen pysäyttämiseen.

Hank, a.k. “Sabot”

Olen viime aikoina seurannut Doryn löytämistä lapseni kanssa, ja osa "tekemisen" materiaaleista hyppää jatkuvasti eteenpäin.

Elokuvassa on tämä mustekala nimeltään Hank:

Disney / Pixar

Septopus, teknisesti. Hänen hahmomallinsa kanssa oli niin vaivalloista työskennellä, he kaappasivat lonkeroon tehdäkseen hänestä animoimaan toteutettavissa. Silti, 4000 erillisellä säätimellä, hän oli uskomattoman haastava työskennellä.

Prosessin tässä vaiheessa he ohittavat luonnokset ja hahmottelut sekä animaatiot - ne alemmat uskollisuusvaiheet, jotka auttavat sinua tarkistamaan joukon ideoita nopeasti ja edullisesti. He jo saivat myös Real. Merkkilauta rakennettiin, tekniset yksityiskohdat valmisteltiin, peruskysymyksiin vastattiin.

He ovat viimeisessä animaatiovaiheessa - 3D-mallit 3D-ympäristöissä. He olisivat voineet myydä tuotantoaikataulun ja budjetin kustannuksella. Sen sijaan he tekivät jotain todella mielenkiintoista - he palasivat luonnostelemaan.

Disney / Pixar

Piirrättämällä Hankin lonkerien monimutkaista liikettä paperille, he voivat naulata murto-osan ajan täydellisestä juoksevasta animaatiosta, jota he etsivät. Kun he olivat tyytyväisiä sekvenssiin, he animoivat 3D: n vastaamaan. He saivat paremman tuotteen vähemmässä ajassa, koska he päättivät arvostaa prosessin periaatteita prosessin määräämisen sijasta.

Reseptilääkityksen parannuskeino

Finding Dory -tiimi teki paremman tuotteen nopeammin tekemällä päätöksiä, joissa etusijalle asetettiin nopeus ja laatu sen sijaan, että pysyisit tarjousprosessissa.

Voit valita muita arvokkaita asioita, mutta jos työskentelet kaupallisessa ympäristössä, keskittymällä nopeuden ja laadun väliseen makeaseen pisteeseen tulisi olla luettelon kärjessä. Hyvän työn kääntäminen nopeasti on tyypillisesti iso asia ammattimaisille suunnittelijoille ja taiteilijoille.

Prosessia ohjaavien periaatteiden määritteleminen on vasta alku. Näin voit toteuttaa ne käytännössä.

Aloita isoilla kysymyksillä

Jos arvostat nopeutta, aloita projekti selvittämällä, mitkä ovat suurimmat, perustavanlaatuisimmat kysymykset. Getting Real -tapahtumassa tätä kutsutaan ”episenterisuunnitteluksi”:

Aloita sivun ytimestä ja rakenna ulospäin
Epicenterin suunnittelussa keskitytään sivun todelliseen ytimeen - epicenteriin - ja rakennetaan sitten ulospäin. Tämä tarkoittaa, että ohitat alussa raajat: navigointi- / välilehdet, alatunniste, värit, sivupalkki, logo jne. Sen sijaan aloitat sen keskuksessa ja suunnittelet ensin tärkeimmän sisällön.
Se, mitä sivu ehdottomasti ei voi elää ilman, on epicentra. Esimerkiksi, jos suunnittelet sivua, jolla näytetään blogiviesti, blogin viesti itsessään on episentraali. Ei sivupalkin luokkia, ei yläotsikkoa, ei alaosassa olevaa kommenttilomaketta, vaan todellista blogin viestiyksikköä. Ilman blogikirjoitusyksikköä sivu ei ole blogi.
Vasta sen jälkeen kun yksikkö on valmis, voit alkaa miettiä sivun toiseksi kriittisintä elementtiä. Sitten toisen kriittisimmän elementin jälkeen siirryt kolmanteen ja niin edelleen. Se on keskuksen muotoilu.
Epicenterin suunnittelu välttää perinteisen "rakennetaan kehyksen ja pudotetaan sitten sisältö" -mallin. Tässä prosessissa sivun muoto rakennetaan, sitten navigointi sisällytetään, sitten markkinoinnin ”jutut”
 lisätään, ja sitten lopuksi ydintoiminnot, sivun todellinen tarkoitus, kaadetaan mihin tahansa tilaa jäljellä. Se on taaksepäin suuntautuva prosessi, joka vie ensisijaisen tavoitteen ja tallentaa sen loppuun asti.

Tässä on esimerkki siitä, miksi tämä on tärkeää. Työskentelin pienessä sivuprojektissa, iOS-sovelluksessa, joka käytti ainutlaatuista, mahdollisesti toimimatonta ääniliitäntää. Jos en arvostaisi nopeutta, olisin voinut viettää lukemattomia tunteja lukemattomien yksityiskohtien suunnittelussa, jotka lepäävät tämän yhden pariton idean perusta. Suunnittelu tulee ennen koodia klassisessa lineaarisessa prosessissa.

Sen sijaan aloitin koodilla selvittääkseni, onko tämä idea toteutettavissa vai ei. Se ei ollut! Joten muokkasin suunnitelmiani ja sääsin itselleni suunnattoman paljon aikaa ja energiaa.

Kysy vain, WMGMTCATMQITLAOT?

Kun tiedät kysymykset, joihin on ensin vastattava, kysy itseltäsi:
"Mikä väline antaa minulle selkeimmän vastauksen kysymyksiini vähiten ajassa?"

Sivuprojektini tapauksessa vastaus oli koodi. Basecamp.com-sivuston vastaus on usein teksti tai luonnos. Sinulle se voi olla jotain muuta kokonaan.

Tiedät, milloin vaihtaa vaihde

Se antaa sinulle lähtökohdan, mutta miten tiedät milloin on aika vaihtaa toiseen välineeseen? Kun osut vastarintaan.

Ajattele ajamista autolla. Risteilet moottoritiellä - moottori tyhjenee kuin tyytyväinen kissanpentu. Mutta sitten alat ajaa mäkeä ylös. Käytössäsi olevat varusteet olivat loistavia risteilyyn, mutta ei mäkikiipeilyyn. Pysyäksesi nopeudellasi vaihdat uuteen vaihteeseen.

Sama asia täällä. Mutta toisin kuin autot, ei ole olemassa mitään kiinteää indikaattoria siitä, että olet kokenut liikaa vastustuskykyä valitsemasi välineellä. Onneksi useimmilla suunnittelijoilla ja taiteilijoilla on vankka kahva päällä, kun sinun on vaihdettava medialle, joka tarjoaa enemmän uskollisuutta. Tämä on osa, joka sopii lopulta klassiseen matalaan tarkkuuteen → erittäin tarkkaan lineaariseen prosessiin. Tiedät, että olet valmis siirtymään luonnostelusta, kun luonnos lopettaa antamasta sinulle hyödyllistä tietoa.

Kun olet osunut tähän kohtaan, selvitä seuraavaksi tärkein kysymysryhmä ja kysy itseltäsi uudelleen: "mikä väline antaa minulle selkeimman vastauksen kysymyksiini vähiten ajassa?"

Toinen tapaus - siirtyminen takaisin alempaan uskollisuuteen - on tiukempi. Sekä siksi, että ihmiset harjoittavat sitä vähemmän, että siksi, että se on hankala. Ota työskennellä koodilla. Työskentelet 100-prosenttisesti uskollisesti, joten median kyvylle vastata kysymyksiin ei ole mitään rajaa. Mutta sen kyvylle vastata nopeasti kysymyksiin on rajoitettu.

Kun tunnet itsesi tekemättä polkuja, koska tuntuu liialliselta työltä, se on todella hyvä merkki siitä, että sinun on palattava pois. Kun asiat tuntuvat siltä, ​​että ne eivät vain napsauta niin kuin pitäisi, on aika arvioida uudelleen. Ole varovainen, ja alat kehittää sitä tunnetta.

Median käyttäminen eduksesi

On olemassa kolmas tapa vaihtaa mediaan tai pysyä siinä. Tämä ei välitä vastarinnasta, se välittää vain perustavanlaatuisesta totuudesta; prosessi vaikuttaa tulokseen. Aivan kuten piirtämällä jotain lyijykynällä, näyttää siltä, ​​että se piirtää merkinnällä, selaimessa tapahtuva suunnittelu tuottaa erilaisen lopputuloksen kuin Sketchissä.

Mitä enemmän ymmärrät kuinka väline vaikuttaa työhösi - millainen työkalu sen jättää - sitä enemmän voit käyttää sitä etuna. Haluatko suunnittelusi olevan ilmeikäs? Todennäköisesti parempi työskennellä visuaalisen työkalun, kuten Sketch, Illustrator tai jopa * huopata * Photoshop, kanssa. Haluatko pienen ja kevyen suunnittelun? Pidä kiinni koodin suunnittelusta.

Käytännöllinen esimerkki

Nyt kun olen käynyt läpi määräävän prosessin vaaroista, haluaisin kertoa teille ... prosessistani. Ei sinun seurata askel askeleelta! Vain antaa sinulle tosielämän esimerkki siitä, kuinka voit käyttää periaatteita prosessin ohjaamiseen.

Olemme käynnistämässä uuden tavan työskennellä Basecampin asiakkaiden kanssa, ja minun tehtäväni oli luoda uusi sivu Basecamp.com-sivustolle sen markkinoimiseksi. Näin se pelataan:

Suurien kysymysten määrittäminen, välineen valitseminen

Tämä ei ole uusi sivusto tai täysin uusi asettelu. Ensin minun piti selvittää tämän sivun tarkoitus, mitä se yrittää sanoa, ja yleinen rakenne.

"Mikä väline antaa minulle selkeimmän vastauksen kysymyksiini vähiten ajassa?"

Kompit ja luonnostelut ovat poissa. Tämä on haluttaessa olemassa olevaan malliin ja olemassa olevaan malliin. Voisin hypätä suoraan koodiin, mutta merkinnät ovat tässä kohinaa. Teksti on aivan oikein.

Joukko puolivalmiita kopioita

Lisää uskollisuutta

En kiinni tekstissä niin kauan, että sain loppuun kaikki sivun kopion. Kun minulla oli ääriviivat ja käsitys siitä, kuinka halusin puhua ominaisuudesta, muutin vaihteet koodiksi.

Miksi?

Tekstidokumentti ei voinut kertoa minulle mitään siitä, jättäisikö rivi lesken, onko kappale ”tuntu” pitkältä, kuinka kuvat virtaavat jne. Tarvitsin enemmän uskollisuutta. Joihinkin uusiin kysymyksiin olisi voinut vastata staattinen pakkaus, mutta se ei olisi vastannut kopion sopivuutta koskeviin kysymyksiin, ellei ole hukannut aikaa sovittamalla pakkaa tarkalleen koodiin. Ei kiitos.

Kopiosuoritusten käsittely koodissa

Vähentämällä uskollisuutta selektiivisesti

Muutaman lisäkierroskierroksen jälkeen sivu alkoi muotoutua. Visuaalisesti se oli mekaaninen ja alikuntoinen. Halusin sen olevan ilmaisuvapaa, joten siirryin Sketchiin päästäkseen ideoihin.

Olisin voinut pysyä koodissa suurimmaksi osaksi, mutta Luonnoksen avulla voisin ampua joukon ideoita paljon nopeammin kuin pystyin koodaamaan ne. Se antaa minun myös verrata näitä ideoita suoraan toisiinsa, eikä se jättäisi CSS-rottien pesää kaikesta kuoresta. Win-win-win.

Joukko puolivalmiita luonnoksia

Huomaa, kuinka mikään niistä ei ole täysin paistettu? Se johtuu siitä, että heillä ei ole väliä! Nämä eivät ole tarkoitettu asiakasesittelyyn tai kehittäjän vaihtoon. He ovat siellä auttamassa minua selvittämään jotain, niin he ovat roskakorissa. Ajan sijoittaminen niiden kiillottamiseen olisi ollut kokonainen työnhukkaa.

Viimeistellä

Kun minulla oli käsitys suunnasta, se oli koodaa loput. Kopion kiillotus, kuvakaappausten naulaaminen ja arviointi aina lopullisen avainkysymyksen suhteen: ”Onko tämä valmis lähettämään?”. Voit katsoa eläviä asiakkaita Basecampin sivulla täältä.

Näin ei jokainen projekti pelata. Joskus piirrän jotain Procreate-sovelluksessa, joskus aloitan nopealla ja likaisella visuaalisella pakkauksella, joskus kirjoitan kopion Sketchissä, joskus työskentelen 100% koodilla. Kaikki riippuu käsillä olevasta hankkeesta.

Toivottavasti se antaa sinulle jonkinlaisen käsityksen siitä, kuinka voit käyttää periaatteita ohjaamaan prosessiasi tapauskohtaisesti ilman tuntumaa, että keksit jatkuvasti pyörää.

Ajattele prosessiasi ja millaista työtä teet. Määritä sinulle tärkeät periaatteet, keskity ensin isoihin juttuihin ja jatka kyselyä siitä, onko työskentelemäsi väline tällä hetkellä oikea. Työsi on sitä parempi.