In a large company like PayPal, working on local projects is a real opportunity to test global frameworks and guidelines.
I've been lucky to work in the team who was in charge of the launch of a prepaid card in Turkey. I won't really talk about all the facets of this project (users' flows, visual 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 only considering design, a lot of different teams and disciplines are involved : visual design, copywriting, interaction design, global teams, local teams,... consistency is a key challenge for all of them (particularly for a payment service).
PayPal handles these consistency issues with a heavy design documentation : visual and copy guidelines, interaction patterns,...
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 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 had to stick with the brand guidelines for most of the visual elements : buttons, text styles, layouts, icons,... the work was about putting all these blocks together.
However, from time to time, we had to create new visual elements (the main homepage banner for instance, or the prepaid card visuals). Here again, a large part of this work consisted in trying to find inspiration in existing elements.
We faced an interesting example of a specific issue on this project.
As you can expect, PayPal defines strong interaction patterns when you need to ask credit card informations to a user. You can literally copy and paste an existing form that already manages errors, help, and everything required to allow users to process this touchy task with confidence.
However, a lot of turkish people are not familiar with credit cards, and therefore are not comfortable at all when we ask them to type informations found on the card to activate their account. This is a very specific issue.
In order to handle this problem on our activation flow, we decided to add visual cues to help people to identify all the informations that were required in the form.
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, this new interaction pattern has been added to global documentations, so it will be used again if the same problem is faced in another project.
But that's not enough, long term communication is critical : you need to save the reasons behind your design decisions for later projects.
At PayPal, we used to do that through "design rationales".
The goal of a design rationale is to explain the main design directions that have driven 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. In order to explain them, we tried to create a very simple template of design rationale.
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 :
Taking part in the design of this project was already an amazing experience, but I think that the most memorable thing for me was to realize that we can apply design methods and processes to the realisation of a design document like this design rationale.
The work is the same : reduction, user centric,... this was for me the confirmation that everything can be designed.
Don't hesitate to have a look at other case studies.