Heya! I’m Dave. I’m a product designer, engineer, PM, and team lead who works at Automattic.

What can Cookbooks Teach Us About Design Systems?

I love to eat (nom nom). 🤗 Cooking is one of my favorite pastimes outside of work.

If I were to break down where I spend my time as it relates to cooking, It would probably look like this:

  • 5% Education – Learning new skills/Expanding my knowledge of food and cooking techniques
  • 5% Discovery – Finding new recipes/Exploration/Experimentation
  • 90% Execution – Cooking dishes that I’m already familiar with

That said, I’ve been cooking for a couple of decades. In that sense have a lot of experience. The percentage breakdown may vary drastically for those just getting into cooking.

Regardless, most cookbooks tend to do a pretty good job of catering to all three of these functions.

Education

Generally towards the beginning of a cookbook you’ll find a section that focuses on education, on how to perform particular skills. Here’s an example from The 4 Hour Chef for how to chop using your knuckle:

Everything on this page is about teaching and education.

Discovery & Execution

The rest of the cookbook (the large majority of pages) are then filled with individual recipes. Here’s another example from The 4 Hour Chef:

If I add some highlights, it’s easier to how each recipe is broken down into two functions:

  1. Discovery in purple
  2. Execution in orange

How does this relate to design systems?

I see a strong connection between how I spend my time cooking and how I spend my time designing/developing. When I’m designing a new feature, typically about 90% of my time is spent executing—or working with pre-existing components that I’m already familiar with. 10% of my time is then split between either education or discovery around new ways to solve a particular problem.

When creating a design system

It may be worth thinking about:

  • Who is the target user of your design system?
    • People who are just getting ramped up?
    • People who understand your principles, process, styles, and components intimately?
    • Or some sort of cross between the two?
  • With that in mind, what percentage of your documentation and your energy is dedicated to:
    • Education
    • Discovery
    • Execution
  • Does that breakout (the % you focus on education, discovery, and execution) match your target user?

Leave a comment