Chris Risdon is a Senior Staff Designer at eBay. Chris describes himself as an interaction designer that tends to look through a service design lens. Alongside his co-author Patrick Quattlebaum, Chris wrote Orchestrating Experiences, which is an excellent guide to the practice of service design. In this conversation, we unpack service design: what it is, how it benefits organizations, and how it might be changing in light of new technologies like AI.

Show notes

Show notes include Amazon affiliate links. We get a small commission for purchases made through these links.

If you're enjoying the show, please rate or review us in Apple's podcast directory:
https://podcasts.apple.com/us/podcast/the-informed-life/id1450117117?itsct=podcast_box&itscg=30200

This episode's transcript was produced by an AI. If you notice any errors, please get in touch.

Transcript

Jorge: Chris, welcome to the show.

Chris: Hello. Thanks for having me.

Jorge: It’s great to have you on the show. We’ve been colleagues at CCA, and I think of the other Rosenfeld Media authors as stablemates.

Chris: Yeah, exactly.

Jorge: You and Patrick Quattlebaum wrote a book called Orchestrating Experiences, which I’ve learned a lot from. I admire your work, and I was hoping that you would tell us about it. So, how do you go about introducing yourself?

About Chris

Chris: I don’t know if I have a canned introduction, but like you said, I’m Chris Risdon. I am currently a senior staff designer at eBay. I’m part of an AI Foundations design team. So it’s a very small team, and it’s a team that’s just been built in the last six months or being grown and developed and led by my manager, Ben Loudon, and we’ve got some other designers on the team.

The focus on AI has been a theme the past few years and through a few jobs with me. Before this, I was working for an AI healthcare company, mostly focused on computer vision, using AI to detect strokes and embolisms for radiologists. And before that, I was at IBM as the Director of Design for a data and AI team under their Watson banner. I got to cut my teeth hands-on with some of those challenges in that job.

I’ve traversed a lot of flavors of disciplines. I started as a graphic designer in my design career, and eventually morphed. Before that, I was actually more of an information architect back in the Web 1.0 days where I was a web producer with my Polar Bear book in hand because we didn’t have dedicated information architects.

Then graphic design morphed more into the broader UX space. And the interesting thing is, I’m probably most known from a service design standpoint, which I like, but I consider myself more of an interaction designer that tends to look through a service design lens. It’s how I frame it, just as a way to reconcile the two disciplines that I like to tread in.

And lately, the past few years have been about looking at the intersection of service design and AI. It’s affecting a lot of things, and my interest from a service design standpoint is how it affects and how it gets used from a service design lens.

Explaining Service Design

Jorge: My sense is that service design is an area that has had more traction or has been more developed in Europe than it has in the US. How do you explain what service design is? Because I suspect a lot of folks might not be familiar with it.

Chris: Yeah. A lot of us that have been trying to, not simply evangelize, but put into practice a lot of service design within organizations, always come up with that definition. I don’t know if rudimentary is the right way to describe it, but I think of service design when I see an experience that takes place over time and space and across different channels and touchpoints. It’s not about worrying whether a product or service is tangible versus intangible. It is more about this idea that you’re engaging with something, whether that’s a company, a brand, a service, or even a type of product experience, and considering the time and space factors involved.

Even if I’m working on a digital product that enables healthcare practitioners in a hospital to communicate better, I’m not simply creating a digital product. I have to think about where they are when they’re using it. Are they using it on the desktop? Is it integrated with another digital product? Are they using it on their mobile device? Is it in the E.R.? Is it when they are being discharged?

So, there’s this time and space, and there are these channels and touchpoints. That’s the baseline for me. Some products can be abstracted out, and you could apply a service design lens, but with digital products where the experience tends to be the same set of actions on the same channel, it’s different. For example, I’m always going to use Microsoft Word in essentially the same way, taking the same steps through the same channel, whether on my laptop or my iPad. It’s still the same touchpoints and experience. The same goes for Dropbox, Twitter, or whatever it is.

