Scroll down to view the full transcript.
For years, User Experience design for enterprise software was at the bottom of the priority pile. Luckily, trends are beginning to shift as Adam Doti, VP/Principal Design Architect for Salesforce, can attest.
He recently joined Propel CMO Dario Ambrosini as a guest on our podcast The Platform Rules: Digital Transformation for Product Companies to chat about trends we can expect for successful enterprise UX design.
Click here to listen to the full episode, or hit play above.
With his 30 year career in UX design and 10 years with Salesforce, Doti is positioned at the forefront of his field. He told us the best practices in UX design right now, and where trends are headed.
Successful UX approaches we’re seeing now
1. Design Ops Implementation
“Rewind about 10 years, operational stuff was put on the individual designer to manage themselves and their own workload, leaving no space left for the craft. Really the goal [of Design Ops] is to organize the people process… to take that off the plate of the designer so they can do what they do best.”
2. Low-code/No-code Design
“There’s been a demand from the market that more people want to roll their sleeves up and design their own solutions, their own websites, or their own app. But with low-code/no-code, there's a lot of complexity underneath the hood.
“The moment there is a human involved, mistakes can be made – at Salesforce, that’s why we have a milestone we call “consequence scanning.” It's where you pause for a minute and think about all the ways where maybe this could go sideways or maybe it could cause harm when we intended it to cause good. Let's just think this through for a second versus just rushing to ship.”
3. Designing for the casual user
“Design for the person that uses it once every four months and their familiarity with it is not all that great. If you try to optimize for the person that's using the platform every day, you're going to cut corners, because you're going to be thinking, ‘oh, they already know about this.’”
What’s in store?
4. Chief Design Officers/Design Leadership
“Having an advocate at the level of the Chief Technical Officer or Chief Product Officer to ensure that the best in great design is being done at the company has been very effective in market trends. “
5. Thick vs thin design
“Thin design is when you're completing a transaction in the flow of something like iMessage – through literally messaging on your phone, versus firing up the website and logging in and trying to navigate. You're going to see a lot of enterprise software companies try to move into this thin realm and try to downplay these behemoth enterprise apps and behemoth CRM.”
Read the full transcript of the conversation below.
AMBROSINI: My guest today is Adam Doti, Vice President, and Principal Design Architect at Salesforce. Adam, thanks for joining us.
DOTI: Hi Dario. Thanks for having me.
So, Adam, you've been in enterprise software design for just under 30 years. The last 10 years have been with Salesforce, so you've seen a huge evolution in the design of software over this period. But let's start with the tail end of that. What are the big trends that you're working on today? What are the big things that are top of mind for you?
I've seen lots of trends. It's almost hard to keep track, but I do think that a couple of the top-of-mind things and themes that I'm seeing are first, one is design ops, and if you haven't heard of that before, it's similar to DevOps. It's been a pretty popular concept for a while now.
And design ops is a really popular one. I'm starting to see its goal, it's in service to organizing people processes and ensuring that craft is all orchestrated in service to designing great experiences. It's been a result of growing design teams and their further integration into their partner teams, like engineering organizations and product management organizations, which is great, which is something I'm sure we can get into a little bit later. But design ops is a very topical thing these days.
The second thing that I'm starting to see—I've seen a trend, a building trend over the past… most of the time I've been at Salesforce—is the notion of low-code or no-code and developer experience. It might seem like they go against each other where we're designing interfaces where you don't need a whole lot of code to create great experiences, like Wix and Squarespace, and folks like that have been doing it for a while. Drag and drop, and build a website.
But there is still code behind the scenes that needs to be created in order just to create those great experiences. But designing these low-code/no-code experiences or these platform design experiences is a trend that I'm also seeing come up a lot across a lot of platforms, especially in my space, in the enterprise design platform space.
Lastly, there's one more. Everything around, the topics of inclusive design, ethical design, and sustainable design. You'll hear a lot about conversation design wrapping your arms around a lot of these softer, less tangible, almost sticky, and sometimes tough-to-navigate spaces as they relate to what we design and more asking the question of should the thing even be designed and created in the first place, right?
And so, again, we can get into that a little bit later too. We refer to that whole package, if you will, or that whole bucket of topics as relationship design. And it's an exciting space that we're playing in right now.
All right. So three very different trends. I don't know if we can tackle them on the aggregate or individually, but when you talk about design ops, it sounds like this is more about getting the designers fully integrated with the rest of the team and fully immersed. Am I reading that right? Is that what's driving that?
I mean rewind about 10 years when designing apps weren't a thing. Your average user experience designer was somewhat on their own to not only set themselves up for such success with the right training, finding the right tools like Adobe Photoshop or Sketch, getting a license for them, getting scheduling design readouts with the product managers. Operational stuff was put on the individual designer to manage themselves and their workload.
Let alone the actual design that needs to be done right. That in itself is a crushing amount of work that needed to be done, right? And there was just no space left for the craft, for the user experience designer to do what they do best, which is to design the project experiences.
So design ops came in, and has been quickly growing to literally take that off the plate of the designer so they can do what they do best. And to connect in larger organizations like Salesforce and other companies like Microsoft and Oracle, they then are peers with DevOps, right? And work on product release cadence and cycles much more effectively and partner much more effectively.
Okay. So when you bring the DevOps/design ops together, what's the ultimate impact on the org here? What's the change that it’s driving?
Much healthier designers and much happier engineers and PMs. Deadlines aren't getting missed. At the end of the day, my observation has been an effective design team really ensures that the designer on the team can show up in their best way with all their talents, right? And not having to juggle four jobs, right?
They're able to focus on their craft while there is another team handling the operational aspects, making sure that design—in service to creating a product—is well connected to engineering and product management. So it's just a happier design team, happier everybody to be honest.
Okay. It just sounds more efficient, happier, an all-around win-win.
It's an employee experience success KPI.
So, let's move on to the second one that you mentioned. The low-code/no-code and developer experience. You already brought it up that it feels like a little bit of a contradiction. But what's driving that trend there?
A couple things. From the perspective that I see it for the low-code/no-code experiences that are being designed and available out there today, it's being done so that you can get more of these platforms and technology into the hands of non-designers so that they can then create and design effectively, design their own solutions.
So again, back to my analogy of Squarespace and Wix and WordPress and things like that—the citizen developer, the citizen designer, or the citizen person that wants to put together their own blog or put together their own apps.
They can do that now with these drag-and-drop tools, right? You can spin up a blank canvas if you will, and you can drag a widget from the left to the right. When it lands on the canvas, it goes “What image do you want to put here? And then what is the title? And then what is the body,” right?
So you can start building your website with these widgets visually, really not seeing any code, right? It’s been a demand from the market that more people want to roll their sleeves up and design and build their own solutions, their own websites, or their own apps if you will.
Also, on complicated platforms such as Salesforce or others, more designers are wanting to play a hands-on role in creating these experiences. And the reason why I'm really zeroing in on anything that's low-code/no-code is it ends up being one of the places that designers on platforms show up the most.
And it's where design is being done the most, whether it's a designer or a developer, an admin knows it or not, right? That act of assembling a page, that act of thinking what's on the page. Am I putting the right things on the page? Are they in the right order? And then even if I put this dropbox on the page and in that Dropbox, I'm going to give a couple default options to the end user—are those the right options in there?
We start to get a little bit into the ethical questions in a second because what I mean by that is when you ask someone to select their sexual preference, the options that you give them is a very intentional decision that you're making as a designer, as a maker, let's say.
This is all rampant within design decisions that are being made. No matter who you identify as. It's not just designers, but this act of assembling a page and thinking through the unintended consequences of your decisions. This is all designed but it's all culminating on this canvas of this low-code/no-code experience as you build up these apps.
So how do you go about deciding what then goes on the page—and there are two things: One, you talked about the ethical side. Are you left to your own devices as a designer to go figure it out? Or is there a support group that helps or at least provides guidelines? And then the user experience itself. Just what design elements visually and from a usability standpoint, how do you bring it all together?
That's a great question. I got lots of answers to that. One of them is that, first of all, you should not be going at this with your hands in the air and like, “I'm just going to go in and just start making stuff up.” There needs to be a plan, right?
So the PM, the product manager, has a vision and there's a requirement, specification, and usually, research has led to that point. And in this case, if we're talking about the moment we're going to start touching pixels and building an experience, let's just assume for a moment that all the proper research has been done. You know your audience, you know your market, let's just assume that part's been done.
So you know what needs to go on the page because you probably have requirements—you know your audience, you know what kind of tasks they need to perform on that page. And so you're building and designing that page in service to getting those tasks done.
These decisions and these moments that got you here should have already gone through a series of steps, checks and balances if you will. Design reviews, review sketches, review wireframes and mockups. But again, it's not a solo job, right? Everybody should have a stake in this decision and every milestone sign-off: engineering, product management, research, design team to get to this point.
Inevitably though, there is a moment where yes, you are by yourself at a moment deciding what's in these interactions. So the dropdown I referenced, right? There is a human in there that's typing in the values if you will.
And there's no perfect... Yes, we can give guidelines, we can give templates, we can give recipes, but the moment that there is a human involved, mistakes can be made.
And it's all good. Part of what we do at Salesforce is that we have checks and balances along the way with design reviews. We have a very nice milestone that we call “Consequence Scanning.” And again, I can reference—all of this in our blog and our website—at the end we can talk about that, but it's a quick little workshop where you pause for a moment and go, “Okay, here’s where we are based on the requirements. You've designed this page. Let's take a pause for a minute and think about all the ways where maybe this could go sideways or maybe it could cause harm when we intended it to cause good. Are we asking all the right questions? Let's just think about, let's just think this through for a second, right?” Versus just rushing to ship.
That's where a lot of people get tripped up. They rush to ship and they just don't literally just pause for a minute and drink some tea and think about the unintended consequences of this thing for a minute.
So it sounds like the designer role is becoming more complicated. It's becoming more, moving parts, more connection to the rest of the org. I mean, is this a good thing or a bad thing in your eyes? It sounds like a little bit of a double-edged sword here.
I can see why people might think it's a bad thing. They might feel like it's overwhelming or it's too much for a human to understand. But I would share that this is where designers thrive.
I don't know how to describe it. They're great dot connectors. They're great at balancing the human needs and the human desire for the thing, and then also the technical, the pixel-perfect aspects of the thing, right?
And so this is actually a place where they thrive. So actually leaning in and investing and ensuring that you have a designer on your team… A lot of this stuff might still be happening in your world and on your teams, but you might not have designers, right? There are people doing design but you may not have designers, right?
It's all good. We want to make everybody better designers and better humans that can juggle these problems. But sometimes there is a moment where in the team's maturity and growth, a few people can't do all the right things, you have to manage that growth.
And when you have an opportunity to hire a new person, think about the balance of the team. Look at the engineering-designer ratio. Are you within a range of good, right? Or do you have a lot of engineers to one designer? Just be thinking about these things as you grow.
But this is a place where the design thinker and the designer does thrive and they're actually happy, even though it comes across as being a lot to handle.
I'm glad that they are happy when it all comes together. You mentioned some of the low-code/no-code platforms. As a marketer, obviously, or maybe not obviously, but for those of you who don't know, marketers use a lot of no-code/low-code software.
And I can certainly tell the difference in my productivity when I'm using something that's been designed, right? It's been designed for our needs. I never really thought of the dropdown menu, but as you're saying it, it does resonate with me when I'm using that and I see things that really speak to me. Why do some companies get it right? And some companies get it wrong? What's the difference between the two?
Yep, that's a good question. These low-code/no-code and just enterprise software and design, one of the trends that I'm seeing—if I could have squeaked in a quick squeaked in a fourth—it might be something around how there's a lot of complexity underneath the hood. A lot of it.
And it's a really hard design challenge to keep that complexity of what's being done underneath the hood on the platform, whether it be a complicated workflow—like you said, marketer, so you probably do a lot of journeys and “if this, then that” and segment whatever, right? Building out journeys and hit and go.
What we want to do is try to strike a balance of making that the most amazing, frictionless experience that you're using as a marketer, while staying true to the complexities underneath the hood.
I have been an admin platform designer for 15 of my enterprise design roles and that's been the most challenging design for me in my career is really designing to that. And that’s probably why it's been my favorite challenge too because it's been the most challenging and the most rewarding when it pays off.
When companies don't recognize that we need to make sure that we're designing, really thinking about the human that's going to use this, that might not have had significant training. I like to design for that person that's going to pull the chair up after not using this thing for four months, right?
You need to be thinking about designing for those experiences and making those frictionless. Because even if you use it every day—if you design for the person that uses it once every four months with a familiarity with it that’s not all that great, you optimize for that. Anybody that uses it every day is just going to benefit from that.
But if you try to optimize for the person that's using the platform every day, you're going to, you're going to cut corners. Because you're going to be thinking, “Oh, they already know about this. I can cut corners.” Or “They know this by muscle memory and that click flow; we can cut corners. The onboarding doesn't need to be all that good. The user inexperience guidance doesn't need to be that good.”
But if you optimize for the other end of the spectrum, you're just going to benefit everybody.
Very fascinating. I never really thought about that—how you have somebody who is just a lightweight loser versus a much more ingrained user. You want that different experience, but it certainly does make sense on the provider side. Again, I know as a user the better the usability, the happier I am. But let's face it, there are some solutions I use the usability is awful, but I still use it because either it's a capability that I can't replace or my other options are all just as bad.
How much of an advantage is this to the actual provider? Do you think enterprise platforms are going to sell more if there is a strong user experience for the end user? Or is it just because it's the right thing to do for those poor end users who, you want to make their life easier?
I'm grinning right now because this might have been the… since 2001, this is the “dollar bill question.” I stuck it up on my wall and I look at it every single morning. It's the million-dollar question, right?
Basically what you're asking is like, “Hey listen, this is enterprise software for an employee that frankly has to use it.” They got no choice. They got a job at a company and this is what we use, right? It's not like an app that you're downloading on your phone, a consumer app, and you're like, well,” that was fun, I don't need it anymore, and you delete it from your phone, right? You have to use enterprise software; it’s part of your work.
The age-old debate and big question has been why should we invest in design? If it's going to be a thing that my boss is going to tell me I have to use anyway, eight hours a day all day for five days a week. Why, what's the point? That definitely was the tone, for better or for worse, for a long time.
But definitely, lately—the past 10 years if not shorter—there has been a pivot to focus on it. And it goes back… well, first two things.
One is a lot of people ask about how we measure the value of investing in enterprise design? What are the right things to pay attention to? In consumer apps, it's engagement. And I've seen people at times try to tie engagements and enterprise app usage, and I don't think that's the thing. Sure, you can look at engagement, but they have to use it, so it doesn't really make a whole lot of sense. They have to go in there and log their cases. They have to log their sales calls, they have to do whatever they do.
What you need to be looking at is user satisfaction and time on task. I mean, frankly, the thing that I've often jokingly said when I first started at Salesforce, was my job here is to design this thing so well that you spend the minimum amount of time in it.
Which seems weirdly backwards, right? Why would you want that? That's the opposite of Facebook's and Twitter's tactic, right? They want to design for engagement and people staying.
Actually, I want to design for people to get in and get back out, get back out in the field and go hang out with their customers. Come into our product, log that call, and they can get back out as fast as possible.
While you're in there, in that time on task, we want it as short as possible. We want to remove all the friction. Do the things you need to do, log it, hit go. And then get back out. That's not true for every enterprise app out there.
It's not true for a lot of them. I've seen a lot of them and they tend to be just tools and tabs. You keep two to six of them open at any given time and you're jumping around, logging your time, planning your trip, submitting your expenses, booking the next thing, logging your calls, right?
And you want to get in and get out as quickly as possible.
I'm sure I'm going to mangle it, but it reminds me of a Mark Twain quote where it's something along the lines of,” if I had more time, I would've written a shorter letter.” So, it takes time to make it simpler. I see where you're coming from.
An amazing amount of time to make it simpler. Because if you just got a request, an RFP, a functional request doc, I could just design that thing verbatim. And it would not take very long at all, but it would not scale. It would not be accessible, it would not be translatable, it would not be localizable—all the things. Because I'm literally just going to hard code the whole thing to meet the spec, verbatim.
But my job as a platform designer is to maybe start there and then I start looking for areas to decouple, the actual way the thing needs to function with, then looking at how might this be scaled to 10 different directions, right?
How might it show up on device form factor size, how might it show up after being translated into right to left, left to right, upside down, whatever, night mode to light mode. All that.
That’s fascinating. So we don't have a whole lot of time left, but I want to switch gears a little bit. You mentioned earlier how on the consumer side it's all about engagement and driving more time on app, whereas you're trying to do less. So I want to go a little bit out of your area of expertise, hoping to get you a little bit out of your comfort zone if we can as well.
Sure.
When I think of consumer products, they're increasingly becoming connected devices. What used to be a design team was entirely hardware now has to incorporate software—software design, very different than hardware design. And this is the bread and butter of who we deal with. We see personally, or I see personally, more and more companies that talk about having to scale that software team now that their devices have become smart, and the difficulty of converging the hardware and software design.
So do you have any background or do you have any thoughts on how this is going to happen or how it's happening today in terms of just this convergence of design on the hardware and software side?
Obviously, I don't work in hardware design. Our software has shown up on hardware devices, and I have a fair amount of experience with industrial design and creating things over my career. So I understand the constraints. One thing is definitely the rise of both has been one of the reasons that has really pushed for… I'm going to start with design leadership and then go into experience.
What I mean by design leadership is the role of the chief design officer, the rise of the chief design officer. Something that's been in the press a lot, especially over the past three, four, or five years, is having a person advocate for great design, period. Doesn't matter if it's hardware, doesn't matter if it's software, doesn't matter if it's a service, doesn't matter if it's service design. Doesn't matter what it is, right?
Having this advocate at the level of the chief technical officer, or a chief product officer to ensure that design is the best and great design is being done at the company has been very critical and very valuable. It's not the right word, but it's been valuable for our company for sure.
But I've seen it be very effective in the market. The trends and what I've seen and the things that come to mind at the intersection of the two—Three things: frictionless communication, design, and thick and thin. I can unpack all three of those.
What I mean by frictionless is that when you're looking at a hardware device, like an Amazon Alexa or a microwave or a stove or your phone and this and that—it's a lot of the connected devices ensuring that the message, the voice and tone, the thing that's being communicated that shows up in the UI—and whether the UI is just a little LED screen or whether it's a full resolution screen doesn't really matter. But the goal that thing was doing as it moves around these different devices—if they are all really connected and talking to each other—is consistency.
Inconsistency is the number one thing that throws people off. It's weird. it's one of the first things that us as humans pick up on, right? If something, especially a non-human thing, is not consistent in the way it talks back to us.
The other thing that we're working around, where our head is in a lot these days, is the notion of thick and thin design. Thin design is like when you're completing a transaction in the flow of an iMessage if you will. You might have booked a ticket or updated your seat through literally messaging through your phone. Versus firing up the website and logging in and trying to navigate to where your ticket is. And then changing all that, the heavy lift of designing for thick experiences in big CRMs is now being pushed to a feed or “thin” experience.
So that's a lot. A lot is going to be happening in that space. This shows up in consumer use cases as well. How you talk to your Amazon Alexa or even your TV or to the remote. It’s a form of a thin experience, even though it's all vocal. But it's not a heavy, thick “fire up the web app and get something done” experience.
I never thought of it that way and when I was thinking connected devices, I was going even further down devices that I've had forever that are now connected. I'm interacting with the hardware less and less and the software even more. And there are some devices… something as similar or as simple as a smart plug. The whole reason for getting a connected one is I don't ever want to touch it. I don't even want to get off my couch to turn it on and off. So the software, it's vital.
I have a very healthy skepticism of a lot of those right now because they're just… they're very buggy.
Like I said, actually, ironically—I said, I'm going to do an experiment. I'm going to buy 12 of these smart plugs, smart switches, install them in the house. I spend more time futzing around with them on my phone because they keep going on and offline and no one knows what's going on and they keep talking to each other and not talking to each other… it's a hot mess. And ironically, I'm messing around with them 15 times more than I ever have been. It's pretty funny.
But I'm just a designer at heart. I'm super curious and my role in this whole experiment is to participate by playing around with them in hopes that eventually I will be giving feedback along with a million other people and make this whole connected experience better.
I think that fast improvement loop, it's certainly out there. I see the difference here over a year with a lot of these products. So I think that your wish is coming true, or at least it's on the path.
So, I want to wrap up with a final question just coming full circle back to where we started. You gave us three trends of where we are today. What do you think lies in the future here of enterprise software design?
Well, actually I spoiled the ending with the thick and thin. You're going to see a lot of enterprise software companies try to move into this thin realm, and trying to sort out what that means.
And actually, again it seems opposite, but really trying to downplay these behemoth enterprise apps, these behemoth CRMs. I mean, we are always going to need them depending on who your audience is or who your primary user is.
But you're going to start to see a lot of enterprise software vendors and designers trying to be looking at this thin space. Again, even the plug, right? How might that show up in this little blinking green light that's on my wall, right? Starting to really think about some of those experiences right there, that's going to be one of the biggest trends personally.
Great, great. So with that, we have to wrap. Adam Doti, Vice President and Principal Design Architect at Salesforce. Adam, I know you're very active on social media and you've got quite a few ways for people to maybe follow up and get more information. For the audience that does want more, how should they find you or how should they find where you're publishing?
You could find me at @Doti on Twitter. You could find my awesome team @SalesforceUX, and you can also just go to salesforce.com/design, and you can get access to all the things—blog, our Twitter, all that fun stuff.
And it certainly is an awesome design team. Adam thank you so much for joining us. We really appreciate it.
Thanks for having me.
