So, if anyone does client work

you'll know that we often times can't talk about it.

So while I would love there to be a wholesale skull and

crystal distributer, this is not.

This is the actual page layout in site.

But, for the integrity of the client, I've swapped out the content to

be New Orleans themed and spooky CSS Stub comp stuff.

So, we're gonna walk through how we made this site, with New Orleans in mind.

It starts with everybody being involved from day one.

It super, super important to have everybody talking about this

stuff together.

Like, the back end developer is usually the last person to touch the site.

And we want them sitting down with the content strategists at the beginning of

the site, figuring out how they're gonna build that CMS in the end.

And we want the front end person talking to the designer about ideas.

we, we just want everybody to know what's going on throughout the whole project.

We want to create goals together so

that we can objectively compromise on them moving forward.

Something like a performance budget where we set the goal for

how lite we want our pages to be in the site overall.

We wanna set that in the beginning together.

Because if a developer sees something like a performance budget or

this really cool technology or idea they wanna try, that's awesome.

That's great, but if the rest of your team is not on board or aware of it,

you're gonna get really frustrated.

Because, say, you just have this idea in your head like, I'm

going to meet this number in my head, I'm gonna set a performance budget to myself.

Well, if the designer isn't aware of that and they hand you a page that's like, for

whatever reason, 4 carousels in 12 font-weights,

you're gonna be really upset trying to retrofit that into your budget.

So if we can set something like this together from the beginning, then,

when the designer comes to you with a million carousels and plot weights,

you can go, that's going to blow our budget out of the water, and

then we can try to compromise and resolve that together.

We also need to educate the client from the beginning.

Believe it or

not, clients do not make websites every day, and that's why they hire us.

So, we can use this to our advantage.

What we might think is a typical deliverable of,

okay, we send them a Photoshop document and

then we code it up and then like, that's just how websites are made.

We can just educate them from the beginning on what to expect.

At Happy Cog, we sort of tell the client upfront, like

we don't really know what the deliverables are gonna be until we get to know you and

your team and the problem we're trying to solve.

So, we can say things like, yeah,

we're going to do some preliminary design work that's static.

And then we're gonna move right into code and you're gonna see some design as code.

And just setting that groundwork to be able to sort of

be flexible with our deliverables.

So we wanna be really upfront with them and be able to get them on board and

excited about these things.

We even show that project hub at kickoff and

say, this is what we're gonna be delivering your stuff in, and

get their development team really excited to see things out that way.

So we just wanna let them know ahead of time to be expecting to see

design as code.

We also wanna make sure that we are using the same words.

Something like template means a hundred different things

to a hundred different people.

So we wanna make sure that when I say, here's a template and

they give feedback on a template, that we both are meaning the same thing.

And this is especially important when we start to get into that

pattern library that uses those sort of, arbitrary words.

We wanna make sure that when they give feedback and

we're talking about things that we're meaning the same things.

And we also need to guide their feedback.

It can get really overwhelming for

them if we're like, here's design and design is code.

And they're like, okay, am I like, looking at the code?

Am I looking at the design?

Like, you know, what, what do you want me to look at?

So being really clear, like, we want, design feedback.

But we also need to remember that interactions are design.

Which I'll get in to in a little bit later.

But, we just wanna be clear.

Like, hey, re, we, we have reworked, reworked a, b, c.

And we did x, y, z to resolve that, you know, what, what are you thinking of that?

So just being clear and guiding the client feedback.

So, this is also assuming that, okay, now we've done that preliminary stuff.

We have the whole team on board.

And we've done our research and wire frames and stuff.

And now we're gonna get into actual design.

So, we need to establish our design direction.

For this particular project that I'm walking us through,

the client actually provided the design direction.

They already established, based on their consumer-facing website,

all these design styles.

So that was a really nice luxury.

So that doesn't usually happen,

you usually have to do some sort of style tile or moodboards.

So, since I don't have an example because

the client provided it here's a different example of what I mean.

Where it's just a collage of elements.

