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

Compose-ing a Design System at Deezer

Jean-Baptiste VINCEY
April 27, 2023
570

Compose-ing a Design System at Deezer

Since Jetpack Compose went stable almost 2 years ago, the enthusiasm for this technology has continued to increase, and its adoption for new projects is a no-brainer. However introducing Compose in a very large and long existing codebase is another story.

At Deezer, we have been working with a Design System for several years now to enhance productivity and consistency. The synergy between Design System and Compose, thanks to composition, seemed a huge opportunity for us to accelerate future developments while creating delightful new experiences. Therefore we established a strategy to migrate our Design System and use Compose in new features, as well as migrate the existing ones. Here are the different steps:
Migrating an existing page entirely to get acquainted with the new paradigms introduced by Compose
Defining a roadmap to initiate a new Compose Design System following Atomic Design principles
Designing our components API to foster reusability and flexibility, for instance by using slot APIs and UI components models
Specifying shared guidelines and standards for both our new Design System and Compose developments

Our return on experience will help you discover possible solutions, better understand the pitfalls to avoid (as we fell into some of them) and see what strategy you could apply to migrate your own apps to Compose.

Jean-Baptiste VINCEY

April 27, 2023
Tweet

Transcript

  1. Why migrating to Compose? • Less code: do more with

    less code and avoid entire classes of bugs, so code is simple and easy to maintain. • Intuitive: just describe our UI, and Compose takes care of the rest. As app state changes, your UI automatically updates. • Accelerate development: compatible with all your existing code so you can adopt when and where you want. Iterate fast with live previews and full Android Studio support. • Powerful: create beautiful apps with direct access to the Android platform APIs and built-in support for Material Design, Dark theme, animations, and more. • New: as developers, we always jump right away on what’s new, don’t we? OK, actually Compose is not “so” new anymore, as it has been stable for more than 1.5 year • Trendy: we can’t count the number of posts, talks and meetup about Compose. It might even be the most trendy topic for a few years now! • No choice: we actually don’t really have a choice, do we? The former toolkit is being deprecated is will receive less and less support • Lorem ipsum: lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui o ffi cia deserunt mollit anim id est laborum.
  2. Solutions • By component • Pick a component • Review

    of all app screens Migration strategy Approaches
  3. Solutions • By screen • Pick a whole screen •

    Rebuild all UI components Migration strategy Approaches
  4. Migration steps Migration strategy Step 1 • Pick one existing

    screen • Representative of the product • Wide range of common elements • Our candidate : the album page Migration steps Migration strategy
  5. • Create from scratch UI when preserving model • Keep

    both screen versions with remote switch Step 2 Migration steps Migration strategy
  6. Step 3 • Create the Compose component • Integrate it

    in target page Design System Migration steps Migration strategy
  7. Step 3 • Repeat! • Until the screen is complete

    Design System Migration steps Migration strategy
  8. Follow Atomic Design principle Tokens 
 Colors, typographies, shapes… Atoms

    
 Buttons, icons, switches, progress bars… Migration steps Migration strategy Migration steps
  9. Follow Atomic Design principle Tokens 
 Colors, typographies, shapes… Atoms

    
 Buttons, icons, switches, progress bars… Migration steps Molecules 
 Cells, cards… Migration strategy Migration steps
  10. Follow Atomic Design principle Tokens 
 Colors, typographies, shapes… Atoms

    
 Buttons, icons, switches, progress bars… Migration steps Molecules 
 Cells, cards… Organisms 
 Pagers, expanded headers… Migration strategy Migration steps
  11. • Continuous API building and evolution And after? • Next,

    all new features will use the new API Migration steps Migration strategy Migration steps
  12. Design System app • Have a dedicated application for Design

    System Agnostic from your features • Acts as • Catalog of your components • Playground for testing components capabilities Migration strategy Test our components
  13. Shared library DS Deezer App DS AnOtherApp by Deezer DS

    Building our API 2 levels of Design System
  14. • Passing fi elds in components signature 𐄂 • Passing

    domain models 𐄂 Building our API //TrackCellData
  15. • Passing fi elds in components signature 𐄂 • Passing

    domain models 𐄂 • De fi ning UI model per component ✔ Building our API //TrackCellData
  16. • Passing fi elds in components signature 𐄂 • Passing

    domain models 𐄂 • De fi ning UI model per component ✔ Building our API //TrackCellData
  17. Improvement areas • (Better) accessibility management • Test automation plan

    review with test tags • Technical tools to diagnose our application Building our API Improve our product
  18. What did we create? • A new design system totally

    in Compose and SwiftUI • Tokens 100 % • Atoms 80 % • Molecules 55 % • Organisms 35 % • 2 UI-dedicated applications Our experience Outcome
  19. What is our status? • Album screen migration • Status

    in QA ! • About 4 months for 2 developers • + all new features starting 2023! Our experience Outcome
  20. Constant API revision • Components naming and signature • Notion

    of slot API • Alignment between iOS and Android APIs Our experience Feedbacks
  21. Sync with feature teams Unexpected circumstances • Design system not

    ready • Dependencies between features Our winnings • Implication in Compose from all team • Challenge during API building • Awareness of good practices design system, accessibility, multi-screens Our experience Feedbacks
  22. Takeaways • Migration strategy • Component versus screen • Design

    System with atomic design approach • Design System API • Theme material versus custom • API building Slot API versus typed API • 2 levels Design System generic and app • Further improvements accessibility, UI tests and large screens