I want to talk a little bit about designing for developers, specifically

in bridging the gap between the design process and the hand off to development.

I want to start by telling a story.

Currently, I'm working on a project with a company

where we were the fourth company in the chain to get brought in for development.

And this company is they do have design capabilities, but they brought

in a third party design team to solve a problem for them.

They then contracted out another company to do the wrap up

of the mobile design and to finish the development of the website.

That company then contracted us to actually do the work.

And if this sounds familiar and you're, I saw a couple of people

shaking their heads, so I'm sure that this is you know, everybody's worst nightmare.

But what we found was that we had no

way of knowing what was going on with these designs.

For example, right before I came out here I was

wrapping up the designs on one of the mobile pages.

And as I turned it in, I checked in my chain design

GitHub, and I got a note back saying this is all wrong.

And I said, no, it's not, these are the designs,

and I sent them the PDF that I was working off.

And they go.

Oh, no.

There's a whole new design.

So it turns out that unbeknownst to me and my team

they've actually still been designing since they sent us the final final.ai.

And so that kind of, that kind of stuff is the,

the sort of thing that I think makes developers hate designers.

And, and the fact that I got that design wrong because I

didn't know that the file existed that I was supposed to be

working on, I think, is one of the things that leads for

designers to have a little bit of attention with developers as well.

So, how many people here are working on

a team that has both designers and developers?

Okay.

How many people are designers?

[COUGH] And developers?

Okay.

And who's in like project management and?

Okay great.

So let's let's jump back in to the actual talk here.

So, before we get started, ten seconds on me.

My name's Jason Lengstorf.

I founded a company called Copter Labs.

We're a digital marketing agency.

I have been doing this for a little over

a decade, and I've written three books on web development.

If you're interested to actually see those, you can Google me.

That's all I'm gonna talk about, on me.

I don't like it when people spend a lot of time on themselves.

okay, so the state of designing and developing on a team.

I feel like this is one of the biggest tensions

that I have seen in every team we've worked with.

When we get called in for agencies, when we work with, within our own team.

And on every team that I've been a part

of, there's always this big tension between design and development.

But I don't think that it's on purpose.

I think everybody on the team wants to be

awesome, we're all trying to do our best work.

The problem comes in because we just don't quite understand each other.

So, I ask developers, what is the issue with designers?

Why do you dislike, you know, the way that they work?

And it comes out as, oh they designed a

bunch of crap that we can't translate into code.

They, you know, they got so excited about

Gotham, who cares it looks just like Helvetica.

You know, things like that.

That, that just, just, you know, struggling.

And then I ask designers the same question.

What is it about developers?

And developers miss the details.

They don't get those hairline borders.

They replaced Gotham with Helvetica.

they, you know, they didn't understand why we cared

about this shade of gray versus a straight black.

So it's, it's kind of a, a mutually struggling place where

everybody doesn't quite understand why the other side is so upset.

But remember, we're all on the same team.

Everybody here is trying for the same thing.

We want an awesome website.

The developers want it to work amazingly, they

want everything to be accessible and for the,

you know, the user to come on and get exactly what they need and move on.

And the designer wants it to blow people's minds and it's gonna be beautiful.

Everybody's gonna walk away talking about how good that site was.

So, it's important to remember we are on the same team.

So, why is this so difficult?

[BLANK_AUDIO]

I think one of the biggest problems is inconsistency.

We don't give people a framework to work

within, so they, they kinda get stuck guessing.

Which is a huge problem.

In attention to detail on both sides.

I think sometimes designers will assume that developers

can fill in the gaps when they can't.

I think a lot of times, developers just straight up don't

pay attention to those details because they don't consider them important.

Lack of organization is huge.

We'll get into more what I mean there.

Poor awareness of the tools being used.

You know, if the, the designers don't know how it's gonna be built, they can't

possibly build for that tool so there's

a little bit of communication up front there.

Good old fashioned laziness is a huge problem.

People just, they don't wanna finish the job.

They want to get it 95% of the way

but they don't wanna do the polish and the naming.

And then there's definitely the whole communication issue.

and, you know, I, I work on both sides of the fence.

I'm a designer and a developer and, I

know I'm a developer, I am terrible at communication.

I just want to be grumpy and grumble at people.

I don't want to talk.

But, I think, there's still hope, I think that there's a lot

of things that can be easily fixed in a process that will allow

for the hand off to go much, much smoother, without requiring you

to change your personality, and without requiring you to hold hands with anybody.

The biggest thing one of the big things, keeping things consistent.

Don't start from scratch with every project.

When you have a starter template it can create a huge amount of saved work.

And it also creates this framework within to create that the developers

are able to then look at and they are familiar with it.

So, this could be anything from just

setting up a simple grid that's yours internally.

Or it could be using Bootstrap and having

the Bootstrap grid system and designing within that.

Just find something that works for your team that can be a starting point.

Use a grid system.

Like I said, it's huge.

And, and be good at the grid system.

Don't use a grid system and then adjust a column when it doesn't fit your design.

