Enemmän kuin sanoja: Oleminen poikkitieteelliseksi sisältöstrategiksi

Ihmiset pääsevät sisältöstrategiaan kaikin tavoin. Osittain siksi, että kyseessä on suhteellisen uusi tieteenala, mikä tarkoittaa, että ihmisillä on vähän ennakkokäsityksiä siitä, kuinka sisältöstrategioiden on tarkoitus toimia. Kokeilemalla omaa työnkulkua olen huomannut, että suunnittelu- ja prototyyppityökalujen mukavuus ja oppiminen koodausympäristöjen ympärille ei ole vain auttanut minua olemaan tehokkaampaa sisältöstrategiaa, vaan myös tehnyt minusta monipuolisemman UX-harjoittajan. ja yhteistyökumppani.
 
Muistan, että asensin suunnitteluohjelmiston luonnoksen ensimmäistä kertaa: olin tarjonnut ottamaan pienen, sisältöön suuntautuneen projektin pois ylikuormitetulta suunnittelijan levyltä. Alennuksen säästämiseksi sen sijaan, että ongelmaa kehitettäisiin diokansiossa tai asiakirjassa, hän lähetti minulle luonnokset-tiedostot uutta komponenttia varten, jotta voisin tehdä muutokset itse. Vietin iltapäivän viihdyttämällä Sketchiä - yrittäessäni piirtää nuolia, miettiä, kuinka muokata ja muuttaa tekstikerrosten kokoa, viemällä piirustuslevyjä jaettavaksi muiden kanssa. Sanojen kirjoittaminen itse makeissa tuntui uudelta ja mielenkiintoiselta - kuten todellisen, konkreettisen edistyksen perustiedot työskentelyssäni. Olin koukussa.

Minulle tyydyttävin tapa harjoittaa sisällön suunnittelua on ollut työskennellä suoraan mallien sisällä.

Facebookin sisältöstrategistina minulla on tehtävä ylläpitää käsitteellisiä puitteita ja ääntä - yksinkertaista, suoraviivaista ja inhimillistä - puhumme yhteisömme kanssa luodaksemme selkeitä, johdonmukaisia ​​ja myötätuntoisia kokemuksia. Kaikki käyttämästämme sävystä kirjoittamiseen, demonstrointiin ja työn jakamiseen tavat auttaa luomaan kokemuksia, jotka ovat harkittuja, inhimillisempiä ja parempia niitä käyttäville ihmisille.
 
Minulla on kuitenkin paljon itsenäisyyttä siitä, kuinka teen tämän työn. Ja ajan myötä olen huomannut, että jotkut parhaista tavoista sisällön luomiseen ja sisältöstrategian arvon osoittamiseen ovat suunnittelijoiden ja insinöörien työkaluissa ja prosesseissa, ei tekstitiedostoissa. Kerron lisää siitä, mitä tarkoittaa olla monitieteinen sisästrategia, osoitan, miksi se on vaivan arvoista, ja tarjoan joitain ohjeita aloittamiseen.

Opi suunnittelemaan ja ideoimaan prototyyppejä itse

Kuten suurin osa sisältöstrategeista, aloittaessani uutta projektia, menin pitkään asiakirjaan tai laskentataulukkoon. Luon hienosti järjestettyjä taulukoita, tuoda kuvakaappauksia ja merkitä sarakkeet juuri niin. Sain paljon tyytyväisyyttä tekemällä nämä hienosäädöt ja asiakirjat edelleen.

Mutta kun nämä asiakirjat olivat ainoa toimitukseni, vietin enemmän aikaa palautteen antamiselle ja kiinni suunnittelu- ja suunnittelutyöhön kuin itse auttaa rakentamaan tuotteita. Tunsin juuttuneen reaktiiviseen asentoon. Tämä johti myös tarpeettomaan ponnisteluun. Suunnittelu väistämättä muuttui, jolloin sisältöni oli vanhentunut. Yrittäessään osoittaa tarkkuutta ja strategista ajattelua näissä asiakirjoissa, usein tuntui siltä, ​​että näytän työni sen vuoksi, että toimin sen sijaan, että tarjoaisin jotain muuta, joka voisi olla hyödyllistä.

