 Earlier this year at work I made a bit of a mistake. I accidentally emailed the entire company and in my case that's almost 16,000 people and it also looked as if this email had come from one of our top executives, the COO. And I did this using a tool that I had designed and I had written the base code for so the way this thing worked that was me. This is not one of my finer moments in my career. I kind of panicked, freaked out, emailed my manager and said, do I still have a job? Turns out I do. So that was good, that was good. Panics subsided a little bit but then I had to think to myself well what if this had happened with one of my clients, the people that I wrote this tool for and what if it had been worse? What if it looked like it come from the COO and had had bad information in it or sensitive information that was too soon to send premature? These were not happy thoughts. I really do not like to set my users up to fail or make big mistakes in that way. I work on a corporate internet and a few years ago we were redesigning the homepage. The homepage gets a lot of traffic. Everybody uses it. Some people sit on it all day long while they're at work and the clients this time around they decided they wanted to have a slider on the homepage. We've never had one before but they wanted to be sure that all employees saw lots of news about the company and they wanted that slider to move automatically. I was not personally super wild about that idea but they said it was important and what we came to was an agreement that it would go every 30 seconds and then they demoed it for their executive sponsor and he said oh no that's too slow. Make it go faster every 20 seconds. This thing was driving me crazy while I was working on it but they needed it so we released it that way. I was not alone as it turned out. Lots of other people did not really like that motion and it was irritating and distracting so the clients kind of relented and they said okay so we can have a pause button but we need to do this fast and also it needs to expire periodically. Okay well easy way to do that. You set a cookie with JavaScript, expires periodically. Okay we released that. Thing is we work at a software company and everyone has like five browsers right that they're using for testing and also they log in from home and also they have mobile devices or go to conference rooms and log in. Well what this meant was not only was the pause button expiring it wasn't set in many of the places that they would go to so they go to another browser that cookie's not there and they pushed back again of course. So this time around I said look let me do this the way that I would want it to be done and give me the time to do it right and you don't really want to create ill will towards your home page so they said yes let's let's do it that way. So because we're on an internet very cool everyone's logged in I can save your preferences to a session database and pull that down everywhere you go and that's what I did. It took a little time it was slightly challenging but that is how I did it and we implemented it that way and everybody was much happier with that. So the whole point of me telling you this whole story is to say that as developers we have this ability to control the end user experience and although it often seems as if the clients executive sponsors project managers designers product owners whatever are standing between us the developers and the end users in fact the relationship between us is very direct because they touch our code directly. As a developer I've trained myself in accessibility and what I've learned is that it goes beyond just meeting the technical standards or making a site keyboard accessible for the user that has low or no vision so they're using a screen reader. It's really more of a mindset. Now as developers a lot of times we love to solve problems a really tricky problem is what I call developer catnip it's irresistible it's engrossing you have the best time. Unfortunately sometimes we lose sight of the end goal in that thrill of solving the problem and the end goal is really to make something something that we're going to put out there for other people to use and hopefully that they will have a great experience using and in many cases will want to come back and use again and again that's a measure of success for us and that's kind of the whole point. So what I find is when I sit down to make my technical decisions even the very beginnings the architectural decisions I draw from what I learned from accessibility and I try to approach that with a mindset of compassion for the end users who are going to use that product in the end. Now because I work on a corporate intranet I have a little bit of an unfair advantage in this way. I'm guessing most of you don't work on intranets if I probably none of you do but I know that the users who come to my site they're all my co-workers and because I've been at my company for a long time I personally know a lot of them. I know for example that the person coming to my site might be a parent holding a crying baby in one arm and a crappy phone on a crappy connection and the other trying to use it with their thumb because they need to get the phone number for our healthcare center because the baby probably has an ear infection and they need to make an appointment. I know that the user coming to my site might be a statistician who is really distracted by emotion and her job is to get the numbers right in our software. This is statistical analysis software so it's critically important that we deliver the correct results to our customers and if she's distracted and unable to focus that's a big problem. I know that the person coming to my site might be an executive whose new job is to ensure the future of our company and he needs to get the company plan out on the site for the employees to read and communicated out to them via email or I know that the person coming to my site is looking for the policy on compassionate leave because they just lost somebody and they're in shock and they don't really know what they're going to do next but they know they're not coming to work and they need to understand what the rules are. So all of this means that I do try to approach the work that I do with compassion and I try to make sure that my team bakes it into everything that we do from the very beginnings because I know that all the other people that are involved with the project and with the design they may seem to stand between us and the end users but they really don't. So cultivating a compassionate mindset might not be the most natural thing especially if you're a developer not because I'm saying developers are bad people or anything but because it's not really part of our job descriptions it's not going to be in a job posting that we apply for but I do have some very practical suggestions on how to go about this. First is to investigate user-centered design. This is how I started a long time ago on the path that I'm on now and it's a very powerful toolkit that you can draw upon to help put the user at the center of the design process from the very beginning. Personas in particular are a very very powerful tool in this toolbox and they're great when you don't know your end users like I do or when you're dealing with a large scale of users as I currently am and you need a way to summarize and yet also bring to life and humanize all the people who are coming and using your product. Study accessibility. Go beyond just the standards and the technical implementations that you have to think about. Follow the people that are experts in that field. Read what they write. Listen to their talks and absorb the approach that they make to their work because they advocate for the end user all the time and compassion is at the center of everything that they do that's why they do it. If you have a way to get to know or talk with your end users take it. If there are user research activities find a way to involve yourself in them. For example if you have a chance to watch a test where a user is actually interacting with your product these are great not just to uncover the problems in a user interface but also to really feel the pain of that very live human that's coming and trying to use your work and to humanize them. Talk to the people that you know outside of work about their experiences in using the Internet. My husband for example he surfs with script blocking turned on. I did not really understand that people like this existed before we met. The Internet is not a very friendly place for him. When he goes to a new site he has to go through a painful process of figuring out which scripts he thinks are safe to enable trying to use the site getting frustrated and then having to enable more scripts that those scripts have in turn called. I didn't really get this before I met him and it's not super comfortable for me as a modern-day web developer to think about the fact that people like this exist but they do. So talk to the people that you know and understand what it is that they encounter when they use the Internet. Finally just think beyond how you would use your site. It's an easy trap to fall into but people do approach your work in a multitude of ways not always expected and you have to think outside of that box. As developers we are the gatekeepers of the end user experience. End users touch our code directly and we have a responsibility to approach our work with compassion for the people who are going to use it. My name is Lisa Lynn Allen and you can find me on Twitter or at spacepod.org slash uprising or find me at lunch. That's good too.