As a recent transplant to the UX team at Workfront, I’ve had my share of catching up to do in regards to the product I work on, the people I work with and the design processes in place. Workfront is a work management tool allowing teams to collaborate across departments and focus on tasks at hand, but from what I could tell coming in, it needed help internally collaborating across time zones, departments and individual product teams. Working as a team of 17 UX designers on a product that could use a facelift, unification was one of the least of our team’s worries. When I first came on board the team, the Workfront design system was a single Sketch file with only a handful of design components — we’re talking, less than the bare minimum (color wasn’t even a design system component yet 🙈) — to say there was work to be done, was an understatement.
I decided with some past experience with a design system at a previous company that I’d like to take it upon myself to help bring the Workfront design system to life. With help from several of my teammates on the UX team we started a weekly design system meeting to start talking and collaborating on what we eventually dubbed Phoenix. I hope by documenting a few of my learnings I can help others trying to kickstart a design system at their own company.
1. It’s not going to build itself
As I stated before, when I first joined Workfront the design system that was in process was barely a Sketch file. With several different types of icons, a half baked type-scale and not even a color palette to pull from. I had my hands full, to say the least. I spoke with several individuals across the UX department trying to understand what the current process was for adding or contributing to the design system which I soon realized, there really wasn’t one. There was a valiant effort to get going on a design system, but nobody was owning the effort, therefore it wasn’t going anywhere.
This point may seem like a no-brainer, but if nobody takes ownership of your design system, it’s not going to happen.
I decided to insert myself in the process, things were a little light on the product team I was currently on and I was itching to get my hands dirty with something new and challenging. I put a weekly design system meeting on our team’s calendar and we began the long, slow process of collaborating across time zones on a design system.
2. Everyone has an opinion
In the early days of creating this new design system, we were like headless chickens trying to get to our coop. I took it upon myself to conduct a Parts, Products and People workshop by Nathan Curtis of Eight Shapes. I conducted this workshop to understand the priorities the team had in terms of the design system — it was enlightening and helped create a basic roadmap for Phoenix.
A weekly meeting was also setup to get the team to collaborate. In this meeting I asked designers that were willing to participate to choose a component to own and then present it to the team. I asked that they conduct an audit of that component as it presented in our product today, then to bring ideas or new patterns that we could use for that pattern, if we felt the current pattern was out-of-date or not functioning efficiently for our users.
As you can guess, having 17 UX designers with varying backgrounds and taste, wrangling decisions in was near impossible. Although we were working and collaborating, we were struggling to make decisions and move forward by adding components to the system. Overcoming this hurdle would prove more difficult than initially thought, it would take a few months and a shift in how we created patterns to solve this. We eventually decided to create an official approval process. I was transitioned to a newly formed product team to work on Phoenix and a new initiative, here I would have more freedom and responsibility in terms of the design system.
As I mentioned above, we put an official approval process into place. This process was to have myself or the designer that created the component to submit the design to our VP and UX managers for approval. They have 48 hours to give input or to ask for changes to the design, then the design is handed back to myself or the designer to make updates based on feedback or, if approved, add it to the design system. We initially didn’t have a timeframe defined for approvals, but after several rounds of things falling through the cracks, I suggested we add a timeframe for my sanity and so that I could count on work moving along. After it’s approved and officially put into our design system, I would create a symbol to add to our Sketch Library for consumption. It is also prioritized in our product team’s backlog for the developers to build and to eventually add to our online repository for the org to consume.
3. You have to sell it to everyone
It was an interesting task coming in and setting up a design system with so many designers with different backgrounds. I’ve always been an advocate for consistency and making interfaces easier to create more time for testing, research and validation. What I wasn’t prepared for was that some of the designers were actually against having a single source of truth, even though we were all working on the same product and company. There were varying degrees of what should or shouldn’t be in a design system. One designer preferred having only a high level “guide” of rules to follow, while others wanted to create components for everything we needed.
Finding the balance to please the entire team has still not been solved, but we’re working towards a middle-ground. We want designers to have the freedom to still design and create solutions that are tailored to their problems, but we also want to have a product that is visually consistent with patterns that are consistent through the product. The solution I’ve found the most valuable is using Brad Frost’s atomic design and guiding designers to use the atoms we’ve selected to create user experiences.
Atomic Design by Brad Frost
Learn how to create and maintain digital design systems, allowing your team to roll out higher quality, more consistent…
The rest of the organization
As it stood, the designers were the sole contributors up until the point I was transitioned to my new product team. Now that I had been granted a product manager and a team of developers, it was time to start selling the system to the rest of Workfront. I have set up a monthly meeting for Phoenix status updates. Others in the product organization are invited to this meeting — including VPs, directors and our CTO. In this meeting, I present the components we’ve added to the system during this period and the developers have started to show off the working components and how they function.This is a chance to show off our work, but also to bring leaders into the process so they feel they have a time to give feedback and understand what progress is being made. It’s been a great meeting to get buy-in, create relationships and to understand broader concerns of the Workfront product team.
Some of you may be gritting your teeth reading this last part, yes it is always dangerous territory getting too many cooks in the kitchen, but to be fair I feel the team at Workfront is an easy to work with group that doesn’t feel the need to input their bias to styles. The positives of showing the progress has instilled trust into my team and the progress we’ve made.
4. Designing components is half the battle
If you think that creating a design system is designing components and having them built, then you’re wrong. I naively came into this thinking that same notion, but it is so much more. Doing an audit in a system that’s been around for nearly two decades can be a bigger task where you’re finding new versions of components months after redesigning it. Documenting components is also something that can be difficult, you need to think through every scenario for that component, which in Workfront can be impossible to think through or predict every scenario. Workfront prides itself on being flexible and allowing users to over-customize things, to the point of a UX designers nightmare. This has been a strategic move, but also a hindrance in product growth, something we’re still trying to improve upon — we’re getting there, but undoing a knot takes patience and focus.
Also, as I mentioned above, catering to a team of 17 UX designers, not to mention their developers and product managers, comes with it’s unique issues. One field error might be the right fit for 80% of the designs, but there are always cases that crop-up that prove you’re not done with this component.
In addition to not catching all use-cases, there comes the development and documentation of these items. I feel I’m in a unique situation as the sole designer (since this writing one other UX designer has been added to my team 🎉) and I feel the progress I’m making is huge, but as I look back, maybe it’s not going as quickly as I would have hoped. I can catch up on components and their designs for first-pass, but developers have their own priorities and keeping the pace of releasing an entire library in a given amount of time (undefined) to please our large product org has proved nearly impossible. My suggestion to you is to ask for help, don’t be too prideful to hand off components to other dev teams to build, other designers to document or just say no.
5. Consumption isn’t as easy as you thought
Wow 😱you just launched v.1 of your design system, pat yourself on the back! Now all your UX designers and developers are on the same page and your product looks SO consistent!
Do you find yourself in design critiques seeing old patterns? Are other designers using a different blue than the blue you carefully selected? Are designers using pills with all-caps bold type, rather than semi-bold sentence case? Are you going crazy?!
I think the hardest thing I’ve encountered is evangelizing our design system. We all know it’s a priority, I literally slack people all day about it, I have several Slack channels setup for feedback, updates and questions, yet I’m still seeing people using the wrong patterns. I first thought maybe this was a problem with different time-zones, but as I dug in, more local-based designers were using wrong components than our remote employees. I sent out surveys asking for feedback and trying to pinpoint where things were falling short.
It mostly came back to how our file was shared. Dropbox was how we were sharing it, I had it privately locked and publically shared as a read-only, but that requires designers to re-download the file each time an update is made, because of how they are using the system. Another problem was designers were losing track of where the file lived, so they’d resort to old files with out-of-date components. Lastly, some designers took issue with certain components, they didn’t think it fit their needs so in the heat-of-the-moment designing they created their own version of a component that suited those needs.
I have recently implemented Sketch Cloud to solve our sharing issue, it seems to be a good intermediary between saving over public Sketch files and not requiring designer’s to re-download a document each time it’s updated. I also make sure to Slack our updates channel each time something is updated or added to our design system — that way designers know in real time that something is new in their library. As for designers taking issue with certain components, I have tried to work closer with each designer when a new component is added to ensure it’s what they need. I haven’t been able to solve the entire problem (there are different tastes and feelings about certain patterns that can’t entirely be solved) but having open communication and justifying why something is the way it is has helped.
So you’re not a copywriter, but you need to document something in your design system? I’ll be the first to admit documentation copy is something I literally have zero interest in, but it’s a very valuable piece of a design system. It can clear up some of the most menial things that could eat up a good 15–30 minutes of your day trying to explain to a designer or a developer. Although initially it wasn’t at the top of my priority list when designing and adding components to Phoenix, reflecting on the past 6 months and the countless conversations I’ve had about padding, hover states and text inputs, I can easily say it’s one of the most valuable pieces of a design system.
Please heed my advice and be sure to document components first-and-foremost. Defining what a component should and shouldn’t do before you even finalize the pattern will probably save you hours, if not days of Slack back-and-forth.
The future of Phoenix
I feel I’ve painted a picture for you of the middle stages of our design system, but I’ll admit, we aren’t finished, nor are we close to finishing. We have an online repository, it’s not completely developed and needs some love, but as a team of 9 trying to build something and wrangling in 20 years of a product and its patterns, we have accomplished a lot.
My next steps with Phoenix are to continue documenting components and designing new patterns. I have a to-do to begin work of designing our repository so that we can hopefully one day share our library with the public and be a learning experience and guide to other companies trying to work backwards into a design system. I also hope to add in time for testing new patterns to validate that they’re the right direction.
To be continued…