Use the grid system.

Be responsible about and be consistent with it.

The, the, the reason this is so important is because when you can put

your design elements on a grid, developers can then see them a little more

clearly in their heads when they're actually working in the code as opposed to

having to, you know, eyeball that 30 pixel margin, there's just a 30 pixel gutter.

And that's something that's, you know, it's important.

Don't make developers have to understand spatial relationships because

it might not be something that they're interested in.

It might or not be something that they're capable of.

the same as you might not be interested in the code, or capable

of really understanding why the JavaScript they wrote is doing what it does.

On the topic of grid systems, do not ignore the vertical grid.

Line heights, making sure that your vertical elements actually have

some kind of consistent rhythm going up and down the page.

This is very, very easy to do in Photoshop.

Photoshop has a grid.

Hit Cmd+' and the grid shows up.

You can adjust that in your settings to be whatever height you want it to be.

Personally I set a 40 pixel grid with 10 pixel break so

that I've got a nice clear, consistent vertical rhythm that I can use.

I line up all my fonts on that.

I line up all my images in the mockups.

Make sure that the headers and everything are on that grid.

So that when I go to the developers,

they know everything is gonna fit within this grid.

And if they're using a framework like Bootstrap,

all they have to do is change one variable.

And set the line height to ten pix.

Or like the, the, you know, vertical rhythm unit, or whatever their grid says.

They get sent to, set to 20 or, or

10 or whatever pixels, and that becomes the vertical rhythm.

They don't have to think about it, they don't

have to know what the line height should be.

It's just done.

Create a color palette [SOUND] and actually stick to it.

This is hugely important.

Because one of the biggest things that we run into, is we are working on a design.

And from one comp to the next, the grey will subtly shift.

And we realize that it was happening in a particular project.

Because, the designer, whenever he needed that grey, would use the Eyedropper tool.

And pull it out of a certain section of somebody's hair.

And that's fine, but we get this subtle variation

in the gray and we don't know, when we're

developing, if that's supposed to be a variation or

if that's just the gray and it should be consistent.

So, what I do that helps me out in a big way is I actually

create a color palette that I stick up in the top left of the page.

That way I can use the Eyedropper tool because it's faster.

And I don't have to, you know, try to remember to pull it out of that

button or pull it out of, you know, of her hat if I need a brown.

I just drop whatever colors I'm gonna use in the design in the top left.

And that's what we do.

that'll, and that's, you can see that sort is a folder called Resources.

And that's just turned off, in the when you

like look at any of the actual layer comps or,

or any of the comps that get sent out,

those little circles up at the top don't show up.

Set typography guidelines this is big.

I think one of the, the consistency issues that I

see most often is that de, za designers, when they're working

with typography will kind of, drag and shift and transform fonts

to fit without wrapping where they don't want them to wrap.

But that creates this huge issue where developers are then trying

to set fonts to 33 pixels here and 45 pixels here

and 37 pixels here and it's really inconsistent and it's almost

guaranteed that at some point the developer's just gonna go, fuck it.

So, you, you know, you wanna make sure that you create your own typography rules.

And, and really stick to them.

So here's an example of one of our internal typography pieces and

this is just, within a comp of one of our sites we have a, a, the typography page.

And that typography page just has the headers

that we're using at the sizes that we're using

them, a block quote styles and then down

towards the bottom of the page you'll see bullets.

We have pull quotes.

We have any of the typographic elements that we're

going to need, they get designed in one place.

And then, if they need to be used in comps,

if we need to show them to the client, then we

will pull these elements out and actually place them rather than

trying to see what'll fit in the space that we have.

We have to work within our own constraints and if we,

if we design something that can be used in where it

needs to be, then we have to actually redesign it in

the typography style guide rather than trying to invent something new.

That'll save you a lot of time and heartache.

The next big thing is attention to details.

So, when you're, when you're talking about details, it's a

lot of, of the same things along the lines of consistency.

But, you know, for example, you want to make sure your measurements are exact.

When you are using a grid system, those grid systems are set up very precisely.

And when you start creating your elements, if

you are dragging those, you know, to whatever

size and then it looks good, but it's at, like 327.85 pixels as opposed to 330.

That is making the developer guess that it's okay for it to be whatever size, It

doesn't take very long, the Transform tool show up right in the top bar of Photoshop.

Just adjust them to nice round numbers.

It'll help you stick to the vertical grid.

It'll help you stick your, your horizontal grid, and

it will make everybody's life just a little bit easier.

And it'll, it'll have that awesome side

effect of making your designs actually look better.

Because when they're perfectly in line with each other, it's just

gonna have a better feel than if they're just barely off.

Design all of the states.

Seriously.

Hover states, active states.

What does it look like if somebody tabs to it?

If there's an error, do we need to highlight it?

Is there an error message?

What's going on there?

Don't let developers guess.

It's a terrible idea.

Make sure that you, if, if it animates, is

there, is there an animation that we need to watch?

Just be as thorough as you possible can.

it, it's, it's one of those things that it, it's totally busy work.

