Bygg et produktdesignteam, bygg et produkt brukerne dine elsker

I juli 2016 ble jeg invitert ombord i det mest ambisiøse prosjektet i OutSystems Engineering: å bli med i en gruppe mennesker som brenner for UX og danne det som i dag er kjent som Product Design-teamet. Dette teamet påvirket hvordan engineering bygger produktet til det punktet at brukeropplevelsen blir forankret i vår kultur. La meg fortelle deg historien om hvordan vi kom hit.

Min historie

Jeg er programvareingeniør som begynte i OutSystems Engineering allerede i 2007. Siden har jeg drevet og lært mye teknisk. Jeg ble teamleder, og underveis oppdaget jeg brukervennlighet og design. Jeg har alltid vært en av de menneskene som virkelig bryr seg om brukerne våre, fyren som eksperimenterte med å jobbe med mockups og prototyper og som gjorde brukervennlighetstester før du sendte produktet.

Januar 2015: En kunde var så fornøyd med teamets arbeid,
at de sendte oss et godt nyttårsbrev.

Imidlertid, hvis du ønsker å bygge et flott produkt, er det ikke nok å ha noen få mennesker som bryr seg om brukeropplevelsen. Selskapet innså det og prøvde (og mislyktes) å opprette og vedlikeholde et sentralisert UX eller designteam. Så hvorfor ble jeg invitert til å bygge dette teamet ?? Vel, som du vil se, grunnen var at vi denne gangen skulle gjøre ting annerledes. Etter en vellykket prøvekjøring i et eksisterende team, godtok ledelsen vårt forslag om å bygge et helt nytt designteam.

En grunnregel for dette teamet var at det måtte være tverrfaglig: i motsetning til tidligere iterasjoner, måtte det være sammensatt av både UI / UX-designere og ingeniører med en sterk programvareutviklingsbakgrunn. Hvorfor var dette viktig?

OutSystems tilbyr en lavkodeplattform for å bygge mobil- og webapplikasjoner. Vårt endelige formål er å forbedre utviklingenes liv ved å gjøre utviklingen raskere og enklere. For å forstå disse utviklerne, oppdage deres behov og designe og validere de beste løsningene, trenger vi både ingeniører og UI / UX designere. Jeg ville være ingeniør og også teamleder for dette nye teamet, og det var en stor utfordring!

November 2016 - Produktdesignteamet.

De tidlige stadiene: Definere vårt formål og vår visjon

Den første viktige avgjørelsen vi tok var å navngi teamet “Product Design.” Vi ønsket å bryte fra tidligere design-bare team. Dessverre hadde disse vært begrenset til de senere stadiene i prosjektene, og arbeidet bare med den visuelle designen (bilder og ikoner) og andre design ting som ingeniørene ikke kan gjøre, som t-skjorter og krus og andre fantastiske svag.

Vi ønsket å forme fremtiden til produktet vårt og ikke være en ettertanke; vi ville være involvert fra grunnen av.

Produktdesignteamet vil påvirke hvordan Engineering designer produktet i sine forskjellige aspekter. Vi vil påvirke funksjonaliteten, brukervennligheten og nytten av produktet, og ja, også de visuelle aspektene ved produktet.

Med dette bestemte vi vår inspirerende visjon:

Produktdesignteamets visjon.

Deretter definerte vi et sett med mål som vi bruker for hvert prosjekt vi jobber med. Disse målene leder oss mot vår visjon: leverer et produkt brukere blir forelsket i ved første blikk og fortsetter å elske for alltid:

  1. Gjør produktet enkelt å bruke.
  2. Gjør produktet vakkert og ønskelig.
  3. Hjelp brukerne våre med å forstå produktverdien.

I ettertid er ikke målene våre forskjellige fra målene fra de tidligere designteamene, og vi var klar over at det alltid er fare for å mislykkes slik de lagene gjorde.

Å kjøre et premortem

