Diplomityö kansissa ja palautettu

Palautin tänään diplomityöni ja hoidin tarvittavat byrokratiat. Näyttäisi siis vahvasti siltä, että valmistumispäivä on 23.9.2009. Ei ollenkaan huono fiilis tapahtuneesta.

Halukkaat voivat löytää diplomityöni oheisen linkin kautta:

Luotain – Ihmisläheinen menetelmä verkkosivustojen suunnitteluun

Henkilökeskeinen verkko

Chris Messina ja Jyri Engeström kirjoittivat Arctic Startupin artikkelissaan dokumenttikeskeisen verkon muutoksesta henkilökeskeiseen suuntaan:

If the document-centric web was dominated by static pages, then the people-centric web is about placing you at the center [...] We’re seeing the rise of dynamic, portable friend lists and non-brand-mediated identities that can be used across a range of standards-compliant websites. People are beginning to move freely between silos. Individuals are increasingly able to bring their data with them and substitute one service or service provider with another, as one can switch between Outlook and Thunderbird for email, or Photoshop and Pixelmator for image editing on the desktop.

Kirjoittajat pitävät aiheesta workshopin Helsingissä 30.9.2009 osana MindTrek-konferenssia. Tapahtuman otsikkona on The Social Web Workshop ja ohjelmassa on kuvauksen perusteella perustietoa sosiaalisen verkon palveluista ja teknologioista sekä annetaan vinkkejä siitä, miten teknologioita voidaan hyödyntää käytännön palveluissa.

Diplomityö paketissa

Vähänpä on tullut tänne blogiin taas kirjoiteltua. Tässä kuitenkin pikaisena raporttina kerrottakoon, että Diplomityö on nyt paketissa! Työn otsikoksi tuli:

“Luotain – Ihmisläheinen menetelmä verkkosivustojen suunnitteluun.”

Varsinainen valmistuminen vienee vielä ainakin muutaman viikon, mutta läheltä liippaa jo. Toivottavasti päätös tulee pian, että pääsee järjestämään valmistujaisbileitä.

Samalla pääsee toteuttamaan haavekuvan, jonka avulla olen motivoinut takamustani takaisin dippatuolin suuntaan: olen luvannut itselleni hankkia valmistuttuani kaasugrillin parvekkeelle. Sopiva ehdokas voisi olla esimerkiksi Landmannin Original-mallistosta löytyvä valurautaparilagrilli, Maskusta 199 euroa.

Design Strategy

Adaptive Pathin Peter Merholz kirjoitti AP:n blogissa strategiasta designin näkökulmasta. Strategia luo pohjaa muulle suunnittelutyölle ja se voidaan jakaa seuraavasti:

  • Philosophy
  • Vision
  • Planning

Filosofia pyrkii luomaan korkeamman tason lähtökohdat suunnittelulle, visio pyrkii muotoilemaan ne toteutettavaan muotoon ja suunnittelu kertoo millaisin konkreettisin askelin koko laajempi ajatus saadaan toteutettua.

Sisältöstrategia – jälleen uusi buzzword?

A List Apart omisti sisältöstrategialle (content strategy) uusimman numeronsa, joten oli aika selvittää, mitä termillä oikeastaan tarkoitetaan.

Content Strategy – Toward a working definition of the disciplinary field (Jeffrey MacIntyre):

Content strategy is an emerging field of practice concerned with the analysis, presentation, production and management of content. It has its home in information sciences and interaction design, and draws practitioners with a diverse range of academic backgrounds.

Content Strategy: The Philosophy of Data (Rachel Lovinger):

The analogy I’ve been using recently is that content strategy is to copywriting as information architecture is to design. I find this analogy to be especially encouraging because six years ago, as the crest of the first wave of the web was about to break, people had no idea what “information architecture” meant either.

The irony of this communication challenge is that the main goal of content strategy is to use words and data to create unambiguous content that supports meaningful, interactive experiences. We have to be experts in all aspects of communication in order to do this effectively.

Sisältöstrategia kuulostaa äkkiseltään buzzwordilta sanan koko merkityksessä. Sana ei kaikessa epämääräisyydessään kelvannut edes wikipediaan, mikä saattaa kertoa jollekin jostain jotain.

