LDS Church Design System

Before I came on to the GVS team (Global Visual Style), the church had been working on unifying all print and content related websites through a design system. When I joined, the GVS team needed to unify all software, applications and non content related websites under the same design system. Because these types of projects were so different from each other, I was assigned to help bridge the design gap between these two departments.

I was involved in helping define, document and design a universal brand for all church applications, websites and software. The goal was to have all software and applications move to the new style guide by the end of 2019.

RIverton Office Building for LDS Technology

My Responsibilites

• Established global style guide for all church websites, apps, and emails.

• Unified design standards through documentation for multiple departments.

• Transitioned departments to align all assets to the global visual style guide.

• Researched standards for design patterns, interactions, behaviors and best practices.

• Applied and tested new design standards through wireframes, mockups, prototypes.

• Conducted design inventory of all church design assets to create new standards.

Building a Design System

When we first sat down as a committee we began to evaluate the work that had been done by the previous group. They had done a good job of laying out a design foundation that worked for content heavy websites but their standards didn't work for software and applications. Many of the design systems such as spacing, typography, buttons, forms, and navigational bar, to name a few, were too big and bulky for software design. It became apparent that a separate but similar looking design system was needed to meet the needs of the hundreds of apps and software the church created.

This was no easy task as the church's applications were highly diverse and had many special needs. We decided to focus on establishing the basics first such as typography standards, color schemes and spacing. We consulted with UX designers from every department and team to establish these standards. While doing so we tested these standards on several applications and software designs. While this was a good start, we began to move from basic standards to more complex standards.

The goal was to have a written standard with visuals of how these components were to be used to create a unified design system for mobile, tablet, and desktop.

We began to form committees to establish standards for the components of a website. These included, but were not limited to:

• Buttons

• Form elements such as ( input fields, radial buttons, check boxes, etc....)

• Toggle Switches

• Navigational Headers

• Sub nav bars

• Bread crumbs

• Pagination

• Filter Bars

• Search Bars

• Email Standards

• Tables

There were many other considerations we had to make when establishing these standards. Because the church is a world wide entity, special considerations were made to accommodate those with special needs. We made sure that everything had to pass accessibility and contrast standards. Several accessibility issues were addressed such as color blindness, low visibility, hearing impaired, people with physical limitations and speech impediments. We also had to consider these standards to apply to thousands of languages and cultures on the planet. For example some languages read right to left while others read right to left. All this we tried to capture in our documentation.

Documenting the Design System

Using the atomic design approach we broke everything down into reusable parts and set standards for each item. Our documentation had to be easy to access for multiple designers and developers who all use different design programs and standards. We had to standardize tools and machinery in order to make sure everyone was on the same page. Any change made to the documentation had to be done on a live website to avoid mixing old standards with new ones. Having researched several design systems we determined each building block needed the following defined:

• A name and a description

• Picture example with a code snippet

• Well defined purpose for the item

• What problem the item solved

• The patterns and behaviors of that item

• Interactions for that item

• Best practices for using the item

• Guidelines of do's and don'ts

• Required items.

• Optional Items.

• Date of when document was last created.

• Changes made from previous update.

Vertical Facet Documentation Example

Email Template Documentation

Testing the Design System

Once we had established the design standards we worked with early adopters of the design system to test out the new styles. We did this for several applications and software on multiple devices. The goal was to create the most realistic mock up to accompany our research and standards for approval. Once approved the developers would begin to add these components to a code repository where developers and designers could use them for their designs.

Test example of our design system.

Lessons Learned

Designing for a world wide church that has thousands of different users was an eye opening experience. I learned the value of what a design system could do to unify design standards across multiple applications and software. I began to realize how important it is to consider the needs of the users, the business, and developers. It is never safe to assume that one size fits all. The designer must be willing to research and take all things in to consideration when designing a design system.

Not only is important that you create a design system, but it must be understood by all those who will use it. The system must be documented and communicated in a way that meets the needs of its intended audience. The designer needs to be aware that documentation needs to be a living document. Documents aren’t created once and handed over to a client or developer; they change and update periodically. I plan on keeping this in mind for future projects.

While there are a lot of lessons I learned from the church the biggest lesson I learned was the importance of being thorough in all you do. Design systems can be complicated and if you aren't careful in doing your research, testing it out, or documenting it the design system could fail.