Table of Contents

nanopay Design System: Accelerating Design & Development

System Design, Front-end Development
7 min read

MintChip Retail Portal

nanopay Design System is a structural and visual guideline to standardize and accelerate the design & development process. It consists of a live style guide with reusable components, design guidelines, CSS snippets, and a component library for designers.

My Role

As the sole designer in the team, I was responsible for designing and coding the nanopay design system website, and creating the Sketch component library & design templates. I also presented my ideas to the executive team to get buy-ins and the had a tutorial on how to use the design system in the organization.


As nanopay grows and scales, problems of inconsistency and low efficency started to arise. With a development team of 20 and a QA team of 3, plus a design team of one, we were eager to find a better and more efficient process.

Outside demands, inner pushes and solutions for the problem
3-1-1 / Above shows what triggered us on starting building a design system

The technology decision has a huge impact on design because all the services will share the same design structure, similar user flow, with the same look and feel. Migrating services also means a reskin of the previous services to match the core product.

This is a critical challenge for me, as this required an overall deep review of the existing products and a more visionary, compatible and mindful design.

Goals & Limitation

Due to limited resources and tight deadlines to deliver products to our clients, we had to minimize the development cost, which means we could not afford a complete redesign. What I decided was to put the latest B2B portal as the main and revise based on it.

Building the Design System

Building up the design system is like building a house, you will need to build the foundation first, then gradually adding the bricks and concrete, and finally paint it in the beautiful colors you like.

Steps of building a design system
3-1-2 / Graph of how I pictured building a design system

#1 The Foundation: Seeking The Patterns

Therefore, the first step I took is to go through all of the existing products and look for commonalities. We have the Retail Portal , B2B Portal , Support Portal and other web-based tools for our clients. I categorized the UI design based on the different structures and created the general layout.

Screenshots of different UIs
3-2-1 / Looking for patterns in the sea of UIs

As a result, I summarized 4 patterns for the platform: List View, Detail View, New Build View and Setting View. They are the key skeletons for the whole platform, and almost all the screens can be categorized into the 4.

4 skeletons of the platform
3-2-2 / As a payment services provider, the list is an extremely important element: Transactions, invoices, users...they are all living in the system in the form of a list. The detail view and new build view are originated from the list view.

#2 Adding The Bricks & Concrete: Reusable Components

Remember the giant style guide we create after every project? There are buttons, checkboxes, lists, tables....almost every actionable element appeared in the product. I looked through the style guides and looked for the components playing the same role, then I unified them together based on the design of the B2B portal.

Screenshots of different style guides
3-2-3 / I created many style guides when working on different projects, which have become a big hard-to-manage burden.

I also did some online research on design systems like Material Design, Shopify's Polaris, Atlassian Design. They focus not only on components, but also animation, marketing, content, etc. As a starting point, I referenced their information architecture and combined the unique nanopay style, finally came up with the following list.

the IA for components
3-2-4 / Initial IA for components part

For each actionable component, I showed how it should look under different statuses, like hover, focus and disabled.

3-2-4.1/ Above shows the components of the Design System, how the layout of each part looks: a title, an actionable sample, and the explanation.

I also added the use cases for the components, like the main button should be used for primary actions only. Separated components are like separated bricks, only the proper concrete can put them together. Having a specific component dedicated to the specific use cases is the key to deliver a consistent user experience.

#3 Painting The Surface: Visual Style Guide

The last step in building a house is to paint the wall and add the decorations, and for the system, is the visual style guide.

3-2-4.2/ Above shows the color scheme and text styles of the Design System

Bridging The Gaps

Besides the efforts to standardize and unify the design, I also worked on optimizing the workflow when designers collaborating with the rest of the company.

1. Between Designer & Marketing Team

Sometimes conversations between the marketing team and me are like this:

Hey Jingyi, can you send me a picture of the logo?

What format and size do you need?

Ah, jpg I guess?

And size and resolution?

hmm...What is resolution?, it is like dpi, ppi.

But wait, what do you need this for?

Oh I want to print out a copy to put on the event desk..

I see! In that case, blah blah blah...

Or this:

Hey, Jingyi, can I get a png of the logo?

What is that for?

To replace the twitter profile pic, looks a bit odd now😥

