Mistä hyvä suunnittelu oikeastaan alkaa?
Edellisissä osissa päädyimme tärkeään johtopäätökseen – emme suunnittele sivua pelkästään siksi, että yritys haluaa "uuden sivun".
Suunnittelemme työkalua, jonka tehtävä on ratkaista tietty ongelma.
Joskus ongelma on heikko myynti. Joskus liian vähäiset yhteydenotot. Joskus asiakkaat eivät löydä tietoa. Toisinaan myyjät vastaavat joka päivä samoihin kysymyksiin, koska sivusto ei välitä perusinformaatiota. Voi myös olla, että yritys on kasvanut ja aiempi palvelu ei enää vastaa todellista laajuutta.
Siksi ensimmäinen vaihe ei saisi olla Photoshop, Figma tai jonkin frameworkin valinta.
Ensimmäisenä vaiheena pitäisi olla keskustelu.
Tutustumme ensin liiketoimintaan
Hyvän UX-suunnittelijan ei tarvitse olla alan ekspertti joka kerta. Hänen täytyy kuitenkin ymmärtää asiakkaan liiketoimintaa riittävän hyvin tietääkseen, mitä ongelmia ratkaistaan.
Siksi kysymme asioita, jotka aluksi voivat vaikuttaa suunnitteluun liittymättömiltä;
- Mistä asiakkaat tulevat?
- Miksi he valitsevat juuri tämän yrityksen?
- Miksi he lähtevät?
- Mitä he yleensä kysyvät ennen ostopäätöstä?
- Miltä myyntiprosessi näyttää?
- Kuka vastaa yhteydenotoista?
- Mitä tapahtuu liidille lomakkeen lähettämisen jälkeen?
- Mitkä tuotteet ovat tärkeimpiä?
- Millä palveluilla on suurin potentiaali?
- Haluuko yritys lisätä yhteydenottojen määrää, tilausten arvoa, asiakasmäärää vai ennen kaikkea parantaa imagoaan?
Vasta nämä kysymykset auttavat määrittämään, mitä meidän pitäisi oikeastaan suunnitella.
Discovery – ennen ensimmäistä luonnosta
Digiprojekteissa käytetään usein termiä Discovery.
Se on vaihe, jossa tutkitaan ongelmaa, käyttäjiä, liiketoimintatavoitteita, rajoituksia ja teknisiä mahdollisuuksia ennen varsinaisen suunnittelun ja kehityksen aloittamista.
Tämä ei ole "tyhjänäikänä ennen työn aloittamista". Hyvin johdetussa projektissa Discovery rajoittaa riskiä rakentaa jotain, joka näyttää hyvältä mutta ei ratkaise todellista ongelmaa.
Saatamme esimerkiksi löytää, että asiakas ei oikeastaan tarvitse uutta sivustoa.
Ehkä hän tarvitsee paremman tiedonarkkitehtuurin.
Tai ostoprosessin yksinkertaistamisen.
Tai integraation CRM:ään.
Tai yhteydenottojen automatisoinnin.
Tai täysin toisenlaisen tavan esitellä tarjontaa.
Siksi joskus kannattaa pysähtyä ennen tuotannon aloittamista.
UX ei ala ulkonäöstä
UX eli User Experience tarkoittaa käyttäjän kokemusta tuotteen tai palvelun käytön aikana.
Verkkosivun kohdalla se kattaa paljon muutakin kuin käyttöliittymän ulkonäön.
Se on myös:
- sivulla liikkumisen tapa,
- helppous löytää tietoa,
- viestinnän ymmärrettävyys,
- ostoprosessi,
- lomakkeet,
- sisällön hierarkia,
- tehtävien nopeus,
- järjestelmän reagointi käyttäjän toimintoihin,
- saavutettavuus,
- turvallisuuden ja luottamuksen tunne.
Siksi UX alkaa jo ennen ensimmäisen ruudun piirtämistä.
Ensin pitää ymmärtää, mitä käyttäjä yrittää saavuttaa.
User Flow – miten käyttäjä pääsee tavoitteeseen?
Yksi UX-suunnittelun perusvälineistä on User Flow. Se kuvaa polun, jonka käyttäjä kulkee suorittaakseen tietyn tehtävän.
Esimerkiksi verkkokaupassa se voi olla: mainos → tuotteen sivu → variantin valinta → ostoskori → toimitus → maksu → tilausvahvistus.
Palveluyrityksessä: Google → palvelusivu → referenssit → suositukset → lomake → yhteydenotto myyjältä.
Valmistajalla: hakukone → tuote → tekniset tiedot → dokumentaatio → tarjouspyyntö.
Jokainen polku vaatii erilaisia suunnitteluratkaisuja.
Jos käyttäjän tärkein tavoite on osto, emme voi pakottaa häntä lukemaan kymmentä näyttöä tekstiä. Jos taas tuote on kallis ja monimutkainen ja vaatii konsultointia, liian nopea lomakkeelle ohjaaminen voi olla huono ratkaisu.
UX:ssa on muun muassa kyse oikeanlaisen ohjauksen tasapainon löytämisestä.
Wireframe – ennen kuin "kaunistamme"
Seuraava vaihe voi olla wireframe, eli yksinkertaistettu ruutukaavio, joka näyttää sisällön ja toimintojen asettelun.
Wireframen ei tarvitse olla kaunis. Eikä sen kuulu. Tässä vaiheessa ei ratkaista, onko napin väri oikea.
Kyse on vastaamisesta kysymyksiin:
- Mitä käyttäjä näkee ensimmäisenä?
- Mikä on tärkeintä?
- Mikä tulisi sijoittaa ylemmäksi?
- Minne sijoitamme lisätiedot?
- Miten käyttäjä etenee seuraavaan vaiheeseen?
- Mitä tapahtuu napin klikkauksen jälkeen?
Se on vähän kuin asunnon suunnittelua.
Ensin määritämme seinät, ovet ja huoneet. Vasta myöhemmin mietimme seinien väriä.
Design system – jotta projekti ei olisi sattumanvaraisten elementtien liitto
Suuremmissa projekteissa esiin nousee tärkeä osa – Design System.
Se on järjestelmällinen kokoelma sääntöjä, komponentteja ja malleja, jotka määrittelevät käyttöliittymän rakentamisen tavan.
Siihen voi kuulua muun muassa:
- värit,
- typografia,
- painikkeet,
- lomakkeet,
- kortit,
- taulukot,
- viestit,
- ikonit,
- välit,
- responsiivisuuden säännöt,
- komponenttien käyttäytyminen.
Miksi? – Jotta käyttöliittymä olisi johdonmukainen.
Jos samalla sivulla painike toimii yhdellä tavalla ja toisella sivulla täysin eri tavalla, käyttäjän on opetettava käyttöliittymä uudelleen joka kerta.
Design System auttaa myös kehitystiimiä. Sen sijaan, että rakentaisivat komponentin joka kerta alusta, he voivat käyttää valmiiksi määriteltyjä elementtejä.
Se johtaa suurempaan yhtenäisyyteen, helpompaan kehitykseen ja usein myös alhaisempiin ylläpitokustannuksiin.
Missä vaiheessa teknologia tulee mukaan?
Teknologian tulisi tulla mukaan oikeaan aikaan, mutta sen ei pitäisi määrätä koko projektia. Tämä on tärkeä ero.
Suunnittelija voi keksiä loistavan ominaisuuden, jolla on liiketoimintalogiikkaa. Kehittäjä voi kuitenkin huomata, että sen toteuttaminen olisi hyvin kallista tai aiheuttaisi suorituskykyongelmia.
Toisaalta kehittäjä voi ehdottaa teknistä ratkaisua, joka on helppo toteuttaa, mutta ei käyttäjän näkökulmasta ratkaise ongelmaa riittävän hyvin.
Siksi parhaat projektit syntyvät, kun UX, design, kehitys ja liiketoiminta keskustelevat yhdessä alusta alkaen.
Ei niin, että "ensin suunnittelijat, sitten kehittäjät".
Vaan: "Pohdimme yhdessä, miten ongelma ratkaistaan parhaiten".
Teknologiaa ei pitäisi valita vain siksi, että se on muodikasta
React, Vue, Next.js, Laravel, Symfony, .NET, WordPress, headless CMS, native-sovellus, PWA... Teknologioita on pitkä lista.
Mutta asiakas ei osta teknologiaa. Hän ostaa ratkaisun.
Siksi kysymys: "Mitä frameworkia käytämme?"
on usein vähemmän tärkeä kuin: "Mitä ongelmia järjestelmän tulee ratkaista?" Vasta sen jälkeen voidaan valita sopiva arkkitehtuuri.
Yksinkertainen yrityssivu tarvitsee erilaista teknologiaa kuin verkkokauppa, joka käsittelee tuhansia tilauksia, ja taas erilaista kuin B2B-alusta, jossa on laajat integraatiot ja käyttäjäkohtaiset käyttöoikeudet.
Teknologian tulisi seurata vaatimuksista, ei vaatimuksen seurata teknologiaa.
Backend, frontend ja se osa, mitä käyttäjä ei näe
On myös hyvä muistaa, että verkkosivu ei ole vain se, mitä näemme selaimessa.
Frontend vastaa siitä osasta sovellusta, jonka kanssa käyttäjä suoraan on vuorovaikutuksessa.
Backend vastaa palvelinpuolen logiikasta – datan käsittelystä, tietokantayhteyksistä, prosessien hallinnasta ja integraatioista.
Ja niiden välissä on usein paljon muita elementtejä;
- CRM.
- ERP.
- Maksujärjestelmä.
- Sähköpostialusta.
- Varastonhallinta.
- API.
- Analytiikka.
- Automaatio.
- Asiakaspalvelujärjestelmä.
Jos suunnittelemme uutta sivustoa ottamatta tätä ekosysteemiä huomioon, voimme luoda kauniin front-endin, joka toimii kuin erillinen saari.
Mutta tavoitteen pitäisi olla jotain aivan muuta.
Hyvä sivu voi tehdä paljon muutakin kuin "vain kerätä lomakkeita"
Moderni verkkosivu voi olla osa laajempaa liiketoimintaprosessia;
- Käyttäjä lähettää kyselyn.
- Järjestelmä tunnistaa sen aiheen.
- Liidi menee CRM:ään.
- Myyjä saa ilmoituksen.
- Asiakas saa automaattisen vahvistuksen.
- Tiedot luokitellaan oikeaan kategoriaan.
- Järjestelmä voi tarkistaa tuotteen saatavuuden.
- Se voi valmistella myyjälle tarvittavat tiedot.
- Se voi käynnistää tietyn työnkulun.
Verkkokaupassa tilaus voi edetä automaattisesti seuraavien vaiheiden läpi. B2B-tilanteessa asiakkaalla voi olla pääsy yksilöllisiin hintoihin, dokumentteihin ja tilaushistoriaan.
Silloin sivu ei ole enää vain "käyntikortti". Siitä tulee osa liiketoiminnan infrastruktuuria.
Entä AI?
Myös tekoäly voi olla osa tällaista järjestelmää. Mutta taas – sitä ei pitäisi lisätä vain siksi, että "kaikilla on nyt AI".
Jos chatbot ei ratkaise mitään todellista ongelmaa, siitä tulee vain lisää ikkunaa sivulle.
Jos taas käyttäjä voi tekoälyn avulla löytää oikean tuotteen nopeammin, konfiguroida palvelun, saada vastauksen kysymykseen tai käydä läpi valintaprosessin, teknologialla on perustelu.
Sama pätee personointiin.
Voimme näyttää käyttäjälle eri sisältöjä sen mukaan, miten hän käyttäytyy, mistä hän tuli tai missä ostoprosessin vaiheessa hän on. Voimme analysoida dataa ja ennakoida asiakkaiden tarpeita paremmin.
Mutta meidän pitäisi aina aloittaa kysymyksellä: "Mitä ongelmaa ratkaistaan?"
Vasta sitten: "Onko AI paras tapa ratkaista se?"
Testaamme enemmän kuin pelkän toimivuuden
Yksi yleisimmistä virheistä on testata sivua vasta lopussa. Silloin paljastuu, että lomake on liian pitkä, ostoprosessi epäintuitiivinen tai käyttäjä ei löydä tärkeintä tietoa.
Mitä myöhemmin löydämme ongelman, sitä kalliimpi on sen korjaus.
Siksi kannattaa testata vaiheittain. Voimme testata prototyyppiä. Voimme havainnoida käyttäjien käyttäytymistä. Voimme tehdä käytettävyystestejä. Voimme analysoida Google Analyticsin tai muiden analytiikkatyökalujen dataa. Voimme käyttää sessiotallenteita tai lämpökarttoja, jos ne on otettu käyttöön tietosuositusten mukaisesti. Voimme myös yksinkertaisesti keskustella myyjien kanssa.
Viimeksi mainittua aliarvioidaan usein.
Myyjä kuulee päivittäin asiakkaiden kysymyksiä; hän tietää, mitä he eivät ymmärrä. Hän tietää, mitä he pelkäävät. Hän tietää, mitä tietoja täytyy antaa ennen ostopäätöstä.
Se on valtava suunnittelutieto.
MVP ei tarkoita mitä tahansa
Digiprojekteissa käytetään usein käsitettä MVP – Minimum Viable Product.
Tarkoitetaan tuotteen ensimmäistä versiota, joka sisältää minimitoiminnallisuuden oletusten tarkistamiseksi ja arvon tuottamiseksi käyttäjille.
MVP ei tarkoita: "Tehdään jotain hutaisten ja katsotaan myöhemmin".
Hyvän MVP:n pitäisi vastata kysymykseen: "Mikä on pienin versio ratkaisusta, jolla voimme testata suuntaa?"
Tämä on tärkeää myös verkkosivuille ja sovelluksille.
Sen sijaan, että rakennamme heti kolmekymmentä ominaisuutta, joskus on parempi julkaista viisi tärkeintä ja katsoa, miten käyttäjät niitä käyttävät. Sitten kehitämme järjestelmää todellisten datan perusteella, ei pelkästään ensimmäisen tapaamisen oletusten pohjalta.
Sivu ei lopu julkaisupäivään
Tämä on toinen usein unohdettu seikka.
Julkaisupäivä on itse asiassa sivun todellisen elämän alku. Vasta silloin tulee todellisia käyttäjiä. Vasta silloin näemme, mitkä sisällöt toimivat. Vasta silloin tiedämme, mitkä elementit jäävät huomiotta. Vasta silloin voimme tarkistaa, ovatko yhteydenottojen määrä, myynti, sivulla vietetty aika tai muut aiemmin määritellyt mittarit nousseet.
Siksi projektia tulisi kehittää jatkuvasti;
- Analyysi.
- Johtopäätökset.
- Muutos.
- Testi.
- Uusi analyysi.
Se muistuttaa enemmän sykliä kuin kertaluonteista tapahtumaa.
Mitä oikeastaan pitäisi mitata?
Se riippuu projektin tavoitteesta.
Verkkokaupalle se voi olla:
- konversioaste,
- keskimääräinen tilauksen arvo,
- ostoskorin hylkäämiset,
- liikevaihto,
- asiakkaan elinkaariarvo.
Palveluyritykselle:
- arvokkaiden liidien määrä,
- lomakkeen konversioprosentti,
- sovitut konsultoinnit,
- liidin hankintakustannus,
- yhteydenottojen laatu.
Uutissivustolle:
- tietyn tiedon löytäminen,
- käyttäjien sitoutuminen,
- palautuvien käyttäjien määrä,
- materiaalien lataukset.
Kaikkea ei tarvitse mitata. Mutta täytyy tietää, mikä on tärkeää.
Sillä jos yritys haluaa lisätä arvokkaiden yhteydenottojen määrää, pelkkä liikenteen kasvattaminen ei välttämättä ole menestys. Voimme saada kymmenkertaisen kävijämäärän emmekä yhtään uutta asiakasta.
Suurin virhe? Suunnittelu ilman vastausta kysymykseen "miksi?"
Voidaan luoda visuaalisesti upea sivusto.
Voidaan käyttää modernia teknologiakokonaisuutta.
Voidaan tehdä täydelliset animaatiot.
Voidaan huolehtia jokaisesta pikselistä.
Ja silti projekti ei välttämättä tuota yritykselle odotettuja tuloksia. Miksi?
Koska puuttui vastaus kaikkein tärkeimpään kysymykseen: Miksi teemme kaiken tämän?
Jos vastaus on: "Koska vanha sivu on ruma",
se on aika vähän.
Jos taas vastaus kuuluu: "Haluamme lisätä B2B-asiakkaiden yhteydenottoja, lyhentää polkua oikean palvelun löytymiseen ja keventää myynnin kuormaa toistuvista kysymyksistä",
meillä on yhtäkkiä konkreettinen ongelma ratkaistavana.
Ja voimme suunnitella ratkaisun.
Web24:ssä emme halua vain luovuttaa sivuja
Se on ero toimeksiannon suorittamisen ja teknologisen yhteistyön välillä.
Jos asiakas tulee konkreettisen idean kanssa, se ei tarkoita, että tehtävämme on toteuttaa se refleksiivisesti.
Tehtävämme on myös sanoa: "Tämä on järkevää".
Tai: "Tämän voi tehdä paremmin".
Tai: "Teknisesti voimme rakentaa tämän, mutta emme näe liiketoiminnallista perustetta".
Tai: "Ennen kuin teemme tämän, tarkistamme, tarvitsevatko käyttäjät sitä todella".
Joskus paras suunnitteluratkaisu on lisätä ominaisuus. Joskus poistaa se. Joskus muuttaa koko lähtöoletusta.
Ja juuri siinä tiimin kokemus näkyy – ei siinä, että voimme rakentaa kaiken, vaan siinä, että tunnistamme, mitä todella kannattaa rakentaa.
Ei ole kahta samanlaista projektia
Palataan takaisin lähtökohtaan.
Voimme olla kahden saman alan asiakkaan kanssa. Kaksi valmistajaa. Kaksi kauppaa. Kaksi asianajotoimistoa. Kaksi softataloa.
Niiden sivut voivat näyttää samankaltaisilta. Mutta niiden ei pitäisi olla samoja vain siksi, että ne toimivat samassa kategoriassa.
Koska heitä erottavat ihmiset. Strategia. Myyntiprosessi. Tarjonta. Budjetti. Teknologia. Asiakkaat. Tavoitteet.
Siksi jokainen projekti vaatii omat päätöksensä.
Ei aina näyttäviä. Ei aina mullistavia. Mutta tietoisia.
Verkkosivu työkaluna, ei koristeena
Hyvin suunnitellun sivun tulisi olla yritykselle enemmän kuin digitaalinen käyntikortti.
Sen pitäisi auttaa käyttäjää tekemään päätös. Sen pitäisi helpottaa myyntiä. Sen pitäisi vastata kysymyksiin. Sen pitäisi rakentaa luottamusta. Sen pitäisi tukea työntekijöitä. Sen pitäisi integroitua muihin järjestelmiin siellä, missä se on järkevää.
Ja ennen kaikkea sen pitäisi toteuttaa konkreettista liiketoiminnallista tavoitetta.
Siksi ei ole yhtä ainoaa vastausta kysymykseen: "Miltä hyvä verkkosivu näyttää?"
Parempi kysymys on: "Miten tämän tietyn yrityksen sivun pitäisi toimia, jotta se auttaa saavuttamaan tavoitteet?"
Ja juuri tästä kysymyksestä jokainen hyvä projekti pitäisi aloittaa.
Lopuksi – tärkein periaate
Emme suunnittele sivua vain jotta asiakas voi sanoa: "Mutta onpa se kaunis".
Suunnittelemme sen niin, että muutaman kuukauden kuluttua asiakas voisi sanoa: "Tämä todella auttaa meille liiketoiminnassa".
Koska ero kauniin sivun ja hyvän digituotteen välillä ei usein näy ensimmäisellä ruudulla.
Se näkyy vasta tuloksissa.
Tiivistelmä koko sarjasta
Tässä sarjassa tarkastelimme, miksi emme suunnittele kahta samanlaista verkkosivua.
Aloitimme yksinkertaisella oletuksella: sama toimiala ei tarkoita samaa liiketoimintaa.
Seuraavaksi näytimme, miten yrityksen strategia, myyntitapa, kohdeyleisö ja käyttäjien tarpeet vaikuttavat UX:ään, tiedonarkkitehtuuriin ja toiminnallisuuksiin.
Viimeisessä osassa kävimme läpi suunnitteluprosessin – Discoverystä ja liiketoiminnan tuntemisesta, User Flow -malleihin, wireframeihin ja Design Systemiin, aina teknologiaan, integraatioihin, testaukseen, analytiikkaan ja jatkokehitykseen.
Yksilöllinen suunnittelu ei tarkoita vain "toisenlaista ulkonäköä".
Se tarkoittaa eri päätöksiä eri ongelmien perusteella.
Ja juuri siksi jokaisen yrityksen pitäisi saada ratkaisu, joka on suunniteltu sille, ei "keskivertoyritykselle alalla".
