Stryk’s new colour system — the ultimate facelift
Giving new life to an outdated app by rethinking colour in a systemic and scalable way.
Introduction
Stryk (formerly known as BUX X) is a CFD trading app that allows users to trade easily on a variety of products such as stocks, commodities, and forex. The app’s proposition is to take the complexity out of the financial markets and simplify the trading experience.
The app was designed in 2014 with a very playful proposition, both in visual and functional terms, that made it stand out from the competition and reach a younger audience.
In 2020 with dark mode becoming a standard feature for mobile devices, the app got a secondary theme that gave users access to a complete dark interface. This challenge was highly user-requested and allowed us to not only keep up-to-date with OSs and competition but also clean up our code and improve accessibility for users with visual impairments.
From dark to light
The design process of creating and implementing the dark mode forced us to begin creating a framework for dealing with colour within our app themes.
It didn’t take long for us to realize that our standard mode was outdated. After 6 years on the market, Stryk had evolved as a business. While we still wanted to position ourselves as exciting and easy-to-use, after conducting a survey with our current user base, the results pointed in a direction in which we needed to:
(1) strip out the playfulness/childishness;
(2) solve accessibility and usability issues;
(3) maintain a clear distinction from our sister app BUX Zero.
The process
We decided to work with a transitional state and achieve our goals without changing the UI. Initially, we wanted a cost-efficient solution from the design and development perspectives, so we decided to reuse the colour framework made for dark mode. This solution had to be in line with what our brand represents and how it is perceived.
Our marketing team had already adopted the blue hue as the main brand colour because it always outperformed other hues in A/B test campaigns, but we still didn’t know for sure if it was the best hue for our app’s main colour.
We decided to run some qualitative research (n=119) with our users presenting the app in different hues (blue, green, and purple) to understand their perception on 3 aspects: maturity, trustworthiness, and seriousness.
The result of the survey indicated that both the green and blue versions of the app would be perceived as mature, trustworthy, and serious, with a slight preference for green.
Taking into account that our primary colour in user-facing communications (ads, stores, emails, app icon…) was already blue, it was easy for us to decide to continue with it: it ensured a softer transition to the new colour palette, would help maintain brand consistency and would require less spend on marketing.
Colour positioning
Since we already had blue as a background in a few places in the app, we chose to continue with it as our main hue (209). To improve contrast and perception of maturity, we lowered its lightness, and to increase the perception of excitement, we increased its saturation.
Expanding the palette
With the main app colour chosen, it was time to define the support and accent colours that would be used so they could be paired with their equivalents in the dark mode. These colours were hand-picked as we still didn’t have a colour system in place (we’re getting there!). Except for the colours that bring awareness in the app, all others would be variations of the same hue creating a more harmonic experience throughout the app.
The accent colour selected — mostly used as the primary action colour — needed to be on the other side of the colour wheel so it would have enough contrast and fulfill its function of drawing the user’s eyes instantly. A faint yellow was our pick as it would pop on our backgrounds while maintaining good contrast with dark text over it.
With all colours in place, it was time to apply it to the app, map out edge cases, and list out exceptions. All in all, the dark mode framework worked well when translated to standard mode. The few exceptions happened in the chat feature of the app where the blue background compromised the readability of longer text strings. In the next phases of the project, we would need to take care of this, but we were ready to start development with a low-cost solution.
A comprehensive and scalable colour system
In the fast pace of a startup, Stryk was developed organically and the app’s colours were a mess of inline definitions, confusion about when to use what colour, and huge issues with updates when things change. With the introduction of support for dark mode, a basic framework was developed but another layer of complexity was added to the app’s colours.
With the team scaling up and having more developers and designers making use of these colours, it was not sustainable to move forward without a colour system. I’m sure it didn’t go unnoticed that in the current framework, colours are named after Game of Thrones characters and carried no meaning. Understanding the purpose of each colour is a challenge with a steep learning curve.
A systemic approach to colours
In order to create a colour system that is usable and useful, the first step was to consult with our developers to understand how they dealt with colours on their side. This brought to light the number of exceptions and inline edits they were doing in the code due to the lack of a system, treating almost every screen as the page of a magazine.
During the process of creating the dark mode and translating its framework to the new standard mode, we mapped out where we were using each colour and what purpose they had. These purposes were defined as:
(1) Backgrounds
(2) Text and Icons
(3) Action
(4) Highlight
(5) Separators
(6) Positive
(7) Warning
(8) Negative
Expanding our horizons
Now that we understood what were the functions of our colours, we needed to make sure that if we ever needed a new colour in the app — if a new function ever appeared — we wouldn’t have to spend hours coming up with a new colour or a new creative name. The system needed to be scalable and, of course, needed to accommodate our pre-existing colours.
The system we created was inspired by the beautiful work from the folks at You Need a Budget and several others. To sum it up, it’s a 2-layer colour system: on layer 1, we first list down all possible colours the system can have and on layer 2, we grab colours from layer 1 and assign meaning to them.
The layer 1 palette was created using the pre-existing colours as a starting point and the workspace chosen for this colour scale was the HSL (hue, saturation, and lightness) due to higher fidelity amongst different types of displays.
These colours were divided into:
(1) Neutrals
(2) Primary
(3) Secondary
(4) Tertiary
(5) Positive
(6) Warning
(7) Negative
This layer is solid and should withstand time. Even if we decide to completely change the colours of the app, we just need to assign new hexadecimal values to each weight.
Colours that already exist in the system will then get attributed to the components or actions previously mapped out. The naming convention for this step had to be created in a way that would be self-explanatory and that could accommodate future use cases:
Mode / Purpose / Emphasis
Now whenever a new mode, purpose, or emphasis is created, a new colour — or set of colours — is created on layer 2 by picking a colour from layer 1. A colour created for the standard mode will always have a pair on dark mode, even if we’re using its hexadecimal code several times per mode.
Test through time and learnings
Such a big change in the colour scheme of an app will without a doubt have consequences for the current users. Some will love it, some will hate it and some will even stop using the app. For this reason, it’s important to involve the community in these changes and we should’ve done that better. Perhaps we could’ve made a public announcement that the app would change so their expectations were managed.
Looking back, if we’d had such a system in place from the beginning, creating the dark mode and reviewing the colours of the new standard mode would’ve been a breeze but were it not for the complications faced in these projects, this colour system wouldn’t exist.
We underestimated the impact of the implementation of this system on our legacy designs where we would need to replace colours one by one, file by file. It is an exhaustive process but future app developers will reap its benefits.
There’s always room to get more specific when listing colours on layer 2. Unless you have a really good reason to, don’t name a colour “iconListItemLeft”. Keep it specific but know where to stop.
The new semantic colour system is still in its implementation phase on the development end. The way these colours are listed in Android and iOS are slightly different, so the way we reference them in layers 1 and 2 will be slightly different.
With the product growing, the possibility of a web version is huge. This will really put this system to the test with the addition of possible new colours in layer 2.
We’re also currently creating a layer 2 palette for marketing. This has to be disconnected from the app’s palette, but it should work in the same systemic way by borrowing colours from layer 1. Just one more reason for this layer to be so sturdy.
Team
Product designers
Igo Mayama / Paulo Bastos
Front-end engineers
Andrei Mamchenko / Ararat Mnatsakanyan / Eva Stos / Loka Podorozhna
Back-end engineers
André Brait / Nikita Romashkin / Osman Cetin / Stanislav Levchenko
Test engineer
Yevheniia Boiko
Project managers
Ekaterina Pozdnyakova / Miguel Mendola
Design manager
Ramon Gervais