I det siste har vi brukt en nyttig teknikk, kalt en premortem (mer her), som hjelper oss å forutsi risiko i prosjektene våre. I et premortem forestiller vi oss en hypotetisk fremtidig fiasko av prosjektet. Vi ber hver person involvert i prosjektet om å påpeke hvilke risikoer som kan ha bidratt til den feilen. Deretter tilpasser vi planene våre, for å unngå disse hypotetiske risikoene, og unngår svikt. Så enkelt og kraftig, ikke sant? Det er; tro meg!

Prosjektets premortem

Så vi bestemte oss for å kjøre premortem for laget. Den hypotetiske innstillingen var at teamet etter ett år hadde mislyktes spektakulært. Vi ba alle på teamet om å identifisere de mulige årsakene til feilen. Fra disse hypotesene identifiserte vi vanlige bekymringer, og vi definerte handlingselementer for å unngå dem. Noen av disse handlingene ble henrettet under oppstart av teamet, og andre blir fremdeles henrettet til i dag, bare for å sikre at vi ikke faller fra stupet. :)

Å vurdere ferdighetene våre

En av risikoen vi hadde identifisert var teamets flerfaglige natur. Det kan være utfordrende å komplettere de forskjellige ferdighetene våre, og på det tidspunktet har vi kanskje ikke de ferdighetene som er nødvendige for å gjøre arbeidet vårt. Vi godtok utfordringene som en flott mulighet for oss til å vokse! Og vi har alle kommet så langt.

Vi så på definisjonen av produkt. Vi fant dette:

Produktdesign identifiserer, undersøker og validerer problemet, og til slutt håndverk, design, tester og sender løsningen.

Vi tilpasset denne definisjonen til våre spesifikke behov, og vi begynte å utforme hva det vil si å være produktdesigner i OutSystems Engineering. Vi lagde også et diagram over de viktigste ferdighetene som vi vil trenge som produktdesignere.

Diagram som demonstrerer ferdighetene til produktdesignteamet for 2016.

Neste, hver av oss gjorde en egenvurdering av ferdigheter, vi diskuterte også ferdighetene vi ønsker å utvikle, eller hvor vi kunne trene andre. Dette ga oss nyttige innsikter om hvor teamet trengte trening eller flere teammedlemmer.

Det hjalp oss også med å definere en annen grunnregel for teamet: vi bør alltid jobbe parvis, bli med på ingeniør- og designferdighetene våre for å utfylle hverandres flotte arbeid og lære av hverandre.

Vi gjør fortsatt denne øvelsen fra tid til annen, og siden den første iterasjonen har vi fortsatt å evaluere ferdighetene våre. Som et resultat har vi tilpasset diagrammet for å omfatte endringene våre. Her er vårt 2018-diagram:

Diagram som demonstrerer ferdighetssettet for produktdesignteamet for 2018.

Arbeide med produktgruppene

Når teamet er på plass, vår visjon og mål satt, og våre ferdigheter bestemt og klare, hvordan kan vi faktisk påvirke fremtiden til produktet? OutSystems engineering har flere produktteam, ett for hvert område av produktet: front-end, back-end, applikasjonslivssyklus, og så videre.

En annen risiko vi hadde identifisert var at produktgruppene kunne bestemme seg for å slutte å jobbe med oss ​​hvis prosessene våre forstyrret smidigheten deres. Så vi setter noen flere bakkeregler for teamet vårt:

  1. Vi jobber med lagene, ikke for lagene
  2. Vi har alltid som mål å legge til maksimal verdi og minst mulig overhead for lagene.

Vi trengte en veldefinert prosess slik at teamene vet når de kan stole på oss. Vi undersøkte flere designsystemer, leste bøker og artikler og hentet inspirasjon fra andre selskaper. Det er mange designprosesser der ute, men vi trengte å skreddersy en prosess til våre egne spesifikke behov.

Vi definerte en prosess med fire trinn: oppdage, prototype, levere og finpusse.

De fire stadiene i produktdesign

Oppdag scenen

