Company
Joyn Insurance
Year
2023
Type of Work
Design Systems
Platform
Desktop
JOYN is a Managing General Agency (“MGA”) that underwrites commercial insurance in the Small and Middle Markets. I was Joyn’s first product design hire and my job is to oversee Spark, a dynamic Policy Administration System. My responsibilities include user research, requirement gathering, dissecting current processes, drafting designs, prototyping, stakeholder presentations, ticket creation, front-end team management, build testing, bug management, and establishing our design system, Ignite.
This case study aims to touch on all the different aspects of my role in navigating the complexities of Spark. It's important to note that Spark's scope extends far beyond what will be highlighted in this report and is constantly changing.
01
Spark
Spark is Joyn's internal platform that serves as the front end for the policy administration system. The system is used by all underwriters and operation specialists on a daily basis for communication, task management, quote management, financial risk analysis, and policy tracking.
.jpg)
01
The problems
Identity and Scalability Obstacles in the Absence of a Design System
When I joined the company, Spark was built using out-of-the-box components from Google's Material UI - a business decision made to swiftly establish the platform’s MVP. However, I quickly learned that there were inherent challenges with that approach.
Absence of branding: The out-of-the-box components failed to convey Joyn's unique identity.
Intricate Functionality: Complex business requirements forced the team into mixing, matching, and editing components from different systems.
Inconsistency: Without a design system, our components were coded with spontaneous, one-off designs. This lack of structure made maintaining a cohesive visual identity challenging.
Inability to Scale: The absence of a design system meant we couldn't make global changes at the component level. Instead, we had to track down instances individually.
03
Goals
Simplification
Design versatile components that can be easily mixed, matched, and customized to meet complex business needs without compromising consistency.
Visual Consistency
Code all UI components according to a standardized design system to maintain uniformity and avoid spontaneous, one-off designs.
Enable Scalability
Build a design system that allows for efficient global updates at the component level, eliminating the need to track down individual instances.
Test & Iterate
Integrate components into Spark’s Test Environment, identify potential flaws, and iterate designs with engineers for minimal user disruption.
Documentation
Maintain comprehensive documentation detailing component properties and usage to ensure consistency.
Brand Identity
Develop a design system that clearly conveys Joyn's identity through consistent colors, fonts, and visual styles,
04
Process
I developed a comprehensive design system for Spark by setting styles, conducting research, inventorying and developing components, sandboxing, iterating, and documenting.
Set Styles
Instead of relying on preset colors from the Material UI Figma kit, I curated the style guide, taking inventory of essential UI system colors and introduced additional brand colors, along with defining basic shadows, gradients, and fonts.
Research
Recognizing the extensive functionalities required by Spark, I conducted research on popular design systems like Ant Design, Material Design, Polaris, and Atlassian's system to inspire how Ignite should be structured. Studying their Figma file structures and component types helped me define the scope of my design system.
Component Inventory
Working closely with the front-end engineering team, I conducted a thorough inventory of existing components in our application. Components were categorized as potential additions to our design system only if they recurred at least three times in the application, ensuring relevance and efficiency.
Sandbox Testing
I established the use of Storybook in our development process. With that, I was able to isolate and rigorously test each component in a controlled environment. This streamlined approach allowed us to efficiently catch any discrepancy between design and build, ensuring seamless integration into Spark
Iteration
Integrating components into Spark’s Test Environment required a thorough review of their original use cases. This often involved identifying flaws or missing functionalities. We then revisited the component design and cataloged required states or variations. Through close collaboration with engineers, components were reiterated and reintegrated into the application, ensuring minimal disruption to users and seamless functionality.
Documentation
In Figma, the Ignite Design System is documented with detailed component properties and specific usage guidelines. This way, we can ensure that any instance the component is used in the application is accounted for and also helps us identify usage patterns in the future as the design system evolves.
05
Final Designs
Explore some of my favorite spark workflows and design components through static images.
06
Reflection
Designing at the Atomic Level: A Crucial Principle from Day One:
While some may argue that prioritizing the creation of a design system in the early stages of a startup isn’t essential, I strongly believe that investing resources into the product yields faster payoffs, especially in a fast-paced startup environment. Building software that constantly evolves and pivots requires the ability to work at the atomic level. This means being able to adapt to quick decisions, implement changes globally, and overall streamlining development when plans changed. Embracing atomic design allows the product team to remain flexible, scrappy, and experimental.
A design system is an ongoing journey, always open to improvement and refinement— a work in progress that continues to evolve.
07
Impact
During my time at Joyn, my design initiatives and involvement in defining the workflow have significantly improved our company's efficiency. These improvements are not solely due to the evolution of the design system. However, the general positive trend strongly indicates good feature development and effective functionality.
In 2022, it took our operations team an average of 1.05 days to get a submission from ‘Submission Received’ to ‘Preparing for Underwriting’. Today, it takes just 0.67 days —36% decrease.
In 2022, it took our operations team an average of 1.20 days to prepare a submission for the Underwriter. Today, it takes just 0.41 days — a 66% decrease.
In 2022, it took our underwriters an average of 2.71 days to quote a submission. Today, it takes just 1.33 days — a 51% decrease.
In 2022, it took our operations team 1.28 days to decline a submission. Today, it takes just 0.73 days — a 43% decrease.