Lessons

Lesson Info

The Design Flow Basics

So now, Jesse and I just want to give you a little bit of background about who we are. You know, where do we come from, and kind of how did we get into this crazy web design-- Why should you listen to these guys, right? Yeah, why care? (laughter) So, I'm the creative director at a digital agency called Favorite Medium. And Jesse-- Is a front end designer at a company called Exygy. Yeah, I wasn't even sure what your, you know, new title was so. Yeah, that sort of changed in the last couple weeks, we'll talk a little more about that. It's sort of, it's, again the philosophy is you want to stay adaptable in web design. So we'll talk about how that trickles into your job title. So Favorite Medium, give you guys a little bit of kind of a background, so my office is in Oakland but we also have client-facing offices in Seoul and Singapore, and then we have other remote teams ranging from Tokyo, Philippines, Malaysia, Dallas, Portland, Mainland China, kind of really spread out. So ...

we're very much a remote distributed team. We don't just focus on websites, we kind of do native android apps, native IOS apps, really kind of a plethora of kind of interactive experiences. So even more, you kind of have to be very flexible with the types of things that you want to learn. And there's gonna be a certain amount of stuff that's gonna kind of translate through all of those but then there's also a lot of specific nuances when you get into that particular experience. So the other thing is that I'm also the co-author and co-designer of this book, Interactive Design by Rockport Publishing, and this is really kind of an introduction to the basics of user-centered design. And aimed at students and professionals looking to kind of make a shift. Some of you might be very much geared towards that. So some of the things, techniques and ideas that we're going to be talking about are in this book and then there's a lot of new stuff in this class as well. So this when I show a very embarrassing photo of myself, gonna get that out there, right? So this was during my unfortunate long hair ponytail days that I moved on. I should've included one too, I'm sorry. Yeah exactly. My hair's gotten a little bigger since then, but you know, this was around probably 2000. And in the early days, this was, for me, when a role like information architect was very new. Even a role like content strategist was something that I hadn't even heard of at that time. It didn't mean that people weren't, you know, filling the needs of these roles, it just meant that we've seen a lot more complexities and a lot more need for there to be more of these formal roles because there's so much work and thinking that goes into them. So, you know, back then a lot of things were very simpler. A lot of the sites that we were building were just in tables, we were using a lot of Flash back then, and in some ways, I would go and work with a developer and I would just say, hey can I build this? And they'd either say, "Yup, you can totally do that," or "No way, you're out of your mind," right? But if you move it over maybe like 10 pixels, then we can totally do it. So it was really kind of interesting. There was a lot less that you could do, and things were a lot simpler and we've kind of come a long way since then. Now, when I was working back then, this was kind of the typical methodology that we used. It was called Waterfall, has anyone heard of waterfall, does that mean anything? Okay, so this is kind of a sequential design process, right? So the idea is, you kind of have, you know, one thing that you're kind of figuring out and then when you're done, you're completely done with discovery, then you kind of move it to the next phase. So the idea is that you can never kind of go back up. Right, so it's like you've completely figured out everything in discovery, you move it to planning and planning is where you might kind of start to figure out design, and start to kind of get into wireframes and then you move that into development and you have this kind of process. It means it's kind of a very, heavyweight, artifact driven process. Where you have to have so much documentation to kind of hand things over, and it makes the teams very siloed, and this is kind of a bit problematic. Because we realize, you know, imagine you have a project that's six months long. So what you're saying here is that everything that you're figuring out here is perfect, and you will never need to adapt or change to kind of go down as you move through the phases. And it also puts the developers at the end of the cycle, right? So now, whatever budget is left, whatever time is left, all these promises that have been made to the client, now have to be delivered, and it's on the shoulders of the developers to kind of make it work, right? So it really sets up a tension within the structure because ultimately, you're kind of placing a lot of that kind of heavy lifting at the end of the process. So there had to be a different way. And so this is kind of a little more representative of how we work today, how Favorite Medium works in particular. And how hopefully we can kind of get you guys to think about as well. So the new methodology is called agile, and there's a lot of flavors of it out there. But the idea is essentially that it's iterative and incremental, right? It also tries to encourage collaboration and flexibility. So instead of kind of having everything flow down, the idea is you have what's called sprints, and so sprints are usually about two to four weeks, it really depends on the team structure, and what you determine as a team is the right fit, but the idea is that you're kind of like, doing design, build tests, in these smaller groups. And it involves the entire team together and kind of working in parallel so that way there's a lot of opportunity to shift gears. And that's kind of what's key. You know, we want to make sure that whatever the process is, is something that allows you that flexibility to kind of shift knowing that you're gonna have new things that you're learning, you're gonna have new competitors that are gonna kind of come into the space and try to change things, and so with a process like this it allows a lot more flexibility to be able to adjust. So more specifically, this is kind of how we work. We have a basic two-phase approach where we have kind of a product planning where we have this kind of discovery, so there's still a bit of discovery, you know, we still have a lot of stuff that we're gonna learn. WE still have a lot of stuff that we need to kind of understand what's important to our users, kind of figure out what those insights are that are gonna help us kind of shift over into when we get into kind of the design and development sprints, and that becomes really crucial, that becomes kind of our foundation. A lot of the class today is gonna focus on this particular area. You know, how do we kind of synthesize that information and make sure it's exactly what we need to build that foundation before we move into the sprints. Da-da! Nice. (audience laughter) Thank you Andy, I'm Jesse Arnold. As Andy mentioned earlier, my own job has been sort of changing form for the last five years I've worked as part of a two-person shop. You saw his math earlier, lots of people and lots of places, our math was much simpler for the last five years I've worked as part of a two-person shop, Mister Machine, and the last two months we've been having more conversations in the last few weeks, I'm proud to announce that I've started working with Exygy. Exygy is unique in the sense that all of their clients that they take on are readily looking to have a positive social impact. So one of the first projects I got to work on was for Google.org, which is the endangered languages project, which is an online archive for languages that are going away. And there are no sort of, there's no archive for them so this is an open resource that everybody can contribute to, that we can all sort of actively sort of like, engage in the practice of sort of maintaining these languages. Which is really exciting, but so what we bring to the table, my team, myself and my development partner, we bring a pretty lean parallel process. So again like I said, the math is pretty simple. I do all of the design, and Micheal does all of the development. At least that's how it started, and it made sense. So again, we've worked with larger organizations, that doesn't mean our projects are small. It means that we as a unit can come in and do more targeted things with larger teams, who are otherwise occupied. So again, we've worked with Conde Nast, NYU, to sort of come in and do like really quick iterative experiments in design to help push their larger team forward. And Jesse, if you don't mind me jumping in, can you just define Micheal and who he is? (laughter) Mysterious, he's here. Micheal Anslow, is my business partner. The other half of Mister Machine and now software engineer at Exygy. Awesome. So yeah, so it's our ability to change and adapt and sort of like customize what it is that we do for each team, that's our strongest offering. So how did I get here? My own meandering line to web design I read some bios from some of the people in the class like, again, it was not a linear path. I started out as a painter, I just wanted sort of to get, sort of, the images out onto surfaces, eventually I sort of like, became engaged with computers, I liked bright things, illuminated screens were really interesting, eventually drifted into photography. But then something along the way intrigued me about sort of a tactile things, and so I started to experiment more in the mid-90s with interactive art. This was a relatively new concept at the time. So I was using a program called Macromedia Director, which was sort of a pre-cursor to Flash and I made CD-ROMs that you would enter into a gallery and there would be a CD-ROM and you would play it kind of like a video game, but it was more like a moving painting. So I've always been interested in crossing this line between the physical space and the virtual space. But I started to see more, and all of these things, in all of these different pursuits, I think even probably as soon as photography, I was always making a web component. It's like hitting print on your keyboard, I needed to show it to other people. I needed to broadcast it, I needed to get it in front of somebody else. So there was always a web component to what I was doing. And like I was telling Andy earlier, I was working in Photoshop and making HTML emails at the same time, so like my brain didn't really gel into one of them as being the right way to do it. And I think that's really important. I think it's really good to experiment early and often. So you don't get locked into the metaphors and principles of a specific tool. And it's good to engage with other people in the process and find out how they do things because again, I think there are much broader softer problems we are trying to solve rather than what tool and what application we want to do a specific task. So from what I did before to what I do now, it's fairly eclectic. I'm a generalist, first, and I have specializations. So within a given day, I'll do some research and planning, I'll get on Skype and I'll talk to a client, I'll move across the office and work with somebody on a content spreadsheet, I'll sit down and have a hack session with a developer around what a component is doing in the browser, and the whole time reiterating and testing, the whole time reiterating and testing. So it's a lot of different things. It is not a conventional design position. So is there a method? Like again, like people ask me, like Andy has these really, Andy talked about agile methodology and again at Mister Machine we followed a lot of the same principles and at Exygy again we follow a lot of the same principles. So what we do differently, and what we always did differently at Mister Machine, and I don't want this slide to scare you, the idea of design and code together at the same time, on the screen, it's like eek! I don't know what we're doing. Again, I've never preferred one over the other. I've always understood that the design is information, and eventually it's gonna have a life in code. So even though I might not be able to, at first, I wasn't able to write it from scratch, I very quickly wanted to get in there and begin dismantling it, trying to figure out like what does this part of the website do? What happens when I change this? What happens when I change that? So I don't have a Computer Science degree, I never studied programming the way you're supposed to do it. I worked with others and sort of peeled away at the layers and sort of learned by stumbling, learned by actively engaging and making mistakes and eventually, and again, that's what iterating and testing is. Like every designer, this is sort of like a funny way to look at design, but design is conflict. Like every idea you put in front of a client, or a developer, at first, the first thing you notice is what's different, before you find out what's the same. So we shouldn't be afraid of these ideas of stumbling. It's definitely not gonna be right the first time and some people say it's never done. So there's more resolutionist artwork but it's pretty much the same principles that Andy was just talking about, both at Mister Machine and at Exygy we plan, we build, and then we learn. As discreet phases of a process. And then we repeat. And so the order in which we do these actually gets rolled together. So in the beginning we have to do some planning, we build something, and then we learn something. And then after that first initial stage we enter into this looping cycle. And as you can see there's always forward momentum. At every stage of the process we create what we call something called a hypothesis, right? Which generates what we'll get into, hopefully we'll mention later, is a minimum viable product. Meaning, what is the least I can do to prove an idea. I need to generate a button that teachers can click on to get tickets for the museum. Let's put a button on a website, let's put it in front of some teachers, and see if they find it. That's an actual hypothesis that I can test. The button's not the right color, it's receding into the background, let's test again. So again every one of these pieces is part of an evolving process that builds and builds and learns. And so now I think Andy and I would like to again show you how we, for who we've kind of applied this to in our collective past. Alright, thanks Jesse. Yeah, so we have had the opportunity to work with a lot of different types of clients, creating a lot of different types of interactive experiences. You know, some are more on the tech side, a lot in kind of the cultural media, kid space. It's been a lot of fun to kind of have that variety and each one kind of has it's own challenges. But there's something, you know, as Jesse and I kind of look at our different kind of skills, fundamentally you know, we are both designers. And I think that's what's really exciting. We're both kind of cut from the same cloth but the cloth is very very big. So as we were exploring, you know, if we think of like our spectrum between Jesse and I, and this isn't saying this is the design spectrum, this is just really between how Jesse and I look at each other. You know, we kind of have user experience on say the far left, right? Front end development on the far right, and visual design in the middle, then I'm gonna lean a little more on kind of the left side between user experience and visual and Jesse is gonna be a little more on the right side between visual and development. And I think if anything, what this shows is how ambiguous the term designer is. In fact, in talking with a lot of you guys it was interesting to hear kind of all the different backgrounds that you guys come from, right? You know, making those transitions, and with those kind of previous careers or new careers, everyone kind of has their own take on what that means. So you know, there's not just one thing, there's not just one skill set that you have to learn. There's not just one program that is the program you need. That's what's exciting, and that way it allows us to kind of shift and figure out well where do you fall, right? And once you kind of figure out where you fall, you can kind of figure out your strengths and your weaknesses so you know how to dovetail with the appropriate team. So even though we have different skill sets, you know there's one thing that we do have in common that's kind of a threadline, we solve the same types of challenges. Right, and that's kind of really key, you know, through these different perspectives, Jesse and I will talk and there's really kind of fun to learn a little bit more about how each other works so we can understand what that means. And that was kind of the whole point that we want to join forces with this class is because it felt a little dishonest to say, I'm the designer and I'm gonna teach web design, but then it's gonna be through this one kind of narrow filter, right? And that just doesn't represent how things are done today. Today things are way too varied. So we really wanted to make sure that it kind of reflects that.