In a large company like PayPal, working on local projects is a real opportunity to test global frameworks and guidelines.
I've been lucky enough to work on the launch of a prepaid card in Turkey. I won't really talk about all the facets of this project (users flows, visual design, interaction design, copy, localisation challenges,...), but I will try to focus on one thing that I found really interesting : the livecycle of design documentation in a large organisation.
PayPal is a huge company. Even when you just consider the design, a lot of different teams and disciplines are involved : visual design, copywriting, interaction design, marketing design, product design, global teams, local teams,... consistency is a key challenge for all of them.
PayPal handles these consistency issues with a heavy design documentation : visual and copy guidelines, interaction patterns, libraries of components,...
It's impossible to define all the specific features and issues that will be faced in so many projects, however taking care of the most common ones enables design teams to focus their work on the questions that are really important.
From a local point of view for instance, that means that a large part of the job consists in finding what makes a project really specific. Once these key points are identified, designers can focus their work on them.
For the prepaid card project, we followed the brand guidelines for most of the visual elements: buttons, text styles, layouts, icons,... the work was mostly about putting all these blocks together.
We faced an interesting example of a specific issue on this project.
As you can expect, PayPal has defined a list of solid interaction patterns for when you need to ask credit card informations to a user. You can literally copy and paste an existing form that will handle everything required.
However, we learned on this project that a lot of turkish people were not familiar with credit cards (most of the people use cash), and therefore were not comfortable at all when we were asking them to type informations found on the card. This is a very specific issue.
So we've decided to add visual cues to help people to identify the different pieces of information that were asked.
This kind of internal communication through documentation is actually a two-ways process. If global rules are applied on local projects, they are also fed from them.
In the case of our activation forms, the visual cues were a new interaction pattern, and they've been added to the global documentation so they can be used again if the same problem is faced on another project.
But that's not enough, long term communication is critical: you also need to save the thinking behind your design decisions.
At PayPal, we used to do that through "design rationales".
The goal of a design rationale is to explain the main design directions that drove a project. Therefore, it's important to be clear and to go straight to the point. For the prepaid card project for instance, our design was driven by 4 principles. We tried to create a very simple template of design rationale to explain them.
Starting by defining what's at stake :
We only had to ask one question for each principle in order to allow any designer to bring its design decision face to the initial design mindset:
Being part of this project was already an amazing experience, but the most memorable thing for me was to realize that we can apply design methods and processes to the design processes and tools themselves, like what we did with this design rationale.
Don't hesitate to have a look at other case studies.