What Comes Next Is?

Matt Griffin at Direction 2016
Sign up for Conffab Free to watch this and hundreds of other videos for free
- We're gonna ease into the final session for, well, it's not the final session today, for this afternoon. This is for the crazy ones. This is for the, who's been doing web stuff since, like, there wasn't a two at the beginning of the year, right? Yeah, some old school people. Well done, represent. Who remembers table-based layouts and doing all that? Terrifying. We need a new crowd in here. We gotta get young people. (laughs) Where are all the young people? Anyway, so Matt Gryphon has been doing web design for a long time. About three or four years ago, I saw he put on Kickstarter a movie, a documentary, about the web. I thought that looks pretty awesome. A couple of years ago, by good fortune, he and I were in the same city. I was speaking at a conference in Nashville, Tennessee. We caught up and chatted. He worked, absolute labour of love on this amazing movie about the history and the future of the web, particularly web design. Last night, if you had a silver or gold ticket, you were fortunate enough, hopefully, to have come along and seen it. You can get it online and have a look. It's truly fantastic. But throughout all that, Matt really dived deeply into the history of the web and web design, and thought about what we have been doing and where it's all headed. Today, that's what he's gonna talk about, using a lot of the research that he did. It's a bit of a blast from the past for some of us who were there at the time, and a bit of a history lesson for those who weren't. I'm really looking forward to it. For this afternoon's session, would you please welcome Matt Gryphon. (applause) - Thanks, John. (applause) Hello, everyone. Hi. How are you doing? - [Audience Member] Pretty good. Pretty good? You still holding up? I know it's a long day. We doing okay, still? (murmurs) Yeah. Okay, all right. Good. Reluctant, but firm. I like it. (laughter) First of all, thank you to all of the other speakers for today. If you are in the audience right now or in the vicinity of my voice, you did a fantastic job. This has been a hell of a conference so far. Can we have just a round of applause for the other speakers, please? (applause) Don't, of course, as John mentioned, forget to stick around for the talk after this one, which I'm sure will be awesome, too. Also, John and Rosemary Allsopp, and everyone else that's been working on this conference, part of the awesomeness of all these talks is due to them and what they've picked out for you. Thank you so much, John, for having me and everyone else here. Now, before I get into this talk, I need to confess something to all of you. I am an American. (laughter) It's true. I know I disguise it pretty well in my voice, (laughter) but I really am. As we all know, America's had a really tough time lately. I'm gonna be straight. Last night didn't go quite as well as I had hoped. (laughter) I think it was best summed up by one of my colleagues at Bearded on Twitter to me when he said, "Just stay where you are. "We'll come to you." (laughter) Which, frankly, sounds like a pretty good plan to me right now. But enough about that. I don't really wanna talk about that stuff because it's pretty soul crushing. Let's move onto something a little more positive, like, for instance, Sydney. Guys, right? It's a great city you've got here. It's amazing. I've been here a couple of days with my wife and my six-year-old son. We've been having a fantastic time. In fact, I would go so far as saying this whole dang country is pretty great. This is where I have to come clean with you, Australia. You see, we've met before. You may not remember, but back in 1994, I was here, and I petted your wallabies. (laughter) I played your didgeridoos. (laughter) I purchased your Driza-Bone apparel. (laughter) I rode your camels. (laughter) I know it's been a long time, Australia, but my point is, I like you. I like you a lot. It's really great to be back. (sighs) It feels good to get that out of the way. I feel like we've kinda cut the tension. (laughter) Got it out in the open, and now we can move on with the rest of the talk. Thanks for bearing with me there. So where was I? Right. I have a studio in Pittsburgh, Pennsylvania. It's called Bearded, where we make great user experiences for the multi-device web. Here we are in Net magazine. I only show you this to point out that in my hand, if you look closely, is a NASA mug. (laughter) Now, I don't know about you guys. I grew up nerdy in the 1980s. That means I was into a bunch of things, like Dungeons and Dragons, the Nintendo Entertainment System. These are mine, these are not stock photos. (laughter) And NASA. One of my favourite things about NASA is Dr. Carl Sagan and his television programme in the '80s, Cosmos. I'm speaking to the right demographic, I can tell. I heard murmurs of approval. John already pointed out that you knew about tables-based layout, so I bet you watched Cosmos, too. (laughter) Now, I went back and re-watched Cosmos a few years ago when it was on Netflix. They had a version that was put out in the '90s, where Carl and his collaborator, Ann Druyan, went back and updated the science of each episode with what were then current information in the '90s. In one episode in particular, Carl had a bit about computers, where he says, "In our time, "a revolution has begun. "A revolution perhaps as significant as the evolution "of DNA and nervous systems and the invention "of writing. "Direct communication among billions "of human beings is now made possible "by computers and satellites. "The potential for a global intelligence "is emerging, linking all the brains on Earth "into a planetary consciousness." A planetary consciousness. Do you guys know what he's talking about there? He's talking about the web. That's what we do. We're working on a planetary consciousness. But what does that mean for us as web designers? What kind of world are we operating in? What are we designing for here, and how could we possibly cope with something like that? Well, for the last three years, I've been working on a documentary film called What Comes Next is the Future. We're gonna be looking at outtakes from that film today, which, for the most part, didn't actually make it into the final film. These are interviews with people that I hold a great deal of respect for, that are designers, primarily. That's what I do, I'm a designer. When I started talking to designers, I found I got a lot further down into the weeds than could really maintain the narrative of a film that most people would want to watch. But luckily, you nerds are like me, so you're gonna enjoy it. (laughter) I've put it into this talk. I'm hoping those conversations that I've had, pieced together in this fashion, are gonna help answer some of these questions about what the heck we're trying to design for and what we're doing and how we go about it. In the first issue of The Manual, Jon Tan said, "We aren't graphic designers. "We're web designers. "There is much more to what we do "than combining typography, layout, "photography, illustration, and colour." Yet, many of us have come from a graphic design background, or if we haven't, we've been, perhaps, trained by people who have. That comes with its own baggage and it's own assumptions because the worlds of branding and print are not the same as the word of the wide web. So let's see what some of our friends in this world have to say about that. - I was building web pages on my own, was trying to figure out how to make web pages. At the same time, I was going to design school, learning how to do print design. During a break during a session, I showed them to my design teacher at the time, and just went through and basically was just showing what I built, what's out there. I noticed that she said, she talked to me and said, "You should do web design." I turned my head and I looked straight at her and I said, "What the heck is web design?" - No offence to people who are graphic designers, but I feel like there's so much thinking and problem solving that has to be done with web design because there's so many different layers to it. There was a point in time where it was really close and the web was mimicking graphic print design, which was why you would get these brochure things and people would be like, it's gotta be pixel perfect and all of this stuff, but now, it's completely its own medium and has a whole different set of circumstances and things to think about, and it's a lot. It's a lot. - You're thinking about internet speeds, users, what device they might be on. Are they on the bus? Are they at the bus stop? Is it raining outside? How is that gonna change how they interact with something? That it can be just stripped into so many different levels is kind of exciting and really cool. I don't think that graphic design has that. - This is natural, and just happens all the time. Whenever a new medium comes along, you tend to borrow from the medium that's come before because it's what you know. For the web, it was print that had come before. There was a lot to learn from print, around typography and colour and white space and all of that, and processes and workflow, as well. We had processes that worked for print, and we adapted them for the web, but they were more or less the same, the same ideas of how something would be in production, and then something as finished, and then something as published and it's out there. That's not actually the way the web works. The web can be this constant iterative thing. - There's this concept of being final. You've made something, and then there's this sort of sweet relief of being done because it's final, but on the web, we just don't have that. I just launched something this morning. I immediately had about 15 tweets that said, oh, this looks broken or this is here or this just doesn't sort of scale right or whatever. Within 10 minutes, I was able to go back, take that feedback, implement it, and then push it back out, and said, "Thank you, internet, for making this thing better," for fixing my problems. - So, print and its 500 years of technological evolution may not always apply to this world of screens we're on. That really became obvious to all of us when mobile came along. Let's take a listen to our friends again and see how mobile broke their process. - When I first started building websites, we only had basically one screen size to focus on, 800 pixels by 600 pixels. Then gradually, over time, those got larger. 1024 by 768 was the monitor I had for the longest time. You'd build websites, you'd lay those out in Photoshop to fit the space that you had. As screen sizes got larger, so did the websites that we built. - Then when the phone came around, it was like, okay, well, I just have to worry about this 1024 by 768 and then this 320 by 240. That's all I have to worry about. Then tablets came around. - It was a sort of thing that dawned on me where I realised that, essentially, all of this custom stuff I was doing with CSS to these HTML documents, in some ways, was breaking the portability of those things, and that having to pinch and zoom around a fixed-width site is not ideal. - I was pretty aware of the responsive work that Ethan was doing from a very early stage, but I don't think I knew the term until I saw him speaking. I think it was the Event Apart in Seattle. He blew everybody away. Everyone was like, you could sense people in the room were like, holy shit. (laughs) I remember Eric Meyer had been talking about media queries. Then Ethan came up and said, "Oh, yeah, "I got media queries," and just threw his mic down and just blew everyone's mind. - There was something about the talk. You could feel it in the audience. It became more and more electric. It was like, yes, yes. This is a thing that we are witnessing, that this a huge shift. It's not a shift that's coming, it's not a, hey, one day you're gonna be able to do this, this is right now. - I remember I pulled up Ethan's demo in the browser, and I squished it, and I realised that this thing was going to dismantle my process completely. That the way that we worked with each other at Paravel, that was all gone. Now I had to find a new way to sort of express myself creatively to solve problems in a new approach. So my first reaction was this is terrible. I wish it would go away, and I don't wanna deal with it. (laughter) - There was no denial for me. I knew it was right and I knew it had to be-- - [Interviewer] You just didn't wanna do it? - I just dived into depression. I don't know whether I've got the energy anymore to learn yet another major thing. I can just about cope with that kind of incremental evolution of the web that goes on the whole time, but when you drop something major on me like that, it's like, okay, where we go again. It was that kind of feel. - Had to let go of the way I liked to design, by myself in Photoshop, kind of thinking through everything, but really embracing responsive web design as a practise and using all those tools to think of pages as networks of content and components. The minute I did that, I sort of found a new way to control the process and to be creative within all of that. But initially, I thought it was terrible. It moved my cheese. - So Steve Jobs moved Trent's cheese. (laughter) But then Ethan Marcotte and responsive web design gave us a new way to look at our work, a way that's closer to the medium for which we're designing. As those devices have multiplied. Yeah, that's a good one, right? Responsive design has become the de facto standard for how we design for the web. But responsive design isn't just a handful of CSS techniques. It's a different mindset. A mindset that was very well described 16 years ago by our very own John Allsopp right here. You can clap for him if you want. I would. (applause) John's very prescient article, A Dao of Web Design, told us that the every-changing, fluid nature of the web wasn't something to be fought against, but to be embraced. It's a feature, in other words, not a bug. But many of us, as designers, come to this field out of a desire to create order out of chaos, to make things better when we see something wrong, to control things, in other words. That can be a hard thing for a designer to accept, this kind of mindset, because it's a mindset that's about ceding control. - It's really interesting. As I've grown up and I've met more and more designers over the years, we're a certain type of person. I remember going out for a meal once with Mark Boulton. We were sitting at the table in the resistant. He started lining things up on the table, which is something I do. I don't know whether you do it, as well. Our minds just work in that way. We have this desire to create order out of chaos, to put things in a logical, ordered manner. - The web sort of requires that we control as much as we can, up until the point that we realise we have to relinquish control and that we have to let the content be consumed the way our users wanna consume that content or need to consume that content. - Ever since the web was introduced, it's always been this fluid environment, but I've seen a lot of designers fight back, trying to create this fixed world. I think that the more we embrace the fluidity of the web, the easier it is to manage. - There's always this tension between what we want the web to be and what the web just kind of is. When we finally figured out that there's actually a mobile web out there, it's like, no, we need all these massive device databases and we need separate mobile and desktop websites and we need to ensure that we're designing for those contexts. Web kinda just defies easy definition, basically, is what it comes down to. The less things we try to control with it, I think the better we do as an industry. - The main thing that I learned, working with these mobile devices, is that you really can't count on anything. That was a while to get to that point in my process where it's just like, hey, maybe it's okay if things are a little broken and accept a little grey. - In the past, where web design was maybe more of a one-way street, where the designer was dictating the terms of engagement, saying, okay, you're gonna be able to access this website and do what you need to do, but you must have a fast connection, you must have a web browser with certain capabilities, you must have a screen that's a certain size. Now, it's much more of a two-way street, more of a conversation, where the user's saying, well, I'm using this browser on this kind of device or computer. The designer's saying, okay, I can accommodate that. You're not gonna get the same experience that somebody on a better browser or bigger screen is gonna get, but I'm gonna make sure you can accomplish your task. They key thing, though, for a designer to be able to do that is that they have to give up the idea that there is one canonical way that this website is supposed to look or feel. There's gonna be different capabilities. That's not a bad thing. - It's not a bad thing, as Jeremy points out, to have different capabilities and different experiences on different devices. In that way, responsive design is a natural continuation of progressive enhancement. But responsive design has also meant for us, as designers, bigger and more complicated problems that we have to solve. When we're trying to solve these bigger and more complicated problems, how can we know that we're making good decisions? Steve Jobs said, "Design is not just what "it looks like and feels like. "Design is how it works." When we talk about how it works, it's hard not to start thinking about the design of user experiences. UX as a practise says that we can't just assume that our designs work the way that we think they do. We have to put them in front of users. That requires research, observation, testing and iteration. Iteration means a more fluid, adaptable process. A process which, perhaps, makes even more sense in this responsive world that we've found ourselves in. - Plenty of research is extremely helpful when it comes to local optimization, trying to maximise the value out of the design that you have, but it doesn't lead to large conceptual breakthroughs. That's where qualitative user research can be very helpful. - A lot of research right now is happening where people have an idea or they have a product and service, and they wanna figure out what are the needs and behaviour of people that we either wanna have be our customers or our current customers. What can we do to innovate our product or our service or what can we do to take it to the next level? - This concept of going out and listening to people and hearing the way that they think sounds a little like it could be open to interpretation. It sounds a little rickety, as compared to numeric analysis, as compared to all that reams of data that you're getting back every second from the interactions that your customers are already having with your offering. But the thing that the numbers don't show you are what that person is thinking. They tell you what that person did. It doesn't say why. It turns out that when you start using people's words and looking for patterns between the way different people think, you get correlation. You get pretty strong correlation. You get repeatable correlation. - Once concept is nailed down and there's a general direction for the point of view, then usability testing comes in really handy to try to get at the specific designs of the flows or the interface, the language, to see if it makes sense to people and if the experience matches their expectations. - What you do, in essence, in usability testing, you sit someone down in front of the design and you sit back, and you don't say anything. Just basically say, "Please use this." They don't see the same design you see because the design you saw had all of the knowledge about its inner workings and all the knowledge about what the client or stakeholders wanted this thing to do and all the knowledge of what came before it. To them, walking up to this thing, it's like, what the hell is that? I'm not sure what I'm supposed to do here. - The best application of usability testing that I've found is when it's done very rapidly and iteratively. You have the full team involved, and they're engaged and watching the studies, and really understanding what's working, what's not working. Then taking those insights, after just a few participants, to iterate again, and then go back into the study to try alternative variations. - We keep treating these tasks as these independent silos, when they're so much more tightly linked than we might like to think. The best projects that I've ever worked on, they're tiny iteration loops over design and development. That's how we worked with The Globe, where we would knock out some designs into a responsive prototype. We'd test them on a bunch of different devices. We'd take art direction from that point on. The design that we were basically vetting and critiquing was live HTML and CSS in the browser. I think the more prototyping I'm able to do earlier and earlier in the project has been great for testing things like performance, whether it's actual or perceived, for figuring out what kind of content issues are we gonna have, we move from one screen type to another. That's changed the way that I work. More prototyping, more actual device testing as a design tool has been a really big help for me. - There's nothing more valuable than a prototype and looking at the site, using the site in the browser, getting a feel for how it is and how it moves and how the content lays out. I think once you get a little bit of practise doing that, you can still use image layout tools, if those are the quickest thing for you, but I use those differently now. It's more of a quick iteration, quick idea thing. Over time, once you get an idea for how content's gonna lay out on a page and how it's gonna change and re-architect itself at different viewports, you can use those tools, understanding the implications of the choices you might make in Photoshop, understanding what you may do there. Basically being accountable to yourself as to how that's gonna actually function and work in the browser. - So what we're talking about here is an iterative cycle of research and design, where we would start with generative research. Generative research is simply research which generates new ideas. Those might be stakeholder interviews or user interviews or diary studies. Then taking the information that we gain from that initial research, and then moving into our initial designs. These may be comps or functional prototypes of some kind. There's something that we can test because the next thing we want to do is do some evaluative research. That, of course, is research which evaluates an existing design. That might be usability testing or perhaps A/B testing, or if you have two things we want to compete against each other. Then we can take the insights that we've gained from watching people who aren't us use our product, and roll that into a period of refinement with the designs. Now, what we learned from that testing, some things will be pretty straightforward. Oftentimes, there are words or language that we're using, and people didn't get it. There are multiple interpretations of a word or homonyms, and they interpreted the other one, so we change the word. We know that's going to sort it out because people understood the other word. Easy change, great, don't need to test it again. There may be other situations where whole interfaces could be wrong. People just couldn't use the damn thing. That's it. We need to try something else. We need to replace it with something wholly different. That's something that we need to go back and test again, having another round of evaluative research to test our new assumptions. Then refine again. This is a process that we can repeat as many a times as time and budget and the need for it allow. That may mean that we actually discover things that are wrong with our designs we don't even have time to fix, but that's okay. That's better than not being aware of them at all. It means we can come back to it at a later time and address it, if it feels warranted. Now, this iterative approach we're talking about requires a lot of skills. That probably means that a web designer is not alone. It means they're part of a team. - Good web design is a team sport. I think you need a lot of perspective to solve problems. - Multidisciplinary teams that are working pretty closely together, that can have conversations about is this gonna be able to be implemented and is this gonna be performant is really important. - Now, we're trying to be more iterative, we're trying to be more true to the web. A lot of that involves much more collaboration, much more just having people sit together and work through stuff, people having complementary skills. They aren't working in silos and throwing things over the wall, but they're sitting down together and figuring stuff out. - Designers and developers, I think, can work incredibly well together. We've got two guys at Headscape. We've got a guy called Dan and a guy called Ed. Ed is our designer, and Dan is our front-end coder. But Dan knows how to do a bit of design, and Ed knows how to do a bit of code. They work so great together. There is tension sometimes, and they argue and disagree with one another, but it's a really good, solid relationship. They sit side by side in the office and they work together. They produce amazing stuff because there's no division between them. There's none of this throw it over the wall. - One of the challenges, I think, with a lot of early digital product design was that it was driven by this visionary sensibility, in terms of that high level, big picture, motive quality, but the figuring out the details often wasn't part of that equation, and so the experiences would fall apart 'cause they just wouldn't work. They wouldn't make sense. It would be hard to use. So the user experience folks are coming in with this more bottom-up, let's understand all the piece parts and how they can work together and how we can organise them to create something that people get, that people fundamentally understand. The shortcoming of the user experience approach is that it often lacks that emotional tenor. It can leave people feeling flat. The projects that I've worked on that have succeeded best are those that marry that bottom-up user experience view and top-down, big picture view, and where those groups are working together. - You can't do any of this stuff by yourself. You're really bound to work with the people on your team. If it's a client services thing, you're bound to talk a lot about the build with your clients, and you're having to share and talk about different views. Everything is multidimensional now. It makes the process a lot dirtier, but also, I've found, a lot more rewarding. I think, kind of at the end of the day, it takes a lot more from the entire team, a lot more trust, a lot more communication. The things that you ship at the end of the day, usually, you're more proud of because of it. - So the ability to communicate and collaborate well is at the core of being able to work well with your team. I've spent years now developing relationships with the people I work with, friendships, really. That makes it a lot more fun to come to work, honestly, but I also think it greatly improves the quality of the work we can do together. When we put all of these different people together, with different skills and perspectives, it can be hard to see eye to eye sometimes. To make this happen, it can be useful to apply some empathy that we can use to help us in our collaborations. - In more practical terms, just how we build websites has changed quite a bit. In my experience, we need bigger teams, lots more specialisation. It doesn't necessarily take more work, it just takes thinking about things differently, from a different point of view and a perspective, and a lot of times, just more communication. - Being a designer, and not just a lead on a project, being a designer or a developer, or anybody on a design team, on a project team, you have to be aware of the needs of other people on the team for them to see a successful project. - It's really funny. We differentiate between designers and developers a lot, and we talk about how different they are. But actually, I think, in a lotta ways, they're very similar. A developer, a good developer, is lazy, aren't they? They try and do the maximum with the minimal amount of input. They make their code work as hard as possible. I think a good designer does exactly the same thing. They create interfaces that are as minimal as possible, but achieve the best results. Designers like to bring order to chaos. Developers like to bring order to chaos. I think we've actually got a lot more in common than we think. Okay, one of us works in a very visual way and one of us works in a code-based way, but I think our objectives are very much the same. - I believe that there has to be a very open relationship with the client, very open relationship with a design team, to discuss mutual goals, to discuss business goals, to discuss any kind of process. I think those are all collaborative and unique per project. To me, really the core value of anything I do is about that collaborative relationship between a client and the team. - What I'm interested in is the cognitive empathy. What is the reasoning there? What is the stuff that we can interpret that isn't open to interpretation? What is the stuff that we can reliably find patterns about? The idea about this kind of empathy is that it is harnessable. You can use it. It's not a method so much as a mindset. It's a mindset of I wanna understand what you're thinking, how are you thinking. Have you ever been in a conference room where one of your teammates is really upset about the idea or the decision that's been made? You feel that tension in the room. You're like, oh, the meeting's over. Good, okay, bye. You grab your notebook or whatever and walk out the room because you don't wanna feel that tension anymore. But if you have this cognitive empathy, curiosity mindset, you close your laptop, and you stand up and look at the other person. You say, "Hey, I realise I don't understand "where your reasoning's coming from. "Can you tell me?" That starts that collaboration process. That lets that other person know that you are open to hearing him. Being heard is the number one human need, especially in our professional areas, being heard, being understood. - So, we're likely to be working in teams. These teams could be made up of people with all kinds of different skills and backgrounds. Content strategists, project managers, accessibility experts and what seems like one of an infinite variety of developers. It can be hard to keep track of what all these web skills even are. Milton Glaser said, "To design is to communicate "clearly by whatever means you can control and master." But with so many different skills to master out there, what do we even expect from a single designer? - The thing is, it's just the inevitability of an increasingly sophisticated and complex platform, like the web, that we have to specialise. That day when you had the person who pretty much knew everything from the server and how to optimise that through to optimising the front end, I think that day is, in some ways sadly gone, but the truth is, as a platform gets more complex and sophisticated, that's just a reality. I'm sure when they first made cars, there were people who pretty much could build a whole car and design it, and certainly with early aircraft. The Wright Brothers built the plane, then they flew the plane. But as those systems get more and more complicated, it's just a reality that no one has enough time to specialise enough in the areas where they work. - When I was building the team at Yahoo, we would take people, we would draw from all kinds of disciplines, library science, architecture, graphic design, computer science. I found that the best designers were ones who really have interests and strengths across multiple disciplines because user experience is such a multidisciplinary field. - I was the biggest pain in the ass when I moved into this industry. The guys who I worked with, I worked with this amazing team who brought me in and they taught me how to design for the web, I questioned everything. Why can't I make the text circular? This is back in 2002, when it made no sense to do something like that. This was something very difficult to do. Why can't I kern all my letters? What can't I use small caps? I learned the hard way by doing everything wrong, and seeing it happen and see why those things didn't make sense to do, why it caused more problems, why it was difficult to interact with things. - I do think that that contributed a lot to my own success because that's my own technical background, 'cause I majored in electrical and computer engineering as an undergrad, my own technical background made it possible for me to relate to the engineers that I was working with at Netscape and Yahoo in the early days. I could establish relationships with them, I could empathise with them, have credibility with them and negotiate with them much more effectively because of it. - There's a lot that goes into making a website. I think it's kinda like you know what areas you're the strongest in, and then it fizzles out from there. It goes the same way for a developer. They should have basic design understanding. They should know how to extend a system, the same way as a designer could go in and start finessing typography and code and that type of thing. I think it's more about meaningful overlap and figuring out where your role overlaps and where you're specialising. That's the most important. - So let's take a practical example here for a minute. We'll take someone that we could call a communication designer, somebody that comes out of school feeling really comfortable designing user interfaces. Then, after some time working in a multidisciplinary team, maybe they pick up some front-end development skills, perhaps just a little HTML and CSS so they can render their own designs in the browser. As they spend more time with these teams, they start getting a basic understanding of user research, content strategy, information architecture, by osmosis, if nothing else. Maybe a little big of project management so they can champion their own designs directly with the client. This starts to look like a pretty well-rounded designer. They have a primary expertise in user interface design, a secondary focus in front-end development and then a broad understanding of adjacent skills. We can imagine other skill combinations that are equally helpful. Let's take another example. How about someone with an additional training in front-end development? Then perhaps spending time building CMS-driven websites. They spend a lot of time thinking about content and data models from building that side of the system. Of course, they become drawn to content strategy, which actually has a lot in common with structuring CMS. Over time, these skills start to improve, and their expertise becomes even more valuable at the outset of the project, where they have the ability to plan the content strategy while factoring in the technical constraints, based on their knowledge and experience as a web developer. Again, we see that they have a deep expertise in one area, and a strong secondary focus, and then that broad knowledge of adjacent fields. That makes them a very useful team member. This really starts to beg the question that I'm sure some of you are thinking about, should designers code? Guess what? I'm not gonna answer that question. I'll let these suckers do it. Here we go. (laughter) - I started thinking about doing websites in 1995. I had a friend. He had a website, and apparently, it was doing really well. I was talking to him about it. He was like, "Yeah, it's cool, buy you're gonna "have to learn how to do computer code." Said it really seriously, like this is some serious stuff, and like, I don't know if you can handle it. - It goes without saying, I think. Web designers should know code. Print designers should know how print presses work. - It may not be know every single thing about code and every best practise out there, but knowing what that technology is capable of, whether it is HTML and CSS or you're moving into JavaScript and HTML5, the rich video and audio elements, knowing the capabilities should then come back into the early design process, but I think it doesn't hurt to code just a little bit, if not a lot. - Web designers should understand the concepts of CSS and HTML, to the point where they can use it to benefit the interactions and the builds and the systems that they're creating. I know HTML and CSS. Am I going to build a production-level site with it? No, I shouldn't because there's a point where you begin to understand your strengths and weaknesses. But can I talk with a developer about it? Do I understand how responsive design works? Yes. - Having a good understanding of the fundamentals of code is really good and helpful for a designer. I still think that there's benefit to someone that is specialising in design, but has a supplementary understanding of development. That's what I do. I try to be really mindful (laughs) of development and how I work with developers, but I'm not a developer. - I still very much consider myself a designer, not a developer. I think that that's been one of the most revealing things. The biggest epiphanies for me is, like, yeah, this whole code thing is actually still design. I feel very often I have a better understanding of how this stuff works in its final environment than the other designers who are working in an abstraction. - Once you learn HTML and CSS, it really clicks and you understand why you went through that entire journey of doing it, but until then, it doesn't seem like (laughs) it makes a lotta sense to do it. I kinda try and think about it a little bit like fashion designers. Fashion design has been something that people have practised for a long time. It has a long history. You wouldn't expect someone like Marc Jacobs or a big name fashion designer to sew his own clothes, but he knows how to sew a prototype or at least to create a prototype enough to send it to somebody to make a production-level design. I think that's really what it comes down to, is knowing enough to be able to communicate properly how to build or make something. - So, designers are still designers. That's their primary field. But when your medium is the web, you do need an intimate knowledge of that medium to be truly effective as a designer. That probably means knowing at least how HTML and CSS work. The better you get at HTML and CSS, and perhaps JavaScript, the more opportunities you're going to have with regards to rendering your designs in the final medium. If you care about your designs, which I know we all do, that's pretty cool. Now, this idea of designers working in code is not a new idea. In fact, Andy Clarke, who we're lucky enough to have where with us at this very conference here today, was writing about this years ago. Andy's 2008 article, Time To Stop Showing Clients Static Design Visuals, argued for designing directly in the browser. When I read that article, at the time, it completely changed the way I thought about design process and what was expected from a web designer, so thank you very much, Andy. But if code is one direction a designer might move in, what about that most nebulous of terms, user experience? Well, Peter Morville said, "The design of good houses "requires an understanding of both "the construction materials and the behaviour "of real humans." If HTML and CSS and JavaScript are the web's construction materials, then human behaviour really starts to get at user experience. But when the term UX comes out, I find there's often a little bit of eye rolling from at least one corner of the room, as if to say, what does user experience design even mean? Come on. Other than, obviously, a discipline which aligns itself with the importance of sticky notes. (laughter) Luckily, I made a movie about this stuff, and I talked to a whole bunch of people that were pivotable. Pivotable? That a American word. (laughter) We're working on a bunch of new ones. (laughter) In the development of the user experience field. Let's see if those folks can't clear this up for us a little bit. - User experience design is a more holistic way of approaching design than traditional, say, graphic design practises. User experience design takes into account interaction design, information architecture, usability engineering, as well as graphic design, and kind of is an umbrella pulling all these things together, recognising that a user's experience emerges from the interaction of all these different feeders, as opposed to being any one thing. - The user experience design is about how you move people through the experience. In contract to graphic design, which is more about aesthetics and what you see, which is also very important, user experience is about the flow. It means that you have to understand what motivates people. How do they think? How do they feel after the interact with your site? It's about understanding people's needs and helping them achieve their goals. - So user experience design typically focuses on the functional and systemic design qualities. How are people going to move through or engage with a digital product? When you click a button, what happens? What's next? When you're creating a menu or some navigation structure, what are the things that you put next to each other and why? What are the things that you put within those categories and why? Those are the elements that are typically considered user experience design. - There's all sorts of other tools and practises that fall under user experience, such as usability testing, interaction design, which is designing the way that software reacts to a user's input, essentially. There's information architecture, which itself is a big, expansive field. - Information architecture, to me, has always been the central part of any kind of experience, whether it's online or in print. It's the way content is laid out and displayed. It's the way information is presented. It's organisation of that, the prioritisation of that. Now, as we get into interaction and pathflows, it becomes the way that we see through an experience and how we get from point A to point B, and what happens in between. - Information architecture, writ large, is the design of any information space with the intent of making it findable, accessible, understandable. People don't get lost trying to figure out what they're doing. They're able to find what it is they're looking for. How do I find the right product on Amazon? How do I find the right clothes on Gap.com? Whatever it is. Those are information architecture problems. What are the categories? Men, women, children, et cetera, for a clothing store. How do then, within men? Is it tops? Is it shirts? If it's tops, is it jackets and shirts? Within shirts, is it causal, button down, dress, formal? All of those labels, that's information architecture. - A good user experience professional needs to understand how to do research, needs to understand how interactions are designed, needs to understand how information can be designed, needs to understand the architecture parts of the information, how you create the navigation of the design or how you organise the content within the design. Needs to understand the visuals, how you make something both aesthetically pleasing and, at the same time, prioritising the visual information so that the most important thing the user needs is the thing that jumps off the screen or off the device. Whereas, the things that they might need down the road become evident at that moment when they need it. Needs to understand how to work on a design team because there's a lot of effort that involves iterating and changing how things go. Needs to be able to get feedback from users, bring that in, needs to be able to say no, that's too much functionality. That thing is not going to make the design better. It's just gonna add complexity and make it more complicated, so let's just leave that out. That sort of editing curation capability is really important. - I like how Jared Spool looks like he's in a 1920s speakeasy at closing time. (laughter) I had to film in some weird locations, let me tell ya. What have we learned about ourselves today, fellow designers? For one thing, it's a bigger, messier world out there that we're designing for. We've outgrown graphic design. There are lots of good lessons to be taken from branding and print, but we can't be limited by its assumptions. We must be flexible. A web design's endpoints are nearly infinite, as opposed to the fixed solutions that you get in a print world. We must design flexible systems, not singular solutions. We need to be flexible in our perspectives, as well. We must embrace teams. The web is too big and complicated to go it alone, so it's important to learn which other disciplines there are that complement your own and improve your collaboration skills to work with them. We have to specialise and overlap. Specialising in a single area, with a secondary supporting area, and a broad understanding of those adjacent skills that help us collaborate better with other people. There's so many useful skills for designing for the web these days. There are many ways that you can choose to develop as a web designer. Lately, I've been envisioning the web designers' professional development as one gigantic Venn diagram, where ya might find one team member at the intersection of design and code and UX, and another that's more devoted to just design and code. Perhaps a third is focused on just UX and design, and a fourth, who splits their time between code and research. Now, these are four designers, but these four designers can accomplish a lot together. They can shift the kinds of tasks they work on from project to project, and even from phase to phase within the same project. That makes 'em very, very useful team members. This may seem like a lot to take in and a lot for you to master, and it is, but isn't that why you got into this business in the first place? The web never sits still, and neither do you. That's why you love it. That's why you chose to work on a planetary consciousness. You can handle it. Why is that? Because you're awesome, that's why. (laughter) I'm Matt Gryphon. Thank you very much for listening. (applause) Are we gonna do a little Q and A? Do we have time? - Does anyone like to ask any questions? Any questions, comments? We do have a couple of minutes. - [Matt] I've brought these-- - Oh, he's got bribes. - Hand-Printed Bearded notebooks. I've got a few of them, so if you ask a question, no matter how bad it is, I'll still give you a notebook. - [Audience Member] Can I have one? (laughter) - I'm not even sure that's a question. Is that a question? - I'm a designer, not a ball player. - [Audience Member] Hi, there. - Hi. May I have one? (laughter) I am that dad. (laughter) When my three year old asks, "May I?" (laughs) Just over here. - [Audience Member] Excellent. I just had a question around where does strategy, I suppose, play in that Venn diagram of yours? I noticed there was a few different ways that you can get involved, but there's design strategy that's been really growing in our field, so how do you see that going? - That's a very good point. A lot of these terms, it's so hard to define what the correct terms are. In fact, when I talked to various people, like I talked to Jared Spool and I talked to Indi Young and Karen McGrane and all these people who identify as people in the user experience profession, getting them to agree on what all these terms mean exactly is really difficult. What is strategy? What is design strategy? You could argue that that's at the nexus of design and research. You'll also notice on that Venn diagram that, unfortunately, the way Venn diagrams work, not all of the things overlapped in the correct. You couldn't be at the nexus of a thing that's over here and over there, which is totally false. You can totally do whatever you want, guys. Don't listen to that Venn diagram. (laughter) Don't let the Venn diagram pen you in. I don't know. Strategy, to me, feels like anyone who has useful knowledge and experience to contribute, hopefully, at the outset of the project, and not at the end of the project. When we have strategy sessions, we want a designer in the room, we want a developer in the room, we want a content strategist in the room. We kinda just want everybody that's gonna work on the project in the room at the beginning, partly so that even if they're not a person whose personality tends to push forward ideas and contribute, that they're listening, absorbing, so they can be processing that later when they're doing their work. For instance, I found a lotta times developers, even if they don't feel they have something to contribute at the beginning of the project, we should put them in there because later, when they're doing the part that they're excited about, they're gonna have all of that understanding of why they're doing what they're doing so that they'll be less frustrated and feel more empowered to make good decisions when they get to unknowns. Is that good? How do I get you one of these? Do you wanna come up? Here, you come up and I'll hand it while we do the next one. Or is that too hard? All right, you're a book runner now. (laughter) You just diversified your skillset. (laughter) - Okay, we got time for one or two more, perhaps. All the way over. Do you wanna run all the way over here? Poor David. (people talking) - Don't worry. You're just starting out at this. (laughter) It's gonna get easier. - [Audience Member] Hi. (clears throat) We currently have a CTO at our company that really believes in full stack developers, or pretty much full stack everything. Traditionally, developers have done pretty much everything, front end, back end, design. - Flow in the plane. - [Audience Member] I need something to tell him, essentially, because you seem to be adamant that full stack developers, or full stack anything, doesn't exist. You only have specialists with somewhat rounded knowledge of the rest of the fields. What would you say to him? - Maybe do a job posting for the title webmaster and see what kind of applications you get? (laughter) See how that goes. 1990 called. It wants its job posting back. (laughter) Really, I would just explain. Who knows what people listen to, right? But try to explain that there are an incredible number of skills and fields that are out there right now that make up the web. I think John's explanation was really good. When you built the first car, you could probably do it all yourself, but is there one person out there right now that can build the whole car? Who's building each Tesla? There's one person in the back cobbling it together. That's not happening. Maybe that analogy will help. The web has gotten to that point. You can let him or her know that in 1990, we did have webmasters and they did know how to do all of it because there wasn't as much to know. Now, there's way too much to know. Front-end developers can barely keep up with front-end development, much less all the rest of it. (laughter) Ya need a good team with a disparate set of skills and that are nice and can talk to each other. - I think Aubrey's point to having a job description which has more than five requests actually turning people off and lowering the quality of applications speaks to this in a more subtle way, as well. I think that was a great point that she made, and I think it ties into your thinking, as well. - [Audience Member] T-shaped people. - T-shaped people, that's right. Who's next? - This lady just down here. So where's David? - This is the last one? - [Audience Member] What was the most surprising thing you learned during the filming? I would expect that you go to talk to these people, you expect their answers to what you want to hear. Was there anything that was out of the ordinary? - The most surprising thing? Okay, I can do that one. I went in with a few different assumptions. This is part of what really changed my perspective on the web, in general, I think, and what actually became the movie that John and some other folks watched last night, the real core of it. I went into some of these questions, asking designers things about, tell me about designing for Flash, tell me about designing with tables. My question at the outset was Flash, right? Or tables, right? (grunts) (laughter) Then, the people that I talked to that were really in full swing in their career at that point had a totally different reaction. They would say, "Yeah, yeah, I know." Like, I know kid. They're bad now, right? But at the time, that's what we had to work with. There wasn't anything else. If you wanted layout at that point, you had tables, and that was it. You had tables or ya had nothin'. We used tables until they gave us something better to work with, and then we started using CSS. CSS Zen Garden came along. We went, oh, wait, this is great. Let's do that. Until we needed video and audio, and then we had Flash. That's all you had. In 1999, damn right, I want a Flash website. That's the best thing out there, until you give me something else. But the W3C was totally preoccupied with the semantic web, and wasn't giving us anything. IE wasn't creating new features because they had won the browser wars. Everything had stopped. You had Flash or you had not that much. That was a real surprise for me, that I went in there going Flash and tables, and they were all like, no, actually, Flash and tables. (laughter) It gave me a totally different appreciation for the trajectory of web. Honestly, it reframed the whole thing for me. That's how we do web. We do it the terrible, ugly way that we have at our disposal right now to push forward the ideas and prove that it's what we need and what's gonna work. Then once that gets some momentum, then we figure out how to do it the right way. We build the plane while we're flying it, which is, by the way, not a good idea with planes. (laughter) Is that it? - All right. I'm sure we could go on and on, and we can, just outside the door. - I'll be out there. I've got three more. - Three more, three more questions. Remember, too, there's this fantastic, if you haven't gone and talked to some of those students about their work, it's amazing, fantastic, very fun to play with. Other things to experience, please go and do that. Please stay until six o'clock when we'll coming back, and Jen is gonna delight us with some special stuff. I can't wait for that. But in the meantime, let's thank Matt and all our speakers for today. Been a fantastic day. (applause)