Deep dive into my process
Process does not always have to be a scary forbidden word. It’s kind of funny because most engineers I have met love process, and most designers, dislike it.
Since design systems are mostly* technical, I like process. Unlike the image though, process isn’t linear, Its more like, two steps forward, one step backward, plus a small pivot…and sometimes just scrapping it all together. Since I work at the epicenter of design and engineering my process generally has two sets of steps. The most important thing at every stage is communication. Whether thats ‘things to come’, ‘things we are doing’ or ‘things we did’, it all should be communicated. Let’s go.
*The way I work
defining the task
Similar to a feature team, design system should have a product requirements doc (PRD). This is where we identify what the problem is and how big it’s going to be and why we should fix it.
Design
What: Is this a component? Pattern? Sticker sheet? Docs? Domain specific? Does this have a code counterpart?
Why: Where is the gap? What purpose will this fulfill? Is this to a initiative?
Engineering
What: Is this a component? API? Documentation?
Why: Where is the gap? What purpose will this fulfill? Is this to a initiative?
You’ll see that the questions are almost the same for both orgs, but the paths to those answers are pretty different.
Research
Possibly unpopular opinion here, but research is very important and sets the stage for a lot of ‘how are we going to do <xyz>’. It’s setting up the architecture figuratively and literally.
Figma vs. Code
Inside the Design org, we use a design tool that can house pretty much anything you could imagine. I’ve see and built docs, redlines, ux guidelines, sticker sheets, template components, you name it. Not everything (probably most things) has a code counterpart.
Here’s an example — Most engineering teams do not have a coded template component for a ‘form’. It’s too variable, heavy on data and not scalable since all forms are different. Can you imagine having a pre-coded form template for EVERY kind of form?? In design and Figma, you can actually build these ready-made form components FOR designers to better streamline their productivity while abiding by the ui and domain guides. This is a great example of a component not being bidirectional.
Identifying whether the task IS in fact a bidirectional component or will only live inside of Figma for the designers is critical.
In the Engineering org, this is where architecture docs can be written with information on what the state of the current state is and the proposed solution and testing sequence. Architecture docs are reviewed with Engineering manager and myself to ensure parity between design and code. I can’t always read a full architecture doc without my head starting to spin, but it does provide valuable insight to the complexities of a component(s) and how those complexities can related to design.
Competitive analysis
Whether its brand new ui or upgrading something already coded, I run competitive analysis inside of production and outside products. I try to keep competitive analysis within the same product cateogry. I wouldn’t always compare a saas product against a video production product unless we had a domain/feature that had a similar function. It’s important from the system side to reduce potential new builds, when and if we have the same thing already in a different domain (unless new build IS that task 😅).
Code competitive analysis is definitely and engineering task, but I tend to run midfield when doing design competitive analysis to make sure that what I’m researching is even code-able. Running code feasibility against the existing framework against the task can have a huge impact on the story points and level of effort to build <xyz>. This generally would equate to an engineering spike to investigate what we have under the hood, and what we can build or what we have to totally rethink.
Build
Building can be daisy chained with research since both inform each other. In the research phase where we investigate the task, that will generally inform how and where something is built.
If it’s a Figma only component/pattern, that narrows down the level of potential complexity since we are taking out a coded counterpart. There are still decisions that need to be made as to how this Figma component will be built. Is this variant heavy? Slot design method? Is it meant to be a template therefore detachable? Where in Figma <xyz> lives. Is it a core component? a pattern? How will designers access <xyz>?
Coded components have a much higher level of complexity. Research and architecure will inform how something would be coded:
Is this a CSS override?
Javascript? How heavy will this be?
A <class>?
A prop we get out of the box from the framework or something new?
Is this garbage legacy code?
…endless code questions…
Additionally, where will this <xyz> live? In my experiences, I have worked with many code repositories and identifying which repo is the best is a large part of the architecture since it will affect import statements = potential breaking changes. Once it's built, PR’s go through code reviews with peers and other architects/guilds. This step helps engineers validate the work and helps give them another set of eyes (usually their direct customer) which gives us insight on how best to build.
Test & Analyze
Design testing
My preferred testing method for Figma is sharing the component with few designers and having them use it either isolated or inside their domain files. I keep a Testing Figma file in a publish spot and have designers test out things like:
Properties/Boolean: Are the properties and booleans easy to use?
Variants: Do they make sense as a user?
Semantics: Do the labels and naming conventions making sense?
Responsive: Is it responding as intended/correctly?
I like to test a component with designers about 1-2 weeks so I can gather enough feedback and make adjustments and re-test. Fun fact: I aways end up finding an area that can be turned into a learning session.
Code testing
Any major ui updates are gated under a feature flag, this ensure that we don’t cause disruption while we are testing. Similar to design testing, we choose a handful of domains to test within staging and report any bugs. With my team we keep a bug report log for these code tests and from that, write bug stories to address in the following sprints. Engineering will reload to staging as many times as necessary to prove out the POC.
educate & distribution
At this stage, the design system team has validated their POC’s and are confident in rolling out. When the rollout happens, I hold office hours for designers for triaging if they’re having trouble paired with Figma documentation in a design blog post. Inside these blog posts are helpful diagrams on the properties panel, the location of the native component and usage guides, which can also be found in our front end internal site.
In code we can release feature flags in segments into production. Code documentation in the internal site repository is distributed in external comms and we hold engineering office hours for bugs. After 100% roll out to prod, we archive the feature flag.