Kalo is creating the future of work, building tools to help freelancers and companies work together. As the first UI Engineering hire, one of my first projects was leading the development of a product UI system.
What's the scope of the problem?
At just over two years old, the main platform codebase was in the midst of rapid growth. New features and patterns were being added weekly with little consideration to the overarching user experience.
Drawing boundaries around UI
We began by drawing up a list of patterns that included low-level components (such as buttons), protected components (components that are key to the product), and brand patterns (typography, color, iconography). This led to a list of around 80 individual components.
Many of the low-level components had single use-case props such as isLegacyLayout, which were specific to a single view. Extracting these components out in to an entirely seperate repo forced us to think of the UI components as a dependency. This made us consider the wider reaching impact that changing a component would have.
As the components were moved out of the core product codebase, we cleaned up their API's (deprecating unused or single-use props), added flowtypes, and added both unit and visual regression tests. As the components were moved out of the core product codebase, they were all taken through these four steps:
- Cleaning up their API's (deprecating unused or single-use props)
- Adding flowtypes
- Add unit tests
- Write stories (examples) for the components to document use-cases.