Project summary
I audited outdated pattern libraries to create and define the new UI & UX rules for Spot On, the period and birth control tracking mobile app. I oversaw and collaborated closely with a peer designer to come up with the solutions that work best across different Planned Parenthood digital products.Vision and Innovation
About Pattern Library
A pattern library is a living and evolving documentation of UI components and their UX rules. It works as a single source of truth and helps muster coherent end-user experiences. Internally it increases efficiency in design, delivery and development processes by reducing design and code redundancy.
Final deliverables
I added a separate page for color and typography so product managers and other stakeholders can easily reference them.
UI components, icons, logos and Illustrations were organized in their own pages so it’s easier to find them.
I created UI components as Variants to list out different states. It allowed designers to swap UIs quickly while designing and building prototypes.
I added anatomy and descriptions for each component to clarify their names and key functions. It helped the internal and external teams to establish the shared understanding of the UI and their UX rules, such as when and where the components were used.
We added URLs for animation and prototypes for quick reference because some interactions are much easier to show than explain in written language.
We made sure all the components meet AA requirements.
Defining Users
We identified 4 different types of internal users and conducted lightweight surveys with them. Our goal was to understand their pain points so that we could build the most helpful pattern libraries. This process gave us confidence in why the pattern library was pivotal for our organization and helped us get buy-ins from the leadership later.
Product designers and researchers (who are also contributors) wanted to:
reduce the time spent in building new design components and prototypes
align the team on the name of UI components and their use cases
be able to update one source component in a pattern library and the changes dispatch to all connected files
Product managers wanted to:
work more independently and efficiently without the help of product designers especially when they write tickets
reduce the risk of miscommunications
see written specs for UI elements
onboard new team members and vendors so the team can work more efficiently
Developers wanted to:
not write redundant codes
quickly get specs for UI elements
be able to quickly understand different variants and when and how they are used
External venders and collaborators wanted to:
gain instant understanding of the productMeeting User Needs
Pepper is built with both the restaurant and the customer in mind. For the user, Pepper delivers a smooth, enjoyable experience, allowing them to explore the menu, learn more about the restaurant, and order food effortlessly. For the restaurant owner, Pepper offers an easy-to-manage CMS, making menu updates quick and straightforward. The responsive design means you never have to worry about how your site looks on different devices—it always shines.
Building Pattern Libraries
Challenges and scope
Although the pattern library will increase our velocity and quality of work, there were a few challenges we faced while moving the project forward.
Resourcing Capacity: Because the pattern library’s benefits are not immediately visible, it was crucial to convince the product managers and leadership to see the value of this work so that we could set aside time to dedicate to it.
Outdated legacy pattern library: While we had existing pattern libraries that were partially built, most of the components were outdated and inaccurate which caused confusion. We had to manually compare the different versions’ components.
Inconsistent patterns across different products: Often our users engage with more than one Planned Parenthood digital products yet some of the products were designed by outside vendors that didn’t have the full understanding of our digital products as a whole. As a result, UI patterns and their experiences were disjointed.
Limited scope: Our final goal was to have written codes for all of the UI elements so the product teams can accelerate the development process. However, our MVP would not involve developers due to the limited resources and time.
Step 1: Plan the big picture
As a first step, the peer designer and I aligned on our goals, principles, timeline and scope. Then we defined the roles and steps, such as how the pattern library should be used and when it should be updated.
Step 2: get buy ins
We communicated with Product managers about our timeline so that they can adjust their product teams’ roadmap.
Step 3: Communications and check ins
We aligned on details such as naming conventions, file structures, examples to be documented, and more. In order to quickly share ongoing decisions and updates, we created a slack channel and scheduled by-weekly Check-ins. Later this check-in meeting became a Demo meeting where we showcased the progress we made.
Step 4: Auditing the old pattern library and components
We dedicated a sprint to audit the existing components on legacy libraries by manually comparing them to the ones on the latest production. We then created a list of components that are not on the legacy pattern library so we could come back and rebuild them. We also flagged any accessibility issues and mismatching UI patterns.
Impact
Once the pattern library was in place, the design team started adding a pattern library link in the development tickets instead of creating new separate design deliverables because a lot of elements and requirements were already defined in the pattern library. This saved time for not only the designers but also Product managers. In addition, it greatly reduced the risk of miscommunication between developers, product managers, QAs and designers. It was a lot more efficient for the designers to manage the files and ensure all the components are up to date because making changes in the pattern library automatically updates all other files that use the components from the pattern library.
Post MVP
We have iterated our process and format of the pattern library multiple times throughout. Due to the nature of the pattern library, the project is still working in progress and evolving every sprint. Once we stop updating the pattern libraries, it will quickly be outdated and less useful. As our next step, we would love to monitor how different types of internal users engage with the pattern library so we can adjust the layout and structure. We’d like to remove less helpful documentation and update the pattern library more efficiently. Ultimately we aim to have developers write the code for each component and consolidate the duplicate lines of code and speed up the build time.
Project summary
I audited outdated pattern libraries to create and define the new UI & UX rules for Spot On, the period and birth control tracking mobile app. I oversaw and collaborated closely with a peer designer to come up with the solutions that work best across different Planned Parenthood digital products.Vision and Innovation
About Pattern Library
A pattern library is a living and evolving documentation of UI components and their UX rules. It works as a single source of truth and helps muster coherent end-user experiences. Internally it increases efficiency in design, delivery and development processes by reducing design and code redundancy.
Final deliverables
I added a separate page for color and typography so product managers and other stakeholders can easily reference them.
UI components, icons, logos and Illustrations were organized in their own pages so it’s easier to find them.
I created UI components as Variants to list out different states. It allowed designers to swap UIs quickly while designing and building prototypes.
I added anatomy and descriptions for each component to clarify their names and key functions. It helped the internal and external teams to establish the shared understanding of the UI and their UX rules, such as when and where the components were used.
We added URLs for animation and prototypes for quick reference because some interactions are much easier to show than explain in written language.
We made sure all the components meet AA requirements.
Defining Users
We identified 4 different types of internal users and conducted lightweight surveys with them. Our goal was to understand their pain points so that we could build the most helpful pattern libraries. This process gave us confidence in why the pattern library was pivotal for our organization and helped us get buy-ins from the leadership later.
Product designers and researchers (who are also contributors) wanted to:
reduce the time spent in building new design components and prototypes
align the team on the name of UI components and their use cases
be able to update one source component in a pattern library and the changes dispatch to all connected files
Product managers wanted to:
work more independently and efficiently without the help of product designers especially when they write tickets
reduce the risk of miscommunications
see written specs for UI elements
onboard new team members and vendors so the team can work more efficiently
Developers wanted to:
not write redundant codes
quickly get specs for UI elements
be able to quickly understand different variants and when and how they are used
External venders and collaborators wanted to:
gain instant understanding of the productMeeting User Needs
Pepper is built with both the restaurant and the customer in mind. For the user, Pepper delivers a smooth, enjoyable experience, allowing them to explore the menu, learn more about the restaurant, and order food effortlessly. For the restaurant owner, Pepper offers an easy-to-manage CMS, making menu updates quick and straightforward. The responsive design means you never have to worry about how your site looks on different devices—it always shines.
Building Pattern Libraries
Challenges and scope
Although the pattern library will increase our velocity and quality of work, there were a few challenges we faced while moving the project forward.
Resourcing Capacity: Because the pattern library’s benefits are not immediately visible, it was crucial to convince the product managers and leadership to see the value of this work so that we could set aside time to dedicate to it.
Outdated legacy pattern library: While we had existing pattern libraries that were partially built, most of the components were outdated and inaccurate which caused confusion. We had to manually compare the different versions’ components.
Inconsistent patterns across different products: Often our users engage with more than one Planned Parenthood digital products yet some of the products were designed by outside vendors that didn’t have the full understanding of our digital products as a whole. As a result, UI patterns and their experiences were disjointed.
Limited scope: Our final goal was to have written codes for all of the UI elements so the product teams can accelerate the development process. However, our MVP would not involve developers due to the limited resources and time.
Step 1: Plan the big picture
As a first step, the peer designer and I aligned on our goals, principles, timeline and scope. Then we defined the roles and steps, such as how the pattern library should be used and when it should be updated.
Step 2: get buy ins
We communicated with Product managers about our timeline so that they can adjust their product teams’ roadmap.
Step 3: Communications and check ins
We aligned on details such as naming conventions, file structures, examples to be documented, and more. In order to quickly share ongoing decisions and updates, we created a slack channel and scheduled by-weekly Check-ins. Later this check-in meeting became a Demo meeting where we showcased the progress we made.
Step 4: Auditing the old pattern library and components
We dedicated a sprint to audit the existing components on legacy libraries by manually comparing them to the ones on the latest production. We then created a list of components that are not on the legacy pattern library so we could come back and rebuild them. We also flagged any accessibility issues and mismatching UI patterns.
Impact
Once the pattern library was in place, the design team started adding a pattern library link in the development tickets instead of creating new separate design deliverables because a lot of elements and requirements were already defined in the pattern library. This saved time for not only the designers but also Product managers. In addition, it greatly reduced the risk of miscommunication between developers, product managers, QAs and designers. It was a lot more efficient for the designers to manage the files and ensure all the components are up to date because making changes in the pattern library automatically updates all other files that use the components from the pattern library.
Post MVP
We have iterated our process and format of the pattern library multiple times throughout. Due to the nature of the pattern library, the project is still working in progress and evolving every sprint. Once we stop updating the pattern libraries, it will quickly be outdated and less useful. As our next step, we would love to monitor how different types of internal users engage with the pattern library so we can adjust the layout and structure. We’d like to remove less helpful documentation and update the pattern library more efficiently. Ultimately we aim to have developers write the code for each component and consolidate the duplicate lines of code and speed up the build time.