And how images can be treated.

And really pushing the brand and seeing, where we can take things.

And I want to try a couple different directions.

Maybe one feels a little more like the brand and

will respond to one a little bit more.

So we wanna just work with the client until it feels right.

And then ultimately after a couple rounds move into some sort of

moodboard that feels more like an actual page.

And what we really wanna get out of this is different UI elements and

those sort of pattern library elements.

We wanna see how they're responding to those, what they're feeling good about.

So in this example they really liked this sort of cut paper feel for

buttons, so we knew that was something that we were going to keep around.

Because the next round, we're going to work on our coded style guide.

So all of those UI elements, when the client is feeling right and

responding well to them, we wanna be able to immediately code those out.

We know we're going to use those, we know we're going to need a button style in

our type style, so we should start coding those now because those will help us

moving forward, having those already laid out.

So what that looks like is, we have all of those basics,

those atoms those very granular things.

The buttons, our icons, our typography, forms.

These are things that we established this early, like right

when we're design concepting and we know the direction that we're heading.

So we can see that there's the code for

them, there, the client team to be able to use and

extend and we know that we're gonna continue to use it throughout our system.

Same with buttons and field set, and

basically all the components that we know every web site is going to have,

we wanna try and style those out now, and prepare ourselves to build on that.

So, like I said,

we still want our designers to design whatever they feel comfortable in.

So, moving into a full page, this will also probably be a static mock-up.

And that is totally fine.

That's totally applicable and not gonna hinder any of this sort of coding it out.

So this is the flat mock-up.

What we do is we like to do like a desktop homepage or

just one page and then do a different device size of like an interior page.

Because we wanna put as much for the client right now as we can,

get a nice wide range of those styles and see again what they respond to.

So we have the desktop homepage.

And then, like I said earlier the tablet experience is really important,

so we have an article tablet page with the different type scale and everything.

So we're able to really push and pull styles see how their working for

different devices and also be able to con, condense them because when, when we

start coding this out then, we'll be able to see where we have duplicate styles.

Because the developer will say, okay which one?

Is it from this page or this page?

And then we'll be able to really condense them and

make a nice clean coded style guide.

So to get the client sort of used to seeing our designs in the browser we like

to deliver them sort of like a faux website in the browser.

What this looks like in our project hub, is we have the mock up and

this is just one big jpg.

This same one that we were just looking at.

And then with a little bit of HTML and CSS, we have a one

pixels repeating background going behind it, that we took from the JPEG.

And, you can see that it sort of gives them the feel and

the illusion that this is a website, even though they can't interact with it.

They're just used to them seeing it in the browser.

So then we're gonna get feedback on those.

And we wanna feel comfortable that this is the right move and

that we're, we're headed in the right direction.

If the client's like, this is not really feeling like our brand,

we'll probably wanna go back to Photoshop and try again.

But, if it's kind of minor feedback that we feel can easily be achieved in code,

then we can move into code right now.

And if you're keeping track,

this is now the third design deliverable, and we're already coding it out.

And that is awesome.

So, the feedback that we got on this comp was this right rail.

The different modules were feeling like they were kind or running together.

So, separate those out a bit, okay, easily achieved in code.

They wanted this promo area to be more tied to the promotional

products below, okay.

So a little bit of design rework.

No big deal. And

they wanted to add another carousel that had new arrivals,

in addition to the closeouts.

Again, really easily achieved in code.

So we felt confident moving forward that we could code this out and

make those changes for the next deliverable.

Which we are now going to deliver them a coded design deliverable.

When we first put this in front of the client when we first tried this out,

they came back and said things like,

when I click off of the drop-down in like the gray area I want it to close and

not like, have to click the link again to close it.

And we were like, oh no,

we, we weren't clear this is a design deliverable, we need design feedback.

And then we were like, a little lightbulb went off like, no this is awesome,

this is awesome that they're thinking about this, this early on because now it

won't be tracked as a bug at the end of the development.

So these are things that when we put it really early in front of the client and

