Salesforce is one of the biggest companies in the world, and they have all kinds of difficult design and engineering problems to solve. How do they do it? J sat down with Justin Maguire III, SVP of Product Design and User Experience, to find out.

Guest Bio:

I’m an executive level design leader in the area of software, product, and service design concept and delivery to market. With both in-house and agency experience, I specialize in elevating the role of customer centric design practices within organizations and leading globally distributed teams to deliver world class product and service ecosystems to customers.

I’m a passionate believer in the power of great cross disciplinary teams to craft products and services which elevate the human condition and drive market performance. I’m driven to work for companies that share this vision and I look to collaborate with leaders across the various parts of these companies to build now for what’s next. This kind of rare alchemy is difficult to achieve and even more difficult to persist – this challenge creates a sense of urgency and focus that gets me out of bed every day looking for the best partners and most meaningful industries to commit to.

Episode Transcript

J Cornelius: Salesforce is one of the biggest companies in the world, and they have all kinds of difficult design and engineering problems to solve. How do they do it? We'll find out next.

Intro: This is Design Driven, the podcast about using design thinking to build great products, and lasting companies. Whether you're running a start-up or trying something new inside a Fortune 1000, the tools, methods, and insights we talk about will help you create things people love.

And now, your host J Cornelius.

J: Hey, everybody. We are excited to have Justin Maguire with us today. He runs Product Design and User Experience at Salesforce. He's got some pretty interesting stuff to talk about.

Justin, how you feeling today?

Justin Maguire: Doing well. Thanks for having me on board today. It's great to be here.

J: Yeah, I'm glad we could get everything worked out, schedule-wise. So what's going on at Salesforce these days? What are you working on that's exciting you?

Justin: Well, you know, one of our focus areas, actually, and it's very relevant to right now-literally, this is the thing that's the hot topic right now-is how to maintain on ... some of the fun of our brand, all the way through the product, and in a responsible way. We are a tool people use to get the job done, but enterprise software doesn't have to suck, as we like to say.

J: Yeah, exactly.

Justin: And... So we've been thinking about the word "functional", where you imagine the word, F-U-N is bolded in that. So functional.

J: Ah, nice, nice.

Justin: How do we keep ... how do we introduce some fun into a very functional tool? And we think that's both valuable to our end users, but also kind of creates a moment of differentiation and embodies some of our brand values, into the product.

J: Yeah, nice. I like the usage of the ... in functional-

Justin: Yeah.

J: So how is that manifesting itself? What kind of things are you doing to make that happen?

Justin: On ... Some of it's, they're very surface-level things, like how do we take some of the evolution of our brand, the Trailhead characters, you may have seen, sort of the mountains and goats and bears, and some of the cartoonish elements that we've been introducing into our brand vocabulary.

J: Yep.

Justin: How do we appropriately introduce that into the product? But it also gets at things like gamification, like animation, as a feedback mechanism. Whether that's feedback from, sort of a click, or feedback that you've arrived at a milestone or accomplished a task, or maybe hit your sales number for the month or the quarter.

So, many of the kinds of things we talk about in the industry, but in a very pragmatic, practical application of those theories.

J: Oh, so it's kind of adding a little bit of interesting, fun feedback in usage of the application, right?

Justin: That's right.

J: Yeah. So it doesn't feel as much like an enterprise tool, it's more of a ... I'm not sure what that category would be, but the tools that you typically see in more small businesses, where they're actually a little bit easier on the eyes, they're not as clunky, and they feel better to use.

Justin: That's right. And it's a challenge for us, I think, relative to most smaller platforms, that don't offer the level of customization we do. Because, of course, as a platform, you can take and almost completely remove Salesforce, as a sort of visual expression from the product and have it be ... If you're Coke, you can have the whole interface be red.

J: Right.

Justin: With your logo on it and the word "Salesforce" would never show up. So how do we leverage things like patterns of interaction loading, the way in which the page constructs itself, animation... How do we leverage some of those things to both create a sense of joy of use, meaningful way-finding cues and interaction cues, and an expression of our brand that carries through, such that even if you are bright red and Coke, you'd still know that's a Salesforce product you're using.

