The Clearleft Podcast

This is the Clearleft podcast.

Clearleft is a design agency. We also run events aimed at our fellow designers. One of those events is UX Fest, which we ran online earlier this year. One of the speakers at UX Fest was Tobias Ahlin.

I’m Toby and I work with the design engineering at Github.

Toby’s talk was very much about design, but it also had plenty of juicy insights for front end development.

I’m not sure about you, but many times in my career I’ve been part of outlining a very thoughtful design, at least I thought so, that then collapsed on the finish line. And this is gonna happen for a multitude of reasons, right? It could be that it’s an issue with the budget or the scope or the time, but it could also be it’s just a missing link between design and engineering.

And that could be because the handoff isn’t well-structured enough or it can be that the skills needed to actually execute on the design isn’t just there. And that’s why I also really appreciate like lifting this design engineering role to be an actual responsibility rather than just this gap between two other roles.

So I think you find design engineering then at the intersection between design and front-end development. And I think it’s really exciting that it’s growing to be a more common role in the industry.

I think I first came across the term design engineer in a book published by InVision, the Design Engineering Handbook written by Natalya Shelburne, Kim Williams, Eddie Lou, and Adekunle Oduye.

My name is Adekunle Oduye. I’m a UX engineer based out of Brooklyn, New York.

You might remember that I spoke to Adekunle in a previous episode of the Clearleft podcast, all about prototyping. But we also talked about design engineering or in Adekunle’s case, UX engineering.

And the reason why I use UX engineer, cause I think design engineer means something else in other industries. I think it was like fashion or something like that. So I felt like UX engineer aligns with who I am, because I’m a designer.

I feel like it’s been a big journey for me, cause I was one of those early designers that was a coder, but then, you know, there was a lot of articles saying like, Oh, you can’t do two things at once or are they were calling us front end design or, or what or not.

I was trained as a designer and I kind of picked up these engineering skills along the way. And my process is that like, whatever I do, especially from the engineering perspective is making sure that we have a good experience that it’s accessible, it’s inclusive.

And I think more and more companies are opening up to this. I think Google might have been the first company that had these roles called UX engineers. And I think with the rise of design systems and also how products are getting more complex and we need to kind of evolve our process.

And I think having a UX engineer that could work with designers and understand the language of typography, color, line and spacing, and then jump into the actual engineering side of things and be able to talk about functional programming and APIs and structures is very beneficial because it closes that gap between design and engineering.

And another thing is it’s becoming a place where our products are getting more complex and we need people that, to be able to kind of see the idea from concept to completion.

Here’s Toby again, describing the process at GitHub.

Just to take a step back and look at how Github works and the marketing team more specifically.

Now in Github’s marketing team there’s a lot of overlap between design and implementation as in there’s a lot of technical skill within the design team. And that typically means that for any given page HTML and CSS is typically written by designers. All of it. We don’t use React. We don’t use almost any frameworks at all.

We write vanilla JavaScript and TypeScript, but still, and then we write CSS and Sass, but we mostly just write everything vanilla. It’s a Rails application and we try to keep it very lightweight so that we can move quickly. But also step out of the frameworks if we have any, when we want to, or embrace some just for particular page, but we don’t use React or anything like this.

So that means that we can quickly alter design decisions to align with the problem space that we find ourselves in, which is maybe a fancy way of saying, like, if we designed something and we realized it doesn’t work in the browser, we have the skills and experience in the team to iterate on the design during that process, without involving too many stakeholders and having a ton of meetings about it. We can just iterate on how to express the design and let the design change to be expressed effectively.

And this is to me really where design engineering also comes in and why it’s really exciting because to me, it’s the engineering of visuals mostly. So you work less with logic and more so with performance, like optimising for the web vitals, but also animation and just UX. Anything that could be about the perceived experience of an app or a page.

It sounds to me like Toby and Adekunle might’ve arrived at design engineering from different directions. But that’s the beauty of the role. It’s right there in the name. It’s at the intersection of design and engineering.

