Aloittelijan opas Lean UX: hen - oletukset, hypoteesit ja MVP

Ketterästä viitekehyksestä on nopeasti tulossa selkäranka yrityksille, jotka toimittavat uusia ominaisuuksia nopeilla purskeilla. Kehitysjakson tai sprintin aikana kulutetaan kuitenkin suurin osa ajasta vielä suunnitteluprosessissa - käyttäjän vaatimusten keräämisessä, kaiken tutkimisessa ja lopulta dokumentoinnissa. Tämä pahenee entisestään, kun ryhmäsi viettää kuukautta kaiken dokumentoinnissa, mutta juuri ennen varsinaisen kehitysvaiheen alkua vaatimukset muuttuvat tai useita kuukausia sitten tehty tutkimus vanhentunee. Lopputulos? - Joukkueesi on aloitettava neliöltä. Tässä suurin osa yrityksistä tuottaa paljon jätettä, joka maksaa sekä aikaa että resursseja.

Ketterän kehityksen perustana oleva Lean UX on käyttäjäkeskeinen lähestymistapa, joka keskittyy suunnittelusyklin aikana syntyvän jätteen vähentämiseen ja UX: n parantamiseen useilla iteraatioilla kuluttamatta paljon aikaa dokumentointiin.

Liian paljon sulavaa? Annetaan sukeltaa hiukan syvemmälle!

Mikä on Lean UX?

Kuten edellä todettiin, Lean UX perustuu kolmeen päävaiheeseen - rakenna, mittaa, oppi.

Aivan kuten ensimmäistä kertaa keitetyt ruokia eivät ole koskaan täydellisiä, Lean UX olettaa, että tuotteen ensimmäinen muotoilu on aina väärä. Tästä syystä sinun ei pidä viettää paljon aikaa tutkimuksen dokumentointiin, sen sijaan sinun pitäisi vapauttaa vähimmäisresursseilla kehitetty toimiva tuote ja alkaa sitten kerätä palautetta käyttäjiltäsi. Analysoi palaute ja tee sitten tarvittavat muutokset tuotteeseen ja toista prosessi uudelleen. Muista vain yksi asia! -

Rautakehyksesi tai tutkimusasiakirjat eivät ratkaise käyttäjien ongelmia, mutta tuotteesi ratkaisee.

Yhteistyö - Lean UX: n selkäranka

Muista hetkeksi vain tämä kuva mekosta, joka meni virusperäiseksi muutama vuosi sitten vain siksi, että eri ihmiset katsoivat sitä eri sävyissä. Tämä on hyvin pieni esimerkki, joka osoittaa, että eri ihmiset tuovat erilaisia ​​näkökulmia heidän mukanaan. Tästä syystä yritykset, kuten Google, Microsoft, Apple, jne. Palkkaavat ihmisiä, joilla on erilainen kulttuuritausta.

Lean UX suosittelee koko ryhmän yhteistyötä ongelman ratkaisemiseksi. Otetaan toinen esimerkki, kuka luulet tuntevasi asiakkaasi paremmin sinä tai henkilö, joka viettää 8 tuntia päivässä ratkaisemaan käyttäjän kyselyjä? Ilmeisesti asiakaspalvelupäällikkösi, mutta tämä ei tarkoita, että näkemyksilläsi olisi vähemmän arvoa. Jokaiselle ryhmän jäsenelle tulisi antaa mahdollisuus esitellä ideoitaan ratkaistavasta ongelmasta. Jokaisen idean parhaat osat tulisi kerätä ja jatkaa työskentelyä. Tämä auttaa asiakaspalvelupäällikköäsi tuomaan esiin ongelmat, joita asiakkaasi kohtaavat alkuperäisen suunnitteluprosessin aikana. Lisäksi se auttaa markkinointitiimiäsi valmistautumaan seuraavassa julkaisussa esiin tuleviin uusiin ominaisuuksiin. Lisäksi kehittäjät voivat alkaa työskennellä uusien päivitysten arkkitehtuurilla ja tänä aikana suunnittelutiimi voi viimeinkin työskennellä prototyyppien kanssa.

Yhteistyöhön perustuva lähestymistapa ei tuo vain erilaisia ​​näkemyksiä ongelmasta, vaan myös käynnistää tehtävien samanaikaisen käsittelyn ryhmän eri osastoilla. Tämä tehtävien samanaikainen käsittely parantaa tehokkuutta ja lyhentää toimitusaikaa. Ja jos sinulla on suuri joukkue, yritä jakaa joukkue pienempiin alajoukkoihin, joissa on jäsen jokaisesta osastosta kussakin pienemmässä ryhmässä.

Muodostaessaan yhteistyötiimejä ei koskaan palkata itsekeskeistä ninjaa. Tämä johtuu siitä, että egoistiset ihmiset välttävät usein palautteita ja tämä estää yhteistyön motiivia Lean UX: ssä.

Suunnittelusykli Lean UX: n kanssa

Kuten aiemmin mainittiin, Lean UX alkaa löytää ratkaisu ongelmaan ja mitata sitten palautteet ja parantamaan aiempia ratkaisuja näiden palautteiden perusteella.

Ongelmalausunto ja oletukset

