Episode #258 Chris Risdon - Orchestrating Experiences for Complex Ecosystems
User experience, as it has come to be known and understood, is generally associated with the digital space. Designers and developers working in concert to make a site, app, or digital product more usable and well designed. However, a user’s interaction with you as an organization isn’t necessarily confined to just your digital identity. This user experience design can be applied across all channels, such as a call center or physical location.
In Chris Risdon’s virtual seminar, Orchestrating Experience: Strategy And Design For Complex Product Ecosystems, he discusses what it takes to tackle complex systems. He explores the various touchpoints that a customer can interact with over time while engaging with your product or service.
There were many questions from our audience during the live seminar and Chris joins Adam Churchill to answer some of those in this podcast.
- When considering touchpoints, are they able to work together with user stories?
- How do you define the need for a digital versus a human touchpoint?
- How can you get user stories for a product that doesn’t exist yet?
- What approaches can you take for nonlinear experiences?
- How long does this process take to map and arrive at consensus when dealing with multiple stakeholders?
- If you have multiple experiences, how many maps do you need?
- Can the re-engineering of the journey be a valid stage in getting to a service blueprint?
- Have clients ever wanted to take the research and jump in before recommendations have been made?
Adam Churchill: Hello, everyone. Happy New Year, and welcome to another episode of The Spool Cast. Recently, Chris Risdon presented a fantastic virtual seminar for our audience. It's called "Orchestrating Experience: Strategy And Design For Complex Product Ecosystems."
Now that recording -- recording of Chris' seminar -- is available along with about 193 other UX seminars. They're all now part of UIE's "All You Can Learn." It's a subscription-based library that you can actually get your hands on all of those recordings when you need them.
Project work, something comes up and you need to bump up on a skill, or you've got somebody that's on your team that needs to learn a new skill, or how to do something a little differently. They're all there available for you when you need them. Check that out.
On Chris' seminar, our design calendars are becoming more and more complex. Services are more interconnected across channels, both digital and physical. More importantly, one of the things Chris talked about is the cross time and space. In this seminar, he showed us how to make sense of all those moving parts of this increasingly complex system.
In today's podcast, we're going to talk a bit more about it, and address some of the questions that our audience has.
Hey Chris, thanks for coming back.
Chris Risdon: Thanks for having me. Glad to be back.
Adam: For some of the folks that weren't with us for your seminar, can you give an overview on what you presented that day?
Chris: Sure. You sort of set the table pretty well. Over the past four or five years, I had started to figure out, and a lot of us at Adaptive Path, what it looks like to...the maturation of our process as we were dealing with more complicated design challenges, and you said it really well.
We were doing something really good as digital product designers. We were bringing empathy, and design thinking, and an informed strategy around defining the user experience. For us, at Adaptive Path, and for me, in the process tackling, we're doing that in organizations.
We're realizing, "Well, what you did in that group," like the dotcom group, or the user experience group, or the digital product group, "why couldn't you do that for our call center?" That process isn't necessarily a digital centric process, or a physical space.
We've talked about how user experience, as we typically define it, in experience design, isn't confined to digital. It doesn't have to be digital if you go to talks. They talk about digital, and people say, "Oh, it doesn't have to be digital." It's really a more universal process.
The fact of the matter is, it's true, but 90 percent of what we do has still been digital. That's really started to change. We saw this. Organizations were asking us to expand what we were doing out of the dotcom, or the UX, or the digital product group, and apply it to other parts of the organization.
We were still at that ground up, where we were individually applying it. Then we saw, what they started asking us to do, was to say, "Well, now we need all these parts to work together. It's great that you've helped improve our call centers, or improved our physical retail spaces, or improved our digital products.
But now we're realizing your omni-channel and cross-channel and service design, whatever the lens is, we know we need to kind of create this holistic experience."
Really, what the virtual seminar I did was about was kind of not anything new, from a process standpoint. It still talked about research. It still talked about synthesis, and it still talked about understanding the end users are the customers.
With this sort of, "What sort of adjustments can you make, or need to make?" or "What things can you bring in from other disciplines such as service design, or a framework of customer experience, that can help your design process tackle these more complicated systems?"
The nutshell, what it's about, is saying, "Well, what does it look like to tackle these complicated systems?" Also, now that we're having to deal with more moving parts and more complexity, how do we maintain empathy in the face of that increased complexity?
The virtual seminar really wanted to understand the main characteristics of these products and services, or product ecosystems, where that they were basically unfolding over time, and through many different touch points or channels. The idea of the shifting context became really important.
What does it look like if we have greater complexity, we want to maintain empathy with all of these moving parts. We want to understand, instead of thinking about designing static products like someone's going to use an interface when they sit at their desk at work or when they sit at their laptop, with the approach we're planning and designing these experiences when we factor in that they're going to unfold over time and space.
Previously, I had talked about experience mapping. Experience mapping is a great hub tool to get a handle on how your end user or your customer is experiencing your product or service over time. The reason I call it a hub, and what this virtual seminar aimed to do, was to kind of expand the framework beyond just that core methodology.
The basic approach isn't trying to reinvent how we go about doing our work, especially if you're within the field of user experience, when you think about understanding your customers and understanding research. It's really understanding how we modify that approach to handle these more complicated design challenges, that have more moving parts, more platforms or media, more channels involved.
Also more stakeholders involved from the organization, because you might be pulling from different areas like call centers, and physical retail, and operations. This is really a framework that looks to say, "How do we modify what we do?" or "How do we bring in other processes and methodologies from different disciplines, like customer experience, or service design?"
Bring that together to see, "We have more complicated problems. We want to maintain empathy. What does our process look like as we evolve it to do this?" One of the ways I think of it is the fact that I used to, what I still do, I still very much keep experience mapping as a methodology.
It's a great way to articulate insights you have about your end user, your customer. I often refer to that as the hub of empathy and understanding. If you think about it as a hub, an experience map as a hub, I call it a hub because you can move in two directions.
You can move up, and what I say by "up" is you look at the journey and then you can understand how do we want to do processing engineering? How do we want to prioritize and do road mapping? How do we want to martial our resources within our organization?
You can look at these big picture things that affect your organization or affect your strategy for moving forward.
But as a hub you can also move down and take an individual moment from within the experience map and say, "OK, how do we want to design this moment better, this touchpoint?" For example, this conversation somebody's having when they call the customer service center or the experience they're having when they use the mobile phone while they're in the retail store as well.
We start with that. I've taught that a lot, but I really think of orchestrating experiences and orchestrating touchpoints as the full framework. It talks about the research you need to do in order to get a handle on these complex experiences. It talks about not just the experience mapping, but the things you do after the experience mapping, like identifying opportunities, how you envision what the future state should look like.
How you do some process engineering or you want to support the new journey by doing service blueprinting.
Then how do you design for moments, not just design for screens but design for things that are going to probably be cross channel in nature? That might be a screen that also interfaces with the phone or interfaces with the physical environment.
So really, the virtual seminar is about the larger framework within experience mapping lives to think about these more complicated problems.
Adam: Awesome stuff, Chris. Let's talk about some of the questions that rolled in from our audience.
Some of the folks were wondering, how do you socialize the concepts of things like channels and touchpoints in your organization, when those are terms, words, things to think about that you just haven't used before?
Chris: In the case of "channels," it's not that we haven't used them. It's that we've used in different ways to mean different things, depending on the context of our work environment. If we're in marketing, we might mean one thing with "channels." If we're in the dotcom area, we might do other things with "channels."
Both might think of email as a channel, but marketing is going to think about print as a channel. Dotcom's going to wonder if live chat is a channel or mobile is a channel, even though all these things can live together.
Then with regard to "touchpoint," touchpoint comes from really retail and a little bit of service design. It's not something that's used from a traditional user experience standpoint. I kind of see that as a reclamation project, because it's been discarded as confusing, because we often get touchpoint and channel conflated together.
But really, touchpoints are about identifying a moment, like a specific human need in a specific time and place. When you interact with a brand or an organization or a product, whether that's calling somebody through the call center or whether that's getting on your mobile phone, what you're trying to do is deliver to me a specific need for that person at that specific time and place.
That tells you a little bit about the context in which that's happening, so you can understand how to design for that.
Both these things aren't necessarily new, but what we are doing is introducing them so that they feel like they complement each other.
When you introduce that to your organization, the best way to do it is through a couple of case studies, where you can really illustrate, so this is what's happening. Here's a touchpoint. This is a moment where some persona like John is trying to get this down. That's how we define the touchpoint.
Then here are the channels that actually are involved in supporting that. They get on their mobile phone. They get on the website a little bit. They find something and then there's a link that allows them to dial right up and call or something like that. These are the things that define what you can do to meet or to deliver on that moment or that touchpoint.
To introduce them, you're not necessarily introducing completely new concepts. I think you're more level setting, so that everyone has the same sense of definition of what those concepts mean.
Adam: Say more about touchpoint. There seems like people are talking about user stories and Agile in their design process. Does it get confusing when now we're talking about touchpoints? Are they things that work together or is there actually a conflict?
Chris: They don't have to be a conflict. A lot of that depends on context, but it's interesting that you bring that up, because I often use when I'm trying to define like, "This is what a touchpoint is," I use Agile user stories as an example. Because I said earlier that a touchpoint is really an interaction that involves a specific human need in a specific time and place.
Which means that I might be Chris that needs to do X for Y reason. That's sort of the anatomy of a user story. I'm somebody who needs to do something for a certain reason. I try to make sure people can understand touchpoints by using that familiar analogy.
But they can be different, because touchpoints are usually looking at kind of a "macro moment," meaning it might be a moment that's not limited to the screen. It might be something where I need to be on the computer, but then I need to get a text message to do some two step security, so that's another channel involved.
Then I need to get back on to the computer.
User stories are typically going to be in a development environment and thinking about the screens and thinking about the features.
There are two ways to go about it. You might just need to start at the macro level and your cross-functional team that's going to be more than just developers and designers can think in terms of touchpoints. We have a moment here that we want to design for, and that's what that touchpoint is.
In my graduate, it's the same. Now that we're dealing with these specific screens, we might translate that into very specific user stories and epics that are another part of that environment. Or, you call them whatever you want, if it's easier to essentially think about it. I'm not necessarily an advocate that you have to adopt the vocabulary of touchpoints.
If you still largely work in a digital environment and you don't have the same cross-functional...I guess you could call it "language barriers," where you want to have everyone have a shared frame of reference. Then call it a "user story" and think of it in those terms.
There's one way, depending on the context of whether you're starting at a very broad cross-functional group and so, touchpoint and thinking about those moments that can be multi-channel in nature and thinking about those. Later, when you're dealing specifically with the screens, translating to touchpoints.
Or if you're digital and just staying with user stories and just thinking about those specific needs at those specific points and times. Either way can work depending on the organization.
Adam: In this process, how do you define the need for a digital versus a human touchpoint?
Chris: That's a good question. A little bit if you do your research and you look at your customer insights. What you'll see is when people are using which channels? Are they talking to a person over the phone? Are they talking to a person in a store or at a front desk? Are they on a screen?
You have remote agents, so you might be talking through a video channel on a phone headset. It's both a digital channel while also being a human touchpoint.
The old way of thinking about touchpoints, the more branding and retail way, was thinking of touchpoints as three different things. You could have a static touchpoint, which would be like advertising or packaging. These are things that you don't interact with, but are moments you come in contact with a brand or an organization or a product or service.
Then you have interactive touchpoints, and that's very clearly like websites and kiosks. You have human touchpoints. That could be a call center. It could be going to the Apple Store and talking to a rep or a genius or something like that.
I didn't think that that really told us much about what need needed to be met and what context was happening by the fact that I was talking to somebody. Versus if I call up a phone center and I want to transfer funds from one account to the other or I call up and I want to close my account, those are very different touchpoints.
Because those are very different needs that might be happening in very different times and places, or at least in very different contexts.
I really didn't worry about defining touchpoints, whether they were a human touchpoint or a digital touchpoint. I might sit there and define that it's on a digital channel, like on a screen or it's in a physical channel, like in a store or it's on a phone channel, but the touchpoint itself is really about the human need of, like, "I want to close my account" or, "I want to transfer funds."
Then I'll look at what I have at my disposal to support that. Is there a human element or is there a digital element? Is there a physical element? I'll define it that way.
It's less about defining human touchpoints versus digital touchpoints, and understanding that touchpoints around the human need. The channels are really what you have to support it. Those could be human. Those could be digital. Those could be physical.
Adam: I know this is a tricky one, but how do you get user stories if you're building something that doesn't yet exist?
Chris: User stories are defining touchpoints to find specific moments when those moments don't exist.
What you really do then, what your journey should look like, what you're researching is the current state. What you want to do is research what life is like without it. Look at something like an Uber. What is the journey for people to get from point A to point B through the traditional cab system? Whether they call somebody or whether they reserve it online or whatever it is.
You have touchpoints that don't exist, because those are touchpoints that Uber has, like interfacing with the screen and seeing where your driver is on a map or rating your driver at the end. Or the absence of touchpoints, like I don't have to worry about paying my fare at the end of the ride.
What you're doing is you're going to start by looking at the current state journey. You're going to then see what those gaps and those opportunities are where you can fill in a role. You are defining new touchpoints. But what you're going to do is identify either touchpoints that need to change or touchpoints that need to go away or touchpoints that need to exist that don't exist when you look at the current state ecosystem.
We're big fans of ecosystem mapping, which is the idea of really uncovering all the moving parts that influence your product or service, particularly when you're introducing something new. That could be...I'll use Uber as an example. It's like what are all the things we have to think of? Sure, we have to think of drivers and cars, but we also have to think of municipal regulations.
We have to think of parking. We have to think of re-fueling. We have to think of all these things really exhaustively to understand how they influence our potentially new or innovative or disruptive service that doesn't exist yet.
That's going to reveal touchpoints that you didn't virtually even know existed, even when you were thinking about doing this, you have to uncover them.
There is a point of looking at the current state of the ecosystem. Under covering really what the touchpoints are and understanding how those change when you want to introduce your new ecosystem. It's almost metaphorically like an overlay. You have a current state and you're overlaying a new state. So you're going to be looking at, "OK. These touchpoints match. In the new system and the old system, this touchpoint still is going to exist."
People are going to still have to call somebody up or something like that.
"Here's a touchpoint that goes away. I don't have to pay for my cab fare at the end of the ride." "Here's a touchpoint that needs to exist. I have to enter my card to be a part of this service before I get started." So you kind of overlay where things are duplicated, where they're going to change, and where they either go away or are introduced as new.
Adam: Any experience or thoughts to offer when teams are representing nonlinear experiences?
Chris: If we think about an ecosystem map, which is one of the early discovery activities we often recommend, where we, like I said, "unsurface" all the moving parts. Those are very nonlinear in nature. We just care about uncovering something.
For example, in a workshop, one of our case studies is a car dealership. Rethinking how car dealerships need to evolve. To your previous question, what does it look like? A new service that would be on top of this.
We have to uncover everything, from the lot and sales people to third party things like insurance and financing and all these things that involve the cars themselves, test drives. When we do that, we don't care about the linear nature of it at this time. We just care about uncovering it.
It's one thing that's a good place to start when you already know that you might be thinking of a nonlinear process.
The second thing is when you do experience maps or customer journey mapping, we care about time, because it's linear in the sense that time is always moving forward. It's not linear in the sense that you have to go back and do something or you might do multiple things over and over again.
One common example is research. Let's say I want to go on a trip. I'm going to research for one week. I'm going to research for three weeks. I'm going to go back to blogs. I'm going to go back to Facebook recommendations or whatever it is. That's in a sense nonlinear. But in a way, it's still always going to be linear, because it occurs over time.
Time is the linear aspect of a customer journey map or an experience map, but it doesn't mean that visually you don't tell the story by showing certain things repeat themselves or people go back in processes or people hit dead ends and then they need to fork into another path.
There's sort of that creativity of saying that this doesn't necessarily have to be represented as a point A to point B to point C type of journey. It can be a journey that is generalizing all the things that may occur in time. It definitely...You can have things that one person wouldn't do, but you might represent both, like, "I'm going to call customer service and I'm also going to talk on live chat."
Your journeys that you have may not say like people do both, but you might represent both in an experience map to show that they both could occur.
The linear nature...I talk about being linear, but I think it's a good point, because it isn't to imply that things have to happen in a sequential order. Things can happen in any order and be redundant and duplicative, but the linear part comes from the fact that they do occur over time in that sense.
Adam: Chris, we have some questions. There are obviously some teams that are thinking about how do I take this idea that Chris is sharing and put it in our existing process? One was about time. How long would this end to end process with multiple stakeholders involve take to map and get agreement, come to a consensus on it?
Chris: There's the proverbial "it depends" as far as the qualifier that I know I'm sure in every interview you get, you talk to US people, they always say those about five times in an interview. But to give some examples, if you're just pulling out, say, the experience map. Like I said, that's kind of a nice hub, because people can rally around that.
It's a good excuse to get a cross-functional group in the room -- IT, marketing, UX, if they exist, the call center or the physical operations or talent, people that are hiring the staff, things like that. That's one of the reasons I refer to it as a hub, because it's this good starting point. That can be something that can take anywhere from three to six weeks.
Sometimes for really complicated stuff, maybe up to eight. But you really are talking less than a month and a half really to do the research and get the inputs you need for those experience maps, which is really articulating insight. Then make some sense of that and use that in some way.
That's not too big of a lift for most organizations if they buy into the idea of that cross-functional collaboration of getting what you could call this "holistic insight" to how those product ecosystems or those services are being experienced across touchpoints and across channels. Not just the screens or not just the call centers.
But if you really look at the whole process, which could include a certain amount of research, it includes really exploring what the ecosystem is, what all those moving parts is. Collaboratively getting those insights together through an experience map. How you then identify the opportunities or the pain points and really prioritize those and road map those as far as what you're seeing in those insights.
Envisioning what the future state could look like. We want to affect these moments or these touchpoints along the journey. We want to improve them. We want to redesign them. What does the new journey look like? That can be our north star. Can serve as blueprinting, which is a way to really show what are the people and the processes and the technology we need to support our future.
Then actually going in and designing those touchpoints. That's hard to put a marker down, because these usually become extended programs. If this is done well, that's actually a good thing. It's like, "OK, the feedback of prioritizing and road mapping, you might create a six-month road map or you might create a two-year road map."
But if you start with the idea of identifying and prioritizing what you should do, so the research, the experience map that articulates those insights from the research, and identify what that experience map is telling you that you might want to change or improve on, that can probably be anywhere from a five- to an eight-week process.
Obviously, what the lift is to actually make those improvements, road map them, understand what order or what you need to do to actually have them, it goes in a cyclical iterative cycle, just like a lot of things do. That's going to vary completely depending on the context of whether you're a small company and pretty much just a digital ecosystem or you're a ginormous financial services institution or healthcare institution that's going to have a lot of moving parts to align and get in place.
Adam: How about quantifying it? How many maps does a company need? This particular team was asking how many maps a company has to have with different experiences. Do you split those up by the different personas the design teams are working with?
Chris: Yeah, there's no set number. You don't want too many, just because you start to lose a real sense of focus, because there's just going to be more than you're going to be able to address.
But it's good to recognize that, what I'm not advocating, I don't think anyone at Adaptive Path's ever advocated it's like you don't need "a map." Sometimes you might start with a map and sometimes you might need two or three maps. It's going to be dependent on context of do you need to separate say, the journey of the customer from the journey of the employee?
Those could be separate maps. Or you have very distinct personas that go in very divergent paths or are using a separate product or service from each other, so you might have two or three maps there. You might even have four.
Once you get to, if you have so many personas that you have like six or seven or eight maps, then what I would do is I'd find ways to consolidate it. Like these two personas had enough in common that they could be represented with one map. Because once you're trying to produce that many maps, they sort of lose their effectiveness.
That ability to say, "We can put these on a wall. We can look in, get a shared sense of what the insights are. And we can pull the same things out of them and get a plan of action for addressing them."
But we've often done somewhere between two and four maps, depending on the context. They can be maps based on breaking up the stages, like here's the on boarding process, and that's a separate map, because it's complicated enough. Here is the service delivery part of it. And that's a separate map.
It could be about chunking up the journey to make sense and communicate in different ways. It could be about divvying it up by persona or by some sort of use case.
Then sometimes we like to actually overlay them. If it's really where the personas go on the same journey, essentially. They interact with the same touchpoints and their perceptions of them, whether they're a business customer or a consumer customer are different, then it could be interesting to overlay those journeys on the same map.
It's really going to depend on the context of what you're trying to get out of it. The best lens to start that thinking is probably going to understand, "Well, why do we want an experience map? Why do we want to do this?"
There are really three things you should look at. You might really care about one of these things or you might care about all three of them, but one is the organizationally, like what we have to understand is where do we need to marshal our resources? Do we need more people here? Do we need less people here?
How do we need to transform our organization to make it sustainable? How do we lower some silos so we're communicating better? Are we doing this map for organizational purposes? Is it strategic purposes?
We need to identify where the problems are or where there's some unmet opportunity is. Road map them and service blueprint them so that we can actually implement the changes that we're seeing on the map.
Or is it sort of design guidance? Like we want to take certain moments of the journey and say, "What is it that we should understand about this when we improve it or redesign it?" Is it that it should meet certain design principles or meet certain metrics?
Organizational, strategic, or design tactical, you'll look at those and a lot of those things are going to help you determine how many maps you need and split in which different ways.
Adam: Can you talk a bit about blueprints? A question came in, "Can the re-engineering of the journey be a valid stage in getting to a service blueprint?"
Chris: Yeah. That's an interesting question. I'm not totally sure what it means if you are re-engineering the journey or are using the journey as a step to the blueprinting. It's definitely the latter. We see blueprinting being a great activity to come after the journey.
A lot of people ask about future state experience maps. You can do future state experience maps, but I personally have not been a big fan of them. I found that there's qualitatively better ways to represent the future. Because when you have an experience map, you're showing how your product or service is being experienced.
Obviously, you're going to have highs and lows. "I really like how that conversation went with the call center" or, "I really hated how I couldn't recover my password on the screen." So your future state is where everything's going to be great and everything's going to be high when you look at the data visualization of an experience map.
That's one reason I'm not a big fan of future state experience maps. Whether you do prototypes or whether you do storyboards, there's better ways to visualize how you want bigger future design to be experienced and how you intend it. Like if we do this, this is what the journey will look like. That journey could be a five-panel sketched storyboard or it could be a set of screens or whatever it needs to be.
Where I think if you really look at the journey level of the future state, service blueprinting is where you really want to think about the future state. Service blueprinting typically can look like a process flow diagram, but it doesn't have to be contained in that.
But why I say that is because you can think of it metaphorically as a bunch of boxes you can move around. You can say, like, "If we change this one interaction point," then you might want to blueprint what's involved in that interaction.
Like what people are involved, what technology is involved, what process happen, like fills out an application and a person in the back reviews that application. Then they enter it into a database. All these things go along to support that interaction.
That's where I think you really care about looking at the future state. You can almost use service blueprinting as kind of a prototyping tool when you're prototyping processes and flows. It is good for process re-engineering to think about the future state through the lens of a service blueprint instead of the lens of an experience map.
Adam: There's a question that came in about a challenge with clients. Have you ever run into a situation where they've wanted to take the research findings and sort of run with them before the recommendations have been created in more of a team environment?
Chris: Yeah. This is a problem that can be persistent outside of this orchestrating experiences or experience mapping kind of framework, is people want to look at the data that hasn't been synthesized yet. We haven't found connections and patterns and themes across inputs, across voice of customer, across web analytics, across usability studies, across just even customer interviews for how they perceived their experience or their journey, so to speak.
I had a colleague, Todd Wilkins, used to have what we called "Wilkins Law," which was that the value of research is inversely proportional to the size of the binder it's contained in. Which is a fancy way of saying that a lot of executive stakeholders think that they're paying -- whether it's internal and they're paying through resource allocation or its external -- for a giant binder with lots of data points.
When really what's more valuable is a thin binder full with really crisp insights. In many ways, that's what we try to get through with an experience map is what you have. An experience map is usually accompanied by a proper research report.
But from a socializable way of getting insights across, it's one document. It can be a dense document. It can be a dense...we make these large. We make them four feet by three feet, so you can put them on a wall and actually use them in workshops and use them as tools. They can be dense, but they're also very concise, because they're the insights and not simply the data points.
We hope that that one reason you can use an experience map is you can use it as a tool to bypass the idea that some executives are going to say, "Just give me that thick binder full of data points." You're hoping to have like how can I make this something that's more valuable by being more concise and not ironically thinner, so to speak, metaphorically thinner by not being a thousand data points. Instead being a dozen key insights.
You hope that people buy in to the process that they don't co-opt the research data, that they're along for the ride and buy in to the process because hopefully they're involved, that don't get to the more crisp and concise research insights.
Adam: Great stuff, Chris. Thanks for giving us some more of your valuable time.
Chris: You bet. Very appreciative of you having me again.
Adam: Any time.
For our audience, remember that you can get at Chris' virtual seminar and over 190 other awesome UX presentations at All You Can Learn. Thanks for your support of the virtual seminar program and good-bye for now.