J: Yeah, that's a really interesting challenge, I would think. Because you've got to think about, not just how do you express the brand and have that in your own UI, but how does that manifest itself across all these other different permutations where it might appear, right?

Justin: That's right.

J: Yeah. So... man, that's a pretty challenging thing. How are you handling that? I mean, do you do, like, on-site testing with people at Coke, or how do you know if you're developing an interface to accomplish a certain task. How do you know that it's going to hold up in those different environments?

Justin: Well, yeah, it's a bunch of stress-testing the system. Right?  First, it starts with having a platform mindset that you just ... You know, which we've had, we try to hire for, but of course, in our more junior people that we're hiring, say, straight out of school, that's something we have to cultivate-

J: Right.

Justin: -and build over time. But, bringing that platform-like mindset to everything we do, we see that as the meaty part of the challenge, right? And it can be sometimes expressed in a little bit of arrogance when we talk to, or talk about other companies, where we say, "Oh, isn't that cute, they just don't have the solve for that." They can just do whatever they want, and not have to care about the fact that...

J: There's 20,000 users somewhere that would hate that thing, right?

Justin: That's right.

J: Yeah.

Justin: You know, one way to think about that, like a nice analogy that we've all used many times when we talk about platform, is LEGO. Right? LEGO can be put together in a billion different possible ways, and yet, you would never look at something built in the LEGO platform and not know it's LEGO.

J: Right.

Justin: Right, and so we like that challenge. Right, that's a ... I think that brings out the best creativity. And it is hard. It is a challenge, right?

J: Yeah, no doubt.

So, you mention people coming straight out of school. You kind of have to re-train them, or shift the way that they approach things. What do you see as one of the major shifts, or what kind of things you having to teach them that they don't get in school?

Justin: The first is that ... is to see those constraints as a joyful thing, right?

J: Right.

Justin: I think, you know, there's been such a... design and user experience has been elevated in the last 10 to 15 years to a place of, you know, real power in the world. And where the things we celebrate in FastCo, Monacle, and Wired, et cetera, et cetera, right? Are these, sort of singular, one-off beautiful little things, right? And we sort of love those consumer products that do one thing really well with a very, very high level of design execution.

J: Mm-hmm.

Justin: And it is kind of a mindset shift to see the opportunity and the challenge that's present when, really, we think of it as co-creating with our customers. Right? And it's, again, not co-creating where we bring them in, in an IDEO design kind of way, figure out the one perfect expression of a product. It's that we are co-creating longitudinally, always, with our customers. They get to make whatever they want with our product.

J: Right. Yeah, 'cause the answer to "Can you do that in SalesForce?" is typically always "Yes." Right? It's just a matter of customization.

Justin: That's right. That's right. Exactly right. And when we go to design something, it is really a... that's a conversation we even have internally. Where something as simple as, "Hey", where we have an action bar, where we express, or we expose on a... the top right of a page, a set of functions, global functions for that page. And we've neatly laid out, a grid format, that there are five buttons in a menu. And, well, could there be two rows of 20 buttons? Would we... is there any reason we would say "No" to that?

And it's a challenge because we're... you want to put enough guardrails in place to make doing the right thing easy. But, we don't always know what the "right thing" is. And, for some customers, two rows of 50 buttons might be the right thing. Even though, for most of the immediate use cases we can think of, that sounds like a terrible idea.

J: Right.

Justin: That actually may be the right thing, right? That's sort of like, think about the difference between the dashboard in a simple sports car, and what you see on the flight deck of an A-380.

J: Yeah. So, it reminds me, I was talking with Aaron Irizarry at Nasdaq, about something kind of similar. They're dealing with people who need to see a very large amount of complex financial data at a glance. So, if they were to approach it from a more aesthetic perspective, that would be a failed design. Because the people couldn't get what they needed in the time that they needed it, in the level of efficiency that they're expecting. So I had... it sounds like you've got a similar problem in that in some instances of the application, you need a much denser interface, because the tasks people are trying to accomplish are different. So it's kind of interesting to think through that.

