Skip to main content

Like any startup, began small, way back in 2014. A few developers. No teams.


Updating styles? No problem. Change a class, and boom — the whole app is updated.


Eight years later, enter C O M P L E X I T Y ✨🌈


People: When work began on a design system in May 2020, had about 60 members. From the end of 2020 to the time of writing, we exploded from 93 members to 310(!!), working from time zones across the globe. All these people need structure.


Organization: In the latter half of 2021, transitioned to cross-functional teams and adopted Agile methodologies. Lots of scrum teams all working simultaneously is fantastic for a number of reasons. Also, we now have a Design Chapter! By the way, are we going to implement a different Button component in every repository? (If you’re wondering how we handled documentation, you’re in luck.)


Tooling: Started from jQuery and Django. Now we have React, Vue, and Ruby touching frontend across a number of repositories. Styled Components. SASS. Ruby Bootstrap styles all up in my business.


I think you get it. It’s a problem. The days of updating a single class are long gone.


Design Systems and Updates


Creating a design system lays the foundation for future designs, and puts designers in control of the frequent changes of direction that happen in a startup. With modern tools like Figma and Storybook, collaboration between designers and developers is easier than ever, making maintenance less of a chore.


Importantly, a design system gives structure and consistency to a brand. If, however, as the system changes, the codebase is not updated appropriately, it loses effectiveness. With a large number of developers working on an ever increasing codebase, we found ourselves with a hodgepodge of styles across our applications.


Remember that single class that updated the entire app? What if, as the design system changes, we could change one file to update styles across our whole ecosystem? Enter the component library.


What is a component library?


A component library is a repository of customizable, reusable components, with a consistent design approach. Common items include: buttons, cards, menu dropdowns, and tabs.


Reinvent the wheel?


When deciding to use a component library, one can either choose to build the entire thing from scratch, or to extend an existing user interface (UI) library. To reduce development and design cost, chose to build off of the excellent Material UI library by Google.


A robust, customizable, and accessible library of foundational and advanced components, enabling you to build your own design system and develop React applications faster.


Naturally, every decision has its drawbacks. Extending a UI library means accepting the way that they have implemented their API and base styles. There may be painful migrations and version changes that must happen along the way. Maybe the documentation is unclear about best practices.


Material UI is by no means simple. With such a comprehensive UI library, there is an inherent learning curve, and it takes time for developers and designers to adapt. After carefully weighing the pros and cons with the Frontend and Design Chapters, we made the decision to go with Material UI.




Washi is’s component library built on top of Material UI. In Japanese, one meaning of washi is traditional Japanese paper (和紙). In this sense, it’s the medium on which we visually express our content. Written in a different way, washi can also mean “eagle” (鷲). Maybe using it will give you eagle powers.



Washi consists of three packages — components, styles, and shared utils — managed and released via Lerna, a tool for managing JavaScript projects with multiple packages.


Where are we now?



The project repository was created on March 7th, 2021. As you can see, there were spurts of activity throughout the year.


Recently, the frontend team at has actively used Washi in three repositories. Now when our designs change, we can update Washi and see those changes reflected everywhere it is used. While the upfront cost of developing a component library is relatively high, there are a number of positive outcomes:


  • Mid- to long-term maintenance costs will be decreased compared to managing independent components.
  • Design consistency is the basis of brand consistency, which fosters users’ trust.
  • Consistency is key for usability and user experience. Reducing either the amount of time it takes for users to accomplish a task, or the bounce rate of a site, or both, will improve our bottom line.


With each new component and usage, we’re adding more consistency and scalability into the applications at




Washi is still a work in progress. From a conceptual standpoint, the biggest ticket on the docket now is hashing out the workflow -– how we go from identifying a need, to design, to development. After component development, we must also deprecate old components and replace them with their shiny new counterparts.


On the design side, our excellent team is developing the colors and typography, while also creating a dedicated design file for each component to link in Storybook. If you have any favorite Storybook add-ons, please write your suggestions in the comments below 👇


As a Frontend Chapter, we’re working to migrate Material UI from version 4 to version 5. In the near future, we’d like to:


  • Add other JavaScript framework versions to Storybook (Vue, Svelte, who knows?)
  • Create Regression Testing Automation
  • Update Storybook with Design Tokens


Recently, we’ve deployed our Storybook to Firebase to make it easier for non-developers to easily access the most up to date release. Take a look and give us your thoughts here:




While we still have a long road ahead of us, we now have the pieces in place — Design System, Component Library, and an accessible Storybook — that create a strong foundation to build on. As we continue to develop and expand Washi, I’m sure we will encounter new challenges that will push us forward into creating a better solution for designers, developers, and ultimately users at