Ongelmakohdat, joihin sisältöstrategia pyrkii tuomaan helpotusta ovat kuitenkin todellisia:

  • Sivuston käyttöliittymän ja käyttökokemuksen suunnitteluun käytetään paljon aikaa, vaivaa ja rahaa, mutta sivuston todellinen arvo vesittyy huonon sisällön takia.
  • Sivuston ulkoasu suunnitellaan lorem ipsumin avulla, vaikka sisällön merkityksellä olisi aivan yhtä paljon merkitystä kuin sillä, miltä sanat näyttävät. Lisähaastetta tuo suomen kieli, joka pitkine sanoineen ei pahimmassa tapauksessa edes mahdu sille varattuun tilaan.
  • Sivuston rakenteen suunnittelusta vastaa usein graafikko, joka saattaa (kärjistetyssä tilanteessa) varata leiskassa paikan tärkeälle nostolle ja asiakas pohtii, millä tämänkin paikan täyttäisi – eikö prosessin kuuluisi mennä toisin päin?
  • Asiakas haluaa kirjoittaa sisällön itse, vaikkei välttämättä tajua verkkoon kirjoittamisesta riittävästi tuottaakseen hyvää tekstiä. Asiakkaat (tai asiakkaan esimiehet) eivät myöskään usein ymmärrä kirjoitustyön vaatimaa aikaa, ja sisältö kirjoitetaan kaiken muun työn ohessa deadlinen painaessa päälle.
  • Sivustojen julkaisu myöhästyy sisällöntuotannon myöhästymisen takia.
  • Sivuston sisältö on ajantasalla (hyvässä tapauksessa) julkaisun aikaan, mutta kuolee myöhemmin, koska kukaan ei päivitä sitä aktiivisesti.

Sisältöstrategia asettuu sanana buzzword-hierarkiassa jonnekin käyttökokemuksen alahaaraksi, verkkokirjoittamisen laajennukseksi, interaktiosuunnittelun ja informaatiotieteiden välimaastoon.

Sisältöstrategia pyrkii kuvaamaan ja ohjeistamaan toimituksellisen sisällön tuotantoprosessia asettamalla tavoitteet siitä, mistä kirjoitetaan, miten ja kenelle. Tarkkaa käytännön rajausta on tuskin mahdollista tai järkevääkään tehdä. Joissain tapauksissa sisältöstrategian alle on sijoitettu myös muun muassa hakukoneoptimointi, metadatamalli ja muun muassa sisällön julkaisemisen workflow.

Diplomityössäni kehitteillä olevassa verkkopalveluiden määrittelymallissa on sisällöntuotantoprosessien suunnittelulle ja kuvaamiselle annettu paljon painoarvoa. Ajatuksena on yksinkertaistettuna, että käyttäjiltä tulevien tarpeiden ja asiakkaan liiketoiminta- ja muiden tavoitteiden pohjalta muodostetaan ajatus siitä, millaisia toimintoja ja sisältöjä sivulla halutaan näyttää, mutta samalla toimintojen toteutusmahdollisuuksia arvioidaan realistisesti asiakkaan resurssien (sisällöntuottajat, raha) valossa.

Tavoitteena on siis tuoda käyttökokemuksen, käyttöliittymän ja sisällön suunnittelu maanläheisemmälle tasolle: “Haluatte blogin, koska kilpailijoillakin on? OK, onko blogille kirjoittajia, jotka varmistavat säännöllisen, viikottaisen sisältövirran – käsi sydämelle!”. Tämä saattaa kuulostaa insinöörimäiseltä inhorealismilta, itse käyttäisin mielummin termiä terve maalaisjärki.

Asiakkaan sisällöntuotantoresurssit ovat rajalliset, ne kannattaa käyttää toimintoihin, jotka ovat oikeasti merkityksellisiä asiakkaalle ja tuovat arvoa käyttäjille.

Diplomityöni yhtenä tärkeänä tavoitteena on tuoda sisällöntuotantoprosessien pohtiminen mukaan määrittelyprosessiin alusta alkaen – liippaa siis läheltä sisältöstrategiaa. Itse en ole mikään suuri “strategia”-sanojen fani, mutta paremman termin puutteessa kelvatkoon – oikealla asialla kuitenkin ollaan.

Konseptisuunnittelija-titteli hautaan