I dette stadiet er målet å forstå alt om problemet. Vi intervjuer, samler tilbakemeldinger fra flere kilder, gjør brukervennlighetstester med den nåværende løsningen, analyserer konkurransen og kjører en idéprosess for å komme opp med så mange løsninger som mulig. Vi gjennomførte noen veldig kule eksperimenter under forestillingsprosessen, og i dag kjører vi en variant av Google Design Sprint vi kaller "Design Session." vi prøver å løse.

November 2016: Prøver Google Design-sprinten.Desember 2016 - Produktet fra vår aller første Design Session, for Full-Stack Visual Debugger.

Prototypescenen

I dette stadiet prototyper vi løsninger for problemet, tester dem med målbrukere og deretter itererer dem. Prototypene kan spenne over flere nivåer av troskap, fra papir til programvare. På slutten av dette stadiet har vi testet flere prototyper, så vi vet hva som fungerer og hva som ikke fungerer. Vi jobber tett med produktgruppene som skal implementere løsningen, og på slutten bestemmer de hvilke løsninger som skal implementeres.

Januar 2017: Full-Stack Visual Debugger-prototyper.Mars 2017: A Styles Editor-prototype.

Leverer scenen

I løpet av dette stadiet bygger produktgruppene programvaren og produktdesign gir visuelle eiendeler, gjennomgår den implementerte programvaren fra ende til annen og kjører brukervennlighetstester. Testing med arbeidsprogramvaren gir oss ekstra innsikt i brukervennlighetsspørsmål, og vi er åpne for å tilpasse løsninger på dette stadiet, og om nødvendig kan vi prototype alternativer. På slutten av leveringsstadiet blir produktet sendt og vi feirer dette med teamet!

Mars 2017: Et av teammedlemmene fødte en baby, wow!September 2017 - Det endelige brukergrensesnittet for dialogboksen for mobilenheter for Full Stack Visual Debugger

Tweak-scenen

Dette trinnet starter når tilbakemeldinger fra brukerne våre ruller inn. På dette stadiet ser vi på beregninger for å finjustere den leverte løsningen. Målet er å identifisere hva som fungerer og hva som ikke er, å utføre hurtigreparasjoner eller planlegge fremtidige forbedringer. I neste bilde kan du se vår analyse av Styles Editor-beregningene. Fra analysen identifiserte vi hvor mange forskjellige måter brukere fikk tilgang til funksjonalitetene, og hvilken vei som var den mest populære.

Denne informasjonen hjelper oss med å forenkle designet.

Desember 2017: - Analysere bruksmålinger for Styles Editor.

Skum, skyll, gjenta

Vi går gjennom alle disse stadiene med våre produktteam, slik at alle er involvert i designprosessen, fra dag én til kundene lykkelig bruker det vi alle bygde sammen. Prosessen er tilpasningsdyktig og iterativ; vi kan kjøre den flere ganger i løpet av et prosjekt. Vi er alltid åpne for å tilpasse prosessen til nye teknikker, nye krav, og vi justerte den under eksperimentene våre.

Hvor vi er i dag; Hvor vi er på vei?

I dag har vi et jevnt, sterkt og høytytende produktdesignteam, og vi har bevist vår verdi i flere prosjekter, noen allerede levert. Vi har jobbet med de fleste produktteamene, og i dag forstår all OutSystems engineering verdien av vår praksis. Brukeropplevelse blir en del av vår kultur.

Vi har fremdeles mange utfordringer fremover: vi må skalere teamet for å påvirke flere prosjekter, vi må fortsette å jobbe med vår visjon for fremtiden, vi må forbedre synkroniseringen med produktledere og produkteiere, og så videre. Det er mye å gjøre, så la oss rulle opp ermene og bli opptatt!

Tilbake til Min historie

Dette er det klart mest utfordrende og givende prosjektet jeg har vært involvert i i løpet av min tid hos OutSystems. Utfordringene er konstante; teamet er fantastisk! Takk, OutSystems, for en så ekstraordinær mulighet.

Produktdesignteamet i 2018