Global Design System for PlayStation

The style guide is an evolving resource that globally united PlayStation’s digital landscape to keep the experience cohesive

In this study, I am going to describe my process of creating the Global PlayStation design system from the initial idea to the final stage.

The Goal:

• To create an efficient workflow between designers, engineers, and PMs
• Unify UX through a Shared Design Language = source of truth
• Connect the team through common patterns, tools, and code that deliver the next generation Playstation Experience
• Create and maintain a consistent, cohesive experience that is easily learned and scalable across the platform and associated devices

Responsibility:

My day to day routine as a UX/product designer includes:

• Create flows, wireframes, and interactive models and corresponding documentation
• Conduct research to ensure the design is in line with corp standards and best practices
• Develop components, guidelines, and specs/tokens for engineers
• Collaborate with stakeholders including product managers, the design community, and engineering teams around the world in the USA, China, and Japan, to build inclusiveness and shared vision.

The Plan:

1. Audit, Research & User Persona
2. Make a Low-Fidelity mockup for page templates
3. Populate respective pages with agreed content (Mid Fidelity)
4. Convert from wireframe to high fidelity and fill the gaps in content
5. Documenting the Design Style Guide
6. Collaboration with Developers
7. Conclusion and findings

Step 1: Audit, Research & User Persona

Internal Research

First of all, I learned about my team’s process of starting a new project: how they track the process, how they collaborate, and who makes the decisions. I demonstrated my day to the day design process and how I make decisions using best practices to collaborate with stakeholders to achieve the company’s objectives.

External research

I did an audit and external research comparing design systems from other companies. After collecting all the information, I made a mood board consistent with the future style guide. I started this project with some heavy research. I read medium articles, studied the guidelines laid out by Google, Facebook, Apple, Airbnb, and Atlassian, and searched for other designers who faced a similar challenge. Resources can be found at the end of this post

Audit

I started out experimenting with three different products that would be applied to the system. The user interface (UI) and style changed over time. When I felt I had captured every color, button, icon, and design pattern, I grouped them into categories and divided all the content into dark and light mode backgrounds. Viewing them side-by-side revealed exactly why we needed a system. There were dozens of button styles, different color usage rules, inconsistent grids, and breakpoints, and incorrectly applied font.

User persona:

Who are the users of the design system? They are designers, developers, and vendors who provide games for Playstation. In this project, I didn’t have a focus group of real users, but I worked with the designers and developers and I tested on them.

Step 2: Low-Fidelity Mockups

PlayStation recently changed its breakpoints and grid system and I had to redesign the layout to follow the new rules. In total, I created twenty-five variations of page modules ready to be converted to the real design.

Step 3: Populate respective pages with agreed content.

This design system should be responsive even though 70% of users will only use it on a desktop. However, the goal was to create responsive pages for every guideline/component. For each page, I created low and high-fidelity mockups. Firstly, the low fidelity mockup included the page layout and Loren Ipsum text plus placeholder images and video. After collaboration and daily sync, I received approval from other designers, engineers, and product managers and was primed for step 4.

Colors:

The main goal was to create a color palette to make it easy to find the same color using white and dark modes. I created a few options, but for the final result, I decided to select Option 2, because the left text is not necessary. The focus should be on the colors.

An additional idea I had was to create clickable color numbers. For example, the user could click on a color and its number would automatically copy to the keyboard. Then, they just needed to “paste” it on the sketch. But the developers rejected this idea.

While it’s pretty simple to build responsive components, it’s not so simple to mockup responsively. That was a tricky part. It’s important to design web UIs that work at different browser widths. I used Sketch for creating responsive mockups. It provides the ability to set elements to respond in different ways as they grow or shrink in size.

Step 4: Convert from Wireframe to High fidelity

High-fidelity mockups show a lot more detail. They give a better taste of what real UI elements might look like. They make it easier to communicate functionality to developers.

After approval of all pages by stakeholders, I started to convert low fidelity mockups to high fidelity with real content images and video. The tools I used for images and animation were Sketch and Principle. Another tricky part was writing the content. Each guideline included not only the image and video, but also the description, the “How to Use” section, best practices, and so on. I provided that information and synced with copywriters for approval.

For each guideline, the UX producers team created a JIRA ticket and tracked the process every two weeks and created a new stream for me. The company works in an Agile environment. My team had a daily standup-meeting, a weekly meeting with developers, and a bi-monthly meeting with all stakeholders.

Step 5: Documenting the Design System

When I am creating a design system, I am always thinking I won’t be the only designer or developer who works with it. Most importantly, I always think about the users. For documenting the rules and principles I recommend using Google presentation.

It’s easily accessible by all stakeholders, plus they can comment inline, which is great for feedback. It is also easy to show the visual part of the documentation in a friendly and engaging way.

As the documentation is in a private Google Doc, I’ve captured some screenshots below to give a good idea of how it was constructed, laid out, and what it contains.

Step 6: Collaborate with Engineers

As the documentation was taking shape, the design needed a way of communicating and tracking the build and integration of the system to the developers.

Many companies recommend using GitHub for this. But because I was the one organizing all the documentation, I collaborated with engineers through Slack and once a week at the meeting call where we discussed all of our questions. I prepared a list of ‘issues’ for specific guidelines — sharing previews of the design and specs to ease the development process. This way the engineers could tackle these bitesize chunks one-by-one so nothing was missed.

One of the goals of the design system and style guide is to help designers, developers, and product managers all speaking the same language. We can help to achieve this with consistent, semantic naming conventions we’re all familiar with (in the design and code), such as design tokens, font styles, colors, templates, grid systems, and UI patterns.

Step 7: Conclusion and findings

I see each design project as a new lifeline. It starts as an idea and in someone’s mind, then improves and grows. The project can be successful only if people can collaborate.

• Define problems and goals together. Your team will be more aligned and you have more perspective to make a decision.
• Don’t be afraid to express your opinions and ideas. If you disagree, describe why. Build a working culture with your team where they are confident in sharing their thoughts.
• Treat your team members with the utmost respect. Remember that every role has different difficulties. Always support and encourage each team member in any condition.
• Actively listen to the feedback from your team and consider how you can apply it. Avoid discarding the feedback without really understanding why it matters. Never let things get personal. When you or your team are facing a problem, discuss it immediately, and try to find a solution right away.
• Make time for brainstorming. When you collaborate with your colleagues in a relaxed environment, brilliant ideas arise.
• Try to test your assumptions on the real users and work based on data

The whole team should focus on the customer in mind. We have one goal: to make our product better and see happy customers. Flawless products can only be delivered by a dream team. I love working in a highly collaborative environment where each person’s voice and contribution is heard and valued.

The End

I hope you enjoyed this case study, an insight into my design process, the tools I use, and a preview! Let me know if you would like to collaborate or have any questions. See you next post.

Final Result: