Vastuullinen muotoilu

Ja kehityksen rooli suunnittelussa

Tämä on syvä sukellus kehityksen rooliin suunnitteluprosessissa keskittyen reagoivaan suunnitteluun. Se on suunnattu suunnittelijoille / johtajille ja suunnittelijaryhmien kanssa työskenteleville kehittäjille ja visuaalisuunnittelijoille, jotka haluavat tulla paremmiksi web-suunnittelijoiksi. Yritän määritellä ongelmat ja ehdottaa käytännön ratkaisuja. Toivottavasti se auttaa.

Vastuullinen web-suunnittelu. Tumma taide?

On vuosi 2018. Miksi puhumme edelleen reagoivasta suunnittelusta?

Ensin opiskelin reagoivaa suunnittelua jo vuonna 2011. Aloitin aloittamalla lukemalla Ethan Marcotten kirjan "Responsive Web Design".

Tumma verkkosivustojen suunnittelu?

Reagoiva suunnittelu on ollut asia noin 8–9 vuotta. Alkuaikoina oli suoraan vaikuttavaa nähdä reagoiva verkkosivusto! Melkein ”pimeä taide” web-suunnittelu. Mutta se oli kauan sitten.

Suunnittelijana tai suunnittelijana minusta on outoa, että asiakkaat, toimistot ja suunnittelijat kysyvät minulta edelleen:

”… Reagoiva verkkosivusto…”

Ensimmäinen ajatukseni on aina:

"No, tietysti ..."

Mutta suuri osa freelance-web-kehitystyöstäni liittyy asioiden tekemiseen reagoiviksi. Suunnittelijat pyytävät minua rakentamaan heille verkkosivuston ja lähettämään minulle sitten mallin vain työpöydälle tarkoitetusta verkkosivustosta. Ja ensimmäinen kysymykseni on aina:

“Miltä tämä näyttää matkapuhelimella? Tabletissa? ”

Ajattele työpöydän ulkopuolella

Lainata Ethanin teoksesta:

Ajattele työpöydän ulkopuolella ja käsityömalleja, jotka vastaavat käyttäjien tarpeita riippumatta siitä, kuinka suuri tai pieni näyttö on.

Kokemukseni mukaan visuaaliset suunnittelijat eivät vieläkään tee tätä. Tai ainakin, et tee sitä riittävän hyvin.

Kauhu tarina verkkosivujen suunnittelusta meni pieleen

Asiayhteydeksi haluan jakaa pahimman todellisen kokemukseni verkkosivujen suunnittelusta mennessä pieleen. En tietenkään nimeä nimiä. Sanon vain, että verkkosivusto sai merkittävää liikennettä, myös suuren määrän mobiililaitteissa. Ja että liiketoiminta oli riippuvaista myynnistä heidän verkkosivustoltaan. Joten oli iso asia saada tämä oikein!

Yhtiö oli viettänyt yli 3 kuukautta ja reilusti yli 100 000 dollaria verkkosivustonsa massiiviseen uusintaan. He olivat luoneet kauniin konseptityön, mutta he eivät olleet lähellä rakennettavaa suunnittelua, ja kova käynnistyspäivä kasvoi tuskallisesti lähelle.

Tiimi ei ollut sitä mieltä, kuinka se toimisi työpöydän ulkopuolella. Ja kun kyselin vastaavaa ryhmää siitä, kuinka jokin se toimisi muissa kokoissa, sain vain tyhjät lausekkeet takaisin, kuten kysyin hulluja kysymyksiä! He eivät todellakaan nähneet sitä osana työtä ajatella näitä asioita.

He olivat suunnitelleet kauniin kuvan vain verkkosivustolta. Ei mitään, mitä voitaisiin rakentaa.

Nyt en ehdota, että suunnittelukonseptin tutkimusajanjakso ei ole kannattavaa, ennen kuin siirrytään tuotantoon valmissuunnitteluun ... Mutta he olivat käyttäneet melkein koko projektin aikataulun, ja rakennus oli nyt kaukana aikataulusta (tai pikemminkin se ei ollut alkanut).

