Designing Products for Complex Processes

Jackie Scherer, Antonio Kaplan at UXDX Community: San Fran. Video: https://youtu.be/3Y1pAuZ_6R8

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

A new design team for RippleNet

[00:00:05] Jackie: Formally, product design is actually a new discipline for Ripple. The reason for that is because RippleNet started out as just a set of back-end APIs that integrate with our financial institution customers, and so the user experience for our enterprise users is in some ways often out of our control. However, Antonio and I have been working on starting a new team, which is working on a user experience, or user interface, that's a way of accessing RippleNet. And we're working on a product that supports highly complex processes: not only payment operations processes for enterprise users, but also business, legal and integration processes. Oh dear. Come back. Okay, just touchy, I guess.

[00:01:18] This process map was actually the end-to-end business process flow for all of Ripple. Actually, any process flow you see today is really a simplified version of the complexity that exists underneath. And this experience of mapping out what this end-to-end business process looked like was very illuminating for a lot of reasons. Basically, when I joined, there was this task that was given to me: "Here's a bunch of business process flows. Map out the end-to-end customer journey." And I was like, "Well, this isn't really the customer journey. This is our business process." So I had to make it very clear that the business process is different from the user journey. But it was a very illuminating process. The top is all of the business processes at Ripple, and the bottom is the different touch points for our customers.

[00:02:27] A complex process: a system of separate series of events or relationships that somehow relate to each other and create a larger whole. How many people here have either built, designed or managed products that are for processes that would fit this definition? Okay, so a lot of people, and probably a lot of them in specialized domains as well.

Backgrounds in complex domains

[00:02:57] Both Antonio and I have worked in different domains that are full of complex processes. I actually started my career in a construction company, in the marketing department, and I learned very quickly that I'm very fascinated by complex processes and how things are actually built. In construction there are so many different moving pieces and parts and things to manage. Then I went on to design construction software, actually ERP software. Later in my career I had a little bit of a hiatus in something that was a lot less complex, and I got bored very quickly. So then I went into manufacturing analytics, specifically on the plant production floor. I had not worked in finance before Ripple, but Antonio has. He'll tell you about it.

[00:04:08] Antonio: Yeah, I have. I've worked in a couple of different industries, finance and film. The similarity here is that they both have a lot of inherent complexity, moving pieces. The other big part is that there are natural incentives for the systems to stay the way they are, because there are a lot of people who make money and find success in them. An example in the film industry is actually distribution. When I started working in the film industry, the people who make the most money are oftentimes the distributors, though they're the people with the least creative involvement, and they come in at the end. So the risk-reward thing is always in a balance.

[00:04:45] And every single time, I think, as everybody mentioned before, you have this balance: there is a process for how films are made, but there is creativity that flows within it. And that's one of the main challenges, and what I've found exciting in my career: being able to say, how can we understand what the complexities are in these systems, and then find the creative solutions for them.

[00:05:05] Jackie: For sure. And I will say I really enjoy working with Antonio, because he really embodies what I would call a T-shaped engineering leader: very multidisciplinary, and he's held many different kinds of roles in his career. So we collaborate together, not only in designing based on requirements that are handed to us, but really pushing against the edges of things to figure out where the design innovation lies, and the engineering innovation as well.

Cross-border payments and who the customer is

[00:05:47] Antonio: Okay, so I'll take you through it. As Jackie mentioned before, there's a difference between Ripple and RippleNet. RippleNet is the product that the Ripple team is building. For anybody who doesn't know, and in this diagram it is not completely clear, RippleNet is a global financial network. The specific challenge and problem set that we're trying to solve is cross-border payments. Has anybody ever tried to send money overseas? For those of you who haven't, it is expensive, it is slow, and the user experience... I don't even know if you could call it that.

[00:06:27] Ripple is really trying to solve those three problems, along those three vectors: increasing the reliability, lowering the error rate. This is one of the things that shocked me: apparently six transactions out of a hundred in international transfers fail. Six out of 100. If you think about your credit card failing six out of 100 times, that's not what you'd expect of a financial institution, but that's actually what happens. And that leads to why it is expensive and why it is slow. That's really the reason.

[00:07:02] What Ripple does is we actually work with, not against, local regulators. We work with these legacy systems to understand what is inherent in these complexities, to utilize the existing rails that we have. And that's what a lot of our partners do. We have the sending side and the receiving side. The main part of what we do is actually integrating with a lot of these complex legacy systems, which is something that I think everybody's discussed.

