Once we had built our product, things felt quite static.
Of course we could css transitions to buttons and controls, but that would still only make it feel like a website, we wanted our product to feel like a native app with buttery smooth transitions all around.
This was an ambitious goal, we didn't have the time or the resources to meticulously add transitions to every component or flow.
So we built a motion framework that let us programmatically add transitions to the entire system through carefully defined principles. We tokenised easing functions and applied them to specific types of UI interactions, which were then applied to DOM elements.
As I was responsible for the front-end architecture as well in Tessact, the design system was deeply integrated in the way our product was structured.
Components and tokens were translated with the system serving as a single source of truth. We used tools like storybook and framer to build and maintain parity between assets used in the design as well as on the front-end of our products.
This improved the time taken to build and test new features massively. We had a workflow in place to build and review new components before they went into the process and designers were regularly involved in front-end code reviews.
This paradigm improved collaboration between the design and front-end teams and helped think through and make design changes as a systemic level instead of at a feature level.
We used react for all our front-ends and worked to maintain styling and tokens separate from functionality.
We used styled-components to manage styling within a framework that we built. Styles are always managed at the component level with utility components supporting complex layouts.
One of the principles in place was to make sure that we never had any page-specific styling. Layouts were reused within the logic of layout components and made it easier to scale the app to include experiences like custom panel layouts.
Performance metrics were tracked on every commit and we had minimal reliance on third-party libraries. We made sure that not a single line of CSS was getting loaded that was not used for the view that the user was in at that time. Motion was handled by framer-motion and relied on the motion specs to apply consistent performant motion principles across the board preventing unnecessary browser re-draws.