Kun avasin heidän ensimmäisen PSD: n, huomasin, että verkkosivuston säilö oli noin 1750px. Jos et vielä polta, harkitse tätä leveyttä vain 1–5%: n liikenteestä!

Pienen kaivamisen jälkeen kaiken tämän syyt selvisivät:

Kuukausien ajan oli ollut visuaalisten suunnittelijoiden ryhmä, joka rakasti rakastavasti pikseliä eristettynä kaikista, joilla on mitään vastaavaa tai kehitystietoa.

Sanoen, että he olivat tarkistaneet työtään suurilla TV-näytöillä ja tulostaneet makeisia pienille paperinpalalle, kiinnitettynä studion seinälle. Hämmästyttävää, kukaan tämän prosessin aikana ei ollut miettinyt miltä se todella näyttää selaimella, puhumattakaan pienemmistä näytöistä ja mobiililaitteista.

Lopulta he aloittivat (jotain) määräajassa. Mutta koska vain puolet verkkosivustosta on rakennettu, lukemattomia kysymyksiä ja monet erittäin tyytymättömät sidosryhmät vihaisesti kysyvät:

"Kuinka tämä tapahtui?!"

Kehittäjät selvittävät sen

Valitettavasti juuri monet suunnittelijat ajattelevat tätä.

Olen työskennellyt lukemattomissa projekteissa, joissa minun on pitänyt suunnitella työpöytäsuunnittelu ja muuttaa siitä toimiva, rakennettava, reagoiva verkkosivusto.

Suunnittelijana täytän puutteet muissa suunnittelijoiden työssä. Mutta kehittäjänä menen * yli ja yli * viimeistelemään mitä suunnittelijalla pitäisi olla.

* Huomaa: Rehellisesti sanottuna olen tosissaan (joskus) nautinnut tästä haasteesta luovana kehittäjänä. Tämä on enemmän sanottavaa; Keskimääräinen kehittäjäsi / kehitystiimisi ei arvosta tätä.

Mitä voimme tehdä sille?

Uskon, että se johtuu ajattelutavan muutoksesta:

  • Ajatella reagoivasti.
  • Suunnitteluprosessin uudelleen ajattelu.

Myöhemmin tässä artikkelissa aion käsitellä joitain asioita, jotka olen kokeillut suunnittelutiimien kanssa, joiden kanssa olen työskennellyt, mikä osoittautui onnistuneeksi. Mutta ensin; Tämän artikkelin kiistanalaisin osa… Pidä itsesi kiinni

Tapa suunnittelijoille, jotka oppivat koodaamaan

Tarvitsen kaulani täällä ... Mutta älä piiskaa! Jatka lukemista täyden perusteeni perusteella. Se ei ole niin "mustavalkoinen" kuin luuletkaan ...

Tämä ajattelutapa 'kehittäjät selvittää' ei ole tarpeeksi hyvä.

Kokenut suunnittelija kykenee kuitenkin olemaan hyvä reagoiva web-suunnittelija, jos he ajattelevat reagoivasti.

Se ei ole niin mustavalkoinen kuin "suunnittelijoiden tulisi koodata". Se ei ole. Mutta se auttaa.

Jos et oikein ymmärrä, miten jokin toimii, otat vain oikein pistoksen siihen. Kehittäjät eivät kuitenkaan halua, että suunnittelijat tartuttavat siihen ja jättävät sen heidän selvittää, miten se todella toimii.

Meidän kaikkien on tehtävä paremmin - onko kyse suunnittelijoista, jotka oppivat koodaamaan, tai työskentelevät visuaalisten suunnittelijoiden kanssa opettamalla heille, kuinka suunnitella parempia, reagoivia verkkosivustoja.

Tämä on 1500-luvulta peräisin oleva kaiverrus, nimeltään italialainen kuvanveistäjä Domenico del Barbiere ”Kaksi reunustamaa miestä ja heidän luurankojensa”.

