Caleb Jenkins talks about why an Agile coach cares about UX, checking tickets at an amusement park, and the futility of trying to use two promo codes. Hosted by Ben Judy.
- Caleb Jenkins on LinkedIn
- Caleb Jenkins on Twitter
- Caleb Jenkins Presentations - Slideshare
- Developing UX - Life of a Silverlight Expert Ninja!
- Session: Slay the Legacy Code Beast at Big (D)esign Conference 2011
- The Art & Science of Seductive Interactions - presentation by Stephen P. Anderson on Slideshare
- Essential UX Layers for Agile and Lean Design Teams by Jared Spool
- Fast Path to a Great UX - Increased Exposure Hours by Jared Spool
- Sabre Airline Solutions
Welcome to the DFW UX podcast – the podcast for user experience professionals in the Dallas – Fort Worth metroplex, all of North Texas, and beyond. This is episode number three. I’m your host, Ben Judy. In this episode I’ll have a conversation with our excellent guest, mister Caleb Jenkins.
Caleb X. Jenkins is an accomplished developer and Agile development coach. He’s the founder, CTO, and principal mentor at Pro Action Mentors. He’s a recognized Microsoft platform expert, author, and national speaker. He loves working with development teams around the globe to help make them more awesome.
Caleb lives in the Dallas area where he – I’m just reading from your LinkedIn profile, I hope that’s okay.
He lives in the Dallas area where continues to date his beautiful wife, and busies himself playing Candy Land and Xbox 360 with their four incredible children. But something tells me that’s all just scratching the surface of answering the question, “who is Caleb Jenkins?”
So, Caleb, welcome to the DFW UX podcast.
Thank you. I’m excited to be here. I’m glad you told me that was from my LinkedIn profile. I thought, boy, you really – I felt like I was being stalked there for a minute.
It could be disconcerting.
How did you know I played Candy Land? That’s a little creepy.
Just last night, right?
So, Caleb, from the looks of things, if one glances over your LinkedIn page, or your web site at developingux.com, I think one would come to the conclusion that you’re actually three or four people. You have a lot of plates spinning! You’re in the middle of a lot of things. So what’s a day in the life of Caleb like right now?
Well, right now most of my time is being taken up by Sabre. That’s the company that I work for. They’re my employer. I have an interesting relationship with Sabre going back many, many years. So I’ve only worked here as an employee for six months or so. Right around there, since December. They do something here called – they have a “Bring It” campaign, they do Hack Days, and even going back to my Microsoft days, I was one of the few people as an external person to be invited to come participate in a Hack Day. And that was sort of my first introduction to the campus and what the culture here was like, and I liked it.
Later, I was asked to come be a Hack Day judge. They had a Twitter panel, which seemed like an odd thing, but apparently I had been on Twitter for a very long time. So someone asked me to come be on the Twitter panel. And, of course, the Big Design Conference is something that was originally conceived of by primarily people that worked here, and some of the creative groups, and to this day is still run by – there’s a large representation from Sabre. So I've spoken at the Big Design Conference in Dallas pretty much since the first year it happened, and every year, and I love the conference. But again it just gives me just a good opportunity to get acquainted with a lot of the people that are here and familiar with this place.
So I was asked to come work with one of the teams that’s owned by Travelocity. I was the senior architect at Six Flags at the time. That’s a fun story in and of itself. But I had the opportunity to come work with a team here, and I took it, and that was when I really started my own company to do consulting because it wasn't necessarily a permanent thing. But I liked the challenge and the opportunity. I did that for eight months, finished the project. I was ready to move on and they said, “hey, why don’t you come over here as an Agile coach?” That is a little bit of a different role for me. I'm used to being more technical, but Agile projects and process has really been in my DNA for the last nine to ten years. It’s a big part of who I am and a lot of the projects I’ve worked on, so it was a good fit, and it's exciting. We’ll see where that goes.
I have to ask because I don't think I know anyone else who either works or has worked for an amusement park – what did you do at Six Flags, exactly? Were you doing Agile development or Agile mentoring? How does that tie in?
That’s funny. Yeah, so coincidentally when I went there, they were actually in the process of transitioning from a fairly waterfall process to adopting Scrum as an Agile methodology. So that was interesting, to go through that transformation there with some of the misconceptions, and you know, stated goals but then in practice sometimes it's hard to change.
But the fun part about that was, people would ask me – people that I know would say, “oh, what are you doing over Six Flags?” All right, so their corporate office – I wasn’t actually at the park –
Sure. No, I imagine you just riding roller coasters all day.
I wanted to do that. That was what sold me on the job. But, so people would ask me, “what are you doing over there?” And the answer was, “Well, I’m checking tickets at the gate.”
And I’d get weird looks from that and I’d explain, “No, I'm checking all the tickets, at all the gates, at all the parks.”
Essentially the software that helps run the park is the software that I helped work on, in its interconnected parts, and in, you know, the needs for that. They have a very small team doing a lot. And so part of what I was doing was working with the consulting companies that would come in to work on some of the larger initiatives. So they might come in with four or five people to do a lot of the coding on some of the projects. And I would help – sort of – it’s sort of a governance. When you have a team of two people doing all of your maintenance, [and] a team of six people coming in to actually create a project, it's really important the technology that they bring in is something that the very small team of two people is actually going to be able to maintain.
And so when you run an environment like that where you are bringing different groups to work on initiatives, it is very important to sort of guard against random technology showing up because they seem like a good idea at the time.
Yeah. So you have a background in development and in processes and how development teams work and related things. What about user experience? Why do you care about user experience? I mean, I think I can get why but I think there are probably a lot – I am conjecturing here, but – there are probably a lot of developers and Agile coaches and development mentors who really see their job as more tied to technology right and tied to processes involved in coding. Why do you care about UX?
Well it’s interesting. My degree is actually in design. My degree is a multimedia design degree. I tell people I became a developer is a fluke of timing and everything else.
Literally my first job, which I'll refer to as a development job, started with a company who wanted me to redesign their website. Build their website, actually. They were entirely static HTML, and they had about 9,000 products.
And so the first thing I told them was, “Okay, we’re going to rebuild this, and we’re going to use this technology.” You know, it was a technology at the time that I had chosen. And I said, “I don't know it. But I can learn it.”
And they said, “Great! What do you need from us?”
So they literally went and bought me a book. And that was my start in kind of really making that shift to backend systems and development. What’s interesting about that though is that, you know, there are some developers that will take the approach, “Well it was hard to write it. It should be hard to use.”
Sounds familiar. Yeah.
You know, “They’ll figure it out.” Right? And the reality is – and as a developer I’ve worked on systems that people loved. The end-users loved. They adopted it. They would drool over it. “This is the best system in the world.” And then you get in to work with the code and you realize, “Oh, dear Lord, this is impossible to actually extend or maintain.” Or, I didn't realize, you know, every month a developer is going in and updating tables because of how he built it, that's the only way to run this report that everybody loves and is using.
And you realize that for something to really be successful, the underlying code can be garbage, but if your end-users enjoy using it, it will be successful. It'll be up a nightmare to maintain. It’ll be a nightmare actually for the developers to work with, but it will actually be successful. Your business owners will, you know, flaunt over it, just because it's something that solves a business needs.
And to me, you know, if you look at UX as a practice it's not just, “how does it look?” Obviously there's a bigger world there, your information architecture, and – to me, the user experience professionals are really so much closer to solving the business problems, the business needs, than very often we get to on the development side.
I find often thinking outside of the box solving some of, you know – as long as I look at the bigger picture than just, what does it look like? That it puts me much closer to that consumer, and I start asking the questions, “What are they actually trying to do? What they want to accomplish? What would delight them? What would help them?”
You know, I think Stephen Anderson just has a book out on seductive UI and creating delightful experiences. So that is really what will, I think, drive success and adoption. You can have the best coded application in the world, but if nobody wants to use it, then I argue on how successful it is.
So this is where they both come together. This is where you have developers and what they look at in the areas of concern. Often it’s the “-ilities”: the security, the reliability, the scalability, the maintainability. Those are all really important to good developers and architects. And often the “-ilities” of software are not that important to UX professionals.
And the converse is true. The overall experience, the information architecture, the flow, how easy is it for me to get to this information – are often things the developers could care less about, right? I’ll give you a command prompt and you just have to memorize these thousand, you know, keyboard – and it’s perfect!
It works. So when those come together is when you really have success. This is something on the UX side. If my system looks awesome, but it has no uptime, right, it's – the availability is horrible, or all of a sudden the security was bad and I lose my account, you know because it was injected with SQL injection, and all of a sudden my personal information is out on the Internet. All of those kill your user experience.
Yesterday – and I don't want to name companies, but it it's a company that lets you rent DVDs and they have boxes in stores that aren't red, so that big blue boxes in stores – they e-mailed me, ironically, this was just yesterday I was going to pick up a movie for my kids at home, and minutes before I walked into the store got an e-mail from this company with two promo codes. Usually they send out one promo code.
And I just thought, “Brilliant! I can get TWO movies tonight for free!” And I got all excited.
Well, then I used their kiosk, and two things about that. I ended up having to push the kiosk for any button at least three times because it just wouldn't register those hit points. And that really irritated me and slowed me down, and it killed the experience. And the other thing was, once entered – so I put both videos in my basket, added a promo code, and then the option to add a second promo code went away!
It wasn’t available. They only expected you, when they built this UI, to have one promo code at a time! And so there was a disconnect between the user’s experience and this marketing campaign that sent me two promo codes.
And literally – and by the way, they both were good for today and expired tonight – so I literally had to remove one item from my basket, go through the entire checkout process – which, again, that double hit on the kiosk was annoying. I started to get a line behind me.
I was gonna to ask!
But I’m thinking, you know what, I’m getting my second DVD, you all can wait! I'm sorry their UX sucks! That was my thought. And I went ahead and loaded up the second DVD, but I just thought, “You guys are killing me here!”
So how do you solve a problem like that? Presumably this – ABC video store – is a big, maybe an international, you know, corporation, or at least a huge national corporation with a lot of moving parts. And here you've got the folks who built the kiosk systems. And you’ve got interface developers, you've got hardware people, you've got experience people involved with that, and then you've got the marketing team that sent you the e-mails with the promos. There's the disconnect, but within a corporation – maybe a large corporation – how do you solve a disconnect like that?
That’s a – so that’s –
I expect you solve it on the spot. Right now.
Right now. You know, I find most things that are wrong in the world – most things you can look at, and you can say, you know, they didn’t ask Caleb before they did that.
So that's the solution! @Caleb Jenkins on Twitter, and he’ll solve it for you.
And boy, they should've asked me first. No. [Laughter]
So that’s obviously a bigger question. There aren’t necessarily easy answers for that, but just knowing wow, they had this – so, the e-mail delighted me. The e-mail actually, you know, it just so happened I was going there anyways, but it's something I pass on my way home. So normally it's a single thing, and all of a sudden I get two. That was exciting! I’d never gotten two before. And to start on that, sort of that high, and then to have to just muddle through all those steps to actually take vantage of that, kills ya.
It's kind of like, wow, you really left a bad taste in my mouth for something that started with such a good taste. You know, a positive expectation and –
A real letdown. And that’s – you know, you think about experience – so that's a hard question because I was actually thinking about this and I'm checking out. Is a really their fault that the touch display is so bad? I don't know, right? I don't know if that was the software, but certainly that's a problem they solve.
Was it their fault, though, that there is a disconnect between how the software worked and the e-mail campaign? Certainly. I would assume that their kiosks can self-update, because they are connected to a network. That's how that whole system works, right? They validate my credit card, they post back to the account, I mean all that system is, that’s a networked device. So the idea that they would roll out a marketing campaign that would have such a bad experience to the end user, you know – and there’s no salesperson there to sort of smooth things over or provide training to you, right? That is the touch point to the consumer are these devices. And so that was a real breakdown in process.
The annoying touchpad? I was in the Lego store with my kids. There's a new Lego store at, I guess over here in Grapevine, right? And same kind of experience with their kiosk. They wanted you to fill out a survey. And it was so bad how many times I had to push – you know, maybe I have bad fingers, I don’t know. Maybe that’s the problem, right? I just -- kiosks don’t work well for me. But that was, again, the same kind of thing. I thought, “boy, I’m filling this survey out for you guys but I'm not happy about it.”
I don’t have a good answer for that. That might just be a kiosk technology issue. But it’s certainly one that should be solved.
So that’s my request to the world. I'm not going to solve it, but somebody out of your thousands and millions of listeners. Episode three, right?
Right. Yes. Exactly.
Okay, so we’ll catch this on the long tail. That in the long tail the thousands and millions of listeners, somebody please, please fix kiosks. That’s my plea to the world.
So user experience and Agile is an interesting mix where they blend together. I don’t know if you – So, Jared Spool posted something to his blog probably about a month ago specifically talking about user experience and as it works with Agile, and sort of where they come together. Really interesting stuff. If anybody – of course you would discover this podcast first, but then if you discover this podcast and you don't know Jared Spool’s blog, you know, what's wrong with you? But, no, go read his stuff. Really good stuff.
But he talks about – and the reason I bring this up is, here at this company that we work with right now, we run the gauntlet. There are product owners which represent the business to a software development team. So the businesses needs and priorities, they help prioritize the backlog and stories. So you have product owners in some cases that are trying to communicate with software development teams by just a bunch of bullet points and stories.
And I have conversations with them like, “Are you creating mockups? Did you work with a UX person on this product? And do you have a real –“ and their question is, “Well, we’re Agile, why would we want that?”
Well, you’re trying to communicate with a software team. In this case the product owners are here and the software team is on the other side of the world, actually in Poland, in Kraków. And I had to say, “You’re trying to communicate with people on the other side of the world. Wouldn't that help?”
There’s nothing about Agile that says you have to use bullet points. The point of the story is to communicate an idea. And so, what could increase the fidelity of that than referencing screenshots, and drawing pictures on them, and pointing with arrows, and saying, “This is exactly what I'm talking about for this feature.” And just helping to increase the fidelity of that.
But then it's also interesting because I was working with another team and they did have a UX team they were working with. The challenge that UX team had is that – and this was, boy, they flushed out this product. It was beautiful. And it was a five year road map. Because it would probably take three to five years to actually build everything in that, that they designed. And the development team said, “Okay, we need to ship something in three months. That's our next release.”
So everybody just work really fast.
Right. Help us pare this down, and we have this set of priorities, and what would this look like? The UX team in that case essentially took the approach, “Well, we can't take stuff out. This is the design.”
It’s a cohesive experience.
Exactly. This is the design. You can’t just start – and so the development team ended up just to clearly communicate, “Okay we’re gonna take these screenshots and take a red marker and we’re going to mark out everything that were not building in the next sprint, in the next release.” And I think that was shocking to the UX team.
But it comes back to this is where UX really has to kind of blend well with Agile, but a way to help it blend is to start taking those phased or adaptive UI’s. So actually having enough a user experience that can be modular in design, and I can start thinking through, if I have this form and it's going to be this form with all these areas and maybe tabs or drop-downs, you know, however I might design it as a user experience person. But in our initial release we’re only going to be able to capture this information: a name, an e-mail, and a submit button. That’s our first story.
So I don’t necessarily want to leave the form, you know, taking up the whole page and I have this awkward void where I have this information huddled at the top and then this button huddled way down below, and it just looks awkward. But if I start to think of design in ways of, how can it be adaptive? How can it help flow and grow? I think becomes significantly important for the user experience person to have that input and help drive that end user experience throughout the entire lifecycle of development. Not just focusing on the end product. I think you have to have that vision in mind, but being able to have a way to grow through that entire development process.
Great. Yes. A minute ago you mentioned Jared Spool. And, boy, he’s a great jumping off point to many things. But one thing that I read recently and I've been thinking about a lot recently is an article that he posted in the first half of 2011. Just a few months ago from when we’re speaking.
It was about increased exposure hours. I don’t know if you saw that one. Basically he went out and – you know, he took his UIE outfit and did a bunch of research with software companies, trying to determine a fast path to a great UX. So, what are the common threads among all of these different companies that that lead quickly to a great user experience in a product?
And what he found was that the common factor was not only the UX designers but everybody in the organization – the developers, the leadership, management, executives – spending time, exposure hours with end users using the product. That was the common factor. And so his recommendation I think was very precise, it was to have everyone in your organization from top to bottom spend two hours every six weeks directly observing and engaging with users as they're using your product.
So in your experience working with development teams, how much of that you see? Developers actually observing and engaging with users using the product? And is that a recommendation you agree with? How do you feel about that?
I think any time you can get the developers that are writing the code more closely aligned with people using the software, you’ll have a better experience. I think that’s always going to be a win.
It's interesting. I hate to give “it depends” answers, but very often it depends on the organization and the type of software that they’re writing. So, for example, when I went to was doing architecture for Six Flags, a lot of the software that we were writing was internal software. And so to get the stakeholders or to get the product owners, you know, or the people that were having input into the software together was, in our case, it was a lot easier. Now, they are a large company in fact that they have people all over the US and the world, so in some cases it would mean setting a specific time to bring everyone together. But we were 2 miles from the local park. So as often as we needed to we could fact – and we did – drive across the street, essentially, and go sit with people in the ticketing areas, and learn about their workflow.
And there was a lot of insight gained from that. And you're asking questions, you know, “Oh, why do you do it that way?” And trying to think of ways we could help solve some of their challenges that they faced. That’s a learning experience that can’t be replaced. It's easy to make assumptions about how you think it probably works, and it's eye-opening to walk in and then see how it actually works, or what the capabilities of the existing system actually are. And the more you can base your daily decisions in actual reality as opposed to just assumptions is huge.
So I'm working with a team of interns right now here at Sabre. Sabre does – every summer that do an intern competition. I'm working with a group of interns to help them him do a business feasibility study on a project. And early on there were some assumptions even about the capabilities of products here within the company. And by simply scheduling time and meeting with the product owner, someone who had an understanding of that product, and in one of our first meetings they actually threw out, “Well, this is our plan.”
And the person essentially said, “You're completely wrong.” Like, “Our product doesn't do that at all, and that's not all how it works, and it probably never will do that, and –”almost like, why am I here? Why are you wasting our time?
It wasn't a waste of time. It was a good learning experience which was valid.
As Mark Twain said, “Supposing is good but finding out is better.”
That's right. Absolutely. So it was definitely eye-opening to the people in the room. And a good learning experience.
Well, we’ve got a couple minutes left. The other jumping off point from Jared Spool is the Big Design Conference which you also mentioned earlier. And you're going to be presenting at Big Design Conference 2011 in Dallas. Actually t will be in Carrollton, I think, at the Crowne Plaza. I think that's bigdesignevents.com for anyone who doesn't know and wants check it out. There’s still plenty of time to get tickets.
There’s not plenty of time! Run! Hurry now!
Hurry now. Go immediately, in fact. But that what are you talking about at the Big Design Conference?
So, this is neat because it is more of a design conference, and I think the first year I spoke at it I talked about the new features in one of the versions of Silverlight. And that was a really fun talk because it really kind of when across that the gauntlet. Silverlight is a UI technology from Microsoft. And last year I gave a talk which was more developer focused. It was Ten Reasons Your Software Sucks and How to Fix It.” I was nervous about that because it was definitely more developer talk, but it was great in the fact that it was actually a very full room and the feedback that I got whether people did Java or PHP or Ruby on Rails or .Net – everybody that was there (at least that gave me feedback) it was positive feedback. It was a learning experience across the board.
So this year I’m doing a little bit of a different twist. It's actually going little more technical which will be interesting. But it's Taming the Legacy Code Beast. And so it’s some practical strategies. Things that I've really had to implement that are really no-brainers, but things people don't think about a lot or often enough. It’s very easy to just jump in and to want to start making changes, or to look at the size of something and just be terrified of it and think, “We don't want to make any changes to that. Ever.”
And so you see both sides of the spectrum where people inadvertently break important stuff and not know it, or just leave it alone and never actually gets better and never improves, and hurts the overall agility of the business. And so I’ll be talking about some really practical approaches. I won't tell you all the companies that those practical approaches came from, but it has come out of very specific projects I worked on the last three to four years. Very specific companies I worked with and some of their code bases.
Great. It sounds like you’re going to share a lot of real-world experience in that talk. And thank you for sharing your experience with us here on the on the DFW UX podcast!
Where can people find you? I know that your website is at developingUX.com. It looks like you’re CalebJenkins everywhere online – on Slideshare they can find your presentations; you’re @CalebJenkins on Twitter. Anywhere else?
Those are probably the big places. You found me on LinkedIn, and unfortunately I think I was a day late to grabbing CalebJenkins on Facebook. So, you know, these young upstarts with my name.
What are they doing with your name?
Every now and then I get these Google alerts that talk about how well I did on some football team. Boy, you don’t know me at all, do you? But yeah, Twitter @Caleb Jenkins and my blog is developingUX.com and those are great places to start.
Great! Well thanks a lot, Caleb.
Absolutely, it was a pleasure. Thanks for having me.
Well, that’s gonna do it for this episode of the DFW UX podcast. Thanks for joining me.
You can also follow us on Twitter @dfwux. If you want to be a part of the show, if you’re a UX practitioner and you have something to contribute to the podcast, just contact me. The best way is to send me an email. Send it to firstname.lastname@example.org or send a private message on Twitter @dfwux.
The music you hear on this podcast was written and recorded by Father Cornmelia, a very talented group of local artists. Just Google the name Father Cornmelia and you’ll find their Facebook page and you can listen to more their music on Reverb Nation. Thanks, Father Cornmelia.
Until next week, I’m Ben Judy. Go make the world a better place.