Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Extreme rebranding at Deezer

Extreme rebranding at Deezer

Only 3 months to rebrand the whole Deezer application, how do we do that?
1 year ago, we presented our Design System migration to Compose, we didn't realize we would face such a challenge right after.
Extreme rebranding, 3 months to change it all: challenge accepted!

In this talk we are presenting the birth of the new Deezer brand identity, and how we managed to integrate it in a record time.

Jean-Baptiste VINCEY

April 24, 2024
Tweet

More Decks by Jean-Baptiste VINCEY

Other Decks in Programming

Transcript

  1. New challenge Rebrand the application ! Due date: 7th November

    Accept In 3 months, really ? Challenge Accepted
  2. Rebranding motivations • Rejuvenate Deezer image in the eyes of

    18-25yo • Brand new positioning to be distinguishable • Commitment reinforcement towards fans, artists and partners • Graphical identity stronger
  3. Application inventory No idea where we're going at that time.

    What we have: • Many layers of architecture and design updates • Old colors, styles, icons and themes, not from design system • Magic values here and there Final design won’t be available before September • Deezer logo everywhere
  4. What would you do? Run! Go on vacation Rewrite the

    whole application in Compose in 2 months Rebrand the app in a Barbie theme
  5. app

  6. Let's change to a pink app with Comic Sans MS

    font and a generic icon app
  7. Restructuring Design System foundations Improving consistency across token structure: 1.

    Core tokens • ColorCore.Red100 = Color(0xFFF44336) • ScaleCore.X0_125 = 2.dp 2. Semantic tokens • ColorSemantics.background.primary.default • ScaleSemantics.radius.xs
  8. Meanwhile… Design team is working hard! • Powered by Koto

    Studio • Translate sketches with our technical constraints • App sketches, website, communications…
  9. Ideation • Still no validated designs BUT • Several explorations

    presented • Designers have many ideas • They want to assess feasibility
  10. Pre-mortem What could go wrong? Context: • Design expected for

    tomorrow • App must be released on November 7th at 7pm • No beta possible (usually 2 weeks of beta) • No progressive rollout
  11. What could go wrong? Scope / priority changing on the

    run Big rush until the last minute Designs are too ambitious Assets (icons / logo) not ready on time
  12. Find the matching action for each risk Prioritize assets and

    deliver by batch Management to commit on scope / priority Do not plan new development on last sprint Propose alternatives / tradeoffs technically simpler ? ? ? ? Scope / priority changing on the run Big rush until the last minute Designs are too ambitious Assets (icons / logo) not ready on time
  13. Find the matching action for each risk → → →

    → Prioritize assets and deliver by batch Management to commit on scope / priority Do not plan new development on last sprint Propose alternatives / tradeoffs technically simpler Scope / priority changing on the run Big rush until the last minute Designs are too ambitious Assets (icons / logo) not ready on time
  14. Scrum of Scrum • 1 representative per stack to collect

    and dispatch information • Standard scrum rituals • No meetings for devs Methodology Reinforcement from other teams
  15. Team spirit Product, design, tech teams : All for One

    ! • Common goal • Alignment on priorities Let’s put a little water in the wine • Continuous communication • More fl exibility • More autonomy and initiatives
  16. Testing flow Merge fi rst Feedbacks channel Delivery every day

    with Firebase distribution QA by batch + employees tests
  17. //Composable @Composable fun TempoButton(…) {…} Integrate both in Compose &

    XML //Custom View class TempoButtonView(…) : AbstractComposeView() { @Composable override fun Content() { TempoTheme { TempoButton(…) } } } //Usage in XML layouts <com.deezer.tempo.buttons.TempoButtonView android:id=“@+id/button" …
  18. Delivery strategy • Code freeze 2 weeks ahead of D-Day

    Managed publishing Deploy November 7th at 4’ • Prepare a hot fi x version to submit on D-Day+1 Balance between risk/value
  19. D-Day: Backstage On site duty • Frontend go live •

    Update of images and editorial contents • CRM campaign to encourage apps update Monitoring • Vitals • Crashlytics
  20. Impact on customers • Increase of customer base • Positive

    impact on brand consideration Impacts on product Impacts on installations
  21. Takeaways • Design System, Design System, Design System • Deliver

    technical updates in advance (player / tokens structure) • Anticipate what might go wrong with pre-mortem • Prioritize to maximize the impact • Adapt process (e.g. scrum of scrum, give autonomy to propose alternatives) • Deliver continuously to get early feedback loop • Rely on monitoring tools and follow reactions