Justin: Absolutely. It's really a... I think it makes it fun, right? It makes it fun to think about what's possible. And frankly, we love it when we go out to see a customer and see some crazy thing they've built.

We had a customer come in and present to us two days ago who has leveraged the IoT platform to do just some amazing stuff. Stuff we hadn't even thought about hooking up yet. And, really, it's like a dream customer, cause you think, "Wow, you're showing us the way. You're opening up new conversations and new ways of thinking about the product that we've built." And that's exciting.

J: Yeah. Yeah, it must be.

So, that's actually kind of an interesting topic, is, how much is the design decision process, or the build process, if you may, driven by customer feedback? And, how often are you going out and collecting that information, and how are you doing it?

Justin: Well, it's actually hugely driven by customer feedback, and we have a variety of channels. Let's say, in some ways, relative to companies I've been a part of, or that I consulted with when I was at Frog, we are a leader in our capacity to listen across many, many channels. We have all manner of listening devices out there. I'd say the challenge we face, and I think ... I suspect we're not alone in this. I think that anybody who is at the forefront of listening, you then find yourself in a challenge of signal-to-noise ratio.

J: Yeah. Of course.

Justin: And, where you then have to create a series of decision constructs, for how do you weight the feedback you're getting. Right?

J: Mm-hmm.

Justin: Which channel is more important, which trumps which? How do you make decisions based on this data? It's great to have the data, that's obviously the first step. And, that goes even to things like ... We have a thing called "Idea exchange" where we invite customers to log in and post ideas. Sometimes it's with a screenshot, sometimes it's just a description. It's all manner of things we get. And ... a customer posts an idea, and then the community votes on that idea. And, then, when that idea gets a certain... achieves a certain threshold of likes, if you will, we commit at that threshold to actually then go assess, is this something we can, and/or should do? And, respond to the community.

So, I forget what that... to be honest, I forget the number. Let's say it's 20,000. At 20,000 idea exchange points, we will then pick that idea up and do an assessment internally. And then come back to the community and say, "We can't do it for this technical reason," or "We're not going to do it, because, whilst it seems like a good idea, that would actually break our number one value of trust." It might introduce a security risk, or we would come back and say, "We're gonna take this on, in release 212. So expect to see that in the spring of this year." Right?

J: Yeah, so it sounds like it's kind of, like a Reddit style community up-vote for things that you want to see-

Justin: Exactly.

J: -... in the application.

Justin: Exactly right. And you know, they've been doing that for a long time. Which again, I would argue is really co-creating with customers. They're not using the trendy design terminology around that, but that's a great example.

But, of course, the flip side is, it is a self-selected group of people, and-

J: Right.

Justin: ... they bring, you know, as a result, there's a certain measure of bias to that. And so, we shouldn't just take everything you say, what is the quiet person in the corner who's not posting their idea think? What do they want?

J: What is the person that is too busy to get involved in that process?

Justin: That's right. That's right.

J: Yeah.

So, how are you weighting the data you collect through that community versus in-person feedback, and other data points?

Justin: To be honest, it's a very active conversation at the leadership team level. I think on... one of the amazing things about Salesforce, you'll hear people refer to it as the world's largest startup. While it's clearly not a startup anymore, there are behaviors and internal mechanisms that when you first come here, especially if you've been in a bigger company, this can feel very Wild West because there isn't that sort of algorithmic rule, or this person decides, or here's this six step process.

J: Right. Not a real rigid hierarchy.

Justin: That's right. Yeah, no, it's very much an active debate that happens amongst the senior leadership of the product organization. And, it's a very active and healthy debate where we're encouraging people to bring both their passion and their various expertise to the table. As I've said before, trust is our number one value. Right?  When you have companies like American Express trusting us with their data on our cloud servers, you know it can't. If you aren't trusted-

J: Yeah, you can't mess that up-

Justin: Yeah, it's an extinction level event to mess that up.

J: Yeah, exactly.

Justin: So we take that extraordinarily seriously. And so we have long conversations, and often, the biggest thing that pushes out, the ability for us to execute an idea, is whether or not we can actually do it as part of the platform, versus sort of, a one-off point solution.

J: Do you mean like a custom for an individual customer, or company?

