Princeton University Design System
Design System Architecture
The goal of this project was to build a solid foundation of heuristics and structures to eventually inform and create an intuive, compact design system for the Princeton University community.
Primary Challenge
Unlike many production design systems, Jazz’ intended users were not experienced designers or developers, but academics or administrative staff.
So we needed to make a both a component library and a building structure that enabled inexperienced users to build quickly while adhering to design and accessibility standards.
Design System Architecture
The goal of this project was to build a solid foundation of heuristics and structures to eventually inform and create an intuive, compact design system for the Princeton University community.
Primary Challenge
Unlike many production design systems, Jazz’ intended users were not experienced designers or developers, but academics or administrative staff.
So we needed to make a both a component library and a building structure that enabled inexperienced users to build quickly while adhering to design and accessibility standards.
Problem Definition
The primary beneficiaries of the project were the Web Development Services (WDS) of Princeton and the administrative staff or academics looking for website consults or buildiing services.
WDS was receiving high volumes of design requests and didn’t have enough resources to properly consult incoming requests that often repeated the same questions and demands on website customization.
The design system was meant to provide a guard-railed environment for academics and administrators to build their websites before making a request. In doing so, WDS would have a figma reference for all requests and administrators would only need access to the figma library in order to test website ideas. Reducing friction on both ends of the service process.
Initial work
At the time of joining, a small component library already existed as well as a list of components that needed implementation. After implementing the components, I went on the rename and organize the components by their function and size, documenting the process for our developers for handoff as well.
The primary beneficiaries of the project were the Web Development Services (WDS) of Princeton and the administrative staff or academics looking for website consults or buildiing services.
WDS was receiving high volumes of design requests and didn’t have enough resources to properly consult incoming requests that often repeated the same questions and demands on website customization.
The design system was meant to provide a guard-railed environment for academics and administrators to build their websites before making a request. In doing so, WDS would have a figma reference for all requests and administrators would only need access to the figma library in order to test website ideas. Reducing friction on both ends of the service process.
Initial work
At the time of joining, a small component library already existed as well as a list of components that needed implementation. After implementing the components, I went on the rename and organize the components by their function and size, documenting the process for our developers for handoff as well.
Component simplification
Due to the sheer number of variations and options we wanted to offer the user, our components often ended up being very complex. This meant high costs of maintenance for WDS and difficulty of use for administrators and academics.
As a result, we dedicated cycles to simplifying the structure of these components by nesting higher and lower level components. This exponentially reduces the number of components to maintain as well as the number of options available initially to users.
For example, the button text and icons were components nested within the left and right icon buttons. This meant we could control the icons allowed on each side of the button via the icon components instead of adding 40 new buttons when wanting a new icon supported.
Due to the sheer number of variations and options we wanted to offer the user, our components often ended up being very complex. This meant high costs of maintenance for WDS and difficulty of use for administrators and academics.
As a result, we dedicated cycles to simplifying the structure of these components by nesting higher and lower level components. This exponentially reduces the number of components to maintain as well as the number of options available initially to users.
For example, the button text and icons were components nested within the left and right icon buttons. This meant we could control the icons allowed on each side of the button via the icon components instead of adding 40 new buttons when wanting a new icon supported.
Building process simplification
The final issue to address for our first iteration was reducing the complexity involved with building full prototypes using the component library. This was accomplished by using a container component that takes advantage of Auto-Layout to autoformat components dropped in by the user.
Testing & Validation
We tested the first iteration with the administrators of our school library. First we demo’d the process to them, followed by a guided walkthrough with three individual members to get their feedback.
Following this round of testing, we hired a new part-time student worked to start writing a FAQ and guide wiki while I continued to refine the styling options available for components and build new prefabricated layouts to serve our users.
The final issue to address for our first iteration was reducing the complexity involved with building full prototypes using the component library. This was accomplished by using a container component that takes advantage of Auto-Layout to autoformat components dropped in by the user.
Testing & Validation
We tested the first iteration with the administrators of our school library. First we demo’d the process to them, followed by a guided walkthrough with three individual members to get their feedback.
- This is easy to use, but what if I want to have another component in this container instead of what is offered?
-
Should we write our content into these pages or should we just leave the placeholder text?
- How do we change the colors of these components so that everything stays consistent?
Following this round of testing, we hired a new part-time student worked to start writing a FAQ and guide wiki while I continued to refine the styling options available for components and build new prefabricated layouts to serve our users.