But then there are digital products where time, space, touchpoints, and channels come into play. This interplay can boil down further to context switching. The context of me using certain digital products always stays the same, but there are digital products or experiences in general where the context changes. That’s probably the simplest way I’ve reconciled when I want to apply a service design lens.

Jorge: I’m going to reflect it back to you just to make sure that I’m getting it right, and I’ll do that through the lens of an interaction that happens to me fairly frequently, which is mentoring folks who are entering the field. I was just having a conversation a couple of days ago with someone who is thinking about pivoting into UX. The sense I got from that conversation was that this person was conceiving of UX design as something that is screen-oriented. So, they’re thinking, “I’m going to be designing things that people experience on screens,” and perhaps—the context there, to use your word—they’re designing a set of screens for a particular app or web-based application. That’s one way of doing design.

But what I’m hearing here is that there are situations where the thing that you are designing is not just a set of screens or steps that are experienced in one app or web-based product. They actually span multiple touchpoints and channels, and it happens over a span of time. I’m making this distinction because I’ve had experiences where I’m onboarding into a new digital product, and it’s all happening within the same app. Maybe the initial step is applying for access, and then it takes a couple of days before I get an email saying, “Now you have access,” but I’m staying within that “product.” Can you spell out the difference between channels and touchpoints? I think that’s something that might not be clear to folks.

Channels and Touchpoints

Chris: So channels, I still kinda consider the medium of delivery, right? A kiosk could be a channel, and a mobile phone could be a channel, but I don’t think there’s a rigid taxonomy to channels, in that sense. I think if you try to overly define the mobile device as a channel, but then think about the ways you might use a mobile device, like is an iPad a mobile device? But it is the means of delivery.

The touchpoint, I think, is… touchpoints sometimes are a dirty word because I think people don’t know what to do with it and they can conflate it with the channel and that’s fine. But, in my own sense-making, a touchpoint is really defined almost agnostic of the channel about the moment of meeting a specific need at a specific point in time.

So, a kiosk for checking into the airport has multiple touchpoints. If I have to scan something like an ID, that’s a touchpoint because that’s a specific need I need to address. You can sit there and go, “It’s the kiosk touchpoint where I scan my passport,” but that touchpoint is different from the one when I’m entering things into the kiosk to select my seats or pay for the bags I check. That’s a different touchpoint being delivered through the kiosk channel. But it’s a different need being set technically, maybe seconds differentiated, by a different need being met at a different point in time. But it might be delivered by that same channel, the kiosk, that’s there.

I don’t say that there are hard and fast rules between them, but you can conflate them. But I think that the channel, at any point in time, is the means of delivering that experience, and a touchpoint you can conflate it with the channel, but it’s defined by the moment and the need that is being met. You can say the mobile channel is also the touchpoint if I’m interacting with it to swipe open my phone. So, I try not to say that there’s a rigid structure or taxonomy between them, but I tend to define them a little bit about the touchpoint being that moment being met and the channel whenever it’s getting used is static in this position of being a means of delivering the experience.

Jorge: I’m envisioning almost a hierarchy where multiple touchpoints could happen in a particular channel. I could imagine that you can also have similar touchpoints that are served through different channels. So like you could apply for an account in the mobile app, or you could go in person to the office, and that would be a touchpoint served through different channels, right?

Chris: Absolutely. That’s absolutely right. And like I say, I don’t worry about if someone’s using those words correctly. I just think that there are times when you might want to make that distinction around what’s happening at the moment, what needs are being met by this channel. So that’s when it becomes a touchpoint because there is that “touchpoint.”

It’s like when the brand or the experience and the consumer come together. And then where’s the channel? And you just look at it from a lens of what the capabilities of this channel are. So touchpoints are going to be a little bit more about the moment and what goal is being met. And a channel is going to be a little bit more about capabilities. So if I have a touchpoint of needing to inquire about my account balance at a bank, I can go to the mobile channel to do that, or I can go to the phone channel to do that.

And when I’m designing an experience, I look at the capabilities of the channel to see what’s good for a linear conversation that can bounce around versus a linear experience of navigating through a website. So I look—I’m being a little oversimplified—but I look at what the capabilities of the channel are. So then if they each can serve a touchpoint of inquiring about my account balance, I can design those touchpoints in relation to what the capabilities of the channel are.