But it's busy work that's gonna pay you off in the long run.

Because if you don't do it know, you're gonna do it

later when you see what the developer makes up on your behalf.

If you have a complex interaction, actually make a demo of it.

And now I don't necessarily mean that you need to somehow become an animator or

learn how to code so that you can build a demo of this, this interaction.

What I mean is, if you see something happening, you're gonna remove

or add an element to a page and you, you see an animation.

Or you're going to have a hover state,

where additional information slides in from the bottom.

If that's gonna happen, draw it on a napkin.

Draw me a stick figure.

Do anything to explain to me that, that's going to happen.

Because if you show me the off state and the on state with no description

of what happens in-between, I can tell you what's going to happen with the developer.

It's going to be a snap from the off-state to the on-state and back.

So, if you see an animation in your head, draw it out.

Draw me a stick figure that's like, here's the

box, here's the arrow coming up, and just say, animate.

And that's all I need.

That's, that tells me enough to know that that's supposed to happen.

And we can at least have a further conversation

if I'm not clear on what's gonna happen from there.

This one is a, really important if you're working with clients.

Especially if these clients are very picky.

Set your font anti-aliasing.

If you're using sharp or crisp, it's going to look thinner in the

comp than it will when it's developed, and then the developers are gonna

be pissed at you because the, the client is going to look at

it and go, we'll why did the fonts look so fat and chunky?

And you're stuck, you know, you, you have no answer

to that unless that font happens to have a lighter weight.

So, make sure that you set Mac LCD and if you, if you have an older

version of Photoshop and you don't have that

anti-aliasing option, use strong because it's the closest.

That will actually render it close enough that clients, only

the pickiest clients will be able to pick out the difference.

Design for high res displays.

I like to I like to design at the exact width of my desktop

because I'm, you know, selfish and I like it to look good for me.

But so what I do is I set the resolution to double 144.

The reason that I do that is so that I can set the fonts in points.

And they won't need to be, you won't have to do math to

figure out what the font sizes are,

because the resolution automatically adjusts point size.

That will it, it's very very easy to de-res a design,

and, you know, take it down to 72 dpi, but it's very, very difficult to upscale.

So, unless you are just given no choice, always do it at

high res because you want the you know, you want the option.

And the last thing that you really wanna do is

to get told, after you've designed it at 72 dpi,

that you now have to create the retina assets and

have to redesign the entire site at the right size.

So, you know, just do it, do it this way,

even if you'll never use it, because there's always the possibility

that down the road somebody's going to go, I just

bought an iPhone and now the, the site looks all pixelly.

Can we fix that?

Organization is another enormous section of of what I think will help out.

How clean are your layers in a Photoshop file?

I

imagine that all of us think they look something like this.

When I hand off a design, I want it to look

like this on the outside and look like this on the inside.

But, up until about a year ago, the layers looked more like that.

Just a disaster.

And, I'm gonna show you, I'm actually picking on one of my other

developers who is not here, our designer, who is not here right now.

This is one of his files.

I dare you to find anything in there.

It's just a nightmare.

I mean, and, and I have, like, I had to open this design two years

later to pull out some elements, and

I spent 45 minutes just trying to understand.

I called him after I opened this file.

We had a talk.

So, name your layers.

Group them logically.

Try to do things that make sense and this is isn't just for the developers.

This is for you.

If you, you know, that, that slide, if you are looking at this.

It doesn't matter if you get that now.

I promise you, after you've done one more project,

you are not gonna remember what goes where in here.

And yeah, you can use the, the the check box to

auto select on click, but that's only gonna get you so far.

Just take them time, name your layers, group them logically.

Look for something, kind, I mean, you don't have to

do it my way, but this, this is my way.

I have each major vertical section broken up into a

folder, and then within those folders I name each piece.

That just helps me and it helps the developers because when they go in and

look at it, the only thing they have to learn is what my naming conventions are.

Okay, main call to action.

All right, that's the big box.

The the video call the action that's ball, shooting

handling all that and, and so on down the page.

So it's, it makes it so that instead of dealing with 150 layers, you're dealing

with the, you know, eight layers within that

one folder, because you know where you are.

And then, within that folder, those layers are named, so that

you're probably only down to like hopefully one thing so it's

very clear what you're working on, or at least just one

or two where you're like, was it that thing or that thing?

it's, it's very, very, very helpful in terms of reduced development time,

this taking the time to organize, as a designer you can do it

on the fly as you're developing an element, just name things get

in the habit of doing it, it's kind of like tying your shoes.

When you first start it, you hate it, you kick him off, you fight your parents.

And then it just becomes a thing that you do

without thinking about it, and you can't imagine not doing it.

So, do it, take the time, build the habit, it's

one of the best habits you can build as a designer.

Another really, really good habit is to start using layer comps.

Who in here uses layer comps.

Is anybody in here not familiar with layer comps at all?

Okay, great.

This is layer comps.

This is one Photoshop document and as you can see it's

just a, a snapshot of the layers in a certain arrangement.