Justin: It's more that, if we're gonna build a new component, we want to be able to do it in a way that all of the products in the Salesforce eco-system can take advantage of. As opposed to authoring it, in a way that is used only in the service desk, for instance.

J: Right, right.

Justin: Right?

J: So, you're thinking of it, kind of, plug and play app mentality, for some of those features?

Justin: That's right. Exactly. It literally, needs to be a component that any of our... anybody in our ecosystem can re-use. Cause we actually eat our own dog food. So that components we build for, say, something, like Lightning, that we expose to the outside community, that they can use to build custom apps. Those are the exact same components we are using ourselves.

J: Right.

Justin: So, we are truly eating our own dog food.

J: Yeah, that help keeps you honest, right?

Justin: That's right. That's right. But, it makes it sometimes feel slow, right? Because, I mean, the reality is... as an intern once had a realization, said to a room full of people at the end, he was doing sort of a retrospective of his time as an intern. He said, "You know, like, this is the only place where I can put a combo-box on a page."

And the reality is, that combo box could be hooked up to the data set in such a way that, very easily, by the way, by an admin, such that the end user clicks on the combo box, and it has to go fetch 50,000 rows. And, then, of those 50,000 rows, it also then knows ... has to know, that the user who clicked on it only has the rights to see 25,000 of the things in that 50,000 row data set.

J: Right.

Justin: And it has to do all of that in a way that's performing in under a second.

J: Yeah.

Justin: It's ...

J: It feels responsive, right?

Justin: That's right. It feels responsive, and, you know, that's a level of scale that's fairly unique here, right? It's not that, say, Amazon doesn't have a similar scale problem, but Amazon doesn't let an admin go in and drop 40 of those combo boxes on a page.

J: Right. And have to worry about the performance hit as a result.

Justin: That's right. That's right.

J: Yeah. So, that's kind of an interesting thread too, is, how do the design and the engineering teams collaborate and make decisions on what can and can't be built and how it should be built?

Justin: Pretty closely. One of the shifts we've been making in the time I've been at Salesforce has been to put our designers closer to the scrum teams.

J: Do you mean physically, organizationally, or what?

Justin: Physically, and also from a process standpoint. Getting a level of ownership for the designers in sprint reviews, in the process, right? Moving away from a service mentality to a partnership mentality where there's greater responsibility and accountability for the UX organization. That also means that we've had to invest in, and ensure that our designers have a very strong technical basis, in understanding the platform.

J: Mm-hmm.

Justin: Which takes time, right? There's a great Medium article by one of the design heads over at Twitter, whose name I'm gonna forget right now. Mike, Mike something, about how Jony Ive had basically... the reason he's in charge is cause he's stuck around a long time. That, in an age where people tend to hop jobs every two to three years, or...

J: Yeah, he kind of won the war of attrition, right?

Justin: Well, also, when you want to make the decision, if you want to have the power or authority, or responsibility to own the vision for a product, what you're really asking is for the company to trust your judgment. And, in a way, that hundreds, sometimes thousands of people's livelihood will depend upon. And to arrive at a place where you are that trusted takes time. You know, you have to show a track record of deeply understanding the customer, the user, the business, and the technology.

And so, the UX leadership team at Salesforce over this last couple years, I think, the opportunity was opened to us, to take a bigger seat at the table. But along with that came an expectation that we rapidly upscale on the areas that weren't just, "What is a user need, want, and desire?" Right, but understanding our business, our technology, and our customers, even our go-to-market strategy, right, getting a much broader understanding of all of those things. Even though our wheelhouse is still the experience of the product, if we want to help steer our product strategy, you have to show a propensity and an empathy for those other dimensions of our business.

J: Right. So, it seems like Salesforce has decided to kind of bake a lot of that design process, and the iterative thinking, through these types of problems, and how those teams collaborate into just the operational structure of the entire business.

Justin: That's right. And there's a deep care, right? I think one of the interesting things about Salesforce is that, it's, relative to other companies I've certainly been a part of, our leadership team, our executive leadership team, we don't really have to argue with them to be customer or user-oriented. Right? I think-

