Table of Contents
Table of Contents
System Design, Front-end Development
7 min read
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.
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.
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.
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 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.
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.
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.
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.
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.
For each actionable component, I showed how it should look under different statuses, like hover, focus and disabled.
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.
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.
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.
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?
...er, 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...
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.
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
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.
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)
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.
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!
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.
During the process, I have encountered three main challenges.
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.
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.
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.
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.
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.
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.
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.
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.
"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.
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.
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
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.
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.