It was done around August 2019. I had a buffer to contribute to the central branding team, taking responsibility of doing the Signify branded navigation templates.

Before the contribution, I had done a Signify branded app, which is Signify Service tag. I had learned the style guide, clearly knew the problems in this new guide and reported the issues. I had back and forth communications with the central team in the very long mails. And below are the problems I reported.

Problems and solutions in the guide

1. The color hierarchies

Issue: The color for the non-interactive icons turned to be the disabled state for the buttons. The drop-downs were even using the color for interactive icons as the disabled state, though the text and icons were with backgrounds. My two cents here was that the disabled state might need to be more disabled and consistent. Further, I used the color for non-interactive icons for unselected tab at the bottom app bar in the app I completed. It was because the selected item can’t stand out if the color for interactive icons were applied, which means the contrast on the bottom tab bar now actually was even worse than the defined disabled state.

Solution: As a consequence in the new guide, the color of the Interactive inline icons were changed to 100 dark gray (like what we have for Interact branded apps), which makes them look more clickable, creates better contrast between the label and the interactive color and is in line with the icons in components library. And the problems on the bottom tab bar has also been solved as I explored the navigation template. Selected state becomes blue, default state is 60 dark gray for icons.

Issue & Solution: Regarding to the color hierarchies, another problem is that the color for interactive items (60 dark gray) and non-interactive (40 dark gray) items might be too similar. But it also has been solved with the changing the interactive icon color to 100 Dark gray as mentioned above.

Issue: Non-interactive color (40 dark gray) can’t pass the accessibility even being used only on the icons.

Solution: As a consequence, the non-interactive icon color was changed to 60 dark gray. It’s then also the same icon color definitions as for Interact which supports consistency. The only thing is that non-interactive icons (labels) then have the same color definition as unselected navigation icons. However, the context in which they are used makes the interactivity clear.

Issue: One thing may need more attention is that in Interact guidelines, we use 80 dark gray for most of the non-interactive parts, like all the body text, paragraphs. We only use 100 dark gray for titles and selected states. But in Signify branded guidelines, the body text is also 100 dark gray. The examples are shown in the “impressions” section as references. All of them, including the dialogs are using dark gray 100 as the color for body text. So I was thinking that is the right color for the body text when I was doing the app design. If we change the interactive color to 100 dark gray, we might need more definitions. Because as mentioned, now body text is also 100 dark gray, which caused the problem that it is hard to tell what is a quiet button and what is just pure text. Because the font style is exactly the same. We need additional guidelines for when we can use a quiet button. Below is my rough solution, which has also been taken in the new released style guide.

2. The components

Drop-down

Issue: According to the specifications in the style guide, the drop-downs should be all with 2 dip border. However, 2-dip borders only appear on focus state for the drop-downs in the examples in the guide. This is not just a wrong definition. It also created the problems in implementations, it was easy to make the UI bouncing on focus state. 

Solution: They were all changed to 1 dip border including the focus state in the new guide. It’s better if the border weight stays the same for all states. The font weight of the quiet dropdown has also been changed from bold to book for the focus state.

Button

Issue: The font on the main button was slightly bigger than other buttons. It looked a bit weird when two buttons were side by side. It didn’t seem to be a common way for the button hierarchy. Further, the height of all the buttons was 50 dip, which wasn’t on the 4 dip grid and made it even harder to have all the elements on the 4 dip grid. When there were input fields and drop-downs side by side, you can’t align them, especially on the cards. It didn’t look very well when input fields, drop-downs and buttons were with different height.

Solution: In the new style guide, the font size for the main action buttons has been changed from 18 to 16, so it’s aligned with the other buttons. And the height of the buttons and drop downs is 48 dips now.

Issue: One more thing about the current style of buttons, it was hard to use on a card, especially there were phrases on a button and two buttons were side by side on a card. Because we had the round-corner style. It occupied too many spaces, especially on the mobile devices. If I want to use a round-corner button on a card, they usually can’t be paratactic. And the wording on some of the buttons could be really long, they were not just a single word, like “Add to cart” and so forth. It was normal to have phrases on the buttons to clearly express the meaning. So in Service tag, I just used the native pattern of different platforms. And considering multi language support, I was not sure if it could still be shown completely, which made the situations even more severe.

There was no further action on this problem now. But the approach I took in Service tag app provided the possibilities for the solutions.

Top app bar

Issue: The height of the current top app bar was a bit too high, compared to a native one in iOS. An native app bar with big titles can be used if something need to be emphasized. So there seemed no reason to create a custom top app bars ourselves. And there could be phrases, like “forgot password”, “create a new group”, etc for the titles. It’s hard to show them entirely when the font size of the titles was 24 dips.

Solution: It has been fixed in the newly designed navigation template, following the principles on different platforms.

3. Margins and details

Issue: It was hard to always follow the rule that there was 24 dips on each side for the paragraphs, input fields and drop downs, 20 dips on each side for the buttons. Top app bar and list view were all 16 dips on each side on iOS. Because of this definition, it was common to have 3 side-margins on one page, 20 dips for the buttons, 24 dips for the other standard components and 16 dips for the lists, which causes many alignment problems.

Further, it was also written in the guide that it should be 16 dips margin on the 2 sides in the grid system for all the mobile devices. There is an ambivalent here in the guide.

Solution: All the examples in the impression section have been changed to avoid confusion.

4. Next step investigation

• The radius value for the round corners were different between components and panels.
• We need more definitions for the illustrations.

Examples of all the problems mentioned above

Exploration

light_theme_accessibility

Proposal 1

Proposal 2

Proposal 3

I discussed the proposals with the central team and got feedbacks. We confirmed proposal 1 as the final direction and refined the details a little bit. Then below is the final version of the Signify branded navigation template, including web, iOS and Android.

Signify branded navigation template

Tab bar

Web navigation template

Hierarchical model

iOS navigation template

Android navigation template

As the final step of the navigation template making, we submitted the template to the branding desk so that all the designers can download the template from the official channel, together with the newly-written Signify branded style guide.