I shared a Google link with you last week

Well, I can't find it, can you just send me through Slack?


Marketing folks asked me for branding resources often, and it is hard to find them within massive links. To minimize the unnecessary back and forth, the constant file transfers, I moved the branding resources to the design system and they can have easy access to the files they need.

Screenshot of branding resource
3-2-5 / I've prepared different formats of logos for prints, social media, design and development.

2. Between Designer & Development Team

We have conversations like this:

Jingyi, what's the hex code for the submit btn in XX portal?

I think it is #xxxxx, you can check on Zeplin

Yeah, but not sure which one to follow, there is a project XX for Client B. Is #xxxxx same for Client C?

Yes, they should be the same

kk, thx

btw, do have an email design for when a user got an invoice?

no...but as it is the same layout as when they received an invoice.

actually, I will make the screen now


As we are managing multiple projects at the same time, when developers are not clear with something they will come to me. While I'm happy to help them, putting the shared style guide online with just one URL away, saved all our days.

Email skeleton
3-2-6 / I've designed a general email skeleton with specs so developers can create the email with content only

3. Inside The Design Team

I created the design templates for the nanopay web platform, color scheme, universal text styles and email templates so I can easily start a new project. (Also for future designer folks)

design resources
3-2-7 / Design resources

4. Supercharge Designer's Workflow

Though I'm the only designer in the team, I feel it is never too early to start building and using a component library, as it can greatly speed up the visual design process and make rapid-prototyping possible in high fidelity.

demo of how to quickly create a mockup using components library
3-2-8 / I made the general component library a shared library, so I can use the same components across different files.

I was able to do text overrides, color overrides, swapping symbols and finished this mockup in less than 4mins!

Thanks to Michael Fouquet sharing how they build up the sketch library, I was able to quickly put the components together, launch, and start using them!

The Development

I was responsible for designing and developing the design system website. As it is an internal tool and with my limited coding experience, I focused highly on the experience on laptops(most of the use cases happen in the office).A one-column static layout also makes it easier to develop as a responsive website. It was launched for internal use at the beginning of 2018.

responsive layout
3-2-9 / To make the menu prominent enough on mobile devices, I chose to show the menu instead of hiding it in the hamburger menu.

Challenges: How We Got There

During the process, I have encountered three main challenges.

#1 Balancing Between Different Projects

When I was trying to find patterns in different projects, I noticed there are some components which are unique to a specific project. For example, for B2B users, there is an invoicing capability while for retail users, there is not. All these cases required a careful review of user goals, use cases, and business requirements to determine the user groups. I worked closely with the PM and development team on identifying user groups and access. Based on our services, we identified 4 basic groups: Merchant, B2B, Support, and Admin.

Structure of nanopay platform
3-3-1 / Overall structure of nanopay platform after migration services to the same server. The retail solution contains consumer app and merchant app, which are not part of the nanopay web platform.

With all the components of different projects in one page, we can easily identify the ones that are shared in common, and we can easily merge them. For those which are unique, there are also shared styles used, like the list item below. But for some very unique cases, we include it in the design system as a special component.

Similar pattern and style for invoices, tickets and transactions
3-3-2 / Invoice, ticket and transaction page have different details, but they all shared the same list component.

#2 Solving Conflicts Between Technology & Design

Migrating the services is a technical decision, but it also had a great impact on design. During the migration, we had lots of unexpected changes to the GUI, such as the navigation structure, unexpected interactions, and some styling details. Being frustrated, I decided to have a meeting with the development team to understand what happened in the back.

I identified: 1. I didn't think comprehensively about how the projects should look like after the migration, so for the parts I missed, the developers filled in based on their understanding; 2. There are some changes in the technology and business direction and strategy.

To solve the existing conflicts, I arranged a meeting with the PM, the development and product lead. We used these two graphs to help identify our primary priority in resolving the usability problems caused by technology changes, considering the business impact, user needs and development cost to make the best choice for nanopay.

Balance between business impact and ease of use Balance between development cost and ease of use
3-3-3, 3-3-4 / In the first graph, the green ones with a checkmark indicates these changes are working fine and don't need further improvement at this point. The area with the biggest business impact, lowest development cost, and most serious usability problems is the sweet spot we need to focus on.

