[Applause]
hi I'm Judy I'm a developer hi i'm fran
from a designer by the way how many
designers do we have today not a lot but
as expected as a mostly tech conference
but how many developers work with
designers so that's of us today and well
we're very excited to be here today and
spark to dev UX culture so what step UX
it's basically well the idea of
spreading the love between designers and
developers finally so just a bit about
myself so I'm a little developer at
theater it's a service company and what
I do is help my client build new
products so this whole story about dev
u8 started actually with the project so
a year ago I was on this project and I
have to build a chat service in six
months so the project starts and the
designer sends me all the mock-ups and
actually I get stuck at the first
feature because I have to display this
chat bubble but I don't have the icons
so I asked the designer for the icon and
he sent me this and actually I cannot
work with this blue background so I
asked for the icon on me and then we're
working on the remote so the designer is
not there and I have to wait for the
icon and I just cannot just go there and
poke him and say yeah give me the icon
please give me the icon so I wait and I
guess and I get this nice PNG but then I
realize hey colors should be
customizable and actually I cannot do
that with the PNG I I really would like
an SVG format so I asked for an SVG
format and I wait for the fight to come
so finally after all those back and
forth about the stupid icon and
basically I wasted half a day on this
well I finally get to finish my feature
so he must hear the frustration in my
voice when I tell this story but at that
time I had much more things to worry
about
I had to
tends to pack ends to manage I had a
team to train so really when it comes to
markup integrations I didn't want it to
come that way and be so painful so then
I took a step back and then I remembered
that well I had a friend Hoss who has
actually an experiment a designer and I
wondered how she was working so I
reached out to her and asked for her
help and her insights so when she called
me was actually pretty funny because I
was suffering on my own project back
then I was working at a sister company
of thedo and so I was working with a
client and a very simple app it was a
mobile application with a very classic
sign up and login
so I gave the design for the signup form
to the developers who start working on
it and then asked me for the login form
and I go why do you need it because
they're actually the same design with
different wordings but they insisted so
I ended up providing it to them but I
was very frustrated because if you look
at those design side by side they're the
same structure the basically the same
thing and it's just it felt like they
didn't try to understand a product as a
whole and were just designing the pages
as he came and I was actually I had
other things to do I had a product owner
who didn't want you to usability testing
so I was trying very hard to convince
him that that was very important to do
and a very short timeline to design the
rest of the features of the app so I'm
having to copy paste the same design and
then changing the wording was that the
last thing I wanted to do so having
heard each side of the story we realized
that by under sting understanding each
other more we would actually enjoy
working together and that's how we
started this whole Devi web thing and so
we experimented on new projects we've
worked with other teams and we were able
to map out four levels of dev UX
collaborations so I'm going to work
through them
grunts you're obviously STIs function
then you can move up to level one the
basics then level two efficiency and
finally the Holy Grail symbiosis so what
we're going to do is walk you through
different projects at different stages
of collaboration to illustrate our
points and before that just a summarize
of the context so the usual team
composition of the project would be the
product team with designers and
developers working hand-in-hand with a
product owner that sets the product
vision and the roadmap around this team
we have stakeholders such as the CEO of
someone from marketing someone from
another product team or even legal
that's gonna tell you yeah I need this
or that so for the first story by the
way all stories are true for the first
time I'm going to take a food tech app
that my company worked on a couple of
years back I didn't work on the project
we're actually working with a freelance
designer who had a very limited time on
the project but I did follow the project
very closely and so it started like this
the designer had time in advance to ship
all of the design for the product so he
provides that to the team and the
product owner is very happy because
that's exactly what she wanted so the
team happily starts and actually one
week later the CEO sees the app and he
is very unhappy with the UI he says
that's totally not what he wanted for
the app and actually that puts a stop to
everything the team has to start over on
the design and the development team has
no choice but to only work on the
backend for a while and it took
literally three weeks and 17 attempts to
find a UI design that actually worked
for both the PIO and the nd CEO and
from then development can start again
but that's when the designer had to
leave because he only had that much time
on the project and that's in theory if
all the designs are great great but of
course there were things that were
missing there were behaviors that were
not clear and so the developers they
have no one to turn to except the
product owner so they asked her for
advice and she goes well I'm not a
designer so I really don't know so they
do what they can and then we call this
best effort which means they try to do
something that not too ugly and Kanna
works and let's hope nothing breaks
and so yeah so let's look back and see
what went wrong so first thing the CEO
made the whole team start over and this
happens when the process for product
definition is not clear so this happens
mostly with macaws being late too many
people being involved in the decision
process there's other problems that can
happen too
like for example the vision of the
product is not well defined so it's very
important at this very basic level to
clarify what each team member has to do
what their responsibility is and to
define key moments where they can
synchronize with each other so a very
simple very basic process would be the
product owner is the one who is in
charge of the product vision so he
writes down the specifications and the
description of the task description he
has dedicated moment with the designer
so that he can pass on that vision so
that the designer can make the mock-ups
and there's a separate moment for
developers you altogether define the
technical strategy to implement all this
so of course this is a very simple way
of doing it but don't be afraid of
adapting this to your context for
example if you know that your product
owner wants or likes to have user inputs
before he decides of the needs bring him
into your user research if you know that
developers can be very picky about
certain things in the design invite them
to the UX workshop so that they can
together you can find solutions for the
upcoming
juice etc etc and it might look a bit
scary like this because it looks like
they're all those big meetings but they
don't have to be big meetings you can do
this
a synchronously over slag or on any tool
that you use you can do that over a
coffee break five minutes the important
thing is just to update every member of
the team product design product owner
all together on what is the new
direction for the product so what's the
second issue the second issue is that
actually the there were missing assets
and that happens a lot when designers do
their job ship the designs and they just
leave and the thing that don't worry
they don't realize is that mock-ups are
not development reading material so what
I really encourage people to do is to
have a meeting developers and designers
together to define what needs to be
delivered alongside the mock-ups and to
centralize those the assets and
everything in the design house so first
you could just for example it could just
be a simple checklist of everything that
needs to be done it may be its static
content maybe it's images where can I
find those images etc a very useful tool
is to use the design hand off tool
because they centralize everything you
can download the asset but you also can
see how the screen was built so that you
see the margins the font size the font
colors you can even export some code
when depending on the under product and
yeah my personal favorite is is the
plane but there's a lot of tools on the
market so we can talk about it later if
you want
and the third thing is that because the
designer had left the developers were
left on their own to figure out some
behaviors and solutions and this this is
again is because the designer had to
leave before the end of the project what
we really encourage you to do is to find
a way to keep the designer working in
parallel of the developers for instance
I always manage to during a certain
sprint help the developers with the
current feature they're working on
because since I worked on the feature
beforehand I can help them with certain
issues certain things that we hadn't
seen upfront but I can also test the
previous features so they can learn from
them and avoid some mistakes in the
future and I can start thinking about
the upcoming features and if the
roadmaps of designers and developers are
well synchronized then it's completely
possible to do this so if I want to
summarize if you cut the design and
development process in three phases
product the finish definition mock-up
delivery and development the product
definition phase four to go to the basic
level of collaboration you need to have
a well-defined process on the mock-up
delivery
it's important to centralize everything
so that developers know where to find
the information and the assets and on
the development side work together where
next to each other so it's easier to
communicate and not have moments where
you just don't know what to do and have
no one to answer to your questions if
you do all this then you got to level
one so welcome you've got the basics so
what happens now with level one project
so the team here is working on a travel
agency tool and what they're trying to
do is display an itinerary on the map
this is the design that the designer
suggests and the team implements it but
actually when it goes live the itinerary
do not look very user friendly and that
happens on most itineraries so the team
has to roll back the feature and the
designer has to work again on the new
design this time with numbers for each
please
I mean numbers for each day and the
place is that the traveler is going to
visit the thing is the designer did not
think of the case where itineraries loop
so developers get stuck when first a
date will happen at the same place as
day five and they need to figure out
something to display that information
and in the first the designer decides to
use a tooltip to display that
information and then the developer
finished the development they implement
the tooltip and well they decided to
improvise on the hover and active state
of that tooltip because they really were
eager to finish that feature and
actually I don't think the designer
really liked it but he went with it
because they wanted to bring value to
the users as fast as possible so what
are the new challenges that arose here
well first of the designer did not use
real data to build their mock episode
they were not really working on real use
case and they did miss edge cases so to
provide that proven that it's essential
that designers work with real data when
it comes to like having complex
situations and developers can provide
those data and then can also provide
technical insights during the mock-up
creation so for instance this is a tool
that house uses on sketch so it's it's
called craft and what you can do is
basically use an API to get some data
and use those data to populate a lists
so getting an image getting a title and
it's really powerful when you need to
populate for say a table or a list
because we all know there are many
educators and it's good to work with
real data the second thing that was
missing was really a list of the states
and edge cases on components and
sometimes what can also miss it within
when it comes to responsive you don't
know how at the screen behaves and the
layout behaves so really important to
have a style guide that some of all the
states and behaviors of components and
also define the break points for your
responsive behavior so we've mentioned I
mean it was mentioned in the previous
talks do you have like a common language
between designers and developers and
that's why I really like the style guide
it's really a UI contract between the
two and so you know what colors should
be used on the app you know what font
size what font you should use you know
the convention around margins and
spacings that should always be multiple
of some values you know like how the
patterns should behave you've got all
the states and you've got the form
different variations of forms errors
States etc so I don't know if you have
this on your project if you don't really
try to get this as soon as possible
because that will help you in your
choices and to get an app consistent and
also
another thing that's helpful is user
flow what I like when I work on a
complex feature is really to understand
how you go from one screen to another so
here we have video uploading work flow
so first you start with the uploading
page then you move to your processing
page and finally if it's successful you
get a preview and if it's not you go
back to the initial upload page with an
error message this is an example of how
the designer can show you how the
layouts
behave on smaller and wider screens and
really the designer can provide all
these but it's essential that developers
are unloaded on this and really
understand how to use style guides or
layout etc otherwise you'll just keep
asking questions to the designer or just
not follow the rules and and the app
will not look like what the designer
intended so to summarize for product
definition it's essential that the
designer has real data and can work on
the different edge cases and for that
developers can provide technical
insights and for mock-up creation and
development it's essential that
designers and developers speak the same
language and you can define that
contract with a style guide and if
you've done all that in congratulations
you're you're reaching the level -
you're being efficient already you've
you've got rid of most of the friction
points so it's quite an achievement when
you're there and things get well happier
so you could just stop there but
sometimes projects are more demanding
and you need to level up your game
so let's see how you can go from a level
2 project where everything runs pretty
smoothly - and a new battery this is
actually a project that yielding and I
worked together on and we were working
for a product owner who was one very
picky about the user experience and he
was right he was a market leader
afford to have bad user experience on
his tool and the tool was a technical
tool was for death plotters and in this
tool there was a very lengthy
documentation as you can imagine and so
I wanted that when you scroll down the
documentation you can see the anchor in
the navigation on the left update so
that you always know where you're at
and you can easily come back to a point
that you've missed previously and of
course the product owner was completely
on board with this idea except that your
link tells me well I'm sorry but it's
too complex and we cannot fit it in a
roadmap right now so the product owner
is pretty disappointed but he
understands and he goes along with it
and I try very hard not to cry and as I
said the product owner was very picky so
he would always make us change tiny
things here and there in the interface
if things were small and not quite right
with fixit's spacing was not right with
fix it
alignment was not right with fix it
colors were not right I'd find a new
color and then we'd implement it and as
you can see we were a team that was very
we would pretty fast in answering and we
were very efficient working together but
there were still some friction points
and we could do better so how can we do
better the first thing you'll notice is
that some cool features got shut down
because of complexity and this actually
is happened because I didn't involve
your link beforehand before going to the
product owner and giving my suggestions
what I should have done is sit down with
her say okay I want to do this I think
it would be a great addition to the
product what do you think can we do this
and this way we could have found a smart
solution together instead of then going
to the product owner then going through
her and having to shut it down and
making everyone very disappointed and
wasting everyone's time actually I want
to give you an example on another
product
of where this happened and it was very
efficient there was this pricing range
that's called cider and so when the
development started they realized that
when it's very together you cannot read
the prices at all and so the rubber came
to me and said okay what do we do now
and I said oh but I actually wanted it
to look like that and he looked at me
and he said okay so we have this pretty
long form and you want me to spend
however long on this I mean can't we
find something that's easier to do and
so we it took two minutes literally on
my desk and we just said okay what's
important the important part is not to
at that point when the two ranges are
very close it's not you have both
numbers visible users are probably going
to slide so if one of the numbers is
legible it should probably be enough at
least for the first for the MVP and so
we added a white background behind the
first number so that you would always be
legible so in retrospect this was
probably not the best solution design or
UX wise but the message here is that we
spend two minutes together and we found
a solution that we were both happy with
and that's what I really want to
emphasize on
the second thing is that there were lots
of back-and-forth in order to improve
and polish the app and those were every
time the they would it would be much but
they would accumulate and become small
delays and so what we ended up doing at
the end of the project was every week
Yelena and I would just sit down and go
through all over the app for one hour
and we together we would find the little
inconsistencies that do things that need
to be improved and polish the app
together so we would basically per
program and this worked well but also
something that works very well if if
designers and developers share common
design patterns so by that what I mean
basically speak the same language but
beyond speaking the same language
understand a bit the logic of each other
each other's logic for example if I have
a team that understands some basics of
UX if I tell them I want the designs to
be keyboard aware then they will know
that whenever a ship we talk about a
form the buttons needs to be pushed up
by the keyboard whenever someone's going
to type and I don't want do not have to
redesign every time the state where the
buttons are below and then the buttons
are pushed up because we understand each
other
or on the other side on the other hand
if I have basis of understanding of HTML
I know that well if for example in this
example the this a table with two
columns I know that there's going to be
a minimum space that I want to leave
between the two columns I can show it to
the designer through the design hand off
tool by putting the max width of the
dump of a big give actually and so that
the designer can inspect it a developer
can inspect it and doesn't need to come
to me and say okay so when it's long
actually the text needs to wrap but I
don't know where and so this way it's
much easier and much more efficient so
this would be our advice you go from
level two to level three make sure to
involve designers developers in the
mock-up design process and find smart
solutions together whenever you find
small small problems make sure you
understand and share the same design
patterns so that you do not always need
to be
asking questions and have moments where
you sit down together and improve the
app together as a team because that's
your common goal is to produce the best
product for your users and if you do
that then you're amazing and welcome to
the Volturi so now that you understand
all about the different levels of
defects collaboration how can you
actually spark this new culture within
your teams well first thing of just
define where you're standing now and
where you want to go if you have very
solute situation if you just don't get
along just sticks stick to the basics if
you have lots of delays lots of
back-and-forth a focus on efficiency and
finally if you have high UX expectations
or if you just want to have fun then aim
for the same disease so basically this
summarize the different levels of def
rave def ux collaboration that you can
reach but the most important message
that we have for you is that dev UX is
all about the mindset so you need to
think as a team and act like a team
player when is the last time that you
had lunch or had a beer with the whole
team with your designers and and just
chat because those team-building moments
are essential to build empathy and
understand each other's problems and
motivations so much for instance my
message to the developers here in this
room is really that designers cannot
guess what you need to work properly so
don't hesitate to ask them and well do
not hesitate to call the designer
whenever whenever you have a design
question because they will save you time
they used to solving those issues second
thing to keep in mind is that details
are here for a reason
so you can rely on something like a
style guide or the design system to know
the truth of what the app is going to
look like so whenever you have a doubt
on colors on phantom sizes just refer to
that and pay attention because the
designer has like take
taken the effort to well provide you the
information so really use it and finally
if you want to make your job more
interesting show that you care about the
product so that's the product owner and
the designer will involve you when
you're making decisions on the other
side what the mindset I'd like to share
the mindset I'd like to share with
designers is first of all that mock-ups
are not development relief material so
you will need to provide extra steps for
the developers to to work and so as I'm
watching what they need another thing
that I've learned is that developers are
amazing at finding errors and edge cases
and so it's so much easier when I evolve
them early on on on the design process
so they can tell me well this what what
is going to happen when this error
happens and I'm like oh are we gonna
have this error yes believe me this is
my experience of course we're gonna have
it so it's it's so much easier when
they're in the room with me to discuss
those points but beyond that it's beyond
the smaller component edge cases we
often get frustrated when we come up
with a nice design and want it to be
implemented and tell us well no sorry
it's too complex but actually what I've
learned is also very frustrating for the
developer to not be able to do it
because they do care about the product
that I want it to be the best possible
so to avoid everyone's frustration just
involve the developer all the time
during the process because that's how
you can now come up with better features
to in order to share the dev you access
period around us
yelling and I have been doing this
monthly Deborah wax drinks with people
around us and it's they're very the idea
is just to chill and talk about what
we're watching on Netflix what we
excited about in the next tools that are
coming out for example recently I shared
a lot about sketch 55:58 which i think
is going to change a lot of things on
the design side of the project
and it's great because you can discuss
in a very informal way about your
problems about what how you feel as a as
a person in a team that might be working
well or might not for example in stencil
and recently not actually I learned
during the first of these drinks is that
actually even though there's friction
sometimes between developers and
designers developers are always so much
happier when they work with designers
because in the end at the end of the day
they're just prouder of the product that
they're making and that was meant so
much to me yeah I I really like those
drinks - I mean wine and cheese like
what what's more serious and more
seriously like there's something that I
learned and that was surprising to me
and actually I felt very relieved to
learn that is that designers are happy
to work with developers because they
help them make their more make them more
thorough with their work and and that's
a relief for me because before that I
only thought I was being annoying with
all those requests and questions so I
think that's our message here if you
wanna if you're interested in kind of
like improving your collaboration we've
set up a website that you ecstatic with
the manifest of quality of UX
collaboration so you can go there find
the tools that we use and if you want to
like chat with us we've set up a slack
also that you can join with this link
and yeah I think that's that that's it
don't hesitate to come and see us
afterwards at the booth thank you so
much thank you so much really and from