Introduction and role

design language

Venice Interface Guidelines (VIG), is the design language for the PayPal Consumer Mobile App. It is a project I co-created with my colleagues Chris Sybico and Libo Su. The mobile app, Venice, is a particularly customized app in its design. It has its own PayPal typeface, its own gradients and colors, its own iconography, motion, etc. Designing for Venice was at times an inconsistent process. There was multiple duplication of assets; reusable components, framework and patterns were not being shared across the design organization; and time spent with developers was inefficient. To solve this, we decided to document every element within the app and create a centralized repo where building blocks for Venice would live. Our hope was to create reusable components and reusable code that could be shared between different teams and make conversation with developers more efficient.

Documenting the app

The VIG initiative started from a simple problem that almost every designer has gone through: exporting assets.

During my very first project as a Product Designer at PayPal, I was asked to export assets. With that request arose a few questions: how and where to export them, what to name them, and determine what assets are already in the app.

I got answers to some of my questions, but not all. I suggested to my team that we should have one folder in our cloud system that would contain all the assets for the app. They would have meaningful names to avoid duplications and be available for all designers and developers to use. In the process of documenting all the assets and making them shareable, we realized that there was so much more than just assets that needed to be shared throughout the organization. There were styles, components, patterns, frameworks and animations that needed to be documented and made available to use in order to make the product more consistent and thus more intuitive and enjoyable.

What is it?

VIG is a work-in-progress. It started off as a side project and our hope for VIG was to make an internal website where anyone building for Venice could go to for reference. If someone needed a button, there would be no need to recreate a button from scratch: it would be available on VIG both for designers to use in their designs and for developers to grab a code snippet from.

How to use it

VIG should be used by anyone who is involved in building for Venice. Take buttons for example. Currently, we have three different types of buttons for two different themes. There should be a detailed description of how to use those buttons, when to use a Full Width button vs. a Split Button, and provided examples of where these different types of buttons are currently being used.

Specs and measurements

When we design for Venice, we follow a 8pt grid system. We use what we call spaceblocks to lay out the screen. That allows elements not to seem like they’re floating randomly in space. The spaceblocks also help developers to see more quickly how different elements are spaced on the screen relative to one another.

Motion

Motion has become an essential tool in today’s UI. Venice is no exception there. We wanted to incorporate elegant motion to further guide and educate the user on what is happening, to give context, and furthermore to add more delight to the experience. We used framer.js to document these micro-interactions from which we could then extract values for developers.

Current state

What started as a side project has developed into a great tool when onboarding new designers on Venice. We came to realize that our vision for VIG will need some rethinking. Unanswered questions remain: how will we maintain VIG? How long will it take to get a global company onboard with VIG where all designers and developers are using it? Who, indeed, is this for? Although VIG is merely a working prototype as of now, it has added much-needed consistency throughout our designs and sped up the process when new designers join our team.

I now own, run and lead VIG as one of my projects. My hope is to create a collaborative environment and advocate consistency in our designs. VIG is merely a guideline, and does not hold all the answers to our users’ problems. If a solution to a particular problem does not exist in VIG, designers are encouraged to explore other possible solutions which will then go through a review and – if proven to work — be added to VIG.