[00:07:29] Jackie: Yeah, and to speak to that a little bit. When I arrived at Ripple, it was a bit confusing when people talked about the customer, because it's one of three things. The customer could be the buyer or the decision maker, the financial institution, or its team, or it could be the person actually using our product. We build a system that enables a better experience for consumers by changing the industry and the infrastructure that supports it. That's been really fascinating for me, because of not only the different sides of the network, sender and receiver, but also the enterprise side, and the way that affects the consumer experience.

[00:08:29] Antonio: The main case study that we wanted to talk about, out of the bunch of different complexities, the main one that we work on, is lowering the bar of entry for our customers. It's one of the most challenging things. Obviously, for a business, you want to be able to onboard customers that have a desire to use your product and move them to actually using the product as quickly as you can. If anybody's worked with financial institutions, this is neither fast nor easy. There are a lot of parties required. So again, there are inherent complexities in this system. But within that is where the challenge lies, I find, of working with UX [?] and working with engineering to see how we can identify and solve these problems. Again, lowering this bar: how can we integrate with these existing systems, and where do we need to push back and innovate new ones?

What makes onboarding so complex

[00:09:19] Jackie: Getting back to this map. The actual integration and setup with our financial institution customers is in this section here of the map. But the goal eventually will be to make this whole business process of getting our customers onto RippleNet completely self-service through a product. So it's a really big mandate. Currently we have a pretty large customer success team that includes project managers, integration engineers and solution architects. If anybody's worked at an enterprise software company with a pretty complex integration, you know that every customer requires a project to get started, or some sort of consulting services. Formerly I worked on an analytics product that often required a lot of upfront data prep and configuration. So this is a common thing that we find in enterprise software, but obviously in order to scale we need to start to productize these things.

[00:10:36] It's pretty clear from this map that this end-to-end process is very complex, but I want to go into some of the things that you don't see on this map that make it particularly complex. One is that there are multiple user journeys and levels of engagement along the way. Especially with our large bank customers, we could potentially start with a certain set of people that we're working with, like a team that is working to integrate the software, and then that team could turn over and we end up with a different team. Or we have a business lead who might come in at the beginning, then go completely MIA and be disengaged, and then come in again at the end. So there are different levels of engagement, and places where these users come in and out of the process. That's one area: how do you design a product for a process where the user is potentially going to change throughout the journey?

[00:11:48] Also, there are concurrent business and technical activities that can sometimes happen in parallel, with different teams, but with dependencies among those teams. For example, sometimes our sender and receiver parties will spend a long time negotiating the terms under which they're going to exchange money, and in the meantime the tech teams are getting up and going. But obviously those two processes need to come together, so they can understand that middle layer where the business requirements meet the technical implementation.

[00:12:27] As I mentioned, collaboration: not only between sender and receiver parties, but also between business and technical teams, both within these institutions and across these institutions. And that doesn't include a lot of qalaat [?] heavy collaboration between Ripple employees and our customers. And there are also a lot of pre-existing rules that need to be followed. There are a lot of standards we have to adhere to that build more inherent complexity into the system, and it's part of the reason it's so difficult to transfer money today. But slowly but surely we are actually molding those standards.

No silver bullet: dwelling in the problem

[00:13:13] We wanted to share with you a few ways in which we have worked to try to envision a more simplified process for this particular problem. Antonio brought up this quote this week, which I also really liked: "For every complex problem there's an answer that is clear, simple and wrong." Self-service onboarding, self-service setup, has been this rallying cry from some of the folks in our organization. And there really is no silver bullet for this. So Antonio and I have been trying to manage expectations about what is possible to do from a product standpoint.

[00:14:06] Antonio: I think as engineers there's a tendency to consistently oversimplify, and also to jump to solutions before you fully understand the problem. And these financial processes have existed for a long time. There are good reasons for some of them, and there aren't for others. That's a lot of the challenge that we've been facing: when to simplify, when to look for those answers, and when to lean on our subject matter experts to realize that sometimes there isn't a really easy solution for these problems.

