The Dawn of Design Engineering: A New Era of Collaboration

Introduction to Design Engineering

Adekunle Oduye introduces the topic of design engineering, sharing his enthusiasm and the significance of the career combining design and engineering principles. He outlines the talk's structure, covering the definition of design engineering, key roles within the field, principles guiding good practice, and the impact of design engineers on product development.

Personal Journey and Multidisciplinary Roles

Adekunle shares his journey from studying Studio Art and Economics to his various roles in the tech industry, demonstrating the multidisciplinary nature of his career and the blending of design and coding skills.

Challenges and Misconceptions

Discussion on the misconceptions and challenges within companies about the roles of designers and coders, highlighting the limitations often placed on individuals and the importance of multidimensional skills.

Defining Design Engineering

Adekunle defines design engineering as a role that specializes at the intersection of design and code, with an emphasis on the potential range of skills from either domain.

Principles of Design Engineering

Introduction to key principles every design engineer should follow, including value, usability, feasibility, and business viability, to ensure the creation of impactful, sustainable products.

Overcoming Challenges and Expanding Capabilities

Addresses the pitfalls of being a "unicorn" in the field but encourages pushing beyond perceived limits, sharing personal anecdotes and a motivational attitude towards learning and growth.

Starting as a Design Engineer

Advice for beginners on becoming a design engineer, focusing on passionate learning and mastering essential skills one at a time to prevent overwhelm, with reference to Pareto's Rule for efficient learning.

Essential Skills in Design and Development

Breaks down the must-know basics for aspiring designers and developers, emphasizing the importance of foundational knowledge in both domains to support a successful career in design engineering.

Key Advantages of Being a Design Engineer

Explains the broader impact of design engineers on teams and projects, including improving communication, reducing friction, and fostering innovation, especially in the context of advancing technology.

Improving Cross-Functional Communication

Highlights how design engineers serve as bilingual professionals who facilitate better collaboration and understanding between designers and developers, resulting in a more cohesive product development process.

Introduction to Design Engineering

Emphasizes the importance of possessing diverse skills in the development process, advocating for building the right product before focusing on optimizing performance and scalability. Highlights roles such as design technologists and UI/UX engineers, underscoring their significance in rapid prototyping and maintaining product quality.

Innovative Tools and Design Systems

Shares examples of tools created by design engineers, like a Slack plugin for accessing brand colors and Mailchimp's early public design system, to illustrate the practical applications and benefits of design engineering in enhancing workflow and brand consistency.

Integrating Design Engineering in Organizations

Discusses various organizational models for incorporating design engineering—centralized, decentralized, and hybrid—each with its own merits and challenges in promoting effective collaboration and innovation across teams.

The Essence of Curiosity in Design Engineering

Stresses the value of curiosity within design engineering roles, suggesting that a proactive and inquisitive attitude is vital for creating usable and innovative products that meet user needs effectively.

Exploration and the Design Process

Explains how the design process, akin to the scientific method, involves questioning, research, hypothesis, and prototyping. This method helps in navigating the 'fuzzy' initial stages of design towards more defined solutions.

The Importance of Prototyping and Collaboration

Highlights prototyping as a crucial part of the design process for clarifying ideas and facilitating efficient feedback. Advocates for the 'handshake' method where designers and engineers collaborate closely from early stages, rather than following a strict sequential approach.

Prototyping Methods and Best Practices

Outlines different methods of prototyping, from low-fidelity paper prototypes to high-fidelity interactive prototypes, and emphasizes choosing the method that best aligns with the confidence level in the idea being pursued.

Conclusion: Creating Value with Design Engineering

Concludes with key takeaways on fostering an environment where hybrid roles can prosper, understanding the importance of validating ideas through exploration, and prioritizing the creation of valuable, accessible, and scalable products. Mentions resources for further exploration of design engineering.

Publishing Plans Announcement

The speaker mentions plans to publish something early next year and thanks the audience or other speakers.


Yeah, thank you.

I'm super excited to be here, especially talking about design, engineering, which is something that I'm passionate about.

I usually just like to start this talk with, the most common question I get, which is, how to pronounce my name, no it's all good, but yeah, my name is Adekunle Oduye.

