Building Confident Users in the Space Between

What's up everybody, this is Cliff Seal, principal product designer at Salesforce, where I've learned a lot about this concept of the space between products. Today, we'll talk about what this looks like, and what we've learned in the process of spinning up organic design efforts that span across huge portions of Salesforce. I think everyone will get some insight you can apply to your context.

But another way to look at this talk, if you'd like, 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 and the benefits they provide, we'll be inherently dismantling some old, unhelpful ways of leading, getting input, and measuring success. Truly effective creativity here requires skills we can learn from community organizing, activism, and other democratic social movements.

If this angle speaks to you, I encourage you to do some additional non-design reading, because I'll be using a more UX-centric framing from here on out. Great places to start include “Where Do We Go From Here" by Dr. Martin Luther King Jr., along with the principles of organized nonviolent action. “Twitter and Tear Gas" by Zeynep Tufekci is another, helping you understand activism decision models—like consensus vs. democracy—and their trade-offs. Even the latest episode from the podcast Your Undivided Attention, called "Come Together Right Now", helps with understanding how other cultures communicate and make decisions together.

But if that's a little much for you, no sweat—we can just 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 you hadn't considered.

We'll talk about four main ideas: first, how to overcome incentives that work against cross-product workflows. Then we'll talk about how to identify opportunities in the space between and get traction on important work. We'll talk about designing for the exponential number of scenarios and workflows  inherent in cross-product interactions. Finally, we'll talk about really owning the end result of this design work and expanding its footprint. Designing for the space between products and services can't be a one-time deal if you want it to succeed and have impact.

You may be familiar with Conway's Law, which proposes that any organization that designs a system will do so in a way that mimics their organization's communication structure. While this may not be universally and literally true, it's a good enough framework for understanding why this "space between" exists at all. The edges and ends of our product experiences say more about our internal structure than they do about product design. Just as there are communication gaps in an organization—and just as those gaps widen as the organization grows—the gaps between product experiences can feel like switching multiverses. Meanwhile, no one internally is held accountable for the blind spot.

That doesn't mean the customer value isn't there, it's just latent. Specifically designing for the space between products lets your users transfer knowledge and intuition from one experience or product to another. When done well, this results in business value like faster adoption, increased customer satisfaction, and better time-to-value. Whether you're adding to your product ecosystem by way of acquisitions or just by shipping fast, you'll get value that accumulates for both your customers and your business. Integration has to go beyond colors and fonts, deep into the bones of how experiences work and how humans learn.

An important thing to note is that thinking about this problem is often designer-only territory. The nature of this work is often outside the incentive structure of any other part of the org, which means designers have to get traction and show value before the business can fund the work. I hope you'll see that as an opportunity. It means that, well before you're given deadlines or pressure, you can do the work to intentionally democratize the design process. You can own the process. You can ensure research is leveraged and applied. You can make sure the work gets adopted correctly. And ultimately, you can take responsibility for bringing others into work, leveraging a variety of experiences and expertise.

With this in mind, identifying opportunities and gaining traction starts with keeping a lookout. What I mean by that is to find ways to ensure you're exposed to work being shipped—not only by your closest colleagues, but everyone else within your organization. That can mean attending reviews, reading documents, rewatching recorded meetings, or holding office hours. It could mean building in mutual critiques with other design teams, even if your products don't interact. Without overwhelming yourself, I encourage you find ways to see as much design work as possible. Glaring into the void that is the space between products means taking time to let your eyes adjust to the expanse. Before long, you'll start noticing connections and patterns you hadn't seen before. Find others you can talk to about your ideas and get meaningful feedback.

Similarly, immerse yourself in qualitative customer feedback. Just as you're trying to absorb more information from looking at design work, you need to absorb more information from reading quotes from research participants and customer feedback. Depending on your organization, you may already have access to a world-class research team with mountains of quality readouts and data, or you may lack decent qualitative feedback entirely—but it's still valuable to look at what you have and read between the lines. Often, design validation tests for a specific interaction can give valuable insight to the larger work that needs to be done. I also recommend looking for multiple words or phrases being used by customers to describe the same concept: it often means you have a chance to solidify their mental model of an interaction and apply it consistently across products.

As you identify problems in the space between that need designed solutions, your next step is to intentionally—but organically—democratize the process.  All you need is a problem worth solving. Once you have that, gather together anyone who cares about this problem and has energy to solve it. To say it directly: diversity of experience and passion for the problem matter way more than design seniority. Don't try to shoehorn your org chart into this work. In fact, it doesn't even need to be mostly designers working on the problem. All that matters is that desired outcomes are clear, and promises from the group to the business are kept—such as any deadlines or progress reports. But you'll likely 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 some initial ideas should come before pitching the work to be funded by the business. This is mainly for those of you at companies large enough to be making very intentional funding decisions with engineering and product resources. At Salesforce, it's a pretty huge request to fund an effort, because that obviously means funding is being pulled from some other worthy cause. Don't try to request resources before you can clearly explain the problem at hand, and can demonstrate that others see the problem as well, and that you've made some progress on solving the problem in multiple contexts. Once you can do that, look for projects that already have funding (and a designer) behind them that could benefit from the work.

For instance, one effort I co-led at Salesforce a few years back was an organic effort from designers who noticed how often users have to put in the same types of rules-based information. It was so common that the interaction differences were nearly trivial in many cases, but the subtle differences would actually confuse users who were otherwise doing a very simple thing. In the bottom right, you see an example of this Expression pattern as we call it now, but in the background are a bunch of examples of similar interactions across products and services. As we gathered designers for this work, we looked for upcoming features or products that would leverage a rules-based interaction.