[00:14:37] Jackie: And yeah, like Antonio said, as a designer, really dwelling in that problem space. Dig deep, marinate, dig deep again. And to that, something that I learned coming into Ripple, especially with product design being a new function: I didn't really have a lot of user research resources, for example. I was the only product designer at all for a while. Sometimes as designers and researchers we think of user knowledge as our superpower: "Oh, if we have this insight about how the user does this task, that'll help us influence change." But I think creative ignorance can also be a superpower: being able to ask your teammates questions and help them get on board by being super humble and super curious.

[00:15:35] Second to that is being helpful to these internal subject matter experts. In any complex process or Colombo's [?] domain, you're going to have subject matter experts. The goal is to really build a win-win relationship with them, where they feel like you're on their team, supporting them in their jobs and eventually making their lives easier. And then lastly, when you have a long, complex process with a lot of internal processes, the user or customer voice can sometimes get lost in that process. So you can continue to work with customer success teams to bring that to the surface and make sure that it's coming through, even with all these different activities going on.

Ways to mold a complex process

[00:16:21] These are a few ways that we've been working to try to mold this complex process. One is making sure to get multiple customer-facing perspectives. You can't just go to sales and get their perspective on how things could change. You can't just go to technical services. You have to actually go to each team and understand their view of the world. That's the only way you can really start to understand how to change the process, because that's how the efficiencies are created: by breaking down these silos.

[00:17:00] This could apply to a lot of different activities. For task analysis, it's tempting as a designer to look at it like architecture: look at the big picture and then start to drill into the details. But innovation can actually be lost that way. Sometimes you can actually get into the details, get very messy, and start to build up a process that is actually simpler. So I actually recommend both approaches. There's a place for either.

[00:17:30] As I mentioned, the business process and the user experience, the way that the user experiences that business process, are two different things and should be defined differently, but they are both important. You can't just look at the user journey. You also have to look at how the business process affects that user journey. That includes what our users are feeling, doing and thinking, and this is our business users.

[00:18:02] Currently we have a set of business and technical teams, a lot of technical folks often working on system integration. We know that in the future we want to make this process so simple that our business users can set up and get going on RippleNet. In fact, one of the projects that I took on was making a future vision video. It was more of a marketing video of what this ultimate experience could look like if the business user can do everything. That was an aligning force: we know this is the future, and we know that the industry is actually going to be changed and transformed if we're able to do this for this particular user. But you can't just dwell in the future. You have to actually look at what's happening on the ground now and try to mold it. It's not an overnight thing. It's a very slow process.

[00:19:03] To sum this up, problems of this type of complexity require brain power from multiple different disciplines. And I think that's what I enjoy so much about working at Ripple and working on this product: you have to collaborate so heavily with so many different people in order to solve this problem that we're working on. And Antonio is going to speak more about that.

Simplify, automate, transform

[00:19:29] Antonio: So what are the processes that we've at least tried to follow within our working group? This three-step approach. Simplify: what does that mean for us? Simplifying means working with the subject matter experts to actually unlock which steps of the process need changing. One example: we had five different steps that all took, let's say, a month. One of them was contract negotiation. And I think as an engineer you see "contract" and think, what's the solution we can have for contracts here? DocuSign. I want to manage the signing of the contracts. Digging into this a lot deeper, our subject matter experts were like, "No, that's not the part of the contract that's hard." That's not unusual. Where the time actually goes is doing service level agreements between the two parties.

[00:20:15] It's about understanding and using the subject matter experts that we have at our disposal. Most companies have a lot of these individual knowledge centers that have a really strong desire to be heard. As an engineering and UX team, our job is to help unify them and bring their voices together to unlock these complex problems.

[00:20:32] The automation part is another thing that engineers, I think, feel really, really good at. The problem and challenge that we have with it is: what has the maximum impact? What are the pieces that we need? So it's not just a premature optimization problem, but making sure that all of the pieces we're trying to solve add up towards a global success.

[00:20:51] And then the transformative part of all of this is working with the existing business processes, working with the existing people that actually do these jobs. Not only can you unlock each part of this, but again, you have to make sure that you're encouraging and incentivizing behavior in a positive way for change. Without really getting into the mindset [?] of each one of these people, you can try to make the process simpler in general, but you actually don't solve the problem. And I think, as we saw, 66 percent of products don't succeed, and this is one of the reasons why: you have individual successes, you're individually optimizing pieces, but you don't have a transformative encouragement of behavior. You're ignoring it, or you're just glossing over it.