I feel like each design engineer or UX engineer is going to be different. So for me, I’m more leaning on the design side. I still can build out components using React and I know frameworks and whatnot, but I feel like there’s a complexity with especially with front end engineering where it’s like, you have to deal with bundling and performance. That’s something that I wouldn’t say I’m an expert in. I know tips and tricks here and there, but I think also in the case of when you’re a UX engineer, design engineer, you become a good collaborator and you become, be able to kind of work with people that have different disciplines.

So like I said, if I’m not an expert in performance and I could definitely work with someone that’s a more performance expert developer. It allows me to kind of not have to focus on that stuff. And I can just focus on making sure that I’m building the right solution.

Or let’s say I’m working with a designer. I could help them take the design and bring them to life. So you can basically have the position be based on your skillset and what you’re passionate about. So I know a lot of UX engineers that are very developer focused, but they have a good sense of the design. And I think it’s good to kind of have these people to have these cross-functional skills because it allows for better collaboration and better collaboration often leads to better products.

The benefit of having design engineers is to make sure that you don’t work in a waterfall, heavy process where you first get the design done, then you get the engineering. So if someone’s working on a wire frame and all right, this is like the general idea of this.

You still figure out, like what are some of the data we need? What are some of the things that might be a problem in the engineering process that we can identify as early as possible in order to kind of come up with a solution for. And I think that’s the kind of the idea where it’s like, you want to make sure those problems you can see in the beginning because you can be more proactive with that.

And I think there’s a quote saying the later you identify a edge case, the more expensive it gets. So I think that’s the idea where you’re just trying to reduce those expenses.

Design engineering really resonates with us at Clearleft. It wasn’t a case of us hearing the term and thinking, we should do that. It was more case of hearing the term and thinking, that’s what we’re doing already.

I probably made a crass joke that, like, you know, coining terms in this industry is probably like what happens a lot, but at the same time, if the glove fits, it’s a good fit, right?

I think design engineering does perfectly encapsulate what we’re trying to achieve with development as we know it at Clearleft and for the future.

That’s Clearleft design director, Jon Aizlewood. He gave an internal presentation about design engineering a little while back. I’m sure he won’t mind if I share some of it with you.

Basically design engineering is an enhanced articulation of our exploratory and collaborative design practice.

So we can do things like setting the scene for design systems. We can provide much more vastly improved usability testing scenarios. We can upskill our clients and we can integrate with them.

And again, you’ve seen this emphasis of with, not for. That’s a real, kind of huge overlap with how we want to just work as an overall consultancy to be honest is working with our clients. We don’t disappear, squirrel away, do something and then say ta-da! We’re highly collaborative. And we tend to not work for our clients, we work with our clients. And the exact same thing applies with our design engineering practice.

It absolutely embodies exactly what we’re trying to achieve at Clearleft.

It’s things like rapid prototyping. Prototyping that literally can take whatever someone like James or Jason are designing and make it into something that people can actually understand and go, ah, because to me, again, like this is my own personal opinion, but if you’re painting pictures of websites, you’re not really designing.

It’s more so when you’re actually creating something you can feel in a medium in which you’re using it. That’s the most important part. And that’s when the penny tends to drop with our clients too. They start to actually see something they can use, they can prototype, they can test with their users.

And that has huge benefits and gains for design, but also for us to help make that project work even faster and better.

I think Trys especially to me embodies this interesting kind of person that sits right in the middle between design and engineering. People who kind of really get the design process. They get the, the nuances, I guess, that are inherent in the messiness, if you will, with design, but they’re also able to kind of articulate that.

To me, it’s like the magic, right? He can articulate those concepts and those ideas into something that’s tangible, usable, and at your fingertips. I think that’s like a genuine superpower.

Well, this guy Trys sounds like who I need to speak to.

Hi, I’m Trys Mudford and I’m a design engineer at Clearleft.

I asked Trys to explain where the role of design engineering came from.

I think as the front end has gotten more complex as we’ve taken business logic from the backend and brought it towards the browser to the client side, through JavaScript frameworks and the like, the front end has gotten a lot more complex and tooling and testing and integration has become like a mainstay part of a, of a front-end developers role.

