WeLoan Design System

RoleLead designer / Font-end developer

In-house redesign of a loan product.

Design systems are powerful tools to help democratize and empower the entire team, both developers and designers, to participate in the design process. Derived from Atomic Design, design systems are now widely accepted by designers in the industry and considered a go-to to produce high quality design efficiently.

At WeBank, we use Sketch on our design from early beginning, and we maintain a library of symbols for components, like buttons, forms etc. But as our products developed, a static and Sketch-only library is failing in many ways.

  • Designers and designers failed to align. Due to the limitations of Sketch Symbols itself, what we can define in the library are merely components, or combinations of components at most, let alone design tokens. Page templates, grids or other guides should be followed cannot be reflected in a static sketch file. Therefore designers may have their own interpretations of a same design pattern, causing different outcomes which should have been the same.
  • Designers and developers failed to align. It is a crippled one that a "design system" is designer-only. Without a corresponding "library" at the developer end, designers have to export the specs of the same button each time it appears in a page. That is not what we call consistence in design or efficiency in development.
  • Developers and developers failed to align. Without a ready-to-go library, developers have to handwrite every component on different pages even it is the same one. It is not only inefficient but will lead to inconsistency on both design and code level.

To solve the problems. A design system needs to be established.


Designers across the team should always be able to get access to the latest component styles in production. So there should be no more inconsistency between the .sketch file and the .css file.

Our product works on multiple platforms. So it is also important to achieve a goal: one code base, all platforms.

Structure of the design system
The structure of our design system. Our product also lived on multiple platforms like Mobile QQ and Tencent Mobile Manager, so we need to in line with their aesthetics respectively.

In this case we use Vue.js to build our UI components and Storybook to organize them. Component styles and code examples are documented so that both designers and developers can always be on the same page.

Process of Implementation


Our first step is take stock of what we had in our original component library - buttons, textfields, icons, lists, etc. We started compiling all of that components into a single file, and from there, it was easy to see repeated applications of patterns that needed to be unified.

And then we take out sizes, margins, paddings, shadows, animation curves, and so on to organize them as design tokens.

Animations curves defined as design tokens.

We also spotted the outliers, or those components that had been used only once, and therefore didn’t have a place in our system.

During the process, we also find out that some designs already in production could be unified into one. The process of organizing is also of process of a design review.


Some designs are not easy to be explained by just exporting the specs. How would you explained "I want it centered in the 60% top on the page"? In this case, I needed to get into the code myself and keep tight communications with the developer team.

I got access to the Git project so that for some minor style tweaking, I could do it myself to accelerate the process of development. And I was also included in the code review so that I could check if components would have desired logical behavior other than just style.

Button component code
You couldn't tell if a button have min-height if you don't dive into the code.


A design system is supposed to be used and enforced by everyone. We don't just finish it and leave it there so that no one but the creators know about what to do with it.

Each component or template is required to include documentations not only for developers, for obvious reasons, but also for designers. Telling them when or where to use certain component and so on.

Making Delivery Faster

With the design system established, our designers get to focus more on user experience itself rather than wasting time on checking if the padding is exactly 20px. And developers can deliver consistent pages across the whole project efficiently like building LEGOs.

Pages based on a same template
These pages are built with a same template. Designers don't even have to export the specs.

An ever WIP

After two months of cooperation between the design team and the developer team, We’ve already been able to rely on our design system for some new projects. But As our product lines are in rapid change, breaking down the existing system from time to time is inevitable. We’re still revising and modifying as we go.