Design at Scale: Modern Design Tools
This post is part of an ongoing series about design at scale. Read “Driving Quality and Consistency at Scale” by Ken Skistimas, “Doing Design at Scale” by Lucinda Burtt and “Creating Stable Design Systems at Scale” by Sean Blanton.
The tools that digital and graphic designers use worldwide today have their roots in a system as old as the profession itself: layers. Since the earliest practitioners, and still common today, designers would create their compositions of a page by laying out the different elements — text, shapes, images — freely on a paper canvas. Later, these layers would be committed to the page using rubber cement or some other glue, becoming the first of many in a mass-produced run of printed matter.
Design tools today leverage many of the same paradigms. Compositions, or mockups, are created in a series of stacked layers, each with a position — their distance from the top left corner of a page — and dimensions of width and height. And when it comes to handing over the composition for someone to turn into a website, the design can be “flattened,” committing all the layers to a single surface, much in the same way that traditional print designers would employ their rubber cement.
Over the decades, the media we design for has evolved at an ever-increasing pace. We moved from print design to digital design with the rise of the Internet. The Internet, too, evolved. Smartphones heralded the end of fixed sizes for designs on printed paper or 800x600-pixel screens and ushered in the era of responsive design, which demanded websites that suited screens and devices of all shapes and capabilities.
However, in all this change, design tools stayed…pretty much the same. We still, for the most part, plop text and images onto a page of a fixed size in an almost arbitrary stack of layers before flattening it all in a screenshot and working with a developer (née printer) to bring it to life.
I want to pause here and talk about the web. Now, while the things we can do on the World Wide Web may have changed significantly over the last few decades, the technology that powers it all has quietly stayed (somewhat) the same too. One of the technologies at the core of the web is HTML.
Every website you’ve ever used, from Yahoo to Google to Neopets to MySpace to Facebook, has been powered by HTML. HTML allows authors to structure their document (in this case, a web page) into different semantic sections: paragraphs, headings, forms, links, buttons, groups thereof, and a plethora of other varyingly specific elements. This kind of semantic grouping allows humans and computers to understand the contents of a document and how to navigate it.
Which brings us back to our design tools. Now, through the lens of the specificity and rigor of HTML, our design tools look comparatively crude. Nowadays, we can arrange layers of shapes and text on a page, but these layers have no semantic meaning. We can group elements together, but their groupings are tenuous: designers might forget to group things until very late in the design process, or group unrelated elements together.
We believe that by removing the barriers between different functions on a product team, entire teams can more seamlessly, and more quickly, build amazing experiences that our customers will love.
This means that when the designer works with their developer to build a product from a mockup, the engineer has quite a lot of guesswork to do. It often falls to them to decide whether a text element is a paragraph, a heading, or something entirely different; they have to infer how elements should be grouped together, for the benefit of future engineers or for users who rely on assistive technology to navigate a page via speech or their keyboard.
Lingua franca
At Facebook in general, and certainly on the Ads team, we’re constantly looking for inefficiencies in our processes and finding ways to improve them so that we can tackle bigger, harder problems. This typical design-to-engineering handoff process struck us as inefficient, so we asked ourselves: What would our ideal look like? What would a modern digital design tool do differently if we moved away from traditional print design paradigms and toward the way that products are actually built?
To that end, we’ve begun to develop design tools that provide designers and developers a shared language and new mental models for creating user experiences. One of the principal changes we’ve explored is how designers arrange elements in a layout.
The tools we’re developing leverage real, code-based components — the same ones the developers use to build the product.
We know that people use our Ads tools using a wide variety of devices, so it doesn’t make sense to design for a single screen or using absolute values to determine an element’s position on a page. Instead, we have designers group the elements in their design, and group those groups, to establish relationships between elements that provide the basis for their arrangement. Those groups can provide spacing between elements, rearrange them depending on available space, and even reverse their reading order for languages that are read from right-to-left.
As my colleague Lucinda mentioned in a previous post, the tools we’re developing also leverage real, code-based components — the same ones that the developers would use to build the product. Putting these components in the hands of designers drastically reduces the risk of a design being misinterpreted, prevents developers from needing to build things from scratch, and helps designers better understand the limitations — and virtues — of the materials that are being used to bring their ideas to life.
Designing from the inside out
One way in which a tool like this differs from traditional design tools is that it is highly dependent on relationships between elements. What designers commit to a page is no longer a loose arrangement of rectangles and text, but a group of elements such as form inputs, buttons and paragraphs. The addition of this semantic meaning for the elements designers are using introduces some healthy friction: they have to pause and decide whether they want to use a button or a link, a paragraph or a heading.
Designers must also think about how elements are grouped together. It’s important to encourage meaningful groupings of related elements, as well as meaningful separation of unrelated elements. Encouraging designers to think about the interminglings of these elements at such detailed levels tends to reveal an entirely new way of designing products: from the inside-out.
In many design tools — I’ll use Sketch as an example — you start with an empty, infinite canvas. Right from the offset, this encourages designers to think about their product at a birds-eye level: first, you have to decide the size of the canvas; then, the size of the contents on that canvas; then, the order of contents within those bounds, and so on and so forth, until you finally arrive at something the end-user will experience or interact with.
In our tools, designers use our design system elements, much like someone would use a set of Lego bricks, to compose solutions to our customer’s problems. They build up and out, based on the discrete user problems they’re solving for, to form a cohesive whole.
Designing for reality
Collaboration (or poor collaboration, at least) between design teams and engineering teams is often described as “throwing things over the wall” — when design gets “done,” it’s handed over to engineering to build.
But this paints an incomplete picture. The wall that really matters comes after the one between design and engineering; it exists between the engineering team and the customers.
By designing in the ways outlined in this post — with the real components that are used to build the product, and grouping and isolating elements to give them a single, meaningful purpose — we inch our tools closer to the myriad realities of how our products will be experienced. These advances in our design tooling allow us to emulate and experience the products we’re building in a variety of screen widths, using real data, resulting in an experience almost indistinguishable from how the real, built product will behave.
And because the design leverages the same components that will be used to build the real product, the transition from design to reality becomes even more seamless.
Our goal in the work we do on our design systems and tooling teams is to lower the barriers to building high-quality products quickly, so that teams can ship meaningful changes to customers, and quickly learn what works and what doesn’t.
We believe that by removing the barriers between different functions on a product team, entire teams can more seamlessly, and more quickly, build amazing experiences that our customers will love.
Stay tuned for a future post on some of the other ways we’re removing the barriers between design and engineering groups to focus on designing and building the best products for our customers.
