Integrate design language in Android app
Fewer errors -> More Productivity -> Happy Team -> $$$
The audience for this article
You should read this article if
- You have some experience in Android development
OR - You are a designer and tired of developers making small & repetitive mistakes. You find inconsistency from time to time. You feel there is some friction between your design and development team
OR - You are a product manager and you find your team taking too much time for mundane tasks
OR - You have nothing interesting to do and want to learn something new
Let’s set some base
One reason behind project delays is communication between teams. That’s why most companies invest in tools, team-outings, sprint planning/retrospective, Stand-ups and what not. Sometimes, we do not realize there is some friction unless we come across a solution.
Our Story
We were doing okay between our designer and developers communication. Our design sprint is mostly planned ahead of the development sprint and we use Sketch to design + Zeplin to communicate. However, Zeplin does a decent job of communicating the design properties (colors, dimensions, styling, etc.), we found ourselves spending more time than required, repeating in the codebase and different developers had a slightly different way of working. It was manageable until we started growing. Overall, we were not under the bus but there was a scope of improvement.
Communication
In Software development, we use the term “Design Pattern”
A design pattern is a general repeatable solution to a commonly occurring problem in software design
Software design patterns not only help in faster development but communication also. When someone in the team says I am using Singleton pattern here, everyone grasps the context and the same mental model helps the communication flow.
Communication between design and development teams
Our designers had access to good tools and they had a set of components in place but they were sharing raw values along with the developers which got the job done in a small team but as we grew, we saw the inconsistency, unwanted delays, the same design implemented in multiple ways, a sense of slow down and found ourselves repeating over and over.
We realized a common language missing between designers and developers, design language — communication with design.
“A set of rules or guidelines that heightens the level of harmony in a digital ecosystem.”
Before I proceed into details, let me show an example
Old vs New Scenario
Let’s say you have one Text heading in your design. You can share your design in some tool and developers can get the specifications by hovering/clicking etc. Example:
In the above example, the tool is showing the required specs. The typeface, the size of the text, the color used, etc. At first glance, it seems simple and easy. It has everything you need. What could be a better way than sharing everything in one click? Do you see any problem? Try not to reading ahead unless you spot one.
The thing is this solution does not scale. Every product needs design and development at every stage of its life. When you have always an ongoing design/development, multiple people working, new people joining, old people leaving, this system makes you terribly slow and digs unknown maintenance holes.
Possible Issues
There is a possibility the new designer used a little different size/space/color/spec. Let’s just say for the sake of argument the designers will not make mistakes given the tools they use.
How about developers? Every time a developer picks a task and if he/she has to find the color code/size/spec it is a lot of time waste. What if someone created a utility earlier and this person is unaware and he/she implements something of her own? What if the developer has some doubt and he/she has to wait till it is clarified by the design team? What if the similar component is implemented in a little different way leading to slight variation in the final outcome?
Not to forget the changing nature of products! What if we need to update some component, say your main heading becomes 20px instead of 18px. Your color schema changes. Your new design demands some experimentation and flexibility. You get the gist!
Every product has a design identity and who would want to follow a process which leads to discrepancies.
What if I say you can reduce the communication friction, ensure right spec every time, ensure minimal developers time, easy navigation, allows changes in a fraction of time, encourages experimentation, facilitates good communication and prone to fewer errors. I know it sounds like election propaganda/a false promise.
Use the system at hand, and do not fight the system.
Design Language Scenario
Same Example with defined Text Styles
Instead of saying 14 px, Gotham-Bold, line height 1.3x, color #xxyyzz; All you need to say is H2/H1 and the color comes from the theme. Do you see how much easier it is to communicate, modify, and read?
Text is only one aspect of any product. Design language encompasses everything you, as a designer deem important. It could be layouts, text, themes, custom elements etc. The point is to make communication very easy with fellow colleagues.
I suggest you keep your style guidelines and color schema little separate. Your color schema is a part of the theme and Android offers superb ways to implement. Here is one article on theming.
With the subtle example of text styles, we see it becomes very easy if we have a common language defined. It not only facilitates communication but leaves very less space for errors and modifying something becomes a breeze. (H2 to H3, 40px in H1)
Implementation
As I mentioned before design language can be as vast as you want it to be. Designers and Developers have to make this conscious call what to consider and what not to!
What we implemented (This section is For Developers)
We figured let’s introduce the design language slowly. We focused on two parts, typography and theming inside the app. Typography because it touches the whole app and it is a deal-breaker in the design world. Theming because we have a lot of games inside our app and each game has its own color schema.
Theming
We divided our app into two schemas. One with a light background and dark text (default of our app )and one with the dark background and light text (most games fall here).
We created two base themes,
<style name=”AppTheme.Default”>
</style><style name=”AppTheme.Dark”>
</style>AND We extended a lot of themes from dark theme<style name="AdrenalineTheme" parent="AppThemeNorm.Dark"> <item name="theme_contentBackground">@color/adrenaline_2</item> <item name="theme_bgAssociatedColor">?theme_contentBackground</item> </style> <style name="CoffeeBreakTheme" parent="AppThemeNorm.Dark"> <item name="theme_contentBackground">@color/coffee_break_3</item> <item name="theme_bgAssociatedColor">?theme_contentBackground</item> </style> <style name="CoordinationTheme" parent="AppThemeNorm.Dark"> <item name="theme_contentBackground">@color/coordination_3</item> <item name="theme_bgAssociatedColor">?theme_contentBackground</item> </style> <style name="EmotionTheme" parent="AppThemeNorm.Dark">
<item name="theme_contentBackground">@color/emotion_3</item> <item name="theme_bgAssociatedColor">?theme_contentBackground</item> </style> ........ and many more
Usage
- We can simply use any of the theme in the GameActivity with setTheme (Learn more about theming in Android here)
- We can inflate any view with any theme using context theme wrapper ( Check this well written article on Context Here )
After theme in place, it is very very easy to change a theme of any game OR modify the theme.
Typography
We created a few text styles
<style name="H1">
<item name="android:textSize">35sp</item>
<item name="android:lineSpacingExtra">9sp</item>
<item name="android:textColor">?theme_textColor</item>
</style>
<style name="Title">
<item name="android:textSize">18sp</item>
<item name="android:lineSpacingExtra">5sp</item>
<item name="android:textColor">?theme_textColor</item>
</style>
<style name="MainButton">
<item name="android:textSize">18sp</item>
<item name="android:lineSpacingExtra">0sp</item>
<item name="android:textColor">?theme_textColor</item>
</style>
<style name="Body">
<item name="android:textSize">14sp</item>
<item name="android:lineSpacingExtra">4sp</item>
<item name="android:textColor">?theme_textColor</item>
</style>
<style name="H2">
<item name="android:textSize">24sp</item>
<item name="android:lineSpacingExtra">5sp</item>
<item name="android:textColor">?theme_textColor</item>
</style>
<style name="Footnote">
<item name="android:textSize">9sp</item>
<item name="android:lineSpacingExtra">3sp</item>
<item name="android:textColor">?theme_textColor</item>
</style>
<style name="Body2">
<item name="android:textSize">12sp</item>
<item name="android:lineSpacingExtra">4sp</item>
<item name="android:textColor">?theme_textColor</item>
</style>With the help of typography in place, we can easily communicate and understand/modify.
Tips:
Do not miss the power of ?theme_textColor (This is called referencing attribute in android, similar to call by reference in programming world)
Do not restrict yourself to only theming and typography. Create a language what suits your need. You might be interested in cards, custom views, paragraphs, images etc.
If you are a developer, you can clap on the article now :D
How we Implemented ( This section is for designers by Meylin Bayryamali )
This section is mainly for designers. We have jotted down few steps which might help you.
- Talk to your devs first. You are not doing this on your own as they need to implement it — arrange a meeting. Try to define their needs, ask them how the codebase works, what is done until now and why it hasn’t worked. Try to identify what are the reasons and decisions that have led to these inconsistencies.
- Be prepared. They will probably ask best practices, so try to read some articles. Here is a good one:
3. Naming conventions — seems like an obvious one. Peak has well-defined colors. However, we had never settled common naming conventions in our color space. Our product is a particular case as we have 66 widely used colors across the app. One tiny human error either in design or development have expanded the catalog of colors in the codebase. To give you an example, currently, we are trying to clean up “55 shades of grey”. To solve this issue design and development sat down together to give naming conventions. Same for fonts, names like H1, H2 and so on, helped a lot the team to keep consistency.
4. Settle on font requirements — From a design perspective having “Gotham” as a font is a challenging one, however, we couldn’t change the font so we had to make the most out of it. To learn from my mistake I would suggest using a system font. There is some discrepancy between our design tool — Sketch and code implementation of the font. For example, line-height is not rendered accurately in Sketch (which is a shame!), so you need to sit down with the developer and go for a round of countless screenshots until you find the magic number of kerning and line-height that you are looking for.
Here is one example: You can see that although 120% line-height applied the design tool does not render the text box properly. Sketch, however, is not well-equipped to meet our needs, however other tools seem to tackle the issue quite well:
5. It’s a slow process, so brace yourself. Unfortunately, we don’t have time to go through all the screens in our product and adapt the new colors and fonts (would also require QA time) as we support 14 languages in our app. So font changes is a challenging one. Here is how we approach the integration in a simple non-obstructive way.
We push the changes for new features only. We design and develop with the agreed new styles, hoping that overtime in the development of the product, we will slowly get rid of the older styles.
6. Create your Sketch style guide
You should create your Text guidelines in Sketch with the agreed naming conventions. This article explains more in-depth on how to approach it. https://medium.com/sketch-app-sources/text-styles-mastery-with-sketch-52-dc00c7fe1aa6
This is how our typography in Sketch looks like. Unfortunately, Sketch is still quite early in the stages of developing overwrites and it might look messy or with too many dropdowns. I believe it is something that the tool needs to look into, or you can just use Sketch Runner which will allow you to control your symbols and styles better and faster.
Appearances are also set in Sketch, comes in extremely handy in the use of Symbols. We made sure the naming convention is kept on the design tool as well as the development.
7. Prepare the Zeplin integration
Once you give an appearance to your text in Sketch and settle on font and color style guides create a Master project on Zeplin. Read more in the latest release notes of Zeplin. You need to have the organization Zeplin subscription to be able to integrate style guides. You need to switch the top bar from Dashboard to Styleguide and let Zeplin fetch the defined guides.
After that, for every new project you create on Zeplin, you can set the master style guide and the colors and fonts from it will be copied.
You end up with something like that in the Styleguide library of Zeplin
So when you hover over a text, if the designer has linked the right properties in the style guide, then you should be able to see this. So you reference Typeface: Body to Colour: #Focus3
Summary
The design language is a terminology a company can define to facilitate communication among design team and with other teams. It helps in easy to develop, easy to maintain and easy to modify designs. The design language can vary from company to company and it is purely dependent upon your needs but the core and purpose remain the same — Good communication, Fewer Errors.
Hope you learned something new. Clap is appreciated so others can also find this article.
Do you have already a defined design language in your team? Share your experience in comments.
