The Dawn of Design Engineering: A New Era of Collaboration

Sweet.

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?

Cool.

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.

Cool.

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.

Yeah.

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.