Crafting a flexible design system under ambiguous and shifting objectives
Project Type: Design system creation and maintenance
Role: UX Designer
Project Length: approx. 2 weeks
Methods: Component audit, wireframing, brand strategy, roadmapping
Tools: Sketch, Zeplin, Figma, Adobe Illustrator
Collaborators: Sr. UX Designer, Brand Supervisor, Lead Strategist, Digital Producer, Sr. Developer, Key Client Stakeholders
Hi-fidelity mockup creation time reduced by 80%
✨
Dev hand-off time reduced by 50%
✨
Hi-fidelity mockup creation time reduced by 80% ✨ Dev hand-off time reduced by 50% ✨
Creating a flexible design system in under two weeks without branding
Seemingly impossible challenges are the bread-and-butter of daily life when working at an agency. This particular instance was no different. With looming deadlines, our campaign artwork and branding in market research, and two websites in need of hand-off in less than 8 weeks, the team was in need of a solution.
That solution was a design system that would eventually reduce hand-off time by 50% and mockup creation time by 80% and allow us to meet the deadlines for both websites.
Why a design system?
Let’s take a look at the benefits of a design system and how they apply to our current challenge:
IMPLEMENTATION: Pre-creating standardized assets that can be easily adjusted in a single place are great for projects with tight deadlines.
FLEXIBILITY: Because we needed to make essentially two brands at once, and both brands needed similar base components, crafting a template-like system that allows for future style adjustment means we will always be able to make changes in a timely fashion.
DEVELOPER FRIENDLY: Maybe one of the most important points being that due to the nature of my company’s hand-off format to third party developers (as well as working with our internal dev team), separating components into an additional file that could be easily attached to Zeplin simplified hand-off and was where much of our time savings came in.
Here’s a short 3.5 minute video that walks through the system at a high level.
Starting with nothing, or how I turned a blank canvas into a usable system in under 2 weeks
For some designers, there is little more intimidating than a blank canvas combined with a looming deadline. Luckily, I thrive in breaking down ambiguity into actionable goals. Let’s start with what we do know:
There will be two different brands using the system at this time (potentially another two in the future, for four total)
Although the two brands have no established style guides or branding, we have a loose manuscript and early wires to inform component creation
Because I have crafted sites for similar brands in the past, I have a pretty good idea of what we need, as well as what dev needs for hand-off
The third-party external dev team has provided some guidelines for breakpoints and malleable components in their existing database
Great, so this isn’t nearly the blank canvas it might appear to be. With these known factors, we can create the MVP that can be expanded once more stylization is available. Not only that, but this early and flexible template will make it easier for other teams and future designers to make adjustments or copy the template for their own brands.
What do we need for MVP?
Based on the wires and past experiences, there’s a few clear standouts necessary for the basic templates, as well as some unique components needed for brand specificity. One of the brands clearly required much more customization, so we focused on building out a system that could meet the larger brands needs. This included:
Placeholders for colors, text styles, iconography, and campaign imagery
Breakpoint grid creation
Documentation and spec creation that aligned with dev and WCAG requirements
Component creation common to basic flexible systems, such as: buttons, interstitial popups, CTAs, navigation, and footer
And some of the unique components that we could start to build based on the wires:
Custom emoji library for a custom interactive emoji cloud
Interactive bumpers
Digital chart graphics
After all of this, we get to the actual building. At long last! (For reference, in real time, this documentation took me about 3-4 hours of communicating with the team to reach a minimum viable product.)
After those initial discussions, I spent the next few days building out the actual system, and as I was finishing up we received feedback from market research so I could begin applying branding and stylization. In total, it took 5 business days to craft the primary system and its two branded subsets, which were then ready for initial hi-fi mockup.
Customizing the template system for brand specificity
One of the primary examples of customizing the system comes in the form of a brand new interactive feature we designed for one of the brands: an emoji cloud. It would be used to help display primary emotions associated with living with a rare disease, as well as create community and empathy. Not only did we need to create custom emoji icons, but we needed to create a robust sizing component that could be easily understood by dev. In early discussions, we landed on three different sizes that would help create the hierarchy we desired.
Another example would be the interactive bumpers used to gather data about each page and the content’s usefulness with a quick activity connected to our analytics account.
Creating the system simplified dev hand-off and reduced time to hand-off by 80%
And because of this up front work, the creation of hi-fidelity mockups was also reduced by 80%, allowing us to meet all of our deadlines without losing quality control. The website launched on time and on budget thanks to the system, which was then used as an example for other teams to replicate and learn from.
What would I do differently in the future?
Given the opportunity, I would start documentation and tokenization earlier in the process. We started with WCAG requirements and this was vital, but not as well communicated due to late documentation and tight timelines. I felt as if we had a lot of touch points with my internal development team but not quite as many with the external third party developers, and I would have liked to bring them in to more discussions as well.
I’d also have loved the chance to further expand the system, track component usage, and assist teams with building their own brand specific versions of the template I created.