Roger Belveal talks about Agile software development, how you know if you’re a UX designer, and other fascinating topics. Hosted by Ben Judy.
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 one. I’m your host, Ben Judy.
In this episode, I’ll have a conversation with our guest, Roger Belveal. We’ll talk about Agile software development, how you know if you’re a UX designer, and who knows what else might come up. It’s going to be a fascinating conversation, I’m sure. Let’s get right to it.
So hi, Roger. Why don’t you tell us about Roger Belveal.
It’s good to be here. Yeah, it’s been a long road. I’ve been in the UX field for about twenty years, give or take, in aerospace, financial services companies, and a lot of different methodologies and environments, different cultures.
We were talking about Agile earlier. You know, it seems that people who have been in the trenches doing UX in Agile projects are just now really starting to come out with their conclusions and observations. I think it’s been a little bit late in coming.
So having been one in the trenches myself, you know I have some conclusions, observations, lessons learned from that.
Sure. Let’s back up just a little bit. Would you call yourself a user experience designer? User research? Information architect? These titles we throw around. How would you label yourself?
I think I’ve used all of those titles and a lot more. I’ve billed myself as a business analyst, a user interface designer, architect, usability specialist. I’ve done the evaluations, the labs, formal labs settings, field research, design.
My background is actually as an industrial designer. But like many industrial designers I morphed into a UX designer quite some time ago, because that’s where things were going.
Sure. So in all of your work as a UX’er, how much of that has been working with developers in an Agile scheme as opposed to waterfall?
Well, that’s an interesting question. You know, one of the things you see when you’ve been in the field a while, in any technical field, is you see the same concepts evolve with different labels, different turns, and a little bit different twists.
So, going back a few years even when I was working for a big airplane company in Seattle, we did Agile by another name. It was called Concurrent Engineering. For me this is a big reference point because working on the triple-seven airplane it was really an Agile project – although they didn’t call it that – but it incorporated some of the primary features of an Agile project: iterative cycles and so forth.
I think that’s a success story. Comparing that with some of the other, uh, less than successful projects, I’ve been able to compare and draw some conclusions from that.
So, you know, first of all – and some of my former coworkers have called me “Metaphor Man”, so I’m just warning you – that I would characterize Agile, in short, as 26 cement mixers pouring feverishly while somebody looks in the Yellow Pages under “architect.”
And the reason for that is when you’re in a code environment, you know, people can debate on a project timeline as to when code freezes. But we all know when it freezes: it’s when it’s written. Because, like the cement mixers, after it’s poured and set up, you can go in and jackhammer it and re-pour it again, but nobody wants to.
So, once any code is written, chances are it’s going to stay the way that it was. Now, I’m not saying it doesn’t ever change, but it’s an uphill battle.
So, going back to the triple-seven airplane, there were some key features. One notably that they called the Digital Preassembly. The entire airplane existed in a flexible, electronic form before the first piece of metal was put on a milling machine. Having that flexible format in which your design can live and evolve before you’re committed is really important.
So how we do that in a software development world – you know, people can mention, you know, things come to mind as far as different ways of modeling things. And we can go down the whole prototype path and talk about options there. So having things flexible matters.
Now, I also want to say that Agile is really good or really bad. It depends on your definition of “iteration.” True iteration is never having to say you’re sorry, to borrow the term from the ‘70’s movie. It means everything is up for revision.
I would also compare it to, say, what people usually do when they say iteration – and I don’t want to say usually, but often what I’ve seen – is what they really are doing is increment. Let me put it this way: an increment is what an inkjet printer does when it’s producing an image, and it goes line-by-line across the page. It’s extremely efficient, but it requires the image to have already been defined in utter detail. Iteration is what Leonardo DaVinci did or what any painter does. Doing a rough sketch and then step back and look at it, evaluate it, refine it, adjust it, refine it some more, and eventually work in the level of detail so that you can start putting paint to canvas, and then it becomes a finished image.
So increment works really good for construction, but it’s terrible for design. Iteration is the way to design. If we can kind of just understand those two concepts when we approach Agile, and make sure that we’re being deliberate about which one we’re doing at any given moment, I think we’ll have better success.
What do you think UX designers, UX practitioners, have to offer in an Agile context to developers, to business, that’s unique? From your experience as a UX’er, when you come to a project that’s doing Agile what are the things that you bring to the table that might not be there if you weren’t there with your UX perspective?
One thing – going back to the triple-seven airplane – there’s an important ingredient also before you start down the Scrum path where everybody is, you know, working on this iterative process. Somebody has to have a vision to start with. The grand scheme of things.
It doesn’t have to have every detail in it. It can’t have every detail in it. But there needs to be an overall vision for what this thing is that we’re building and why, and where it’s going. I think that’s what the UX profession provides more than anything. And whether you want to call it a mini-waterfall or a pre-Scrum iteration or something, the fact is that vision has to be defined going in to the Scrum process. UX has to be on board early on when the business folks – whoever is funding this project – says “we’re gonna take the hill,” UX has to be there to define what that means in terms of the user experience. Then, once that’s defined, then we can come alongside and work in parallel and work as part of the Scrum team to work out the details.
What would you recommend to a team that is trying to evaluate whether they need to take an Agile approach or a waterfall approach. They’re not really sure what their process should be. Maybe they don’t have a process. How do you evaluate which? If it’s an Agile versus waterfall discussion. You often hear it phrased that way. Maybe that’s right maybe that’s wrong, but how do you evaluate which approach is the right approach?
I think the Agile approach is the best approach on this condition: that there is some commitment that has to happen in order for it to be successful. Otherwise, you’re going to shoot yourself in the foot. The commitment has to be three things.
First of all, everybody has to sign up to being willing to work with preliminary, incomplete, sketchy input. You’re not going to have all of the information you need to get started. You going to have to wing it, okay. And everybody has to sign up for that and say, yeah, we’re willing to do that.
The second thing, on a similar note, is you have to be willing to change whatever you’ve done. So, as you create that sketchy – the best output you can given the input that you have – you have to be willing to revisit that and change it all again once you discover better information, or somebody provides you with better input.
The third thing is the overall process has to have a provision for doing that sync-up; for doing that revision. If you don’t plan for being able to respond to what you learn as you go along, then what’s going to happen is at the very end of the project you’re going to be victimized by your own bad guesses that you had from the beginning, because you never moved beyond those.
So, again, back to the cement mixer, that’s how to prevent the cement mixer thing from happening, and how to really take advantage of the power of iteration. It is powerful. It does work, but there are certain ingredients that have to be in place for it to work.
Let me take just a moment to talk about our show sponsor.This episode of the DFW UX podcast is sponsored by Experience Design Consultants. XDC is a consulting firm based right here in the Dallas-Fort Worth metroplex, specializing in usability, user interface design, and user research for web sites, desktop software and mobile applications. XDC leverages the diverse pool of UX talent here in the metroplex to match just the right UX professional with your project needs. Visit Experience Design Consultants today at xdconsultants.com. And we thank them for their support of the DFW UX podcast.
You were talking about UX in general. As UX people, we’re all kind of watching the state of the union regarding our field. It continues to grow in prominence and people are more aware. There’s always the question of once people are aware, do they really understand what they’re aware of, and what are the misconceptions?
I think we battle more these days with just correcting misconceptions and educating people about what it really means and how to do it. The awareness battle, I think, is pretty much over and has been for some time.
Whitney Hess has a blog called Pleasure and Pain, at whitneyhess.com. She wrote this article, looks like it was published April 23, 2011. The title of the article is, “You’re not a user experience designer if…”
What she tries to do is define who is a user experience designer kind of by ruling out those who aren’t.
It’s kind of like, “You’re not a redneck if…”
Exactly. Exactly. So she outlines ten things that kind of help you determine whether or not you’re a UX designer. We can run down through this list and see what you think.
Okay. Sounds interesting.
She says you’re not a user experience designer if you don’t talk to users, if you can’t identify your target audience. In other words, she says if you say your product is designed for everyone, then you haven’t really done your job. You’re not a UX designer.
I’ve been in that spot before where you go into a project fresh and you’re asking the people on the project, “well, who is this for? Who’s going to use this?”
“Well, everyone’s going to use this!”
Well, that’s not the answer. Okay.
You don’t define the problem before trying to solve it. So you’ve got to ask, “why?” You know, “why are we designing what we’re designing? Why are we building what we’re building?”
If you can’t articulate your users’ goals, you’re not a user experience designer.
If you design in a vacuum. I thought that one was interesting. No user experience designer works alone, she says. And if you do, you need to find other people who can review your work and provide feedback.
Yeah, even if I could design in a vacuum, I wouldn’t want to. It just doesn’t feel right. I need feedback. I’ve given you some designs to look at. I’ve actually got some more for you to look at today, too.
So how about this one: “If you make design decisions based on your personal preferences, you’re not a user experience designer.”
We’ll there’s an interesting debate about that, you know, with the 37signals style. And everybody applauds their success, that’s great. You could argue, I suppose, that Steve Jobs is designing for his own preferences and he’s done really well, and nobody can debate that.
Although, I think sometimes the whole genius design approach has merit, but it really aggravates the UX crowd. I think the purest, almost the fundamentalist usability people – I’m talking about, you know, I’m part of the UTest thread online and some other groups – I think it really aggravates people. And puzzles them how somehow Apple seems to break all the rules of usability engineering and yet wins.
So, I think that’s a puzzlement. I’ve spent some time thinking about that and why is that. I think Apple does a few things extremely well. They’ve chosen their strategy and it works. Now, would that same strategy work for everybody? No, I don’t think so.
It sounds like she’s outlining – you can call yourself a user experience designer, and really everyone is a UX designer in the sense that everything you create will produce experiences as soon as someone interacts with it. I think it’s really just about one angle on how to do it well. But your point is well taken that there are those out there who don’t necessarily conduct user research, who do design for themselves, and they seem to produce experiences that most people think are great experiences.
And you don’t hear about the ones that fail.
Right, they don’t succeed.
It’s easy to point to Apple and to 37signals and the ones whose personal preferences happen to match that of their audience, and I think this is something that Jared Spool talked a lot about. If you, yourself are a good representation of the audience that you’re serving, then yeah, you’re a great model to design to. Go for it. But if you don’t, then you need to be aware of that.
In my experience, I’ve designed for a lot of different audiences. I’ve designed for some business-type people who love spreadsheets, and I hate spreadsheets. Well, I have some love-hate relationship with spreadsheets. But my point is, I recognize that they think differently than I do, and when I’m designing for them I have to take a different approach than I would if I was designing for people like me.
How about this one: “you don’t consider the business objectives.” So, if you don’t consider business objectives along with your user goals and meeting your user’s needs, you’re not a user experience designer.
I’m glad you brought that one up. Because I want to say that’s maybe the most important thing. We can always find something else and [say], “oh that’s the most important – oh, this is the most important thing!” There’s a lot of important things.
But undertaking a project, there’s always some business reason we’re doing it. Somebody’s funding this project, right? So there’s some business goal. Now, sometimes that is articulated and sometimes it isn’t. We have to find out what that is. But we also have to understand what the user’s goal is.
Really what we’re talking about is a business relationship that’s like any business relationship; somebody wants to buy something, somebody wants to sell something. Where those paths cross, where those objectives intersect, you have a deal. Both parties are happy with some transaction, and everybody walks away happy, hopefully. And everybody makes money and we get paid.
If we fail to understand what our user’s goal is and how may in fact differ from the corporate goal or the product goal, then we can’t accommodate that. Our purpose as designers is to create a situation and environment where that match can happen. In a sense we’re matchmaking. We’re like doing match.com or something like that, only you know the parties are the business and customer. We’re trying to make that relationship happen.
So we have to understand it each – and I’ll say eHarmony too, to be fair – we have to understand the profile of each party involved so we can help make that match. And that's what good salespeople do in real life ,and we’re emulating that online.
This one might be my favorite: If you don’t use UX methods, you’re not a user experience designer. So, user interviews, usability tests, personas, scenarios, card sorts, affinity diagrams, concept models, et cetera. If you don’t have a systematic approach for articulating what you learn about your users to others on your team, you might be trying but you aren’t a user experience designer, says Whitney Hess. Your thoughts?
Well, you know, using the tools is expected. However, it’s not like we have this toy box full of – oh, let’s pull these out and just spread them out on the floor and just use up all these things – because there's usually a hundred things that could be done, but there's usually – I would say there's always some finite amount of time and resource; access to users. There’s all kinds of constraints that we have to work with.
So the question is: which tool is going to give us the results that we need right now in order to move the project forward? So you really have to assess the project. I mean, it's like going to the doctor and he starts throwing all these treatments at you because he has them in the room. He has to do an accurate diagnosis as to what is going to help the patient improve and then apply the correct method whether that's an analysis method, some diagnostic tool, or an actual prescription, you know.
And we have to be the same way with the design problems that we’re trying to solve. We have to understand the problem and I think she mentioned that as one of the first points, is to understand problem that were trying to solve and then we can select the correct method. And there’s almost always some tweaking that has to happen of the method. Very seldom do we apply the method straight out-of-the-box in a cookie-cutter fashion, because every situation is his unique in some way.
And I think it's about having a systematic approach so you don't wing it. You don't spread the tools out on the floor and maybe use them, maybe not, maybe try one out just to see how it goes. It's having, I guess, the experience to know, as you said, which ones are appropriate in certain situations to achieve the goals you're trying to achieve. But it's about having a systematic approach that you can articulate. And at least in my experience, that’s the piece that separates, you know, kind of the “newbies” from the real pros, kind of the “old hands” in UX. You can explain what your process is and what your approach is.
You’re right, there is a process that you go through – and I’ll give another metaphor, I don’t know if this works for people but, you know – here’s a sheep with wool on it, here a knitting needle, now make a sweater! There’s a process that you have to go through. There's these intermediate stages where in our case it’s like getting the wool off the sheep. We have to go and get the requirements and understand – whether we’re working with some business analysts or doing it all ourselves, or there's already some requirements in which case I want to use him, but I also want to question ‘em – but there’s a process you go through and you develop those.
You go through some analysis steps in between and eventually you arrive at some design. I skipped over a whole bunch of steps there, but the point is you can you can go light on those steps sometimes, but you can’t skip them altogether.
You know, in the old days people just pulled designs out of the air. And developers were notorious for doing that. And then we kind of reached this level of maturity where we’d do a whole bunch of analysis and then we would pull a design out of the air!
And that somehow made it better.
And that made it better! And people would get, “I don’t understand it, we did all these techniques! And yet still we’re struggling here!” Because there should be a thread. You should be able to follow this process from that beginning stage all the way to the end, and you should be able to see the connections in between. I think that's what you're getting at with this discipline of having an approach or methodology.
Now, again, that's not applying every toy in the toybox. I'm thinking back to the early days of desktop publishing when all of a sudden people had 150 fonts that they could use. And they use all of them in one document! Okay now you have to understand, why would you use a particular font for a certain document. So there's a whole method to that.
Okay, the wrap this up, there’s two more on the list that Whitney Hess published. The 10 things to know whether or not you are a user experience designer. Number nine, you don't design for conditions and edge cases. If you don't do that, you’re not a UX designer. So, yes, you design the happy path, but you’ve also got to account for things like branches, escape hatches for alternate needs, user errors, system errors, general curiosity; you have to account for those things to be a user experience designer. That just sounds like common sense to me.
Yeah, and here’s another metaphor. If I were designing a bowling alley, I would design it with the gutter in the middle. And the idea is that we know, maybe – apply the 80/20 rule, and maybe it's a 90/10 rule – 90 percent of the time we know, hey, you want to bowl a strike. Just follow this gutter and everything will be fine. But there's these oddball cases for whatever reason. This is where the metaphor breaks down because I don’t know why you would want to do something different in bowling. But there's these odd cases where you need to do some different and you have the ability to do that.
We have to accommodate that, but we don't design for the exception. The happy path still has to be there in the most prominent form with user control to depart from that and pick up those spares, whatever that happens to be.
And finally on the list: if you only think about the interface, she says, you are a user interface designer, not a user experience designer, and there’s a big difference. That one really resonates with me. I think for long time in my career, early in my career, I was an interface designer. I didn’t really know what UX was. If I had, I might have thought, “well that sounds cool, I’ll call myself a user experience designer. But I wasn't doing these other things. I wasn’t conducting user research. I wasn't trying to determine what users’ goals are. I couldn’t really explain what my systematic approach to understanding user needs was. But I was pulling designs out of thin air. I was essentially designing what I thought looked good and what mapped to the business requirements as I understood them. And that made me interface designer. Maybe I was a good interface designer, maybe not. But I wasn't a user experience designer.
I think that speaks to taking it a notch above just redesigning what happens to be in the system already. It’s kind of a scope question. What is the scope?
Really, we can take a higher level, too, and often times the conversation elevates to this level of customer experience. So, yeah, we have user experience that's inside of an application that we’re maybe designing for the first time. Or were redesigning it. But then whenever I go and sit and watch a user doing a contextual inquiry, I’m watching them at their desk performing a task. And I see Post-it notes and cheat sheets. I see them writing things down. And I say, “what are you doing there? What’s that about?”
“Well, the system doesn't capture this information. I have to look at it here and enter again over here.” You know, there’s some extraneous task. And I'm thinking, the total experience is – the total user experience, or employee experience, whatever – incorporates those things. So I may choose to embed those things into the system, or, sometimes there's things that have to happen and they’re best done on paper. Now, I know I sound like a heretic for saying that. But there are some manual processes that make sense left as manual processes.
And then at the higher level, looking at the total customer experience. Of course, that gets into branding and customer service and quality of product, and that whole big picture which we’re actually a part of. And, you know, so you can’t have a failed customer experience in some other area and blame that on the UX necessarily. The UX helps to facilitate that, but it's part of that bigger picture.
Well, thanks Roger for joining me and having this chat. And I hope to talk to you again soon.
That's it for this episode of the DFW UX podcast. Thanks for joining for me. Remember to check out our show sponsor, Experience Design Consultants at xdconsultants.com.
During the program we mentioned a number of online resources, articles, various web sites and things. You can find links to all of the stuff we discussed in the show notes. Just go to dfwux.com and find episode number one.
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 at firstname.lastname@example.org or a private message on Twitter @dfwux.
Also we’re always looking for show sponsors. If you’d like to support what we’re doing – and as an added bonus get your name out there in front of a very targeted audience, the DFW UX community – check out all the details at dfwux.com/sponsors.
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.