Engineering & Design: Primitive Problems
The following is a transcription of sorts from a talk I gave at CampJS 2017 in Melbourne Australia.
Hello everyone, my name is Brad. I’m a frontend engineer at Redbubble in Melbourne. I’ve been working with them for close to 2 years now, focusing on the scalability of the product’s UI.
In my role, I’m lucky enough to work closely with designers both in my team and company wide. I say lucky, because as engineers we stand to learn a lot from designers. The inverse is true too and that’s what I’m here to talk about today.
Design and Engineering
Reducing the gap for the benefit of both disciplines
How can we reduce the gap between design and engineering for the benefit of both disciplines
Because there is a gap. It’s not that big, in fact design and engineering are so closely connected it’s sometimes difficult to see. Many of you may not really notice it because it has become an accepted part of the way we do things.
You’ll know it as the frustration you feel as an engineer when the design you’re meant to implement doesn’t explain what to do when the user’s phone is in landscape mode.
You’ll know it as a designer, when you spent hours detailing the colors for active, hover and visited states of a button only to find that they didn’t make it into the release.
You’ll know it as a product owner who moves through an organisation introducing features with different teams and each one looks different to the last.
There’s a language barrier between design and engineering and things get lost in translation. Arguably it’s more of a dialect barrier, our languages sound the same but somehow things just end up looking slightly different.
Now I have some opinions on how we might start to make a change here, but first I want to take a moment to understand why I think things ended up this way.
Chapter 1
The case of the misleading magazine
Since I can remember I’ve been fascinated by web design.
I used to buy this magazine called Web Designer Mag (I know, it’s a little ironic)…but I’d buy it every month without fail. It cost about $100 cos it was from the UK and I lived in South Africa at the time…anyway…I got this magazine and I pored over every page.
I learnt about Photoshop brushes and blend layers, css hover effects and our good old friend Flash.
I just played with it all, mucking around with designs until I thought they looked good. I’d tweak variables and functions until things worked…and slowly my understanding grew.
I started in Flash, as many of us did but ultimately, this stuff became my frontend engineering career on the web.
Eventually I worked my way into handful of agencies and one of the first things I was asked to do was to “cut up a Photoshop design into HTML”.
“How do you even do that?” I thought. You see until then, I’d only made my own things. I’d created banner images or icons for my HTML buttons in Photoshop. I’d designed a UI in flash and made it link off with ActionScript.
This…was different.
“Don’t I get to have a say in the design?”
“What happens when I hover over the button?”
“This is just a picture…”
I had so many questions.
My magazine had tricked me…it’d promised that design and code went hand in hand but here I was slicing a design into chunks and shoving them into table cells.
The design had been produced by one professional and their toolset…and now it was to be implemented by another and his. The barrier was clear and obvious and you may not believe me, but this engineer found himself missing Flash.
Chapter 2
Maybe it wasn’t just a flash in the pan
Now, I know Flash has a bad rep, it went away for a reason. Often the sites were too heavy and over-design had led to problems like mystery-meat menus and “loading spinners for days”.
I can remember being amazed by some truly beautiful flash sites though. Art in motion, if you will, that you could interact with too. It blew my mind.
The thing to remember though, is that to create those sites someone (often one person) had to work in the Flash editor; drawing, animating, layering but also coding.
There wasn’t the same level of disconnect between what it looked like and how it worked.
The two disciplines of design and engineering were delivered in unison and it’s here that I think Flash got it right.
ActionScript code manipulated and mutated the shapes that had been drawn in the editor. These things worked on the same primitives and gave you an incredible amount of control over the final product.
But alas, Flash went away and took ActionScript and symbols with it. We were left with Web 2.0, where the focus wasn’t the surprise and delight factor of Flash sites but rather the more functional aspects we’d previously only experienced in desktop software.
Naturally, web design trended towards the appearance of typical desktop software too. Mercifully, these more complicated (albeit mundane) interfaces demanded that web technologies improve. HTML and CSS standards took a leap with HTML5 and CSS3. The potential of CSS animations and the HTML canvas made me wonder whether it was time for design and code to become one again, and they did. Sort of.
Chapter 3
Canvas…the technology that gamers stole
Whilst Web 2.0 was bringing us Facebook and Wikipedia, another community entirely was forming around the newer capabilities of HTML and CSS like the Canvas.
Motion designers, game developers and the like who’d previously relied on Flash had found a new home and they quickly made themselves comfortable.
These content authors (by and large) were already comfortable sitting on the fence between design and engineering. You kind of have to be in those industries, which is an interesting contrast to our own. Granted, they don’t typically suffer the problems of scale we do because they’re designing just one piece of collateral or just one motion graphic for a video interstitial.
Now, I don’t necessarily think that Canvas is the ideal solution for the types of applications the majority of us build day today but I do sort of feel cheated. Why can’t our designs and code work together in such a nice closed ecosystem, especially when we essentially own that ecosystem within ours.
Maybe they would have, maybe if we’d had more time working closer together on these problems we’d have something more akin to that. Instead the designers and engineers of web applications each faced a series of rapid and unsettling changes that caused them to diverge even further.
Chapter 4
Learn me a UX for great good
So at this point we were designing more complicated applications than had ever been seen on the web before. There was also this thing called an iPhone that had popped up with it’s own skeuomorphic ideas. Kind of all of a sudden people realised that actual humans were on the other end of these web apps.
And so began the age of UX on the web.
Suddenly teams had to have a UX person to lead them, visual designers who’d been happily creating web content now had an additional person to report to.
They also had to get their heads around the ideas of user testing, sentiment analysis, script writing, emotional design, survey building, user research, experience design…the list was endless.
Design assets that had previously been approved on pure visual aesthetic now had to undergo a rigorous evaluation of their inherent user-friendliness.
Now, these processes and skillsets aren’t new. Designers of desktop software and embedded systems, even the iPhone for instance, had already been aware of these things. The web just took a little while to catch up and I think it took the web design world a little by surprise.
Overall as an industry we’ve actually passed this milestone. The UX boom is over. It’s still crucial to the success of our products but it’s become (for the most part) a default consideration in many projects.
But what it did, was it disrupted the web design industry and pulled designers further away from engineering on the functional spectrum of a web product team…towards the marketing and research side of things.
Engineering though, didn’t necessarily even notice this, since they had problems of their own.
Chapter 5
Browsers, screens and screams
Whilst designers spent hours in user testing sessions, faint screams could be heard from the engineering department.
“Why, WHY can’t I use a PNG IE6…why do you hate me?”
Ah yes, browsers. There were many of them and the idea of “evergreen” was a mirage on the horizon.
Almost overnight the iPhone and friends “10xed” that problem by adding their screen sizes to the mix. Ethan Marcote wrote a book on mathematics vaguely disguised as a book about responsive design. Note the word “design” in that title. It’s important, because at least in my experience that book was on more engineers bookshelves than it was designers.
It became fairly common for engineers to receive the same designs they had been receiving all along (although, now much friendlier for our users) and we had to go through the painstakingly difficult task of reverse engineering the mobile experience.
So there we were, writing sprawling amounts of CSS, HTML and jQuery, FINALLY getting it to work on IE6, Firefox and Chrome. Safari too if you were rich enough to own a Mac for testing. Then, you saved your work, committed to Git, cracked your knuckles and settled in to tear it all down for mobile.
We got better at this. We learnt about mobile first design, we inverted our media queries to respond as screens grew instead of shrunk. We contributed to browser standards and ended up with our evergreens. We talked to designers and soon enough we received pictures of both the desktop AND mobile versions of our apps.
Here at the dawn of the semantic web, designers and engineers emerged from the fog of their respective efforts.
We’d reached a point where designs were user friendly and looked good and where engineers could (within reason) code a page that worked on at least 3246 different screen and browser combinations without pulling their hair out.
And so it was, the status quo, which we then just sort of…preserved.
Chapter 6
Agile design system, crouching component
In the lull that followed the explosion of screens and the advent of user experience design, we sort of went into this introspective phase.
Like teenagers hitting their mid-twenties and realising they’re adults, we suddenly felt the responsibility of these applications we’d built on our shoulders.
So, we did some housekeeping.
On the engineering side, our frameworks matured. Spaghetti jQuery was a thing of the past. Backbone gave us just that…enough structure to realise we wanted something like Angular, Ember or Knockout.
Our principles evolved, we learnt more of the architectural patterns that’d served the older software generations.
Functional programming reared it’s head and React and it’s companions convinced many of us that component based architecture is the only way to truly work at scale.
On the design side of things, new tools began to emerge. Tools aimed at wire-framing, prototyping and motion design. Even tools that could export CSS.
Designers began to seek feedback from the team using tools like Invision to share works in progress.
Style-guides grew up and became design systems or languages. Whole methodologies that encompassed everything from brand, voice and tone down to the design and usage guidelines of individual components. Sketch landed on the scene a few years ago revolutionised the way we design with it’s smart symbols.
We fixed things, we improved processes and when the agile methodology swept across our industry we even started working together, side by side on single product features, collaborating in real time.
I began this talk speaking highly of the close working relationship I have with the designers in my team. Slowly this is becoming more common, it’s not quite where it should be I think but that’s ok..it’s a work in progress. In a way the gap is closing, but one important piece of the puzzle remains unsolved.
Chapter 7
A picture is worth -10,000 words
Design and engineering have put so much effort into their respective tools and processes but here’s the problem, and
I’ll let Frank Chimero (a respected freelance designer and co-founder of Abstract) say it for me:
Too much of the design toolset is focused on creating isolated artifacts instead of supporting connected workflows.
The majority of a design job is orchestrating the team, ensuring visual consistency, […] documenting decisions, interpreting feedback, and delivering the work for implementation. When you look at it this way, it becomes clear. We don’t need more visual tools. We need help managing our work and how design relates to the rest of the organization.
~ Frank Chimero
Between designers and the engineers who implement their work, the artifacts he speaks of are (for the most part) pictures.
Pictures of what the application looks like, on desktop, on mobile, on the login screen, when an error happens. Hundreds of pictures documenting all the states of the application.
But here’s the problem: those pictures are worth -10,000 lines of code. They literally represent the demand for engineering work to be done and in most cases they don’t contribute towards that work other than to act as reference material.
It’s here that the language barrier is most obvious. Design speaks in pictures and engineering speaks with coded entities and there’s friction involved in translation. And where there’s friction, there’s loss of fidelity.
All the micro-decisions that the designer made, the particular combination of components, the choice of font size - they may not hold true when they land in the the real world environment of the browser.
We tend to solve this by working with designers at implementation time and whilst that’s commendable and an improvement from our pasts, it’s still additional work to be done.
Now some of you might be thinking that the component model and similar abstractions solve this. If we code components once then those pictures only require a few hundred lines of code not 1000’s. That’s the intention for sure, but for this to work those pictures have to be formed exclusively from existing components or they need to be reduced to wireframes…to act merely as layout suggestions.
Design systems offer a way to ensure that these pictures are built only from a catalogue of supported components, but to me they simply represent a duplication of the work the engineers are already doing in their own component libraries. We’re going in circles.
The cost of maintaining both a design and engineering catalogue is high and the processes are often convoluted.
For instance, how do you know when a component in the design system changes? How do you make sure the coded version is updated? How do you track the inverse: when a coded component is buggy and starts diverging from the standard.
I sat down with a couple of engineers and designers at Redbubble recently to start a new design-focused online space for our React components.
It’s going to explain the motivation behind each component. It’s going to provide guidelines for their usage. It’s going to embed real renders of the real components for engineers to use as a reference.
The thing that stumped us, is what do you put at the top of the page? You’re on the page for the button component, what do you see?
Do you see a flat asset output from Sketch? Do you see a render of the component? Picture or code? Do you see both?
Which one is the real source of truth?
There’s a fundamental issue here and I believe after everything we’ve been through we’re now in the position to fix it.
We need to work on the same primitives, we need to speak the same language and we need to work together to make that happen.
Chapter 8
In which we do something about it
So why now? Why do I think we can succeed now where we’ve failed before?
There’s a few factors:
Vocabulary
Our vocabularies are converging. The component model and Brad Frost’s Atomic design are largely to thank for this but now, more than ever we can speak about individual units of functionality with a common set of terms and that greatly improves the level of empathy we have for the challenges we each face.
Borrowed Practices
Design tools are starting to include functionalities such as: version control, smart symbols for abstraction and plugins for dynamic data wherein you connect data sources to your symbols — which feels a lot like the separation of concerns idiom in programming.
These tools operate almost entirely in the visual artifacts space: version control for pictures if you will. However, it shows that the concepts so familiar to engineering are making their way into the design world and I believe this is an avenue for collaboration.
Proximity
I mentioned this before, but more and more designers and engineers are working together. They have to to ensure the translation process goes smoothly. Now we just need to leverage this proximity to fix our tooling and processes rather than to constantly patch the holes.
Interoperability
With the pervasiveness of JavaScript, we have design tools written in the same language as components being designed in them. We’re literally using a program written in JavaScript to draw pictures of components that will eventually be implemented in JavaScript and yet somehow we can’t close the loop.
Luckily, frontend libraries like React and module systems like Webpack have revolutionised the way we package up our code for maximum transportability.
The end result is that we’re ready for levels of interoperability between design and code that we couldn’t have imagined before. Maybe we can close that loop after all.
The pain of scale
The more ambitious our products become, the harder it gets to keep them consistent. Aside from lengthy QA pipelines, communication becomes the only way to ensure things are kept in sync and as we’ve seen: communication is slow and lossy. Better to save our comms for creative and strategical thinking and leave repetitive tasks to the computer.
Awareness
The last thing is awareness. In order for things to change people need to know there’s a problem and they need to care.
And they do, already.
Prior Work
So not only do people care but some folks are already doing something about it.
React SketchApp is probably the first attempt to truly solve this problem by introducing a common primitive.
It’s come out of Airbnb Design and basically it allows you to render React components directly on to the Sketch canvas. From what I can tell, work is still being done to facilitate the reverse of that, having Sketch’s interface contribute back to the component. This is really exciting stuff.
Now usually in a talk like mine there’d be more examples: “Here’s some amazing stuff to get you all inspired”. But there isn’t, yet.
I’m actually hoping that the lack of work in the space combined with the obvious need for things to improve can motivate us even more. These problems impact us daily, and we have the ability to solve them, potentially even using some of our most familiar day to day technologies.
Which brings me back to …
Awareness
It’s truly the most important thing right now. Things are broken, we have to accept that but I like to take Jon Gold’s point of view on this one:
My fav thing about design being so abjectly broken is that we have lots and lots of fun work to do with smart & inspiring people to fix it
~ Jon Gold
He’s right, all we have to do is work together and fix it. I look forward to a world hopefully not too far from now where the shared primitives problem has already been solved. Where the arguments over whether Vim or Atom is the better editor, now include Sketch in the mix.
I can imagine there might be a new role, a sort of Experience Engineer. One who crafts user experiences through a seamless combination of visuals and logic using tools that cater to the task at hand. There’ll still be designers…still be engineers, it’s always a spectrum. With the friction between design and engineering removed however, we’ll have space and time to focus on even more exciting endeavors and that’s when we’ll really start to see our full potential shine.
Usually stories end with epilogues, but I wanted to really push the idea that this is the beginning. People are talking about this, people are experiencing this whether they know it or not. Now that you know about it, I can’t wait to see what we can do about it, together.