Tämä taideteos edustaa italialaisia ​​renessanssitaiteilijoita, kuten suuria Leonardo da Vinciä ja Michelangeloa, jotka leikkasivat kuolleita ihmiskehoja saadakseen paremman käsityksen lihaksen toiminnasta, jotta he voisivat luoda realistisempia maalauksia ja veistoksia.

Tämä käytäntö on uskomaton esimerkki omistautumisesta käsityöhösi. En aio ehdottaa, että aloitamme erittelymme verkkosivustomme käyttäjille tai web-kehittäjille! Mutta se on hyvä ruoka ajatukselle, kuinka:

Paremman työn ymmärtäminen on välttämätöntä paremman ymmärryksen saamiseksi siitä, miten jokin toimii.

Suositun analogian leikkaaminen

Jos olet joskus keskustellut visuaalisten suunnittelijoiden kanssa "pitäisikö suunnittelijoiden tietää koodin", olet todennäköisesti kuullut tämän linjan:

"Mutta arkkitehdit eivät tiedä kuinka rakentaa!" Gotcha!

No ei. Useimmat arkkitehdit eivät pysty rakentamaan rakennusta. Mutta hyvällä arkkitehdilla on hyvä käsitys siitä, mitä siihen kuuluu. He eivät piirrä vain kauniita kuvia rakennuksista. He laativat kaaviot. He tuntevat käytetyt materiaalit - miten ne näyttävät, tuntevat, reagoivat erilaiseen valoon jne.

Isäni oli määränmittaaja. Hänen työhönsä liittyi riskien arviointi ja hinnan asettaminen arkkitehtien - usein epärealistisille - visioille. Ja ymmärrettävästi, hän ei ollut ihastunut joihinkin arkkitehteihin, joiden kanssa hän työskenteli! (Kuulostaako visuaalisten suunnittelijoiden ja kehittäjien suhteesta? ”)

Mutta parhaat arkkitehdit, joiden kanssa hän työskenteli - jotka todella tunsivat kaupan - suunnittelivat realistisempia, rakennettavia rakennuksia, mikä säästää kaikille paljon aikaa ja rahaa. Ja hän rakasti työskentelyä arkkitehtien kanssa! Aivan kuten kehittäjät rakastavat työskennellä suunnittelijoiden kanssa, jotka tietävät tavaraa. Mikä tekee terveellisemmästä työkulttuurista ja paremman lopputuotteen.

Rehellinen neuvoni on:

Opi rakentamaan mitä suunnittelet. Se yksinkertaisesti tekee sinusta paremman web-suunnittelijan. Luulen, että sinut yllättää kuinka paljon nautit siitä. On hauskaa ja erittäin ilahduttavaa tuoda omat luomuksesi elämään ja parantaa niitä selaimessa!

Mutta epäonnistuessaan:

Kaikki tämä ei tarkoita, että visuaaliset suunnittelijat eivät voi olla hyviä web-suunnittelijoita tai heille ei voida opettaa reagoivaa suunnittelua. Heidän on vain opittava ajattelemaan reagoivasti - ajattelemaan kehittäjänä tietämättä koodia.

Kaksi tapaa lähestyä reagoivaa web-suunnittelua

On olemassa kaksi tapaa lähestyä web-suunnittelua, mutta ajatteluprosessi - tämä ajattelu reagoivasti ajattelee - on aina sama. Mikä on mielestäni avain.

Pohjimmiltaan se, kuinka paljon itse visuaalisesti suunnittelen (ts. Luon yksityiskohtaisia ​​malleja), riippuu siitä, kuka sitä rakentaa.

Lähestymistapa 1: Kun joku muu aikoo rakentaa mitä suunnittelen

Tässä tapauksessa suunnittelijana:

  • Suunnittelen jokaisen taitekohdan.
  • Varmistan, että katan kaikki skenaariot ja tilat.
  • Toimitan reagoivia mallisuunnitelmia.
  • Toimitan tyylinoppaan, joka kattaa kaiken, mikä ei ole visuaalisen suunnittelun ilmeistä, kuten hover-tilat jne.