But they’re not technically the same touchpoint, but it’s the same moment, it’s the same need being met at a certain point in time inquiring about my account balance. And so, am I meeting that with the capabilities of a mobile device, or am I meeting that with the capabilities of a conversation through a phone channel, through a customer call center?

Jorge: One of the ideas that I think is implicit in this distinction is that there are some services, some organizations that are more complex than others, right? They provide services that span multiple channels, right? They might have several different touchpoints that span multiple channels. There are other products, organizations, services that are simpler and maybe are served just through a single channel. I expect that the sort of work that we’re talking about is best put to use in the more complex situations, right?

Chris: Yeah. Yeah, absolutely. So if I were to illustrate that as an example, you could think of a messaging device as being fairly simple. iMessage, WhatsApp, or whatever those are. And that is, call it a channel, you don’t really worry about touchpoints there. There are messages. If I’m designing a messaging app for healthcare workers that are going end-to-end from being in an ambulance with someone having a stroke, to the moment they’re discharged, they’re using the same channel, they’re using a mobile device that has an app with messaging.

But when you are an ambulance driver or the passenger, the other paramedic, and you are needing to send information to a hospital before the patient gets there, that you could define as a different touchpoint. It’s a different need being met at a different time than when I’m a nurse who’s discharging a patient, making sure there’s a follow-up appointment and using the same communication app.

I’m actually instigating actions, and then in between, when I need to tell—when I’m a doctor and I need to tell a nurse to prep an O.R.—that’s a different moment in time. Again, talking about time and space, I’m in a different location than, say, like an ambulance, like the paramedic, and I basically have a different need at that point that I’m designing around the same capabilities of the channel, but it’s a different need. It’s a different task versus if I’m just using iMessage and I’m just sending messages back and forth to my wife. You don’t really think about it in the same touchpoint plus channel lens.

But if I’m thinking about the same channel being used across essentially different needs, and time and space, then all of a sudden seeing the relationship between touchpoints and channels becomes clear. And like you said, the complexity has been raised, so it helps a little bit to distinguish between those two.

Jorge: You introduced a third factor there, which is different types of users, right? The nurse, the patient, all these folks are going to be using probably the same channels or similar channels within the same ecosystem, but they’re going to expect to get different things out of the experience.

The book has the word “orchestrating” in the title, right? Orchestration. And I think that’s a well-chosen word because what I’m imagining is the desired outcome here is coordinating all of these disparate channels, touchpoints, etc., so that they provide for all these users a cohesive experience. Is that a fair take on that?

Chris: Oh yeah. And it’s that simple. It’s not as simple in practice, but the framing is that simple.

Jorge: Simple as it is, the question that raises for me is who in the organization looks after this stuff? Because when I think of design, I think of what most people think of design, which is these are the folks who design the screens that I interact with or whatever. They can imagine that there is a part of the organization that is responsible for managing that product’s user interface or whatever. Who in the organization looks after this cohesiveness of experience?

The Role of Service Designers in Organizations

Chris: So, that’s a really good question, and I don’t know if I have a spicy take on that or not, but I have a point of view. There are a handful, a smattering of organizations that have made sense of this. They may be using service design; they may be using other titles, but they have something akin to journey managers—people who are tasked with looking at that. The key for that to be effective for service design is they have to have some level of responsibility, accountability, or influence, which service designers often don’t have. The role that usually has this influence to direct the work based on what we’re seeing at that sort of journey level, that service level, that orchestration of all these silos, is usually a product leader of some sort.

And so you’re opening up the can of worms, so I’ll just keep going with that. I think talking about service design as a practice has helped to be a part of the design practice, but there’s a ceiling to that. Versus if you hypothetically had service design—whether you called it that or not—but you had the capabilities of service design, that orchestrating and viewing across that certain altitude probably needs to be some flavor of a product role. Because that’s the role that has that.

