Vapor/Redwood
c. 2018–2020
--
Context
In 2018, I joined the Oracle Data Cloud design team as a fully remote employee. With working remotely comes the importance of being intentional about communication, and being on the same wavelength as your teammates.
When I noticed that the design and engineering languages didn’t communicate well with each other, I looked a little deeper at what could be causing this divide.
Introduction
As a part of my onboarding was the learning of style guides, and the way the design team approached a new project. While doing this, I found that the design team did not have one single source of truth as far as style guidelines, and certainly not a design system to build new projects with cohesively across different products and team members.
Once I learned this, I looked at what the engineers has to lead on as far as documentation and components when building new interfaces. While they had a bit more to draw from, there were multiple libraries to reference, and none of them matched up with any of the guides that we as designers had.
A few months after I joined, our first organization-wide hackathon took place. I saw this as an opportunity to spend a handful of focused hours on getting the foundation of a design system in place. Within 24 hours, we had a rough version of a color palette, typography weights and sizes, a handful of icons, and a few components built. The three of us working on the hackathon project made some of these initial decisions by acknowledging what our customers might be familiar with per the current state of our product, and what, if any, guidelines any of our acquisitions had.
The next day, we presented our project with an example mockup of one of our more used experiences, and called the initiative Vapor.
Finding Value
The project was received well, but that doesn’t mean building it became a top priority the next day. We still needed to get buy-in from engineering leadership to begin building the one React library the would help bring cohesion between what design had started dreaming up. We also needed product leadership to give engineering priority to do that work of uniting us all.
Through many conversations, examples of data driven value, and even more hackathons, we began receiving the buy-in we needed to make serious traction.
Businesses typically want to get things done as quickly as possible. When the understanding that spending time up front to build a design system that would enable engineering teams to build more consistent products more efficiently, we were able to use our resources to build the design system over time. Thankfully, implementing a unified design system into our existing product and new features meant providing familiarity to users through different interactions and flows, helping them feel more comfortable in our platform to accomplish their tasks, ultimately leading to their loyalty to using and helping us improve our product.
If We Build It
A design system team began forming, made up of myself as the lead from the design stand point working closely with a lead from the engineering side. To make sure the entire team felt involved in decision making and understood where they could contribute, we started holding weekly meetings discussing new needs for the design system.
From the design side, I designed separate libraries in Sketch that designers could access to build mockups from. When I say separate, I mean we had a different library for colors, typography, icons, spatial scales, and components. This helped optimize the speed of Sketch and capabilities of our machines, since we found that including everything in one library would demand too much computer memory, slowing it down. Keeping them separate also helped me to manage changing or adding to them individually with more ease and organization.
Making progress on this work meant working with engineering in a way we the organization hadn’t seen before. Instead of just handing over an annotated mockup of an interface and having a brief conversation through a Jira ticket, we were working together day in and day out to build a system for design and engineering knew like the back of our hands. Something that helped us ensure we (design) was giving everything engineering needed in order to build components, was a checklist that was born and is continually nourished through intimate conversation together. This checklist, in one example, helps us to make sure we are considering every state of a component, so anything possible in a user experience could be built into the components from the beginning.
Together, we created a Storybook to document each part of the design system, from our mission and values, to every component with knobs for different states.
Migration & Adaption
About a year and a half after started to build Vapor as a library design and engineering referenced to create cohesive interfaces and experiences, allowing us to have implemented these visual and technical changes in much of our product, Oracle proper released their design system called Redwood.
Though we are able to work independently from the rest of the Oracle organizations, it was in all of our best interest to come together and use one, consistent design language. However, Redwood is built on a different tech stack than Vapor, and their components were sized a bit differently. If we were to fully adopt this design system right away, it would take a lot of resources, and mean our interfaces would break due to the difference in sizing structure. To solve this in the interim, before we could fully migrate to this new system, I created a theme on the Vapor Sketch libraries, using visual styling, typography, and icons from Redwood to give us the feeling of other products, while we wouldn’t completely alarm our users by switching everything at once. We felt it was important to work in these kind of periodic phases, and best for our users.
Not long after we began adapting Vapor into Redwood, the entire company switched from Sketch to Figma. This meant not only migrating to a new design system theme, but rebuilding the complete library in a new application, all while learning that application.
So I did just that. I started learning more about building design systems in Figma, since I had only used the software for personal projects outside of work thus far.
I rebuilt our 8px spatial scale, used for annotating mockups and for documentation.
I learned that Figma builds components (what Sketch calls Symbols) in quite a different way. Or at least users have discovered new ways to build in something like states of a component. Figma also has a feature called Auto Layout which enables components to be dynamically sized depending on what is inside of a frame.
Below is an example of our Page Notification Alert and a designer can customize the type of functionality allowed in the alert by turning on or off different options, like the ability to undo an action that prompted the alert, or whether or not an icon can summarize the immediate message being communicated.
Another feature in Figma, is the ability to search any assets inside any connected libraries. This makes dropping an instance of a component very quick and easy, IF a designer can find it easily. After discussing with the designers on the team to gather feedback on how we might search for something like a a button, I decided to take some steps to enable us to find what we’re looking for, and use it as easily as possible. One thing I did was build the states of a button into the layers of the component. This means there is not a component for each state a button could have, for every type and variant a button could be, which are a lot—think a Medium-Sized-Primary-Icon-Button.
In the example below, I’m able to find what I’m looking for by searching first for “Button”, and I can filter it down by adding queries like “Primary” and “Icon” to the search.
Components don’t exist in a silo. Many components, or atoms in Atomic design, are used to make up molecules. In this example, I’m showing how a designer might use different components to build a portion of a form, using a label (with or without an icon), a text input, and assistive text. The options in the layer panel make it easy to then change the state of the input and assistive text, in this case to portray an error state.
Sharing & Usage
With a distributed team in an enterprise company, distributing the design system can be a challenge. Limiting access to VPN’s and file syncing software restricts the ability to sync the design system assets easily with constant updating.
I found that what was most important is communicating with each designer and meeting them with they are with their specific needs of access. For some, this meant syncing using an Oracle desktop file syncing app, similar to Dropbox or Google Drive (which we don’t have access to). For others, this meant using a particular VPN to access a Git repository that those same files were pushed to in order to maintain them. And for a few, it meant providing a ZIP file containing the latest version of the design system from the Git repository.
To help make the process of getting started on a new project for designers easier, and to help encourage cohesion between designers, I developed a series of templates in a starter file. These templates, as shown below, included the four different possible foundational layouts for a page, with the breakpoints we prioritize, and with examples of what an interface might look like using that layout. It also included a blank page for each breakpoint, with a spatial scale layer on top to help guide a designer in laying out components.
Something else we created to help quickly input data relevant to our product, was generic text data files that could be used to populate list, table, or visualization items.
Another piece of the design system puzzle, is documentation. It’s important that designers have a place to reference during onboarding or refreshers that help them understand how to use a specific attribute of the design system. Creating definitions, showing examples, explaining what to do or not to do with an attribute are all pieces of this process.