And I think that has attracted more backend focused system thinking developers to be working on the front end, which can leave quite a big gap between the design and then the realization of that in engineering. A design is realized by an engineer and maybe not in the fidelity, in the semantic qualities that you’d expect from a front end developer.

So I think there is a gulf between a designer and what they’ve envisioned in Figma or in sketch and what comes out the other side. And I think there can also be a gulf the other way, where an engineer can feel that they designer hasn’t provided enough states or direction in the design and they’ve got to do a lot of, a lot of work on that side. So I think that there’s a gulf there.

And then there’s the gulf between the front of the front end and the back of the front end as Brad frost coined. Where as this front-end has got more complex, there has been a split within front-end development itself between those who are more designed focused, working more in HTML and CSS, and those who are more systems or engineering focused working mostly in JavaScript.

And so that’s where another gulf has appeared in the last few years.

I think a design engineer fits into that gulf really nicely and could be a really helpful go between between the two disciplines.

That’s an interesting way of framing it. Earlier I described design engineering as sitting at the intersection of design and engineering. That implies there’s an overlap there, but without explicitly acknowledging the role of design engineering, there is no overlap. Instead, as Triys puts it, there’s a gulf.

I asked Trys to tell me about his journey to becoming a design engineer.

I started in a small agency. We were building WordPress websites and it was taking a design and building that into a fully working website, both the front end and the CMS in the back. And then over time I moved to a product team where I was just working on the front end, but that was a bit of the back of the front end, integrating a product with a backend team.

And then I came to Clearleft where I was working on all manner of projects. And some projects required a lot more integration and a lot of like systems thinking and back of the front end work and others were very much getting the design into the browser in the most accessible performan t and appropriate way and very much front of the front end. And then some projects kind of span between the two. And I realized that I wasn’t really building websites anymore.

I couldn’t say that I was building a full website. I was building the front of the front end or the back of the front end, but there’s a huge spectrum there to build an actual whole website. And then there were projects where I was just building for the browser and projects where I was just building for the engineers.

So creating tools and prototypes that would show how the product should work or how the website should work. But ultimately what I’d created was throwaway and was there purely as like an artifact to, to hand over to someone else to make their life more straightforward and I wasn’t sure what that role was. It didn’t feel like a traditional web developer or front-end developer role.

And it was when I came across the design engineering handbook from InVision and Natalya Shelburne’s excellent chapters in there, particularly there was a paragraph that said “Design engineering is the name for the discipline that finesses the overlap between design and engineering to speed up delivery and idea validation.”

And it goes on to say “From prototyping to production ready code this function fast-tracks design decisions, mitigates risk, and establishes UI code quality. The design engineer’s work establishes the systems, workflows and techniques. That empowers designers and engineers to collaborate most effectively to optimize product development and innovation.”

The penny dropped. That’s exactly what I’ve been doing over the last few years. I just hadn’t had the name for it.

So yeah, that’s the journey that I’ve come on.

So what exactly does a design engineer do?

I think a design engineer is a translator between the visual and the systems thinking and the engineering.

A design engineer’s main role is to be helpful to both the designer and the engineer. To clear a path.

Design engineering in the title doesn’t talk about any hard skills or any specific languages or approaches . It talks about design and engineering, and it’s all about that overlap and that translation between the two mediums from visual to systems. That can come out through all manner of approaches. That could be through prototyping or through writing actual production code.

I’d say the primary language for a design engineer is probably CSS. Given CSS is a bit of a contentious language, but I think that’s because as Natalya Shelburne sort of explores, it’s at this intersection between design and systems and engineering and that’s why it comes under a lot of heat.

Words are another tool. So just discussing and describing and documenting foundations. That’s another tool in the design engineer’s handbook.

And also just using technologies that aren’t necessarily comfortable but are appropriate for the project. So I think a design engineer is happy to learn or to apply their thinking to new technologies or new frameworks or new approaches that will either help the designer or help the engineer realize their role better.

Does this mean that every organization should have some design engineering capability?