J: That's-

Justin: Many people in our community, in the design user experience community have spent their careers having to sort of fight the good fight, on educating our senior-most executives in a company, on the value of being user-centered, right?

J: Right.

Justin: And, that's not the case here. You know, Marc's almost first question any time you've shown him a product thing is, "Have we tested this with users?"

J: Yeah, and that's really powerful, and you can see that that definitely leads to an advantage in a way, that the product gets used in the market, right? I mean, obviously-

Justin: Yeah.

J: ... people have frustrations with any product, and a product that has the scale and the number of users that Salesforce does, and you're gonna have factions of people who feel one way or the other. But, overall, I don't think anybody could argue with the success that Salesforce has had. It sounds like, that partially could be rooted in the fact that you've been listening to users all along.

Justin: It absolutely is. I think the next challenge from the UX perspective here is that, at Salesforce, is that as we reach... As our products reach a certain maturity, the... how do I say this? And this is true of any business, right? When there was no car, right, the fact that the first car had 38 levers, required five hands to operate, and four of the levers were behind you, didn't matter. Right-

J: Right.

Justin: You get a new "what". Like, what it did, it offered a new "what" to the universe. When there were 30 cars, 30 different car companies, then, and they all did the same "what", then the differentiation turned to "how." Right? How it did those things. And I think it's a mistake to think of design is only being the "how." We have to be concerned with both the "what" and the "how," and having a healthy balance, right?

J: Yep, yep. Exactly.

Justin: Very few companies in the world have effectively monetized the "how." You know, Apple's a canonical example.  But you know, you could argue, luxury brands generally, differentiate on the "how." But most new sales, most of what companies are trying to push and sell, is a "what." Is that it a does a thing that nobody else does. And you got... we are at a point now whereas our product's ecosystem starts to mature, we reach a level of functionality where, you know, there aren't massive new "whats," let's say.

J: Right. Yeah, so, it really comes down to the experience, of getting the task done, and how easy, and how delightful that is.

Justin: That's right. And a business challenge then is how to monetize that, how to explain to someone what they should pay us extra money, or more money, because we made something nicer and easier to use. And Apple themselves struggle with this, by the way. It's very interesting.

If you watch their product releases, you know, a few releases ago, they did a product release where they largely didn't, sort of, announce a brand new, shiny physical product. They did a very... they did a heavy software release. And, the response from the market was shockingly lukewarm. And if you look, like, what they actually delivered was a ton of stuff. A ton of refinements, big and small, that made just using their software ecosystem better. But it was all, sort of, making something better. It wasn't, here's a bright, shiny, brand new "what". And-

J: Yeah, and it was a bunch of intangibles, right?

Justin: Right. And the market really did not like that, which was very interesting, because the users of the product, of course, loved it. But it doesn't necessarily open up new markets. It doesn't attract, necessarily, new customers. It makes the customers you have happier.

J: Yeah. It's also an interesting point, is, the people who used the new software, once they used it, they saw the value. But communicating that value ahead of time is inordinately difficult.

Justin: That's right.

J: Especially if you're communicating it to someone who didn't have the usage of the app to compare it with to begin with, right?

Justin: That's right, and takes it back to your beginning question, where we talked about being functional. One of the core things of fun, is, we have a product or, part of our end-to-end experience of the customer journey, user journey, is a thing called Trailhead, which is essentially a learning platform. It's where you can go and learn about, and take small courses, things that five minutes, up to things that take, you know, several days, that teach you all manner of things about the product ecosystem.

And one of the things we're looking at, is, how do we integrate micro-moments of learning and introduction. This is quite common in mobile applications and more mature consumer web apps. Where, when they roll out an update, the next time you log into that piece of software, or open that piece of software, it says, you know, "Hey J, since the last time you were here, awesome sauce has shown up here, here, and here," and sort of points out two or three sort of neat, cool things that it just sort of magically shown up overnight for you. Right?

J: Yup.

Justin: And-

J: And does it in context, right?

