Design System Android – A Problematic Situation

Reading Time: 5 minutes

Prologue

Picture this: you are an Android dev, and a new feature needs to be implemented. It’s a small screen, fairly straightforward layout, some inputs, nothing fancy.

And here you are, on one screen you got the Figma document open, in the other screen your IDE. You see this new button, seems a little bit larger than what you have in the rest of the app. It’s probably just a minor mistake on the designer’s part. You decide to use the regular size for the button.

And here’s where the fun begins.

Just to be sure, you ask your iOS buddy about this size thing. He ends up telling you that they use a totally different system to handle button size. They are doing their own thing.

Of course they do. You think. They are the inferior platform after all. They need to do things a la “Apple way” and follow what mum has to say.

You also check with your Web counterpart, but he ends up in a 30 minutes rant about CSS, breakpoints, browsers, javascript, oil price, and if the moon landing was real 🤷‍♂️

Design review time, you feel calm and confident.
Here come the results:

✅ iOS
❌ Web
❌ Android

This is outrageous!
It’s unfair!

How’s that possible, after all, you did your best, and your design is pixel-perfect.
Could it be that pesky button?
And indeed it is.

All of you, together with your designer, decided to align all buttons on all platforms.
You add your task in the backlog, but you noticed something, there’s a similar task:

[Android] SUP-163249: Align checkbox to iOS

You don’t recall anything like that, perhaps before your time. You start investigating and you see that indeed the checkbox is also different on all platforms.
But that’s just one small part of it, you notice far more drastic differences, mismatching colors, and different font sizes. Web doesn’t even use text limit on their inputs.

Where does it end?

🎨 The Design System

The ☝️ story was an exaggeration but I’m pretty sure something similar happened to you at some point. We noticed that and decided to address it. Basically, we started this cool side-project called The Design System, which as the name suggests, is a set of standards to organize design across platforms, tools, teams, etc…

Ideally, the design system should do the following:

Create consistency
Boost efficiency
Lower maintenance
Provide transparency

We will not go into too many details about it now.
In this blog post, we will focus on the Android decisions on how to develop such a system because we had a problematic situation.

The problematic situation

At the time we started working on the design system, Jetpack Compose was released out of beta.
But you might ask, what’s Jetpack Compose? 🤔

Jetpack Compose is Android’s modern toolkit for building native UI. It simplifies and accelerates UI development on Android. Quickly bring your app to life with less code, powerful tools, and intuitive Kotlin APIs.
from Google

TL;DR: It’s a more modern way of building UI, sort of Google’s response to React, Swift UI, and all the declarative frameworks that have grown in popularity in the past years.

And oh boy is Jetpack Compose a game changer. For us Android devs it’s the same jump as we had from Java to Kotlin 🚀

Ok, but why is that a problem? This is good for you, right?

Well, you see, both our apps are still using the XML/View system, the old UI toolkit.
So the question was, what should the design system be written in?

XML/View System vs Compose

So we had to think about what to choose for our Design System implementation. And what better way to take this decision than a PRO/CON list, on the left we have XML and on the right, Compose.

As you can see, Compose definitely overshadows XML in every aspect. But the tradeoff is that it will be harder to integrate into current apps: none of them contained any Compose code! We had plans to start the migration but we decided to wait for the design system to see if maybe it could help in the migration.

Of course, there were other factors as well, but in a 🥜, we ended up choosing Compose!

Not so fast

So we started implementing some stuff, colors, typography, icons, etc… And as we tried to integrate them into current apps we noticed that it wasn’t that easy. The challenge was especially harder for higher-level components such as the Button.

Didn’t you take that into account before?

It’s hard to foresee every single aspect, and nonetheless, we were still playing around, trying things and seeing what would be the best approach. This was but a minor setback, a lesson learned.

Take two: We ended up choosing a hybrid XML-Compose approach! BUT with Compose as 1st class citizen, this way we could force ourselves to speed up the migration into current apps. Ideally, new features would be developed directly in Compose, and in the meantime, we would use XML or Compose, depending on the situation, for older parts of the app.

The hybrid design system

Turns out it’s actually not that hard to implement a hybrid system for that. There are some limitations here and there, but overall it’s doable.

Bla Bla Bla, just show us the Design System!

Hold on, this blog post is getting quite long and I would like to go into more details for specific topics such as: design tokens, themes, how our design system works with the material one, hybrid components, and much more! But for that, stay tuned for future blog posts. For now, I’ll leave this sneak peek of our playground app 🪅

P.S: Actually the library itself is public! So if you are curious about what we are doing, check our GitHub
🚧 Just note that we are still trying things, the library is still in its inception phase 🚧

Additional Resources

I’ll leave here some cool resources that helped us in our journey:

Author: @GhimpuLucianEduard