Nykyään sen sijaan, että aloittaisin tekstiasiakirjassa, aloitan useimmat projektit käyttämällä samoja komponentteja ja suunnittelutyökaluja kuin ryhmäni suunnittelijoilla. Kun suunnittelija näyttää minulle jotain, jota he työskentelevät Sketchissä, ensimmäinen pyyntöni on, että he jakaisivat taulunsa kanssani. Kun he rakentavat prototyyppiä Frameriin tai Origamiin, pyydän tiedostoja, jotta voin nähdä, kuinka he tekivät sen. Ajan myötä näiden työkalujen taitojen hankkiminen on auttanut minua jatkamaan nykyistä suunnittelutyötä paljon tehokkaammin.

Yrittäessään osoittaa tarkkuutta ja strategista ajattelua näissä asiakirjoissa, usein tuntui siltä, ​​että näytän työni sen vuoksi, että toimin sen sijaan, että tarjoaisin jotain muuta, joka voisi olla hyödyllistä.

Esimerkiksi äskettäisessä projektissa sain tietää, että voimme lisätä uuden toiminnallisuuden, jonka oletin, että meillä ei olisi aikaa toteuttaa. Puhuessani ryhmäni suunnittelijan kanssa oikeasta ratkaisusta, muutin itse malleja ja prototyyppiä. Tämä säästää meille molemmille aikaa: hän pystyi keskittymään korkeamman asteen ongelmiin, eikä minun tarvinnut odottaa häntä hämmästyttämään muutosta ja käsittelemään sisällön ja mallien välisiä eroja. Hoitoin sitä lähteellä.
 
Viime aikoina olen alkanut suunnitella ja prototyyppittää perustuotteiden virtauksia tyhjästä, käsitellä ongelmia, jotka haluan ratkaista alusta alkaen. Itseluottamukseksi lisääminen ja ideoiden elämään oppiminen yksinään ovat auttaneet minua luomaan rikkaampia suhteita myös suunnittelijoihin; toimimme enemmän ristiinfunktionaalisesti ja ymmärrämme toisiamme paremmin. Tiimini suunnittelijat luottavat enemmän mielipiteihini tuotesuunnittelusta, ja mielestäni heidän palautteensa sisältöön on myös hyödyllisempää.
 
Minulle tyydyttävin tapa harjoittaa sisällön suunnittelua on ollut työskennellä suoraan mallien sisällä. Kirjoitan ja ylläpidän tekstitekstejä, jotka toimivat usein paremmin nopeissa, pienissä sisältöprojekteissa tai kun minun on näytettävä useita vaihtoehtoja kerralla. Mutta kun minulla on idea, josta olen erityisen innoissani, sen suunnittelulla ja prototyyppien suunnittelulla ja prototyyppien suunnittelulla ja prototyyppien suunnittelulla olen itse ollut paljon tehokkaampaa saada sisäänosto ja saada kiinnostusta kuin millään dokumentilla, ehdotuksella tai aivoriihalla, jonka olen koskaan koonnut.

Päivitä sisältö itse ja osallistu koodin arvosteluihin

Suurin osa tuotesisällön strategeista luottaa koodiin - ja sitä kirjoittavat insinöörit - työhömme nähdäkseen päivänvalon. Joten on syytä ymmärtää koodaus (ja koodin käyttöönotto), ja vielä tärkeämpää on tulla osaksi sitä. Minulle koodilla työskenteleminen on kyse kirjoituksen omistamisesta ideasta luonnokseen julkaisuun. Pystyminen päivittämään sisältöä yksinään antaa voimaa, ja siitä on tullut olennainen osa työskentelyäni.

Väittäisin, että todellinen tuotettaito vaatii jonkinlaista koodilukutaitoa. Ja koodi on loppujen lopuksi vain toisenlainen kieli - jokaisen sisällönstrategian luonnollinen väline. Mutta jos oman sisällön päivittäminen tai muuten suoraan koodikirjoittaminen kuulostaa pelottavalta, suosittelen, että aloitat hankkimalla lukutaidon siitä, kuinka ryhmäsi insinöörit työskentelevät - työkaluilla, joita he käyttävät ja kuinka he iteroivat ja julkaisevat koodinsa. Jos ryhmäsi käyttää esimerkiksi ohjelmistokehitysalustaa GitHub, harkitse oppimista luoda ja yhdistää omia vetopyyntöjäsi. Uusien taitojen oppiminen omaan lukuunsa on yleensä kannattavaa, mutta oppimistaitot, jotka antavat sinulle kokonaisemman näkökulman työstäsi, ovat vielä arvokkaampia. Ne auttavat sinua tekemään monipuolisemmasta yhteistyökumppanista, ja koska ryhmäkavereidesi työskentelyn tunteminen on eräänlaista empatiaa, rakennat suhteita prosessissa. Lisäksi, jos tiedät kuinka ryhmäsi insinöörit työskentelevät, voit lisätä itsesi työnkulkuun ja tehdä heidän elämästään helpompaa poistamalla vaiheet siitä, kuinka he käyttävät sisältöäsi. Harvemmat sekaannusmahdollisuudet ovat aina parempia.