Kuten mainitsin kohdassa 4 yleistä virhettä, UX-suunnittelijoiden tulisi välttää tuotesuunnitteluprosessin aikana, kun ryhmäsi kohtaa ongelmalausunnon, keskitytään “miksi” eikä “miten”. Tämä opastaa sinua oletusten muodostamisessa.

Oletus muodostuu annetusta ongelmasta ja sen oletetaan olevan totta. Jokainen joukkueesi henkilö (yhteistyö) keksii oman ratkaisunsa annettuun ongelmaan, mitkä oletukset luodaan. Nämä oletukset voivat perustua vastauksiin - tuotteen käyttäjiä tyyppiin tai tilanteisiin, joissa tuotetta käytetään tai epävarmuustekijöihin, jotka saattavat estää tuotteen käyttöä ja niin edelleen.

Monimuotoiset joukkueet voivat kertoa monenlaisia ​​vastauksia edellä mainittuihin tapauksiin. Tämä viittaa tarpeeseen asettaa tärkeysjärjestykseen oletukset, jotka perustuvat - tietoisuuteen ongelmasi ja sen seurausten tasoon, joka voi tapahtua, jos oletus menee pieleen. Oletukset, joihin liittyy suuri riski tai niihin liittyvät riskit, joukkueellasi on vain vähän tietoa, ovat ensisijaisia.

On myös selvää, että oletukset voivat osoittautua väärin tulevaisuudessa, mutta niitä voidaan muuttaa aina, kun se tapahtuu.

Hypoteesi

Kun olet ajatellut ongelmalausuntoja ja yhdistänyt ryhmäsi jäsenten ideoita, luot hypoteesit. Hypoteeseja käytetään oletusten testaamiseen.

Kuten Interaction Design Foundation on todennut, ilmoitat uskomuksen, sen tärkeyden ja tärkeät henkilöt. Sitten puhut odotuksistasi ja lopputuloksesta, joka todistaa uskomuksesi.

Esimerkiksi: ”Uskomme, että yhden napsautuksen rekisteröinnin lisääminen Facebookin avulla on hyödyllinen ominaisuus kiireisille käyttäjille, joilla on Facebook-tili, koska se säästää heidän aikaa. Tämä lisää käyttäjien rekisteröintiastetta 20 prosentilla. ”

Yllä olevassa esimerkissä usko siihen, että yhden napsautuksen rekisteröinnin lisääminen Facebookin avulla on hyödyllinen; persoonat ovat kiireisiä käyttäjiä, joilla on Facebook-tili; tärkeys on säästää käyttäjän aikaa; odotus kasvattaa ilmoittautumismääräämme; ja tulos, joka todistaa uskomuksen, kasvaa kirjautumisprosentti 20 prosentilla.

Yksi positiivisista puolista hypoteesin kirjoittamisessa on se, että voit päätellä, että olet menossa väärään suuntaan, jos et milloinkaan löydä mitään tapaa todistaa hypoteesiasi.

MVP (minimi elinkelpoinen tuote)

Kun ryhmäsi on suorittanut oletushypoteesit, aloitat Minimal Lifeble Product tai MVP.

Wikipedian mukaan

MVP on tuote, jolla on vain tarpeeksi ominaisuuksia tyydyttääkseen varhaiset asiakkaat ja antaa palautetta tuleville päivityksille.

Tämä määritelmä vie meidät takaisin mihin aloitimme - rakentaa, mitata, oppia. Rakennat MVP: n käyttämällä kaikkia ideoita, joita ryhmäsi aivoriihi ja luodut hypoteesit käyttävät, ja kysy sitten käyttäjiltä arvokasta palautetta ja viimeinkin käytä näitä palautteita oletusten ja lopulta tuotteen päivittämiseen.

[Lähde Internet-suunnitteluorganisaatio]

MVP ei koostu vain harvoista ominaisuuksista, vaan sen sijaan se sisältää joitain käyttökelpoisia ominaisuuksia, jotka ratkaisevat käyttäjän ongelmat ja joihin on liitetty joitain UX: itä.

MVP voi olla myös heikkolaatuinen (Lo-Fi) prototyyppi, esimerkiksi paperiprototyyppi tai digitaalinen prototyyppi, jonka käyttäjät voivat olla vuorovaikutuksessa ja katsella erilaisia ​​näytöjä siellä olevien toimien seurauksena.

johtopäätös

Lean UX voi olla erittäin tehokas joukkueille, joilla on vähän resursseja, ja siitä voi olla hyötyä myös joukkueille, jotka haluavat maksimoida tuotantonsa ja vähentää jätteitä. Se kulkee käsi kädessä ketterän kehityskehyksen kanssa, mikä tekee siitä erittäin sujuvan mukautua nykyiseen järjestelmään. Lisätietoja palautteesta ja testauksesta.

Jos nautit tämän lukemisesta, älä unohda osoittaa rakkauttasi antamalla “50 claps” ja napsauttamalla “follow” -painiketta :). Se motivoi minua kirjoittamaan lisää tämän tyyppisiä tarinoita ja auttamaan ystäviäsi löytämään tämän jakamalla tämän heidän kanssaan. Kiitos! :)