If you actually go to my website, there's a, able to like, to see the various pronunciations of my name.

So if you're interested, go check it out.

On the internet, so I'm just known by my first name, last name, super easy.

And then.

Yeah, I want to talk about, what I'm going to be covering.

There's so much to talk about, especially around design engineering, but I just want to give you, the basic foundations.

So the first thing is, I want to explain about what is design engineering and, the specific roles within them.

There's, two key roles, and I just want to go deep, dive deep into that one.

And then the second is more focusing on the principles, since it's technically a new kind of career position.

It's always to have these principles that kind of serve as a guidelines for what makes a good design engineer.

And then finally, I'll talk about more about like how, Design engineers can be a positive impact to the product development process and this is from both a design and engineering perspective.

So if y'all want to download the slides or have them up already, it's the first time ever me doing something like this, so definitely download them and yeah, let's get into it.

I've been in this industry for a decade and like my career journey started.

When I was in college and I didn't know what I wanted to do, so I basically took two majors, Studio Art and Economics, and yeah, those two degrees don't really mix well with each other.

I just picked something that I was interested in and then my mom was like, you need to choose a discipline that you can, feed yourself.

So I selected economics and I still have no clue what I will do with, with my economics degree, but that's he, she, it, and what, when I was, like, starting out, I started mostly in print and my first job, I was like a jack of all trades and I was able to do print design, logo design, brand identity, front end development, back end development, which was interesting because I was an intern and I was like doing all these projects, but, I guess that's what you get when you're an intern making like $5 an hour.

And this is back in 10 years ago, but looking back to all the positions I had in, the past decade, there's a lot.

So I was a web designer, front end developer, product designer, front end engineer, design technologist, UX engineer.

Funny enough that my sister still thinks I'm like a graphic designer and I'm like, yeah, I'm not a graphic designer.

I do way more stuff than that.

But there's like some similarities within these roles.

Some of them are both design and code and also depending on which company you work at, you might be leaning one or the other.

But, the one thing I want to communicate is that a lot of times when you're working in companies, they try to put you in a box.

If you're a designer, they want you to do that 24x7.

If you're a coder, they want you to do that 24x7 too.

I know for me personally, I get very bored if I'm doing the same thing over and over again.

I want to be able to do multiple things.

And I would say that a lot of us, and very few of us, are one dimensional.

So you could be a product designer that's interested in front end, back end code.

You could be a product owner that's interested in UI design.

And I feel like this is a good thing to have, because that makes you the ultimate collaborator, so you're able to kind of work throughout any of the actual streams of work.

So you could work in a design process, maybe you want to do some user research.

And I think this, there's a lot of benefit of having these multidimensional individuals.

But before we get into anything too deep, I want to define what a design engineer is.

I know that like in Australia, you can't really talk, call yourself an engineer, but I think US, we don't have those rules, but I would say like a design engineer is basically someone that specializes in the intersection of design and code.

So this could be a designer who is, able to do front end code.

Or it could be a developer that's like very, has a lot of good skill sets within the design, role.

And since we have a new role, technically, I would like to define like the principles that I feel like every design engineer should have.

And I think it's going to be very valuable, especially when you progress your career and work in different, various companies.

So the first thing is value.

I'm a big believer that, as our roles are like problem solvers and If we're not really solving problems, then we're not really useful.

But the first question you should ask is in whatever I'm doing, whether it's an internal product or an external product, am I bringing value to my customers?

And also, am I solving their problems too?

Because if you're not doing this, then whatever you do is pretty worthless.

Value is probably the top one.

The next is usability.

If I present a product to somebody, can users figure out how to use it in a way that it's very intuitive and whatnot.

This is the second thing and this is why a lot of times when you come up with a solution, you actually want to test it with users to see if it works or not.

Third is feasibility.

So feasibility is where it's like you I want to understand if you're able to build a solution within the time, resource, and technology that's available.

I think we all want to build stuff that's bleeding edge and whatnot, but there are limitations and restrictions, and I think it's important for us to learn those limitations and how to like, when to actually push your boundaries versus like when to build within them.

And the final one is business viability.

