- Hey everyone. Today I'm here with my
two favorite engineers on YouTube.
- Aw.
- This is Mayuko and Jarvis.
- Hi!
- Hello!
- We're doing a collab series today,
sorta about all our careers, stuff, ya know.
- Yeah.
- Yeah, it's gonna be great.
You're gonna check out their videos.
Link down below in the description.
But right now, in my video,
we're gonna talk about designers working with developers.
- Yes.
- Yes, should be good.
Sometimes there's some conflict in those areas.
You know, it happens.
- Yeah, any human relationship
has the opportunity for conflict.
- Yeah.
- Do you wanna start by telling everyone
what type of engineer you are, and what do you do.
- Sure, I'll go first.
- Yeah.
- So I'm an iOS engineer, so I make iOS apps.
- And I'm a full-stack web engineer,
focusing primarily on the back end.
So I'm building API's and systems
that power a web application.
- Right.
Okay, so how do you normally work with designers?
It sounds like from your two jobs,
the processes would be kinda different.
- So iOS apps tend to be kinda like considered as front end.
So kind of in the same world as, like, Android apps
or even front-end webs.
So it's really like building what the user sees.
So a lot of it is a direct translation between
what the designer designs and turning that into
an app or functional code. - Yeah.
- So yeah, we work really, really heavily with--
Really, really heavily? Is that the word?
Really, Really?
- Closely.
- Closely! That's the word.
So yeah, we work really, really closely
with designers for that.
- And how does the process work?
Like does a designer do a full pixel-perfect mock-up
and give it to you and you build it from there
and then they do feedback?
Does that sound right?
- Yeah, yeah. Typically they get to maybe,
like, a 50 to 90 percent completion, I would say.
The more looser and flexible it is the better,
because then there's more opportunity for feedback.
Especially as an engineer giving feedback to a designer
for a specific design.
It's like providing any expertise I have about
how long is this going to take to build,
is this really complicated to build.
We don't want to spend too much time on something that's
really, really specific that isn't important to the problem.
- Yep.
- So yeah, if designers have it at this good range
then it makes it really easy for us to work with them,
and we can make a better product as a result.
- Yeah.
There's a constant dialogue between the engineering team,
and the designer and product,
that sort of cycle of communication is very important.
So often times on the team,
there are meetings with the designer,
with where we see this like 80 percent design
and the team is able to weigh in on it,
in terms of complexity on the engineering side
and just general feedback.
As well as on the design side, they're doing design reviews
so it's already going through layers and layers of feedback.
And then, we give our feedback
and are able to iterate towards our solution.
- I like that it goes both ways too,
with the feedback.
- Yeah. It's very important,
because any break down in that communication can
make people distrustful of why they're building
what they're building.
- Yeah.
- And it can feel on the engineering side
like a feature factory where you are just like a code monkey
and you have no say in, like, what's being built.
(both women agreeing)
And that's never a situation you ever want to be in.
- I definitely remember that from past jobs
I've had working with developers
where things were kind of separate
and would hand it off for them to build it
and they'd build it not exactly like the design,
and I'd be like, "Why'd you do this?",
and they'll be like,
"Oh I didn't think that was important."
And I was like, "That's the most important part."
(laughing)
- It's a very long feedback cycle.
Here's a design. I built the thing,
and now we find out if something's wrong.
- Exactly.
- Where as you can have like a more peace meal
conversation, more consistent--
- More like constant contact.
- Constant contact, you get much better results.
- Exactly.
- And I think the healthiest product teams,
cause at the end of the day,
product manager, designer, and engineer
are all working towards solving a problem together
and each person is going to make specific decisions
around that, but if you can all align
on what's the best solution for that problem
then that's like the best case scenario.
(Jarvis and Charli agreeing)
So that involves a lot of this talking and collaboration
and really agreeing and aligning what that is.
So, like, having everyone in the room at once to do that
is, like, awesome.
- That makes totally sense.
I'm always asking,
well, back when I worked with a front-end developer,
now I have to develop my own websites,
so that's a whole different story.
(Mayuko and Jarvis laughing)
But I was always asking like,
"How long is this going to take to build?"
Like if I design it this way,
is that gonna really extend the build time
because it's not that important,
but I would kinda like it to look like this.
(laughing)
- One of the benefits that comes with
engineering and design and having a constant communication
is those types of discussions the designer can learn
more about what is possible,
and the engineer can think more about the long term
because if you really want the design to be that way.
Well do we as an organization want designs
to be more like this in the future?
Because in that case, we might want to make investments
that make those types of problems
easier to solve down the line.
- I learned a lot from, like,
almost things that went wrong with developers,
about pointing out when something was gonna be
like a component.
Like, hey, I plan on using this a lot, like,
this style of thing so build it out like that.
I just wasn't aware of pointing that out to start with.
- Should we define a component?
- Yeah, maybe.
- Yeah, so like, in a product or in a design
often times a design is made up of smaller reusable pieces
that look, that you can
use more than once. - Yeah.
- Everywhere.
Like you'll notice if you go to different pages on Facebook,
you'll see a lot of the same design elements.
- Yeah.
- And there, the designers
and the engineers lives are made easier
by having like a library or a system
by which they can build these reusable components
and use them all over the place.
- Yeah.
We often find that sometimes, I don't know,
depending on which developer I worked with, this quote,
design, component, would look different
because we hadn't told them, like,
hey, this is being reused,
and they didn't realize that someone else
had already built it on a another page.
- Yeah.
Sometimes I always have to think
when there is a design system,
I'm like, oh, the way that designers build their mocks
is really similar to how we build code,
because if you have these reasonable components
and you're just like using them in different places
and tweaking them a little bit.
Engineers are going to create classes that are reusable.
Designers are gonna use symbols that are reusable, right?
- Yeah, it makes sense.
- So the process is pretty similar
so when you engineers and designers
can jive like that it's like you get so much stuff done
and it feels so good.
- Can you think of any situations
where you've had something like that,
working with a designer,
something's gone wrong and what you learned from it.
Like, how can we as designers who are watching this,
because it's mostly designers that watch my channel.
How can they learn from this?
- Mmmm.
I feel like always communicating kinda like,
what is going into the thinking of a design
I think is really important.
As engineers, we see everything as a whole thing.
So we don't understand the specific decisions
that were made.
Like, why is this button rounded?,
Or like, why is this there? Why is this there?
- Right, right.
- But by understanding that we can also
prioritize what's the most important part of this mock
from a designer that we should prioritize,
so that also helps up be like,
okay, this is really expensive to create
but it's a really core part of the design
then we really should spend the time to do it.
Or if it's like, okay this is a really expensive thing to do
but it's not that important,
then we can have conversations to decide
what to do basically,
but I think that constant communication of just like open,
I guess that constant open and honest communication
is really important,
and really its just understanding where each other is at.
It's almost an exercise of empathy.
- Yeah, yeah.
And I think it's really important to try,
I think I've had some experiences
where someone on the design side wasn't
trying to understand or like maybe,
that communication channel hadn't been built
and it was more of like throwing it over the fence.
But,
when you,
on either side, engineer or designer,
try to understand the systems that are at play.
Everyone's job is easier.
But if you, kind of, are only zoned into your world
and not looking.
Like, your engineers are your friends,
you're all working together to the same goal
so talking to one another,
not being afraid,
I think is like that best thing
and when that doesn't happen
I've just seen it go so wrong.
- Yeah, that makes sense.
I mean, it sounds pretty simple right?
- Yeah.
- Communication.
(laughing)
For some reason, it is difficult.
- Yeah, it's tough, it's tough.
There's a lot of competing interests.
It's always hard to know
when too much communication can be a thing,
and you never want to put up
arbitrary barriers and red tape.
It makes everybody feel like
it's harder to get their work done.
- Yep.
- So striking that balance is, like, wide.
It's like a simple concept but a very difficult practice.
- Especially because each person
had their individual expectations, right?
And each person has a really unique way of doing that
so every time there's a new designer or new engineer,
you have to feel that out a little bit.
- And like build the relationship again as well.
- Exactly.
You have to develop that trust too,
and that stuff just takes time to do
and you just have to work at it really well.
- So on that,
do you think that the designers should learn to code?
This is the question that the internet asks.
- Oooh, oooh. This is a good one.
- Yeah.
- Short answer,
why not? Yeah.
I don't think its,
I also think that engineers should learn fundamental
aspects of design.
- That was gonna be my next question.
(laughing)
- It goes both ways.
- It kinda goes back to like,
this communication and the reciprocity necessary,
and they empathy that Mayuko was talking about.
It's so easy to imagine what engineers do
as like this wild black box.
There's a lot of complexity there,
but there's also a lot of simplicity
and it takes, you know,
you could spend, you could get 80 percent of the benefit
of understanding how engineering systems work
with 20 percent of the effort,
and that's like a really valuable thing to do
because it's gonna just make your life easier
and I say the same thing about engineers with design
because, I mean, have you seen an engineer de--
(laughing)
You can always tell when an engineer
is designing something right?
- Yeah, I totally agree with that
because that empathy for going back and forth
is really important,
but if you build that up,
engineers have the skills to design
and designers have the skills to code, or not even.
Like, they just understand how that works
then there maybe doesn't even have to be
too much communication of like,
hey, I really highly prioritize this
because this is like a core design thing
that just needs to happen, right?
Like buttons should be easy to identify
and like, they shouldn't be this wild color
where text is hard to read,
like, those are things that are,
if you understand those things,
then you don't even have to consult your designer
for every single thing.
- Right.
- And I think that also goes the same way
from a designer's perspective too.
There is certain constraints
that engineers is trying to work with.
So understanding at least the shape of those constraints
can make making decisions together a lot easier.
- And that helps the over-communication problem,
where you can have more meaningful communication
if you dip your foot in the other person's pool?
Pond? (laughing)
There was a metaphor there.
- Yeah, it means that, you know, you don't
have to explain the basics to them, right?
'Cause you're already getting each other
on a fundamental level.
- And you don't resent each other, like,
oh, they keep asking me these basic questions,
if only they had, you know--
- Taken two seconds to like learn--
- Taken two seconds or spent a day
walking in my shoes.
I'm mixing lots of metaphors here.
(laughing)
- That's good.
I think it's good that, I don't know.
Thank you for being here to share this, like,
view of things.
- Yeah, of course. - Totally.
- Because,
more designers and developers need to talk
'cause we're both building the same thing
at the end of the day.
- Right.
- Yeah, okay.
Thank you for watching everyone.
Give this video a thumbs up if you enjoyed it.
Do you want to quickly say what videos
we're doing on each of your channels,
so then people can go click the cards and watch them.
- Sure, yeah.
So on my channel, we're talking about success.
How do we define it, how do we think about it.
Yeah, it'll be a good time.
- Yeah.
= And on my channel, we're talking about failure.
So a nice yin and yang we got goin' on there.
- Thank you for watching.
Have a good day everyone.
(light calming music)