While working for US Bank as a Product Designer I identified a need for a design library that my UX team could use to fill in the gaps between our company's Shield Design System and our product work. This was not part of my day to day Sprint work and instead I completed it as “side of the desk” work over the span of 8 months give or take. The completion of this work has lead to less down time waiting for files to load, clear files going out to developers leading to less defects, and overall a lot more clarity for every team member due to clear and consistent design files across products.
Role
Product Designer
Work
Side of the desk
8 months
Tools and techniques
Figma
My UX team supported 7 different experiences with a revolving cast of designers as they flexed between different teams or moved on to other roles. Take this and couple it with design files that started their life as Sketch files imported into Figma (a true nightmare) and you end up with some messy and often out of date files. Just for fun, splash in shifting Product priorities and timelines to really see designers scratch their heads as they try to decide if the wireframe they are looking at is accurate to what it is in production or not.
And now for a riddle, if two products share one micro-app (take a contact list as an example) do they also share one design file for the micro-app or do they have two separate design files attempting to show the same thing?
Well we had the latter and it led to a lot of confusion when one designer would make last minute changes in their file, but not let the other designer working on the same micro-app in another file know about the changes. If you’re thinking “Wow why are they working on the same thing in two separate files?” brother... me too!I won’t continue to wax poetic about many of the other issues we faced with our Figma structure. Instead I present them to you in cold hard bullet points.
File size: Coworkers in other countries accessing our files on their networks had trouble with our large file’s load times.- Even coworkers at our offices had issues with large load times (Too many Figma variants being stored in memory)- Non-designers tended to get overwhelmed at navigating through various pages of wireframes
Alignment across products: New team members weren’t able to easily reference existing patterns or content leading to unnecessary variations across products - Experiences shared across products were being duplicated and updated in product silos leading to a constant need to catch up when one team would update the shared experience, but not the other
Lack of clarity: Each of our files were laid out in different ways, meaning if you learned how things were set up in one file, you’d need to relearn that set up in a new file- In progress work lived alongside release ready work, sometimes leading to developers trying to work ahead of design (and then often having rework once designs were finalized)- Sometimes screens needed last minute changes after being released to developers and there was not a good way to note the changes- Designer would do exploratory work in the same file as work released to developers, causing developers to panic when they thought we wanted to rebuild Rome in a day (sorry I know I said I wouldn’t wax on)
All of those problems were things I observed after spending time working on multiple pieces and parts of each product. It was like living with some horrible house guest. Leaving dishes in the sink or taking your wet clothes out of the wash and putting them on top of the dryer. Things that sure you could ignore and keep living with, but you’d be a whole lot happier if you said “okay pack your bags and get out!”
So I laid out a plan to kick the old system out and bring in a new one. I set up a list of the top things I wanted as part of the new system.
I wanted a file that accurately matched what was in production so that product and outside teams could easily understand what our customers were seeing.
I wanted our files to be “lightweight” so team members weren’t waiting around for files to load and they might feel encouraged to explore around the files a bit more since doing so wouldn’t mean 2 minutes of exploration for 18 minutes of waiting for things to load.
Finally I wanted controls in place to limit developers from running with work that wasn’t ready for them yet or designers less familiar with Figma breaking screens that developers or QAs were trying to work off of.
Now with my goals in hand and a few ideas in mind I started out with a few quick low stakes experiments. Setting up components in libraries that were nothing more than gray boxes with random symbols on them and then pulling them into new files, branches, libraries, etc to see if I moved this here then how did it affect this and if did this instead what happened.
Originally I thought my design team might be able to utilize branches more. My plan was that we could have a design file that matched Production and then use a branch to set up all our new design work for that Epic. That branch would then be a library that we would pull just the screens that developers needed for that Epic. That way when the development work was completed we would close off the design work by merging the branch into the rest of the production accurate file and voila the file was now accurate to the current release. But there was one major issue - components. My plan relied on designers being able to have a main component in a branch that they could update while keeping that same main component in the file it was branched from unchanged. Unfortunately for me that wasn’t possible. If I made updates to the main component it made them directly into the original file and not the branch.
I was kind of stumped for a few weeks. The idea that I saw so much promise in fell flat all with one seemingly simple thing. I kicked the can on the idea a few times when I had some spare time, but not being able to update a branch specific component really blew up the whole structure. It was like taking out the second floor of a parking garage. The lowest level was still somewhat standing but the upper floors had pancaked on top of one another leaving me with only covered parking, but no parking deck. Coincidentally a little event was around the corner that really helped get my creative spirits and logical side of my brain kicking again. FigCon.
FigCon 2024 had some great talks and some big changes. A new UI, a dedicated slide deck tool, everyone found out the Dev mode they were using for free now cost money -_-, and maybe not as glamorous and absorbing of limelight was “Variables 2.0”.
With Variables 2.0 came extended talks and focus on how Figma and other teams were using the new variables in their design systems. Which meant I watched and rewatched one particular FigCon talk repeatedly: Design systems and best practices.
I’m the type of person that likes to start fresh rather than build on top of existing. I say “well that sucked” I dust off my hands, if I’m smart that day I take some time to think of what I learned from my attempt and I start over. I won't lie and say “Oh I didn’t throw out all the work I did. Instead I plugged the carburetor in the giga-max capacitor and blam! Everything worked and I saved a bunch of time cause I didn’t burn it all down and start from the studs.” I did start over fresh in a new file, but luckily whatever day I did that I decided to be smart and think through what Figma handles well and what it’s not so strong at. With that in mind I wrote out a new plan.
I have my company's design system. I pull the components I need from it into my team’s library. In that library I customize, but not detach, the design system components into what our team needs. Let's take a text input for example. From the design system it just comes in with generic content “Field name here” and “Placeholder text there”. I take that variant and wrap it in a new component, update that text to something like “Routing number” and then on the component I made I create variants of the Routing number input that my team needs, so error states with specific messages like “You can only type 17 characters.” I do that with all the various Lego pieces we need across our products. I’d say that is a pretty standard thing most teams are doing.
Let me give it to you in a metaphor. The company's design system gives me a generic brand wheel rim. I take that wheel rim and slap whatever tires I need on it. I don’t watch F1, but I know they have dry and wet tires. My design team is the driver. Sometimes they need dry tires. Sometimes they need wet tires.
Now out of F1 and back to Figma where I take that process further. The components I made in that new library are then brought into the various design files, in total we have 5. Where the Lego pieces are put together into the various forms and pages we need (aka the racecar). Typically most teams stop there and then either use the “Mark ready for Dev” feature or have some other system of letting their developers know which screens to work off of (aka it’s race time folks). Instead I dedicate that file for just UX designers, no one else has access and that gives us space to try out ideas, make things messy as we work through it, be able to preview screens with developers or product, but not hand them out just yet(the practice laps).
When the screens are all set up the way we want them we turn them into components of the full page and publish those to the last files in the line. The developer file and the pre-production match file. The developer file only includes the screens they are working on for that Epic. Meaning the file is lightweight and easy to navigate as there are only the needed screens in it and no extra exploratory UX work.
The pre-production file contains all of the screens that are in the experience in one place. As such it’s obviously a larger file with a larger load time, but it’s often necessary to see how all the new work will fit in with the old. The pre-production file will also become the production accurate file when Dev releases the new work and all it takes is renaming the file. No branch merging or manual process of moving files around.
First he was talking about Figma files. Then he was talking about tires and racecars. Forget the cars, they go up to 233 miles per hour and they're long gone down the road. We’re back here at my portfolio.
We have one company design system. We have one library for my UX team where all of our building blocks and templates live. We have 5 UX specific design files, one for each application. We have 3 files for developers, one for each product team, where the shared experiences and product specific experience can easily live together. And we have 3 pre-production files that become the production match file upon each product release.
Overall it’s a lot of files, but if, as all UX designers should do, we think about it from our user’s perspective.
And importantly, coworkers outside of my day to day work can easily see what a product looks like with our production match file and what it will look like in the next release with our pre-production file. Allowing my team to break down any siloing and spend less time fielding questions from coworkers who want to leverage our reusable products.
The system is set up to be modular and flex with the changes that will come with my organization as it positions itself to best help our users. When new components are added to the design system we can accept those changes into the library and because nothing has been detached only wrapped up in a new layer of customization those changes flow like a waterfall into file after file, with a dam in between the files to allow designers to accept changes only when their teams are ready to take on the work. Agilists you can come back now I’m done talking about waterfalls. When new team members join our team they can see where products are currently at and where they’ve come from at each release as there is an archive of all past releases. And finally if I move on from this team there is a guide and a system for the next designer to take up for as long as it helps the team.
We now have production accurate files always available. This is a big win for us as it takes out a lot of guesswork or needing to get a QA to grab screenshots for us of our test environments or production. It allows us to easily provide outside teams accurate files to use in their own files, that if they don’t detach them and accept our library updates continue to be updated as we make changes.
Team members with slower connection speeds are able to access files with just the screens they need. Leading to more working time and ability to stay in a “flow state” rather than waiting for files to load.
Designers have control through Figma publishing when screens are available to other parts of their team. Leading to less chances for developers to start working off of something they shouldn’t be. It also allows less Figma experienced UX and Content Designers to feel comfortable making changes in a file without consequences as the more experienced designers doing the publishing can review work before it goes out and catch any formatting issues or mistakes.
This system is just in use by my direct UX team, but other design teams inside my same business segment have smelled what’s cookin over here and are interested to see how their teams could leverage or build out something similar and I hope to help them with it and ideally expand this across my organization so long as it’s a good fit for each team.