We all, we live in a capitalist world, so the idea that you could build a product that's very useful, that's feasible, but also usable.

The problem is that if it's not really supporting the business overall, what tends to happen is that it's not sustainable.

So you really want to understand what are the business goals and how you can align business goals with the user needs.

So that's like the four principles of design engineering.

I do want to talk about like the caveats because there are some like conflicts in being so quote unquote unicorn.

I know for personally, for me, I've, definitely branded myself out multiple times trying to learn new technologies or learn new skills, but I think it's possible and what I've seen especially when I'm talking to younger people that want to get into the industry is that they get told that they can't do it and it's impossible.

And I always say that a lot of times that the people that tell them this are trying to impose their own limitations on to anyone they speak to.

And for me, it was easier because, I'm actually the last of seven.

So I had to basically take orders from nine people in the household and I was a natural rebel.

For me it was like easy when someone said I can't do it, and I'm like, I'm gonna do it anyway.

It actually made me the perfect candidate for this, this role.

So I think it is possible, but to go back to, the opposite side is that it isn't easy and I think there's many ways to approach how to become a design engineer.

And I think with the proper process, you can definitely, make it and be able to be a valuable asset, not only for your company, but especially if you want to do like your own startup in the future, you already have the skill sets already to make that happen.

I want to outline this quote, this is from, a book I co authored called The Design Engineering Book, and one of the authors is Eddie Liu, and he had this quote about, if you're passionate, you can learn anything.

And I'm a big believer of this because usually if you're passionate about something and you might be tired or exhausted and frustrated, that passion is going to carry you to be able to figure out how can I make this happen.

So it's always good to have some sort of passion when you're dealing with, something that's unknown.

Let's say I'm starting today, I want to become a design engineer.

Where should I start?

A lot of times people try to learn everything at once.

I'm a big believer of kind of, choosing the stuff that you must know.

And I think there's a good rule called, Pareto's Rule.

How many people are familiar with this?


For those who don't know, Pareto's Rule is basically, as known as the 80 20 rule.

And it's the idea where it says, 80 percent of the effects come from 20 percent of the causes.

So if you put this in the context of a skill, I would say, 20% of what you learn is probably the 80 percent of what you need.

And I break it down to this, where it's like more visual.

It could be a skill, language, or whatnot, but there's always like the must know versus the nice to know.

And if you learn that key 20%, what ends up happening is that you're good enough and competent enough to be able to progress, farther.

And then over time, you can learn more things.

So if we break this down into design, I feel like there's five things that you should definitely try to master, be good at, in order to be a good designer.

So this is understanding line, color theory, space, shape, and typography.

I think when you learn these two, these five, concepts, you're able to be a graphic designer, or if you want to do web design, and also translate into, if you want to do something around space.

The next thing is more about, must knows around becoming an engineer or developer, and I would say, it revolves around, these five specific, key areas where it's talking about data types, operators, conditionals, functions, and objects.

And you learn that, once you go into, one language, say, JavaScript, and if you want to, learn Go, it's, there's some key, foundation elements that kind of work within both programming languages.

Usually, there's some differences, but you get a good foundation to be able to learn as quickly as possible.

The question is, like, how you should try to, learn this stuff if I'm brand new.

And I always tell people that you should only learn one skill at a time, because usually if you don't, you'll overwhelm yourself.

And a good story that I've recently heard about where, some, someone asked a question is is it possible to be a marine, an astronaut, and a doctor at the same time?

Most often people are thinking about no, you need to go to school for all of that.

But this is a good story, from Johnny Kim.

He was able to, to accomplish all three of these things, and he has like a podcast, an article that kind of goes through like the details of his journey, and the idea is that he didn't set off to be an astronaut right away, he was like, I'm just gonna try to master being a Marine, and after that, he tried to master being a doctor, and then so on.

And I think having the same approach is definitely beneficial when you're trying to become a design engineer, because most often times, you might get overwhelmed, and I always tell people learn their basics and then go on to the next skill.

So the key, especially around, like products and how it scales is that as, products get more complex, the separation between design and engineering grows wider.

So that's why it's very important to have people that are able to speak the same language between design and code and able to be like the ultimate collaborator.