get them thinking about these things and interacting with it we'll catch a lot of

those things really early on and not get pushed down the stream.

So things like the dropdowns and popovers and

stuff, those are things that probably haven't been accounted for in design yet.

And that's totally fine because now we can catch them because the developer's coding

it out and then saying hey, I need a style for this.

And then if you're keeping track, if the developer is getting more used to

design and getting a little bit more design savvy.

It's really awesome to just take a first crack at styling that and

then go to the designer and say, hey, I styled that drop down, what do you think?

And then the designer can either go in and

sort of finesse it or just say like, no, good job.

And that's especially awesome for responsive layouts.

If a developer can take a first crack when they're coding it to sort of say, hey,

like what do you think if we put this over here.

And then the designer can say,

yeah that's awesome good idea or you know again do a little mock up.

So, like I was saying before, trying to catch these things with the client early

this watched items over on the right rail through wireframes and

early design and everything, we didn't think about how to sort of, unwatch them.

And then as soon as we put them in front of the client and

they were sort of interacting with it, they were like, how would we unwatch this?

And we were like, oh, we haven't thought about that.

So we developed this little system.

And again that's something that wouldn't have been accounted for

until much, much later.

And we're catching it really, really early on in the design deliverables.

So since this is still a design deliverable,

we definitely want it to still be designed and designed well.

I know that I was feeling a little guilty when we tried this at first,

that the developer was spending all the time on like, my design deliverable, so

I started to get in there and really finesse and nitpick the CSS.

And now is the time for it, that to really work and work well.

so, we wanna keep design iterating on these things.

Something like hover animations,

unfortunately I kind of would forget about those until the very end.

We're just like we'll pick a darker color, whatever.

But in that time where I was like really trying to play around and

like, get into those little granular details and really smooth things out like,

little messages like, how would that alert go and adding the little bounce and

stuff, those hover animations that usually kind of get overlooked.

Now is the time for the designer to get in, get in there and

really have some fun with that and figure out some cool CSS animations.

So, I had a lot of fun with this because I had the time to sort of nitpick.

We're really only coding out like, two pages at this point.

That's only like two pages worth of CSS.

So, now is the time for us to get in there and really smooth things out and

really get those to that pixel perfect detail.

But actually in code and not in Photoshop.

So now is the time for

us to QA and then our system as we build on it, will already have all of

those nice details that we've spent the time working out really early on.

Like I've been saying,

we want to catch these things early because they are design iterations.

They are not bugs.

Bugs are, this is broken in Internet Explorer.

Bugs are not, I want the modal to close when I click in the grey area.

Those things that usually are tickets at the end of development that

are sort of less important than like, actual bugs we can account for

those now, especially design.

A lot of times, I know I tend to make tickets that are like,

little design nitpicks and those usually don't get accounted for

because we have real bugs to solve at the end of development.

So we wanna get that stuff in now.

We wanna get the, those client in, iterations in now.

And all those design iterations now.

And as we continue to build this out, we wanna make sure that we're documenting it,

we're making it this modular, extensible code.

This is that homepage that we saw coded out.

And you can see we have the footer pulled out.

You can't really see it that well, but you can interact with all of the links.

This is a fully functioning code that they can pull.

Let's take a look at the stories, those news items that were there.

There's the description, and then the code for the client's team to then pull out and

reuse once our engagement's done.

So, we can take it a little step further and go down to just then that news item.

So you can see how these blocks kind of build on each other and

we can get more detailed as we dig in.

[BLANK_AUDIO]

So this next part is a little bit more fluid.

And will take a lot of back and forth with your team to sort of figure out.

Designers really like to be perfectionists and, you know,

figure this stuff out before letting anyone else see it.

But we need to sort of let go of that and

really talk it out with developers to figure out what they need from us.

So the developer can say, hey I really need this module design from you, and

really just trying to fill in those gaps in our system.

Dan Maul has said it really nicely where he said it's about deciding in browser,

not designing in browser, and I really like that.

