Hey everyone and welcome to Developer Tea. My name is Jonathan Cutrell and in today's episode we're going to continue the interview with Jessica Ivins, Jessica works at Center Center as a UX educator. If you haven't listened to the first part of the interview, I encourage you to go back and listen to it as well. We talked a lot about learning on that episode and today's episode we're going to be talking about user experience for programmers. So I hope you enjoy today's episode with Jessica. There is not an explicit sponsor for today's episode but I will encourage you to go and check out spec.fm. There are other shows that you will enjoy if you enjoy Developer Tea and you should subscribe to those shows as well as Developer Tea and whatever podcasting app you use. Go and check it out spec.fm. Of course you know the show notes for this episode and every other episode of Developer Tea are at spec.fm but spend some time clicking around and looking at the other shows and the other content providers on spec. Go and check it out spec.fm. I hope you enjoy this interview with Jessica Ivins. Jessica welcome back for the second part of the interview. Let's kind of recap the first interview if you don't mind. What did we talk about on the first interview? So we talked about, wow I feel like we talked about a lot. We talked about what UX design is. We talked about choose your own adventure learning which is creating a learning plan that is tailored to your own style of learning, a way of learning that excites you and a way of learning that works well for you. Oh geez, we talked about so much but I think that generally captures it. Yeah I think that covers a lot of it. We stopped around the time that you were talking about finding a learning buddy and finding ways to reflect on the things that you've learned. You mentioned a stand up meeting and you also mentioned getting somebody else who is like you're saying the learning buddy. Someone else who is really interested in a particular topic and reflecting with them discussing the things that you are learning. And I want to make a little bit of a mandate to those of you who are listening and you have the opportunity to influence the working culture wherever you are. If you are a leader or if you have the ear of a leader, if you regularly meet with leaders and they are willing to listen to your suggestions, I suggest that you start doing 10 minute stand-ups at least twice a week. This is such an important part of a working culture especially for in my opinion especially for developers. Jessica, imagine you would say that this is important for pretty much any working environment where people are focused on things that they need to be learning as well on a regular basis going through that feedback loop. So recommend this to your coworkers, see what they have to say and bring that learning feedback loop into your day-to-day work and more specifically a couple of times a week. That's what I've found has been really successful for our development team at Whiteboard. It gets us into a rhythm and it gives us enough time between, we actually do Tuesdays and Thursdays and it gives us enough time between those 10 minute stand-up meetings and we have few enough people that the everyday stand-up doesn't seem to yield as good of results as the two times a week. Do you have a recommendation on that Jessica? Yeah, so I'm not really sure what to recommend in terms of how often folks who are listening should do stand-ups or how they would benefit from a certain number of stand-ups. I think starting out twice a week might be a less daunting way and a more friendly way of trying it out with your colleagues. But I'm not really sure. I would say that I'm so used to it now at Center Center. We do it every day and it works for us. But I think it's a matter of just trying it out and seeing what works for your day. Yeah, I agree with that. The thing that we found that is so important is just to have kind of a touch base with everyone. And this functions for a lot of different specific things when it comes to team dynamics. Obviously, the learning portion is possibly the most important part is as I learned something and I share that information, not only do I learn it better, but other people are enlightened by my experiences. And I'm enlightened by other people's experiences. As other people learn, they share that learning moment with me. And now I know, for example, if I encounter a similar problem, not only do I have a little bit of information from them, but I also know, hey, that person has encountered that problem, I can bring them over to my desk for five minutes and they may know exactly what to do. And rather than me banging my head against the desk for hours on end, because I just didn't know that somebody else had already solved that particular problem. So that's super helpful. Another piece that is really helpful is just having that kind of culture of discussion on a given team. And this is really kind of one of those soft skills kind of things. But when we have a regular rhythm for our team to kind of gather around a table, I've noticed that we are closer as individuals, as people, and we share more where typically people call this morale, but I don't like calling it morale because there's even a business reason to do this, right? There's a business reason to break down the barriers of communication between two developers. Sure, they're happier when you do this, which is important. But it also happier workers typically tend to work better together. And so that's an important part of the standard meaning is that we're coming together around a table. And maybe we spend two minutes of our stand up just sharing a funny story with each other. And that's totally okay. That actually invests into the company and invests into our individual learning experiences and invests into our camaraderie as a team. Again, this is getting way into soft skills land. But I just recommend that people try this out, try this idea of talking to each other in person. And you mentioned a learning buddy. I also recommend going to lunch once or twice a week with one of your coworkers with the specific intention of talking about something that you're learning. There's a book I think it's called Never Eat Lunch Alone. I've never actually read it. It's a disclaimer. The book discusses the idea that lunches are such a cool, not just lunches, but your breaks. Don't allow them to just pass you by. Use them for something that you actually want to use them for. Yeah, I love the idea of learning during lunch. Yeah, I think that's great. Yeah, and it could even be in the office. It doesn't have to be like a big thing. You don't even have to answer. Sure. Yeah. We're going to have one corner of the cafeteria and the three of us who are really interested in getting out about learning are going to do this. What I've noticed about those kind of things is that once you start small and it's working really well, you'll attract like minds. So the group could even grow. If it's just something that you're doing every day and people find out about it and they're like, oh, that sounds cool. I want to be a part of that. It could be an organic thing. Love the idea of doing it over lunch. Yeah, because everyone has lunch. Everyone has to eat. And so if you already are doing that, then who wants to eat alone? First, I mean, I guess I as an introvert, I enjoy my alone lunches. But if you're only doing it once or twice a week, then that's not really that big of an investment anyway. But it could make huge difference for your learning processes. It's interesting you say that because we have a weekly lunch and learn at Center Center. So every Friday, we watch a video. It could be an online seminar or it could be a recorded presentation from a conference. And we watch that. And we use a tool called MySpeed for the browser. That basically what it does is it speeds up audio without sacrificing audio quality. So you can watch something. Once you get used to it, you can even watch something double speed and it's fine. You have to kind of work your way up to the speed though. I usually go 1.5. That lets us get through a presentation quickly. So we have an hour for lunch. So we watch the presentation, we take notes, and then we have a targeted question at the end of the presentation. And that targeted question could be, what's one thing you learned that you didn't know before you watched this presentation or seminar or whatever it was? And then we go around and we briefly share. And that in itself is a way of reflecting. It's once a week, so it's not something that we ask people to do every day. And I think just the key is reflecting on what you learned. You could watch it and be like, yeah, guys, it was awesome. OK, back to work. But if you just take the time to give each person a few minutes to share what they've learned and reflect, it helps it stick for that person. But again, it also helps you learn because they might have picked up on something in the presentation that didn't really resonate with you. And you might be like, wow, why didn't I think of that? Yeah, that is an awesome thing. I wouldn't have taken away from this presentation otherwise if my colleague didn't bring it up. That's another thing that you can do, especially if you're the kind of person like me who's antsy and doesn't like to sit down and watch videos. It actually gets me to watch one video a week. I'm just kind of, I don't know, I just don't like to, again, it comes back to your own learning preferences and how you learn. I like to read. But there are lots of things that I can't read because there are presentations or there are seminars. So this is my opportunity to learn once a week. Yeah, it also forces, well, it gives you the opportunity, maybe not forces, but it gives you the opportunity to apply an idea that comes from outside of your company to your company. So instead of only being stuck in the bubble, all right, you're only sharing your own opinions and circling or cycling those around the people in your company, you're also bringing in the opinions of outsiders of other people in the industry, typically well respected people in the industry, giving presentations, giving these kind of content, heavy presentations. And then you can say, okay, how do we apply this to us? How do we take this in and filter our opinions through it and see how it, you know, see what comes out on the other side? Because if you're only cycling your own opinions around to each other, then quite honestly, you're not getting all of the value out of what so much of the internet is made for is just sharing content, sharing information with each other. And there's just a wealth of information out there that is just waiting to be learned from. There's so much information. Yeah, it's a lot to keep up with. It is a lot to keep up with. You know, of course, we talk about that all the time on the show is how do we, as developers or really just as humans, how do we keep up with the ever faster internet that is swirling around us and all the content that we're supposed to be smart about? And, you know, we have this feeling that everyone around us is all keeping up faster than we are, but everyone else is drowning just as fast as we are. And so, you know, if you are feeling that way, this is just kind of a PSA. If you are feeling that feeling of, I really badly need to keep up. I recommend you go. There's a couple of episodes. I'm going to include the media consumption diet episode. Jessica, have you listened to that specific episode? If not, it's okay. I think I have. You know, I, I listen to your podcast regularly and that does ring a bell. I think I have this synopsis is basically that, you know, we don't eat everything that is healthy, right? Even if we are on a healthy diet, it would be unhealthy to try to eat everything that we see that's healthy. So why do we assume that even though there's so much good content out there that to keep up or to, to culture ourselves or to learn that we have to learn at all? And so I mentioned having a, you know, on a good diet, you have a specific caloric intake typically or you have a specific nutrient intake that you try to target on a daily basis. The thought is that you should, you should limit yourself to a specific amount of content in a given day. And this gives you a system that, that is maintainable, right? Instead of saying, well, let's just see how many articles I accidentally encounter every day. Well, now it's, I'm going to read three to five articles every day. And then you get more picky about the ones that you read, right? And you start spending your time more consciously. Kind of like imposing constraints on yourself. Exactly. Yeah. So I can only read three to five articles. So I better pick the ones that are most relevant to me or the ones that most excited about or whatever it is. It just kind of, it gives you a guideline for focused energy. Exactly. Yeah. I like that. Well, let's, let's shift gears. But first, I'm going to, I'm going to talk about today's sponsor. And then we're going to shift gears into the discussion on the importance of UX and UX for programmers. But first, let's talk about today's sponsor. Today is kind of a unique day because we don't have a specific sponsor. But I want to take the chance to thank all of the sponsors from this year. The sponsors of Developer Teahave made this show possible. So please show your support for the show as well as our incredible sponsors by heading over to spec.fm slash sponsors. We have a list of all of the people who have helped make the show possible over the past year. It's been an incredible year for Developer Tea and that wouldn't have been possible without all of these amazing sponsors. But I also want to thank you, the listeners. This show obviously would have no point if you weren't there on the other side listening to all of these amazing guests that I've had on and listening to me talk about all of these different topics of development. So thank you for listening to the show. I can't wait to kick off 2016. We have a lot of awesome stuff planned for 2016 for the show, not only for the podcast, but also for spec.fm. So please continue to visit spec.fm. There is always new content quite literally every single day. There's going to be new content up on spec.fm. So thank you again for listening and thank you again to all of our incredible sponsors. You are the reason the show exists and you are the reason the show can exist. It is your support that makes it possible. Thank you so much for making 2015 an incredible year. Now let's jump right back into the interview with Jessica Evans. So we've been talking about the importance of user experience with Jessica in today's episode and in the last part of the interview, which is in the last episode of Developer Tea. Make sure you check that out. You can find that at spec.fm. Of course show notes for this episode and every other episode of Developer Tea. Are on spec.fm. But now we're going to jump in and talk about the importance of user experience and user experience specifically for programmers. Jessica is specifically interested in this. So I'm ready to hear Jessica what you have to say about UX for programmers. You know, I've seen some light bulbs go off, I guess, with the programmers and the Developer That I've worked with. And I found that some programmers and developers are really receptive to learning about UX design. And after working with them for a while, I see that they become just more equipped to make decisions. So one thing that I get really excited about after I've been working with a team for a while is that if I'm out on vacation or if I'm out sick and I'm not there and somebody has a UX question, if the team collectively can resolve it without me, like that's a win, right? And that doesn't mean that I'm like out of a job because all of a sudden, you know, I'm obsolete and everybody can do everything without me. No, that's not the case at all. But I think that, you know, it's especially with front-end developers. So if, you know, assuming that most of your listeners who do development do work on the front-end, you know, obviously, front-end development in UX design or like peanut butter and jelly, effective UX designers and effective front-end developers work together as a team to produce great things. But I think it's, you know, it can make you so much more well-rounded and so much more marketable if you're just better equipped to make good UX design decisions without a UX designer. I think that's especially true this day and age because UX design is so in demand and there's not enough talent to fill the demand. So chances are that some of your listeners who are hearing this right now are thinking, oh yeah, that sounds like my organization. We've been trying to hire a UX designer for a year now and we can't find anybody. And it all comes back to being well-rounded. But I do think front-end developers who are equipped to make effective UX design decisions are just a step ahead and they really have an edge over Developer That don't have this. I've been talking about this in my, in at Whiteboard. We all make the same thing, right? I discuss this on an episode as well. We all make the same end product. And so we have a lot of research that goes into user experience and ultimately that user experience research is intended, it's intended to go into the development phase. In Jessica and I, we discussed this at length at the meeting that we had before this episode. But keeping the user experience mindset throughout the entire process, not just when the developers are on board and also not just at the beginning when the user experience team is doing the primary research for the project. But throughout the entire thing, right, we are all supposed to be concerned and aware of what a good user experience looks like for a given person, for a given scenario, for a given product. And this is now granted, Jessica, your job is to be the expert in that particular subject. And what you're saying is so true that just because a group of developers can make a decision about a particular aspect of the user experience doesn't put out the user experience specific person. What it does is it makes us work better together. It makes the final product, it makes it reflect that research just a little bit better in my opinion. And Jessica, you're saying that you see the same thing in practice. Yeah, yeah. And I think what you touched on reminds me that as a programmer or a developer, if you understand who your audience is, who your customer is, that in itself is a huge step. I remember there was one organization that I worked at where I was the first dedicated UX designer. And when I came on board, I heard, you know, 50 different descriptions of who the customer was. And it was really hard to make team decisions about what the customer needed because nobody really knew what the customer needed. And then once, you know, we did use a research together as a team and knowledge of the customer spread, so many people became, again, equipped to make good decisions. So if you know that your customer, you know, primarily uses your product or your service to do these three things every day, then you can make decisions that prioritize those three primary tasks for that customer. You know, that's just one simple example, but the more you know about your customer, the better you're able to make your product. And a good UX designer and effective UX designer will practice UX design as a team. There's a saying in the UX field that UX is a team sport. I think Leah Buley coined that term. She's a, she's done a lot of speaking and writing in the industry and she wrote a book called the UX team of one. But she even joked around saying that maybe she should have called the book UX is a team sport. She really advocates getting everybody involved in the UX process from day one. And not necessarily, that doesn't mean like getting everybody to do your work for you, not at all, but it's just, it's getting everybody involved in exploration, getting everybody involved in making decisions. And that way, you know, if you kick off a project that's six months long, but you've had developers involved for all six months, you know, during month five, when there's a complicated decision to make and there are two developers hovered over somebody screen trying to figure out how to make that decision, they might, at that point, hopefully they'll know enough about the customer and about the project and about the goals to make that decision without again, having to consult the UX designer. You know, and you can't have that shared understanding if you don't approach UX design as a team sport. So an effective UX designer, a good UX designer will involve you as a programmer or you as a developer from day one. You know, the reality of user experience design is that when we gave it a title, we started treating it similar to front end development. It's very easy to say, well, you know, as a designer, I'm not necessarily concerned with how the developer is doing the front end development. Or as a copywriter, you know, I don't need to learn JavaScript. And those two things are relatively, you know, they are not concerned with each other. Writing copy is not necessarily at all related to writing JavaScript. However, because user experience is such a universal thing, it is kind of a foundational necessity of a product at every single point in the process, right? Meaning the content affects the user experience, the speed of the server that your application is running on, it affects the user experience, the color palette affects the user experience. Whether or not the site is optimized to work on, you know, every device that affects the user experience, everything that you can imagine in that long chain, you know, we aren't just talking about digital products, we're talking about everything that is offered to people to use. That is exactly what user experience is about. And so, you know, saying that user experience should be hold into this one specific person's responsibilities, well, that's ignoring reality. When we gave it a title, it kind of confused us into thinking, I think, as an industry, that we can quarantine user experience over into, you know, quality control or something like quality control, but we're all concerned with the user experience and everything that we do, every decision we make has some kind of effect on user experience at the end of the day. Yeah, I would agree with that for sure. You know, and it's funny because it doesn't necessarily work the other way around. Like, I should know, you know, I should know as a UX designer what JavaScript is capable of, you know, and what it can do, but that doesn't necessarily mean that the JavaScript developer needs to have me sit in, you know, various meetings throughout the project life cycle. You know what I mean? So, it doesn't necessarily work both ways, but it's so true. I think that, you know, we, at the end of the day, we all own our product or our service or whatever it is that we're building. We all have a stake in user experience. And it's a great feeling to put out a product that works really well for people. I think it's a great feeling for everyone. I agree. Totally agree with that. Jessica, this has been a fantastic discussion on user experience. Where can people find out more about you, read more about the things that you are thinking about and talking about use, are you still speaking regularly or is that kind of a thing of the past at this point? I do speak occasionally. I do, you know, give presentations and workshops occasionally, not as much as I used to, but yeah, if folks want to find out more about me, definitely check out the UX design school where I work as a faculty member. And that's called Center Center. And it's spelled C-E-N-T-E-R-C-E-N-T-R-E. So Center Center dot com. And you can find out about us there. And I have a faculty page there. I do have a blog where I blog occasionally about learning UX design and the like. And that's Jessica Ivins dot net. And that's my first and last name. And on Twitter you are Jessica Ivins, correct? Yes, that's correct. You can follow me on Twitter as well. I like to post, you know, UX findings and whatnot. That's usually what I'm posting about. And or various things like my windshield wiper getting stolen or something like that. But usually, usually I get usually. What a bizarre thing to occur. Yeah, yeah, that's, it's only happened to me once, but yeah, it was very bizarre. Perfect. Well, all of those links will be in the show notes, of course, which you can again find at spec dot FM. Jessica, it has been absolutely a joy to have you on the show. Thank you so much. Sure, Jonathan. Thanks for having me. Thank you for listening to today's episode of Developer Tea. My interview with Jessica Ivins. Make sure you follow Jessica on Twitter. The link to that will be in the show notes at spec dot FM. Again, huge thank you to all of our sponsors for this year, 2015. I look forward to 2016 and thank you, the listener for listening. Until next time, enjoy your tea.