And I want to outline three, three positive things around being a design engineer and like why we should have them.

Like I said before, it improves the cross functional communication and collaboration.

And this works well, especially when you're working within a smaller team, but also a bigger team, because you can focus on key different areas.

The next thing is around reduced friction.

What often happens is that, especially when teams get bigger, they're less likely to try new things and it's like a lot of friction between design and your product.

So it's important to have these individuals that are able to take ideas from concept to completion and work by themselves or basically work as a team.

And last is more around like exploring, innovative ideas.

As we're exploring this age of AI and whatnot.

And usually if you want to explore, you need someone that's able to feel comfortable, be able to understand how to perceive product design, but also like, where can we use AI to benefit not only our colleagues, but our users.

So I'm going to get into the first one that revolves around, improving cross functional communication and collaboration.

I think communication is like one of the key things around, design, but also development, because most often times, when problems happen, it's because people are not communicating clearly, and the great thing about design engineers is that naturally we are bilingual, so we're able to speak to designers about color theory and line, and then from the engineering perspective, you could talk about, front end architecture or API design.

And with this diagram, I'm showing like the focus between product designer and the front engineer.

So as you can see, the product designers is, very focused on UX research, the UI design, and then prototyping.

And this is where you see this like handoff process where, once it's done, the actual, developer will take it, implement the UI and then, go connect it to like the APIs and database.

And where design engineers kind of fall is like in this middle.

And they're able to like work from the, from concept to completion.

And I will also communicate not all design engineers are the same.

So for me, I'm more of a UI designer and I lean towards the code side, but I've.

I've worked with people that are more, researchers and are able to take the research and kind of find these reports and whatnot.

So it's important to understand what's your, I would say two skills that you like to do in, but also be competent that you can if you need to work throughout the whole process.

And one of the things I like sayings I like to use when I'm like thinking about creating tools or products or whatnot, it's like.

Making sure that I build the right thing.

So am I building something that users want?

And once I figure that out, I want to make sure that I'm building the thing right.

And what I mean by that is that I want to make sure that things are accessible, it's performant, and scalable.

And I think it's very important not to do these at the same time, because, again, if you do it at the same time, you're going to feel overwhelmed, and you're not going to do it to the best of your ability.

So I talked about design engineer, but I want to highlight two specific roles that are super important.

So we have like design technologists and then you have UI, UX engineer, but you can switch out engineer for UI, UX developer.

And the great thing is like I have experience in both of these roles and there's like some similarities, but there's some differences.

So if you get into what is a design technologist?

Usually, they focus on rapid prototyping ideas, and then being able to validate them for future features.

I'll also say that, they really focus on, tooling, so this could be Figma tooling or anything that will optimize the design development process.

What about UI, UX engineering?

So they focus mostly on production level code, making sure that it's accessible, performant, and scalable.

And again, there might be cases where they do a lot more prototyping, but I would say they're more focused on the production level aspect of it.

So I want to talk about some of those similarities and where they focus on.

So like I mentioned before, tooling is probably one of the things that some of the people really focus on.

So what I've done in the past is I've built tooling for Figma, or back in the day Sketch that kinda optimize the process of building and designing UI.

The second thing is prototyping.

I think, as we're all like, designers and developers, the best thing we do is like prototyping ideas from concept to completion and be able to validate, if they're worthy to explore.

And last is design systems.

I think design systems is like the home of the hybrid.

You're able to work on both from the design perspective, but also from the engineering perspective in the control area.

So I highly recommend if you're interested in becoming a design engineer or design technologist, definitely look into being, going into design systems.

So I'm going to showcase a couple, tools that, a couple of design engineers have built in the past.

So this was, we were facing an issue where a lot of people didn't know our brand colors and this is like when I was working at MailChimp.

And they just wanted a place where they could just do it where everyone is at, which is Slack.

So one of my colleagues basically created a Slack plugin that allowed them to output all of the brand colors within Slack and the idea around this is that like sometimes, and this is before Figma, but sometimes, when, people that are non designers want to know what are the brand colors, they just put this, type this in and they're able to output all the colors.

This is Mailchimp's design system.

Mailchimp had probably one of the earliest design systems, public design systems.

