Leveraging the power of Android design language
Plum, since its first days until now, has always been a money management app, that not only grows your money but also helps you to be better off, being friendly, funny, and direct at the same time.
A financial AI assistant with personality.
Back in spring 2019, Plum decided to sift through the leading AI chatbot assistant connected with Facebook Messenger, in order to become a mobile-first company. Then we started discussing the choices we were going to make to create the first version of the Plum Android app.
We had to translate this AI personality into a specific design system. A beautiful, modern app that can “sparkle” as the chatbot did, speaking not anymore with words, but with its own application design components.
Thus, one of the substantial decisions we quickly had to make was the design language we wanted our app to “speak”.
In this article, we are sharing our experience of creating a consistent Android design language. How we applied it to the app from the setup of the Android project and the benefits such an application has in the project, for the team, and the scaling of a digital product.
Creating the design language
The design language is the set of rules that apply to the reusable visual elements of a digital product and ensure coherence and harmony across all its parts.
However, while design language creation might sound like a designer topic, the truth is that the creation of the design consists of three main actions:
1. Customising your theme
2. Applying it across your design mocks
3. Using it in code
Customizing your theme
To bring our vision to life, we needed to set the grounds for the design language of the Plum Android app. Our choice without a second thought was to follow the Material Design guidelines for Android applications.
Not only can this give you the foundation of a design language, but the AndroidX Material Design Components library can help you in the development cycle too, as reusing the material components can save you precious development time.
Above all, this is the easiest way to provide common design language “words” among many of the modern Android applications and make your application look familiar to the platform users.
Customizing your theme is like creating the first substantial letters of your design language.
Our designers put together strong typography branding, specific colors and variations, iconography and language and enabled us to create the alphabet of our design language:
Usually, this set of rules and templated reusable components can be found in a project that your design team has created in the tools they work with, and is something like an interface inventory or a component library:
Applying it in design mocks.
After creating the alphabet of our design language, it was easy for us to start putting together the real designs of the Plum Android app.
When the development of a feature is decided, we start by creating a simple mockup of the feature, and after this mockup is agreed upon, we start the design task. This is when our designers apply the design language and the alphabet of our design language starts forming its first “words”.
Having the design language elements already in a design library, the creation of the screens is easy and quick and can be always consistent across all the parts of the app.
Thus, the design task becomes simpler and faster for the designers, helping to the internal efficiency of the team they work in, while providing a unified user experience to the end-users.
Using it in code
Translating our design library was an exciting task, as the Plum Android design library was based on the Material Theming guidelines. On Android, Material Theming can be implemented using the Material Components (MDC) library, from version 1.3.0 onwards.
Color resources
After our designers put together one of the foundation elements of the design library, the color palette, colors were added in the Plum Android project.
We created a single res/values/colors.xml file and stored our colors and color variations there, using literal names and avoiding semantic names:
Theme
Next, we created our base theme that was going to inherit and implement Theme.MaterialComponents.
We applied our color palette and look & feel elements in the base Plum application theme, transforming the design choices of the design library into code.
Our res/values/styles.xml file was created, like this:
Text appearance
Material Design provides 13 types of styles that are applied to all the text in your app:
So we created our type dimensions with dimension values to be defined as <dimen> resources. We created a single res/values/dimens.xml file:
Finally, we created our TextAppearance styles. We created a single res/values/text_appearances.xml file where, beyond the text dimensions, we also applied all the other attributes of the text styles:
Material theming in Material Components
We also applied Material Theming in all the Material Components our app implements and uses.
Having set the correct base colors, and typography in the parent style, helped save time in the implementation of the theming of the Material Components, as the properties of their styles would only override the style defaults if needed.
Mind that each component has specific instructions on how to implement the Material Theming.
Our res/values/styles.xml file was transformed to this:
Custom views
Going one step further we decided to code the main UI components of the app beforehand and have them stored into a design library but inside Plum Android project this time.
Thus, we created a :ui module where all our custom views are stored and is a dependency of our feature modules that contain user-facing features.
These views do not contain business logic, they are just wrapping all the attributes and the variations of all the components of the Plum Android design library.
For example, let’s focus on one of the most important custom views that Plum Android :ui module has, PlumMenuRow.kt.
PlumMenuRow view helps us portray all our menu row variations that are designed in the Plum Android design library:
The attributes of this custom view, helps us customize the look and feel of every PlumMenuRow usage:
Implementing a feature
Let’s focus now on the creation of a feature, for example, Plum Android’s version information screen and feedback center.
This layout can be just implemented by a sequence of PlumMenuRows inside a ConstraintLayout.
Having our common views already developed as custom views helps us create the layouts of our features almost instantly.
Also, the already set TextAppearance styles can help our text views have the absolute correct style by just setting the android:textAppearance="@style/PlumTheme.TextAppearance.xx" attribute.
Thus, layout design becomes more time-efficient and less error-prone for the developers.
No need to reinvent the wheel and take serious decisions every time a screen needs to be implemented.
But is this only about design?
The design language creates the personality of the product, a unique identity that helps your mobile app stand out in a group of similar products. Users also feel a consistent, solid, enjoyable flow and an experience that the whole mobile ecosystem has trained them to be familiar with.
The first version of Plum Android app was released in November 2019. Since then, the product team has grown 3 times (and it is still growing, check here for open vacancies 👉 https://apply.workable.com/withplum). More than 15 big features have been implemented and the Android project is five times bigger than the first MVP, containing more than 180 screens.
The creation of the design language started at the beginning of the project in collaboration with designers and Android engineers, and it is still evolving day by day. Having the Plum Android design language in place, not only as a design library but also a :ui module, was one of the best choices we got when we started and a great investment in time for the Android Plum project.
Moving forward in time, this has enabled designers and developers to deliver fast, and precisely the designed screens of the features and has also given the opportunity to the cross-functional teams to create, modify and iterate on the product in a quick and cost-efficient manner.
Because setting the design language of your application is not an art performance.
It is an engineered task that, when following the correct guidelines can help your team’s productivity increase and speed up the design and development process while creating a unique mobile product!
