The Problem
Being a member of the Item Display team over the past few years, I noticed that there we didn't have clear guidelines, rules, or written documentation for how product cards should be used and how they work within our existing design system as a pattern. Even though product cards make up at least 80% of our digital experience, there were no set rules in place regarding what they should look like or how other teams could use them across our digital experience.
Lack of documentation made it difficult for our team to own and maintain a consistent pattern across the experience and it made it difficult for other domain teams to understand which cards were the right ones to use. While this work started as a side of desk project, I was eventually able to get buy in from both product and design leadership on the importance of documentation and the need for standardizing the card pattern across our experience.
Gathering Requirements
Starting out, I mapped out all of the card types we had in our experience today and then worked with my product manager to identify card ownership, stakeholders, and data sources for the collection of features that appear on the cards today.
Defining Terms, Components, Features & Card Types
In order for the documentation to be useful and meaningful to other teams outside of our product team, we needed to break down and define what product cards are, what types of cards live in our digital experience, and what each component does and when & how it shows up on the front end experience.
So I took time to list out every card & component and defined their purpose and behaviors. My PM and I believed that if one day this documentation would be incorporated into our design system -- we had to get specific about what could and could not display on the cards and why and which stakeholders played a role in the individual components.
Below are samples of some of the content included:
Delivery Phase 1
While tools like Figma and Mural were effective planning tools for me in starting to map out this documentation -- as we moved into refining the content, I really wanted the engineers on my team to be able to weigh in and contribute more technical details to common questions our team would often get.
With that said, my product manager and I decided that our first step in getting the documentation refined and published was to move the content I had pulled together into Confluence. This allowed everyone within our product team to be able to contribute or make changes to the documentation prior to its official launch date.
Delivery Phase 2
Once published on Confluence, we did still feel like a version might still need to live in Figma as updates to our current design system were on the horizon. Utilizing Figma would allow the product card components to stay connected to the existing libraries and accept updates to the card component easily which would make maintaining the documentation easier in the future.
Delivery Phase 3 + Beyond
Once the documentation was finalized and published on both Confluence and Figma, we were ready to share our documentation with the wider Customer Experience leadership & organization! My PM and I presented and shared the work in various team and all hands meetings in the Spring of 2024.
These presentations led to conversations with other domain teams and stakeholders regarding how their team could better utilize product cards in their spaces, migrate off of custom builds, and open dialog between engineers regarding additional variations needed for their team's specific use cases.