And this is where, especially if you're like a design engineer or a hybrid this is a perfect place because you're able to leverage both of your skills at the same time.

And this is actually one of my favorite projects.

One of my colleagues created this tool called Bench, and it was basically a product that you were able to bootstrap a prototype within two, three minutes.

And the idea is it was head built, it was built in with the design system in mind.

So it came with the design system, but also if you wanted to make it publicly available, you run a simple command and you're able to have it available to the public.

So if you're doing any, if you're doing any, user res, if you're doing any user research or usability testing, be able to do it in a very, streamlined way and very easily.

And what we did was like, we worked with a couple of clients and we we had a couple of prototypes and then we just plugged in their own data so that when we're doing usability testing, they're able to really understand, like, how to use a product because it's in context of, the data that they're familiar with.


Let's get into, how does design engineering, reduce, friction.

And this really depends on, like, how it's incorporated into the actual, organization.

I've been in the past where it's like a standalone, discipline, or it's like under design at Eng, or it's under product, and the common question I always get is like, where should it live?

I would say it doesn't matter.

I think the only thing that matters is that you're at, regardless of if you're under design or engineering.

You want to be in a place that you're able to collaborate with all three different disciplines at the same time.

So this is a quote from Natalie Antaglia who was one of the other co authors and she mentioned that organizations that recognize the opportunity in the gap between design and engineering will outpace those that fail to invest in it.

So if you invest in these hybrid roles, what ends up happening is that you're able to move quickly, have better products.

And have products that are more scalable, accessible, and performant.

And there's three different ways we can integrate design engineering as a practice within an organization.

So the first way is a centralized model, so where you have a design engineer org, and then you have a couple of design engineers that kind of report to the manager.

The great thing about this is it's a great way to establish design engineer practices and whatnot.

The problem or the con is that what ends up happening is that you're siloed away from the product development and usually you miss out on key things to like collaborate on.

This is the decentralized model.

So this is where the design engineers are embedded within the actual product teams.

This is also pretty good.

I think the pro is that they're part of the team.

The con is that it's hard to set up a good design engineer practice when people are just segmented through different teams.

And then last is more like the hybrid model, and I've done this before, is where you as a design engineering team, you act like consultants.

So every, year you go and work with a product team for a quarter and you're basically, working on figuring out how to, provide support on accessibility, prototyping and whatnot.

And I would say the caveat is that you want to make sure that you scope it to a specific time and problem because what could end up happening is that these teams want you to, be part of the team full time.

But I think the idea is, you want to act like a consultant to be able to, when the job is done, go back to your team.

Kim Williams, who's also, co author of the book, she had a good idea about, technologies come and go, but the willingness to be curious is a lasting key trait for all members of a thriving design engineering organization.

So I think the key word is curiosity, making sure that as design engineers we're very curious about the problem, technologies, and use that curiosity to push us to make sure that we build, usable products for everyone.

I'm going to get into a couple of ways where, design engineering allows for exploration and, building innovative ideas.

This is like the design process I use now.

It's more based on the actual scientific method where, You start with the question, then you start doing some research, you come up with a hypothesis about and then you think about like how you want to prototype it and I think about it as a way where you learn, test, and iterate over time and kind of dog fooding your solution before you test it with external ones.

This is what's also called like the, design squiggly or the fuzzy front end.

But the idea is that like when you're in the beginning stages.

There's a lot of noise and uncertainty.

And as you do like more research and concepts and prototyping.

Things get more clear, especially when you get to the design point of view.

And the last diagram I want to show is more in case of like, how good ideas are built off of bad ideas.

So the idea is we always have like a bunch of ideas in the beginning, but as you progress, you validate and it's like, all right, this is not a good idea, but you build on top of it and whatnot.

I want to talk about like the process overall.

I know like in some cases, a lot of us work in a waterfall methodology where you start with the design and then you wait until it's done and then you hand it off to the developer and they build it off.

The problem with this is that you're putting a lot of pressure on the design, designer to make sure that they come up with the perfect solution because, the cost of being able to rectify a bad design decision in the development is very costly.

So that's why I really like the idea of a handshake process.

