• UI Design
• Design Scalable Components
• Documentation (Anatomy, Types, States, Behavior, Interaction)
• Design Specs
• Bug bashing all the way to launch
• Educating product designer partners on how to leverage the new design system

As the need for a mobile application grew to extend Splunk's capabilities and was actively being built, a new design organization was emerging at Splunk looking to refresh the look and feel of a new generation of Splunk products. Cascading the old legacy products visual aesthetics, and in with new.

With that in mind, I was a part of the design systems team at Splunk tasked with designing the first iteration of the Splunk Mobile design system where I built out scalable components, documentation within Figma, design specs, bug bashing, and educating product design partners - teaching them how to leverage the new components.

Previously at Splunk, there was no real design system alignment with the engineering partners working on mobile for both iOS and Android. This project opened the pathway to not just scalable components for designers, but introduced the beginnings of a consistent design language that cross-functional partners were apart of, making the the product development process more ethical and efficient.

Unified. Consistent language & framework that supports intentional divergence, rather than complete uniformity.

Modular. Flexibility to enable teams in building tailored solutions, scalable across form factors & platforms.

Intentional. Clear purpose behind design decisions. Typography, scale, color, and motion create meaning, orientation, and focus.

Inclusive. Ensure people with varying levels of abilities can access our products.

Ethical. Make the right, ethical decisions that are clear and concise for folks to leverage and build upon.

Due to the design system being the first iteration there were 3 core areas we prioritized for maximum impact when it came to folks leveraging our Design System in Figma. Those areas were, design, engineering, and education, and documentation.

Design

We ensured all components and documentation were scalable and available for designers to reference as needed and appropriately distributing the design system to all product areas by default within the newly created Splunk Figma Organization at the time. The core principles of this first iteration for the Splunk Mobile design system for both iOS and Android were stepping stones for what is now the scaled Splunk Mobile design team where the design agency Handsome further evolved the design language of the Splunk Mobile app.

Engineering

The well organized pages within Figma made it easy for engineers to view various aspects of the design system whether it was primitive level elements, components or patterns, all main components, and documentation on states, behavior, accessibility, tokens, and anatomy was available for engineers to dissect throughout the design and hand-off phases.

Education

Ensuring designers had the educational resources via documentation in Figma and on-going workshops to ensure effective use of the system with optional Figma exercise files.

My design process for creating components was focused around ensuring components were scalable so product designers didn't have to spend time tweaking responsiveness on a component or questioning the padding, styles, states, or accessibility. And with that said I broke down the creation of 25+ components ranging from primitive components to patterns.

Once all of the components adhered to the appropriate design spec, we began to document those specs for designers, engineers, and product to reference and provide feedback on it as needed. All of this documentation was hosted alongside the design system components within the Figma file.

Anatomy

An example of documentation breaking down the anatomy of a component. More in-depth insights available upon request.

Types

An example of documenting all the variations of one type of component. This example being menu component variations.

States & Behavior

An example of documenting the states of all button components and the styles (tokens) associated with them.

Usage Guidelines

Usage guidelines crafted based on what products and feature areas the components were used in to ensure coverage of all use-cases and the nuances being expressed in the guidelines for design, engineering, and product to consume. An example of Button guidelines below.

We also provided guidelines on how to use components at the pattern level.

An example of how we documented specs for Buttons answering questions constantly asked by product designers using the design system.

Throughout the creation of this design system there was constant feedback coming from Design Leads and Engineers as they were inspecting the components and documentation. I would say the most collaborative effort was the QA bug bashes that would occur frequently prior to launching Splunk were some of the most educational moments for myself to learn from engineers and how they interpret components and how that translates to them being hands on and implementing the design system via their frameworks of choice. It was also a really cool opportunity to leverage my git knowledge as I created a BitBucket repository and pushed all iconography for engineers to pull from.

As for concrete metrics, I don't have any at my disposal unfortunately or else I would do my best to discuss the impact my design system work had on the product, user engagement, conversion rates, or other valuable metrics. But, one thing I can say is that this first iteration of the design system in Figma was a positive testament to the value the newly formed design system team was to Splunk as we were able to publicly launch it on both iOS and Android platforms within a year.

With the constant collaboration and consistent stand-ups we had, I was always able to implement the feedback and was not afraid to ask questions if I were stuck on something. This being the first product I was a part of that publicly launched has been a great experience and something I constantly look back on in general to analyze and learn from as I've grown as a designer. In terms of adaptability, I found it easy to pivot if there were any urgent changes needed within the design system. With a solid understanding of how tokens permeate throughout a system conceptually as both a designer and front-end developer, it gave me the confidence to make large cascading changes which made everything else seem easy for some reason.