Ja lopputuote näyttää noin:

Adobe Portfolio -markkinoinnin verkkosivuston (2016) suunnittelutapaustutkimus

Lähestymistapa 2: Aion rakentaa sitä, mitä suunnittelen itse

Vastoin sitä, mitä olen sanonut kaikkien väliaikojen ja skenaarioiden kattamisesta - tässä tapauksessa - suunnittelen vain työpöydälle. Mutta ajattelen ja kuvittelen aina, kuinka se voisi näyttää pienemmiltä näytöiltä. Koska olen yksi rakentamassa sitä, pääsen selaimeen mahdollisimman nopeasti vahvistaakseni ideani.

Esimerkki tästä lähestymistavasta on henkilökohtainen projekti, Club of the Waves:

Club of the Waves -tapaustutkimus

Kuten yllä näet, pilkkasin vain työpöydän ydinsivuja.

Suunnitteluprosessini sujui suunnilleen näin:

  • Tämä oli olemassa olevan verkkosivuston uudelleensuunnittelu. Joten käytin Google Analyticsia selvittääksesi, mikä selainkoko ”useimmat ihmiset” katsovat verkkosivustoa. Sitten suunnittelin työpöydän malleja vastaamaan tätä kokoa.
  • Sieltä suunnittelin loput selaimeen - koodin kirjoittamisen - ja näen muutosten tapahtuvan reaaliaikaisesti. Tällä tavalla voin mukauttaa koot, etäisyydet, asettelun ja animaation sydämeni sisältöön.
  • Ja voin testata sitä eri selainkokoilla lisäämällä tarvittavat väliaikapisteet ja mediakyselyt.

Toinen esimerkki tästä lähestymistavasta web-suunnitteluun on Owl Studios -verkkosivusto. Pilkkasin sitä työpöydälle, kuten alla näkyy:

Owl Studiosin suunnittelutapaustutkimus

Ja sitten minulla oli hauskaa sen kanssa selaimessa:

Minulla ei ollut todellista suunnitelmaa sivuston animoimisesta. Tunsin sen vain kirjoittaessani koodia ja päivittämään selainta, kunnes olin tyytyväinen siihen. Se oli hyvin "kehitysasia", mutta 100% osa suunnitteluprosessia.

Ja sama ”selaimen suunnittelu” -prosessi koskee kaikkia raja-arvoja. Alla näet kuvakaappauksia siitä, miltä se päätyi mobiililaitteille:

Kysymys hienosäätöstä

Olen juuri kuvaillut, kuinka hienosäätää mallia selaimessa - lisäämällä animaatiota, mukauttamalla kokoja ja välilyöntejä jne.

Ajattele kuinka helppoa, tehokasta ja nopeaa tämä on luovan kehittäjän tehtävä. Kuvittele nyt suunnittelija, joka yrittää välittää ne samat sävelmät kehittäjälle ...

  • Toimitatko heille kierroksen jälkeen kierroksia sähköpostitse?
  • Löysitkö heitä Slackilla?
  • Lähetetäänkö kymmeniä GitHub-julkaisuja?
  • Toimitatko heille uuden suunnittelutiedoston, joka korostaa muutokset useita kertoja?
  • Tai istutko heidän vieressään ja sanot heille, mitä tehdä !?
Lupaan sinulle, ettei kukaan kehittäjä halua suunnittelijan olkapäänsä yli, selkänojassa ajamista!

Kuitenkin teet sen, edestakaisin -prosessi voi olla erittäin aikaa vievä, tehoton ja turhauttava kaikille.

Kehitys on muotoilua

Suunnittelijoiden, tuotepäälliköiden, suunnittelupäälliköiden ja jopa kehittäjien on lakattava ajattelemasta kehitystä erillään suunnittelusta.

Ja sen ei tarvitse tarkoittaa:

  • "Suunnittelijoiden tulisi koodata."
  • Tai; "Kehittäjien tulisi suunnitella."

