David Kelley Interview

Aug 11 2011
Download

David Kelley, Principal User Experience Architect at Wirestone, talks about how UX should be a concern of everyone on the team and not just fluffy designer stuff. David has described his role as being the glue between designers and developers. He makes a strong case for both designers and developers to learn more about the other discipline for the sake of better communication and better products.

Links referenced in the show:

The music in the show, Have Mercy — Big Walter Horton, was provided by Mevio’s Music Alley.

Transcription

  1. David 00:00:21

    My name is David Kelley and I am the Principle User Experience Architect for an interactive design firm called Wirestone. And today we’re going to talk about user experience and topics related to emerging experiences and the latest and greatest stuff that we do here at our Experience Center in Seattle.

  2. Ryan 00:00:47

    Very cool. I think this is a real interesting topic. I’m really excited to be able to kind of dig into this. We’ve been doing a lot of really developer-centric things and I like, well, one of the ways you describe your role is basically being that glue between designers and developers, kind of, to make a better product. And I think, like, that idea and just really delving into this is something that’ll be really, really useful for the listeners. Kind of see why you do that, what are the results of it and, kind of, you know, things they should be thinking about.

  3. DK: Yeah. Yeah. It’s a great topic.

  4. Ryan 00:01:20

    Cool. So typical day; like, what kind of responsibilities as a Principal UX Architect? Like, what is that for people? And really, go all the way back to people may not really resonate with UX, right? So what is all this stuff?

  5. David 00:01:36

    So UX is User Experience, right? And I guess for me, becoming a UX Architect evolves out of my role as a software architect, where I’m engineering these large systems. And it was more than just that; it was working with designers, it was, you know, building these interconnected systems that were cool, you know? That people loved to engage with. And the more I fell into that role and the more I was doing designery things and getting everyone to work together, I found myself really kind of sliding into that role where the only way to explain to people what I do was to use, you know, User Experience Architect. And User Experience, at least to me, is about the “experience” that people have when they interact with the system. You know, it’s not just about what you see on the screen, but like in the case of some of the touchwalls and other kinds of architectural touch experiences, you know. It can be about lighting, it can be about how that person feels, it can be, you know, when someone comes into a space, you know, what is that target person starting with? So how do you engage that person in a way that gets them engaged; that they enjoy that, they walk away from that “experience” saying, “Wow, that was cool,” or, you know, “I feel refreshed.” You know, even if it was buying tile or buying software or whatever that experience really was. And so UX is really the idea of designing that overall experience from whether it’s that external elements, those interior design kind of things, to the stuff you see on the screen or the stuff you don’t see on the screen or the sensors or these other kinds of things that you work with. And so as a UX Architect, typically I find my role being one of almost like the cheap Kool-Aid drinker, you know. I happen to talk the designer speak, I’m happening to talk the developer speak, and I’m getting these people -- getting those two teams to not be two teams, but to work together as a cohesive unit and finding ways to work on the same thing at the same time and including developers and designers and IAs and all these people through the whole process. So it’s not these guys go over and do their task and they throw it over the fence at these people and then these people do their thing. So my job is to kind of get away from that and get people to come together and hold hands and sing Kumbaya and make cool things happen.

  6. Ryan 00:04:35

    That sounds great. It seems like maybe historically there was almost this encampment, right? Like maybe the designers and developers seemed like they were working against different goals as opposed to trying to come together. It does seem like recently it’s a more popular approach -- well, especially, like, with, you know, user-centric design, you know, for your products. It seems like that’s really about, you know, better communication like you’re talking about. And everybody really agreeing that this is about the user and not about, “We need to streamline the interface so it’s easier to build,” or, “No, we need to add all this richness because I know how to use this thing in Photoshop,” right? So, like, the idea of actually just thinking about a good product…that’s good. Are you noticing, for the most part, I know that you’re really active in different community activities. I’ve seen you communicating with people at different kind of usergroups and meetups and just, you know, Web videos. Is this an idea that you think is more accepted than has been in relatively recent history?

  7. David 00:05:36

    I think it is and it’s probably going to continue to be a big trend, at least through 2020. If someone is just interested, kind of in the whole UX trend, kind of at a higher level (at a almost a business sort of level), I’d encourage people to go get the book by Daniel Pink, A Whole New Mind, which I think does a good job of laying out a lot of the aspects of why UX is important. The book isn’t specifically UX-meant originally. It won’t be in the UX section of the bookstore, I guess is what I’m saying. But it really does a wonderful job of laying out the case for why the trends are going to continue to go that way. And so I encourage people to go check out that book if they’re interested. But the people that do UX, meaning they’re able to work together with other people in other disciplines to build better designed experiences, are the ones that are going to really be able to find better work; they’re going to be more in demand. Like, from a programmer’s standpoint, right, just about everything we do could almost be automated or it’s getting to the point where it could be easily automated. And it’s no longer as highly demanded, I think, as it used to be or it won’t be in the future. And I think where the demand is are those developers that can talk designer-ese and, you know, can care about the look and the feel and the process and the user interaction and can enable those experiences in the work they do and can work with customers without people freaking out. We have to lock a developer in a closet because all they do is binary and pointers and other, you know, techno mumbo jumbo that normal people just aren’t able to get. I think they’re going to be having a harder time. So that’s kind of my take on the whole UX thing.

  8. Ryan 00:07:47

    Yeah. It seems like more and more, basically as an industry, you know, development isn’t the Wild West. Like, people really aren’t impressed with you just being able to create something, right? Whatever space you’re in is probably already crowded and the big way to differentiate yourself is this experience that you create for people; and you see it all over the place.

  9. DK: Absolutely. And I think it will continue to be a trend.

  10. Ryan 00:08:11

    Great. It’s interesting that you really have this UX thing in a very complete way. I think usually when people are talking about the term, you know, “user experience,” you know, either they say UX designer or specialist, whatever -- it seems very nuanced because I feel like it’s usually talked about in the scope of the Web. Where, I mean, you’re actually talking about, you know, reaching out and touching a wall. Like, you’ve got a tactile experience. You’re actually working with lights. You know, you’re working with more than just, you know, the two dimensions and sound that I think a lot of Web guys are so that’s interesting. It seems like maybe it’s almost easier for you to kind of have the conversation about how your role is different from other design aspects just because you do get to play with the full palette.

  11. David 00:09:01

    Well, I think so. A lot of people, you know, they’re pigeon-holed and they’ve kind of done it to themselves. I mean, it’s a trend or has been for the past couple of decades. People specialize and they focus on their little piece and now, you know, they throw this UX thing in there almost because it’s cool without really understanding what that necessarily means. And I think, in a lot of ways, it’s being abused or it’s just being used for marketing purposes without people really understanding. I know I was asked to do a presentation for the Seattle Graphics Designer Guild because those people had been doing graphic design for 10-20 years and wanted to know what UX is so they could put it on their resume. And I, you know, I think that’s great, but you really need to understand what that means to really make use of it. And I think, you know, fine, it might help you get a job, but understanding UX as a whole, being able to look at that bigger picture, is where it’ll also help you in your career and to come out of that deep specialization that people have done. And it’s going to help people kind of broaden their skills set even if, you know, they might be deeply specialized in X, Y, and Z, but, you know, at least being able to talk to these other disciplines easily and jump in with the programmers or the designers or the IAs and do this kind of UX stuff, it helps them do their deep specialization just that much better, right? So at least in a lot of the work I’m doing is I try to encourage people to reach out to, you know, broaden their skills set at least a little bit; enough that they can work with these other groups of people so we can stop being so siloed and so specialized, right?

  12. Ryan 00:10:54

    Yeah. It definitely makes sense to me. I’ve been going around giving this presentation to different usergroups and things, you know, Modern Web Concepts. It’s basically talking to developers about how to, you know, kind of make better products and kind of enjoy it better. And one of the things I talk about is you need to bring a designer in earlier. But really, I think I say design because, you know, working in a small shop I tend to put, like, all the UX, the IA; it’s sort of the responsibility of the designer as sort of the empath on the team. Where I guess, you know, really thinking about this in a broader term like in a firm the size of yours, it would -- I should probably be talking about that UX guy. I guess, personally, I tend not to use that term because it seems like, you know, in my circles it’s being abused, like you said, right? Like, to speak its name is to own it. Where it’s hard to not sound like you’re just trying to claim this title for SEO purposes.

  13. David 00:11:50

    Yeah. I think it shouldn’t be just the designer owning the UX. That’s the whole I think part of why it’s, you know, it’s not the UX designer and UX developer. I mean, everybody should be able to put UX by their name, which makes the term kind of irrelevant, but…

  14. RP: Good product, right? At that point.

  15. David 00:12:07

    Right. Right. It’s everyone should care about UX. It’s the developer, the designer, the business owner. Everyone should care about it and it shouldn’t be just the -- you know, developers have a lot of good input into wireframes, just as designers do. From, “Hey, that data’s going to be kind of hard. Maybe we shouldn’t put that there or not do it at all or do something else which affects the end design.” It’s when everyone communicates about things and kind of does it as everyone is, you know, a UX this and a UX that, you really get a better end product in most cases.

  16. Ryan 00:12:45

    Yeah. I agree. I think, you know, the real endgame would be that things like a good product isn’t something that you feel like, for one reason or another, is like a bartering chip, right? Like, you shouldn’t have, you know, the designer saying this is the better product when, you know, like you said; sometimes you can make an app more performant or, you know, even if it’s just talking about scale. And if you put certain bits of data on certain pages for caching purposes, that is part of the experience as well, right, and it shouldn’t be taken for granted.

  17. David 00:13:12

    Absolutely. The user experience is everything. It’s the experience that the user goes through. And that’s from performance to caching to the design to the color to the environment to the screen it’s on to the -- everything. You know, everything is about the user experience, really. Or it affects the user experience; I guess maybe that’s a better way of putting it.

  18. Ryan 00:13:38

    I like the concept that you brushed up on there that, you know, really the whole thing about user experience should become so far-reaching that the title becomes irrelevant, right, because it’s just this thing. I think that would probably solve a lot of the semantic quibbling that I see going around the Internet and about whether or not they should use these titles and who’s allowed to use this title and things like that.

  19. David 00:14:01

    I agree. I think as the term UX, though, becomes more ubiquitous in the work that we do or the industry, you know, you probably won’t see it as much anymore. It’ll just be assumed. And I think, at least right now, part of the benefit of everyone using that term, even if it is overused, is it’s starting to get companies to pay attention. Which is, I think, part of the big problems now is having companies appreciate UX. You know, there’s a lot of big corporate development shops that, you know, you suggest having a designer involved in building the UI of something and they’re just like, you know. The idea of UX, you might as well have told them to, you know, fly to the moon and write your software there. You know, it’s just they think it’s a ridiculous idea. It’s inefficient use of resources and a waste. You know, they want to see the return on investment. And so having UX so overly used, you know, is going to I think in the long run get the term phased out, but it also helps raise that awareness in the industry, which I think -- by companies. By the non-UX people, which I think is kind of an important aspect; as overused as it makes the term.

  20. Ryan 00:15:25

    You know, it’s the same thing with lots of terms in our fields though. I mean, it seemed like for a long time, you know, AJAX was a thing people talked about. Now if someone says they have, you know, “We solved this in an AJAX-y way,” you almost kind of like, “Well, of course you would, say, do that asynchronously because of, you know, the nature of the problem you’re solving, but really, did you just put that as a bullet point?”

  21. David 00:15:46

    You know, AJAX was -- that actually hits on another pet peeve that we didn’t mention and that’s the use of marketing terms to rehash technologies that have been there for 10 years.

  22. RP: Right.

  23. David 00:15:58

    You know, what is AJAX? The use of JavaScript and calling stuff asynchronously on a Webpage. It’s not like that was called remote scripting or SOAP or any other way of doing it.

  24. RP: Right. DHTML.

  25. David 00:16:14

    Yeah. DHTML. You know, I remember doing stuff 10-15 years ago, you know, in, like, Netscape 2. Where you have a zero-width frame and loading stuff there so you can get data from the server to change stuff on the page so you could do “asnyc” -- they’re rehashing, you know, whiz-bang versions of stuff that have been around forever and it just drives me nuts. Like AJAX and jQuery and JSON -- ooh, there’s a new protocol we’ve just invented. You know, people have been doing string. or, you know, whatever, string.eval or whatever it is that you just eval and you pass in the string in JavaScript for a long time to reconstitute stuff and they just -- someone gave it the name and called it a new protocol. I mean, really? Is the new protocol -- it’s all, you know, marketing mumbo-jumbo.

  26. Ryan 00:17:11

    Yeah. Well, it’s sort of like what you said about the UX though. I think sometimes they do service a greater good even though it is really frustrating. I think especially if you’re, you know, kind of, of the ilk that communication (clear communication) is important to you. Like, all these new buzzwords and kind of the overuse of them. I mean, hey, I’ve got “cloud” in the title of this podcast, right? I’m sensitive to this. But people use these words and, you know, you get really frustrated because you’re like, you know, it’s very much like The Princess Bride. Like, I don’t think that word means what you think that means.

  27. David 00:17:41

    Right. Exactly. You know, it’s not like we have been using the "cloud," for example. You know, what has the Internet been up until now? So it’s the cloud is some new thing we’ve come up with the past few years?

  28. Ryan 00:17:54

    Yeah. Well, it’s hard because people, like, the term kind of meant the Internet and now it has to mean this idea of, like, hardware abstraction. And it’s like, “But that word. People are already using it. They’re already using the illustration in their pitches, like…”

  29. DK: They’re overloading the terms to mean different things.

  30. RP: Yeah.

  31. DK: But, you know, it serves a purpose sometimes, but it’s a little annoying.

  32. RP: Yeah. Well, I think you really just have to take a step back and just, you know, just focus on making good stuff, right? And just let the communication kind of hash itself out.

  33. DK: That’s right.

  34. Ryan 00:18:27

    So what kind of things -- you talked about these huge, like, environmental pieces that you’re doing. Like, big touchwalls and various installations. What is the scope of the kind of project that you work on? Like, it seems like you’ve described everything from phones to huge, you know, installation pieces. Is it that? Everything in between? Like, what do you work with on a typical day? Does that exist?

  35. David 00:18:49

    Well, you know, the projects are pretty eclectic, really, but recently we just wrote the Phone 7 version of Allrecipes; it was a popular iPhone app and so we took the Metro aesthetic and Allrecipes, kind of, brand and the Web services that they had and made a Phone 7 version of that. And it’s, you know, in the marketplace now; it’s a free app. But then we also do big projects like the Nike Touchwall in New York City. Or if anyone’s gone into any of the Microsoft stores popping up, we designed the retail kiosk where you buy software; it’s a touch display. And they manufacture the software in the back. And then you see where the software is flying on the wall up above that touch kiosk. That whole interaction space thing we designed. Although they did not make the corrections to the lighting. I just -- if you actually go in the store, my biggest pet peeve was the lighting for -- the way they did it is just horrible. But…

  36. RP: Now you definitely sound like a designer there, right? Like, the execution of this is not up to the spec that I demanded. The big caveat, right?

  37. David 00:20:09

    That reminds me, I -- my career has kind of orbited Microsoft for a long time and I went to this architectural, technical review thing about some topic I can’t really talk about without the NDA ninjas assassinating me. But I come in there and it’s a bunch of hardcore software architects in there showing me some new stuff and I’m, like, complaining. You know, I raise my hand, so, “Hey, you know. I can’t look at this. It’s just too terrible. This, like, alignment here is, like, three pixels off.” And these are all my old, like, architectural people that are, like, uber-programmers. We don’t care about design. And they’re just, like, rolling their eyes saying, “You sound like a freaking designer.” But, you know, design is important to me. I’m not just about code. It’s about that overall experience and, you know, this stuff matters to me. And I think that it also helps us build better stuff is when everyone cares about all the aspects of that experience and those developers sound a little bit like designers and the designers maybe even might say some developer-y things now and then. You know, it’s -- I think it’s important to be able to bringing everyone together.

  38. RP: I mean, really it shouldn’t be a thing about, you know, designer vs. developer, but it’s just a quality of execution, right?

  39. David 00:21:35

    Yes. Yeah. And I think that’s something that’s really been part of my career the past six years or so is, you know, unless it’s absolutely perfect, you know, I’m not interested in doing quickie projects that are half-baked, generally. You know, I might have some Phone 7 apps that I whipped together to try this aesthetic or that aesthetic or something privately, but, you know, in my professional life, if it’s not good enough to be, you know, the best of the best, you know, it’s like (and I think that shows in the work that I’ve worked on; everything from Entertainment Tonight to the Emmy Awards to Nike to Bill Gates demos or Ballmer keynotes or whatever it is) everything has to be absolutely, from a UX standpoint, freaking perfect, pixel perfect. And that’s been kind of the highlight of everything I do. And I’m just not interested in being on stuff that isn’t going to be done at that level.

  40. Ryan 00:22:35

    Good. Good. I think a lot of people could learn from that, right? Like, again, back to what we were saying before. Less and less are people proud that you can just achieve a result, right? You need to do good stuff to really differentiate yourself.

  41. DK: Yes. I think -- I absolutely agree.

  42. Ryan 00:22:51

    So you talk about being Microsoft-centric and the solutions that you’re making are leveraging a lot of Microsoft technology. And you definitely have a very design-oriented team. Where do you find all of these designers that are using Blend? Is that the way the workflow works or is there something else that you do?

  43. David 00:23:11

    No, no, no, no. So I wouldn’t even say we’re a Microsoft shop. We’re an Adobe Design studio, you know. Our design teams live in Photoshop and live in Adobe Illustrator, but we’re still able to workflow. I know Microsoft talks about this whole, you know, designer/developer thing with Blend and Visual Studio, and that’s totally true, but that workflow can be done without having to force designers into tools they’re uncomfortable with. And the return on investment for that is just not realistic for most shops. You can’t just tell the designers to jump ship and use these other tools they’re unfamiliar with. That’s not going to be productive. That’d take you years to build up a team that’s capable of doing anything. Now that being the case, what we’ve learned to do is learn how to merge those tools together. The designers: they don’t need to know anything about Visual Studio. They just need to know how to present their work in a way that we can work together. So, like, when doing font work, you know, I want my font redlines in Photoshop. All of them will be in Photoshop and that’s because I can dump that stuff into Blend/Visual Studio and it comes across perfect. All the design work needs to be done in Illustrator. And, you know, we have, like -- I think I have, like, seven rules or so. And I think one is about font redlines in Photoshop because they port in pixel-perfect. I need the TTF files so that I can render those fonts perfectly. I need everything, all the design work done in Illustrator because it comes in perfectly. I mean, if a designer takes the time to design their stuff in Illustrator, to drop that into the canvas -- make sure it’s on the canvas. I know some designers don’t like it in the big gray box, but it needs to be in a gray box. I mean, it can go outside of that, but it has to be built out of there, right? And then they layer their stuff and they give things intelligent names. So then I, for the most part, can write code directly against that. And I can even take updates. They can do more design work and as long as the structure stayed the same and the name has stayed the same and I’m binding all my logic to the names and not directly into the output XAML from that conversion, they can keep updating the design while we’re doing development. And you get that Blend/Visual Studio kind of effect, but they can live in those tools and we get that benefit of being able to work at the same time on the same things. And so instead of taking twelve weeks, we now do the project in six weeks because it’s no longer the design team throwing it at the developer team over the fence, it’s a team working together to build that experience. And then we also use integrators, but we don’t have a lot of them because there’s not very many out there, that designers that can live in Blend that maybe can work with data and do minor tweak-y things. And so the developers, though, will use, you know, engineering practices that allow those designer types (the few that we have) to be able to make sure that the designers can see how their stuff renders in real time with, say, data, right? Which is a big part of, you know, if it’s a business app especially, you need, kind of, interesting data and you need to see that in the design tools so you can do the proper design. And so there’s, you know, rules around that that I have developers do so that that stuff is easily consumed in kind of the design tools and can be easily visualized and we can work through that stuff. And, you know, anyone that’s not willing to kind of contribute to that is kind of out, right? And so that’s really the kind of shop we are. We’re not a Microsoft shop. The reason our end stuff happens to be Microsoft stuff doesn’t mean that that’s our tool set or that that’s our primary thing. We do it for a business reason. I can build/design something in Adobe quickly and the designers do a wonderful job. And I can get that together faster than, say, Flash, for example. And I’m not -- nothing wrong with Flash. We’ve done a lot of it, but I can do the same thing with a WPF or Silverlight and end solution even if it was designed in Adobe twice as fast or more, right? So from my standpoint, I need to be technology-agnostic. It’s not about the Microsoft Kool-Aid, as it were. It’s about the best solution for the end user. You know, some of our stuff is on the iPad, right? And we’ll do stuff that was partially designed in Adobe and hacked up with Microsoft tools and then ends up as an iPad app.

  44. Ryan 00:28:27

    Awesome. I’m really glad to hear you say this. It’s funny; just this weekend when I was giving that presentation I used the exact terms, you know, “The design ought to be, you know, technology-agnostic.” It’s interesting that you go the same way because someone was asking me, you know, devil’s advocate saying, “What happens when the technology constraints stop you from being able to solve a problem in an appropriate way.” And I say, “You’re using the wrong technology at that point,” right?

  45. David 00:28:50

    Exactly. That’s -- you know, it’s about reaching the most users, whatever that target demographic is. And you know, in a retail place when I control the touchwall, yeah, I could dictate whatever technology is easier for me to deliver. NewAirplane.com, if you go there and click on 737 and explore something like there, there’s -- anyway, there’s this 737 Explorer we developed for the Boeing corporation that is an example of one of those systems that, you know, it’s been designed for the largest audience possible where it lives out in Azure, there’s an iPad version, there’s, you know, we’re using AJAX to swap out those deep zoom images, there’s a Phone 7 version. And it’s like we were saying, you know, it shouldn’t be about the technology; it’s about reaching the target demographic. And if I need to do that on iPad or I need to do that on whatever, that’s what I need to do to present things to those users. And so like with us, you know, fine a lot of our touchwalls are WPF because it’s easier for me to build that best of breed solution with, you know, that wall being based on Microsoft technologies, but that doesn’t mean it’s designed with Microsoft technologies. Or the same thing with the iPad. Bits of the back end might be built in Microsoft technologies, but it’s all iPad Kool-Aid on the front end, right? And then learning how to modularize the bits of technology that you use really, kind of, help us build that best of breed, but at the same time very far-reaching across all the devices. And that’s one of the reasons why HTML5 is so popular, speaking of rehashed marketing terms. But, you know, it’s this concept of HTML5 applications where if I can build one app and it runs on iPhone and Android and Phone 7 or Windows 8 or whatever, that’s just so much the cooler thing to do, right, because you reach that larger demographic.

  46. Ryan 00:31:01

    Yeah. It seems like you want to, you know, smoke test any kind of app in HTML. Like, that just makes sense to me. And then when you need a richer experience or you get traction in a certain market, then go back and make that native app once you need a little bit more.

  47. David 00:31:14

    Yeah. Yeah. And that’s exactly like with that NewAirplane Explorer, that’s what we did. All those -- it’s the largest deep zoom (composed deep zoom) system ever ever ever, but it’s all been built in a way there where I can do it in HTML4 with some AJAX, right? And then present a custom UI on any device that can render that from Android to Phone 7. And then I can give those richer, even more intense experiences, on, say, touchwalls using some WPF or Silverlight, but consuming all the same assets because it was designed that way so that I could use it across the systems. But people need to kind of take that into consideration when they approach a UX project up front because if you go down some road on XYZ technology and that’s all you’re focused on, by the time you get to the endpoint, you know, you’re pigeonholed with that audience that can consume that technology and it’s going to be much the cost for you to deliver that to another, say like if you had built it for iPhone in Objective-C instead of in HTML5. Now if you’re trying to port Objective-C to Phone 7 that’s a huge -- you might as well just start over from scratch. It’s just not worth even considering.

  48. RP: Yeah. You know, the user interface is just so different, right? Like, the native experience; how you’d want to kind of mock that up.

  49. DK: Yeah. It’s an entirely different metaphor.

  50. Ryan 00:32:50

    Well, I think this is fantastic food for thought. I feel like we could talk about this kind of stuff all day long, but we’re going to have to leave the audience wanting more. Maybe I’ll have to get you back on here sometime.

  51. DK: Oh, no worries. Just let me know.

  52. RP: All right. Well, thanks a lot for your time.

  53. DK: My pleasure.