Digicert Design System

On October 31st 2017 Symantec was bought out by Digicert; it was the case of the little fish eating the big fish. Symantec was the world's leading cyber security company. They are responsible for making sure anytime data is sent or received online it is encrypted. Digicert is the world's premier high assurance digital SSL certificate provider. If you have ever seen the secure icon in the next to the url on your browser most likely Digicert has certified & validated that website. Basically they make sure that each site you visit is legitimate.

By combining these two amazing products together, users are now able to know that the sites they visit are valid and that their data is encrypted. It was a win-win situation for anyone who purchased SSL certificates. While the merge sounded good on paper the question for those working at the company was how will this merge happen?

The Problem

Before I came onboard to the company, several offices around the globe were either kept open or shut down. Designers & developers were either let go or asked to move to new locations. Team structures were organized to be a mix of Digicert employees & Symantec employees. During the first year of the merge it was decided that Symantec's functionality would be added to Digicert's application CertCentral. CertCentral is an application that allows Digicert users to manage their SSL Certificates. All visual components, patterns, and interaction behaviors from Symantec were to match CertCentral's current style.

Months after the merge it became clear that the style guide, workflow procedures, and standards of Digicert were not adequate to meet the company's growing needs. In many cases the guidelines for designers/developers were loose, not written down, or lacked enough information to create accurate & consistent products. Designers could choose which tools they wanted to use which made it harder to collaborate with other designers. To make communicating designs even more complicated many designers & developers were not in the same location or time zone.

This forced designers and developers to rely on whatever procedure, tool or workflow that worked best for them. These loose standards lead to many problems including inconsistent visuals, strange ui behaviors, unique patterns only used once, as well as unclear expectations of tools, procedures and workflows. In some cases designers & developers often ignored the style guide all together.

Interface Inventory

Many attempts had been made to establish design standards and procedures through a style guide to help fix these inconsistencies, but each time the result ended with little to no success. This was primarily due to designers & developers having to split their time between working on their projects and working on the guide. Rather than slow down or halt new designs and features from being created the company decided to bring on another designer to work on the guide. This is where I come in. I was brought on to solve many of the problems that had been plaguing the company since the two companies merged.

My Role

As with any project before I could start I needed to understand the needs of the business as well as the users needs.Several kickoff meetings between designers, developers, project managers as well as members of the marketing department were held. We discussed that our primary users would be ux designers and front end developers. I was also able to find out the problems previously mentioned as well as the tasks they needed to accomplish.We came up with five missions for me to accomplish and prioritized them in this order:

1. Establish design: procedures,workflows, trainings to help on-board new and old designers.

2. Create a visual widget library with page templates to speed up design production

3. Unify all visuals, interactions, behaviors and patterns through a style guide.

4. Provide a source of truth where designers & developers could find answers to their questions.

5. Heal and fix communication issues with the marketing team.

Unlike previous designers who had little to no time to establish work on these items, this was my main task. I was to be given six months to fully research, develop and test these new guidelines. With the end of my contract in mind we began to set milestones for when each task was to be completed. The ultimate goal of these tasks was to create consistent visual standards and faster turnaround times for our wireframe designs.

Establishing Workflows and Procedures.

With our goal in mind I decided to do some research to uncover any pain points regarding the procedures, workflows, and thoughts about the widget library and onboarding training. After speaking with the ux team manager we decided to focus our efforts on fixing the way the ux team was communicating with the developers/stakeholders. I was able to identify the following problems/suggestions:

Developers Pain Points Notes

• High fidelity mockups can be confusing to know what's final and what's in progress.

• Designers need to spec out each page; sometimes they are inconsistent.

• Due to a long history of inconsistent coding making major changes would take up time, resources and it may cause larger bugs in the system. So basically not worth it.

• It would be easier to make small changes slowly to the ui to fix the inconsistencies.

• We could create new css classes and use them from now on which will allow major changed in the future. It would take awhile to setup but once done future changes would be alot easier to implement.

