Creating a web design system from an app design system
A case study of the complexity of building a new front-end design system that was built on top of an existing app design system.
I work at Tink, an online service that provides the best way to connect to banks across Europe and quickly build smart financial services. We provide our API to huge banks such as ABN Amro, Klarna, SEB, SBAB and more.
Tink is also connecting with new disrupting fintech companies such as Zmarta and Bofink (first mortgage robo-advisor) that uses Tink’s API platform. We’re releasing major updates to our PFM (Personal Finance Management) app, such as Dark Mode which I wrote about on Medium recently. It’s a hectic schedule with a lot of new interesting happenings week in — week out. (And it’s nice that it’s spreading through the grapevine, like Wired, who titled Tink as as one of the hottest startups in all of Europe.)
Tink released an open API platform for developers in April. This allows developers access financial data from more than 300 banks in a single API, once the end user has given their consent for this data to be accessed. The developer platform will make it faster and easier for developers to experiment and launch new and innovative customer-facing products. A couple of developers have worked on this feature, where we’ve updated it and made it responsive — now also eligible for desktop.
Tink has gained ground in recent years due to the PFM app which has been downloaded more than half a million times. The branding has been set, more than the logo and the colors overall, Tink as a software company has evolved a clear and defined design language throughout the app. The design system is robust and makes Tink… Tink.
Opening up the API for developers also opened up the Tink design spectrum: we’d need a web design system to build responsive pages for. So far there were no web design system to rely on, and the design system for the app lacked styling for larger desktop designs such as a documentation portal, or a complex dashboard.
Implementing design with the current app design system looks like this:
Problems converting app design to complex desktop dashboard design
It looks nice, but as mentioned, it’s not a piece of cake to use the exact same design system from the app environment to this new desktop dashboard.
Here are some of the problems:
#1 Large shadows
While large shadows looks good when there’s just a few pieces of content viewable on a small device, applying this to a larger screen such as a desktop, it gets cluttered and spread out.
#2 Too much #ffffff
When reducing the shadows a lot, a large screen device (2440 pixels large) with only white background looks bland and the content such as cards blends in and away, taking away focus from them. Applying a light background adds the necessary contrast to make the important content “pop”.
#3 Non-hover devices rely on color more than hover states
When you have no hover, like on a mobile, you need to separate much clearer which button or tab is selected, while on a desktop, it’s natural to just hover a piece to understand (while also indicating with colors and fonts but not too much background color, rather colorized text and/or underlines).
Take the segment controller below, in the first image of the three mobile screens, the heavy coloring on the background color for the selected tab (here; “Everyday”) indicates clearly which tab it’s on. If you’d do this on a larger screen (huge desktop), all these navigational elements would take too much hierarchy from other content, such as cards, why they on desktop devices need to have a toned down effect to balance out.
#4 A lot of design and components are missing
On mobile you won’t have hover state. That’s a huge amount of work and design thinking to implement on each component that will need it.
You also won’t have large tables optimized for desktop and vice versa. Creating a good table on a mobile usually takes another lap of design tweaks to build. Also, it won’t always turn out to be a table in the end (maybe accordions, etc).
#5 You have a lot of more room to breathe
White space is one part of a design system. Keeping it tight and narrow is one styling, while spacing it out gives another look. When on an app, you only have so much place to breathe and use, while on a desktop you can spread it out and i.e. have more margins inside of cards. This change will overall change the look and feel.
#6 Information overload
A summary of the five problems stated could be summarized to one single problem: when you’re on a mobile device you only have so much space, so you can’t fit too much either, while on desktop you have so much area to play with.
Adding too much content with too much hierarchy (with font boldness, colors, heavy imagery, etc) will make it a mess on a desktop. Hence, one needs to reduce the components a notch everywhere: the shadows will become smaller, the tabs won’t have a heavy background but rather a colored underline to indicate which is active instead, and so on.
Two quick practical tips to get started
#1 Setup a few basic components
Start off by bringing components from your current design system or create a few that you feel will be often used, and have them with you whenever you create a new page (wether you’re going to use them or not) to have them by the side to check that you’re using the same look and feel.
#2 Create the most important variables
When the project reaches the front-end developers, it’s practical to have a few variables defined, such as the shadows.
(A variable is something the front-enders will use over and over again, like a symbol in your design software, that they call by a unique name, like $shadow-large or $shadow-small)
I created shadows, rounded corners and padding/margins, since that’s something that is often re-used. The benefit of creating them as variables in your design system and front-end specs is that you’ll be able to easily change it in one place and it’ll change everywhere.
It’s a living thing
I used to work at a printing factory. Printing hundred of books was a nervous task. When you realized you’d made a typo or messed up a line break somewhere, you could just hope that the manager didn’t spot it (because you’d have to oversee the reprint and burn a lot of money). Fortunately, as we all know, the web is editable along the way and it’s easy to change things as you go. I spend as much time revising the things I’ve designed when it’s in production as I spend time creating them in the first place.
The developers often realize a benefit of doing X or Y instead of your solution which is incredibly good. It’s often when I code myself that I realize things that doesn’t add up, compared to when you sit and design a component here and there. It’s incredibly helpful to have the developers have time to do inputs and this needs to be in the schedule when you build the new system.
You are walking on a rainbow
Converting the system from app design to web design is a large project. You’ll often sit and tweak, change, redo and overthink decisions. But in the grand scheme of things, it’s a joyful process that actually has the biggest reward at the end. When you’ve done all the work and land at the end, the treasure is yours to grab: having the web design system implemented will make it such a breeze (in comparison at least) to take on new tasks and build new things.
On to the next one
We’re constantly updating and upgrading the web design system at Tink. This is where we’re at right now, but who knows what task tomorrow brings, and the design changes that are needed.