Se tarkoittaa; Meidän pitäisi työskennellä yhdessä.

HTML, CSS ja jopa JavaScript nykyään ovat osa suunnitteluprosessia.

Suunnittelu ei lopu, kun poistut Sketchistä, Photoshopista tai XD: stä. Tai kun olet avannut verkkosivuston tai tuotteen.

  • Mukautamme malleja selaimeen.
  • Testaamme malleja oikeiden ihmisten kanssa,
  • Sitten suunnittelijat ja kehittäjät työskentelevät yhdessä suunnittelun iteraamiseksi.

Verkkosivun animaatio on ehkä ilmeisin esimerkki siitä, kuinka kehitys on muotoilua. Teollisuudemme on pakkomielle verkkosivustojen animoinnista. Mutta suunnittelija ei tee niin *, kehittäjä on.

* Ja en puhu suunnittelijoista, jotka käyttävät hienoja muotoiluprototyyppiohjelmistoja videoiden ja simulaatioiden luomiseen, jotka jäljittelevät lataustiloja ja vuorovaikutusta. Anteeksi. Se ei ole totta. Kehittäjän on edelleen luotava sen mitä suunnittelija teki - niin tarkasti kuin he realistisesti pystyvät - budjetin ja aikataulun puitteissa.

Epicurrence №6 ja peruskulttuuri, kuten esiintyvät: 'Elämän hengittäminen digitaalisiin tuotteisiin'

Jos yllä olevien kaltaisten asioiden kehittämistä ei pidetä luovana tai suunnitteluprosessin osana ... En tiedä mikä on.

Joten, jotka liittyvät kehityksen rooliin suunnittelussa:

Tehdä:

Lisää suunnitteluprosessissa käyttöliittymiä ja luovia kehittäjiä. Hanki mielipiteensä varhaisessa vaiheessa ja poista ongelmat ennen kuin on liian myöhäistä.

Älä:

Hyppää vain mallit kehittäjille prosessin lopussa. Toivottavasti kaikki on kunnossa. Tai voit lopettaa kauhujutun kilpailevalle kaivoksellesi, aikaisemmin!

Olet joukkue, toimit kuten yksi

Yksinkertainen tapa rohkaista suunnittelijoita ja kehittäjiä työskentelemään paremmin yhdessä on saada suunnittelu- ja kehitysryhmät istumaan keskenään. Tai ainakin lähellä toisiaan. Älä erota heitä.

  • Tiimisi jakaminen asettaa tarpeettomat rajat.
  • Luo jakavan kulttuurin.
  • Ja vaikeuttaa yhteistyötä.

Olen kokenut tämän menneen pieleen niin monta kertaa suurissa yrityksissä ja suunnittelutoimistoissa. Se ei ole terveellistä.

Ajattelee reagoivasti

Kukaan suunnittelija ei aio kiusata kehittäjiä, mutta toisinaan he suunnittelevat vahingossa asioita, jotka eivät toimi tai jotka eivät kata kaikkia perusteita. Kuten joku koodaajista ymmärrän tämän, mutta puhtaasti visuaalisuuteen keskittyvät suunnittelijat eivät usein tee sitä. Heidän on opittava ajattelemaan reagoivasti - ajatella kehittäjänä.

Joten miten opetamme visuaalisia suunnittelijoita ajattelemaan reagoivasti?

Vastauksena ei ole huutaa heitä, kun he tekevät virheitä. Se on kouluttaa heitä, jotta he muodostavat parempia tapoja suunnitteluprosessissaan ja ajattelussaan.

Alla on 5 asiaa, jotka olen kokeillut suunnittelutiimien kanssa NYC: ssä, mikä osoittautui tehokkaaksi:

1) Suunnittele reagoivilla malleilla

Tässä on luonnosmalli, jonka olen luonut suunnittelijaryhmälle aikaisemmassa työssä:

Tämä lähestymistapa on hyvä tapa opettaa suunnittelijoita ajattelemaan kaikkia skenaarioita ja lähestymään suunnitelmiaan reagoivammin.

