Skip to main content

Modern Web Design Demystified

Lesson 19 of 37

Communicating with Developers

Andy Pratt, Jesse Arnold

Modern Web Design Demystified

Andy Pratt, Jesse Arnold

Starting under


Get access to this class +2000 more taught by the world's top experts

  • 24/7 access via desktop, mobile, or TV
  • New classes added every month
  • Download lessons for offline viewing
  • Exclusive content for subscribers

Lesson Info

19. Communicating with Developers


  Class Trailer
Now Playing
1 Class Introduction Duration:09:10
2 The Design Flow Basics Duration:18:27
3 The Designer as Co-Creators Duration:06:48
4 Get to Know Your Material Duration:17:07
6 Mobile First: Working Small Duration:09:46
9 Prioritize Your Users Duration:39:42
11 Intro to Scrum Duration:04:24
12 User Stories & Epics Duration:35:53
13 Content Basics Duration:27:40
14 Defining the Visual Language Duration:22:31
15 Starting with Type Duration:35:31
16 Starting with Grids Duration:15:40
17 Gutcheck & The Product Brief Duration:22:03
18 Working With Developers Duration:12:33
19 Communicating with Developers Duration:16:25
21 Code Literacy Duration:04:37
22 Sitemap & Wireframe Basics Duration:33:48
23 Prototyping Basics Duration:12:02
24 HTML Prototypes Duration:13:28
26 Developer Lingo Duration:07:23
28 Designing for Performance Duration:18:19
29 Progressive Enhancements Duration:07:00
31 Workflow Examples Duration:20:25
33 Alternative Workflow Duration:23:04
34 Alternative Workflow Part 2 Duration:21:52
35 Tech Requirements Duration:21:53
36 Retrofitting an Existing Site Duration:12:15

Lesson Info

Communicating with Developers

We're gonna talk about communication. We're gonna talk about developing a common language and finally we're going to talk about this idea of code literacy. The first step of communicating. Again, Scrum, Andy mentioned this yesterday. I really dig this drawing, not because, just because of the pretty colors, although the colors are pretty, but because it's the most accurate way of actually ever seeing this described, like I have tried to draw this myself like... Parallel means everybody the same time but we don't all really start at exactly the same moment, and then we all don't always finish at exactly the same time. So, I really like this idea that we all start on a staggered format but for the majority of the process, we are working side by side. So, whenever we show you a list of tasks, that means we might have started them then, but there comes a point when they're all happening at the same time, and we gotta maintain communication across those channels to make sure that we don't g...