And, you can, you can capture whether or not it's visible.

You can capture it's position on the page.

You can capture, you know, on off states here, the

blog page, blog page selected so that we see hover state.

It gives you the ability to avoid doing the PSD dance

where you've got an individual PSD for each view of the page.

Now, the reason that I like this better than

doing multiple PSDs for comps is because if you've

got a common element, like for example, the header

here is consistent across almost every view in the site.

If I need to change that header, and I've got

15 views, in order to keep things consistent so the

developer doesn't accidentally create the wrong version of the header,

I have to go through 15 PSDs and fix that header.

If I make a change here.

It takes me very little time to go through an update

in my layer comps because the header change has already been made.

I just have to put it back, make sure the

things that are visible are visible and save that layer comp.

It's gonna save you a lot of time.

Developers will be happy too because another really good advantage of this

is as you start developing, you're gonna be turning off type layers.

You're gonna be turning of overlays things that you can build in CSS like

for example these have gradients laid over them that should be built in CSS.

So in order to pull those assets out and add these one you wouldn't.

But if you need to pull assets out that have

a gradient overlaid, you're gonna turn off that layer style.

You're gonna end up hiding elements and all

those things so that you can slice it up.

Now, if you do that and then you forget where you were.

The layer comp has a reset button.

It puts you right back to where you were as opposed to having to

quit the Photoshop document and reopen to revert or to actually just hit the Revert.

This allows you to jump between states and you can save your slices

and if that's something that you're, you know, if you are still slicing.

All those things are super useful on the design and development side.

It'll save you time and revisions as a designer and it'll

save you a bunch of time and slicing as a developer.

Another big one that I've noticed is, remember to make notes about your fonts.

If you use fonts make sure, first of all that those fonts are legal to use.

There's fonts.com, typography.com, Typekit.

A lot of fonts can be purchased as a single license web font.

Make sure that you can actually use the fonts you're designing with in the design.

If you hand a developer a design with fonts that are not legal to embed, well

actually the project manager's gonna kick your ass

but the developers not gonna be very happy either.

So what we do is in the just the readme of a project folder.

We put what the heading font is what the body font is.

If we had a different block quote font, if we had a different pull quote font.

If we had whatever font stack, we would add that as an additional note.

And then we say what the font is and what

weights we use and then where you can embed it from.

So we use fonts.com for a lot of our font embedding.

These are the two fonts that we use in this particular design.

And we used just the regular weight for the headings,

foreweights for the body copy and you know this makes it

so that my developement manager, Drew here sitting in the front

he doesn't have to ask the designer what fonts were used.

He doesn't have to open the Photoshop document and

dig through it to figure out which fonts were used.

And then he misses one because, you know, he didnt open that particular layer comp.

Instead he just looks at this, goes to www.fonts.com, builds the kit,

gets it set up for the developer and the developer hits the ground

running.

Awareness of the process awareness of the people you are working

with and awareness of what you are doing is very very important.

Know the tools that you are gonna be using.

Designers this one is gonna require a little bit of learning on your part.

But if you are working on a team and you have enough

preliminary planning to know when or what its gonna be built in.

So for example, if you are building a site

and you know that it's gonna be built in bootstrap.

If that's just part of the project description

then go out there and look photoshop documents exist

that are complete UI kits every element in bootstrap

has been mocked up as a photoshop element that

you can then use in your mock ups and

only redesign the things you need to redesign buttons,

things like that don't redesign inputs if you don't

have to it is a silly thing to do.

Which brings me to my next point, which is go native

this is one of the biggest points of contention, I think because

it's very much a form over function or vice versa, kind of question.

Select boxes.

In a field like select boxes or something where designers

go I can make that look really nice and developers go.

Damn it.

Because they're one of the hardest things to sell.

It's basically, you don't get to style a Select box.

You have to actually write a JavaScript wrapper or something to sit on top of

it to replace the Select box and then update it, dynamically.

Which makes it a huge pain in the ass,

which means it's gonna take a long time to build.

So, if you have the option, in a design to use native form elements, do it.

If it's not gonna ruin your design use native

form elements, it's gonna make everybody a little bit happier.

If you do need to redesign a form element, make sure that form

element is something vital to the design that's actually adding a lot of value.

For example, if you wanted to have an improved select

box for how to search feature or something along those lines.

That makes sense.

Then it's worth it to go through and go through the pain of redesigning it.

But if all it's going to do is change it from being the native select box

to being a flat bordered select box that

does exactly the same thing as a select box.

You might be wasting time.

So just you know be aware of that.

Be mindful of your blend modes.

It's definitely tempting on the top here, this

is set up with a couple overlay layers

at varying transparencies to get a cool kind

of effect that stands out but blends in well.

At the bottom, that's a little closer to what's actually possible

on the web, that's opacity, we will get there, it's coming.

The spec is in place.

Everybody's trying to move it forward, where

we'll get blending modes on the internet.

There are I think, the Chrome Nightlys allow you to use them

in a certain capacity but it's not gonna be here for a while.

We still have to wait for, like the next six generations

