[MUSIC]

[SOUND] Cool.

I am really embracing the Vegas, so I am dressed accordingly.

Cuz Vegas is really fun and sparkly.

Like Elias said, my name Katie Kavalson.

I am a designer at Sparkbox based out of Dayton, Ohio.

And today I'm gonna talk about collaboration,

which is like this magical buzzword that everybody's always talking about

that's gonna fix all of our problems.

But why is it this magical buzzword that's gonna fix all of our problems?

And to think about that gonna take a little history lesson and

talk about Bill Bernbach.

He was a art director in an advertising agency in the 1940s and

he worked at Grey Advertising.

Where they did a pretty traditional advertising structure, where

the copywriter would write all of the copy and then walk it down to the hall, and

put it on the art director's desk, who would then lay it out.

And the results were pretty boring and uninspired layouts,

of just like an image and the text, and that was that.

And he wanted to do things differently.

He left there and formed Doyle, Dane, Bernbach or

DDB and wanted to take this approach with creative teams.

This was his team, and it consisted of an art director and

a copy writer working together from the beginning.

To come up with ideas and he called them creative teams, and

it totally revolutionized the advertising industry and

the results were impressive pieces like this.

Where the words and the imagery work

together to deliver really a powerful message, like the, Think small, campaign.

It's interesting to me that in 2015 we're still kind of

making those same early advertising industry mistakes.

Where designers are kind of working on things

in their own little silo and making a nice picture of the website.

And then walking down the hall and

putting it in developer's desk and saying, here, build it.

And that just Isn't really working to produce some inspiring results.

And we're also holding everything on the project to this picture of a website,

and not an actual living, breathing, in-browser experience that is a website.

So it's interesting that we get signoff and approval and

everything on JPEGs of a website, and not actual live code that is

much more realistic to what the website is going to look like.

And also, we feel sometimes like we're making the same website,

likw two, three, even four times between doing the wireframing and

then doing the mockups, and then the code, and maybe prototyping.

We're rebuilding the same thing a lot of times,

rather than just working towards that one end goal experience.

So working this way, just like in advertising industry,

something has to give.

And It's usually gonna be the budget or timeline.

We're gonna run out of those, or money.

But ultimately our creative iterations and

our sanity of wanting to create these really great experiences.

So I think it would be great if we start to think and

function the work in relationship between designers and

developers to function more like those creative teams.

Because ultimately again the more realistic expectations can be met in

the browser, when we serve the client's actual coded designs in the browser,

and tweek the feedback accordingly rather than tweaking a picture of a website.

And you might be sitting there like, yeah, duh.

Developers have been trying to design and code in the browser for years.

I design using CSS.

But I think a really important caveat is to let the designers

design in whatever method they are most comfortable in.

At least for a little bit.

Whether that's Photoshop or Sketch or whatever.

I think we're pretty quick to shame designers for using it.

I feel guilty for still using Photoshop sometimes, but

that's what's most comfortable for my creative expression.

And I think we need to just accept that that's okay to a point.

We're also really quick to tell designers that they need to learn to code, and

not necessarily the reverse, that developers need to learn some design.

I wrote an article about this earlier this year, about

expanding skill sets to kind of bridge the gap and work better together as a team.

Not just designers learning to code, but developers learning some design as well.

So if we kind of think of skill sets as being this spectrum of, let's say,

design being this pink color, and back-end being that blue color,

and front-end being the purple in between.

I'm probably somewhere around here, where just purely design,

a little bit of front-end.

And if I were working with a back-end developer who

just was in that blue area and dabbled a little bit in front-end, but

wasn't really comfortable in it, we have a gap then, in the middle.

And that needs to be filled somehow for us to properly communicate and

work effectively together.

So aside from adding a third person to the team,

one way that we could get around that and have better conversations,

is by me learning a little bit more front-end and my team mate also learning

a little bit more front-end so that we kinda cover all of our bases there.

I think another really great way to work better together is to have

designers work in the developer build tools.

S-V-Gee is a really great example of this.

I worked on my website with Chris Coyier and he showed

me really great things that we could do with S-V-Gee's that I had no idea.

I thought that this was just a technical thing that developers could do.

It's just a file format.

I didn't know that there was so much cool things that I, as I designer,

could be build around for something that I thought was technical like SPG.

Until a developer showed me, and said,

hey we can animate these, we can do cool things on hover, and I was like, oh yeah.

I'm all about that, so we built it using.

Jackal, and there was a Grunt file, which I'm not technical, but I know enough to go

in Terminal and type a couple words, like grunt serve, and grunt, and then run that,

and then some magical stuff, that I don't really understand, happens.