et out of sync. Well, we're gonna add to this, these are all the ceremonies that Andy reviewed yesterday. Again these are daily/weekly processes, but we're gonna talk about the in between spaces, things that are always open. So, first up, my favorite, sort of where I think the people that I work with, where I think we really kicked up our production level was maintaining Google Docs around specific parts of our process. The way that this works with my development partner, we meet every morning and we have something that we call 'work week' and it has all seven days laid out within a Google Doc as header elements, and then there's bulleted lists of tasks. We walk through and make actionable the next thing for every project in the queue. It's not a long process. The idea's to think quickly, very similar to Scrum, and the main goal here is to both contribute to the process of what is the next actionable thing. There's a great book "Getting Things Done" where he talks about this like, there's an idea that David Allen Green, I think, author, David Allen, take this abstract idea, the user story, and that's gonna cause both the developer and the designer stress unless they know what they can actually do about it. So, by whittling it down to an actionable step does this thing cognitively, it actually strips away these open loops, these stresses, and lets me know: this is the next thing I need to do. So, it focuses the team. But the idea that these documents are open all the time, it's different than a chatroom, because it's a collection, it's a list, this is our... An example of this our content inventory, our plain text files, our component inventories, these are all collaborative documents that we're communicating and contributing to and everybody is a part of. Next up is channels, sort of a generic term. It means chat applications. I think, they're trying to get away from trying to call them 'chat' because they're sort of like trying to blend the business model of what it actually does. So, Slack, which most of you may have probably heard of, and HipChat, we use HipChat at Exegy. I was actually going to call the team up but then Andy and I talked about the... So, I could if I wanted to, if you guys challenged me. They're always open and the cool thing about them is you have access to people, but these are, it's different than a task you assign somebody, the way that channels work when you work with teams, again, these are rules that I've learned with experience is that there are, they come with some general etiquette. It's learning to respect each other's space, so, you wanna be respectful of your team members' time. So, everybody's opting into this practice, right, we're all gonna be in HipChat, we're all gonna be in Slack, but you gotta understand that people have families, like the whole idea of distributive working, and working with everyone, it's cool, right? But there's just some unsaid rules that if, and I understand when people break them 'cause you're in and out of timelines and stuff, but these are just things you should keep in the forefront of your mind if you're trying to sort of play nice with others, so, be respectful of each other's time. Where as Scrums have a designated start time for the whole team, responses in these channels, they're not guaranteed, and the best way to pay it forward is to like, is to answer people, like the way that we use it in our team is people will throw out global questions, and that's sort of like your opportunity to pay it forward and go, "Let me answer this global question for somebody who's struggling with this design concept," and then I'll answer it, and then other times you'll get personal messages directly to you, and again, it's up to you when you answer it. And, so, there's no right or wrong answer, but the effort that you make in answering these responses is a fair way to look at what to expect from other people, you know, so, understand that you're dropping the flag, you're saying, "I need some help," but there's no guarantee that anybody's gonna come and pick up that flag, or answer that call right away, so, again, as great as they are, understand that your friends and your collaborators are not robots, they have to sleep and all of that stuff, social lives... Just to add a little something, so, at Favorite Medium we've kind of also very much believe in channels, we use Google Hangouts for pretty much all of our communications, not only the Docs, but also Hangouts to communicate. Couple of key things that I think made things a lot easier: one is having Google Hangouts, the app, on your phone, just makes it really easy to kind of stay connected because you're often on the go. The other thing is that download the Hangout extension, you know, say, for Chrome, it's a much better experience than trying to constantly trying to go through Google Plus to kind of figure out where the Hangout is. Just makes it so much simpler, and what's really interesting about the way you communicate is that as you kind of look at the process in which you communicate it also defines the culture of your company, right. So, process and culture inform each other, and that's something that's really important. You'll notice that if you're working with a client, you know, you're kind of seeing a different agency, and you can feel that tension, that tension bubbles up, as part of the culture, but if you look kind of underneath, a lot of it is about the process. You know, what are the things that people are frustrated with that essentially inform that culture. So, there is that kind of back and forth, a little between, but it's really important just to kind of stay connected and keep that collaboration going and for a remote team, it's, you know, very critical because we have overlap when we're on certain timezones, and then a lot of times, you just have to let that team run a little bit. So, very critical, and I think that you're going to find it so helpful just to be connected all the time. Yeah, and then you're gonna find the software that works for your team, I think, I have all three. Like I have Skype, Slack, and HipChat, and different teams prefer different ones. So, I just adapt and sort of just move around. And the other thing that we do, too, when we're talking about kind of respecting time, because things blend, is, you know, in our calendars we actually block out, you know, like I have blocks for family time, right, like because it's not... The traditional workday now breaks down when you potentially have team members in different locations, so, one of the key ways that you can kind of start to establish that respect is by having and just blocking out, "This is my time, this is work time, even like, I don't even want meetings here," and just starting to look at your calendar as not just the place for profession time, and not just the place for when meetings happen, but to kind of dictate, you know, the way you wanna structure your time, and it's not perfect, so, sometimes there might need to be a meeting that overlaps into one of those areas, but at least there's kind of an understand and it would be more of like, "Hey, can we do this during your time? I realize this is your personal time." Changes the conversation a little bit and again creates that respect within that culture. Yeah, cool. Yeah, we are all real people. The other method, format of communication are these Hack Sessions, so, within chat and channels you can ask discreet questions, you can get sort of maybe codes that fits your things, your solutions, you can send JPEGS or references to files back and forth, but like we said before, yesterday, sometimes there are these micro-tasks that sort of add up, or you have a bunch of cards in the queue relating to a specific user story and sometimes there's (stammers) again, as much as distributive development as "Yay, good." Nothing beats a concentrated, side-by-side, at-the-same-time, synchronous, collaboration where you're actually asking/answering questions, filling in for each others. So, again Hack Sessions, most literally comes from again, programmers did this, they found that this pushed things forward. More and more I see designers doing this without developers. Just sort of hack on a project. It's a concentrated period of time, a hack, a concentrated period of time that everyone agrees: "We're not gonna do anything else but this." You're shutting off e-mail, you're shutting off all this other stuff and for two hours, you're just gonna geek out, zone out, answer questions, around this particular piece of functionality. And again it goes, this is the most literal translation of the parallel design/development idea. I have designers sit with me as having more front end knowledge than them, and I dive into the code, and then they ask for things to change, and I'm not just doing what they say, I'm teaching them how to do what I do. Like this is where the knowledge exchange happens. Like they're curious of the difference between CSS and Sass. So, Sass is a pre-processor for CSS, which allows me to abbreviate and condense some of my statements. So, designers are curious 'cause most of them understand basic principles of CSS, but they wanna know how Sass works, and I'll show them and it'll set off like, they'll start to think and design differently. So, they'll go, "Oh, you can do that? Well, why don't you do this?" Again, I've been looking at it for so long as a developer, when I'm in that mindset, I'm not making some of the associative leaps that a designer's making. So, I need them to leap for me while I'm thinking very technical, and problem solve. So, it's basically having both sides of the hemisphere of a brain working at the same time, and that Guillermo del Toro movie calls it 'drifting,' right, so, it's like this idea that they have two pilots of these giant robots and so it requires both sides of the brain to be working at the same time. (Andy whispering) Yeah, Pacific Rim, yeah, yeah. (laughing) Is that where you went? That's where I went, just there. I wrote a blog about that, we'll put it in the show. So, the rules here are, this is the team at Exegy working on a concentrated sort of format around a goal, so, what we're doing here is we're asking questions, I encourage you to just submit when you don't know what you're talking about, you know. And also, encourage the developer to have you articulate yourself if you use a design term that they might not understand, and again, realize that this is where you're doing that translation of concepts, you're teaching each other each other's languages. And again, stand up for your design goals, as much as you like, say, "I don't understand what Sass is. I don't understand the difference between Rails and PHP. Can you explain it to me?" When you say something like, "I need to create a hero unit that sort of like impacts and gives an immersive experience, and sort of drives the eye through my vertical rhythm." They're gonna wanna ask you to describe exactly what you're talking about, right? And stand up for that stuff. You know, like don't feel like you have to reduce the importance of your design goals, because it doesn't translate immediately, 'cause, trust me, developers want to know, they want to know, because they want to learn to anticipate your needs so they can be better developers. So, at the same time as you're asking questions, stand up and sort of like speak, speak the word when it comes to design language. The other side of these sessions is... I guess every team's different, but I've always known white boarding is more of a design exercise. I know developers do white board exercises as well, what I'm encouraging here are these cross discipline... I'm saying invite developers to design white boarding sessions, right, because the realm of these ideas, these realm of the goals, this is a universal space, because there's no aesthetic here and because you're in thinking space. So, again, developers want to learn your language, and this is a place, again, you're not in code land, you're in this active wire framing block modeling land, it's a really powerful place for potential for sort of like learning from each other. Developers again are really interested in the user story, they want to know the why, they do want to know that last part of the, like, they wanna know why, because, the how, they get the how, but knowing the why, and having that consistent reminder of where in the big pictures this fits, it makes it more than just the tasks. "Okay, gotta make this, me typing again, I gotta make the button red because they said so." It's because it performs a certain function within a larger user story. And also, developers are gonna make some design suggestions. They're gonna say,"'Why isn't that round?" They're gonna say "Why is it that color?" You just need to be open to this, they're acting, they're reacting instinctively, so, again, I encourage you to not, as much as, if you expect to be let into code land you need to let developers into design land. You need to let them, like Andy did yesterday during the sort of user story, like, keep at: "What do you mean by that, what is sort of the larger goal?" It's sort of like, again, get away from features, and get into stories, and try to find out what is the actual user benefit that they're suggesting and sort of work it that way, rather than taking it as maybe as an aesthetic critique, like, "I think the font's too small. Why?"

