UX Advantage with Jared Spool & Karen McGrane

What does it take to create a culture of design? How does putting user experience first change the way organizations work? At UX Advantage, Jared Spool & Karen McGrane interviewed inspirational pioneers who deliver user experience as a competitive advantage to their organization. The UX Advantage Podcast traces the journey to that event with short bursts of insight.

Episode #1 Inventing the Yes Lawyer and Restructuring Incentives and Rewards

May 12, 2015  ·  21 minutes

Listen Now

Download the MP3

What does it take to create a culture of design? How does putting user experience first change the way organizations work?

Those are the questions being addressed at the UX Advantage conference. Jared Spool and Karen McGrane will be your hosts as they delve into a series of topics with top design executives. In this podcast, Jared tackles two of those topics, Inventing the Yes Lawyer and Restructuring Incentives and Rewards.

Show Notes

Bringing the regulation, compliance, and procurement experts into the design process early is a fundamental shift in corporate relationships. Hear how a “Yes” lawyer becomes an essential member of the design team and how the entire process benefits.

How does an organization measure the value of design—and evaluate the work of designers. Incentives and rewards are about performance management, HR, bonus pools, and goal setting. How do you shift the culture away from rewarding on delivery date regardless of the experience?

Full Transcript

Sean Quinn: Hey now, I'm Sean Quinn. Today I'm joined by the co-executive producer of the UX Advantage conference Jared Spool, who along with Karen McGrane have been working really hard on putting together a conference focusing on the UX strategies issues that no one else is talking about. In this podcast we'll dive into two of the UX Advantage topics, role of the yes lawyer and incentives and rewards. How are you doing Jared?
Jared Spool: I'm doing fine. How are you doing Sean?
Sean: I'm excited to talk about some of these topics with you and learn more about them and be able to share the information with all the folks out there who may be interested in learning more about it.
Jared: I am equally as excited.
Sean: Let's start with this concept of the Yes Lawyer. One of the topics that will be covered at the UX Advantage conference is, inventing the Yes Lawyer. I was wondering if you would take a few minutes to explain what a Yes Lawyer is and how they partner up. Or, the role they play in UX design?
Jared: People who have worked in business in any way, have encountered no lawyers. No lawyers are lawyers whose job it is to say no. You try and do something interesting and they say, "Unfortunately we can't do that. We can't do that because the regulations prevent us. We can't do that because the rules don't let us do that." "We have to put this out to RFP. We have to write the RFPs a certain way." Those folks, there are many of them. They're everywhere. The problem is, they get in the way. Particularly when you're working in a regulated industry or you're trying to do something interesting with an organization you want to hire. We run into these problems of these lawyers stopping progress. A few months ago, I was talking to somebody over at the US Digital Service. She was very excited about the fact that what they've done, is they've decided to bring legal staff into the digital service itself and tackle these no problems from the very beginning and have the lawyers understand what you're trying to do. She said, "We have lawyers who say yes." They say, "Yes, I understand what you're trying to do. Let's see if we can do that." I thought about that. I thought, well that's interesting. Maybe that's a government thing. The next week I was listening to Karen McGrane and Ethan Marcotte's interviews of the folks at Fidelity. They were talking about how they involved lawyers in their redesign of Fidelity.com. They involve their lawyers up front. Their lawyers got involved from the very beginning to understand what their intention was and to start to help them navigate the complex legal world of financial regulation, they had brought these people in. Then I met this woman at the US Digital Service when I was talking to them, whose job it is to figure out procurement issues. Government procurement is the big problem. It's, how do I bring in folks to work with? To do the work who are capable and not just the lowest bidder. They were embedding procurement officers into the teams and trying to make the contract officers understand what it means to do this. So, this idea of having lawyers as part of your team grew out of this. This is a new idea, but we all have been involved in these projects where suddenly the lawyers tell you that you have to have this ugly all upper case, "I agree to the terms and conditions," button that causes everybody to stop. These guys are looking at the problem and saying, "OK, maybe it doesn't have to be ugly. Maybe it doesn't all have to be uppercase. Maybe we could do this another way that gets to the intention of what the rules are. But at the same time makes for a better experience." Yes lawyers are these people who are on the legal side, who are saying, "Yes! Let's figure out a way to do that."
Sean: Do they re-write the rules? Or, is this more of trying to navigate the current system that's in place?
Jared: A bit of both. We were talking with Jeff Gladchun and Tracy Walker. Jeff Gladchun is from Fidelity and Tracy Walker is from US Digital Service. One of the things they were both telling Karen and me when we were talking to them, preparing for the UX Advantage Conference was that. There's a difference between the law and policy. Often what happens is, the law is very broad. It isn't that specific. Then organizations make a response to that law by creating policy. The policy is what they decide to do going forward. So they're always consistent. They know they can defend it, so that they know they're within the law. What these folks are realizing when they're trying to navigate this, is that maybe some of the policies need to be revisited. More importantly, there are occasions where you can go back to the policy makers and in some cases the law makers, and say, "We want to follow the intent of what you're trying to do, because what you're trying to do makes a lot of sense." In the case of regulation in financial services, we're protecting the investor. That's the right thing to do. In the case of procurement, the Government is trying to spend it's money wisely for the taxpayer. Both of those things, everybody wants. When you say, "Wisely means, always go with the lowest bidder." Suddenly you're no longer protecting the taxpayer, if the lowest bidder can't do the job and you waste all that money and the project gets canceled. Or, when the rules are, the investor isn't really protected because they're agreeing to terms and conditions they don't understand and they're moving forward and making mistakes anyways. The idea is, to come up with rules that do the things that make sense for the share holder. For the investor and taxpayer. Then to create policy around that, that does the right thing. In both cases, they tell us that they're actively looking at new ways to interpret the new policy and new ways to interpret the laws.
Sean: Does the person who's interpreting the policy and law have to be a lawyer in this Yes Lawyer role?
Jared: They work with lawyers. Tracy is not a lawyer. Jeff, it turns out, he's now the director of product at Fidelity, but he was a lawyer. He has his JD Degree. Tracy isn't a lawyer, but she works very closely with the White House Council. She is in fact doing those things and they work collaboratively. She can handle...you have to be very versed in the law and understand where the law works and doesn't. You also do what lawyers do, which is go see council and ask opinions. In both organizations it seems that's very much a team effort. Which is good, because that means more people are thinking about, "How can we creatively move through this process?"
Sean: Do you think the process will result in terms that people will read before they click on, I agree?
Jared: Some of the times it will be terms they click on and sometimes it will be translating things to plain English. Sometimes it will be embedding those things into the interface. To say, instead of making you disclose them up front, to say at the time when you're trying to do something. You have to make sure you file your taxes. Or, we're not responsible for these pieces at that moment. Instead of having this up front disclosure that tells you what they will and won't do. Then two months later you don't remember what's in that thing, even if you read it and chances are you didn't read it.
Sean: It's a really interesting concept. One that is certainly newer. One thing that struck me as you were talking is, where does this fit in to the actual user experience? Is it only in the terms and conditions? Or do we see it elsewhere?
Jared: No, it's all through the interface. All through the experience. There's two parts. The stuff that Jeff is working on, which has to do with compliance and regulations. A lot of that has to do with what are called disclosures, which are the things that financial companies have to do to say, "Look, you're the investor. We're going to place the trade. If you lose money, it's not our fault. You can lose money. By the way, investing in the stock market, you probably will lose money." That's the things they're disclosing. The trick there is, making sure the share holders are protected. They understand there are no safe bets. In the case of procurement, it's not so much things that are built into the interface as much as they are ways that the project happens. If you're going to hire an organization and you want them to do truly agile development, that means they can't predict the end game. They can't tell you what they're going to deliver when they're putting in their proposal, or when they're writing the contract. You have to write a contract that lets you embed the notion of exploration and innovation, where you don't know what the final deliverable is. That's completely new to contract law. We have to re-think the way contracts are written, because we're not asking people to deliver a website that does X. We're asking them to work on this project that will deliver something that's useful. Those are two very different statements. We don't know if the website that does X, is useful. In the case of procurement, the challenge there is, how do we construct an agreement so we can make sure the team we're hiring is the right team for the job. They understand what we're going to ask them to do. They're going to deliver something of value without specifying what that delivery is. That's what Tracy's expertise is in. It's fascinating.
Sean: It really is interesting. There is some interesting parallel to another topic at the UX Advantage conference that you touched on, when you mentioned the deliverable of the product. That topic is incentive and rewards. We know that traditional rewards and incentives are based on getting a product out of the door by a certain date, or producing something within or under budget. A question I have is, should companies be rethinking this reward and incentive process? If so, why?
Jared: It's funny, Karen and I keep approaching the incentive and rewards thing in different angles, and they both are really interesting. Karen's take has a lot to do with how bonuses are allocated and how people are rewarded in organizations. We both see in our clients, a lot of organizations where some senior member of the executive team has this bonus to get this thing deployed this quarter. It's got to go out this quarter. If it doesn't go out this quarter, you're not going to get your bonus. Because user experience often means, slowing things down and really taking and asking the question, "Are we building the right thing?" That counters to, "Hurry up and get this thing built." One of the topics that we're exploring with the different industry leaders we're bringing in, is how those explicit bonuses work against user experience, and what they've done to counter them. The other thing I've noticed, is that there are implicit rewards and bonuses that organizations build into their DNA. An example is, how the budget gets allocated. An organization might have two separate budgets. One is for development, and one is for customer support. The managers are always fighting for more budget. They want more budget so they can get in more resources, so they can do their job more effectively. Is it the case that, if development makes something that reduces support cost? By reducing support cost, they save money in the support budget. But, they have to spend money in the development budget. Will the fact that resources are tight in development make an executive make a decision that they should do something that will increase the development budget? Or save money on the development side versus something that will spend more money without the reward on their side while the support people are getting the reward. Something like a password reset function, which will reduce support calls about resetting your password might cost extra money to build. Who benefits from building that? Is it support or is it development? Part of what we want to explore is, how these rewards and incentives are key to understanding what's going on. There is an old saying, "What gets measured, gets done. What gets rewarded, gets done well." How do you build rewards around great design and great experience? Particularly when you're talking, you have to involve multiple departments. If you're doing something in e-commerce, you very much may have a retail outlet that is rewarded for sales in the store. You've got your online website that's rewarded for sales online. The store doesn't want people to purchase online because it takes the money out of the store. We see this happening all the time. There's one of the top businesses in the United States who has an online presence, but almost always you end up calling their support center to complete the purchase. The reason you call the support center to complete the purchase, is because the website is very complicated. The support center doesn't want you to fix that, because their call reps get commissions based on those purchases. If people were able to purchase online without calling the call center, their commissions would go down and they would lose their best support people. They don't want to fix the experience.
Sean: It sounds like a better experience would be, some of the retailers we see who you go in, you see an item you want. They don't have it in your size. You bring it up and they will go online for you, complete the purchase and have it shipped to your house.
Jared: Yes, absolutely. K-Mart started this campaign a year or so ago, where you can go in the store and purchase anything, and they'll ship it to you. What they refer to as the ship my pants promotion. I shipped my pants. That's the thing that's happening. This basic rethinking of how are those rewards done? If the store is rewarded on sales, and their sales people are sending people to the website. That doesn't benefit the store and the store manager who's competing and getting bonuses based on these things. These are the types of things that we're very interested in. As we've been talking to the various folks like Bill Scott from PayPal and Karen Pascoe from Mastercard. We've been exploring what those rewards and issues are within an organization that they have to work through and say, OK, we need to reward the whole organization for success. Not just each individual group for it's own success, so we stop them from competing against each other in a way that makes a worse user experience."
Sean: It sounds like a really complex problem. If you look at the incentives and rewards, are you able to differentiate if one is more important then the other? If your incentivizing one group but there is an overall reward, how do we measure the value of that incentive related to the individual reward? Or, are there levels of each one that come together to make the whole? Essentially I'm asking, is one more important then the other? The incentive or the reward?
Jared: That's an excellent question. The reward or incentive, I'm not sure symmetrically they're that different. In both cases there is a carrot on a stick, and the question is, are they causing the organization to move in the right direction? A lot of the incentives that organizations have built in, were built years ago. They work against this new economy where customers are choosing to purchase from lots of different places and not necessarily going straight to a single location. When I do banking, I might go into a branch, but I also do a lot of my banking online. Does the branch get rewarded for opening an account, or should the business as a whole get rewarded for opening an account? If someone walks into a branch and finds out everything they need and opens the account at home, does the branch get penalized for that? In the old days when they were counting how many new accounts we opened, that's how branches were rewarded. The ones that opened the most new accounts, got the monthly bonus. Got the reward. Got the plaque in the office. Whatever it was. Got the recognition for being the leader in that division. That has to be re-thought. Where we see this problem mostly happening are in the older businesses. The ones that pre-date online experiences. Pre-date digital experience. The systems are trying to adapt, but they haven't gotten there yet. The conversations we're going to have with folks, is about how they dealt with that. Mastercard is way older then the web. Now that Mastercard is competing against Apple Pay and Square, how does that change the incentives for signing up new merchants? How does that change the incentive for delivering customer service? How does that help the Mastercard card holder get access to their account and be able to use the services so they don't switch to somebody else's credit card?
Sean: That's a fascinating topic as well. The incentives and rewards, along with the invention of the Yes Lawyer, which are only two of the topics at the UX Advantage conference. I want to thank you for your time today, Jared.
Jared: Thank you for your time today, Sean.
Sean: Watch for other podcasts covering more of the conference topics. Be sure to check out the conference speakers and all the topics at UXAdvantage.com. We hope to see you in Baltimore on August 18th and 19th.