Minua on pitkään nyppinyt konsepti-johdannaisten sanojen epämääräisyys – konsepti, konseptisuunnitelma, konseptisuunnittelija. Ainakin verkkopalveluiden suunnittelun kontekstissa on vaikea antaa yleispätevää (saatika maallikolle selitettävissä olevaa) kuvausta sanoille.

En ole ainut, jota sanojen epämääräisyys häiritsee. Aiheesta on kirjoitettu myös lopputyö TAIK:ssa.

Monissa suomalaisissa verkkopalveluita suunnittelevissa yrityksissä tuntuu sivuston suunnittelussa yleensä olevan mukana henkilö tittelillä konseptisuunnittelija. Tämä henkilö vastaa projekteissa käsittääkseni ainakin suunnittelun alkuvaiheen ideoinnista ja monissa tapauksissa myös laajemmin palvelun informaatioarkkitehtuurin, käyttökokemuksen ja jopa käyttöliittymän suunnittelusta.

Maailmalla taas sanaa tunnutaan käyttävän vähemmän. Google löytää Suomesta 20 000 konseptisuunnittelijaa, mutta maailmalta vain reilut 100 000 concept designeria (myönnetään ei kovin tieteellinen testi, mutta kertonee jotain jotain).

Konkreettisesti törmäsin konseptijohdannaisten sanojen käytön problematiikkaan diplomityöni myötä. Alustavan otsikkoni loppupuoli meni osapuilleen seuraavasti “Käyttäjälähtöinen konseptisuunnittelu sujuvan projektityön ohjaajana”. Tarkemmin asioita pyöriteltyäni “konseptisuunnittelu”-sana on ruvennut kuitenkin vaikuttamaan vain pieneltä osalta koko verkkopalvelun määrittelyprosessia. Otsikko vaatii siis työtä.

Itse koen sanan konsepti tarkoittavan sivuston perimmäistä ideaa sisältäen tapauskohtaisesti mm. sivuston vision, positioinnin, kohderyhmät, sisältöteemat ja erilaiset liiketoiminta- ja muut tavoitteet. Konsepti ei mielestäni sisällä yksityiskohtaista listausta sivuston toiminnoista, käyttöliittymäkuvauksia tai visuaalista ilmettä.

Omassa mallissani konsepti kumpuaa ympäristöstä, jossa sivusto tulee toimimaan, Internetin ja asiakkaan alan trendeistä, asiakkaan arvomaailmasta ja liiketoimintatavoitteista. Hyvän konseptin tulisi pystyä perustelemaan sivuston olemassaolo muutaman kappaleen mittaisella kuvauksella. Hyvä konsepti on myös muodostettu yhteisymmärryksessä asiakkaan ja toimittajan välillä ja se on tahtotila, joka ohjaa muun sivuston suunnittelua.

Konsepti realisoituu käsin kosketeltavaksi verkkopalveluksi toimintojen, käyttöliittymän ja visun välityksellä. Huolellisesti mietitty konsepti auttaa myös sivuston rajaamisessa. Kaiken sivustolta löytyvän materiaalin pitäisi kummuta konseptista – jos toiminto ei palvele konseptia, ei sen olemassaololle ole periaatteessa mitään perusteita.

Vaikka konseptin suunnittelu sijoittuukin luonnollisesti suunnittelun alkuvaiheeseen, pitää hyvän konseptin mielestäni voida kuitenkin joustaa sivuston suunnittelun (ja toteutuksen) edetessä ja ideoiden kypsyessä. Siksi onkin hassua, että konseptisuunnittelija perinteisesti luopuu leikistä siinä vaiheessa, kun projekti siirtyy toteutusvaiheeseen.

Konsepti on tärkeä osa verkkopalvelua, mutta mielestäni kuitenkin vain pieni osa suunnittelua. Tämän määritelmän mukaisen konseptin suunnitteluun ei ole mielestäni mitään järkeä omistaa omaa ammattinimikettään – sanan konseptisuunnittelija voisi siis mielestäni haudata ja korvata jollain paremmin nykyisten konseptisuunnittelijoiden työnkuvaa kuvaavalla tittelillä.

Se, mikä tämä uusi titteli pitäisi olla, onkin sitten toinen kysymys.

