Full Transcript

Adam Churchill: Welcome, everyone, to another episode of the SpoolCast. Earlier this summer, Cennydd Bowles joined us for a virtual seminar, "UX Design when Time, Money, and Support is Limited." Most UX designers have to work hard to make an impact in organizations that maybe aren't yet recognizing design as a competitive advantage. In this seminar, Cennydd shows us how to put UX principles into practice, really in any organization, and how to make the case for user-experience design with results, not just theory.

Lucky for us, Cennydd has offered to come back and tackle some of the questions we didn't get to address in the seminar. Now folks who didn't listen to the particular seminar can get at it in UIE's User Experience Training Library, which has over 70 recorded seminars from experts just like Cennydd.

Cennydd joins us today from the UK. Hello, sir. Welcome back.

Cennydd Bowles: Thank you. My pleasure.

Adam: Now, I guess for folks who weren't with us during your presentation, can you dive a little deeper on the overview that I offered?

Cennydd: Yeah, sure. So really, this seminar was all about why just learning the theory of user experience design isn't necessarily enough. I think there are a lot of people who know, you know who have good fundamentals. But among people I mentor and train, what I find most of them fall down on is the doing part, is actually getting it working in their organization, because very few of us are in a fortunate position where we work for a company that gets it. We don't all work for Apple.

So, while the books will suggest that user-experience design is this big, disruptive change, we're not really in a position where we can, you know, enact that kind of change. You need to be a senior executive, and, let's be honest, most of us aren't yet.

So this seminar was really all about presenting what I call undercover user experience design, as a lightweight way to introduce user experience practice without people really realizing what you're doing and asking those difficult questions that start those enormous conversations.

So we began by looking at research. I think the key there was that I think, for this kind of work, you need to start by researching the business rather than the users, because it's only by knowing the culture and really understanding what makes people tick within the organization that a good approach for researching users and for implementing UX kind of follows.

So we started looking at some of the cultural red flags that are worth watching for, what we call "cash cows" or enormous expectations, this kind of thing. And from there, then we moved on to quick-and-dirty research techniques, phone interviews and surveys and the benefits of remote testing, and also, importantly, looking at the data that you've already got within any organization, such as marketing data, analytics and so on.

So then we moved on to the idea of how you can make a case for the work you're trying to do. Is it even necessary? Can you get stuff done without proving return on investment? When should you try and make a case? And really, the key here was that we were trying to find ways to frame user experience as something that helps not just the company but also the individuals within it. So we talked about how to get developers, product owners, senior managers, et cetera, on board. How to, in essence, flatter them with the techniques that you're trying to apply.

So from there we moved into quick ways to involve that team, your allies, in these design activities, without this big hoo-ha that we're doing design, which is sometimes this scary thing for some companies. So we were talking about sketching and design games, and particularly how you can share the work you've done and make it visible. So you have this transparency to design, to show that it isn't this big, scary, unfathomable thing.

Obviously, around then, we talked about what formats you should do your deliverables in, should you go low-fidelity, high-fidelity, and so on. Really, what to choose at what stage. But the most important idea, I think, within this seminar is really on about how to iterate on the work you've done, learning particularly from internal critique and from user feedback and other data.

So we spent quite a bit of time talking about how to run a fairly informal critique session, and particularly when you should be ceding points for the greater good of your cause and when and how you should be standing up for the things that you're really positive about, you're convinced about, and how you find that corner.

And then we wrapped up by looking at how a company can progress through this user-experience maturity ladder, as it's sometimes called, and how far the undercover approach stretches before you need to break and then formalize some of the processes you've been drip-feeding into the organization.

So, for me, it was a really enjoyable session. With any luck, hopefully our attendees got plenty out of it as well.

Adam: I think they did. They were very engaged. Thanks for that summary, that overview. It was fantastic.

Let's get to some of those questions that we couldn't tackle. Erin wants to know, this concept of undercover, can only expert UX'ers go undercover effectively? In other words, do you need to know the rules before you break them, or can newbies and newbie teams start this way, too?

Cennydd: Yeah, that's an interesting one. I think there's something in the mindset of some expert UX'ers that often they tend to slide toward these more UX-friendly environments, just by their nature. Now, I'm not saying that, you know, people who aren't working in those companies aren't expert, but you can understand there's this sort of natural desire to work with people who kind of think the same way you do, where a lot of those battles are already won.