Justin: That's right. Exactly. And so, we're very much starting to do that, because we've realized that the power of our platform, or the complexity, depending on, how, you know, glass is half full, glass half-empty. It's... there's so much there, that the customer journey is something we have to think about starting to choreograph. That, as a user comes in on the first day, first ten minutes, first ten hours, first ten days, first ten weeks, first ten months, right? How do we start to progressively reveal and introduce stuff along that journey? And, of course, when we do our three times a year update, how do we let you know that something new and awesome has shown up over in this corner?

J: Without moving somebody's cheese at the same time.

Justin: Exactly right. Exactly. And that's... you know, we think that's important because, of course, if we've invested time, like, as I've said to executives, the ROI of a feature that's unused is zero.

J: Yeah, exactly. Doesn't matter how much effort you've put into something if nobody's gonna use it, or they don't like using it, then you've just wasted it.

Justin: That's right. And, a really funny thing, for users, If you ever want to, for listeners of the podcast, I, as a joke, made a slide that followed that. I had a slide that said, "zero", big zero in pen. And, my voice over was, "The ROI of an unused feature is zero." The next slide was 61%. 61% of that new features are undiscovered by users. I totally made that number up. I literally made it up. I just made it up. But I put this up, and put in front of our executives. And what was funny, is, that the room kind of went, "Yeah, seems about right."

J: Yeah, nobody questions it.

Justin: Nobody questioned it. And I said, "Okay, so I totally made that number up. But the fact that none of you really questioned that should scare the crap out of all of you." Right?

J: Right.

Justin: You know, we have a whole... what's our annual budget for the R&D organization? We're all delivering stuff, and 61% of what we deliver is just not ever figured out or used? That's kind of a problem.

J: Right, and you were just okay with it?

Justin: Yeah. I think, you know, and they're not really okay with it. I don't want to... you know. But, they're ... I mean, the point was to spark the conversation. A very healthy-

J: Right.

Justin: ... debate followed that. And, yeah. I think that led, amongst other things, to a desire to invest in a framework that allows us to do that kind of harbor tour of new things in the product, and, you know, that's important, right? That part of the customer experience and customer journey is often unattended to.

J: Right.

Justin: And again, for us, because it's not a one-off, we have to think about, "Well how do we author that sort of tour of the product as a framework that not only can we use across all of the products in our ecosystem, but if a developer can build a custom app on our platform, that they can use it as well."

J: Mm-hmm. Yeah. So, if they're rolling something out to their internal work force, they can add little tidbits of information here and there. Guidance, to help people through whatever those features or functionalities might be.

Justin: That's right.

J:  And then you have to design something to help those people understand how to create those little tidbits of information.

Justin: Exactly. Now you got it.

J: Yeah. So, you kind of have this design system inception thing going on.

Justin: Exactly. Exactly.

J: Yeah, so it's interesting that some of the challenges that you're explaining here are kind of a level above what we typically talk about when we think of systems design, or design thinking, or any of the buzzwords that are floating around now. It goes back to what you said at the very beginning. It's more platform thinking than it is application or functionality or feature driven thinking.

Justin: That's right.

J: Yeah, cause you're having to think about things in a much broader context.

Justin: And you could argue that it's really the long pole of design systems, right? I... you know, I think design systems have, for all manner of good reasons, have become de rigueur in the last, I don't know, five to seven years. I mean, we were doing them for customers at Frog eight years ago.

J: Right.

Justin: So, the concept's been around for a while. It matured more as development libraries than redlines and brand guidelines. And as such, are also that much more effective. But I also think that, part of what's made the Lightning Design System so effective at Salesforce is the fact that our executive team on both the products, marketing, the product platform, and our engineering side, all three, have really aligned and gotten behind that, right?

It's not something the design team delivered, and we kind of hope our own internal audience will use, or we have to go persuade. The engineering team has been totally brought in, and frankly, that's required us to up-level, and bring in different level of rigor to our own process. Where we have to match the level of rigor of our engineering teams in our own delivery model. Because they're now ... we've created a dependency, our own internal development teams are dependent on this. And so-

J: Right.