You talked about how service design has deeper roots in Europe and from a sort of pure, tech and channel agnostic approach in government services and in healthcare. The majority of service designers in the US, I would say above 60%, probably more like 75%, are living inside a design team, a digital product design team, not living somewhere in the org that’s not really about digital products. I don’t want to necessarily call it a survey, but I basically did a LinkedIn search.

And manually counted people who had the title of service designer in the US, and I went about 500 people deep. I don’t know why, I was just very curious for myself, and I found that most people are employed in a digital product organization, whether that’s a pure digital product organization or the digital product unit inside of a bigger organization like a financial services company. Over 70% were. There were three or four big industries like healthcare and government and financial services and insurance and things like that.

But even within those sort of broad industries, the service designers lived inside the digital org. That’s where you start to see people who say, “We have these designers. We know we need to start,”—they won’t use these words, but orchestrating—”we know we need to start making this more cohesive, this chain of the in-person experience with the digital product. We need to start to do that, so maybe we have service designers. Who is our design leader? Okay, you’re a digital design leader. Hire service designers to help us out.”

So that creates a ceiling though because the service designer’s impact more than likely won’t just be on product and service outcomes. They’ll be influencing the work prioritization among what you could call silos. We’re orchestrating this. So in a way, we are then saying these are the opportunities, these are the pain points, these are the needs, and we can help prioritize them, and that should influence your OKRs at the product level and each team that’s responsible for them. That would be the ideal.

But if you’re a designer inside the design world or in the design part of the org, you have a ceiling relative to influencing that. Like I said, some orgs have elevated that accountability, and it’s there. So technically, someone could cite an example where it works, but in general, there’s a ceiling relative to service design’s broader impact across silos or across the organization from an orchestration level. So usually, they tend to focus a little bit more narrowly down, like within a particular team, and then just thinking about what that experience is like within that.

Service Design and Digital Products

Jorge: I was thinking, hearing you talk about it, that many organizations now have— the ones that manage large digital products now have— roles who are either part of the design team or parallel to the design team that manage the design system, right? So there’s this idea that we will bring some cohesiveness to the UI layer of things. And this strikes me as being similar but not limited to UI, rather having its focus on interactions with users independent of where that interaction is happening. Is that fair?

Chris: No, I would say that’s accurate. Yeah.

Jorge: The challenge that I have with the notion of products is that when I think of products, the way that they’re usually structured in organizations, the product team has a scope that is limited to that product.

Chris: Exactly. Effectively their own P&L, right? Whether it’s a feature group inside of a pure digital product, or it’s a bigger team inside, like a large organization like financial services. But we’re dealing with this stuff for checking versus savings and it’s the digital aspect of it. They have their own P&L to some degree, their own OKRs, their own measurement impacts that aren’t usually connected to a greater whole that others are laddering up to.

Jorge: And almost by definition, the way that you’ve been describing it is, the objective here is to bridge these gaps between potential silos so that the experience appears to be cohesive to the end user.

Chris: I’ll elaborate a little bit more in a hypothetical world, a service designer that’s trying to operate at that level, because there’s absolutely opportunities for service designers to zoom in and operate in a service design lens at a product level, you’ll call it, all of a sudden a thesis to be less of a product and more of a component of a service or a portion of a service, but nonetheless, at a lower level. So it isn’t that a service designer cannot have value in and engage in their practice at different levels of zoom. It is just that sort of idealized orchestration layer that is meant to connect silos and create that proverbial holistic and cohesive experience is a challenge.

And in an ideal world, my sort of spicy take is service design doesn’t live in the design organization, it lives in the product organization. When we’re talking about these places that use a product-centric model, like I would love to blow that up, but that’s tilting at windmills. And I say ideally because that’s where they’re gonna have the influence on the work that they’re trying to do in “designing” a cross-channel space and time type of experience that’s cohesive across those silos.

I say hypothetically because even if I could tomorrow do that, I don’t know if I would, because I don’t like how most product management practices operate. If I were to look at product management leaders, Marty Cagan, Teresa Torres, Gothelf and Seiden, these people that really ladder to having like strategy and vision and continuous discovery, there is a massive amount of compatibility with service design. Obviously, they’re looking through a product lens, and we might look at it much more holistically. But the things they want to do when they’re advocating for product vision, product strategy, continuous discovery, really well-laddered OKRs, product OKRs that ladder up and help to unify across.