of Internet Explorer before this is gonna actually be production ready.

So in the meantime, anything that's gonna be dynamic text.

Anything that needs to move and interact with other elements on the page.

Unless you've had a very in depth discussion with development

about how it's going to work, don't use blend modes.

Your blend mode options are normal and varying level of transparency.

It sucks, I know, I hate it but it's

unfortunately it's where we are at the state of things.

Laziness is another big problem right now there's a tendency to skip the easy parts.

The problem is the easy parts and the reason that's in

quotes is because the easy parts differ from person to person.

And the easy parts for a designer are usually the hardest parts for a developer.

[BLANK_AUDIO]

Don't make destructive edits this one I think is extremely important, I've

seen it happen a couple times and it always results in tears.

If you are working on an asset, a banner, a header, anything that's

going to be used, don't flatten it and then save that as like the psd.

Save the layers, always save the layers.

Always leave yourself an out to go back.

And this is, I mean, first of all when you've got

developers working with it, there's a chance they're going to need to.

Pull individual elements out, if there's going

to be dynamic text, things like that.

They need to be able to interact with that banner to actually mark it up.

But more importantly, if you flatten an asset, I guarantee, it's like,

you might as well be like

doing everything, walking under ladders and crossing

paths with black cats because as soon as you do that the client's

going to go, I have an idea, I want to change that banner.

So don't do it, just make sure that you leave your layers intact.

If you need a flattened version, save it as an individual file.

Don't ever do edits that are gonna make you go back and do things instead.

Here's some things that will really help.

Use layer masks instead of deletion.

If you are working with a photo and you need it to be

circular or you need it to be trimmed on the top and bottom.

Rather than using the marquee tool selecting

and deleting the parts that you don't

want select the part that you do want, hit that layer mask button at the

bottom and it will be hidden without being gone so that if later the client

decides they want that image to be 200 pixels tall instead of 100 pixels tall.

You are able to go in and delete that layer mask, the photo is fine.

And then you just add a new layer mask.

This is also really helpful when you're dealing with development

because you can do things like adding headers that overlay things

but leaving that image available for the developer to actually put

under it when the development is happening, little things like that.

Use smart objects instead of applied filters,

don't gosh and blurred directly to an image.

Convert it to a smart object and then apply a gosh

and blur and it's something you can toggle on and off.

Great reason for that is because you can now do

blur in the browser in most modern browsers so there's a

good chance that the developer will need to turn that off

so that they can use the browser effects to do that.

There is no reason to destructively edit anything.

Photoshop makes it very easy to not do that.

Again, don't flatten layers.

Be mindful that you are going to have to change it.

And the last thing that I have wanted talk about is communication.

Communication is the hardest part to talk

about because it differs so greatly between teams.

So a lot of times, it just kinda feels like you know, yeah, we are buddies but

I am gonna talk a bunch of shit behind your back when you are not in the room.

And that's you know, that's a problem.

It creates a toxic work environment.

It makes it difficult to have an open conversation with somebody

when you know that they dislike you or dislike your work.

Even if you guys would potentially be best friends outside of the office

in the office, if there's this tension because you know, they feel like

they don't understand why you're so mad at them all the time and

vice versa, it makes it really difficult to ever get anything productive done.

Because you're always kind of walking on eggshells.

So I think the most important thing is to never make assumptions.

Remember you know what you know because you've been doing it

for years and you worked really hard to get good at it.

So if you make an assumption that somebody who's

in a different department is going to understand something that

you inherently know, you're probably going to come off condescending

and you're probably going to leave them in the lurch.

So make sure that you know if going back

to the being complete and designing all of the states.

All those sorts of things you never

wanna let a developer make those design assumptions.

And developer should never assume that designers understand that

you know, what they did won't work in code.

So, you know if you sit down to have a meeting and there's a

prototype that's being built and the designer

goes what'd you do with those hover states?

And the developer goes I don't know.

You didn't give me anything to design.

What you didn't just know that?

And then the developer says well, you knew

that couldn't be developed into code, like, you idiot.

And it's everybody just keeps condescending and weird

and defensive as opposed to saying you know.

Like, oh, this hover state doesn't entirely make

sense to me, can you explain how it works?

Like, yes, of course, that actually doesn't work in code and here's why.

And they go, oh, well let's figure out a way to fix it.

So it's a very minor shift in the way the conversation works.

But instead of going in on the defensive, you go

in on the open and instead of saying, you did a

thing that I can't do, say I'm not sure how

this is supposed to work, can you help me understand it?

It's very subtle but it makes a big difference.

Add notes about everything, this is another

one that has been big for our team.

We all work remotely compter lab is distributed

so we don't ever work in the same

office so we don't get the chance to walk over to someones desk and say hey.

I don't quite understand what you did here.

We have to send a message in Slacker and e-mail.

Some of our guys are in Europe, so if you know, Rob in Scotland is in bed at 4PM my

time, I don't get an answer until I wake up

the next morning, so I'm totally hobbled for the day.