By finding these funded use cases that aligned with the overall goal—and committing to helping them with their design—we created a win-win scenario for everyone: these product and engineering teams would benefit from the design direction of the workgroup, which meant less time between concept and code for them. In return, our design effort gets the attention and thought of the designers from those use cases, which further diversifies the effort. It's a much smoother path to getting foundational design changes implemented across the organization. I can't stress enough how important this has been for this type of design work at Salesforce: adopting funded use cases builds rapport with the business by giving us a chance to show how this type of work is valuable. As you accumulate these smaller use cases that benefit from the overall effort and show that you can deliver value on a timeline, you'll gain organizational trust.

Now, as you commit to funded use cases and establish the scope of your work, you can go back to that first part of every design workshop—exploring. Get visual with all the use cases and their relevant interactions and put them all on the same board or in the same slide deck. Take time as a group to look for commonalities, and cluster similar interactions across products and workflows. This can be a simple asynchronous exercise with dot voting, so that the best design opportunities rise to the top. Start generating solutions that consolidate as many interactions as possible into repeatable patterns.

Then, you slam back down on the other side of the double diamond or design sprint or whatever our latest industry name for a meeting is. We reality-check and stress-test design ideas against those use cases. Here's what this means: instead of trying to design a broad pattern in isolation, apply the pattern to the funded use cases. Validate and test at that level. This ensures the context is right for the user performing the task, and feedback relevant to the pattern can bubble back up. Sometimes you discover a big problem ahead of time. Sometimes you'll just need to create a simple variation on the pattern to suit a new category of use cases. At any rate, our goal is still to let users transfer knowledge and intuition confidently and reliably across products.

One way of doing this is to analyze task completion down on that use case level, but with a couple of important notes that made this research invaluable to the organization (especially outside of UX). First, not only was this validation done on the use case level—an email builder in this case—but we designed the effort so that each user was creating something they already knew how to create in another tool. We asked users to bring their own email to build during the exercise. This gave us a better understanding of the delta between our current design, user expectations, and the ability to complete the task. As well, we asked users to rank their confidence in themselves during the exercise—it's not good enough for people to be able to accomplish a task, we need them to do it confidently. Transferring that confidence across products is the key.

For the gnarlier problems, and especially those that get into questions of information architecture, we've done research devoid of any product interfaces—no drawings, no wireframes, no mocks, no demos. Instead, we've used in-person and chat-based conversations to have users walk us through workflows using any terminology they wish—even terminology from a different product ecosystem. By asking questions and exploring the user's journey outside the bounds of UI, we were able to look for commonalities between mental models, and better align our work to them over the long-term.

As we round the corner into our final idea—owning the end result—I want to start by noting that the nature of this work gives you an opportunity as a human being to go beyond just getting work done. Thanks to the democratization of the work and the traction you can get before executive eyeballs are on you, you can also demonstrate new ways of thinking about constraints. In the cross-product design effort for building content in a drag-and-drop environment, we established a principle early on that this work wouldn't just be technically accessible—we adopted the language that "keyboard users are first-class citizens". Traditionally, drag-and-drop builders are hellish nightmares for keyboard users, but as a group we were able to design interactions that benefitted both mouse and keyboard users alike. Our accessibility specialists were invaluable here,  but a swarm of designers and engineers and PMs worked with them to create something excellent.

On the last slide, you saw an example of a more in-depth design document than we publish on lightningdesignsystem.com. At Salesforce, deliverables from our cross-product efforts include lengthy and robust documents for our design system website, but it doesn't have the level of detail needed for internal designers to get the full scope, or for engineering teams to build the designed patterns. So, we created a canonical internal document that further breaks down every part of the pattern, specs out the UI, and serves as an ongoing place for feedback and questions. Design the appropriate deliverables for your organization.  But most importantly, deliver what you say you're going to deliver. Every time. On time, or early. And in higher quality than anyone expects.

But don't stop at gaining internal trust. Set an example. Hold yourselves accountable to thoughtful, public metrics that can speak to the project's success. This reinforces the value of designing for the space between products, but it also reinforces the value of democratized, inclusive design work that gets rigorously tested. Because of Conway's Law, which we discussed at the beginning, your organization is likely not structured to "see" the benefits of this work, because it won't immediately make a money-number go up. Look for other metrics that indicate success: how much is the pattern being used, and how is the application of that pattern being received by users? What feedback is that team getting? What are they having to iterate on? How have you shortened the time between design and code for teams who use this pattern? Remember that even traditional usage metrics won't do the trick—if you're designing the space between products, you'll likely be reducing time spent in products. Think deeply about how to hold yourselves accountable, but please do.

The work isn't done once the work is done. The group must continue to evangelize, support, and advocate for new work adopting the pattern. Again, this is why you need a core team that cares deeply about this problem, so that the passion to see it through can carry the work forward for years. Utilizing funded use cases to get the work done means it can take a long time for the 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. Continue testing, iterating, improving, and expanding the work as needed. Whatever this looks like for you at your organization: share the hell out of it. Tell everyone about it. The more visible this work becomes, the more your willingness to be accountable pays off, and the more the organization will value designing for the space between. Most importantly, though, the humans on the other side of your designs will appreciate the reduction in cognitive load, uncertainty, and overall anxiety navigating across technology they pay you a lot of money for. Instead, they'll be increasingly confident navigating the space between.