Maailmalla tunnutaan käyttävän jonkin verran titteliä Lead Designer (760 000 hittiä). Sana on mielestäni hyvä sen takia, että se sisältää sekä Web Designer, että Software Designer -sanojen loppuosan, eli tittelillä työskentelevän ihmisen voisi ajatella ottavan huomioon molemmat puolet (olettaen, että verkkopalveluiden koodipuolen ja HTML+CSS-puolen toteuttaa eri ihmiset, kuten meillä).

Toinen variaatio sanasta on “Chief Designer”, joka oli käytössä tietääkseni ainakin vielä vanhassa Satamassa ja Googlen mukaan yhtä suosittu kuin Lead Designer. Molemmat sanat kuvaavat mielestäni tehtäväkentän hyvin.

Olennaista mielestäni olisi, että Lead/Chief Designer olisi mukana koko projektin elinkaaren ajan ylläpitämässä sivuston konseptia ja huolehtimassa sivuston ylläpidosta. Monet verkkopalvelut suunnitellaan alunperin huolellisesti, mutta kuolevat joko sen takia, ettei jatkokehitykseen ymmärretä panostaa tai jatkokehitystä tehdään ilman selkeää suunnitelmaa tai tavoitteita.

Myöskään “määrittely” ei kuulu lempisanastooni johtuen kaikesta sitä vaivaavasta painolastista. Tähän olisikin kiva keksiä joku parempi sana.

Kommenttiosuuteen saa ehdottaa.

GUIDe-menetelmä ja web-kehitys

GUIDe (Goals – User Interface Design – Implementation) on Interacta Design Oy:ssä kehitetty prosessimalli käyttötapauslähtöiseen käyttöliittymäsuunnitteluun. Menetelmä pyrkii varmistamaan tarkoituksenmukaisen käyttöliittymän syntymisen siirtämällä käyttöliittymäsuunnitteluvaihe määrittelyvaiheen alkuun ja muodostamalla käyttöliittymä systemaattisesti käyttötapausten avulla.

