Creating Design System. True Story

I work in Alfa-Bank, one of the biggest and successful privately-held banks in Russia. Back in 2013 I created design department and besides hiring and working on products started working on bank’s design system.

Our first steps were for web, but later we scaled our approach on mobile applications as well, and now we’re updating it.

I want to share our experience and approach — it may be useful for other fellow product designers/owners and developers and I expect some feedback and ideas — so please, welcome to discuss.

Design system works well with a family of products

Evolution is the key in product design. At any given moment there is something to improve.

The only important thing (the true goal) in all processes is working product, which is used by people.

The problem with style guide is that it gets outdated the day it is published, because life is way more interesting and we find lots of reasons to make our products better no matter what guidelines have to say about it. It’s just the way it is.

And the only actual layout/mockup/etc. is working application. Thus all our graphic files lack value from our real goal’s perspective (happy user; users don’t care about our graphic files).

Instead, we have an opportunity to work with code library and contribute with new findings and keep our apps design always up to date — in code, not in graphic assets. When code library is done well, every product team can build from there and improve it so that other teams can reuse it and update their apps/products without any doubt. That is awesome.

Bricks and motors

So, basically Design System is a set of bricks and motors of UI and UX patterns, created as a library in code.

Imagine Lego Technics for a second.

Bricks are metaphor for UI components — like inputs, buttons, checkboxes and et cetera.

Motors are metaphor for more complicated behavioural patterns like authorisation, OTP confirmations, navigation and so on. Developers just pick services that were already created and use them as they are in apps and products where required — just like already assembled motors in Lego Technics.

The difference between Guidelines (styleguide) and Design System

  1. Instead of just creating a list of colours and typography rules and writing them down we have to create a library of UI and UX components made in code.
  2. UI components library is a huge list of inputs, buttons, headings, icons library (another big topic), checkboxes, dropdowns, alerts and way more (the number is multiplied on amount of colour schemes, two or more sizes and desktop/mobile for web apps). They have to be presented as code library, tested UI components for whatever mobile OS/browser they are required. Think of them as of Lego bricks: they fit each other and the result is consistent, and even kids can create great stuff. They are not drawings of bricks (not graphic files), they are code components (actual bricks). I hope you can see the difference.
  3. UX patterns including things like authorization, error and alert indicators, animations and so on (they mostly product or company specific). They are stored in library in code (again, not graphic files) and can be reused in every app by any team. When they are updated for some reason (change of style, new UX ideas, easier solution) every team can just update them in a few moments (and be sure updated components will fit perfectly). Or leave previous version (usually it’s fine: don’t fix it if it’s not broken).

We’ll be back with building Design System from scratch later.

Design System Pros for Product Development Team

  • Quick customizations. Less time on coding means faster delivery.
  • Faster delivery means better time to market!
  • New developers can start working on products without reinventing the wheel.
  • Cross-departmental collaboration. Different product teams are working within one style so that all the products look and feel the same to end user.
  • Design in code: every component has to be programmed, tested, and described before being stored in common library so that it can be reused again safely. Even if there was something wrong on design stage, it’ll be fixed properly on development stage. (Actually, this one is a little bit pain in the neck for those who “just want to do something new” without proper thinking about all other products in line — imagine one can’t push an update or new UI element without properly describing it, testing and so on. It makes library more clean and free from trash, and products more stable from end user’s perspective.)
  • Less bugs and mistakes in UI and UX since more people are using the same components and fixing them when necessary.
  • Approved ergonomics. Best practices, basic components and UX patterns (motors) must be reused to save time and money and to support consistent user experience along all the products.

Sounds great!

Design System Pros for Designers

  • Less time on drawing, more time on creating better UX. Focusing on user’s goals.
  • More time to test ideas while staying in the same visual system.
  • Realistic prototypes instead of dull wireframes. You can actually create production-ready frontend at least for web. Adaptive from the very beginning.
  • More code-centric design approach changes the way we design: design tools are not that necessary, it’s faster to come up with real page/screen in code than in graphic editor.
  • Use real data instead of “Lorem ipsum”. This one is extremely important.
  • Test UI in browsers on different devices instead of graphic software environment is way better approach. :-)

Does it kill creativity?

There were many questions on such systems killing creativity. Actually this kind of library can be described as alphabet: it has only these letters, but one can assemble them into words and sentences, use them to write poems, press releases, fairy tales and this kind of posts. It’s just a great tool for creating products and focusing on what’s important.

So the right answer is no. It does not kill creativity but expands it. Don’t worry!


Alfa-Bank Design System