So rather than waiting until the design is fully done, the engineers can like work in tandem.

The great thing about this is like the engineers are able to be familiar with the design early in the process, and also share like any, things that it's not feasible based on the technology and whatnot.

But the one thing I want to communicate is this role is very ambiguous.

So you're going to have definitely a lot of, projects that are, not clear on guidelines or stakeholders and whatnot.

And you must be like comfortable with that because that often happens a lot.

Another quote from Eddie Liu, he talked about, perhaps the most important element of design engineers is, can contribute is the mindset.

And I think having the growth mindset is going to take you far, especially if you're looking at becoming a design engineer, but also when you're working with your colleagues.

So I want to talk about prototyping because it's the, one of my favorite things I like to do.

This is a quote about, from, Tom and David Kelly around prototyping where it's like.

If a picture is worth a thousand words, a prototype is worth a thousand meetings.

This is great for me because I hate meanings any time I want to decline it, but I think it's mostly because a lot of times people don't know how to run meetings efficiently.

And I think having a prototype will definitely make it where it's easier to have more efficient feedback sessions and whatnot.

So there's definitely a couple of pros about prototyping.

I think a lot of it comes to being able to sell ideas to stakeholders.

And this matters if your stakeholders are more of your teams, but also, high level, colleagues.

It helps you uncover potential edge cases, this often happens, especially when you're working on very complex, product development and product design.

And it helps you, improve macro interactions, because you can include animation and whatnot.

And I want to get into like quickly, prototyping methods.

I know I'm like running out of time, but there's a couple of methods that I think are super important.

So you have a paper prototype.

This is like a prototype that's made out of paper and you just use pen, paper, and pencil.

This is great when you're starting out.

Then this is more of a wireframe prototype.

So you're doing a case where it's not, it's… the content's not figured out, but you it's very general and, it's like kind of more grayscale.

And then you have more static prototypes.

So this could be Figma , InVision and whatnot, but then you just click around and be able to leverage, the tool and whatnot.

One of my favorite prototypes is like interactive prototypes.

So I do a lot of front end prototypes and this is from what I was doing when I was at NASDAQ.

And you can see like in earlier, like the earlier the prototype is like very ugly and stuff didn't make sense but as you progress you see the progression and this is example of like we thought we wanted to have a, start with a big chart.

Obviously it was a bad idea, but I think this is the idea where it's like you're able to work through as many ideas as possible.

And we did 14 iterations of this prototype itself.

But I like to say like the idea should drive the prototype method overall.

So this is a chart where you can see like how confident you are with the actual prototype should drive which method you use.

So if you're not confident, use something that's more flexible.

And then the more confident you are, the more, the higher fidelity the prototype is going to be.


So I'm going to get into a couple of takeaways.

So the first takeaway is to create a space for hybrids to thrive.

I think it's very important to have a space where hybrids are able to have time to build prototypes, tooling, and really understand what is, what are some of the things that, the users, but also internal users are facing.

The next is be able to validate those ideas in exploration.

So you want to be able to allow time for this exploration.

So this could be anything from AR or maybe using a different framework.

It's very important to have time for able to focus on these things.

And then next is, you want to be able to focus on building the right thing, then the thing right.

So I want to make sure you're building something that's going to add some value.

Once you find that out, you need to build something that's accessible, scalable, and performant.

Thanks again for, listening to me.

If anyone's interested, this is mostly coming from the Design Engine Handbook.

Definitely, check it out if you want to have more of a deep dive of design engineering.

And then, I am writing a book about prototyping, so if anyone's interested or want to be like a beta, reader, definitely check it out, let me know.

I will be publishing something probably early next year.

But cool.

Thank you very much.

Thank you.

Thank you.

Adekunle Oduye

(Add-eh-koon-lay Oh-due-yay)


Talk Overview

  • The meaning of design engineering and the key roles within them
  • The four principles of design engineering
  • How design engineering can positively impact the product development process

Link to Slides

My Career Journey

Roles I've had in the past:

  • Web Designer
  • Front-end Developer
  • Product Designer
  • Front-end Engineer
  • Design Technologist
  • UX Engineer

The industry wants you to put you in a box

But very few of us are one dimensional

