Building Confident Users in the Space Between
Cliff Seal presented “Building Confident Users in the Space Between” at UX Camp Spring 2021. Enjoy!
Principal Design, Salesforce
Cliff is a Principal Designer at Salesforce, helping build world-class customer experience tools. For him, experience design is a strategy for creating positive change in the world for others—not in a vague sense, but a literal one. Transparency, feedback, and accountability are critical components of any equitable system. Great design work treats these components as requirements for success and leverages them to better ensure human-centered outcomes. Cliff put this perspective to work through experience design, thoughtful presentations, and lots of experimentation.
The following transcript very likely contains typographical errors. Please forgive any mistakes!
Alright, let me make sure I pull these up correctly. Alright, awesome. Cool, so good morning or good afternoon. Where I am over on the East Coast in Atlanta. My name is Cliff, I’m a principal product designer here at Salesforce. I like to say here at Salesforce, because normally I’m at work during a meeting, but… My God, it’s Saturday. I’ve learned a lot in my time at Salesforce, a little over nine years. Now, I think about this concept that we’re gonna talk about today of the space between products, and so we’ll discuss a little bit about what this looks like, what we’ve learned, the process of spinning up organic design efforts that span across these kind of huge portions of a large company like Salesforce, but I think everyone is gonna get some insight that you can apply to your individual context, no matter whether you’re working for yourself or just a smaller company or a big center prize behemoth like myself, but I do wanna give you another way to look at this talk if you’d like, because actually another way to see it is subverting systems of infinite growth and toxic leadership through intentional diversification and coalition building for the betterment of all people, simply by discussing non-traditional forms of leadership today and the benefits that they provide, will kind of be inherently dismantling some old unhelpful ways of leaving, of leading people, of getting input, of deciding what input matters, and by measuring success, truly effective creativity in this design space we’re talking about require skills that we can learn from community organization and activism and other democratic social movements.
So if this angle speaks to you, I encourage you to do some additional non-design reading because I’m gonna be using a UX-centric framing from here on out.
So a few great places to start, if you identify with this angle, or where do we go from here by Dr. Martin Luther King Jr, along with the principles of organized non-violent action, the book Twitter and tear gas by SNAP to ECI is another helping you understand activism, activism, decision models like consensus versus democracy and their trade-offs, even the latest episode from a podcast called your undivided attention called Come Together right now helps you understand how other cultures communicate, they make decisions together.
But listen, if that’s a little much for you, no sweat, because we’re just gonna talk about building confident users in the space between products and services to better enable them to use your product for its intended purposes and to allow new use cases to emerge that you had not considered.
So we’re gonna talk about four main ideas, we’re gonna talk about overcoming incentives that work against cross-product workflows, that’s an important part for us to unlock, to start with. Then we’ll talk about how to identify opportunities in the space between and get traction on this important work, we’ll talk about designing for basically this exponential number of scenarios and workflows that’s inherent in cross-product interaction, and finally, we’ll talk about really owning the interest of this design work and expanding its footprint, designing for the space between products and services cannot be a one-time deal, if you want any product or project to succeed and have impact at this level. So let’s go ahead and dive in. You may be familiar with Conway law, which proposes that any organization that designs a system will do so in a way that mimics their organization’s communication structure, whether this is universally a literally true or not, which it is not, it’s a good enough framework for understanding why this space between products exist at all, the edges and the ends of our product experiences really say more about our internal structure than they do about product design at all.
Just as there are communication gaps in an organization, and just as those gaps widen as the organization grows, so to do the gaps between product experiences, it can start to feel like switching multi-verses and hitting up the Nexus, Meanwhile, no one internally is held accountable for the blind spot that happens there because of Con way’s law, so that doesn’t mean that the customer value isn’t there, it just means that it’s latent, and that is kind of your job to make sure it gets brought out and shown to people, so you specifically designing for the space between products allowed your users to transfer knowledge and intuition from one experience or product to another. And when done well, this results in business value, like faster adoption and increase customer satisfaction and better time to value, so whether you’re adding to your product ecosystem by way of acquisitions creating this cross-product experience, or whether you’re just shipping a lot of things really quickly, lots of new products quickly, you’ll still need the value that accumulates here, the value accumulates for both your business and your customers, so this is where we have to push past the kind of business-level integration that says, as long as they look similar, we’ve integrated colors and fonts don’t cut it, we gotta go deep into the bones of how experiences work and how human beings learn.
Now, an important thing to note before we can dive into the how of it, is that thinking about this problem, and I wanna be clear on this one, it’s often designer-only territory, not because we’re excluding other people, but because the nature of this work is often outside the incentive structure of any other part of the org, so designers have to get traction and show value before the business itself really understands how to fund the work, so I hope you’ll see this as an opportunity today… Just because other people don’t see it doesn’t mean it isn’t there. It just means you have an opportunity to figure out how to structure this work.
So the opportunity is well, before you’re given deadlines or pressure from the business to solve a problem, you can do the work to intentionally democratize the design process, you can own the entire shape of how this looks and works itself out, you can ensure that research is leveraged and applied, you can make sure that the work gets adopted correctly by advocating for it long term, and ultimately you can take responsibility for bringing others into the work, leveraging a variety of experiences and expertise, and we’ll talk about the tactics of that a little bit more, so with all of this in mind, as we start looking to identify opportunities, it starts with something really particular, and I call it keeping a look out. And what I mean by that is to find ways to ensure you’re exposed to work that’s being shipped, not just by your team or by teams that are closely associated with you, but by everyone else within your organization.
So that can mean attending reviews for designs, you may not have anything to do with or reading documents for things you may not technically need to read or re-watching recorded internal meetings or holding office hours to ask questions and give feedback, it can mean building in mutual critiques with other design teams, even if your products don’t interact yet.
Without overwhelming yourself, I encourage you to find ways to see as much design work as possible that might possibly be relevant to designing for the space between… Because here’s the thing, glaring into the void, that is the space between products means taking some time to let your eyes adjust to that expense it, the same way you need to see all the stars by kind of… Letting your eyes adjust to the darkness. Before long, you’ll start noticing connections and patterns that you hadn’t seen before, find others that you can talk to about your ideas and get meaningful feedback. Now, second part of identifying opportunities means immersing yourself in qualitative customer feedback, just as you’re trying to absorb more information from looking at the expanse of design work, you also wanna absorb more information from reading quotes from research participants, customer feedback, idea exchanges, whatever you can get a hold of, because depending on your organization, you may already have access to a world class research team with mountains of quality read-outs and data like myself, or you may totally lack decent qualitative feedback entirely. The thing is, it’s still really valuable to look at what you have and read between the lines.
Even design validation tests for a specific interaction in some other product can give you some valuable insight into the larger work that to be done. I also recommend speaking of idea exchanges and other forms of open customer feedback, I also recommend looking for multiple words or phrases that are being used by customers to describe what you would say is the same concept.
When you notice this occurring when there’s two or more words or phrases that describe the same idea, it means you have an opportunity to solidify the mental model of interaction across products and start applying it consistently in this space between…
Now, as you identify the problems in the space between that knee design solutions, your next step is to intentionally but organically democratize this process, all you need is a problem we’re solving, and that’s why we’ve talked about getting immersed in the qualitative feedback and keeping a look out because what you need, even if you can’t fully describe it yet, is a problem we’re solving, I see something out there that’s in the space between products… Does anyone else see it as soon as you have that you can start gathering together, anyone else who says yes, and I really wanna work on that. You’re looking for anyone who cares about the problem and has the energy to solve it, now to say This really directly diversity of experience and passion for the problem matter way more than design seniority here.
So I wanna encourage you when you’re creating these kind of organic processes to start solving a problem that other people don’t know how to describe yet, don’t you horn your org chart into the word don’t create a bunch of hierarchy, it doesn’t even need to be mostly designers working on this problem, all
Of that matters at this stage is that your desired outcome is clear, I want to solve this problem that I’m seeing, and then that any promise that this working group makes to the business is kept… If you give yourself a deadline or you promise to get progress reports or you get asked for something else in exchange for spending this time working on this problem, keep your promises, but before you get this work totally funded before the business usually pays a lot of attention to any of this stuff, you’re probably gonna need to make some progress first, in fact, it’s been my experience that working with a passionate and diverse group of folks to get an initial idea or so should come way before pitching to fund this problem by the business, right?
So the idea here is that, again, you’re using this group of people who care about the problem to start getting some motion so that you can go tell other people, not only do I want you to help us make this problem better or help us make this problem go away because we want to learn how to solve it and implement it, but
Here are some things we’ve already been able to do from the get-go without further funding or resourcing or whatever.
Now, this is especially important for those of you at companies who are large enough to be making these really intentional funding decisions with engineering or product resources at Salesforce, it’s a really huge request to fund an effort because that means that funding is being pulled from something else that’s probably worthy as well.
So I wanna encourage you don’t try to request resources for this problem or this word group before you can really clearly explain what the problem is, can demonstrate that others have seen the problem as well, and that you as a group, I’ve made some progress on starting to solve that problem in multiple contexts. You don’t need to have the right answer, you just need to show that you were able to get answers. Pretty quickly from nothing.
Once you do that, then you can begin looking for projects that already have funding and hopefully a designer along with them that you can leverage that can benefit from the work of this kind of overall larger problem that’s being solved, but you also get a second benefit.
So I wanna break down how this works because it’s… We’re talking about the space between… It’s really easy to get a little meta and esoteric here.
So I’m gonna make sure that we bring this down to some use cases and some real literal things that I’ve personally learned through efforts like this. So one effort that I collected Salesforce a few years back was in an organic effort from designers who noticed how often users have to put in the same types of rules-based information, and this probably makes sense to you as an actual user of services as well, there are infinite ways for you to put in basically three inputs worth of information as some sort of criteria in a system, it’s just breaking down SQL and trying to make it user-friendly.
But the thing is, it was so common is even inside of just all the products that we had… That we’re connecting together. That the subtle difference is we’re actually confusing users, even if the overall interaction was really similar across products, right. It was because it felt similar and that just one or two things were different that actually made it worse than it feeling like a totally different interaction at all, because users felt confidence, but then found that they couldn’t actually complete the task that they wanted to do.
So in the bottom right of the slide, you see an example of what we would end up calling the expression pattern, which became a standardized way for us to do this across Salesforce products, but in the background or just the sampling of the audit that we did of all of the different places that we felt that this existing interaction was occurring in products today, so that we could go ahead and figure out what was and wasn’t working, and then could really easily start to look for new opportunities based on these that were either new features, being added or new products that might take advantage of this kind of rules or criteria-based UI, and what that let us do was find designers and use cases that we could bring into this work by looking for those existing efforts that were already being done. We kind of created this leverage for ourselves, we created a way to kind of draft off of what was already being done and funded by the business, because when you’re looking at this problem and you’re starting to get a little bit of traction about solving the overall problem but now you wanna start really letting the rubber meet the road and solving this on the individual use case problem, using those funded use cases that the business has already committed to you, gives you a lot of leverage in this kind of win-win scenario, right.
’Cause two things happen when you do this, instead of trying to create use cases from scratch, first of all, the existing teams who are already planning to work on these use cases are going to benefit from the design direction of the worker, which means less time from design concept to code for teams, that’s usually a huge win to start with.
Now, in return, our design effort, this big work group gets the attention and thought of at least one designer who’s working on this, and usually the rest of the team who’s working on this problem, and that further diversities our effort, it brings more people to the table who want to solve this problem, but might not know how to look for the space between…
So again, this has been really important for us at Salesforce, and I would encourage you, especially at other large organizations, to think about adopting funded use cases to really start building out this design work, it helps you build a rapport with the business because it also gives you a chance to show how this type of work group effort is valuable, remember, we talked about this is often designer-only territory because people don’t know how to know that this work is there. Well, what you’re showing them now is, designers can identify this work, we can start to get traction organically, and we can come alongside use cases that the business already wants to ship and we can make it better, and we can help it ship faster, and we can help those users have more confidence, that creates organizational trust in this entire concept, which means if you stack a few of those up, eventually the business wants this sort of thing to happen.
So you’ve gotten those funded use cases, you’ve really… People in… Now, let’s talk about the actual design part of it, which frankly is a lot more fun because if you’ve done the work of getting the right people kind of having a seat at the table, if you’ve got an intentionally diverse group of people passionate about solving this problem, you’ve done most of the setup work that’s important, now it’s simple design process stuff, right, so you’ve got those funded use cases, you’ve thought of the scope of your work, what problems are we gonna solve and how are they gonna apply to these particular use cases?
Now you go to the first part of every design workshop, right, you start exploring, take all the use cases, put them all on the same white board or the same mural Board or the same slide deck or whatever you want, and start pulling out all of the relevant interactions, and start thinking about how you can cluster to them, what are the commonalities between all of the interactions inside
Of these particular patterns, and then between them and across products, just start looking for commonalities and clustering, so this can be a really simple common design exercise right. Like an asynchronous, everyone go identify every cluster that they can, and then we’ll come back and do some simple dot voting on the ones that make more sense.
So that the best opportunities rise to the top, right? There’s no straightforward way to solve this problem, so you just gotta start by exploring what’s there and then whittling it back down, so you wanna start generating these solutions that consolidate as many interactions as possible into repeatable and usable patterns.
Once you’ve done that and you’ve done the big exploration stuff, you slam back down to the other side of the Double Diamond or the design sprint or whatever our latest industry term for a meeting is, and what we’re doing there is where reality checking and stress testing, or design ideas, we’ve come up with the big clusters, we’re starting to figure out how to solve these clusters, and what we need to do instead of testing at that generic level is bring them down to the individual funded use cases. So instead of trying to design a broad pattern that solves everything and testing and validating on that level, apply the pattern as proposed to the funded use cases, then validate and test at that level, that ensures that the context is right for the user that’s actually gonna be performing this task, and that the feedback relevant to the pattern can then bubble back up instead of trying to test as one big idea, you’re testing as little use cases and then learning what you can from that validation and letting that bubble back up for iteration, because at any rate, our goal is to let these individual end users transfer knowledge and intuition confidently and reliably across products.
Now, I wanna give you a few really specific ways to think about bringing down patterns to the individual use case level and making sure that they could be validated.
So one way to do this is combining task completion and confidence.
So let me give me an example of a test that we did that worked really well and one that became really invaluable to the organization, even outside of us, so we were designing on a larger content builder pattern level, we wanted the building of content to be really consistent across all of our products going forward. Which was a big lift. Right.
And so what we did here was we brought it down to the individual use case level, so this was for an email builder, but
We designed this particular testing effort so that each user was creating something that they already knew how to create, so we asked each user to bring their own email that they were already using, that they had built using either one of our products or another Email Builder product and use that as their goal for the test.
So then they had to use our tested builder to create a thing they already knew how to create, so this gave us a better understanding of the delta between our current design user expectations about the design and their actual ability to complete that task as well. We ask users to rank their own confidence in themselves during the exercise, because there’s a thing, it’s not good enough for people just to be able to complete a task. We need them to know that they’re doing it correctly. We need them to have the confidence so that they can transfer that confidence across other products, so you have to actually be able to measure that and make sure they’re confidently Achieving the task as designed for some gnarly or problems, and especially those that kinda get into questions of information architecture, we’ve done research devoid of any product interfaces at all, right. No drawings, no wire frames, no mock-ups, no demos. Instead.
We’ve used in-person or even chat-based conversations to have users walk us through workflows and their daily work using any terminology they wish, even terminology from a different product ecosystem by asking questions and exploring their journey outside of the bounds of an interface, we’re able to look for commonalities between mental models and then better align our work to them over the long term… So as we round the corner into our final idea here, owning the in result as the pattern has gotten designed, applied to end use cases, tested and validated and then continues that iteration cycle.
I wanna start now by noting that the nature of this work gives you an opportunity as a human being to go beyond just getting the work done.
Okay. Thanks to the democratization of the work and the traction that you got before executive eyeballs might have landed on you, you can also demonstrate new ways of thinking about constraints, so in the cross-product design effort for building content, like I was mentioning a moment ago with builders in a drag and drop environment, we established a principal early on that we didn’t want this work to just be technically accessible, we adopted a language that keyboard users are first-class citizens in a drag and drop builder, like that’s no joke. That’s really hard to do it. Traditionally, drag and drop is a hellish nightmare for keyboard users, but as a group, we were able to design interactions that benefited both mouse and keyboard users alike by taking this approach, our accessibility specialists who are involved in the work the whole time, we’re obviously invaluable.
But a swarm of designers and engineers and PMs work together with that principle to create something excellent instead of just checking the box, he says, this pattern technically meets guidelines, we’re able to say instead, if you use a keyboard, you can also build any content in a very reasonable… And comparable amount of time to using drag and drop, and that’s pretty huge. Now, on that last slide, you saw an example of more in-depth design documentation, actually we go back to it, just so you see a little bit more, this is actually a screenshot of an internal design deck. Now, we do, we have more in-depth internal documentation like that, then we publish on our design system public website, Lightning Design System dot com.
So at Salesforce, deliverables from cross-product efforts have really specific deliverables, they include lengthy and robust documents for our design system website, but even that document does not have the level of detail needed for internal designers to get the full scope of the work over engineering teams to build the designed patterns, so we created a canonical internal document that further breaks down every part of the pattern, which was that screenshot you saw it specs out all the UI on a super detailed level ensures also as a place for ongoing feedback and questions from anyone who has questions about this pattern or wants to critique it.
So I want you to consider designing the appropriate deliverables for your organization, think really deeply about what it means to deliver an output from this effort and what’s gonna most benefit your organization overall, most importantly though, decide what you’re gonna deliver ahead of time, and then deliver what you’re gonna deliver every time on time or early and in higher quality than anyone expects. This is important, I think over my career, I think a lot of other people would agree, we’ve kind of gone from design having a seat at the table to actually being able to do some things from time to time to the business, but we can’t lose that now, so remember that these efforts need to be shown to be valuable, and you can do that by meeting expectations and delivering every single time, but
Don’t start at gaining or don’t stop at gaining that internal trust. I want you to set an example, I’m gonna encourage you to do that because it’s possible with this type of work, hold yourselves accountable to thoughtful public metrics that speak to the project’s success, this… The value of designing for the space between products, but it also reinforces the value of democratized inclusive design work that then gets rigorously tested because of Conway S-law, like we mentioned, your organization is likely not structured to see the benefits of this work from the get-go. Because it won’t immediately make a money number go up somewhere, right?
So look for other metrics that indicate success, how often is this new pattern being used that you’ve designed, how is the application of that pattern being received by users, what feedback are those end use case teams getting, what are they having to iterate on? Have you shortened the time between design and code for internal teams who use this pattern? Just remember that traditional usage metrics will not do the trick if you’re designing well for the space between products, you’re likely reducing the time spent in apps, so think deeply about how you wanna hold yourselves accountable, but please do. Now finally, the work isn’t done, once the work is done, the group has to continue to evangelize, support and advocate for this new work, and getting the organization to adopt the pattern. Again, this is why it pays off to initially get that care team that cares deeply about this problem.
So that the passion to see it through can carry that work forward for years, utilizing funded use cases to get the work done means that it can take a really long time for this new work to permeate different products and services, but if you keep at it, eventually it will continue under its own momentum, I’ve seen this firsthand, so continue testing, iterating, improving and expanding this work as needed, whatever this looks like for you at your organization, share the hell out of it. Tell everyone about this work, about how people weren’t seeing the problem, then a group of people solve the problem, then you started being able to solve the problem, then you found use cases to solve that problem, then you ship to use case solutions and solve that problem. And now you wanna keep iterating, this pays off, the more valuable or the more visible this work becomes, the more your willingness to be accountable for it pays off, and the more the organization will value designing for the space between most importantly though, the human beings on the other side of your designs that we traditionally call users will appreciate the reduction and cognitive load, the reduction in uncertainty, in the reduction in overall anxiety having to navigate across technology that they pay you a lot of money for, instead they’ll be increasingly confident navigating that space between.
So thank you so much for spending some time with me today. I get really excited talking about this, and it was a true joy to get to present this with you. Thanks so much.