Hyvä reagoiva malli sisältää:

  • Kuvataulu jokaisen rajapisteen esittämiseksi.
  • Jokaisessa reagoiva ruudukko on selvästi näkyvissä.
  • Tässä tapauksessa tauonpisteet vastaavat suunnilleen ”suurta” ja ”pientä” työpöydän näkymää, tablettia (muotokuva) ja mobiililaitetta.

Nyt minun pitäisi sanoa; Mielestäni on tärkeätä olla ajattelematta verkkosivustoa pelkästään työpöydällä, tablet-laitteella ja mobiililaitteilla. Tai 'breakpoint 1', 'breakpoint 2' ja niin edelleen ... Mutta se on tehokas tapa kehystää se muille kuin teknisille henkilöille. Ja tarpeeksi hyvä tällaiseen visuaaliseen suunnitteluun.

Mielestäni tärkeä oppitunti on tässä:

Stressitesti

Et todennäköisesti ratkaise kaikkia reagoivia kysymyksiä tällaisella mallinnetulla mallinnusmenetelmällä, mutta ainakin se tarjoaa suunnittelijoille yksinkertaisen keinon stressitestaamiseen. Ja löytää onneksi kaikki suunnittelussa olevat puutteet ennen kuin ne luovutetaan kehittäjälle.

2) Se ei ole 'versio'

Mielestäni tehokas toteutus joillekin ihmisille on lakata ajattelemasta mobiililaitteita ja tablet-laitteita versioksi.

  • Se ei ole versio.
  • Se on sama verkkosivusto.
  • Se on sama HTML-koodi.
  • Vain CSS on muuttunut.

Versio on perintötermi matkaviestinnän uudelleenohjaamisen aikakaudelta, joka on suunnattu mobiilikäyttäjille - aikakaudesta, joka korvasi reagoivien verkkosivustojen. Meidän on siirryttävä eteenpäin tästä vanhasta termiästä.

Mielestäni tämä "versio-ajattelutapa" pidättää jotkut suunnittelijat suunnittelemasta reagoivasti.

"Joku muu selvittää toisen version ..."

Tai;

"Ei niin monet ihmiset näkevät sitä matkapuhelimella ..."

No, tämä asenne ei ole enää tarpeeksi hyvä. Koska 'muu versio' saa paljon enemmän huomiota kuin jotkut tajuavat tai ajattelevat. Se on osa suunnittelijan työtä ajatella työpöydän ulkopuolella.

3) Suunnittelu kaikille skenaarioille, ei vain parhaimmissa tapauksissa

Ajattele reagoivaa asettelua seuraavasti:

  • Käyttöliittymä, jota on lähes mahdoton rikkoa.
  • Se voi viedä minkä tahansa määrän sisältöä ja merkkejä.
  • Ja se toimii millä tahansa selaimen leveydellä tai korkeudella.

Näen liian usein malleja, jotka toimivat vain rajoitetulle määrälle merkkejä, mutta voit taata, että asiakas kirjoittaa otsikkoonsa enemmän sanoja kuin ”Lorem Ipsum”.

Älä suunnittele sopivalla määrällä merkkejä sopimaan mallisi.

Ajattele suunnittelua ja sisältöä jotain, joka toimii yhdessä. Ei toisistaan ​​riippumatta.

Älä suunnittele asioita vaikuttamaan suunnittelijaystäväsi tai voittaa palkinto tai saada tykkää Dribbblessa. Maadoita työsi todellisuudessa ja suunnittele todellisella sisällöllä ja tiedoilla - tai lähikuva.

4) Ajattele prosentteina, ei pikseleinä

Voit suunnitella jotain 100 pikselin leveää suunnitteluohjelmistosi. Selaimessa kyseinen 100 kuvapistettä on sen säilön prosenttimääräinen leveys. Joten, kun selaimen leveys pienenee, 100 pikselistä tulee enemmän kuin 80 pikseliä, 60 pikseliä, 40 pikseliä ja niin edelleen.

