Developing a design environment
What is a design environment and how can it make a design system easier to use?
Since moving to San Francisco, I’ve done my fair share of job-hopping. I’ve been a communication designer, a product designer and a front-end developer. Each time my role shifted, I was always busy learning new skills but never felt like I was working on problems that I’d actually be good at solving. Fortunately, it all turned out to be great training for the job I have now, which is building out Thread, Credit Karma’s internal design system.
The best part about jumping around, though, was the opportunity to study how different types of organizations approach getting work done. I was particularly fascinated by engineering teams, because in engineering, collaboration is essentially non-optional. If you have 400 engineers writing code, each person’s contributions have to interoperate and engineering organizations go to great lengths to ensure there are as few snags when combining code as possible.
In fact, in most engineering organizations, you spend your whole first day setting up your development environment so you can actually ship code. It’s generally pretty tedious and no one likes doing it, but it’s this thing you do to contribute meaningful work to production. Which got me thinking, what would it look like to make it easier for designers to design for production?
For the purposes of this post, I’m defining a development environment as “The set of processes and programming tools used to create the program or software product.”
Development environment: the set of processes and programming tools used to create the program or software product.
By contrast, a design environment would be “The set of processes and design tools used to design the program or software product.”
Design environment: the set of processes and design tools used to design the program or software product.
Thread, our design system, is successful if the easiest way to design or build UI is also the highest quality. A huge part of that success is closing the gap between what a designer has access to in Sketch and what an engineer has access to in code. Could formalizing the list of design tooling and process requirements help shrink the divide? To find out, I started with a list.
To design properly for production, a Credit Karma designer would need:
- Thread Symbols that behave as closely to their React component counterparts as possible (spacing, typography, etc)
- Access to a color palette that matches our CSS variables
- Access to text styles that match our CSS classes
- Access to layer styles that match our CSS classes
- Access to the up-to-date Thread Sketch library
- A way to test if the correct company font is installed and access to the correct version if the old one is present
From there, it was easy to start identifying possible solutions and I put together a few options that I thought would help.
- Dynamic Button and Anima Auto Layout to align Symbol spacing and padding with React component spacing and padding
- Sketch Palettes for importing colors
- Sketch Style Libraries to pull text styles from the Thread Sketch library
- Sketch Style Libraries to pull border and background styles from the Thread Sketch library
- Abstract for library distribution and version control
- A Sketch file to test the font version and access to the correct font on Google Drive
This last problem was the trickiest. The original font we bought had some line-height issues, causing buttons and badges to look vertically off-center. We worked with the font maker to fix the problem but it was hard for people to easily tell if the font had been actually updated or not. I picked the most obvious elements that would look wrong if the font was incorrect and took screenshots of the difference, then put them on a “✅ Font check” page in the Thread Sketch library file.
I also noted some nice-to-haves, like setting Sketch’s Shift + Arrow nudging to 8px instead of the 10px default to match our 8px padding class scale and installing SketchRunner to speed up Symbol management.
When I finished the proposal of recommendations, I put all of the loose resources into a single folder on Google Drive and prepared a presentation on how the design environment setup process should work.
Note: as with development environments, the problems a design environment aims to solve and the solutions it provides will vary widely from company to company.
Testing the process
The next step was gathering a group of designers together to give the proposal a step-by-step test run, which we did this past February.
It started with a group of 6 volunteers, which grew to 10 by the time the meeting rolled around. I walked everyone through the presentation, the design environment goals and the Thread resource folder on Google Drive, pausing after each step to make sure everyone’s setup was working.
As it turned out, 10 people was way too big of a group and the nitty-gritty nature of the exercise made it easy for participants to get distracted and lose focus. Despite the bumps, I took notes on all the places where people got into trouble and turned the presentation into a guide on our documentation site.
In the guide, I made sure to frame the process as an investment, designed to save time when collaborating with engineering. I also added an estimated “time to complete,” to set expectations that the whole process should only take about 30 minutes from start to finish.
Once the guide was published, I set up a video chat with Pedro, a designer in our LA office, and took additional notes as he went through the guide. Again, I found a lot of things to improve and clarify, then iterated on some of the instructions.
Tradeoffs
Though the project has seen some early success (one of my coworkers told me that setting up a new Sketch file is now “a cheap thrill”), it’s still a work in progress and as always, there are tradeoffs to consider.
Reduced workflow autonomy
One of the biggest changes for our team was taking a group stance on file management by using Abstract to track Sketch file changes. Deciding to use Abstract meant asking everyone to change the way they organized their work, which took some convincing. But we were struggling to effectively track and share work as the team grew, so the context that version control provides was really appealing. Though it cost us a bit of workflow autonomy, it’s been majorly helpful for collaboration, particularly when handing designs off to engineering.
Additional dependencies and software conflicts
Of course, when any new dependencies are added to a toolchain, the risk of software conflict increases. It hasn’t been an significant issue yet, but upgrading to major versions of key software like Sketch can understandably lead to some frustrations. Additionally, new software is less likely to be stable than mature software, both in bugs and longevity. When choosing to incorporate an open source project or startup tool, be aware that there’s a chance that the project won’t be maintained or that the startup will fold.
Mental overhead
The last thing to watch out for is mental overhead. With each new tool and plugin, there are shortcuts and behaviors that users of the design environment need to remember. While I want to reduce the gap between what a designer sees in Sketch and what they see in production as much as possible, too many steps and plugins would defeat the purpose of creating a more streamlined workflow. Since there will always be discrepancies between Sketch’s rendering and browser rendering, Sketch should be treated as a close approximation anyway.
Evaluating tools
In digital product design, the number of tools to choose has never been higher, so how do you actually figure out if introducing a new tool is a good idea? If you decide on replacing an old tool with a new one, how do you convince everyone else on your team?
The three main questions to consider are:
- What problems are you trying to solve with this new tool?
- What new problems might this tool introduce?
- What makes that trade-off worth it?
No tool is perfect and they all come with a cost. If you’re asking a group of people to significantly change the way they work, it’s nice to be upfront about the pros and cons of the change you’re proposing to show you’ve done your due diligence.
However, the nice thing about design tools collectively converging is that all the tools individually get better. When Figma got prototyping, Sketch followed suit. When Abstract introduced version control for Sketch, Figma released version history with comments. Even prototyping tools like Framer and InVision have upped their investment in the design side of tooling. Some companies, like Airbnb and Facebook, are building custom tools on top of these platforms or building entirely new tools altogether.
The nice thing about design tools collectively converging is that all the tools individually get better.
The best thing to do is consider your process holistically and choose tools that bend to the way you want to work, and not the other way around.
Looking ahead
This design environment project is just the beginning. What other best practices can we adapt from related disciplines that have solved problems that design organizations traditionally struggle with? Can any of those practices make design systems easier to use?
Other companies are already starting to do this. Airbnb has created a design linting experiment with the Figma API. Abstract is paving the way for design pull requests that could make maintaining system-level consistency a shared responsibility. And there’s plenty to learn beyond engineering: Shopify’s Polaris design system is setting the bar for cross-functional learning by putting component-level content strategy in their documentation.
Regardless of what tools we’re all using in the next five years, I’m looking forward to seeing how our approach to getting work done evolves over time.