So that's a problem, you know, you wanna make sure that when you're designing.

That you add little notes about things that

could be big deal, like hover states or if

there's a particular interaction, or if you added,

say, like a really subtle hairline border that only

you'll notice but it makes that little bit

of difference, make a note about it because the

developer is not going to notice, oh look there's

a one pixel border that's almost the same color.

They won't do it.

It's just not going to happen so add a note.

What I do is in Photoshop, I'll often add a layer called notes and I'll just

put yellow boxes with type in about like,

what ever the section is that I'm talking about.

I do that, I could do it as a read me, I could do

it as a, I think Skitch is a good tool for adding notations to things.

It's whatever works best for your team.

I put it directly in the Photoshop documents so that when they open it the

notes are right in their face and they can't tell me they forgot to look.

[LAUGH]

If possible, actually get in a room together.

If you can sit down and look at a design and point and

talk about what things you're going to do and how they're going to work.

You're gonna be able to clarify 1000 times faster

than trying to do it via email back and forth.

Or if you can't get into a room together, get on a video chat.

You can use Skype, you can use Talkee.io.

You can use GoToMeeting if you pay for one of this.

And share screens and look at the design together.

Try to get a feel for what it is and how it works.

And barring that, you know, you can at least get on a

call so you can both be looking at it at the same time.

Just try to avoid textual conversations about visual things.

It's a very, it's a difficult process.

[BLANK_AUDIO]

Don't forget, we're all on the same team

here, so when you're struggling with a design.

As a developer you know, when you're looking at

it, going, I hate Steve, he's such a dick.

It's not because Steve didn't want this to be a fun project for you.

And it's not because Steve wanted you to fail as a web developer.

He did something that he thought was right.

And if he didn't have enough information or if he

didn't have enough you know, he didn't have enough education

about the code to make an informed design decision and

he left you kinda stuck, that is not his fault.

That's something that you can do to

actually go educate Steve so that Steve can

get a little bit better as a designers and understand more about how the code works.

And that's also something that you can fix.

It's not the end of the world.

It's very rare that something is so bizarre that gets through QA and

final client review that you are literally stuck having to shit a miracle.

Unless it's timeline.

I know that happens all the time.

But you know, I think if we can really just focus

on the communication of really trying to be open and non-combative.

And willing to make everything like a cowork,

as opposed to I am in development, I'm designed.

We don't really get along but sometimes we lobbed grenades at each other.

We can fix the problem, we can you know get

is so that the design and development really get each other.

So to recap here,

try to create good habits, be consistent.

This is kind of the manifesto that I wanted to get this into one sentence.

Two sentences, sorry.

Deliver consistent designs that are fully thought out and

well-organized using the appropriate tools and without getting lazy.

Then, discuss it like besties.

I think that's if you can embody that

as like your mission statement, as a designer.

And if you can understand as a developer that when designers are

working on these tools, none of the decisions they make are malicious.

If they are making malicious decisions that's a

whole different meeting that you need to have.

But it's really you know everybody's working towards the same goal, they

want the best possible outcome, so you know we're trying to create.

Good habits, a good process that can smooth this out and make sure

that everybody on the team has the tools that they need, that they're not

left guessing and that they're able to do the best possible work and also

have a clear channel to come back and say, I'm not sure about this.

Or designers you know, on that same page, I

probably should have talked about this a couple slides ago.

But designers, make sure that when you're designing something, if you

get even the slightest hint that it might not work, go check.

Go check first.

Maybe, even if you don't get the slightest hint that it'll work.

Just walk over to development and be like, hey,

I'm thinking about doing this, is this actually a thing?

It'll save you a bunch of time and it'll make the developers

feel like they've had a little bit of input on the process.

And developer don't abuse that power.

If your designers are willing to come over and ask you for help.

Do not tell them not to do things

that you can totally build because you're feeling lazy.

If you abuse that power you will lose it.

And then we'll be right back where we started.

So that's about the end of what I wanted to talk about.

Does anybody have any questions or.

Really if you have things that you're doing in your workflow that

are good for the design development hand off, that we didn't talk about.

I'd love to hear about those as well.

>> So a lot of these tips

are really, really good when you have the hand off.

>> Hm.

>> But the hand off is kinda dying and people are starting to leave.

>> And how would this work.

>> Like having a [UNKNOWN] having all this past [CROSSTALK] [UNKNOWN].

>> When things are changing everyday, how do you like, keep up to that?

I mean, the style guide doesn't really go out of style,

whether it's designed in Photoshop or whether it's designed in the browser.

Having a clear definition of like you know you could do this with modular design.

Where if you were building in the browser you can build components

out as a designer that can then be pulled across by the

developer with clear rules and a clear communication you know the same

general process of handoff but it doesn't matter what your tools are.

Making sure that what you deliver is consistent and that what you know, what is

going across is clearly communicated, easy to execute and consistent in all cases.

You know, that's, that's kind of the overarching

point is just to make sure that you're

never handing somebody that they look at and go, I'm not, I'm like 80% on this.