But, a developer wrote that, knowing my needs, so

that I can just quickly go in and see, make a little change.

Let's say I wanna change that word from design to Not design and

then I hit save and it updates.

And we're working together in the same tools,

cuz ultimately what we're building is in the browser or website, so

our tools to be comfortable reflecting that and then we're working together

in the actual same environment and cool things will happen then.

And it's also important for

designers to explain their design decisions to the developers.

A lot of times I think in my head, this is a very obvious layout.

My grid is so obvious.

This is lined up with this.

And that's not usually the case.

Some developers overlook a lot of those things because they don't

have that trained design eye.

So, we can work together to bridge that gap, by explaining those design decisions.

This is a design that I'm gonna get to here in a little bit.

But the tablet experience was so important, and so that

there's a completely different typographic scale at the tablet experience.

And to the developer, that might not be so obvious, that there was just a little bit

of shift in the line height and the scale and everything.

That's something to explain, and explain the reasoning, and how we tested it,

and arrived at the solution.

And that will help the developers to understand and

make better design decisions as well.

Ultimately, it takes two skill sets to create a really

wonderful pattern library and extendable design system.

That doesn't necessarily mean two different people.

If you're one of those superhumans that possesses both of those skillsets,

that's awesome.

But we wanna work together to be these cool little emoji girls and

deliver an awesome design system together.

I think that Dave Rupert really puts it best when he describes these

pattern libraries as being like tiny bootstraps for every client.

They're these custom frameworks that we build for them,

that they can then plug and play and pull together to use and

extend what we build for them, rather than us just handing them some pages.

At my last job at Happy Cog, this was what we used to use, a pattern library,

and we built it ourself and it it housed, you can see like the wire frames and

the mockups and the code, and also all the other project stuff.

And it was based largely on Brad Frost's atomic design principle,

where we have the atoms being like the smallest elements on the page.

Like a button.

Then we put a couple of atoms together to make a molecule and so on and so

forth until we get the full pages.

From there, built pattern lab which is kind of the framework built around

that atom design principle, where you can build your modular code together in there.

And this is kinda what it looks like just with the Lorem ipsum and

generic images and stuff.

Back to the one that we built, you can see that it has the same principals of

the biggest six building it together [INAUDIBLE] the fragments.

Then we have the layouts with the full pages.

Sparkbox, this is one that's just simple.

You can just have a simple list linking to the different patterns.

It doesn't even need to be as complex of a project tub as the previous one.

So, to kind of demonstrate a good working style together between the designers and

developers, I'm going to walk through a couple different projects that I've worked

on, and sort of the wins that we saw along the way working closely together.

So, this is a site that I wish existed.

I wish that there was a wholesale skull and crystal distributor, but there's not.

This is actually a real client project, but I can't talk about the actual client.

So, I swapped out the content to be things that I like.

But, the process is still the same.

And, I'm also gonna walk through what Sparkbox and

CodePen have done working together to re-design CodePen.

We're still in the middle of that, but we're still designing that in the open.

So you're gonna talk about some of the things that we've done working closely

with their team.

I think the most important thing is having everybody involved from day one.

I don't like to design without knowing what developer I can have

on hand to talk to and answer questions for me.

And I think it's important for the developer to be kept

up to speed from the beginning on how we've arrived at certain design decisions.

And we can also start from the beginning creating goals together.

If we want to try and do something like a performance budget,

which talked about earlier and it was really an amazing talk.

We can establish that together before design, so

that we're not at the end scrambling to kind of retrofit these goals

into a design that wasn't meant to house them.

And if we have different ideas about how we want to prototype,

different parts of the sight,

we can talk about that from the beginning before we ever even start design.

Because how many times do developers have in their head,

I want to try to this really cool technology or framework, or plugin.

There's these things that I want to try.

But that's not ever voiced to the team.

And then they get really frustrated that, oh I'm handed this design that I

can't do all the cool things that I wanted to try on, again.

But if that were brought up in the beginning we could say, yeah, great idea,

let's figure out a way to make that happen.

So this is kind of like a typical project timeline working together,

where as design's ramping up, development is sort of checking in.

And then as development is ramping up, design is tapering off, but

still involved.

A lot of really great conversations happen in this part.

Where the developer is involved in the design reviews and looking at it and

pointing out any red flags or things that they don't necessarily agree with,

or if it would be difficult to build, and things like that.

We can sketch out different solutions.

I worked with a really great developer who was so good at sketching out ideas on

the fly, and saying I'm not sure about that pattern or that interaction.

And then we would just whiteboard it together.

And they were always amazing ideas,

coming from someone who wasn't a quote unquote designer.

