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.