You want them to be at least 95 and let them come to you for the other 5%.

>> Part of the lead process is not to go to that part, like go to 10%.

>> Just do something, test it, if it's not working, go back and try again.

>> So, you can do things like [INAUDIBLE] and size [INAUDIBLE] [COUGH].

>> My change from day to day.

Well and if that's the case I mean that'll probably

put developers and designers in a much closer work environment.

so if that's the case I mean they'll kinda be solving those

problems anyways by being in a room working on things, like together.

So I'm not sure that this process would really apply there.

But the principles of communication and you know, keeping

everything clear are, they're gonna be pretty similar just

in you know but that'll be environmentally facilitated as

opposed to actually trying to put any processes in place.

Did I see, yeah.

>> [INAUDIBLE].

>> Mm.

>> [INAUDIBLE].

>> I think we're just exploring [INAUDIBLE] if it's going to be

good or bad, I'm wondering if you have the [INAUDIBLE] experiences with that?

We tried having our designers cut out the

PSD's and create individual assets instead of you know

because a lot of the designs we're doing, we're

on board, we bought, we drank the flat Kool-Aid.

So a lot of our designs have a lot of,

you know, boxes and empty space that are CSS buildable.

So we tried having them do just the headers and the individual banners and

committing those are not committing them but

you know, giving them to the developer.

But we ran into was that, they didn't

understand slicing, and so when they were like trying

to, to build things out, they would cut

them weird or they wouldn't be able, they, they,

they would like not optimize the images, they

or they were just a handful of issues that

we ran into where it ultimately turned out to be faster for the developers to do it.

I don't, but I think that's a team by team thing.

If you've got a more savvy design

team that's, that understands, like, compressing for the

web and you know, removing metadata, and the things that, that will bloat an image.

That could, it could definitely be something that would work out.

I think it would just take experimentation and seeing

if it's actually saving time, or if it's one

of those things that you thought would save time

but you're actually spending an extra day on it.

>> You mentioned identifying all the actions [INAUDIBLE] do you think it's best

to have those directly in the site's PSP or in the developer's style guide.

>> Yeah, I am a big fan of having a layer comp that has things like elements.

So that that way you're not having to design.

Four layer comps of like, you know, the contact form with like

a error state, an active state and a filled state and all that.

I mean you can just create your elements and

here's the input, here are the four states below it.

I think that's a little faster, especially when

you're dealing with a large number of components.

It really just comes down to, again, you know, what.

What the PSD requires.

If you're doing a simple site that has one form, and that form has four

states, it might make sense to just whip it out as a, as a layer comp.

But you know, it, it really just kinda

comes down to what works best for the project.

>> Yeah, it's tough cuz in my agency, we go

through this constant internal battle of do we use layer comps?

Do we not use layer comps?

Because it's not everyone knows how to use layer comps.

That alone has hurt them.

>> Mm-hm.

>> So it's really hard to get the whole

agency on board with using something that's so unfamiliar.

>> Yeah.

>> So identifying stuff like you know the active states and stuff like that.

Can get a little tricky.

>> Yeah, I if your not using layer pumps

than I would do a separate document it, yeah.

Cuz that just seems like it, it cause then

you can just give You know, a style guide or

a components guide to the developer, as opposed to

making them open four PSDs to see four different states.

yeah, I don't know.

I mean I, I would be evangelizing for, for

layer comps if I was in your shoes, though.

[INAUDIBLE].

>> Uh-huh.

[INAUDIBLE].

>> Uh-huh.

[INAUDIBLE]

>> Oh.

[UNKNOWN] >> Yeah, that sounds familiar.

[LAUGH] >> So I'm having a real difficult time

in learning what to ask for and how to [UNKNOWN]

>> I think something that you, the question was,

That shes having issues getting apps that are usable.

It's PDF or an in design file.

When your going into contract I, I like to set the expectation's super clearly.

We write for all of our clients we write out, it's like a 900

word project kick off agreement that says these are the things you're going to do.

If you don't do any of those things, your either going

to forfeit 20% of your deposit or there going to fire you.

Or your going to pay us more money to fix the project later.

So we every time that something like that happens and we get a

file that doesn't work we, we just have to add more things to the

kick off agreement that say you know, if you give us something that we

have to then reverse engineer and redesign we're gonna charge you for those hours.

So I, I mean if one thing that you could do is maybe build a, a sample psd.

That you send out, and say like, this is what I

would, I would love to get, is something organized like this.

Or just you know, mention in, in part of your

terms that, the, the quoting price is for a layered Photoshop

document or a layer of Photoshop or Sketch or Illustrator,

something that you can actually get in, and, and work with.

And if they send you a PDF, that, that's gonna

be outside of the scope, and you'll have to quote accordingly.

I mean, unfortunately, you, you're going to have a hard

time changing an agency's mind on how they deliver files.

So, the only thing you can do is financially cover your ass.

Did you have a question back here?

[INAUDIBLE].

>> You know, I'm the wrong guy to ask about this.

Because I have a full on scorched earth policy with Internet Explorer.