And I've also had project managers who have really great ideas.

It doesn't need to be this ego thing,

where just the designer has all the ideas and has the final say.

We can have some really great conversations in these design

reviews with the entire team.

It's also really important to educate the client from the beginning.

We're pretty quick to complain about clients in our industry, and

I don't like that, because when the client is being a quote unquote bad client,

or not letting us do the things we wanna do.

It's cuz we didn't properly educate them from the beginning

to tell them why they should care about that, and how we're going to build it.

And all of the conversations that we wanna have, like we're gonna build you

this pattern library, we're gonna deliver our designs and code, all of that

conversation needs to happen at the very beginning when sales is talking to them.

We don't want it to be at the end of development and we're like, whelp, we're

gonna deliver you this code this way and they're like, where did that come from?

We don't understand it.

It's gonna be really frustrating.

So, the sales conversation is so important to setting up the foundation for

the team's success.

The setting up the expectations.

The quote unquote Coven Project we set up

those expectations from the beginning that you have gone through a redesign before.

You are used to seeing typical mock ups, a bunch of mock up and

approving those before we build it.

But we don't wanna build it that way because of these reasons, and we're gonna

start showing you designs and code a lot earlier than you're probably used to.

And they were on board.

They got it because we set that expectation from the beginning.

And we also wanna use the same language.

A lot of times a word like template can mean

vastly different things to different people.

And I've even had clients call the hamburger icon the basement.

That's fine if that's what they learned but

that means something different to everybody.

So we should probably talk about that at the beginning and say, hey,

when we say this word, we mean this.

And then we can all speak the same language.

Now we're gonna move into establishing the design direction,

which I tend to still do statically.

That's again just how I can make design decisions the best.

And I think a lot of times people also are quick to

figure out the wire frames first before moving on to the visual design?

And I think that they can be done simultaneously,

because they are separate pieces.

So what I like to do while working on wireframes is do something like an element

collage, which is this idea that

Dan Mall has coined where it's literally a collage of elements.

It looks like pieces of an actual page, but

it's not the full page, it doesn't include the layout.

And it also helps because a lot of times clients get really hung up at the content

of the design more so than the design itself and

they're like, can we change that word?

Yes we can change the word, but what about the aesthetic.

You can quickly knock out several different aesthetics.

And this is for same client, and you can see how the different

directions that these could take, and each of these took less than a day to do.

It's a really great way to get out that aesthetic.

This is the one we did for CodePen which is pretty bare bones.

We just wanted to figure out how we can elevate the type styles and

make more sense of the colors and thing like that.

So it can be as kind of quick as you need it to be to get your ideas out.

And, from there, once we sort of get the approval like,

yes that's a good direction, let's see what you come up with.

We could then move into the full page of combining

the wireframe sort of with that element collage.

Again, this can be static.

This is the one that I came up with that coven design where

also figuring the tablet layout simultaneously.

You can see getting some quick type styles out, the layout and everything else.

And then just wanting to hear that, okay, yeah go on from the client.

And when starting design from the page,

I like to think of the epicenter design principles.

Which is kind of thinking of the true, main piece of that page,

and making sure that we really nail that before figuring out the rest of the page.

And this plays nicely with things like the pattern library and

atomic design of building out.

In the example of CodePen, what's more important to CodePen than the pens?

That is what their entire product hinges on.

We designed the pen first and really made sure we got pen the looking right and

looking the way we want to, before then moving on to say, a collection of pens.

And what do six of those pens look like together,

and then kind of adjusting the design accordingly.

Okay, now that we have a group of them, okay,

let's switch some of the elements around.

And then from there we can add in the rest of the page.

What's down below, what that sidebar is looking like.

And so you can see how we build out from what's really important on that page.

And in this step I also like to think of more

realistic fidelity than being the pixel perfect comp.

So you can see on CodePen, this is just a lot of copy and

pasting of the same content, the same image.

But you get the picture, you get the layout.

And that's pretty easy to communicate, just like, yeah, it's a white box, but

it will be something.

And it communicates well enough to the client that they can say, yeah I get it,

I like where this is going.

Or, Maybe we want to shift that element around on the page.

And we're not wasting a lot of time perfecting this picture of the website,

because all of those details of polishing, we'll get to in the browser.

And I also at this stage,

like to keep sort of a blank document open that I can copy and

paste all my styles against to make sure that I'm not getting unruly with them.

So this is the one I had working for CodePen.

And you can see by doing this exercise I can see that the recent activity

in my recent pens are like almost the same style, but not quite the same style.

And I should probably condense those,

because I don't have a real reason to have those be slightly different.