I can sit there and say read Marty Cagan’s book Inspired, which is this like product management primer, and then go read Orchestrating Experiences to know how to put it back in practice. Because a lot of things he talks about doing is what we expand on, on how to do it. So there’s this ideal world where service design, call it that or call it something else, actually lives in product. And I see what product leaders are saying, and I think there’s this massive compatibility, but I see very few product management practices actually doing what they ascribe or prescribe to do.

They sometimes suffer from having someone who maybe calcified in an older way of doing product management, a little bit more command and control, a little bit more get it shipped, they use words like “break glass” and “bias for action” for kind of excuses to make shortcuts. And that’s a separate role where service design has a PR problem in feeling like they’re slowing the process down, which I don’t believe that needs to be, that’s a framing problem. But that’s back to the product management.

Where I would love to see product management practices engage in the practice in a way that these product leaders are prescribing, and then I would love to see service design take that more orchestrated cross-silo and, for the customer, cross-channel lens, in service to their continuous discovery efforts of uncovering the needs people have and creating hypotheses around how to meet those needs. Doing experiments, but doing it in a way where you’re taking the whole into account and not just the silo into account.

Jorge: The idea that the discipline might be slowing things down resonates with me as an information architect, as you might imagine.

Chris: Yeah, exactly.

Jorge: And I think it comes with the territory of having a more systemic lens in that almost by definition, you are asking folks to aim before firing. So often, the approach seems to be ready, fire, aim; let’s correct course after we’ve released the thing.

Chris: They wanna break glass, we wanna measure twice, cut once. And there’s always this perception of incompatibility there. And the work we have to do is to somehow say we will get to the same outcomes in the same amount of time. Because often when you go through the bias for action, it ends up being a little bit of a shit show and there’s pivots and things don’t happen. And you end up taking the same amount of time as if you measured twice and cut once.

And so there’s a little bit of work to do to talk about how that does not slow things down. Doing some product discovery, service design, discovery, whatever you wanna call it, where the same outcome, getting to an outcome will take the same amount and hopefully it’ll be a better outcome. Those are two parts of that story.

But we suffer from that because service design came about mostly through consultative stuff, right? From Livework and from Adaptive Path’s transformation, that was a little bit more service design. Before it got acquired, it was more of a service design agency than a UX agency, a little bit of both. And so, consultancies always have that baggage of being more research-based and slower and just recommending stuff that may or may not be executed or delivered.

And so, when you have that insight, and a service designer is because they need to make sense of multiple silos, multiple teams, and multiple touchpoints and channels, it’s gonna feel like, oh, you wanna slow us down? And you want to be like an in-house consultant to do this, but we need to ship something this week. And I think there’s always a mismatch there that can be resolved, but it takes some work.

Jorge: I suspect that there might be a maturity model in here somewhere. And there are some organizations that are better served by this than others. The ones that you called up as examples, it struck me that they’re all either highly regulated or regulators, right? Like the government, healthcare, and finance.

Service Design Evolving

Jorge: But I actually want to pivot here. Because you talked about, and I’m going to paraphrase here, but you talked about service design as helping realize some of these directions that are set in the product organization. The book came out in 2018, so it is a book of the before times, right? So both before the pandemic and before AI.

One of the things that stood out to me when I read the book was how you all went to great lengths to spell out how you actually do this work, which can be fairly abstract. A lot of it involved doing things like workshops. I imagine that if you’re working across channels and touchpoints, being out in the world is going to be important for research. How, if any, has the practice changed since you wrote the book?

Chris: I’m not totally sure I have a good answer for that. I think in some ways it’s changing. I don’t know if I have a clear sense of what has changed. I would refer to that ceiling I mentioned earlier. I think it is coming up against constraints where its impact might be limited based on its position in the organization and its perceptions, the perceptions I talked about earlier, feeling more consultative.

