Jag har länge haft en fri roll. Det finns en rollbeskrivning men inget facit för vad en UX Director på Hemnet ska göra eller hur man ska vara. Det finns ingen annan UX Director. Oftast har det varit kul, för jag är intresserad av det mesta och älskar att upptäcka nya områden där jag kan lära mig och bidra. Men ibland har det varit jobbigt och bland har jag haft känslan av att jag inte fokuserar på rätt saker.
För ungefär ett år sedan gjorde jag en förbättring som hjälpte mig i det här. Jag avsatte 30 minuter varje fredag till reflektion och uppfann en reflektionsmall som jag använt sedan dess. Den består av följande rubriker:
Gjorde
Kände
Lärde mig
Kunde gjort mer/mindre av
Att fokusera på nästa vecka
Att skriva för att reflektera funkar bra för mig (det är också därför jag skriver den här bloggen) och veckoreflektionen har hjälpt mig på flera sätt:
Jag är mer medveten om hur jag spenderar min tid och prioriterar. Det blir lättare att skifta fokus om jag hamnar på ”fel” spår.
Jag kan tidigare upptäcka att jag har för mycket att göra och hantera det.
Jag är snällare mot mig själv och bättre på att ge mig själv återhämtning och pausa i intensiva perioder.
Jag har lättare att känna att jag bidrar och skapar värde.
Jag rekommenderar verkligen alla att prova att avsätta tid för reflektion.
Hemnet jobbar med OKR (Objectives and Key Results), vilket jag skrivit om tidigare och även här. På den fina konferensen Agila Sverige hamnade jag i flera snack om OKR och tänkte mer på hur vi på Hemnet använder OKRs, vilka delar jag gillar och vilka som är svåra.
Mål (Objectives) för att dra åt samma håll och prioritera är bra
Hela grundidén med att ha mål (Objectives i OKR) på organisations- och teamnivå är att aligna folks mål med teamet och organisationen de jobbar i. Alla vill ju, förhoppningsvis, jobba med att göra nytta och då behöver man förstå vilken nytta vi jobbar med för tillfället för att alla ska kunna dra åt (typ) samma håll.
En annan bra sak är att det blir lättare att förstå vad andra team jobbar med om det finns ett uttalat mål, så man kan upptäcka synergier och hjälpas åt.
En tredje bra sak är att det blir lättare att prioritera om målet är uttalat och lätt att förstå, både som team och teammedlem.
Sätta mätpunkter (Key Results) på förhand är svårt
Vi har satt övergripande OKR för hela Hemnet varje år, och våra team har satt OKR varje kvartal. Man bestämmer vad man vill uppnå, gärna i form av ett användarbeteende man önskar förändra (Outcome) som gynnar vår affär.
En förändring i mänskligt beteende som teamet kan påverka och som driver ett affärsmål.
Till exempel kan vi vilja att bostadssökare använder Hemnet för att hitta nyproduktion, (outcome) vilket är bra för vår affär eftersom det gör oss mer attraktiva för bostadsutvecklare som vill synas på Hemnet och ökar vår trafik vilket stärker oss.
Man bestämmer också hur man tänker mäta beteendeförändringen och vilken konkret siffra man vill landa i. Så hur mäter vi att folk använder Hemnet för att hitta nyproduktion? Mäter vi trafik och försöker identifiera nyproduktionssökare? Gör vi en enkätundersökning för att se var folk letar nyproduktion?
Nästa fråga är vilken ambitionsnivå vi ska sätta. Om vi väljer ett trafikmått, kan vi öka det 10% på ett kvartal? 20%? 50%?
Vi vet ofta inte hur vi ska mäta eller vilken ambitionsnivå som är lagom. Vi vill jobba utforskande, förstå användargruppen och förstå problemen Hur kan vi på förhand bestämma ett sätt att mäta progress och en rimlig ambitionsnivå?
Teamen fastnar ofta i långa diskussioner kring mätning och ambition som landar i att man gissar något utan tillräcklig information, för att OKR-ramverket kräver det. Man landar ofta i att mäta något som inte direkt speglar jobbet som görs och sätter en på tok för hög eller en på tok för låg siffra.
Resultatet blir att man har Key results som inte är relevanta för arbetet som görs och inte motiverar någon. Det kan tvärtom kännas rätt tungt när man totalt misslyckas med att nå sina mål, trots att man gjort en massa jättefint arbete och det känns som att man tagit stora kliv framåt.
Det här händer framför allt när man går in i ett nytt och okänt område, det är förstås lättare att sätta mål när man jobbar med att förbättra och optimera något befintligt.
Hur löser vi det här?
Lösningen tänker jag är att fokusera på den finaste delen av OKRs – målet (O) för att uppnå alignment, kommunicera vad organisationen och teamen vill uppnå och kunna prioritera.
Mätpunkterna (KR) kan vara sekundära och får växa fram under tiden vi jobbar med målet. Med tid och när vi lärt oss saker blir det tydligare vad som är vettigt att mäta. Vi kan behöva göra en basmätning och göra några förbättringar för att se hur lätt det är att påverka målet innan vi kan sätta en ambitionsnivå.
När mätpunkterna inte är satta från början finns det så klart ingen progress att följa från början. Det kanske man får leva med. Jag tror ändå alternativet, att följa en mätpunkt som inte speglar arbetet som görs, är sämre för det minskar folks förtroende för OKRs och ger en felaktig bild av progress.
Jag tror också det är bra att jobba med samma mätpunkter under en längre tid, att inte hela tiden definiera om vad man mäter, så man kan lära känna mätpunkten och lära sig om hur lätt den är att påverka. På Hemnet kommer det här bli lättare framöver, när vi går över från att sätta team-OKRs varje kvartal till varje halvår.
Alla ni andra som jobbar med OKR, hur tänker ni på det här problemet? Har ni någon annan lösning? Kommentera gärna!
För ett tag sedan skrev jag om hur vi som jobbar med produktutveckling på Hemnet diggar Teresa Torres och börjat använda Opportunity Solution Trees i fler och fler team, för att visualisera product discovery.
En annan del i Torres sätt att göra product discovery som fler och fler team anammar är product trio.
Vad är product trio?
Vi vill att våra team både ska ta reda på vilken grej som är allra vettigast att bygga härnäst (product discovery) och bygga grejer man redan vet att man vill bygga, med hög kvalitet (product delivery). Helst samtidigt.
Discovery och delivery skiljer sig väldigt mycket från varandra. Delivery är mer förutsägbart och går att planera, man vet vad man ska göra härnäst. Discovery är rörigare, oförutsägbart och man behöver ta jättemånga små beslut på kort tid.
Discovery kräver också olika perspektiv. Vad är bra för affären? Vad funkar för användare? Var är tekniskt möjligt? En variant är att involvera hela produktteamet i besluten så alla perspektiv täcks in, men det tar för lång tid.
Det är inte heller lika motiverande för alla i teamet att jobba med discovery. För product manager och UX designer är det en naturlig del av jobbet, förstås. Men hos utvecklare ser intresset olika ut. Även om alla i ett produktteam vill och ska vara med i discovery i någon mån så kanske inte alla vill lägga 50% av sin tid på det.
Vad vi gör istället är att sätta ihop en product trio, en mindre grupp i teamet där både affärsperspektiv, användarperspektiv och teknikperspektiv finns mer. En typisk laguppställning är en product manager/affärsutvecklare, en designer/researcher och en utvecklare/systemarkitekt. Exakt vilka kompetenser kan variera beroende på team och organisation. Och det behöver inte vara en trio, ibland kan det behövas en kvartett.
Det är förstås viktigt att hela produktteamet är engagerat i discovery på något sätt. Där har trion en viktig uppgift, att avgöra när andra behöver involveras och hur.
Vad vi lärt oss
För ett tag sedan körde vi en kunskapsdelning där team som provat product trio fick berätta hur man gjort och vilka utmaningar man sett.
Ett första steg många team tagit är product trio för att definiera mål och mätpunkter. Vi jobbar med kvartalsmål (OKRs) och har ofta kört workshops med hela teamet för att spåna mål inför kommande kvartal. Det har blivit mer effektivt och roligt när en product trio kan förbereda mål och mätpunkter som hela teamet sedan kan diskutera.
Utvecklarrollen i en product trio passar inte alla. Man behöver vara okej med att skriva mindre kod, ha mer möten/workshops, prata med användare, jobba med teknisk research och proof of concept.
Det är viktigt att visualisera product discovery (t.ex. i en Opportunity Solution Tree) för att kunna kommunicera effektivt både inom trion och när man blandar in andra utanför. Med visualisering blir vi också mindre personberoende och kan lättare växla medlemmar i trion, det går snabbare att komma på banan och förstå var vi befinner oss i discovery-arbetet.
En product trio är inte bara bra för att öka farten, det blir också oundvikligt så att vi sätter mer fokus på discovery och ”tvingar oss” att tänka på det som en viktig kontinuerlig del av teamets arbete.
Det kan vara utmanande för en trio att avgöra när man ska blanda in resten av teamet. Det är både vanligt att man gör för mycket innan resten av teamet involveras, och att man involverar resten av teamet för tidigt. Här gäller det att ha rutiner och hela tiden en dialog i teamet om hur vi kan göra det bättre.
Tack alla smarta kollegor som delade era lärdomar!
För drygt två år sedan kom jag och min chef överens om en ny roll för mig. Jag hade varit UX Designer i ett produktteam på Hemnet i några år och sett behovet av en roll som jobbar övergripande med designfrågor. Rollen fick heta UX Director. Mitt ansvar blev att inom områdena UX, design, analys och CRO:
Bidra med förutsättningar för effektiva arbetssätt i produktteamen
Se till att vi har rätt kompetens i produktteamen
Driva teamöverskridande initiativ
Hjälpa produktteam hands on vid behov (till exempel när ett team saknar designer)
Jag är superglad att jag fick det här förtroendet. Rollen har varit väldigt kul, svår och jag har förstås lärt mig en hel massa. Inga revolutionerande saker men kanske intressant för den som gör eller vill göra en rollförändring åt samma håll.
Lyssna och jobba i medvind
Den kanske största utmaningen har varit att avgöra vad jag ska fokusera på. Vilka förändringar ska jag driva? Var kan jag vara till mest nytta?
En sak jag lärt mig är att fokusera på att driva saker där det finns medvind. Att driva initiativ som jag tror starkt på men där ingen annan redan är med på banan eller ser ett behov är energidränerande och dömt att misslyckas. Det kanske kan låta passivt och det är det. Jag har lärt mig att ha tålamod, avvakta och lyssna efter behov som kollegor uttrycker istället för att driva saker som bara jag tror på. Har jag redan en eller några stycken allierade kommer det inte bara bli lättare att lyckas, chanserna att det jag gör är ”rätt” och till nytta ökar dramatiskt. Jag sitter ju inte på facit. Alltid. 🙂
Om jag har en stark tro på något, så börja prata om det istället för att driva igång initiativ direkt. Förhoppningsvis kommer folk förstå nyttan och börja prata om samma saker efter ett tag. Då är det dags ta till vara på den energin och gasa.
Reflektera
Tid för reflektion är nog viktigt i alla roller men extra viktigt i en sådan här roll med mycket frihet och självledarskap. Reflektion är lätt att prioritera bort när jag har mycket att göra, så jag har en stående bokning varje vecka där jag fyller i en mall jag hittat på:
Gjorde – vad har jag gjort under veckan?
Kände – hur har jag mått? vad har gett mig energi?
Lärde mig – vad lärde jag mig?
Kunde gjort med/mindre av – jobbade jag med rätt saker? lagom arbetsbelastning?
Att fokusera på nästa vecka
Jag är en sån som tycker det mesta inom produktutveckling är kul och intressant. Under en vecka rör jag mig ofta mellan att tänka kring strategi och framtida organisationssätt till att pixel-pusha design och skriva kod. Mina veckoreflektioner jag hjälpt mig att bli mer medveten om vad jag gör och fokuserar på.
Att jag gör saker som är bra för Hemnet är förstås viktigt, men det är också viktigt att jag göra saker som jag får energi av. Reflektionerna hjälper mig att hitta vad som ger energi och balansera så jag både kan göra nytta för Hemnet, få energi och må bra.
Vara med där det händer
Man lär sig så mycket av att vara med där det händer. Inte bara i olika diskussioner ledare emellan utan i användarintervjuer, i Slack-trådar och i koddiskussioner på Github. Folk uppskattar också ledare som är närvarande, förstår utmaningarna och deltar i diskussioner på alla nivåer på ”rätt” sätt, utan att pyssla med micro management.
Det här är väl inte något jag ändrat direkt, men tänkt på att jag vill fortsätta med och uppskattar hos kollegor.
Ta hjälp av communityt
Som ensam i sin roll har det varit viktigt att ibland få inspiration utifrån och höra om hur andra gör. Det har hjälpt mig att vara del av UX Open Snack, Design Leadership Community och lyssna på Jens Wedins podd Det måste finnas ett bättre sätt där han samtalar med svenska designledare. Jag gillar att podden är ärlig och handlar om hur vi jobbar i verkligheten i svenska företag.
Vi i Hemnets UX-gäng har också haft ett antal utbyten med UX-gäng på andra företag och diskuterat hur vi jobbar. Vi har försökt hålla tröskeln låg, komma överens om några gemensamma ämnen på förhand och boka upp kanske två timmar där vi kör diskussionsgrupper med representanter från respektive företag. Det har varit kul, lärorikt och inte alls varit svårt att få tag på andra företag som vill ses och prata.
En sak jag ska göra mer av framöver är att ha några personer i liknande roller på andra företag att bolla med regelbundet i one to ones.
Designsystemet är en rätt stor förändring för oss och hur vi jobbar. Vi har skapat det utan att ha ett dedikerat team som ansvarar för det. Och vi har gjort den här förändringen samtidigt som våra produktteam egentligen fokuserat på annan produktutveckling. Det här har förstås varit utmanade och det har varit viktigt att utvärdera och prata om hur vi tar oss framåt.
Här tänkte jag dela några principer vi tillsammans kommit överens om. Det här är saker vi behöver påminna oss själva om, som inte alltid händer automatiskt:
We want to include component work when we plan work in teams – this should be viewed as a required hygiene factor that will save time later for us and for others.
Vi jobbar med designsystemet för att vi tror att det gör oss effektivare långsiktigt och höjer kvalitén. Dels genom att vi har genomtänkta komponenter och mönster vi kan återanvända på en massa ställen. Dels genom att vi utvecklare, designers och andra kompetenser har ett gemensamt språk – vi kan kommunicera bättre.
När ett produktteam ser behov av en generell komponent så går det går oftast snabbare att ta fram den lokalt i sin egen lilla bubbla istället för att låta den vara en del av designsystemet och bli ”officiell”. Det här tycker jag är den största utmaningen med att ha delat ansvar för designsystemet och vi måste påminna oss om och om igen. Teamen måste planera för designsystemarbete och inte bara tänka på produkten de jobbar med för tillfället.
We want to have a team mindset that ”we need to do new components and we have the support from others” rather than ”others are doing new components”.
Den här hänger ihop mycket med den första. Produktteamen ska jobba med designsystem och när de gör det så har de support från andra teammedlemmar, från ledare och från mig (User Experience Director) som faciliterar, följer upp och hejar på.
Teams that have a need for components but don’t think they have time should express their need (for example in Design system forum or in #designsystem Slack)
En annan viktig grej att påminna sig om, att uttrycka sitt behov av nya/förändrade komponenter eller principer så idéerna inte fastnar i ett team eller i några personers huvuden. De två viktigaste kommunikationskanalerna vår slack-kanal och ett forum som vi kör varannan vecka. Där deltar utvecklare och designers från alla team och vi försöker ha minst en representant från varje team.
I forumet lyfter vi behov, visar upp saker vi jobbar med på olika håll och pratar om hur vi jobbar. De här principerna kommer från en workshop i ett designsystemforum.
We want to be generous in accepting things that are not perfect – to be fast.
Don’t let perfect be the enemy of good. När man jobbar fram gemensamma komponenter och principer är det lättare än vanligt att hamna i ”analysis paralysis” (sorry, mycket swenglish nu). Vi vill att det som är gemensamt ska vara så himla bra och genomtänkt att vi ibland har svårt att ta nästa steg.
Vi behöver ofta påminna oss om att acceptera saker som är bra nog men inte helt perfekta. En av fördelarna med designsystem är ju faktiskt att man kan ändra designen senare. Det är svårare att ändra på strukturer men vi måste våga ta beslut och släppa saker för att komma framåt.
We don’t just want to add new things. Iterating, maintaining components and implementing them in contexts are also ways of growing the design system.
Det är viktigt att inte bara uppfinna nya saker. Gör vi det så hamnar vi snart i ett stort och för komplext designsystem. Men det är ofta enklare att bygga nytt än att ta hand om något befintligt. Ibland får vi påminna oss själva om det här, det kommer bli ännu viktigare framåt när vårt designsystem växer.
We want to think about all platforms (web/iOS/Android) when we add new components and patterns.
Själva bostadstjänsten Hemnet finns i tre plattformar. Webb, iOS och Android. På webben har vi ett gäng olika webbplatser som alla använder samma webbkomponenter. De största är hemnet.se och vår backoffice-tjänst för mäklare, Kundportalen. I native app-världen har vi ”bara” en Hemnetapp för iOS och en för Android.
Vi utvecklar komponenter i olika teknik för webb respektive native appar. Men många av våra designbeslut och mönster kan vara generella och fungerar lika bra i webb, iOS och Android.
En webbutvecklare eller designer som för tillfället jobbar med något för webben behöver ofta påminna sig om att försöka hitta mönster som vi kan använda i alla plattformar. Ofta kan vi vinna mycket på att tänka på samtliga plattformar när vi tar fram en komponent eller mönster i designsystemet.
Vissa saker kan behöver skilja sig mellan plattformarna men då ska det finnas en anledning. Som när det går betydligt snabbare att använda en native komponent rakt av än att designa en egen.
Jobba på Hemnet!
Om du är intresserad av designsystem och jobba i tvärfunktionella team så rekommenderar jag verkligen att jobba på Hemnet. När jag skriver det här söker vi bland annat utvecklare och UX designer.
Senaste året har det snackats mycket ost på Hemnet. Och då inte bara gouda, gruyere eller gorgonzola utan också Opportunity Solution Tree, ett visualiseringssätt och verktyg för utforskande.
Våra tvärfunktionella team jobbar både med att leverera lösningar som vi vet att vi vill bygga (delivery), och att utforska vilka lösningar vi vill leverera i framtiden (discovery). Delivery har sina utmaningar men är mer förutsägbart. Discovery är mer rörigt, iterativt och svårhanterligt. Vi jobbar med att förstå våra användare så vi kan prioritera rätt saker. Vi är kreativa och producerar olika lösningar. Vi gör experiment för att kolla om lösningarna fungerar för användare och affär.
Eftersom discovery är så rörigt har några av våra team anammat Teresa Torres Opportunity Solution Tree för att strukturera och visualisera sitt utforskande. En OST är ett upp-och-nervänt träd med:
En outcome högst upp, alltså ett övergripande mål vi vill uppnå. Outcome kan beskrivas som en förändring i användarbeteende som kommer driva våra affärsmål. Det finnas en massa att läsa om att styra med hjälp av outcomes, till exempel boken Outcomes Over Output.
På nästa nivå en hierarki av opportunities vilket är observerade användarbehov och användarproblem som kan bidra till vår outcome. Flera behov eller problem som liknar varandra kan grupperas i en övergripande opportunity. Till exempel skulle ”jag vill förstå hur man köper bostad” och ”jag vill veta ett jag kommer kunna låna pengar” grupperas ihop i ”jag vill vara förberedd inför ett bostadsköp”. Övergripande opportunities hjälper oss navigera i trädet och prioritera. Vi kan börja med att prioritera opportunities på högsta nivån vilket gör det hela mer hanterbart.
Varje opportunity kan ha en eller flera solutions, alltså lösningsidéer på hur vi kan lösa problemet eller tillgodose behovet. Lösningar kopplas oftast till specifika opportunities långt ner i trädet eftersom det är lättare att komma på lösningar på specifika användarbehov.
En opportunity kan valideras med hjälp av ett eller flera experiment. Alltså ett sätt att ta reda på om lösningen kommer bidra till vår outcome. Här kan vi använda hela UX-verktygslådan. Allt från kvalitativa användningstester eller intervjuer till kvantitativa A/B-tester, smoke tests eller enkäter.
Opportunity Solution Tree
Som UX-designer i Sverige känner man igen den här typen av visualisering. Det är i princip en effektkarta, med några små skillnader och den sista nivån experiment som tillägg. Den stora skillnaden är processen. Teresa Torres beskriver förstås den här visualiseringsmodellen i sin färska bok Continuous Discovery Habits. Men framför allt handlar den om en process för kontinuerligt utforskande i tvärfunktionella team. Det fina med processen som beskrivs i boken är att den är så konkret. Boken är kort och koncis och mycket av komplexiteten utelämnas. Perfekt för ett nytt team eller ett team som vill jobba mer strukturerat med discovery.
Opportunity Solution Tree har hjälpt några av våra team med att bli mer strukturerade och kommunicera bättre kring utforskande. Teammedlemmarna har en bättre helhetsbild av vilka användarbehov som finns, vilka vi jobbar med och vilka vi just nu väljer bort. Då och då samlas teamet för att planera nästa steg i sitt utforskande. Där använder man OST för att prioritera användarbehov och diskutera potentiella lösningar på de mest prioriterade användarbehoven.
Opportunity Solution Tree här har spritt sig till fler och fler team det senaste året, så nu har nog alla Hemnets produktteam jobbat med OST på något sätt. Väldigt roligt. Jag rekommenderar verkligen boken, tror den kan bli obligatoriskt lästips för alla nyanställda designers på Hemnet framöver.
Nådens år 2020 lider mot sitt slut. Det där uttrycket, ”i nådens år” låter lite ålderdomligt och apokalyptiskt. Tydligen skrev man så förr för att komma ihåg att varje nytt år är en oerhört fin och generös gåva från Gud. Tack för 2020. Dags att reflektera över vad som varit och hoppas på en lite bättre gåva nästa gång.
Under 2020 har Hemnets sex produktutvecklingsteam tagit stora kliv i skapa ett designsystem. Vi har idag en gemensam webbplattform med delade webbkomponenter som kan användas överallt. Vi har infört komponenter och vår nya grafiska profil på många ställen både i våra appar och på webben. Vi har kommunikationskanaler och forum där vi jobbar fram gemensam design, principer och komponenter.
Vi har gjort det här gemensamt och parallellt med annat produktarbete, utan att ha något team som ansvarar för designsystemet. Här tänkte jag berätta hur vi har gjort.
Hur allt började
När den här historian börjar (sisådär två år sedan) hade vi en webb-styleguide med lite gemensam styling och guidelines för hur vi använder bland annat typografi och färger. En bra grej men tyvärr hade den inte uppdaterats på ett tag, den användes bara av en av våra webbplatser (hemnet.se) och var webbspecifik. Designers använde den inte heller utan hade sina egna komponenter i Sketch. Både front end-utvecklare och designers ville göra detta bättre och mindre initiativ började poppa upp.
Vi började prata en del om fördelarna med gemensamma designguidelines och komponenter. Mindre dubbeljobb när byggstenarna redan finns, bättre kommunikation mellan utvecklare och designers, lättare för alla teammedlemmar att jobba självständigt och ta egna designbeslut.
Delar av Hemnets nya grafiska profil
2019 tog Hemnet fram en ny grafisk profil med hjälp av varumärkesbyrån Bold. Den innehöll bland annat nya färger, typografi och en tweakad logga. Vi ville förstås få det här att synas i våra webbar och appar men mycket återstod. Vi behövde komma fram till vad profilen innebär digitalt.
Det blev naturligt att dra igång på allvar med ett bättre designsystem och samtidigt införa den här nya grafiska profilen. Vi bestämde att designsystemet skulle bygga helt på den nya grafiska profilen. Det skulle också öka incitamenten för teamen att införa komponenter från designsystemet. Man kan använda färdiga byggstenar och får dessutom nya fräscha färger och typsnitt.
Verktyg och infrastruktur
Vår nya grafiska profil levererades i Frontify, en plattform för varumärken och grafiska profiler. Vi bestämde oss för att fortsätta använda den som ett innehållssystem för designsystemet och skapade tre delar:
Identity: Vår grafiska profil, det grundläggande som färger och typsnitt
Components: Gemensamma byggstenar för våra webbar och appar, plus guidelines för dem
Text: Guidelines för hur vi uttrycker oss i text och vilka ord vi använder
Vi använder Frontify som en samlingsplats för allt Hemnet-designrelaterat. Alla på Hemnet har tillgång och det går enkelt att editera text eller ladda upp bilder.
En stor del av designsystemarbetet har handlat om att göra det möjligt att skapa delade webbkomponenter som vi kan använda på olika webbplatser. Våra viktigaste webbar är hemnet.se och Kundportalen där mäklare loggar in och bland annat kan administrera bostadsannonser.
Guidelines och webbkomponent i Frontify
Kort om hur webbkomponentbiblioteket fungerar tekniskt:
Våra webbkomponenter utvecklas i ett eget Git repository, paketeras och importeras till våra applikationer (som Hemnet.se och Kundportal) med hjälp av npm.
Vi använder Storybook för att testa och visa upp komponenterna.
En komponent kan användas via React eller HTML/CSS – Storybook innehåller kodexempel för båda.
I Frontify visas guidelines för varje komponent, och själva komponenten från Storybook (delen med grå bakgrund i bilden ovan).
Androidvarianten av primär knapp i Frontify
För våra native appar (iOS och Android) finns förstås också komponenter men de är svårare att visa upp på webben. Där har vi i nuläget bara tagit skärmdumpar för att visa hur komponenten ser ut.
Våra designers jobbar numera i Figma. Där speglar vi (manuellt) komponenterna för att kunna använda i skisser och prototyper men det är de riktiga kodade komponenterna som är sanningen.
Hur vi jobbat
Vi har jobbat med det här i lite olika former under året.
I början behövde vi göra grundläggande arbete för att sätta upp Storybook och få våra webbar att använda gemensamma komponenter. Några representanter från olika team jobbade fokuserat med det under några veckor.
Under större delen av året har det handlat om att införa komponenter (inklusive ny grafisk profil) överallt, ta fram nya komponenter och vidareutveckla designprinciper. Vi har jobbat stegvis del för del och prioriterat de komponenter som används mest och gör mest skillnad visuellt, till exempel rubriker och knappar. Vi har prioriterat att införa komponenterna där de syns och märks mest.
En del av hemnet.se med ny design
En eller ett par utvecklare per team har varit designsystem-representant och fokuserat på detta någon dag i veckan. Ibland har vi haft en fast dag där alla jobbar tillsammans, ibland har det varit upp till teamet. Men vi har hela tiden haft ett möte varannan vecka där vi sprider vad vi jobbar med på designsystem-fronten och lyfter problem. Vi har också ett annat forum varannan vecka mer dedikerat till att diskutera designdetaljer.
I övrigt sker mycket av kommunikationen kring designsystemet i Slack. I kanalen #designsystem postar vi allt från frågor kring designdetaljer till tekniska frågor kring webbkomponentbiblioteket.
Allt det här har fungerat bra, mycket tack vare några personer (både utvecklare och designers) med extra engagemang för designsystemet. Tack!
En annan framgångsfaktor tror jag har varit vår inställning, att allt alltid kan ändras och inte behöver vara perfekt från början. Det är ju faktiskt tvärtom, nu när vi har gemensamma komponenter kan en smart förbättring införas överallt med en knapptryckning. Typ.
En tredje framgångsfaktor tror jag är att utvecklare och designers jobbat tillsammans hela tiden. På Hemnet är vi rätt vana vi det med det är ingen självklarhet överallt. Att designa och bygga saker funkar absolut bäst när alla inblandade har förståelse för både teknik och design.
I Dungeons & Dragons (rollspel) är en ritual en sorts trollformel som kräver extra lång förberedelse. Du kanske behöver rita upp ett pentagram eller koka en gryta på fladdermusvingar. När du väl är klar kan du uträtta något stort och häftigt, som att återuppliva någon som dött eller prata med djur.
I produktutvecklingsteam är en ritual en återkommande händelse, något som händer varje vecka eller månad. Precis som i D&D krävs lite förberedelse (göra bokningar) men resultatet blir ofta magi. Långsökt liknelse tänker du? You bet!
Ritualer på Hemnet
I Hemnets produktutvecklingsteam har vi både teamritualer och ritualer som är gemensamma för alla team.
Teamritualerna varierar lite från team till team men alla jobbar i tvåveckorssprintar, börjar sin sprint med en sprintplanering och avslutar med ett teamretrospektiv. Många har en daglig synk på morgonen varje dag och någon sorts förberedande möte inför nästa sprint (grooming) mot slutet.
Vi har också gemensamma ritualer för alla team för att promota kommunikation, samarbete och feedback. De har lite olika timing och de flesta är valfria:
Demo (60 min en gång per sprint, obligatorisk för alla) – teamen visar upp vad de gjort och lärt sig
Heads up (10 min en gång per sprint, obligatoriskt för en representant per team) – ett synkmöte för att lyfta beroenden mellan team
Design system status (60 min en gång per sprint) – alla som är involverade i att jobba med det gemensamma designsystemet berättar om vad som gjorts och lyfter saker man behöver hjälp med
Speedback friday (30 min en gång per sprint) – en möjlighet att få snabb feedback på vad som helst man jobbar med som du kan läsa mer om här
Design feedback (60 min en gång per sprint) – feedback-tillfälle med fokus på detaljdesign
Feedback friday (en gång per sprint) – varannan fredag bokar vi upp och träffar ett gäng användare för intervjuer och användningstester
Experiments (60 min en gång per sprint) – vi delar och förbättrar hur vi jobbar med experiment
Artikelklubben (30 min en gång per vecka) – alla som vill är med och diskuterar en intressant artikel/video som har med produktutveckling att göra
Jag tror det var alla! Vi har också ett gäng olika kompetensforum (front end, back end, UX, analys, arkitektur) som träffas lite olika ofta beroende på behov. Och ritualer som händer mer sällan, som kompetensutvecklingsdag och labbvecka.
Vad som gör ritualer magiska
Ritualer påminner oss om saker vi gör varje sprint så vi slipper tänka. Som att få feedback från andra team, kommunicera vad vi jobbar med eller dela kunskap. Vi skulle förstås kunna göra de här sakerna ändå men våra hjärnor är begränsade. Ritualerna gör att vi slipper tänka på allt vi måste göra i en sprint. Teammedlemmarna kan slippa tänka på när och hur man ska inhämta feedback eller visa vad man gjort. Det kommer automatiskt, även om det förstås kräver en insats varje gång.
Ritualer minskar mötesadministration. Det blir förstås en mindre insats att boka upp återkommande aktiviteter. Och när bokningarna redan finns där i folks kalendrar sedan länge blir det inget jobb med att hitta tider då alla är tillgängliga. När saker händer samma dag och tid varje vecka börjar man komma ihåg ritualerna efter ett tag vilket underlättar för vår stackars stenåldershjärna.
Ritualer kan pusha oss åt rätt håll. Att förändra hur man jobbar kan vara svårt och jobbigt. Flera av våra ritualer är uppsatta som en lösning på ett problem. ”Heads up” tillkom eftersom teamen inte tyckte sig ha tillräcklig koll på beroenden till andra team. ”Feedback friday” tillkom eftersom vi ville träffa våra användare oftare. Vi ska förstås hela tiden ha ett öga på problemet, finns det fortfarande? Är den här ritualen fortfarande en bra lösning, ska den tweakas eller tas bort?
De senaste veckorna har jag jobbat med att tillsammans med Hemnets produktteam definiera nya team missions. Alltså teamets syfte på lång sikt, en kort beskrivning av varför varje team existerar.
Vi vill att teamen på Hemnet ska vara autonoma för vi tror det är effektivt och skapar engagemang. Teamen ska själva sätta sina mål (vi använder OKRs) och jobba självständigt mot målen. Men för att kunna veta hur ett team ska kunna bidra till Hemnets mål behöver de förstå sitt uppdrag. Teamen behöver också förstå andra teams uppdrag för att veta vad de inte ska jobba med, samarbeta och hantera beroenden mellan team. Att sätta team mission löser inte allt men vi tror att det kan bidra till bättre diskussioner kring vad teamen gör och hur de förhåller sig till varandra. Plus ökat engagemang kring teamets egna mål och uppdrag.
Vi har sex team, där fyra av teamen är produktteam som ansvarar för ett produktområde. Produktområdesansvaret är mestadels skuret utifrån målgrupp – bostadsköpare, bostadssäljare, mäklare, annonsörer och partners. De övriga två teamen, appteamet och plattformsteamet, jobbar inte mot någon speciell målgrupp eller produktområde.
Det finns lite olika definitioner av mission och man kan lätt hamna i metadiskussioner om vad som är vad och vad ett mission ska innehålla. Så här har jag presenterat det:
Det ska rama in vårt teams syfte och ansvar är
Det får gärna innehålla vad vi gör, för vem vi gör det och varför
Det ska vara kort och koncist
Det ska vara vårt syfte idag, inte någon långsiktig ambition (detta är snarare vision tänker jag)
Hur vi gjorde
Våra team satte sina missions i en workshop som resulterade i en idé om mission statement. De fick börja med att svara på enklare frågor som ”om du träffade en ny kollega, vad skulle du säga att ditt team gör?”. Sedan fick de två och två komma fram till ett mission statement och presentera för varandra på den digitala whiteboarden i Miro. Där kom vi sedan fram till en gemensam mission genom att hitta gemensamma nämnare i förslagen och diskutera vad som skulle vara med, ord för ord.
En person (jag) faciliterade alla workshops, vilket rekommenderas. Man lär sig en massa, blir för varje gång bättre på att sätta rätt kontext och fokusera på det som är viktigast. Jag lärde mig till exempel att vara noggrann med hur vi definierar mission. Några team hade gjort liknande övningar förut och hade olika definitioner med sig in i workshopen.
Efter workshopen fick teamet feedback från produkt/utvecklingsledning utifrån helhetsbilden. Vi vill att bitarna i teampusslet ska passa ihop, att inget viktigt faller utanför teamens ansvar och att ett teams mission inte överlappar något annat team för mycket. Några team körde sedan uppföljningsworkshops, andra fick feedback och kunde enas via Slack.
Resultatet
Så här blev en av våra team missions:
Team Agent Products makes Hemnet an obvious choice for agents by giving them the best possible conditions to make successful property transactions and reach new customers
Någon vecka senare, när vi börjat prata om teamens mål för nästa kvartal, har jag hört missions användas i diskussioner kring vilket team som ska ansvara för vilket mål. Jag hoppas våra missions kommer fortsätta hjälpa oss framöver.
I lördags förmiddag höll Elin Bjurevall från Skandiamäklarna den första livestreamade visningen på Hemnet någonsin. Ett gulligt rött hus med vita knutar utanför Tystberga visades för ca 40 spekulanter. När jag kollade streamen blev jag helt varm i kroppen av stolthet. För en dryg vecka tidigare fanns ingenting. Noll.
Det är förstås en speciell situation med coronavirus och mycket av energin bygger på en vilja att hjälpa till. Minska smittspridningen på öppna visningar och förhoppningsvis bidra till att bostadsmarknaden inte dyker under krisen. Och vi har jobbat i ett högt tempo, ohållbart på sikt. Men det är ändå kul att reflektera över vad som hände egentligen. Hur kunde vi vara så snabba? Finns det något vi kan ta med oss i hur vi jobbar med produktutveckling även när det inte är krisläge?
Den öppna Slack-kanalen #hemnet-live startades 13 mars och kommunikationen exploderade snabbt. Här kan man se aktiviteten på Slack i alla kanaler:
Vi har sedan 13 mars skickat dubbelt så många meddelanden som vanligt och en del av ökningen beror på att alla jobbar hemma på grund av viruset. Men #hemnet-live står för en stor del av ökningen. Det har postats 1844 meddelanden i kanalen på nio dagar vilket är mer än vad som postats någon annan kanal på en månad.
Några saker som har kännetecknat kommunikationen i #hemnet-live:
Snabba svar. Ingen vill fördröja någon annans arbete genom väntetider. Det gäller också code review (som sker i Github), man har fått sin kod granskad snabbare än kvickt.
Snabba beslut. I normalfall kan det bli utdragna diskussioner om olika vägval. Här föreslog någon något, andra tyckte det var good enough och så körde man på det direkt. En viktig förutsättning var att det var tydligt kommunicerat ”uppifrån” att vi som jobbade med tjänsten hade mandat att ta beslut själva.
Transparens. Vi har vanligtvis en kultur av att visa upp och få feedback på det vi gör. I och med Hemnet Live boostades även den. Kanalen var öppen och vi var flitiga med att visa upp halvfärdiga fulskisser, få tidig feedback på copy, testa lösningar och dela idéer. Mycket av kommunikationen var visuell. Visualiserade flöden, skärmdumpar, skisser.
Ständiga diskussioner om målet. Vårt mål var att komma ut med livestreamade visningar till visningshelgen vecka 12 men exakt vad som skulle finnas på plats visste ingen. Vad måste vara på plats för att vi ska kunna komma ut? Vad kan läggas till senare? Vad kan göras manuellt? Vårt mål var inte att ha en perfekt lösning ute från början, utan att komma ut snabbt så vi kunde lära oss vad som fungerar.
Det där sista, att bygga en halvfärdig men så bra lösning att den kan användas fullt ut, tror jag vi kan bli ännu bättre på i normalläge. Vi pratar ofta om att jobba med MVP (Minimum Viable Product) eller RAT (Riskiest Assumption Test) – men gör vi verkligen det? Kan vi fuska mer och lära oss snabbare?
Efter den här första visningshelgen har ca 50 mäklare livetreamat sina visningar. Vi har snappat upp mängder av frågetecken och problem från både mäklare och besökare. Vi har kunnat delta själva och fått en känsla för vad spekulanterna upplever. Vi kan nu förklara för mäklare vad de bör tänka på för att göra en bra onlinevisning. Vem hade till exempel kunnat förutse att vissa mäklares skor med hård sula skapar ett ljud som tränger igenom allt prat?
Insikterna vi fått från riktig användning gör att vi nu, vecka två, kan fokusera på att fixa rätt saker istället för att bygga potentiellt onödiga saker eller lägga tid på att spekulera kring potentiella problem. Det är verkligen guld värt och något jag hoppas vi tar med oss framåt.
Med det sagt, otroligt imponerad av alla kollegor som gjorde detta möjligt. Ni är bäst!
Helt Sonika 