What is a Design Engineer?

What is a Design Engineer?

It's the specialization in the intersection of design and engineering.

Design Engineer Principles


Does our product add value and solve problems for our users?


Can users figure out how to use it?


Will engineers be able to build the features within the time, resources, and technology available?

Business Viability

Will this solution benefit the business?

There are conflicts in being a "unicorn"

People try to impose their limitations on others

It isn't easy being design engineer

"If you're passionate, you can learn anything."

Eddie Lou, Design Engineering Handbook

Pareto's Rule or 80/20 Rule

Pareto's Rule or 80/20 Rule

Roughly 80% of the effects come from 20% of the causes.

Visualize pareto principle for a skill

Pie chart divided into two sections showing the Pareto Principle for a skill, with the larger section labeled 'Must Know' and the smaller section labeled 'Nice To Know'.

Design: Must know

  • Line
  • Color Theory
  • Space
  • Shape
  • Typography

A pie chart with two segments. The larger segment is labeled "Must Know" and the smaller segment is labeled "Nice To Know".

Engineer: Must know

  • Data types
  • Operators
  • Conditionals
  • Functions
  • Objects
A pie chart showing the division of knowledge areas an engineer must know, with a larger 'Must Know' segment in blue and a smaller 'Nice To Know' segment in dark teal.

Johnny Kim: Navy seal, doctor and astronaut

Credits: Allkpop Article | Interview
Three portrait photos of Johnny Kim in different stages of his career: on the left as a Navy SEAL in combat gear, in the center as a doctor in a white coat and tie, and on the right as an astronaut in a blue NASA flight suit.

As products get more complex, the separation between design & engineering grows wider

Positives of having design engineers:

  • Improve cross-functional communication & collaboration
  • Reduce friction
  • Allow exploration of innovative ideas

Improve cross-functional communication & collaboration

By default, design engineers are biligual.

Diagram showing a dual-axis graph with 'Level of Focus' on the vertical y-axis, rising and falling as it moves from UX Research to APIs & Databases along the horizontal x-axis. The left side of the graph representing 'Product Designer' is shaded in blue, with the focus declining from UX Research to UI Implementation and slightly rising towards APIs & Databases. The right side representing 'Front-end Engineer' is shaded in green, with an inverse trend, displaying a lower focus on UX Research that peaks at UI Implementation then slightly declines towards APIs & Databases.
A Venn diagram illustrating the overlap of skills between Product Designers (blue), Design Engineers (pink), and Front-end Engineers (green). There are five areas labeled: UX Research, UI Design, Prototyping, UI Implementation, and APIs & Databases. The diagram shows the level of focus of each profession on these areas.

Build the right thing

Build the right thing then the thing right

Design engineer key roles:

Design engineer key roles:

  • Design Technologist
  • UI/UX Engineer

What does a Design Technologist do?

Rapid prototype ideas in order to validate future features.

What does a UI/UX Engineer do?

Develop production-level code that is accessible, performant and scalable.

Design engineer focus areas:

  • Tooling
  • Prototyping
  • Design systems
A screenshot displaying a Slack message with an embedded image preview and a link to an image file, alongside a command input field.

Mailchimp's Design System

A screenshot of a page in Mailchimps design system for buttons.

Bench: Mailchimp's Prototyping Tool

A screenshot of Mailchimp’s prototyping tool interface named Bench, featuring a search bar, navigation items, and a project titled "Hello World!" with Adekunle-Oduye listed as the author.

Reduce friction

Incorporate design engineers into organization

Should it live under design, engineer or product?

"Organizations that recognize the opportunity in the gap between design and engineering will outpace those that fail to invest in it."

Natalya Shelburne, Design Engineering Handbook
Background image of a person's silhouette on the left with a gradient overlay, mainly dark, which fades to the right side of the slide.

Centralized model

Diagram of a centralized model with a single Design Engineer Manager at the top, connected by arrows to four Design Engineers arranged horizontally below.

Decentralized model

An organizational chart illustrating a decentralized model with three repeating units. Each unit is a vertical hierarchy from 'General Manager' at the top, branching out to 'Product Manager' and 'Design Engineer' below, and further branching to 'Product Designer', 'Software Engineer', and 'User Researcher'. Arrows indicate bi-directional communication between all roles.