Justin: You know, it's a double-edged sword. But, it's, you know, I think for folks who are looking to do this internally, if you don't insure really upfront, that you have your development leadership way on board, as partners of this, from the earliest, it's ... you could find yourself hitting massive roadblocks later, and even worse. You could find that you've finished building it, it just doesn't really get used. That the story you've told yourself about it and how it's actually functioning in practice are not aligned.

J: Yeah, I see that happen more frequently than I would like in a lot of the client companies we work with. If they start out with a vision and they work towards that vision, and then somewhere along the way things get derailed. And finding out where that derailment happened is usually quite a struggle, and sometimes can get political. I don't know if that's been an issue within Salesforce, but if it has, can you talk to, maybe some of the ways that, maybe you've looked for certain red flags, or even monitor processes, or look at certain metrics to kind of ensure that things don't get derailed?

Justin: Sure. I mean, I'd say a couple of things. You know, this started in a very startuppy, boot-strappy way. You know, the first version of the Lightning Design System and its delivery into Lightning was a very small team. It was like 15 people and, like, four months. You know, it was extremely fast. And Sunka, who runs the U.S. engineering part of my organization, you know, when I sat down with him, after Dreamforce a year and a half ago, I said, "Okay, you are the proverbial dog that's just caught the bus."

J: Yeah, now what are you gonna do?

Justin: Right, like, "You got... it's amazing what you guys accomplished and what you got done with a very small team of very dedicated people, but you know, you did a dead sprint for four months. Now you've birthed the child that you have to feed and water and grow and educate for the next forever. And so we need to pause and back up and think about what are the process steps we need to put in place? How do we set the organization, your team, and the organization of Salesforce up such that this scales and is sustainable for you and the team over the long haul?"

And that's been kind of a journey over the last year. And you know, we're actually just about to roll out a new tool that we've built. It's a Chrome-plug. It's a Chrome extension that enables our own developers to run and audit just how correct they are. Like, have they hard-coded anything, are tags all in the right place? It's basically, gives them-

J: Interesting.

Justin: -a de-bugger, if you will. Against how well they're using the Salesforce Lightning Design System. And this will enable us over the course of this year to implement a policy that says you're actually not allowed to check in. If you fail this, you're not allowed to check in. And what's great about that level of buy-in from our engineering partners is that it takes user experience out of the wheelhouse of being a bad cop or even having to log bugs. Right?

J: Yeah, that's interesting. So it's kind of like a continuous integration tool. Right? If things don't pass, then they don't get to move to the next step in the process.

Justin: That's right. And it really makes compliance with the guidelines... something that's sort of automated, and just expected of every developer. And UX teams today that have to spend a lot of time going through and using the product and logging bugs, and are sort of... a) it's a waste of their time and b) it's seen as, you know, we end up being sort of bad cops. It saves us the time, and we are no longer the bad cops. It's just the way we breathe air here. It's how it operates and-

J: Yeah, interesting. That's... I'm kind of remembering... the shadows coming back to me from the late nineties when I was making web-authoring tools, .html editors, and that kind of thing. We actually put a test in that would run your markup through the w3c validator before it would save and let you know what any errors you had, so on and so forth. And we thought it was a brilliant idea at the time, and it certainly seemed to help the web standards movement and all of that. But we got it into beta, and people absolutely hated it because of all the hacks you had to do to make things actually appear the way they wanted to appear, because browsers were so crappy, right?

Justin: That's right.

J: So, it's kind of interesting. I'm thinking back to that now and thinking could something like that actually work in today's day and age? I'm still not sure that it's possible. But it's interesting from a theoretical point that the design system. It sounds like the design systems and the thinking around the way you solve problems at Salesforce have matured to the point where you can now use a tool like that. And it's actually effective and it's helping not just the people do their jobs day to day, but it sounds like it's actually helping the quality of the product that's being delivered to the user.

Justin: It does. And at the end of the day it also allows us to focus on what matters, right? You know, I think that if we've gone through the trouble of building a design system that's a code repository, a mark-up repository, you know, why would we... like, there should just never be... we should never have to chase down something that isn't correct anymore. Right? It's-

J: Right.