If you have a team running from design to front end to development and nothing is falling between the gaps, then it would suggest that you as a team, there’s enough of an overlap between what you’re doing that you probably don’t need a design engineer in there, or you are already doing the role of a design engineer. But it’s in organizations where there is these cracks between disciplines, where the code is thrown over the fence, or the design is thrown over the fence, that’s when it’s handy to have someone to come in and identify that and to help smooth that over and help the designers ensure that what they’ve designed actually gets through to production and help the engineers feel like they’re not being dumped a flat picture that they have to untangle and recreate in code.

Is this really anything new though? Is this just old school front end development by another name?

There is a school of thinking that suggests that the front of the front-end equals design engineering. And I think that writing great HTML, CSS and JavaScript and realizing a design from a UI perspective is definitely a big part of it. But I think the systems thinking part of a design engineer’s role, and helping the engineer out is as much a part of it. So I think there is definitely a place for someone from an engineering perspective to pull back into a design engineering role. And that might be an engineer who’s creating prototypes that are testing API integrations or testing data filtering, or how we can efficiently store or move state around in a system.

So I don’t think it’s necessarily design engineering equals front of the front end or even UI. But I think it’s anyone that is in that gap, that can look back to the design and the UX and the content and the research that’s happened before I look forward to the engineering that’s going to happen and the final deliverable and help finesse that gap and help with that handshake and that overlap that needs to happen.

Trys gave me some nitty gritty details of his design engineering work.

I see it as a role that happens early in a project to establish good practices, to mitigate any risk and to explore ideas early, without committing to something that might not work.

A Figma file is a picture of a website. Figma is incredibly powerful, and there are other tools available, but it’s ultimately a static single-width demonstration of what the designer thinks the website will look like in the end.

But we know that fonts render differently and browsers interpret color differently.

And we know that that websites are viewed on every screen size imaginable. And so the only way to truly know how a design is going to look in a web browser is to put it into a web browser.

I see this as part of a validation of a design before it gets to production, is to get these design foundations, so that’s typography space, grids, color, maybe iconography, all these foundational building blocks of a design, get those into a browser really early, start prototyping with them and seeing how they come together and then adapting them and changing them before we get too far down the line.

By bringing a design engineer earlier into the process and starting alongside the designer, we can check these assumptions really early, put them into a real device and hand them around so that we could create a prototype on the same day that the designer is choosing the fonts and choosing the colors, put that prototype into a browser, hand it around on a tablet and a phone and a laptop, and just see how it renders in reality as it were, and just check those assumptions right at the start.

Because if you get them wrong, it’s a right pain to reverse engineer and change those later on.

Crucially a design engineer is involved in the design process right from the beginning. Instead of handover, there’s collaboration.

One of the things that a design engineer can do very well is establish the groundwork of a design system. Because they can both think in terms of the visual side of things, how we can best display content on the web, what tools we can use visually to demonstrate that.

But also from a systems point of view, how can we manage these components efficiently? How can we compose them together? Bring them up from atoms to molecules, to organisms. How are they going to coexist? And how is the engineer going to actually use that component in production.

So I think a design engineer’s role establishing these foundations could also be a huge part of establishing the foundations of a design system.

The design engineer is there at the beginning to set the tone, the standards, the ground work, and that could be setting up the tooling as it were the dev ops or the design ops to make the system work. And then I think they would tail off handing over to a more long-term maintaining engineering team.

But I think the design engineer can then come back in and take a more consultative view and interview the designers and the engineers and observe how they’re using the systems and start to identify opportunities to improve them over time.

Personally, I’m all in on design engineering. I think the term helps to clarify what we do at Clearleft. Previously, I might’ve said we’re a design agency, but we also do front end development. That can lead to confusion. Clients might expect us to provide full stack development.

But our strength lies in design. We do front end development in order to make sure our design work is honest and real. That’s design engineering.

If, after listening to this, you think your organization would benefit from design engineering expertise, you can get in touch with Clearleftat clearleft.com And, if after listening to this, you think you might be a design engineer, come and work for us. We’re currently looking for a design engineer.

Check out clearleft.com/about/jobs

My thanks to Trys for sharing his thoughts with me. He’s also written a lot about design engineering on his website, trysmudford.com

I highly recommend reading his blog posts there on design engineering.

Thank you for listening.