👩🏻🍳 The Pantry
We coined our design system The Pantry! The perfect analogy for putting all the ingredients (components) together in order to serve an irresistible dish (product)
Last updated
Was this helpful?
We coined our design system The Pantry! The perfect analogy for putting all the ingredients (components) together in order to serve an irresistible dish (product)
Last updated
Was this helpful?
📌 In true Pantry fashion, I will take you through the sections whilst referencing the cooking process. Imagine that FSMK is a restaurant and the design system is the pantry of the restaurant.
Ease of finding our ingredients? Knowing what ingredients we have to work with? Easily manage all of our food in one area?
We were very clear that we wanted to embark on the Design system journey so that we could help create consistency amongst all of our various products as well as see improve the designer and developer handoffs/operations by creating our very own design language.
We needed to know some of the popular dishes that were cooked all the time! This is so we remember to include that type of ingredient in the pantry. What are some ingredients that are all-time must-haves! These are the basics that form the base of your dishes - onion, garlic, parsley, etc.
In order to have a very good overview of how to tackle this monster problem, we conducted a product audit of all the products under FSMK’s umbrella. We organized them into specific components and the frequency in which they appeared amongst all of the live screen pages on the product.
After we obtained a very clear overview of the number of inconsistencies that occurred throughout all of our products and where exactly they occurred, we came to an understanding. We have yet to establish a clear direction/voice/style on what our products should look like and this boiled down to very fundamental problems.
There were things like dark vs light mode or the use of rounded edges vs sharp edges or content strategy that differed across products. This was a major finding and insight. We came up with 2 approaches in which we could employ moving forward from the product audit.
Starting with a page/product or
Starting with atomic components
We eventually decided to go with designing page/product-specific pages and work our way from there.
We had not established a clear direction for our design principles and values yet. Therefore, we employed an exploratory approach. To be discovered as we design. Adopting the page-specific approach would mean that at the end of the exercise, we would have a complete flow to showcase. We would be able to better visualize and illustrate the impacts of the design system, convincing upper management that resources should indeed be directed towards the design system for future streamlining and efficiency efforts.
We wanted to make sure that aside from creating consistency across all of our products and improving development efficiencies, we have to improve the overall user experience of each product.
We compiled various different types of designs as mentioned earlier, on the types of edges, colors, sizes, typography etc. How do we begin distilling this and begin with a design that will optimize for all the products?
We were lucky to have had a brand workshop conducted by the marketing and product team in Jakarta at the start of the year to align on how we want to move forward with this initiative and create consistency in the branding material we push out. The language, type of colors used, structure and shapes, etc. That helped inform us on how we wanted to begin our design direction.
The product design team sat down together to discuss what would our first steps be in this case.
Learn through experiments and constant discovery
Our constant experimentation led to countless permutations of the Pantry. I can personally attest to how many rounds of reiteration any one component went through.
One of the mistakes that I made (rookie), was to begin designing based on my own intuition and understanding on what the best practices rather than research the usability and different use cases a component could exist in and what needs to be catered for it.
📌 You should always be prepared to answer:
Why are you re-designing this component? What are your trying to solve?
With this new design, how does it solve the problem? & What proof do you have?
Is this also technically feasible?
Thinking for the Business: Cater for the possibility that this might affect key pages such as our lead generation pages. How could it affect conversion on our most frequently visited pages?
A quick tip: Begin your research by looking at other design systems and what they have implemented and more importantly why
Samantha would relay the business goals and concerns and map that back to how the design system could help. We needed to be in sync with current projects that the company is prioritizing for the quarter and other quarters to come.
I took on the role of the actual experimentation and setting up of the design system on Figma. The product team worked very closely with the engineering team Stuart to ensure that we were on the right track.
Stuart acted as the gatekeeper for all the new components that were coming into the pantry. He ensured that all of the components we were trying to establish in the new design system were fault-proof.
Therefore, there were tons of back and forth between the product team, myself as well as Stuart on how we can make the system more efficient and ensure that we were designing for the best usability at all times.
This back and forth resulted in a strong understanding of the impact of our design on development efficiency as well as how they functioned on the web itself. This was also the start of establishing our design language with our engineering team as well as creating a deeper and better understanding of what are some of the considerations we should have thought of when designing certain components.
The success of your design system largely depends on how robust and well thought out your components are. This requires you to work very closely together with the engineering team to ensure that you understand very clearly how the component is being built, types of content the component can cater for, instances in which this component could be rendered useless as well as how this component would behave at different states and on different screen sizes.
My personal struggle:
In the beginning, as we took an exploratory approach, it was hard to imagine how what we were doing might feed into the final design. This is also largely due to my learning style and capabilities. I very much am a global learner and what that means is, it is important for me to grasp the big picture before being able to delve into the micro. On a personal level, it was very challenging.
We often discussed and brought up 1000 different ideas on the “could be’s” of this design system. These were both hopeful but overwhelming to deal with at times. Because of the magnitude of possible routes, we could take. We were all filled with so much hope on what this design system can be and should be.
But anyway, we began our conquest! ⚔️
We first adopted the previous design system and worked our way from there.
Questioning every design decision that we made in order to build a strong and robust pantry. Things that we considered were:
Catering for usability in tech variables
Conducting in-depth research on each component
Thinking about how the designs would behave on different screens
Should we redesign the current system? Does it inform both desktop and mobile functionality?
Based on the branding workshop and the work that we have done so far, does this fit into the ecosystem of things?
Obtaining data of how our users behave, statistics on the usage types (e.g. more than 50% of user are on mobile)
This led us to design mobile-first for our designs. This is apparent from the implementation of the grid on the Pantry
Questioning the status quo of the current tech stack
Example: If there are 3 breakpoints, question if it was necessary to have 3. Sometimes there are best practices, but the most important thing to note about the design system is that most of them are context-specific. If there is another solution that works better for your business, run with it.
However, there were several times when the component would go to the production stage, we discovered that there were things we had not previously considered and that was when we would take it in our stride to solve the unanswered questions. Questions are always welcomed! The more the merrier even if they might end up exposing a million gaps in your design. That is just how we get better 🦾
Moving forward, what I would have done differently would have been to document a more detailed step-by-step checklist like the one detailed below, on what I need to think of before moving on.