Mieti nyt, mitä sisältöä sinulla on tällä 100 kuvapisteen alueella ...

  • Toimiiko se pienemmällä leveydellä kuin 100 kuvapistettä?
  • Jos ei, sinun on joko mietittävä asettelua tai sisältöä uudelleen.
  • Voit myös luoda välivaiheen kattaaksesi tilanne, joka tapahtuu, kun se ei enää toimi.

Korostan tätä ajattelutapaa prosentteina eikä pikseleinä, koska juuri se viimeisimmässä työssäni suunnittelijat kamppailivat eniten. He eivät vain voineet saada päätään tämän käsitteen ympärille, jonka mukaan asiat kapenevat suhteellisesti, ja miksi se on suunnitteluongelma.

Loin tämän nopean mallin (yllä) osoittaakseni tämän kohdan nuoremmille (ja vanhemmille) visuaalisuunnittelijoille viimeisellä työni aikana, mikä osoittautui todella tehokkaaksi!

  • Se näyttää saman 12 sarakkeen ruudukon, 2 eri selaimen leveydellä.
  • Se osoittaa selvästi, kuinka ruudukkon sarakkeet kapenevat,
  • Ja mikä vaikutus sillä on samaan tekstiin, joka kattaa samat 4 saraketta molemmissa skenaarioissa.

Joskus näkeminen uskoo. Tällaisten asioiden osoittaminen suunnittelumallissa tai nopea esittely selaimessa (Codepenin kaltaisen palvelun kautta) voi olla avain ihmisten ymmärtämiseen.

5) Tarkastele malleja selaimessa tai laitteessa

Palaa aikaisempaan kauhuhistoriaani: virheitä tehdään helposti, kun emme maadoita työtämme todellisuudessa. Niin:

  • Älä tarkista (vain) suurissa näytöissä tai TV-näytöissä tekemiäsi töitä.
  • Älä tulosta (vain) malleja ja katso niitä kiinnitettyinä seinälle.

Kumpikaan näistä ei anna tarkkaa kuvaa siitä, mitä loppukäyttäjä näkee. Mikä todella on ainoa asia, jolla on merkitystä.

Ole myös varovainen suunnitellessasi verkkokalkkinäytöille ja pienille kannettavien tietokoneiden näytöille. Esimerkiksi verkkosivuston suunnittelu MacBookille - tai mille tahansa kannettavalle tietokoneelle - on vaikeaa, koska et todennäköisesti näe koko sivun leveyttä suunnitteluohjelmistossa. Joten voit zoomata ja loitontaa nähdäksesi työn suunnitellessasi. Mutta ongelma on seuraava: vain sinä, suunnittelija ystäväsi ja Dribbble-seuraajasi näkevät työtänne näin. Loppukäyttäjä ei.

Toivottavasti tämä osoittaa huomautukseni:

Vasemmalla on verkkosivusi suunnittelumalli. Tiimisi arvioi sitä kokonaisuutena, yhtenäisenä suunnitteluna, aivan kuin sinä tekisit graafisen suunnittelun.

Mutta oikealla puolella on se, mitä käyttäjä todella näkee - selaimessa - kun selaa. Siinä on iso ero! Joten, sinun on otettava huomioon tämä todellisuus, enemmän kuin koko sivu.

Tämä ei ole graafinen suunnittelu, vaan web-suunnittelu.

Hyvä tapa välttää tämä ongelma on päästä rakennettuun prototyyppiin mahdollisimman nopeasti. Tai seuraavaksi parasta, jotain InVision-prototyyppiä. Tällä tavalla tiimisi voi tarkistaa työn selaimessa, kuten loppukäyttäjät tekisivät ... Tai heidän kädessään mobiililaitteessa.

On tärkeää pitää näkökulma ja maadoittaa mallisi todellisuuteen.

Päivitys: 2019. Kirjoitin kirjan järjestelmän suunnittelusta ja digitaalisen tuotemerkin ohjeista! https://designsystemfoundations.com