Prosessi menee seuraavasti:

  1. Käyttötapaukset: Seurataan käyttäjien oikeaa toimintaa (tai simuloidaan sitä). Muodostetaan tavoitepohjaiset käyttötapaukset (goal-based use cases) toiminnan pohjalta.
  2. Käyttöliittymäsuunnittelu: Hahmotellaan käyttöliittymä yksi käyttötapaus kerrallaan ja lisätään käyttöliittymään vain elementtejä, jotka ovat käyttötapausten kannalta olennaisia (simulointipohjainen käyttöliittymäsuunnittelu (Goal-Derived Design, GDD)
  3. Testaus: Kaikki toiminnot sisältävä käyttöliittymä testataan oikeiden käyttäjien avulla joko käytettävyystestien tai läpikäyntien (walkthroughs) avulla. Tehdään kokemusten perusteella tarvittaessa muutoksia, eli palataan edelliseen vaiheeseen (iteratiivinen käyttöliittymäsuunnittelu).
  4. Käyttöliittymäspeksi: Valmis käyttöliittymä dokumentoidaan speksiksi, jossa on periaatteessa kaikki näkymät piirretty lopulliseen muotoonsa. Speksi pyrkii siis kuvaamaan miltä suunniteltu käyttöliittymä näyttää ja miten se toimii. Hyötynä on
  5. Toteutus: Valmis käyttöliittymä toteutetaan joko vesiputousmallin mukaisesti yhdessä klimpissä tai ketterämmin toimintokokonaisuus kerrallaan.

Menetelmä on kuulemma saanut jonkinverran kritiikkiä ketterien kehitysmenetelmien kannattajilta, koska se periaatteessa pyrkii siirtämään kaiken suunnittelun projektin alkuun, sen sijaan, että toiminnallisuuksia suunniteltaisiin ja toteutettaisiin pienemmissä ja helpommin hallittavissa osissa.

Menetelmä on myös käytössä Reaktor Innovationsilla, jossa yksi GUIDe:n kehittäjistäkin nykyisin vaikuttaa. Reaktorin artikkelin suositusten mukaan kannattaa pienet käyttöliittymät suunnitella kokonaan yhdellä istumalla ja laajemmat pyrkiä suunnittelemaan karkealla tasolla siten, että käyttöliittymän kokonaisrakenne saadaan selville. Yksittäiset osakokonaisuudet voidaan tämän jälkeen suunnitella ja toteuttaa yksi kerrallaan ketterästi esimerkiksi Scrum-menetelmää noudattaen.

Soveltaminen verkkokehitykseen

Menetelmä toimii varmasti perinteisessä softakehityksessä loistavasti. Verkkokehitykseen soveltaminen perinteisessä toimittaja-asiakas-loppukäyttäjä-asetelmassa vaatii jo enemmän mielikuvitusta.

Sisällöllisesti rikkaissa ja toiminnallisesti köyhissä verkkopalveluissa käyttöliittymä on usein aika pienessä roolissa. Sivuston yleinen käyttöliittymä (navigaatio, hakutoiminnot, …) pitää toki suunnitella, mutta ok-lopputulokseen päästään usein maalaisjärjellä ja konventioita noudattamalla. Sisältöorientoituneella sivustolla käyttäjien tarpeet liittyvät usein jonkin tietyn tiedon löytämiseen ja sikäli niiden simuloiminen ei luultavasti tuota ei-triviaalia tietoa.

Sinänsä menetelmään sisältyvä less-is-more -ajatus voisi olla hedelmällinen myös sivuston sisällön miettimiseen. Periaatteessahan sivustolla on turha kertoa asioista, joista loppukäyttäjät eivät ole kiinnostuneet. Turhan sisällön lisääminen sivustolle vaikeuttaa olennaisen löytämistä ja lisää sisällön ylläpitämiseksi tehtävää työtä.

Menetelmä on nimenomaisesti käyttäjälähtöinen ja sen soveltaminen edellyttäisi aitoa kontaktia tuotteen loppukäyttäjiin. Kuitenkin suurelle yleisölle tehtävää verkkokehitystä joudutaan usein tekemään ainakin osittain side silmillä, kun loppukäyttäjistä ja heidän tarpeistaan tiedetään oikeastaan vain se, mitä asiakas osaa kertoa.

Tilanne olisi korjattavissa, jos toimittajalla olisi paukkuja ottaa loppukäyttäjä (asiakkaan asiakas) mukaan suunnitteluprosessiin. Tämä vaatisi tosin osaamista ja rahallisia panoksia ja näin ollen perustelutyötä asiakkaan suuntaan. Tilannetta ei helpota se, että asiakas usein luulee tietävänsä omat asiakkaansa todellisuutta paremmin. Optimaalisessa tilanteessa asiakas ymmärtää asiakkaansa hyvin, mutta ei tajua verkkokehityksen lainalaisuuksista tai ihmisten verkkokäyttäytymisestä riittävästi tajutakseen, mitä loppukäyttäjät verkossa tarvitsevat.

Tilanne on tietysti täysin erilainen, jos ollaan tekemässä toiminnallista verkkosivustoa tai esimerkiksi siirtämään olemassaolevan työpöytäsovelluksen toimintoja verkkoon. Tällöin luulisi käyttöliittymäsuunnittelun olevan automaattisesti iso osa projektia, mutta reaalimaailmassa ei tämäkään aina ihan toteudu…

Innovointimenetelmiä

Turkulainen Stratox Oy listaa sivuillaan kasan erilaisia innovointimenetelmiä, jotka vaikuttavat pikaisella vilkaisulla ainakin lukemisen arvoisilta. Menetelmistä osalla lienee jotain teoriaa takanaan, osa taas on omia kehitelmiä. Yritys näyttäisi olevan Heikki Nummelinin yhden miehen show, mutta ilmeisesti (lue: nettisivujen perusteella) kaverilla on pitkä ja laaja kokemus erilaisten ideointiworkshoppien pitämisestä.

Kalanruoto- ja Heiluri-nimisten menetelmien soveltamisessa lienee haasteena lähinnä se, ettei homma mene jo konseptitasolla ihan häröilyksi. Itsekin olen ehdottomasti systemaattisten ja tuotteistettujen menetelmien kannalla (mikä tahansa menetelmä tuo varmasti hyvin läpi vietynä parempia tuloksia kuin vapaa demokratiaan perustuva säätäminen), mutta ideoiden myymisessä ja uskottavassa läpiviennissä on varmasti haasteita.

Jos kyseessä on esimerkiksi TBWA\:n Disruption-menetelmä, on homma varmasti helposti myytävissä, kun menetelmän tueksi voi esittää menestystarinoita kymmenistä maista ympäri maailmaa. Enemmän haastetta on, jos esimerkiksi IT-talo päättää lähteä kehittämää omaa luovaa menetelmäänsä, jonka toimivuudesta ei oikeastaan aluksi ole mitään takeita.

Olisi siis kiva löytää oman menetelmän pohjaksi joku hyväksi havaittu, vapaasti käytettävissä oleva menetelmä – eipä myöskään haittaisi vaikka menetelmän tehosta olisi jonkinlaista tieteellistä näyttöä…

Palvelumuotoilu Design Management Review:ssa

Design Management Review omistaa palvelumuotoilulle koko talvinumeronsa.

Thomas Walton kuvaa artikkelissaan It’s All About Service IDEO:n innovointiprosessia:

The first steps involve the ability to be expansive and “letting go of reality.” Once this yields a rich portfolio of promising ideas, the IDEO framework shirts gears toward prototyping and rigorous testing. This also involves gathering market insights on customers, the business in general, and current technology. These are thorough, nuance-rich explorations that reveal opportunities for growth and genuinely innovative ways to meet needs. Next, corporate leaders and front-line personnel collaborate to model new service propositions that, in a third stage, are on the cutting-edge and evaluated for desirability, viability, and economic feasibility. In the last two phases of this effort, metrics are devised to appraise success and time, and resources are allocated to fail and retool. This involves releasing a pilot and running it through its paces. Refinements are made and, finally, plans for a large-scale rollout are carefully plotted.

Samassa artikkelissa kirjoittaja kertoo Molecular-nimiselle yritykselle työskentelevän Brian Gillespien suosituksia Internet-palveluiden inkrementaaliseen suunnitteluun:

He stresses the advantages of building sites incrementally rather than all at once. Providing well-organized information can attract and help retain customers, while more-complex international transactional capabilities such as e-commerce, contact options, and an extranet can be added later. Irrespective of this possibility, all sites should embody the brand and engage the spectrum of customer profiles. Research is fundamental to determining these profiles, as well as variations in consumer needs and desires.

Eli tehdään perustyö huolellisesti, mietitään kohderyhmät ja viestinnälliset asiat jo ensi vaiheessa, mutta ei pyritä toteuttamaan sivustoa koko laajuudessaan yhdeltä istumalta.

Samansuuntaisia ajatuksia on pyöritelty myös töissä, ja tuntuisi, että jonkinlainen yhdistelmä perusasioiden huolellista määrittelyä ja toteutuksen ketteryyttä voisi tuoda fiksuja tuloksia nopeasti ja kustannustehokkaasti. Varsinaisia teknisiä esteitähän perussivuston nopeallekin toteutukselle ei juuri nykypäivänä ole (tai ainakaan pitäisi olla), kun käytössä on pitkälle kehitettyjä julkaisujärjestelmiä.

Täytyypä perehtyä lehden tarjontaan paremmin paremmalla ajalla…

[via Design for Service]

Engine Service Designin prosessi

Lontoolainen Engine Service Design jakaa palvelumuotoiluprosessinsa avoimesti nettisivullaan. Pikaisella vilkaisulla näyttää varsin tuotteistetulta kuvaukselta, joka antaa yrityksestä ensi silmäyksellä hyvän fiiliksen.

Töissä olemme jonkin verran jutelleet siitä, miten paljon yrityksen omista prosesseista on turvallista / järkevää / tarkoituksenmukaista kertoa nettisivulla.

Oma mielipiteeni asiaan on, että pelkkien prosessikuvausten perusteella ei prosessia kopioida vaan loppukädessä suojeltavaa on ihmisissä, jotka ovat vastuussa prosessin läpi viemisestä omalla ammattitaidollaan.

Ainakin minulle hyvä prosessikuvaus antaa yrityksestä fiksun kuvan:

  • Yrityksen toiminta on läpinäkyvää, kun prosessista kerrotaan avoimesti.
  • Yritys on toiminnassaan edistyksellinen ja haluaa jakaa tietämystään myös muille parantaakseen alan toimintaa.
  • Vaikka malli koostuisikin lähinnä itsestäänselvyyksistä, näyttää homma silti hallitummalta, kun toiminta puetaan systemaattiseen prosessikuvaukseen.