Creating a system at exactly the right time

Juggle

Design System

As co-founder and designer on the Juggle team, soon after we started developing our POC, it became necessary to formalise our design thoughts.

I was responsible for creating and maintaining foundations, such as colour palettes, typography and iconography, as well as developing the Juggle component kit.

Juggle is a smart, little property management tool. You shouldn't need to be an expert or pay a lot of money to manage your rental property. Stay on top of maintenance, bills and tenants all in one place.

Methodology

As far as possible, I stuck to the Atomic Design methodology. An atom is an item in it’s simplest form, Molecules are more relatively simple combinations of Atoms, and Organisms are more complex arrangements of Molecules and Atoms.

Property management is a two-fold operation. One being monthly (or weekly) in the form of rental bills, the other is more intermittent, in the form of maintenance.

One of the most valuable features of Juggle is the ability to report maintenance issues, and managing these issues with effective communication until they’re resolved.

The solution focused on two parts.

Needs must

Since Juggle was in its infancy, it didn't make sense to have overly complex components, with equally expansive nested variable options. We were still testing, learning and reworking the product on the fly, so we needed to be able to swap out larger "chunks" of design in our working files, rather than having to reconfigure them in a bunch of places across the product.

In general, overly flexible components are more error prone, less self explanatory, and a nightmare to maintain. Especially in a young design system.

With Juggle’s UI is being very card-based, it was more effective to lock in the formatting at the card level, and make blocks of content as interchangeable slots. It meant that when a layout wasn't working, we could adjust the slot component contents only without disturbing or recreating the top level formatting of the card itself - and roll it out across all working files.

The content types are exposed in the instance panel for easy discoverability. It’s easy to see which content options are available.

System file structure

The system was structured with separate foundation files for Typography, Colour Palette, Iconography, Illustrations, and a separate UI Kit file with all components and documentation.

This structure kept the UI Kit uncluttered, with no local styles to maintain in other files. It would also have been easier to split off into platform-specific UI kits if needed, because the foundational files would remain undisturbed.

Back to contents