Lessons
Day 1
1Class Introduction
09:10 2The Design Flow Basics
18:27 3The Designer as Co-Creators
06:48 4Get to Know Your Material
17:07 5Responsive Vocab: Floats, Flows, & Images
11:58 6Mobile First: Working Small
09:46 7Future Friendly: Embrace Unpredictability
14:17Collaborating with Your Clients
13:52 9Prioritize Your Users
39:42 10Best Practices for Defining Success
08:58 11Intro to Scrum
04:24 12User Stories & Epics
35:53 13Content Basics
27:40 14Defining the Visual Language
22:31 15Starting with Type
35:31 16Starting with Grids
15:40 17Gutcheck & The Product Brief
22:03 18Working With Developers
12:33 19Communicating with Developers
16:25 20Finding a Common Language with Developers
06:28 21Code Literacy
04:37 22Sitemap & Wireframe Basics
33:48 23Prototyping Basics
12:02 24HTML Prototypes
13:28 25Code Literacy & Developer Tools
11:46 26Developer Lingo
07:23 27Interface Personality & Behavior Galleries
17:27 28Designing for Performance
18:19 29Progressive Enhancements
07:00 30Designing a System: Discovery to Pattern Library
12:25 31Workflow Examples
20:25 32Applying the Style Guide to the Pattern Library
09:08 33Alternative Workflow
23:04 34Alternative Workflow Part 2
21:52 35Tech Requirements
21:53 36Retrofitting an Existing Site
12:15 37Project Cupcake: Building a Site from Scratch
24:08Day 2
Lesson Info
Working With Developers
This is, again, a question that both Andy and I hear a lot and some of you might be thinking, I think we looked around in the chatroom and sort of saw some people had this question. And we've even talked to some of the participants in the studio about this, and people are really curious because I'm designing the browser, doesn't that mean I have to learn some code? Like, I'm just not comfortable there. Like, it's intimidating. It's a foreign language. What do I do? We just wanted to address outright, again, some of the conversation in the chatroom was, "What if I'm a solo practitioner?" Which is where we all start. I started there. I'm sure Andy did too. Like, I just sort of went on Craigslist, and I took whatever job I could get. And I kinda lied at first in order to get the job. And I kinda stayed up all night to kinda figure out what it is I needed to do. And my whole process was kinda filled with insecurity. Until I realized that I could admit what I didn't know. And that's when I ...
found people that I can work with. 'Cause I found out that, the more I admitted what I didn't know, the people that I worked with also said, "Yeah, I don't understand this whole visual language thing." "I don't understand why I would care about the font." "I don't understand why or how you see what you "see in those images that you pick for the design." So as much as we might have insecurities as designers about how it's put together, developers also have fears and insecurities around what we do. And so, as long as we expose what we don't know to each other, I have always found that those partnerships were happy to fill in for each other. So I would encourage everyone to partner up. Find someone that compliments your skill set, and that where you can admit what you do and you don't know. So that brings us to what we'll be covering today, which is rooted in developer collaboration. How do I start these conversations with developers? Where does my work end and their work begin? What deliverables am I responsible for? Next we'll get into wireframing basics. We're gonna look at how do I begin at the lowest resolution possible, begin modeling my website and my objects in wireframe format? And at some point, wireframes just don't do it. We need something that clicks. We need something that moves. And more and more, as the web becomes more complex, this requires a prototype. So now that things are moving, we have to start asking why do they move? Why does that do that? When it moves like that, that makes me feel this way, or I look at your product that way, and Andy will dive into defining interface personality extending off of prototypes. And then finally, designing for performance. And we touched on this yesterday a little bit, but there's something really important here. Designing for performance. You might have noticed that everything that we've introduced sounds like an add. Like, okay, so I'm adding this, I'm adding that, I'm adding this, I'm adding that. This is a bigger website I have. There's so much stuff going on. But there's strategies about how you add things. How you set up the cascade in your Excel sheets. How you make your components progressively enhancive that will allow you to ensure speed, at least to the core user, no matter what device they have. So we'll dig into that as well. So, again, I am not a designer or a developer. Andy talked about this idea of the spectrum of design and development yesterday, which I kind of wish was more of a Venn diagram, because I do think there's a little bit of overlap in the middle. We simplify it. (mumbling) Yeah. Yeah, yeah. I like to think that we bump into each other. So I started in visual design. At least that's how I sort of came into teams. That was my background. But I found the more and more I just had to communicate, I didn't wanna learn code. I just eventually had to learn code in order to communicate with the people I was working with and the complexity of the projects I was working on. And so, for the last five years, the more I did that, again, we talked about these deliverables yesterday. Like, these things don't come out fully baked. Nobody said, like, a style tile; that's how we'll do this. Like, they're the results of success. We follow our successes, and we give success a label, and that becomes a method or deliverable. So parallel design and development, I made it up. To describe success that I've had with working with developers. So the size of my company that I have worked with for the past five years is fairly convenient. It's one person and one person, and we're sitting side-by-side, and we sort of like aggressively tackle very specific user stories to solve problems and then see success in the browser. I love this quote from Frank Chimero, a web thinker from an article called The Web's Grain. He says, "The walls are gone, so we're left to learn "how to collaborate in the spaces where things connect." So he's talking about the silos, right? Silo design. Silo developer. The silos are the illusion. It's the Matrix, right? And so we're all actually working at the same time. So we're running into each other. I like to think of it like, before responsiveness, it was easier to do the hand-off, right? But now that we don't know what this is, there's no way we can do this without working side-by-side simultaneously. So I like the metaphor of working in parallel as reflecting the unpredictability of the canvas. This is a really pretty drawing that I made in like, I don't know, it took me a while. I spent like a day. So this is the wall that separates traditionally designers and developers. This is the designer, the developer, and this is that PSD mock-up, that thing that I made, that .jpg, and this is me leaving the scene of the crime. Here's the PSD. I'll see you later. And then six months later or three months later, I show up and the website's wrong because they just didn't get it right. They didn't interpret the subtleties of my design language. And when they set up that breakpoint, they totally didn't understand what I was trying to say. How are they supposed to know? If I handed them a static file and left, where were those instructions? Were they imbued into my design? No. There's no possible way. Even if you try to comment every single object in your mock-up, you're not gonna communicate all the subtleties that happen in-between all these breakpoints. So that means this is the yellow brick road, and we're sort of like skipping along it together as designers and developers. There's no more hand-off. We're in this together. Because not only is the viewport width changing, but the goals are changing, like Andy said. The client is allowed between sprints to kinda change what we're doing. Well, I can't design for that, so I've gotta be there to change the design to match the business to keep up with the developers, so, again, there's no more hand-off happily ever after. Andy talked about scrum, and so scrum is a process that's daily, weekly ceremonies. I'm gonna talk about what happens in-between that stuff. 'Cause realistically, from my experience, they're informal but they're really critical to maintaining success. The first one is finding channels of communication and keep them open. This we'll dig into detail. This is Slack, this is HipChat, this is Skype, this is Hangouts, this is whatever you wanna use. But that channel, that line, needs to be live and more open than email. Email is the... This workshop is not about why email is bad. You wanna develop and promote a common language. Now that we're talking to each other all the time, or we have access to each other, when we talk to each other, we wanna mean the same thing. We wanna direct each other to the same component. And so, how do we develop and promote common language? And in the end, this gets sort of finer and finer grained. As we're developing and promoting this common language, when we talk, we gotta sound like we know what we're talking about a little bit. We have to be informed. And so you're not writing code, but you do need to be able to read code from a high level. Understand the differences between an element and a variable, and speak to those names. So again, we're gonna get into this idea of code literacy and why it's different than being a programmer. So this, pair programming is an idea that comes out of development, and this is gonna force us to get out of this artistic genius mode and ask for help. What is the definition is two programmers work as a pair together on a workstation. One is the driver and he's writing. The other one is just looking and talking, and the other one just types. So one is just strictly a typist. The other one's actually doing this sort of softer skillset, making sort of leaps and calculations, and sort of telling the driver what to do. And at first I think people were skeptical, like, that's like two developers at the same time? But you'd be amazed, by separating the mechanical process of typing from the sort of higher level process of navigating how much more got done. So we brought that over and to include designers, and so we say that designers and developers work as a pair, the developer is driving, and the designer is the observer working alongside going, "Nope, nope, the type is still not right. "The type just needs to be nuanced a little bit. "No, the color doesn't match this color. "We should just try to move that." Asking questions. "Why does that breakpoint give me that?" Working as a pair, the developer allowing themselves to learn from the developer and then back and forth, the developer allowing the sort of designer to have these observations. And so this is what the process of parallel design and development looks like. My partner and I, it depends on the projects that we work on. We do a little bit of this. I mean, this is sort of a constant process. But to really sort of generate significant momentum, we'll carve out two hours at a time on a regular schedule to really sort of push through it, and we'll sort of talk about what a session looks like.
Class Materials
Bonus Materials with RSVP
Bonus Materials with Purchase
Ratings and Reviews
CityGirl
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.
user-3d865b
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.
Student Work
Related Classes
Branding