Or if they do need to be different then maybe I should drive those further apart.

So it's a really great way to keep track of the styles that will then

help inform our pattern library that we're building.

And a tip that I really like for delivering these static markups

early on is to get the client comfortable with viewing things in the browser, and

this will help prime them for

looking at our designs when they are coded in the next step.

But to put the JPEG centered, just really quick HTML and

CSS, just centering the JPEG.

And you can see here in the mockup, that's just a JPEG in the center.

And then we take a one pixel repeating background, and repeat that behind it.

And that helps the client to feel what the site looks like in the browser.

And again, that will make that transition to the coded design a lot easier.

But yeah, that's just an image.

So, from there, it's really great to start with this style guide of

just kind of outlining those key patterns that we've been working on.

So, for CodePen, they didn't actually have one documented anywhere.

And they're, obviously, hip developers that understand these things.

So, this was rare luxury that we were able to have the client quickly come up with

the design patterns on the fly.

But so, they made this page in a day, and we're just, yep,

here's all of our patterns.

That was a really great starting place for

us to begin thinking about the design system and

what we needed to cover based on their style guide.

And this is again, back to that repo that we had at Happy Cog.

You can see we have the typography as the basic elements and icons and buttons and

things like that.

So, it can kind of be as complex or simple as you need it to be.

And it just has quick little bits of code in there to talk about what it is,

and buttons and fields.

Again, they're just building on each other.

So, once we're sort of like simultaneously figuring out the style guide, and

we're working on getting our design nailed down.

And now we've shown the client, and we got their feedback.

This is a really important step in sort of evaluating how close we got

to not having to make a ton of different changes.

So, the feedback that we got from this was that that sidebar,

they felt that the My Orders headline was running into the important news

section a little too closely, so they wanted that to be separate.

They wanted us to work on this hero area and

figure out how that looks a little bit more.

And they also wanted us to just add a line to those specials and

closeouts to include a little tagline about the reduced price.

And that was it.

And that seemed like those were simple enough changes that it would be faster for

us to make those in code than to do another Photoshop mock up.

So, once you kind of feel that balance, we're almost there.

That's when we can kind of then move to the browser and

make those iterations there.

And this is kind of where it really starts to get good,

now that we're getting into the browser.

The very next deliverable that we did for

that Coven project was showing them that homepage as code.

And this was really interesting for us.

This was the first time that my team had done that.

And the feedback that we got was about interactions and stuff, and

we're like, oh no.

It's not about the design.

And then, a light bulb went off, like, oh no.

This all design.

So, it was really awesome that we got to think about this stuff really early on.

We were able to catch these drop downs.

And you can see that there's some subtle animations to the arrows and icons and

things like that.

All of these things that usually get overlooked or wait until the end,

until development is starting.

We were able to catch that by the second design deliverable, and it was great.

And the client was able to really feel what the design was looking like.

And all of these iterations we're caught so

early on that normally would be tracked as bugs at the end.

So, for example, the My Watched items.

We didn't even think about how to unwatch them.

But the client seeing it in a browser and clicking things, they were like, oh,

how would you do that?

And we were like, oh, yeah, we totally glossed over that.

Let's figure that out.

And we were able to just flop that into that design really easily and

catch that early on.

The next step then is smoothing out and

really finessing our designs by working together,

by paring, as well call it at Sparkbox.

How we like to do it at Sparkbox,

is we have the designer with their laptop pulled up.

We have sketchpad because we're probably going to try

to sketch out some ideas together.

Different devices that we want to test on and address.

I guess, sorry I thought there was another one.

Whoops.

Got it.

So, back to the Coven project.

For example, like graying out the other tabs.

That was something that we figured out,

sort of just sitting together like, oh, yeah.

Let's try to really, subtly elevate all of these things and

figured out, like oh, your messages.

We can add a little bounce.

And this was just me sitting with the developer for maybe like an hour, and

sort of just smoothing out all these interactions.

And again for thinking back, this is the second design deliverable.

This isn't at the end just like trying to burn some hours while also addressing

bugs, because a lot of times clients are really quick to say, oh,

the model didn't close when I clicked in the gray area.

I have to click the X.

Can we fix that?

I want it to close when I click in the gray area.

And they track it as a bug and

we're trying to do all of the other actual bugs and not address all of these things.

So, it's important to recognize that these are design iterations.

That's part of the design, and the designed experience.

That's not a bug.

It's not broken that it didn't do that.

That's just a preference in a way that you wish it were designed, so

those should be caught in design.

And, we also wanna make sure that we are documenting all of our code that we

are building, and making sure that it's modular and extensible.

So, if we go back to this one, we have our homepage.