Todellinen tuotteiden lukutaito vaatii jonkinlaista koodilukutaitoa. Ja koodi on loppujen lopuksi vain toisenlainen kieli - jokaisen sisältöstrategian luonnollinen väline.

Pyydän kaikkia insinöörejä, joiden kanssa työskentelen, sisällyttämään minut koodiarviointiin. Jos lisäät itsesi koodin tarkistusprosessiin, varmistat, että olet osa keskustelua loppuun saakka ja että tiimisi lähettää määrittämäsi tekstin. Paljon kiillotusta ja viimeistelyä tapahtuu yleensä käyttöönoton aikana. Oleskelu tämän prosessin aikana tarkoittaa, että löydät ja puutut ongelmiin, jotka muuten kaipaat. Olen kiinni kirjoitusvirheistä, löytänyt parempia lauseita viime hetkellä ja estänyt käännösongelmia. Insinöörit arvostavat, että autat myös paremman kokemuksen toimittamisessa. Jos haluat upottaa varvassi kehittäjäympäristöihin tai lähettää oman koodisi, osallistuminen ryhmäsi olemassa olevaan koodin tarkistusprosessiin on hyvä paikka aloittaa.

Tee asia

Näiden taitojen oppiminen vie aikaa, ja voi olla pelottavaa muuttaa jotain perustavaa laatua työskentelytavasi suhteen. Se auttaa myös tiimiä, joka on avoin sinulle ja käyttävät vähemmän perinteistä lähestymistapaa. Jos sinulla on vaikeuksia saada joukkueesi alukseen, aloita etsimällä pieniä tapoja, joilla voit muuttaa työskentelytapasi nyt, sen sijaan, että ottaisit hienon tapauksen muuttaa koko ryhmänlaajuista prosessia.

Jos ihmiset ovat tottuneet siihen, että jaat asiakirjoja heidän kanssaan, alkaa sisällyttää visuaalisia esimerkkejä muutoksista kyseisiin asiakirjoihin. Luo prototyyppejä ja linkki niihin. Kysy ryhmältäsi ehdotuksia siitä, kuinka annat heille työtä tai kuinka voit auttaa heitä olemaan tehokkaampia.
 
Jos insinöörit eivät merkitse sinua koodin arvosteluihin, seuraa heitä missä tahansa koodausympäristössä ja etsi luonnollisia tapoja liittyä keskusteluun. Tilaa heidän työvirransa, jotta näet mitä he ovat tekemisissä. Käytetystä koodausympäristöstä riippuen voi olla mahdollista lisätä sääntö, joka tilaa sinut automaattisesti koodikatsauksiin, joihin liittyy tiettyjä insinöörejä tai sisältömuutoksia. Jonkin ajan kuluttua ryhmäsi insinöörit tottuvat siihen, että olet ympärilläsi, ja alkavat ottaa sinuun yhteyttä ilman, että kukaan tuntuu kuin heidän olisi pitänyt oppia ja omaksua uusi prosessi.

Jos yrität päivittää koodiasi ja tarvitset jonkun opettamaan sinua tai sinun on näytettävä asia oikeiden oikeuksien saamiseksi, kokeile kehystä se tapana säästää tekniikan aikaa. Kun korjaat kirjoitusvirheitä ja säädä virheilmoituksia, insinöörit voivat keskittyä vaikeampiin ongelmiin - ja sinä autat korjaamaan prosessin virheitä.
 
En halua vähentää sydämen ja mielen vaihtamisen vaikeuksia. Hyvä uutinen on kuitenkin, että sisältöstrategia on niin uusi, harvoilla ihmisillä on ennakkokäsitys siitä, kuinka sinun “pitäisi” toimia - päätät itse. Joten jos vietät suurimman osan ajasta täydellisesti hiottujen laskentataulukoiden ja asiakirjojen luomiseen, suosittelen, että laitat ne hetkeksi sivuun ja yrität käyttää samoja työkaluja ja prosesseja kuin ryhmäsi suunnittelijat ja insinöörit. Opi puhumaan heidän kieltään. Et tule pettymään.