We guy back to eight, and all we do in eight is make sure things are clickable.

we, cuz in nine plus things tend to look pretty good.

Eight it's probably about 90% of the way there, and as long

as things aren't laid on top of each other, we don't care.

We're not, we're not working with corporate client that have large

Internet Explorer bases, so for us we can get away with that.

You would have to kinda weigh out on an individual basis.

If you're working with a client where.

Internet Explorer 7 or 8 compatibility is high on their priority list.

Then, yeah, it would probably make sense to, to actually design that and make

sure that the developers know they need to create a, a specific IE style sheet.

But if you have the option not to.

I tend to just let the browsers do what they do.

Like rounded corners?

Who cares?

If somebody's on Internet Explorer 8 they're

probably used to the internet looking like

shit, so it's, its not a big deal if the, the rounded corners don't work.

So another question over here, I think?

No?

Okay?

Oh, yeah, go ahead.

>> You talked about not starting from scratch.

And like using the same system using perhaps [COUGH] Bootstrap setup.

[INAUDIBLE] more and more the same or is it like high level?

>> It's super high level.

It's basically a the grid system is.

Our grid system, what we start with, is a

vertical grid and a horizontal grid set up as guides.

And that's effectively it.

we, we don't have any like, common components that we pull across.

Our, our topography guide is set up but we, we

go in and actually change all the typography every time.

We just don't want to have to type out all of that.

We have a couple common elements like, we, we frequently build on Bootstraps.

So we have like Bootstraps pagination, as an element that we pull in.

And we have you know the, the four elements that

we can pull in and, and drop on a design.

But know 98% of every design that we do, is, is custom design.

But the things that are a pain in the ass.

We just, you know, we just skip them.

Because there not important.

we, sorry we don't skip them, we reuse them because they,

it's not something that's going to make or break a design.

And nobody going to look at like, like the pagination.

I mean, well developers will look at the pagination and go Bootstrap.

But you know, it's.

I don't care.

I, if you, if you know that we built a site

on Bootstrap because of the pagination, good for you, you're a nerd.

[LAUGH] but like it, it doesn't really impact the actual aesthetic of the site.

It's it's you know, so, we, we only non, non-vital elements we'll reuse, but almost

everything is redesigned because we, we do wanna avoid the sites looking the same.

>> [UNKNOWN] So no offence, but

[UNKNOWN] [LAUGH] and were using

things because [UNKNOWN].

>> So okay.

So, the, the, question was, how do you undiva designers?

I, I think you, your best bet is to is to start work on your wishing ability.

But more importantly I think, one of the things that,

that has really helped us is, we got management behind it.

well, when I say we got management, I mean I'm management, I got behind it.

But [LAUGH].

But, I, I started enforcing it, in order

to invoice all, all of our designers are subcontractors.

In order to invoice for the work, files needed to conform to certain things.

So, we, we just did top down on that.

It was kind of, you know, like brutal viking burn the village

takeover when we did it, but once it happened everybody's happier now.

Because now if the designer is working on something and they go out of town or

get sick, we can hand it to another

designer and it's familiar when they walk into it.

They know the grid system.

They know, you know, roughly how things are going to be built out.

They know what's on a vertical grid.

So, they're not guessing.

They're not, you know, it's, it's definitely a designer taking

another designer's work and, and trying to build on it.

But it's not trying to figure out you know why did they use

these eighteen shades of grey the consistence

gets mixed up and that makes it

easier for designers to work with each others work and it also you

know, you, you build habits where you just start doing this stuff by default.

The, the reason that the designers you know speaking from my own experience.

The reason that I do most of the things that I do

in designs is because those are the things that I've learned to do.

It's not, you know, I'm, I'm always out looking for new ideas

and I'm always out looking for something exciting to try on a site.

But, 90% of a site is structural, and so when I'm designing it.

I'm doing the things that I know work.

I mean, using typography rules that I know work.

I'm using color schemes that I know work.

So all that I need to do with that grid

system is make that the thing that I know works.

I know I can make a beautiful design on the Bootstrap grid system.

And it doesn't have to look like, you know, a standard Bootstrap component.

So I think it's just, it's a, a matter of, of

kind of cheerleading the idea of a unified approach, you know?

One of us.

You can, you can do that.

Get people excited about, about the ease of having a system.

Processes are weird, you know, when you're dealing with, especially with artists.

Trying to get them to follow a process can be like pulling teeth.

But, if you can evangelize that and you can show them the value of it whether

it's by getting management to cheer lead and,

and kind of force that down, or whether

that's by working with the designers one by

one on individual projects and showing them the

value of, of following some conventions you'll probably

change a lot of minds, I mean not everybody.

Because you are always gonna have somebody who doesn't wanna follow the

rules, but, y, you know, if, if you can get at least the

majority of people, you can switch pressure in the other direction to where

now the other designers are looking at him like hey maybe fix this.

Maybe do things differently.

Okay.

I'm out of time.

So I've gotta go.

Thanks guys, so much.

[APPLAUSE]