Justin: So, that allows us to spend our time on the harder problems. Which are, as I like to say, low-friction, high-frequency problems. High-friction, low-frequency, we're pretty good. Like if you're a reasonably user experience professional, especially a seasoned one who kind of knows how to look around bends and avoid blind alleys and you know... the sort of course problems that usability problems. We just don't make those mistakes anymore.

J: Right.

Justin: But the things that are sort of... really subtly produce friction but when I have to do that thing six times an hour times eight hours a day times 50... you know, whatever, 365 days a year-

J: Yeah, death by paper cut, right?

Justin: That's right. Like those are really hard because there's not a lot of friction and it's really hard to tease out those problems before you go live. And so... but... they ultimately, as you said, as a death of a thousand paper cuts. And so how do we... that's the kind of place that, you know, I'm trying to shift the mindset of the product organization. That when they think about UX and what the role of the UX team should be in quality, it shouldn't be, "Wow, that color value is wrong” or, “That's four pixels off from the right." That's a waste of our time. We've deeply documented it and it enabled the entire organization with a markup library to send the tools to assess the correctness of your markup relative to that library. So let's not waste our time there, let's think about QA as it relates to uncovering and not... How do we not put out in the world those paper cuts?

J: Right.

Justin: And then, of course, there's a different end, which is UX's value to strategic planning and product vision, which is further upstream. But-

J: Mm-hmm. Mm-hmm. Yeah, it sounds like something I tell my team, which is, let's let computers do the things that computers are good at and let's solve our human brain power for the stuff that computers aren't good at, like solving... What is the right decision for when to roll something out, which group to roll it out to, or how to roll it out? All of those things that are much more qualitative than quantitative.

Justin: That's right. Exactly right.

J: Yeah. Super interesting.

So I want to be respectful of your time. I know that you've got lots of crazy stuff happening over there are Salesforce, so I think we could wrap it up here. But I'd love to get you back on the show at some point in the future and continue talking about this stuff. So, before we wrap up, any parting thoughts? Anything you'd like to say?

Justin: I just think there's no better time in history than right now to be a UX professional.

J: Yeah.

Justin: You know, I hope that your users see that. Your users-your listeners, I should say-see that opportunity and bring some joy to your work every day. You know, I think we're at this cross-over moment where the level of responsibility being handed to us is greater than ever and it can feel daunting, and... Sort of what we thought we were going to school to learn and what we do in our practice day to day are... tend to be quite different. But that's an exciting thing, and this is a... what we do is of huge strategic value to companies and everyone knows that. I think the opportunity is in front of us to deliver upon that.

To grab the reins, show that we are accountable and responsible at a next level, and help our companies ultimately deliver products that are of higher quality and more tuned to our users’ needs, wants, and desires.

J: Yeah and if you do that then that's going to make it much easier for that product or company to succeed and actually retain the people who use the product or service in the first place.

Justin: That's right. That's right.

J: Yeah. Cool. Cool. Yeah, good insight.

So, Justin, if somebody wants to get in touch with you, what's the best way to do it? They want to learn more about what's happening at Salesforce, or maybe they want to join your team?

Justin: Feel free to reach out. My email is Justin.Maguire@Salesforce.com. As we talked about earlier on the show, I'm not a big Twitter kid, I think Twitter's where hate goes to die on the internet, so I don't love Twitter.

J: Yeah. Exactly.

Justin: But email's a good tool. Feel free to reach out. And for those of you who are interested, it’s… go contribute to the Lightning Design System. It is an open source system, so Lightning Design, something you can Google, look up, check it out, love your feedback, love your input.

J: Great. Well, thanks again for being on the show, really appreciate it. Great insights, and look forward to having you back on again.

Justin: Thanks for having me here, J.

Outro: That's it for today. Thanks for listening to Design Driven. We're glad you enjoy the show. Have comments, questions, or an idea that you'd like us to cover? Point your browser to DesignDriven.biz, and click Contact Us on the top of your screen. We'd love to hear from you. Tell your friends and colleagues about the Design Driven pod. Post on Facebook, Twitter, LinkedIn, or send them an email and tell them to go to DesignDriven.biz, or wherever they find their podcasts. Until next time, remember what Thomas Watson, founder of IBM said, "Good design is good business."