Our tooling gets better every day, but by changing our mindset about how development and design can collaborate and contribute to each other’s work, we’ll deliver a better product to our users.
On a recent website redesign, I was in the middle of a review session with one of Sparkbox’s UI Designers when they commented that the text site-wide looked too small. We pulled the designs up and had a collective moment of realization: we were interpreting the Figma artboards differently. Designs were delivered in four breakpoint views: “small-screen” or “mobile,” “medium” or “tablet”, and two “large-screen” or “desktop” layouts. The development team had been building the site from a “mobile-first” perspective. In other words, our devs assumed each artboard showed the minimum size screen that text size was available. When our designer created the artboards, on the other hand, each artboard represented the maximum size screen a particular text size displayed. Because of this, the website text increased in size an entire breakpoint later than was intended. Development and design each used the tooling in different ways, and the result was a breakdown in collaboration.
Thankfully, this was a timely discovery and we were able to course correct without risk to the project timeline. This incident highlights why it’s important for development and design team members to be able to collaborate well, human-to-human. Maybe it’s time to move away from marking Figma files as “ready for dev” and seeing the design to dev hand-off as the last time design touches a project. We know that there is always going to be a back-and-forth between the two disciplines, so why don’t we codify that as part of the process?
This difference in workflows is why keeping design assets in sync with development assets in design systems can be such a problem.
Where does our tooling fall short?
At Sparkbox, we generally use an Agile/Scrum standard process of two-week sprints representing a set of tasks outlined in Jira tickets. We’ve tried aligning design and dev workflows by adding design team members to the Jira board and assigning them tickets like any developer. This process works well for developers because it reflects the work: discrete chunks of work usually addressing a single issue, which are put up for review, after which any feedback is addressed or the ticket is done and it’s time to move on to the next one. This is antithetical to the design workflow, where the feedback and iteration loop is much faster and less linear. Instead of starting work at the component level, they might design entire pages at once as the design language becomes defined. There might be multiple review cycles with clients and peers and other stakeholders where feedback is implemented either in the moment or presented later as multiple actions. Through all of this, as revisions happen, a designer might go back to a “completed” page and implement any learnings.
This difference in workflows is why keeping design assets in sync with development assets in design systems can be such a problem.
When it comes to the tools we use, Figma has been releasing a number of features that attempt to bridge the gap between design and development. As of the time of this writing, their new “grid auto layout,” which aims to mirror the behavior of CSS Grid, is in open alpha. The addition of Figma variables not only cuts down repetitive work but translates easily to code. While features like these allow designers to understand what can be possible when developers start to build out a website, others, like Dev Mode, seem to aim to cut down on the communication that happens between the two disciplines. I am not saying Dev Mode isn’t helpful. Being able to view used variables and the box model of a given element or component beats having to click around and `OPT`-hovering within the design. It also is a boon for developers who move things around by accident, which is easy to do even if you don’t mean to do it.
But as an exercise, try asking developers on your team how much of the code snippets available through Dev Mode make it to production. My guess is not much. There is also a philosophical argument here about whether or not removing the friction between design and development means that the way designers do their work should be dictated by what is available in the code. Just because constraints are a part of any project, it is important to maintain the distinction between a team that collaborates between disciplines and a design team that is forced to design like developers. The former still allows for creative, design-minded solutions to problems.
Blurring the lines
One way Sparkbox builds in collaboration is by planning for regular design review sessions at key points in a project, like the session I mentioned above. We also try to involve designers and developers in each other’s respective work as often and as early as possible. Our Experience team holds a weekly, company-wide design review session where team members share what they are currently working on, or ask for feedback, or bring up areas where they are blocked. The development team is invited to this meeting; their presence makes it so that our Experience team doesn’t also have to know how to code or have detailed accessibility knowledge. This is a practice that could be implemented on any team.
Bringing in developers can fill in gaps early in the process. They’ll be able to bring up questions that often come up when they go to build the designs: What does the loading state look like? What does the page look like when there aren’t any search results? How should this error message be phrased? Accessibility experts can catch any misses before the code editors are opened. Engineers can prototype animations in the browser or in Codepen, where they will live and ultimately be experienced by the user, instead of doubling that work by having designers prototype animations in Figma ahead of time.
On the other side of the waterfall, it makes sense to keep the designers involved while the product is built. What better place for design decisions to take place than a live environment? Having a designer’s eyes during the development process also allows for informed UX decisions in cases that didn’t come up during initial design. This is not to say that developers are unable to make these decisions, but they might not have all the context that went into the design of a product.
We don’t have to have a “design phase” that is completely the domain of designers and a “development phase” where it is the developers’ sole job to faithfully recreate the designers’ work.
Like we aim for at Sparkbox, we don’t have to have a “design phase” that is completely the domain of designers and a “development phase” where it is the developers’ sole job to faithfully recreate the designers’ work. The distinction between the two disciplines is less important when keeping in mind our ultimate goal.
A unified team
As developers become more familiar with the kinds of questions that designers are asking, and as designers are able to learn more about how the designs come to life in development, it is inevitable that we all start to learn more about how to do each other’s jobs. I am not saying that we have to know how to do each other’s jobs, but I advocate for designers knowing a little bit about the code (and a good place to start would be learning about CSS Flexbox and CSS Grid), and I advocate for developers knowing how to get around in a team’s design tool of choice (here is the beginner tutorial for Figma). But we are not trying to create a team of generalists. Instead, we want a team that better understands the types of problems that each team member is trying to solve.
We want a team that better understands the types of problems that each team member is trying to solve.
It might be fair to say that a designer’s deliverable is a collection of Figma files, and that the developer’s deliverable is a bunch of code. This mindset reinforces the division that creates silos in an organization. What is more accurate to consider is that the final product of a web team is the web product. Whether that’s a web app, a documentation site, or an eCommerce store, what the end user interacts with is the culmination of design and development decisions.
Even 1% is better than 0%
You might be thinking of some limitations that would prevent your organization from doing away with two distinct design and development phases in your project lifecycles. The size of your organization might mean that restructuring teams could be a massive undertaking. At a smaller agency, your designers may already be working on multiple projects and might not have the time to devote to revisiting previous work.
There may be any number of limitations that would make it difficult to fully integrate design with development, but like accessibility, it doesn’t have to be an all-or-nothing game. Maybe your organization can try what we’re doing here at Sparkbox, and start with a regular design review session with an invitation extended to engineers. Whatever your solution looks like, taking that first step to opening up the silos between design and development is an investment that will pay off in teams that trust in each others’ work.
