Published on | Prototyping: From UX to Front End — Medium Aaron Weyenberg

Spoilers: You don’t need to learn git, and design ≠ code

Sketch’s 43 will change some fundamental aspects of how software breathes live into designs. It’s going to be fun to watch new tools, plugins and workflows take shape. However, some folklore has emerged, including the idea that instead of a human engineer crafting code, designers will now directly produce shippable code.

A recently published article describes it this way:

“Designers can now generate any layout composition in a matter of minutes and clicks. Translating a visual design to CSS/HTML is now a mundane task of the past. The responsibility for all-things-UI is back in the hands of designers.”

The article conveniently summarizes itself with six claims which I’ll visit one by one.

1. Sketch 43 now has an editable file format (the BIG news)

True! Sketch 43 produces a mix of binary and JSON files to describe the pages, artboards and objects therein. Is that big news? Well, in their own Medium post about it, Bohemian BV, the Netherlands based makers of Sketch, had this to say.

“With this release, we’ve introduced a new Sketch file format, which means documents created with Sketch 43 will not be compatible with previous versions.”

And that’s it. You could nearly fit that in one tweet. That does feel too humble, though. An open file format sets the stage for much more robust plugin development as well as a new generation of tools that could potentially produce some usable code from Sketch source (and vice versa). That is significant indeed, and there are some informed and detailed discussions about it that I encourage the curious among us to visit.

2. Sketch 43 levels the playing [field] for a mutual understanding between designers and engineers

It creates the about same amount of mutual understanding we currently see between illustrators and engineers both looking at SVG source (also text files). The fact that Sketch’s file format is open doesn’t therefore mean designers and engineers will merge concepts and vocabularies as a result. Any shared field of understanding in a post Sketch 43 world will be about as it was before.

But we should play it out anyway. Imagine one scenario where a designer changes some symbol properties in Sketch, and a tool notices and understands that change, producing code that updates, say, a CSS build or a React component, then builds and pushes that change to some dev or staging environment. A designer invokes a tool and code comes out like magic. That doesn’t feel like genuine understanding. In fact, I’d argue that it makes them more abstract and removed from one another.

Another scenario might have designers rolling code in order to change a design, and pushing commits to an actual repo. Not likely. More on that in a bit.

Still another could have developers editing Sketch source directly to change some aspect of the design, and checking that code in so the Sketch app can render those changes next time the designer works with it. The article even offers an example of this for us:

“The engineer, who knows that marketing needs a couple more buttons [on a nav bar created by the designer], can add those to all screens in your .sketch file herself.”

Leaving aside the issue of engineering acting on some kind of backchannel information from marketing, this might look something like…

$ git commit -m "Add buttons to nav bar" -m "BTW John in Marketing OK'd it. Thought I would update your Sketch design."

To which the designer might say…

So now that someone updated the Sketch source, it could theoretically serve as the first mover that builds some important front end code.

But is that a good idea? And how was the engineer in this scenario even able to slip in a design change? Because of this claim…

3. Bohemian Coding creates a new design workflow and standard, the design repo (similar to the development repo)

It theoretically could, but empirically won’t. There’s a fair bit to unpack here.

First, a clarification. The article describes a code repository as “the application that runs the software UI.” I don’t know what is meant by that, but I hope this definition is more concrete: A code repository is a collection of files (typically source code for an app or service) that also stores each file’s revision history (version control).

Distributed version control, in simple terms, allows several people to work on a copy of a project’s source code independently of one another, with every file’s entire history, and manage future changes to those files without everything getting screwed up and conflicted.

Now, here’s the root of a simple React project, versioned with git.

Now here’s what a Sketch 43 file looks like under the hood (after you unzip it).

Each have some JSON files and some folders. It all maybe kind of looks the same.

A new “design workflow and standard” should makes things easier and more accessible for everyone at each point in the cycle. This wouldn’t do that, because…

4. Designers have to learn Git (version control). Yup.

No. False. If you wanted to release a product or feature and literally promise it’s failure, then have it diss your user’s habits, preferences, and workflows while at the same time introducing new pain points.

Designers aren’t going to start doing…

$ git checkout design-tweaks

And after an hour of design work…

$ git add .

$ git commit -m “Change global button radius to 4px. Darken primary color by 15%” -m "Also add trendy gradient background on main headlines."

$ git push origin design-tweaks

To http://ift.tt/2p8QbVh
 ! [rejected]  design-tweaks -> design-tweaks (non-fast-forward)
error: failed to push some refs to 'http://ift.tt/2p8QbVh'

Wait what? Who else is in here?

$ git pull --rebase origin design-tweaks

From github.com:hipsterdesigner/hipdesign.git
 * branch  design-tweaks -> FETCH_HEAD
First, rewinding head to replay your work on top of it...
Fast-forwarded design-tweaks to 129a6981e721adc5415b7c2751c0d9ba2d189d6b.

$ git log

commit 129a6981e721adc5415b7c2751c0d9ba2d189d6b
Author: That engineer from earlier<anengineer@somesstartup.com>
Date:   Tue Apr 09 10:32:44 2017 -0400

   Add buttons to nav bar.

   BTW John in Marketing OK'd it. Thought I would update your Sketch design.

?

$ git push origin design-tweaks

Counting objects: 34, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (34/34), done.
Writing objects: 100% (34/34), 688 bytes | 0 bytes/s, done.
Total 34 (delta 0), reused 0 (delta 0)
To git@github.com:hipsterdesigner/hipdesign.git
   129a698..bcb0130  design-tweaks -> design-tweaks

This straw man example doesn’t prove workflows can’t change and improve. But when they do, it won’t be from designers having to learn git. It’ll be from Sketch’s open format leading to more powerful plugins and third party tools to make the day to day collaboration of designers and developers faster while not upending their existing habits. Folks like Gitlab and Anima are already at it.

Speaking of making things easier for designers and developers…

5. Teams can go straight from design into code without mundane frontend development

This is pretty much the central claim being trafficked. I’m going to take this one to mean that a designer creates or updates an object in Sketch, and this object manifests itself as deployable code without the mind and hand of a front-end engineer involved.

Sketch 43 could make possible some interesting platforms. Maybe one that generates Bootstrap or Foundationesqe styles and libraries directly from a designer’s hand— sort of a next gen WISIWYG in some ways. But to classify front end development as an unvarying, tiresome monolith that teams can skip is hyperbolic at minimum.

6. Design IS Code, Code IS Design

There’s truth to it in a metaphorical sense. but Sketch is a tool to express the output of design thought. Code and design are different things that inhabit different zones of effort. Sketch 43 will further remove some pain and inefficiencies of product development cycle, but it won’t necessarily merge those zones.

As we all witness a world shifting towards automation generally, distinctions about what that actually means in context are important, I think. Here, design is still design, and that’s ok.

Further reading…

<a href="http://ift.tt/2lIYHWK">http://ift.tt/2lIYHWK</a>

Sketch 43: A brief tour of fact vs folklore was originally published in Prototyping: From UX to Front End on Medium, where people are continuing the conversation by highlighting and responding to this story.

Sketch 43: A brief tour of fact vs folklore

Cool stuff, every week

More Articles