We are continuously working on 2 main mobile banking apps (corporate and retail) and two internet-banks (also corporate and retail). We also help other teams (like Alfa-Forex) to build their apps as well so that our users will have seamless experience using any of our apps — mobile and web.

Our goals

  • Seamless UX through all our products
  • Reusable code
  • Modern, holistic design through all our products
  • Save time

Basic principles

  • Create in code as much as possible
  • Test as much as you can
  • Only tested components (UX patterns or UI elements) can be added to libraries

What we’ve achieved so far

  • Better UI and UX in mobile apps (higher CSI)
  • Faster front-end development for web-apps
  • 500+ Web UI Components
  • Web, iOS and Android Code Libraries
  • 260+ Icons Pack
  • Interactive Prototyping System

Starting a Design System. Wrong approach which makes sense at first but bites you later

We’ve started building our Design System from restyling and rewriting existing open-source library created by Yandex’s BEM team.

We figured out that there is already a great solution out there, with lots of tested components, and all we had to do was adding some stuff from our specific needs and restyle the rest — inputs, buttons, etc. Sounds cool, right? Well, it worked great for a while. But only in the beginning.

First step: styling

At first it was like designer’s dream: to have all the buttons in one place, spent some time rearranging and polishing them. I’ve seen the fire in designer’s eyes every time Sketch was updated, like when Symbols were introduced — some of my colleagues wasted tons of time reworking on this kind of graphic library. Smart ones found out sooner that this kind of time killing is lame. But in the very beginning it looked like it made sense to lay down every kind of component on one sheet just to see how they are working together and if they look alike.

(It was very wrong approach, I will explain later why).

We’ve spent approximately four months on restyling existing components and adding new ones (like banking cards) and ended up with HUGE Sketch file.

Sketch file contained all kinds of controls. For example, simple button was created:

  1. In four sizes
  2. On two backgrounds (lite and dark)
  3. In every condition (active, inactive, disabled, hover, focused, etc.)

Resulting sketch file looked like this (marked w. red outline part is buttons section shown before; actual huge file is on the left side, minimized), it was 2742 px width times 37604 px height :

Second step: coding

As I mentioned before, we reused BEM components at first. This approach saved us tons of time, it was like standing on the shoulders of giants.

Later this library moved to ReactJS since other product teams preferred this framework.

Mistakes

Our basic mistake was that we focused on web and missed native mobile apps. Don’t repeat our mistakes and consider carefully crating one whole approach to design across all platforms. In our case it makes perfect sense, but we’ve realized it almost a year later. (It wasn’t that obvious at that moment that Material and iOS will be copying so much from each other and lots of discussions were around using native components versus custom ones; later we decided to go with our own components everywhere and I still think it was a win.)

Second mistake is that you can’t just style UI components and use them to create products. In real life you must focus on user’s tasks/goals and build UI from there — and these solutions affect your UI in a great way. And as you build your product and test it, you add new blocks to your library. Evolution works here as well. Lean approach.

Tons of sizes in the very beginning is a complete overkill. Just start with one and see how it goes, but keep in mind that there can possibly be more. Just really don’t waist your time on this too much.

Meanwhile in Mobile

Slightly off topic, but I think this is very interesting: our audience is split 50/50 between iOS and Android. Sometimes there are couple more percents more iOS users than Android ones. For a while I thought that it was normal and only a couple of years ago I realised that actually it is pretty unusual (and usually there are way more Android users than iOS ones). But that is our bank’s specific.

We used different approach to (re-)designing native mobile apps. Instead of working on buttons and inputs separately from user stories, we wrote down most heavily used scenarios and started building from there.

That was a major game-changing moment. It may look like obvious thing in retrospective, but couple of years ago it was not that obvious. A lot of designers still start working on user interfaces in Sketch or whatever graphic editor. But we started in Google Spreadsheets — writing down major user stories, prioritising them, gaining relative data in JSON and analysing all that stuff. By working on most frequent cases (that are relative to banking app) we developed basic look and construction for main components of our apps.

Instead of buttons we thought in terms of accounts, bank cards, currencies, credits and deposits, transaction records and so on.

Working on these components was hard mainly because we tried to find the right balance between unification of everything and creating task-specific views for each and every case. There are things you can unify and things you can not, because of context or specific mechanics. Usually unification is better than multiplying new items. Take it for granted and let it be your guiding star, but always use your head.

For example, a bank account has lots of attributes and variables, like currency, amount of money, name (title), linked cards (from zero to, for example, 25), it may have a credit line/overdraft and many other things. You can do a lot of actions with your account.

