Bij die factuurlijst kwam ik hetzelfde patroon tegen: in plaats van één lijstcomponent waren er acht, elk gemaakt voor één situatie. Daarom maakte ik me hard voor een herstructurering van de app en een multi-brand design system voor mobiel. Allebei moesten ze zo modulair zijn dat ze nieuwe producten, merken en situaties kunnen opvangen.
Een app voor één soort klant
Wie de app opende, kwam op het dashboard van zijn mobiele abonnement. Tv en internet zaten achter een aparte knop, en zelfs berichten waren per domein gescheiden: een internetstoring vond je op het dashboard van internet. Daardoor was het lastig om proposities bij elkaar te brengen en nieuwe initiatieven van de business in de app te krijgen. Het was tijd voor een herstructurering.
Elk product een eigen plek
Mijn voorstel was een structuur rond de producten van de klant, met ruimte voor nieuwe initiatieven uit elke afdeling, zonder dat het ene product ten koste gaat van het andere. Nieuwe ideeën uit de business zijn dan welkom, in plaats van dat ze stranden op “dat past niet in het ontwerp”. Zo heeft de gebruiker overzicht over al zijn producten, spreekt T-Mobile vanuit één kanaal, en wordt de app ook een sterker kanaal voor communicatie en marketing.
Die structuur wilde ik in kleine stappen bereiken: alle services in één overzicht, alle communicatie op één plek, en tot slot niet meer de interne organisatie van T-Mobile (Mobiel en Thuis) spiegelen in de app, maar het laten aansluiten op de beleving van de klanten, namelijk producten. Voor productteams is het minder risicovol om kleine stappen te maken dan een grote verandering die maanden kost. En gebruikers groeien zo geleidelijk mee, in plaats van dat ze van de ene op de andere dag een heel nieuw ontwerp voor hun kiezen krijgen.
Om te toetsen of de stappen behapbaar waren, zette ik een usabilityonderzoek op en bouwde ik het prototype. Zes klanten liepen door vier flows. Een aantal van hen zag nauwelijks wat er veranderd was. Precies waar kleine stappen voor zijn. Tegelijk vonden ze de nieuwe onderdelen moeiteloos: vijf van de zes zagen het nieuwe verlengaanbod meteen, en de meesten vonden hun abonnementsgegevens nu zonder te zoeken.
Iemand wel of niet op de schouder tikken?
Met een centrale plek voor berichten kwam ook de vraag wie wat naar klanten mag sturen. Pushnotificaties waren een hot topic; iedereen zag er kansen in. Maar overlaad je klanten met meldingen, dan zetten ze die uit.
Daarom organiseerde ik een workshop met drie PO’s van verschillende merken en teams en twee mensen van de klantenservice. Eerst schreef iedereen alle berichten op die ze naar klanten wilden sturen. Daarna vroeg ik ze zich een klant voor te stellen die rustig in een koffietentje zit. Welke berichten zijn belangrijk genoeg dat je naar die persoon toe loopt om op zijn schouder te tikken? Zo werd voelbaar dat een notificatie iemand stoort, en alleen gerechtvaardigd is als je echt helpt. We eindigden met een strategie en een geprioriteerde lijst voor de maanden erna.
Hetzelfde patroon in de componenten
Toen ik de lijst met facturen moest ontwerpen, had ik voor de app nog geen componenten tot mijn beschikking. Ik werd gewezen op de webcomponenten in Figma. In plaats van één ListItem vond ik acht losse lijstcomponenten: een voor een prijslijst, een voor een linklijst, een voor een productlijst, enzovoort. Acht keer hetzelfde ding, elk met een eigen reeks varianten: een variant explosion. Net als de app waren ze gebouwd voor één situatie.
Wat wil een component zijn?
Ik deelde mijn bevindingen met de design lead en stelde voor om het voor mobiel anders aan te pakken. Ik betrok er twee andere designers bij, en in wekelijkse sessies legden we samen het fundament voor een mobiel design system. Elk component kleedden we uit tot de kern. Wat wil dit component in essentie zijn? Wat verwacht iemand als hij het ziet en ermee werkt? Hoe bouwen we het agnostisch van context op, zodat we het overal kunnen toepassen? Die vragen leverden onze beste discussies op. En gedurende het project bouwden we niet alleen componenten op maar ook gedeelde principes en taal.
Omdat de app ook voor Ben en Tele2 moest werken, bouwden we in lagen: multi-brand foundations, een theme per merk, en componenten die bij het wisselen van merk de kleuren, letters en vormen van dat merk overnemen.
Developers meenemen
De PO en de tech lead van het mobile team betrok ik er vroeg bij. In een kickoff voor het iOS- en het Android-team legde ik uit wat we gingen doen en waarom: geen redesign, maar een gedeelde manier van werken. Elke keer dat we een scherm raakten, maakten we van de herbruikbare elementen componenten, waardoor we beetje voor beetje efficiënter en sneller zouden worden. Elke maand haalde ik de developers en de PO bij elkaar om te laten zien wat we gemaakt hadden en waarom het ze zou helpen, zodat niemand werd verrast.
Wat er na Odido overbleef
In mei 2023 ging al het lopende designwerk on hold vanwege de rebranding naar Odido, die toen voor mij nog geheim was. Dat gold ook voor de herstructurering. In juni vertrok ik.
Het design system zelf kwam niet ongeschonden door die overgang. De foundations en de principes wel: de twee designers met wie ik had gewerkt bouwden er later, samen met een derde designer, het Odido design system op.
Dieper graven
Een factuuroverzicht ontwerpen lijkt een eenvoudige klus. Maar als je wat dieper graaft, stuit je soms op onderliggende problemen die de moeite waard zijn om op te lossen. Daarom graaf ik bij elke story even door om te zien of er wat interessants onder ligt, hoe klein het ook lijkt.