Cuz we are making these decisions actually in, in the browser for our actual website.

So the next page in this site that we designed was this article archive.

And you can see this has already been designed and coded.

So as much as it pained me, I just took a screenshot,

I didn't have to design anything, I didn't have to change anything about it.

Just putting that in there for scale and for reference with the rest of the page.

Our header, obviously has already been designed and coded.

I don't need to design that right now.

The only thing in this next deliverable that needed to be designed was this

filter, and then the tagging system and breadcrumbs that went along with it.

And, a lot of that was about the interaction and not

necessarily the design, so, this didn't take that long to actually design out.

But we wanted to bring that into code so

then we could see how those tags would come up, how the filter would expand and

collapse, how we would close some of those filter checkboxes.

And then we put it in front of the client again.

They, once they were actually interacting with it.

They said, we want that filter to remain sticky as they scroll down that page,

so again that is something that we caught on really early on that is

a design iteration and not a bug.

So taking a look at the code we have that same stories,

same code, same components that make it up.

And then here's the new piece that we made, the filter.

And again, fully interactive.

We can dig a little deeper, the descriptions.

And then all the code is right there in the project hub.

So we are just making sure that we document and build out our code to be this

extensible system, that Twitter Bootstrap idea that we're making for the client.

[SOUND] And as we continue to work through this it's gonna

take a little bit of trial and error between your team.

I know when we started doing this.

As you can see the design part of it ends

up being a lot faster the more that we're building on it.

The more we're just kind of piece designing what needs to be filled in.

When the designer ends up designing like three pages and

then the developer has to code out three pages obviously that's gonna

take a little bit more time than that took.

Which, it's totally okay to be up front with the client and

say hey, we did these pages as a static mockup and these pages coded.

We already sort of laid out that groundwork way in the beginning when we

told them what to expect, that we're gonna deliver coded design you're gonna

see some static mockups, that, the, faux in browser, you're gonna see some of this.

So just being really open and letting them know what to expect is totally okay.

And like I said, it'll take a little bit of teamwork to figure out that timing.

But it's also important to always be in communication with your team.

If you're not already using Slack, I highly recommend using Slack.

Slack has been awesome and a really important component of working this way.

You have the different channels, which we have one for our team.

But also you can do things like type to Github, so

that when every time someone pushes it'll alert everyone in that channel.

Whose working on that project like, oh this is what's going on.

So, that's really cool.

It's really great to just get quick feedback toss in a screenshot of

something and then have people weigh in on it on the team.

But then it's also really great for having direct messages where,

when I'm working really closely in that iterative fluid process with a developer,

they can send me a link and say, okay yeah, here's where I took

that first stab at styling the mobile comp for that article page.

And then I can click on it and

then say oh, what if we changed this little piece to be this.

And I quickly mockup in Photoshop and send a screenshot back.

You can see how it really works well to have that quick iteration.

And I'm not exactly sure why it's so

much better than it's predecessors but it like, really, really is.

It's way better than HipChat, any of those things.

So you should look into Slack if you're not already on it.

So now we continue to design.

And continue to work and build on our pages and

now we've laid a really, really, really solid foundation for development.

We have our CSS really finessed out.

We have a lot of our layouts working.

We have this nice style guide.

We have our modules.

We have all of these pieces that then will make development,

hopefully much less painless.

We've hopefully caught a lot of those design iterations early on and our,

hopefully our bug ticket count at the end will be much smaller.

So now we're just gonna just move into development and

continue to build out the rest of the site.

So back to Bill Bernbach, he said, let us prove to the world that good taste,

good art, and good writing can be good selling.

But I think if he were making websites today,

he'd say that it's about good design, good code, and good content.

When we don't bring all perspectives into the equation we get dull results.

These really boring,

uninspired layouts of a large image with some boring type below it.

And when we don't work together we also have giant,

boring images with some boring type below it.

So we want to have the whole team bringing all their

perspectives together to build the best solutions for our clients.

Thank you. [APPLAUSE]