Hey, everyone, and welcome to Developer Team. My name is Jonathan Cottrell. 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. In 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 Team. And you should subscribe to those shows as well as Developer Team in whatever podcasting app you use. So go and check it out, spec.fm. Of course, you know the show notes for this episode and every other episode of Developer Team 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 that generally captures it. Yeah, I think that covers a lot of it. We stopped around the time that you were talking. We 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. Okay. 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, I 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 a rhythm. 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 team. 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. Right? 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 learn something and I share that information, not only do I learn it better, but other people are enlightened by my experiences, right? 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, right? Rather than me banging my head against the desk for hours on end because, you know, 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 the phone. Right? Right. Right. Right. Right. 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 also, happier workers typically tend to work better together. And so that's an important part of the stand-up meeting 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 it invests into our individual learning experiences, and invests into our conversations. So that's a really important part of the stand-up meeting. 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 like 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... Never Eat Lunch Alone. I've never actually read it. It's a disclaimer. But 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 a big thing. You don't even have to go out somewhere. Yeah. We're going to have one corner of the cafeteria. And the three of us who are really interested and geeking out about learning are going to do this. And 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. Right. And so, you know, if you already are doing that, then, you know, who wants to eat alone? First of all, 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 a 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 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 My Speed 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 double speed, though. I usually go 1.5. That lets us get through a presentation. Quickly. So we, you know, 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, you know, what's one thing you learned that you didn't know before you watch 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 reflect reflecting. It's once a week. So it's not something that that we ask people to do every day. But I think just the key is is reflecting on what you learned. You know, 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, you know, and reflect, it helps it stick for that person. But again, it also helps you learn because they might have, you know, picked up on something in the presentation that just that didn't really resonate with you. And you might be like, wow, you know, why didn't I think of that? Yeah, that is a that is an awesome thing that, you know, I wouldn't have taken away from this presentation otherwise if my colleague didn't bring it up. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. like if you're the kind of person like me, who's antsy and doesn't like to sit down and watch videos, um, 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, you know, again, it comes back to like your own learning preferences and how you learn. You know, I like to read, but there are lots of things that I can't read because, you know, their, their presentations or their seminars. So this is my opportunity to learn once a week, um, through. 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, right? 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 presentations, giving, you know, giving presentations, giving presentations, giving these, these, uh, kind of content heavy presentations. And then you can say, okay, how, how do we apply this to us? How do we take this in and filter our opinions, uh, 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, and is just sharing content. Sharing information with each other. And, and there's so, there's a, uh, just a wealth of information out there, uh, that, that is just waiting to be learned from. There's so much information. Yeah. It's, it's a lot to keep up. It is a lot to keep, 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, if you are feeling that way, this is just kind of a PSA. Uh, if you are feeling that, that feeling of, I really badly need to keep up. Um, 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? That specific episode? If not, it's okay. I think I have, you know, I, I listened to your podcast regularly and that does ring a bell. I think, I think I have. The synopsis is basically that, uh, 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, you know, there's so much, you know, there's so much, you know, there's so much good content out there that to keep up or to, uh, 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, uh, you should limit yourself to a specific amount of food that you're eating. And so I mentioned that you should, uh, you should limit yourself to a specific amount of food that you're eating. And so I mentioned that you should, and this gives you a system, um, that, that is maintainable, right? Instead of saying, well, let's just see how many articles I accidentally encounter every, 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. 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 I'm most excited about or whatever it is. It just kind of, it gives you a guideline for focusing your energy. Yeah. Yeah. I like that. Well, let's, let's, uh, shift gears, but first I'm going to, uh, 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. Uh, 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 T have 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 T and that wouldn't have been possible without you. So thank you so much for joining us. We'll see you next time. Thank you. See you soon. year. Now let's jump right back into the interview with Jessica Ivins. 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. And 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 developers that I've worked with. And I found that some programmers and developers are really receptive to the idea of user experience. And I think that's a really good point. And I think 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, I'm obsolete. And everybody, 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, you know, 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 and UX designer 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, 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 developers that don't have this. I've been talking about this in my, at Whiteboard. We all make the same thing, right? And I discussed this on an episode as well. We all make the same end product. And so, you know, 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. And Jessica and I, we discussed this at length at that 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, 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, it 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 was. And so I was like, okay, I'm going to do this. I'm going to do this. And I was like, okay, I'm going to do this. I'm going to do this. I'm going to do this. I'm going to do this. And then once, you know, we did user 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 like simple example. But the more you know about your customer, the better you're able to make your products. And a good UX designer and effective UX designer will practice UX design as a team. So 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 as 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 the top of the list, and they're like, Oh, I'm going to do this. I'm going to do this. I'm going to do this. And then you have to make decisions that are really, really important. And that's what we're doing. 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. 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 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 they're using the same color palette, they're not. So it's a matter of how you're going to 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 the user experience. 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. Um, you know, I 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 lifecycle, do you know what I mean? So it doesn't necessarily work both ways. But it's 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, it's a great feeling to put out a product that works really well for people. I think it's a great feeling for everybody. I 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 you? 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.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.net. And that's, 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 that or various things like my windshield wiper getting stolen or something like that. But usually, usually, I guess, 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.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 T my interview with Jessica Ivins. Make sure you follow Jessica on Twitter. The link to that will be in the show notes at spec.fm. Huge thank you to all of our sponsors for this interview. This year 2015. I look forward to 2016. And thank you the listener for listening. Until next time, enjoy your tea.