• At the end of the day being inconsistent in the ui is a lower priority unless it affects the users ultimate experience with the site.

• Developers would follow a style guide if the designers agreed it was the source of truth.

Veteran Designer Suggestions Notes

• Using the widget library would reduce having to build or copy and paste assets.

• Axure has a feature that allows designers to turn wireframes from high to low fidelity.

• Past style guides failed to be relevant because they were lacking in content.

• Having a source of truth would be nice but a widget library would be more helpful.

• If a style guide was created veterans would only use it occasionally if they need to reference when to use one widget over another.

• If the style guide included the spacing and visual specs there would be no need to make accurate mock ups.

• We need to have a process for adding new components into the style guide.

• In the past there was too much politics in making the guide. Someone needs to be in charge of the guide and make the final decision for guidelines.

• Existing components need to be documented and spec'd. If there are any minor holes in the documentation I would be allowed to fill them in using best practices.

• It's hard to share a visual library when we use different tools

New Designer Pain Point Notes

• There was no training about the tools, brand guidelines or company culture/structure.

• I am not sure when to use one component over another.

• A style guide would be helpful to get up to speed on the brand.

• A widget library would be great; how do I access it?

• We are using a lot of tools to track our notes, and progress; can we reduce them to one tool?

Based on the feed back and other research the following decisions were made:

• All wireframes need to be black & white using axures in low fidelity features

• To speed up designs & be consistent designers must use the widget library.

• A spacing system will be implemented in order to keep everything consistently spaced.

• A new style guide would be created which will be the source of truth. All designers, developers, QA's and content writers must make the style guide part of their workflow.

• A Kanban board will track the progress of each component that needs to be documented.

• When a component moves into the needs review column a style guide committee consisting of designers, developers, content writers would review finished pages.

• In order to reduce politics committee provides feedback but the final say goes to whomever wrote the page for the style guide.

• If there are gaps in the guide they must be filled using best internet practices.

• Designers would no longer need to spec out everything in their wireframes.

• All specs such as visuals, behaviors, states and interactions will be covered by style guide.

• If a new widget is created it must be approved by the committee. New widgets must be reusable & universal.

• Once a change or new item is made in the guide a jira story would be created to add the issue to the backlog.

• Training & onboarding for new designers and developers will be held in the style guide.

Here are some examples of the results that came from my research.

Creating a Widget Library

While figuring out the pain points for the designers discussions were had about how we would be able to share this library of ui components. It was decided that in order to share this library we would all need to use the same tools. Since some of the designers refused to work on a Mac, we opted to stop using Sketch in favor of Axure. This allowed us to have a shared library that worked on multiple operating systems.

With everyone using the same tool it was time to build the widget library. This would allow the designers to be consistent in their hand off's to the developers and save them from having to build all the assets themselves. To begin I conducted an interface inventory. This helped me determine what visual components were being used and where our inconsistencies were.

Once I had made a through list of all the assets we needed for the library I checked with the design team to make sure there was nothing I missed. In collaboration with developers and designers I presented my findings on the inconsistent ui patterns and behaviors that appeared across the app. Plans were made for me to document these grievances and propose new visual/ behavioral patterns for these elements.

Having done a similar system for previous companies I recommended we use atomic design to create the widget library. This way each element of the screen would be designed with a purpose and would be consistent in its look and behavior.

By using files from previous designers as well as current files I began to piece together the beginnings of the widget library. Any item that was missing was created from scratch and added to the library. I was also able to create several page templates in order to help speed up the design process. Since my users were the designers I would often check to make sure that the widgets were labeled correctly. This would allow them to search for the widget they needed without having to scroll through hundreds of assets. Training on how to set up the widget library was created in the style guide as well as confluence. This walked the designer step by step in order to help them connect to the library.

The Style Guide