We realized this is a communication problem. By this incident, we learned not to take things for granted, always share information equally, and ask for clarification if not clear.

#3 Getting Buy-ins & Adoptions

Building a design system costs time and money, which without the support of the company I could never have made. As the only designer in the team, getting buy-ins is very important to get started.

From the Leadership Team

I was lucky enough to be at the time when the company was having changes in technology framework and direction, so the conversation was easier for me. I talked with the head of product about the advantages of having a design system and why it's a right time to build it now. I emphasized scalability, speeding up the design process and the ease of switching themes in the conversations.

The executive team was especially interested in the themes as one of our main sources of revenue is providing white-label solutions. I did a demonstration on changing color universally using SketchApp and I think that was a game changer.

sample screens for themes
3-3-5 / The sample screens I used to show themes

From the Developers and Other Colleagues

Developers are good friends of designers as they help to make designers' solutions come to life. During my day to day life, I have come across some cases (the ones I have shared above) like developers jumping in and asking me for some random assets. At first, I thought it was because they don't know where a specific icon is, but after talking with some of them, I noticed people may not have a clear understanding of different projects going on.

I focus on efficiency in this part. During our weekly learn and share, I demonstrated how to use the system to quickly find specific resources and related materials of the project. I was able to stage the design system in our internal network so developers can go on anytime they want, doing their favorite "Ctrl + F".

My other teammates like marketing and sales team, don't necessarily need to use design system. But they do need access to specific branding resources time to time.

What People Said

The nanopay design system was launched internally at the beginning of 2018. For sure there are lots I can improve, such as showing real coded examples of the components, providing real-time examples for theme-switching...But I'm glad to get some positive feedback!

It also reduced the time I spend on manual work for hi-fi mockups, which allows me to spend more time understanding the users, exploring different flows and interactions, communicating with the team and making better design decisions.



Above / It is based on the assumption of "The designer spends three hours doing hi-fi mockups a day".
"I can now search for a specific project and view the details if I'm interested"
"Don't need to bother Jingyi (the designer) again for the logo"
"Clear documentation on different colors used in different projects, great"
"know about our product more!"

As for now, I only identified the proper CSS for different text styles. In the future, we'd like to build our own CSS components library, to accelerate the development process, minimize design discrepancies and reduce the workload on universal changes, making functional rapid prototyping possible.


#1 Start with a pilot before asking for too much.

In the business world, especially for large projects, people don't risk the whole thing at once, instead, they usually start with a pilot to validate if it is worthy of putting more resources on. It is the same for a design system. As the only designer, what I have created was something very basic: the visual style guide and a summary of current components, which is more like a guideline rather than a functional system. I was also responsible for the development of the website, which means it didn't cost any extra development. In this way, it is easier to get buy-ins and we can achieve more once we have the pilot up and running, and people start to see the actual benefits.

#2 Don't simplify things for the sake of it.

There is no one-size-fits-all solution for different payment services we offer, especially when designing for those services, we've put many efforts to find out the best practices, so we shouldn't make all these in vain. It's important to keep the components in a manageable amount, but we should also understand there are some parts that should not be generalized and over-simplified, as they serve a specific goal

#3 Speak people's language when communicating with them.

A developer cares about performance, just like a visual designer cares about pixels. What I have learned in the conversations with my teammates, is to always speak their languages. Talk about the business impact, KPI, KYC with the business team while telling the development team how it can help them be more efficient and reduce the amount of code they need to copy and paste. In UX design, we advocate putting ourselves in the user's shoes, it is the same situation for an internal tool. Empathy and story-telling go a long way, only if we understand what makes them frustrated and propose something that can truly help them in their daily work, they are likely to appreciate the work we do.

#4 Walk out of the designer bubble and look for opportunities in the real jungle to show people about design.

As the sole designer in the company, sometimes I got stuck in my own corner doing my "design". I was too focused on it sometimes I missed out lots going on inside the company, but I believed people would understand what I was doing. However, doing design is about solving a user's problem, but it is also about communication and collaboration. The design system is my first try at optimizing the internal workflow and a great opportunity to promote the value of design. As the easiest way to validate design's value is to provide a concrete example related to the benefits of your audience.

Related Links

Next Project :
LifeGrow: Grow A Better life With Plants