Roberta Scerri

The Scenario

EVO Payments is a global payment processor having both e-commerce and in-store merchants in USA and Europe. They process millions of transactions and have clients in multiple industries, including gaming, manufacturing and energy. The company has both in-house and outsourced developers even in China.

The company had started building products ad hoc, according to need, and this led to inconsistency in design and user experience. Their aim was to re-visit this experience and make the design consistent in all their products.

The Workflow

In order to achieve their goal, I suggested we build a design system, taking the available scenarios as the base framework for the initial components required, and adding further components according to the planned products. I started this design system project by re-designing their checkout UIs in different integrations to define the initial components. Then I moved on to the next product in the pipeline: the Service Portal.

In a nutshell, the Service Portal – in MVP form – is intended to simplify the way the company’s service/customer care desk operated in order to increase efficiency and reduce manual work (as it allows for even more user errors). Service desk personnel can search for specific merchants, go into their profile and see the users within that merchant, update permissions and help merchants with different steps of user onboarding, review and switch on/off available payment methods for that merchant and so on. The big picture is to expand this portal to include a whole hierarchy, such as Business Units, ISOs and ISVs and add further functionality with each release, to a point where all onboarding operations and merchant and user actions can all occur via this portal. Having this would not only be a business opportunity for the company, but would also organise multiple, complex workflows and log all actions, making it safer and more efficient.

As I designed the Portal, I was adding new components to the design system, updating it as I go, and also testing how these components work together. It worked really well, as now I was completely certain that the pieces of the puzzle within the design system style guide work together in multiple ways and forms.

Naming Convention

For the design system, I created a naming convention that made it much easier to name variants of each component. The name included a reference to the component’s name, type, state (active, inactive etc), and also the device, in a uniform order and naming style applied to all the components.

This system made it much easier to communicate which component or variant I was referring to, and also simplified my workflow on Figma as while building screens I could switch between one component variant and another with just a click.

Redlines

Redlines also composed a big part of my workflow, and they serve as a great guide for developers when building the screens. The naming convention made it easier when labelling the components within the screens, as I did not have to insert measurements and style notes each time, since all the information was in the design system style guide.

Interactivity and Animation Notes

Since at this point the design system has not been yet developed, I added all the information I could for each component, including application instances, animation style and timing (where applicable), exceptions and user interactivity together with system feedback. This information will provide the developers with all they need when building these components, as how they look is not enough; one needs to know how they work and react to the user’s input.

Design Tokens

Design tokens are the basic elements and styles within a design system, including fonts and colours. Defining those sets the base framework for the all of the components within the design system. Below are a couple of screenshots showing the fonts and colour scheme.

Components

The next level after Design Tokens is components. I divided the components into sections, such as Buttons, Selectors, Icons, Headers etc. I redlined each component and provided notes for each one. The screenshots below offer some samples of the components that I designed.

Patterns

Patterns such as notifications are created by bringing together multiple components into a container. Below are some screenshots showing designed notifications accompanied by relevant notes.

The Service Portal

I designed the Service Portal while building the design system style guide. Below are some screens showing some of the flows that were created for the MVP:

• Merchant Search
• Add User
• Edit User
• Payment Methods
• Configurations

Merchant Search

Merchant Search Flow: the service desk person can search for a merchant by typing the name and merchant ID, or one of those entries. When the entry does not provide an exact match, a list of close results appears.

User Manager

User Manager: This is the first screen that loads when the service desk person accesses a merchant. Apart from seeing the list of users (the user accounts with errors or locked are pushed to the top to get the user’s attention), other actions are available, such as adding new users, searching for users and editing users.

Add Users

Add User: In this section, the user details and permissions can be edited. Unless the user creates a password after going through the 2FA process, the account is still not active. At this point, the admin can resend an activation link and the window shows the status of that user’s account.

Payment Methods

Payment Methods: All payment methods are divided into payment type sections. Each payment method is placed in a dedicated card component which shows the type and the status of that method. Whole sections can be turned off by the service desk personnel, and any deactivated method would disappear from the merchant’s e-commerce website or application. If there are issues with a payment, the card takes on an orange tint and when accessed a ribbon notification appears at the top of the payment details window.

Further Work

The design system style guide is only the first step towards creating a final design system. The components need to be developed in line with the guiding notes provided. A great approach to doing this is teaming up the lead front end developers and using tools like CodePen to determine the best method to code components.

One of the functionalities in the backlog is the Upload Users. This is where the user can upload a CSV file containing multiple users and add them to the User List. The screens below show how the basic user details in the CSV sheet can be edited within the portal window before being added to the User Manager. The user can then access each user separately to refine other details and permissions.

Conclusion

This was the first experience for me designing a design system, and it was quite challenging in terms of attention to detail, consistency, flexibility and functionality. I got to discover new tools such as Diez and CodePen and became more familiarised with Brad Frost’s Atomic Design way of thinking. This experience also further shaped my way of working with Figma across multiple design files for different products based on the same styles and built up from the same components. I would like to be a part of another design system project, and have the opportunity to see the components be developed and making the product releases a much seamless and efficient process to appreciate the true impact of a design system on a global product.