Having completed the widget library I moved on to establishing a style guide for the company. I began to work with content writers, developers, designers to gather any necessary requirements for the guide. I also tried to learn from the lessons of the past by exploring older concepts that were left behind in the previous guide. Talking to past designers I was able to save myself some time by learning from their past mistakes. In order to have everyone on board with the guide I need to investigate why the previous guides had failed.

After asking many questions I concluded that veteran designers prefered to not have to think about the specs but rather solve problems. They would use the guide as a reference if they were ever confused about which component to use.

New designers needed to understand the brand and the be exposed to what each component did. Developers prefered that everything was spec'd out exactly how it needed to be in the final mock, if possible having a working demo or picture would be helpful. Content writers wanted to make sure that the components reflected the voice and tone of the company.

After speaking with the IT department I need to get the bigger picture for the guide. I decided to head over to the marketing team to see their style guide. Having had experience working with style guides before I had assumptions that our guide would need to be seperate from marketing's guide. As I spoke with the marketing team we realized we could share similar brand assets such as colors, icons, illustrations & logos, however everything else would need to be separate.

The marketing team did agree should they need any ui components such as forms they would match our visual patterns and behaviors. Since the marketing team was getting ready to redesign the main site we decided to hold bi weekly meetings to touch basis and make sure we were on the same page.

With all this in mind I also moved on to do some competitive research to see how other brands handled their guides.

I concluded that a good style guide should have the following elements:

• Name of the component

• Picture or live demo of the component

• A description of what it does

• The various types & sizes of the component

• General guidelines for what should or should not be done to a component

• The elements that make up a component

• Padding and Spacing

• Interactions, States & Behaviors

• Examples of the component being implemented

• Content Guidelines

• It should be a living guide, no print. This way changes are live.

• Style guides need to be able to be accessed without needing an account.

Once the research was done we decided to use Frontify as our platform to be a living style guide. I began to come up with an information architecture as well as some basic whiteboard sketches.

The style guide information architecture would be:

• What's new?

• Getting Started

• Brand Guidelines

• UI Components

• Motion/Animation

• Style Guide Info

• Archived Ideas

After doing my sketches we formed a committee and established a workflow for documenting & keeping track of each component in the style guide. Using the Konban we prioritized which items needed to be documented first. From there we followed a flow of writing the content creating examples for the guide, getting it approved by the committee and adding any changes to our backlog in jira.

Summary

In my short time with Digicert I was able to accomplish everything we had set out for me to do.

By establishing better workflows and procedures designers no longer have to worry about: being inconsistent, creating confusion with mock ups, and having to spec out every design. They can also work faster by having page templates and widgets to start from. Developers can now have a source of truth which will help keep their code consistent as well as be a resource for new developers. The guide has been made public so that anyone in the company can access it.

Although the guide was not complete by the time my contract ended, the groundwork has been laid down. The goal of the guide was to be a living document that could evolve as time went by. The idea was to allow future content writers to add to the guide. Ideally the writer should rarely makes changes if any to avoid confusing designers and developers.

Many of the major components were documented. The committee meeting still is planning on meeting every two weeks to review new additions to the guide. Thanks to the Kanban board the team can keep track of the status of each item. As for the marketing team, relationships with them have never been better. We now share the saming branding elements and more importantly IT & marketing are talking to each other again.

Lessons Learned

The thing that struck me the most about this project had less to do about using ux principles to design a product, but more about how having the right workflows and procedures can speed up production and reduce confusion. When productivity is slowing down it is important to ask the hard questions to see where the problems lie.

With the case of Digicert the merge had left people confused as to how to do their job. Designers didn't know what the expectations were for their wireframes, this led to confusing mock ups and inconsistent designs. Developers having no reference to how things should look and behave would blindly follow the designs of the designers. Now that there are clear expectations and guidelines for how things should look and behave the team can quickly and efficiently build amazing products. In the future I will be on the look out to see if the processes and workflows we are using will enable designers and developers to work at their maximum capacity.