Class Description

Online web design is not just about choosing fonts, colors, and layouts. The days of throwing a static visual comp over the wall are ending. Designers are now encouraged to work side by side with clients and developers. In Modern Web Design Demystified you’ll learn how to communicate with developers and collaborate with your clients in order to design websites that function as well as they look. You’ll learn about: 

  • The fundamentals of responsive web design
  • Working with Clients to identify and prioritize goals
  • How to communicate with Developers
  • Best practices for project workflow
In this online web design course, Andy and Jesse will share real world case studies to help you understand exactly what goes into creating and launching a website from the ground up. They’ll tell you about the tools they use and offer tips on working with everyone from the coder to the client.

High-quality web design is complex, but it gives businesses and orgs the opportunity to really connect with their users. Learn the ins and outs of the entire web design workflow process in the Modern Web Design Demystified course.

Bonus materials include: 
  • Sample Dev Tickets
  • Responsive HTML Wireframes
  • HTML Pattern Library
  • Sample High Resolution Visual Comps
  • and more! 



I've already taken several web design classes, but there were still some details that I found confusing. Andy and Jesse did a great job of explaining things like; programming languages and how they interact to form the structure of a site, work flow responsibilities between team members and the blurry lines between them; and agile methodologies applied to work flow. They used case studies to illustrate how this all happens, where variations crop up, and how to address them. If you're new to web design, or just want to understand the functions of other team members, this is a great real world look at the whole process. I haven't found this in any other class, either on-line or local. Andy and Jesse are both very experienced working designers with current knowledge. They're very responsive to questions and seem to really enjoy teaching. Having two instructors is a great benefit because you get double the perspective, knowledge, etc.

Junko Bridston

I worked with Andy when he was a Creative Director at Funny Garbage, a design studio in New York City. I found him to be knowledgeable​, articulate, and lovely to work with. I learned so much from him at the beginning of my career. In response to a previous comment: it seems silly to dismiss this class because Andy wears t-shirts with his blazers. If you think leaders only wear suits and ties, then maybe this class isn't for you. But if you want to learn from someone with loads of experience and a friendly manner, I really recommend it. You won’t be disappointed.


I was looking for a class that would not only address the web design basics but also their place and function as part of a workflow. This class did not disappoint and Andy's and Jesse's engaging presentation style made it easy for me to follow along during the 2-day live session. By using real life examples, the presenters provide plenty of tips and strategies how to best work with clients and developers alike — the many, often intangible ingredients that go beyond technical expertise and can make or break a project. Highly recommended.