Again, this is given that a lot of this is within sort of product-centric organizations. That’s the lens that I’ve always been in. So that’s my service design lens versus being a pure service designer, not constrained by what sort of capability or technology part of the organization you’re in. But in that, I think there’s that limit. You’ve always had this, but I think you’ve realized people have to practice service design in a way without maybe having service design as the title.

I was basically a service designer at IBM, even though my technical internal title was a UX designer. But I was helping design a service for using AI as an agent for a fast food drive-through among other things. At first, I was like, this is just ordering a Big Mac and soda, but once you had to think about the way AI integrated and the sensors for knowing the car had shown up and the way you have to think about when you have to bail out the agent with a human intervention, all of a sudden there was this, again, touchpoints and channels, time and space factor with it that made it much more of a service design problem, which was exciting to me and I liked that.

But so you’re seeing, I think, people feel the limits. I rarely come across service designers that don’t have some of the same frustrations that researchers do. If you’re like a horizontal practice, one of the risks you have is demonstrating your impact in the thing that shipped. Researchers have that issue all the time. What is the through line between the stuff that I did and how you can then see that manifest itself in the thing that shipped? And service designers, I think, have that same problem.

One of the reasons why I’ve often shifted in trying to measure service design impact less in the thing that shipped — you’re always going to have that if you can, but particularly in digital product organizations, it’s harder — and more in the work that’s prioritized. How much are you influencing the work that’s prioritized? Because your understanding of the experience, what people’s needs are, is prioritized in a way to make it more cohesive.

And so when I’ve been in a service design role, I’ve tried to reframe how I’m being evaluated more in the influence of those quarterly or half-yearly prioritizations. Are they referencing the work that we’re understanding? Are they using the principles that, the design principles or experience principles we’ve come up with? Are they prioritizing based on the prioritization we came up with but then mapped with feasibility and technical capabilities? Are we impacting the work that’s being done on that quarterly basis, which is probably more measurable than what’s measurable in the actual thing that’s shipped?

Jorge: My sense would be that if you are working on an ecosystem that consists of different channels and touchpoints, which is by definition the sort of thing that you’d be focused on, there are no such things as quick fixes, right? Like every intervention is some kind of systemic intervention, which by definition is almost harder to measure. Because it’s like, what is the cost of this improvement or this degradation? Perhaps it can’t be attributed to just one thing; it’s a combination of things, right?

The Impact of AI on Service Design

Jorge: You’ve been focused on AI. I recently had a conversation with Jodi Forlizzi from Carnegie Mellon, who is talking about AI as a design material of some sort. And you use this example of an agent for a fast-food drive-through order taking. What is the relationship between AI as a new means for creating experiences and this sort of more ecosystemic design practice? Is it changing how you do the work?

Chris: I don’t know if it’s changing how we do… it might be; I hadn’t really thought about it that specifically, so I might have an opinion on that as I get there. What I’ll start with is again, thinking about the fact that in the U.S. at least, we live in a very product-centric world as far as our organizations are concerned and that lens persists. And one of the reasons, I think in the U.S. at least, but I see this in Europe too, there are these service design roots in Europe, but the things that are allowing it to grow are the same things that are allowing it to grow in the U.S.

And I think that is technology-based. Before we even get to AI, I think technology in general has enabled people to think of technology in a service as this sort of connective tissue, right? The idea you’re looking at something and then the doctor can have an iPad with the patient information on it. And I’ll often talk about a journey. If you look at a journey map, it’s often an illustration of not just the journey of a person, but the journey of information, right? It’s almost equal. That’s really what you’re looking at.

And the journey is usually about how people access and interact with information along a path. That’s almost it. If you look at the quintessential service design challenge of an airport, right? That’s always the easiest thing to see where things have to connect over time and meet people’s needs at different points. You see it’s all about information, and it’s all about when you access that information, what you…

I think another definition of that touchpoint going to earlier is the idea that it’s this information object wrapped in interactions, right? Whether it’s at the kiosk, going through security, wayfinding to get your gate. How do you line up to board at your gate? Scanning the information. All of it is about information and whether you interact with it or not, or at least receive that information.