So, for the experts, sometimes there's a little bit less need. But, for instance, I've been doing this a decade, a decade or so now, and if I was starting a new role tomorrow in a company that didn't really grasp design, and particularly user-centered design, then sure, I'd use these techniques, absolutely.

Now, the people who are newer to user experience, they certainly can implement these techniques. But the main skill here, I think, is political astuteness, and a bit of diplomacy and a bit of knowledge of culture and how that works. So I would suggest someone who is, say, much newer to business and what it's like working in a large, complex team... you know, let's say a recent graduate or a 19-year-old or something like that. It's possible that they might struggle to do this undercover user experience design effectively, because they just haven't had a chance yet to build up that political nous, if you like. But certainly an older or more experienced office worker or company worker, who's still newer to user experience, could absolutely use these techniques profitably.

Adam: Our friends at the University of California Berkeley got some exposure to you. You were a panelist at a recent "Usability and the Business Analyst" meeting. They wanted to know, do you think adopting more of the language of the business analyst, such as, "business analysis" or "business process analysis" and "use cases," might be helpful in getting user experience accepted in a less consumer-focused organization? And that's, I guess, what they're describing as an example, such as a university.

Cennydd: Yeah. It's about matching the language and the culture of your organization to the approaches you use. So, certainly, you can do that. I do think it's a bit of a shame that some organizations perhaps think they don't need to be consumer-focused or, certainly, customer-focused. But obviously, changing the culture of these larger organizations is pretty much beyond the reach of us mere mortals.

So all I can say, it's really about understanding your organization, the language it speaks and the culture that it lives by, and then finding a way to synchronize user experience design to that heartbeat. So, if this sort of language is powerful, "business process," "use cases" and so on, then yeah, absolutely, use it. Language is a really powerful way to align those tactics.

Also worth having a look at the reward systems that are in place. I don't mean financially, but what do people reward within the business? Is it numbers? Is it a simple question of making graphs go up or improving percentages? Or is it stories, is it customer feedback, and so on? So what are the things that the organization is trying to achieve and people get rewarded for achieving. And then, again, synchronizing the work you're doing to those key points so you can have a little bit of amplification from that.

I would just say, if you are using the language borrowed from another discipline, you do need to be just a little bit careful about expectations. If people have an understanding of what, for instance, the business analyst does, and you're using that, if you like, as a bit of a cloak for your own agenda, if you like, then that may cause some raised eyebrows. And, of course, you don't actually want to become a fully fledged business analyst. Well, or do you? But if you're trying to unveil user-experience design processes, you need to be careful of just going a little bit too far and getting pigeonholed by your peers' expectations of that role.

Adam: Nash wants to know if you feel like undercover user-experience design applies in the cases of studios or agency-led design firms rather than in-house teams.

Cennydd: Absolutely, it certainly can. Now, there is an added tier of complexity here, which is billable time. So a client isn't going to pay for user experience design services if they're not on the project plan and if they weren't in the original pitch documents and all those sort of things. So you really need to find a way to weave user-centered design thinking and techniques into everything.

Now, the good news is that you'll still have to produce lots of deliverables that naturally benefit from user experience design thought. You'll still have to do mock-ups. You'll have to do some kind of research and some kind of plan of, you might call it a target audience or something like that. You're still going to have to decide the structure of the site or looking at the site map or an information architecture problem or whatever it might be. And these things are ripe for really lightweight intervention.

Now, you're going to have to start small, because you can't go adding two weeks of extra research into this plan. But if it's just a day here and there, I mean heck, you might have to use a couple of lunch breaks. You might have to stay a bit late. But you can start showing the value of user experience design.

Now, you have two sets of people that you can try and convince here. You have your team, your studio partners, your agency; and you also have the client team. The good news is that either, I think, will do. So if you convince one of those teams of the benefits of user-centered design thinking, then they will convince the other, quite naturally.

So if you've got your clients chomping at the bit, saying, "Can we do user-centered design work, user-experience work?" then of course your agency partners, [laughs] is going to turn around and say, "Yeah, sure. We can provide that for you, and here's a plan of work to do that." Likewise, if you've convinced other people on your team, then it makes it a more natural sales pitch and a natural way to introduce that to your clients.

So don't feel like you have to hit both. Chip away at both and then see which is giving you more results, and then maybe focus a bit more attention on that.

Adam: Bob wanted to know if you could speak a little bit more to the dangers of excessive patternization.