We can click in, see the footer, and that's all the live working code.

And you can interact with it and see all the hover states and everything.

We can also dig down into the stories, and you can see that's all that's there.

Here's the code that the client can then,

if they made a new page where they wanted this module, copy and paste that over.

And then, we can also click down and see what makes up that.

Oh, okay it makes one news item.

So then, you can see how just one of those components work together.

So, we're kinda just drilling down and seeing how it builds on top of each other.

And I think, mail trim does a really awesome job at documenting.

They have all these notes over there next to the code.

And sometimes, we've even done like videos for clients,

if it's a really intense piece of code that they need to implement.

So, you want to make sure that you document everything and

educate the client again ongoing, so that we can set them up for

success for them to maintain this once the engagement is over.

And this is kind of the step that gets like a little wishy washy, where,

I don't have a good answer other than just really be fluid and

work closely with your teammates to iterate back and forth and

kind of see what you need to figure out next.

So, this was the next page that the client wanted us to design,

like a search results ending page, and back to the realistic fidelity.

This is just a screenshot that I took of the other page.

It's the same exact module.

I didn't need to redesign it or touch it or do anything.

This is, obviously, the same header that is on all of the other pages, so

I didn't really need to redesign that either.

So, all I needed to do on this next design deliverable was the sidebar filter and

also the tags and breadcrumbs and stuff.

So, that's all that the developer was like, yeah,

that's all that I need from you.

So, I was able to really quickly just design those up, and

throw them over slack, and then we could jump into code.

And then from there, now the client can interact with that actual filter,

see how those tags are popping up.

In this next design deliverable, they didn't even see that static mock up.

And then, they requested that the filter be sticky, so that was really easy for

us to just throw in there once they saw the code live and we're playing with it.

And then, if we go back to our pattern library, we can see what makes it up.

Again, those articles, and then, oh, here's the filter that we just added,

how to implement it, documenting how it works.

And again, all of that is just living in the same place that we've been using

the whole project.

So, back to my site, this was another page I mocked up.

But at this point, I was deciding,

I don't know if I'm really digging my color scheme.

I kind of just chose some colors I liked,

I don't know if they're necessarily working together.

So, I tried playing around with some different colors.

I wanted to see if I could make pink and blue and red work.

I don't know, for whatever reason.

And then, funny enough, just trying to iterate on this,

I was watching Cool Runnings.

[LAUGH] And the opening titles, I don't know, I just thought they had a lot

of energy and cool, and a really interesting color scheme.

And so then, I settled on these colors, which are not directly Cool Runnings

colors, but i don't know, they were definitely inspired by Cool Runnings.

And because I was used to working in those same build tools,

and updating the developer environment and just kind of talking back and forth and

stuff, I really quickly could just go in there and

play around with all these colors on the actual live code.

And that's like a really empowering thing for

a designer to be able to do is do the design explorations on the actual site,

and I think that that is really cool.

And the most important thing, obviously,

as we talk about collaboration is to just have really good communication.

Not just with our team, but with the client team as well,

and make sure that we are communicating every step of the way what we're doing and

why, and to be able to, again, catch those iterations and things.

So, at Sparkbox, we have weekly check-ins with our clients,

where that's just a standing meeting every week,

where we just talk about what we did for that week, and working this way.

Dan Mald says, he likes to think of it as just saying, go on.

We're just going to keep working, keep plugging away, keep iterating on things

until the client tells us to stop because somewhere we made a wrong turn.

So, I think this is a really good way to think of working is to not have these

rigid approvals, if you can.

Again that goes back to setting expectations really early with a client,

but working in this way of just, we're gonna keep working at this end goal,

that is the finished website, until you tell us to stop.

So, by now, we have set a pretty nice foundation in the design for

the developer to then take and extend it.

And we can work really nicely together to just figure out where those holes are,

where we need to fill them, where I need to jump in and design, where it

might be in Photoshop, it might be in code, it could be all over the place.

And I highly recommend seeing Sophie Shepherd's talk tomorrow where she talks

about pattern libraries and how she builds them as well.

[SOUND] So, going back to Bill Bernbach, this was a quote that I really liked

by him, let us prove to the world that good taste, good art, and

good writing can be good selling.

I think, if he made websites today, he would say that it's good design,

good code and good content that can be good selling, because, if we look,

when we don't talk to each other and don't collaborate, we can have pretty

uninspiring and boring results of giant images with a lot of boring text.

And our websites can start to look the same way with just having giant,

boring images with a lot of boring text.

And let's work together,

let creative teams to deliver some more inspiring results.

Thank you.

[APPLAUSE]

[MUSIC]