And that’s a way to get to the fact that the technology has been a connective tissue for services, to take one moment in time and connect it to another moment in time, either because you can move the data there or you can bring the data with you, like I said, like the doctor with an iPad, things like that.

So the AI thing is a component of technology, and it’s the technology that sort of has bolstered the ability for people to look through a service design lens because they have this ability to really create a technology-driven story that’s probably about a bunch of products being linked together through information and the interaction of those informations.

I don’t know if that’s too abstract, but when you get to AI, I tend to see it through Tesler’s law if I’m getting my laws right, that’s the conservation of complexity law, right? Metaphorically, if you think of a balloon, there’s always the same amount of air in there. You squeeze one part, and the other part gets bigger. And, in Tesler’s law, the idea is a system has some finite amount of complexity that you don’t necessarily get rid of; you move it around.

And AI has this promise of taking something that might be more complex, where you’re offloading some of the complexity that a human might have to deal with, and you’re now saying we’ve bolstered the technology now to take that complexity off. AI is like a layer of technology that can do more so that maybe the human can do less. And that could even just be in a quick interaction in a device, or it could be something much greater.

So, I sort of start with the layer of technology being that connective tissue for services, connecting moments of time, touchpoints, and channels, all that stuff. And then the AI is just that technology doing more relative to that conservation of complexity. It’s like we can now move more backstage, so we can potentially create something that is easier for that.

And if I were to try to give an example of that: In healthcare, radiologists look at scans and then they make a report. And they’re very much judged by how many scans they can look at and how many reports they can generate because there’s just a backlog of it, and they’re very critical because these are people who might have very critical conditions like a stroke or something like that.

So they’re using software to generate those reports, and there are things where they can cut and paste better. So you’ve tried to make a report easier than if they just used a word processor. Technology is in that Tesler’s law is acting. You had AI where it can take things that are almost like I always have to do, but it’s always the same. I always have to cut and paste these three things in there, and it’s doing that for you, and you still have to check it. Technology is enabling us and its AI is generating that content. We’re moving more into the backstage to make it there. That’s the same finite amount of complexity to generate the report. We just squeeze the balloon a little bit for the customer, so that the bottom side, the backstage, gets bigger. We’ve moved it.

Jorge: I love that. And I love the phrase “information object wrapped in interactions.” I think it does speak to one of the goals here, which is to provide the right information to the right person at the right time so they can get things done. And, the acknowledgment that in today’s complex ecosystems, the information might be coming at you, or you might be providing it through different means. And, this feels like a way to orchestrate those means so that you don’t make basic mistakes. And one example of that might be, “I’ve already provided you with this stuff, why are you asking me again?”

That’s… and one idea that came to mind as I was hearing you talk about it is that one effect of AI might be to raise the expectations that users have. In a world without AI in it, I think we might be more lenient with services that provide us with these experiences that lack cohesiveness between touchpoints. Whereas now it’s like, “What? Do you mean you’re going to ask me this again? Don’t you have AI?”

Chris: Exactly.

Jorge: Even if the AI isn’t really going to be the one doing it, it might just raise those expectations.

Closing

Jorge: This has been really informative, and I wish we could keep going, but I want to be respectful of your time. Where can folks follow up with you to learn more about you and your work?

Chris: I’m available on all the channels, from LinkedIn to Twitter/X or whatever. I haven’t been doing much lately, but I am going to be self-publishing a little guidebook on crafting and using experience principles. So that’s mostly a self-promotion—keep an eye out for that because I’m hoping in the next three to four months to have that. So that’s probably the next thing you can look out for from me. And that’s it, though.

But otherwise, I’m around, and I’m always happy… I get people randomly reaching out just because they would love to bounce something off me, some advice or something like that. And I don’t want anyone to hesitate to just randomly drop me a line. I’m always happy to hear from people and hear what their work life is like. I think it just always hones my perspective on things to hear what’s going on in other people’s worlds.

Jorge: Thank you for opening that door. This is really important work, and you’re one of the folks who has been writing the most compellingly and deeply about it. So thank you for that, and thank you for sharing with us today.

Chris: I appreciate you having me. I really enjoyed it.