Hybrid model

A diagram showing the Hybrid model with a central role labeled 'Design Engineer Manager' and bidirectional arrows to 'Design Engineers' at four corners. Each corner has additional roles such as 'General Manager,' 'Product Manager,' 'Product Designer,' 'Software Engineer,' and 'User Researcher' arranged hierarchically and connected by arrows indicating relationships.

"Technologies come and go, but the willingness to be curious is a lasting key trait for all members of a thriving design engineering organization."

- Kim Williams, Design Engineering Handbook
A slide with a semi-transparent layer over a blurred background of leaves, with a quote displayed in white text.

Allow exploration of innovative ideas

Design Process

A circular flow chart showing the stages of the design process with five labeled circles arranged in a loop: "Question," "Research," "Hypothesis," "Test," and a central circle "Prototype," depicting three smaller sub-steps: "Learn," "Measure outcomes," and "Test." Arrows indicate the flow from one stage to the next.

The Design Squiggle

Illustration of 'The Design Squiggle' showing a tangled line evolving into a straight line, representing the design process from research and synthesis, through concept and prototype, to clarity and focus in design.
Branching exploration
Diagram of branching paths with a main blue line and several gray lines diverging from it, marked by red 'X' symbols for failure points and a green checkmark indicating a successful path.

Handoff Process

Horizontal timeline with a line progressing from left to right, labeled 'Design' at the start and 'Development' at the end, with a red dot indicating a point on the timeline, suggesting a current phase or milestone in the handoff process.

Handoff Process

Handshake Process

Two horizontal timelines comparing 'Handoff Process' and 'Handshake Process' in product development. The Handoff Process timeline has a single connection point between Design and Development. The Handshake Process timeline displays multiple connection points between Design and Development, indicating iterative collaboration.

Being comfortable with ambiguity is a must.

"Perhaps the most important element design engineers contribute is mindset"

- Eddie Lou, Design Engineering Handbook
Background image of a person's silhouette in dark blue overlay.


"If a picture is worth 1000 words, a prototype is worth 1000 meetings."

- Tom & David Kelley, IDEO
Background image of two males, one on the left in partial profile with glasses and a hat, and one on the right facing forward, both slightly transparent with a dark overlay to allow for white text overlay.

Prototyping benefits

  • Selling ideas to stakeholders
  • Uncover potential edge-cases
  • Improve micro-interactions

Prototype Methods

Image depicts a handwritten paper prototype with a schedule outlined for an "Annual US Roadshow" including dates, topic circles, annotations, and symbols for various meeting types or events. Additional hand drawings indicate stars for ratings, and symbols for flights.

Wireframe Prototype

Image depicts a wireframe prototype

Static Prototype - Invision

Interface design of a benefits management system with navigation on the left, three central content blocks illustrating gym membership, Citi Bike, and 401(k), and a bottom bar with design and interaction tools. The layout conveys a user-friendly experience with prominent call-to-action areas.

Interactive Prototype
A screenshot of a software interface showing an active window of a code editor with JavaScript code on the left and a browser window with a financial dashboard on Nasdaq IR Insight on the right, including bar charts and a list of top buyers.
A screenshot of a financial dashboard interface consisting of bar charts, lists, and numerical data representing top 25 firm holders and upside potential. There is also a section that shows percentage allocations by sector such as Financials, Energy, Health Care, and Industrials.

The idea should drive which prototype method to use.

A graph with a red curved line ascending sharply to the right. The horizontal axis is labeled 'Prototype method' with markers for 'Paper,' 'Wireframe,' 'Static,' and 'Interactive.' The vertical axis is labeled 'Concept Confidence.'

Prototype hypothesis


Create space for hybrids to thrive.

Adjust the process to allow time for exploration & validation.

Focus on building the right thing then the thing right.

Design Engineering Handbook

By Natalya Shelburne, Adekunle Oduye, Kim Williams, by InVision
Illustration of human hands interacting with geometric shapes and patterns representing digital interfaces, suggesting a theme of design and engineering collaboration.



Thanks for listening!