In today's video, I'm going to be sharing
how I typically work with software engineers as a UX product designer.
I'm going to talk about my working relationship with engineers
in the context of a design project timeline
so that you can get a better understanding of when
and how I engage my engineers throughout the design process.
Now, everyone's working style is going to be slightly different.
Each team and company are going to have slightly different processes,
but I found that they're pretty much all similar
and there aren't any real significant differences.
This video may also help some of you prep for behavioral questions
that you may get during interviews with engineers, especially if you don't
have actual work experience working on a product with engineers.
You'll get a better picture of how to effectively collaborate with them.
And so you can create hypothetical answers that will give the interviewer
the impression that even though you don't have work experience,
you do have a good sense of how to work collaboratively with engineers.
If you are actively or passively looking for jobs
and want to get a head start practicing interviews,
do apply to my talent collective to get leads from companies
within my network who are hiring for full time and part time roles.
Applying is super quick and easy so check out the link down
below in my description box.
When it comes to working with engineers, the most important thing
that you need to make sure to do is to share your designs early and often.
The reason why this is so important is because
at the end of the day, your designs can look really amazing.
But without engineers, they can't come to life.
They're the ones who will heavily influence if and when your designs
can get built and can get shipped.
They know how feasible something is
and how much cost and time are involved with building your designs.
You want to solicit their feedback early on so that you can understand
the environment in which your designs will be built,
and also being aware of technical constraints
will inform your design explorations and the decisions that you make.
And this will help remove any potential roadblocks later
down the road when it can be too late to change directions.
People new to the industry think that you need to learn how to code as a designer
and have some amount of coding knowledge in order to be a designer.
But most of the designers I know, including myself, have zero coding
knowledge.
So the important thing here is to really learn how to communicate
with your engineers and understand how they approach a problem.
And that's going to be really different because they're going to
look at your designs from a very technical standpoint, whereas you're looking at it
from the UX UI visual side of things.
Understanding how engineers approach your problem and what they really care
about is going to help you build trust, and that's going to be really crucial
to how easy your job is going to be as a designer.
Whenever you have trust built in a working relationship,
both parties just become less defensive and there will be disagreements
about a product decision or a design decision.
And when that time comes, if you have trust built into the working
relationship it's just going to be a lot easier to have those discussions.
I know from my past experiences working with engineers,
they really appreciate it when designers share their designs and solicit feedback
because they feel very much included in the decision making process.
In addition to having frequent check ins with my engineer, a tool that I love
to use is Loom which is the sponsor of today's video.
Loom is a video recording tool where you can screen record your designs
and share that as a URL link instead of having to upload
a huge video file to Slack or as an email attachment.
Loom has made it super easy for me to be able to share my designs
frequently and collect feedback without having to find a time
that works for everybody.
I'll show you later in the video how I use Loom for asynchronous check-Ins
with my engineers.
A typical design project timeline looks like this.
First you discover the problem space, then you define the problems
that your team is going to work on.
Then you develop solutions and ideas for that problem,
and then you deliver the final solutions.
I talk more in depth about this design process in another video,
so make sure to check that out here as well.
In this discovery
phase we'll usually have a project to kick off meeting led by my PM.
We'll invite the engineers, the data scientist and the designer,
and we'll have a meeting about what the goals are for this project,
discuss any relevant metrics that we need to better understand,
and also discuss any questions that we have to better understand,
current environments and other important details
that we need to know before we actually start on solutioning.
To give you an example of how I might pull my engineers during this stage
and work with them is: this is a project that I did for Beacons.
This is the onboarding flow and before I even worked on these new designs,
one of the things that I asked my engineers was how this page
and this page interacts and connect with each other.
So one of the questions I asked was, what if a user claims a username?
So in this example, the username they chose was Chunsters
but then they actually don't complete their account creation.
Does the username free up?
And so by asking this question, I was able to better understand
how the logic is set up for these two screens.
And with that information and with the answer that the engineer provides for me,
then I can go back to the drawing board and figure out if there are any
areas of improvement that I need to make where the current design is failing.
Once the group has spent some time understanding the problems space
then the leads from the different functions, the product manager,
eng lead, data science lead, and design lead will come together
and try to figure out which problems we're actually going to tackle
for the quarter.
Then I explore some design solutions.
So this is the developer stage where I'll do a lot of ideations
and this is where I try to have a lot of check ins with my engineers.
I will try to solicit as much feedback from the working group,
but there is a balance to keep like
I can't get too much feedback or else there's too many cooks in the kitchen
and then it makes it harder for me to actually make design decisions
and move the project forward.
I like to have in-person check ins because it just facilitates
a lot of discussions and we can just hash things out then and there.
But now that everyone is remote, and people are in different time
zones, it can be very difficult to find a time that works for everyone.
So this is where I find Loom to be extremely helpful,
where I can just screen record my designs and talk about my thought process,
about the design explorations that I've done so far.
And then once I screen record that, I'll send that URL link to my developers
instead of just sending them a figma link and writing up
a whole bunch of texts about the context behind those designs.
It's a lot easier for the person receiving them also to understand
and visualize what is actually happening in the Figma file.
So here's an example of what I would send to my engineers.
I wanted to share some of the explorations that I've done for the onboarding flow,
specifically the claim user name step and the account creation step.
So this is our current screen and these are my explorations.
The main difference here is we're going to be standardizing
the rows for headers and body texts.
Right now the body texts are all in different widths
and it's not very consistent.
So we're going to be just using the same styling
all across the board for onboarding.
This is the new input field as well with the button.
We don't have visuals for
when the username is available or when it's taken.
So these are the success and error states.
I wanted this feedback to be immediately
after the user puts in their username.
I don't know if that's technically difficult, but that's what I had in mind.
And let's go to the account creation step.
So not much is different here.
It's just new components.
And if you're wondering why these are center
aligned, it's because these are buttons and these are input fields so input
fields are always going to be left aligned.
This is the loading state and right now it's empty and this can take about
I believe, a few seconds to maximum 20 seconds.
And I feel like there's an opportunity for us to inspire our users
and engage our users
while they're waiting with sample pages that already exist from other profiles.
We can either use an animation like a Lottie animation for this
to cycle through those sample pages,
or if it's easier to just code static sample pages, we can also do that.
So I'll leave it up to you to decide, which makes more sense given our timeline.
As you can see, Loom helps you get your ideas across very quickly
without having to type everything out.
I find that people are also more engaged and it elicits more thoughtful
responses from the team because from their end
they don't have to try to connect everything in their own heads
while reading a long email or a long Slack thread.
I use Loom on a daily basis for work and for personal things.
Like if I have to screen record a small tutorial
or give feedback for my mentees on their portfolios,
I will record that on Loom and just share out the link.
You can try out Loom for yourself using the link in the description box below.
In the Develop phase, I also try to invite
engineers to use our UXR sessions that are going on
so that they can see for themselves how the designs impacts the users.
This helps with creating empathy among the team
when they listen in on these UXR sessions.
It just makes everything feel a lot more tangible
and you can see actual users and customers using the product that you're building.
Engineers have also told me
that they feel a lot more included when they attend these user sessions.
So try inviting your PMs
and your engineers to these usability or concept testing sessions.
Once my design is finalized, I'll schedule a design handoff meeting with my PM
and engineers to go over the final designs and some of the details
that need a little bit more explaining in this meeting.
No one should be alarmed or surprised by what they're seeing
because you would have done a lot of check ins and shared your designs
that they know why the final designs are the way they are,
and they shouldn't be asking a lot of questions because you should
have answered a lot of them and address those concerns beforehand.
Sometimes I will have like a pre handoff meeting with the engineers
when I'm 80 to 90% done with my design so that the engineers
can scope out some of their work before the specs are ready.
And that way anything that has to be addressed
before the final handoff can be addressed.
And if there's anything that's missing, I can also work on some of the edge cases
and use cases that need to be delivered during the handoff stage.
Once the first build is done, I'll ask the engineers to make sure
they host a QA session with me and some of the others in the team
so that we can test out that to a build and write down
anything that looks a little weird, feels a little weird
so that the final product actually reflects the original design
that was handed off.
I'd love to know how you work with engineers, and if there are things
that are slightly different or has worked really well for you,
throw them in the comments below and I'll see you in my next video!