Cennydd: Right, yeah. So this is something we talked about in the seminar, about how and when you should use pattern libraries. I think it's very easy to make assumptions under the guise of saving time. Particularly when you're under pressure, it's easy to pull out sort of a prefab solution. So you go to your sketches and you instantly, just automatically put down a header and a foot and a left-nav and a carousel in the middle. And you know, that may be right, but it may not be. It's this unthinking use of pattern libraries I think is the danger, particularly because they leave us very little room for differentiation.

This is something I had a bit of a rant about at the IA Summit this year. To me, I see a lot of commoditized sites that are making up the majority of the web, and this doesn't really leave much room for real, genuine innovation through design. And hopefully that's something that's going to change, but I think we all have to do our bit.
So when we're instantly jumping to solutions, or when we're using patterns, be they external or be they implicit within our knowledge bank, we should just question every element: "Actually, is this pattern the right answer?" And that's really all we need to do. It may well be that, "Yes, that pattern is appropriate." But it may be that we just pull ourselves back and say, "Actually, let's look at this from first principles again. This is something that's important enough and different enough that we need to look at it again from this fresh perspective."

Adam: So Jonathan has a question about usability tests. He wants to know, how critical do you consider capturing the user's facial expressions?

Cennydd: Yeah. This is one of these things that I think, within the field, it's regarded as fairly sacrosanct, as something essential that gives real power. I'm going to be a little controversial and say, honestly, it's not always that useful. It's certainly nice to have. Now, if you have an expressive participant who has a strong reaction, be that positive or negative, to you know, some proposed solution or a mock-up or whatever it is, then that can be an extraordinarily powerful and convincing thing. Show that video to your stakeholders and they'll be won over very quickly. But honestly, how often does that happen? Really, not very often. It's pretty rare.

And so, I guess where this question comes from is when we were talking about remote testing. Obviously, you don't get access a lot of the time to that kind of the rich body language and that expressive information. There is a case to say that that is a disadvantage of it, but I would say that that disadvantage is generally outweighed by the advantages you get from remote testing, namely its cost and its speed.

And it's just something that you can outsource to an extent, depending on whether you're going moderated or unmoderated tests, and at least get more data points. And it's the quantity of those data points which is really important with that kind of research, I think.

Adam: Do you tend to avoid using user experience language, including that "UX" label, to remain undercover?

Cennydd: Yes, I do, at the start at least, because the whole point of what we're trying to achieve here is really to avoid disruption. I recognize it can be fairly counterintuitive to what we're trying to do. But I think it's better to leave introduction of the terminologies and the language, at least until we've had some successes and we've widened the net and the profile of what we're trying to do.

And then once people are familiar with some of these techniques, and particularly with the results of them, then it's OK to start introducing some of this language. So to say, "Well, hey, guys, this thing that we just did, hey, that was usability testing, actually," or "That was remote research," or whatever it might be.

But I would advise, with that, keep the language simple. [laughs] This is something that the UX field I don't think does terribly well. I don't see, really, the need for us to be using highfalutin terms like "contextual inquiry" when something like "fly on the wall" works perfectly fine and is pretty well descriptive to pretty much any business.

Adam: So Michael wanted to know...and again, this is an important thing that we have talked a little bit about in the virtual seminar, should the team conducting the testing be separate from the design team?

Cennydd: Yeah, this is a tricky one, isn't it? There's something of a philosophical point, and I don't think you'll find full agreement within the field, whether they're undercover or not. Pretty much everyone has their own point of view on this. So really, what we're questioning here is, which is more important, the retained knowledge you get from conducting the testing and then bringing that back and iterating on that yourself as a designer, or is it more important to eliminate any bias that goes with it?

But I do think, if you're undercover, certainly, potentially it's helpful to separate those teams, particularly because it does validate the effectiveness. If there are people who are still a bit skeptical about the work you're doing and the techniques that you're trying to introduce then, if the results perform well in a test that's moderated by a different team, then that's obviously a fantastic win for you. But to do that, then you have to train people. You have to train someone else to conduct high-quality usability testing, which you know, isn't that difficult, but it does start to sort of ask some of those questions about, really, broadening the scope of what you're doing.

So, to begin with, nice though it would be to separate those, I tend to say it's easier to combine them. But certainly, if you can train up a couple of allies who can test the designs that you're working on, then that's a really big win, not only for the validity of your trials but also just because you're embedding user experience expertise among some other people. So definitely look for that opportunity if it presents itself.

Adam: Well Cennydd, that's great. Thanks for circling back with us. We certainly appreciate the time.

Everybody listening in, thanks for your support of the Virtual Seminar program and for joining us today. Goodbye for now.