And we have not only a retail app but one more app for corporate clients and entrepreneurs as well, and they have some attributes in common and some of their own. Good luck with unifying that! but we did it okay. Here’s an example case at Bechance.


We also decided to create our own style for controls instead of using native-system-like ones. This gave us opportunity to unify designs for iOS and Android, but with careful consideration of navigation patterns (physical buttons on Android devices).

Three different approaches to navigation design (tabs versus action button variations; action button in the middle won).

We also decided to use different icon metaphors for actions like sharing, more and so on — closer to system defaults and default system fonts (SF and Roboto for iOS and Android respectively). And the rest was unified — layout, grid, colours, button shapes, inputs, icon styling, wording, etc. Even main navigation patterns remained the same for both major mobile platforms.

Same styling within iOS and Android devices works well

This approach paid great when we started rethinking our web apps. But we’ll be back to this topic shortly after this awesome break on… icons!

Icons!

Well, icons are frequently required. And every one want them. But icons are hard. First of all, we created a list of icons we need. Then we worked hard on styling. Then we came up with approximately 250+ icons in our library. Then we wrote down the rules of creating new icons and adding them in library. Finally, there is a lot of work in managing them over all of our apps and updating them simultaneously on every app as designers making changes.

  • Most of them are drawn in three sizes (different shapes, amount of details, stroke weight) to be perfectly optically aligned. This is extremely rare!
  • They are all SVG so that they can be animated in web. Still looking forward to do it, but the idea is great.
  • Small file size.
  • One library for web and mobile applications (every icon change affects all other apps). Some icons have their OS-specific twins.
  • We covered all the basic functions specific to banking applications and Personal Finance Manager (PFM) categories
  • White and dark themes supported
  • 260+ icons were created at first iteration
  • Icons repository is integrated with web UI library, being integrated into Android development process and planned to be integrated into iOS development process.

Working on first batch of icons took us approximately one month. One artist dedicated 100% of his working time to create them and at least two designers helped him from time to time.

We started working in Adobe Illustrator, then copied our library to Sketch, then tried tools like IconJar for storing icons, and later moved them to Git. It is still the work in process, so maybe I’ll describe our approach to icons in later post.

What I find to be the right approach

It is very funny that almost every designer nowadays know about “Mobile First” approach. But I found out nine out of ten are starting with desktop layout, saying “I’ll fix it later for mobile”. This is terribly wrong: nobody cares about desktop anymore, and the way we interact with mobile is completely different than how we interact with desktop. We have different form-factors and tasks, so you have to build for better experience for every platform on their own.

One of the first prototypes of new approach to building new web. Compare to our first approach

Knowing that and having separate mobile app designs I’ve set another task to my team: build web apps from existing mobile apps using that very styles and building desktop from mobile.

And it worked just great.

We had some major problems with navigation in desktop (it is still very complicated but we’re working making it simpler), and some lesser psychological problems in switching to new style, but it worked out just fine from the very beginning.

We tested different layouts for desktop, made few adjustments to mobile style and came up with set of general guides are that fit to all our next products.

The value of this is that we created our new Design System really human-centered and technology-based, and thus working, not just looking nice as someone’s portfolio or just awesome pictures. It looks nice too, by the way, but somehow more utilitarian. Another value is that we don’t have to work on web or mobile designs separately anymore. You just work on user’s goal and it will be solved on any device with any OS — web or native iOS/Android. Also, it gives us the opportunity to create seldom required sections as web view (which means two key points: we don’t have to support three apps if changes occur, and we can deliver these sections way faster).

We surely made some major adjustments to web navigational patterns, but it did not affect much on design system and feels right to user.

Couple more things

Before even starting to work on Design System our team worked heavily on creating single sign-on (SSO) between our existing apps. It required tons of will and support from IT-experts: it wasn’t that obvious to them that we have to have it at first.

Also, we needed a good strategy and new approach to creating apps and delivering them. Before the Era of Agile there were tons of paperwork and planning and it was glorious to redesign apps (like internet-bank) from scratch. It took some teams like a few years to recreate something like that. But it is obvious that even a year is so much time and nowadays we don’t have it. So, we came up with an idea of splitting our apps in pieces and recreating them case-by-case, introducing new design approach from app to app. As soon as SSO became possible, it gave us opportunity to launch new things pretty fast.

So, Design System is NOT only about look and feel (or even icons). It is not about graphic files. It is for designers. It is, in short, strategy and technology.


I’ll be glad to answer your questions and expand some topics you might be interested in.

Thank you!