Creating a new language for design and engineering

What makes a winning product isn’t how technically sophisticated it is, or how groundbreaking it is by design. For users, it just has to work.

For a long time, developer handoff was a baton pass that required translating the blueprint of an idea (design) into code. Today, the relationship between designers and engineers is evolving. Screen design is getting more complex. Designers are turning to technical tools that offer more control. And a single primitive can be shared across engineering and design, streamlining designer to developer handoff.

This topic gets designer Payam Rajabi and engineer Andrew McCloud pretty excited. Payam grew up watching his dad (a mechanical engineer). Although trained as a graphic designer, he learned to write code to better understand how his designs would be implemented in the real world.

Andrew started out making graphics, eventually running his own forum communities and slowly getting into web development. When he couldn’t find a way to manage large-scale changes, like re-theming an entire forum, he turned to HTML and templating.

Payam and Andrew recently came together to talk about how design and engineering are evolving, the impact this has on the team, the toolset, and users.

Mapping design to engineering, 1-1

Payam:
The way an engineer works is much closer to the medium than a designer. As a designer, the more I can understand the medium I’m working with, the better solutions I can design.

Andrew:
When I’m programming, I’m still designing, but in a different medium.

There’s a convergence happening: as screen design gets more complex, designers are looking for tools manage the increasing complexity. When crafting a design, they’re doing it by presenting examples. They’re working with a 2D scene and end up breaking the hierarchy of manipulation for rapid prototyping. UI engineers have similar tools but often need to spend more time in the details, like hierarchy (the structure of the code/components in design system). Hierarchy is important as it can impact how a UI can be reused or behaves.

Until designers are embracing the hierarchy of common software patterns, and engineers adopt a more declarative approach to software problems, we won’t see that application. 

Payam:
Primitives are 1-1 pairings that can be shared across engineering and design. But as you start building more complex applications, interactions, and states, it becomes harder to share across frameworks and tools.

Andrew:
Totally. For example, buttons have a wide variety of states. Right now, we’re largely living in two worlds that are similar by design. But there’s nothing connecting those worlds.

In Abstract, Inspect is a translation environment. It’s a place for engineers to extract the data to accurately create a component. It’s a basic dictionary to copy attributes to code environment. Think of it as the single source of truth for an engineer’s design data.

Inspect calls out when layers have changed and gives engineers direct access to the design values they need. And we’re working on improving it, so that there is even more visibility outside of Inspect.

Before Inspect, I’d need to have a Sketch license to access a file. Even if you had Sketch, you’d have to keep clicking on symbols and opening Libraries to get to the really “deep” layers. Now, I can just grab it from Inspect.

Great engineers and designers build toolkits to manipulate code components.

Payam Rajabi | designer, Abstract

Defying the laws of the system in pursuit of speed

Payam:
We talk about the grain of the medium and how designers draw the example and then the engineer will build it. I think that’s partly because design tools don’t have as much functionality to build complex interactive components.

There is a school of thought that says designers should work with code components. If you could compose them together on the screen, you wouldn’t need to translate it into code. It would just be code.

Another school of thought, and the one I’m keen on, is that if you want to innovate, you have to go against the grain and break the rules sometimes. The advantage you have in a design environment is that you can defy the laws of the system, and you can do it much faster, and with fewer restrictions. Both engineers and designers can benefit from this.

We’re trying to build that toolkit. It’s flexible and malleable. Everyone can play with it. It can help us imagine what the real thing could end up becoming.

There’s rapid iteration on one side, and then deviation when it goes into real world environment. This is where design systems are coming into play.

Andrew McCloud | engineer, Abstract

Andrew:
Right now, a lot of us live in two different systems: the design blueprint and the code components with more complexity. You end up designing something and then handing it off to engineering. But the blueprint isn’t as interactive, so you inevitably end up changing things. Because once it’s been built, it’s the first time someone can interact with it.

Designing things up front saves time later because you have something you can interact with earlier in the process. It’s the reason people are pushing for building design systems out of code primitives. It comes naturally, and you’re closer to done. But most tools aren’t made to bridge that divide.

Payam:
I want design tools to continue to move toward a world where designers can manage increasing complexity. But I also think low-fidelity forms of design can remain relevant.

Whether you’re working with the latest front-end framework or a highly sophisticated set of Sketch libraries with Symbols and Shared Styles, you’re always going to be trading off flexibility and malleability for structure and accuracy. It just depends on what you’re trying to accomplish.

A quick, low-fidelity rendition in pen and paper or clickable prototype could help convey 80-90% of an idea that would take hours or days to build with code. Sometimes that is good enough for an early stage concept.

I used to design and write front end code for all of my projects when I was working on a web-only product. Then, our team grew and we brought in iOS and Android developers, and I was still the only designer on the project. It became impossible to do good design work and implement it all flawlessly across multiple platforms.

Any great product today hasn’t been built by one person. Collaborating with people who have different skillsets is essential for turning a big idea into a reality.

Screen design can be anything you want it to be. It’s changing all the time.

Andrew:
We are moving in a direction where we can better express the intent of a design in code. I think we’ll continue to close that gap as more things are designed with intent and code continues to better express the intent.

Payam:
What we build often needs to work for multiple platforms and many different types of people. The platforms are always changing and so are users’ needs. The impact on the user is that they don’t get the sense that a product was built by one person. It looks like it’s been built by different people over a period of time. And that experience can be choppy.

That’s why designers gravitate toward design systems. We’ve gone from handwriting to using a typewriter. The work loses some of its life, but there’s consistency.

Is it a good or a bad thing? It’s just part of the times. I love brick, but drywall is cheaper, faster, and easier to scale.

Maybe we’re in the Industrial Age of software design.