Transcript: Ask the UXperts: The simple philosophies for successfully delivering complicated experiences — with Patrick Quattlebaum & Chris Risdon

Show time

First up, welcome to everyone that’s here.

And a huge thanks for @risdon and @pq185 for giving time and wisdom today so that we can learn

Chris and Patrick crossed our path recently when they published their new book https://rosenfeldmedia.com/books/orchestrating-experiences/

Excited to be here!

Hi everyone!

Luke wrote a review of it here: https://uxmastery.com/book-review-orchestrating-experiences/
He’s a huge fan.

Formal intros:

Patrick Quattlebaum is a designer and teacher who gets up every morning to bring creativity, rigor, and humanity to problem-solving. He is the co-founder and CEO at Harmonic Design, a consulting firm based in Atlanta, GA, USA. Previously, he was principal designer at studioPQ, Managing Director at Adaptive Path, and Head of Service Design at Capital One.

An expert in design strategy and service design, Patrick places a premium on pushing design practice to be more value-centered, collaborative, and iterative. He and his co-author, Chris Risdon, share their design philosophy and its practical applications in Orchestrating Experiences: Collaborative Design for Complexity.

Chris Risdon is Director of Design for a peer-to-peer carsharing service, Getaround, and co-author of the book Orchestrating Experiences: Collaborative Design for Complexity.

Previously, Chris was Head of Behavioral Design for Capital One and a Design Director for Adaptive Path, the pioneering experience design consultancy.

Hello!

Chris has introduced and advanced new methods in design, teaching thousands of design professionals and students. With a focus on designing complicated services and behavioral design, he has been published in a number of blogs, journals and magazines, as well as contributing to a number of books and articles. He’s spoken and taught workshops at conferences such as SxSW, UX Week, and IxDA’s Interaction Conference.

And now I’ll be quiet and let the UXperts speak. Can you give us an intro to the topic please?

Happy too!!

The book we’ve written is fairly comprehensive.

I don’t think we set out to make it so — we were after solving 3 challenges we were seeing in our work.

Across our time together at a couple consultancies, plus in-house at a large financial institution…

First, we noticed more than ever, good design at companies was a team sport.

Specifically cross-functional. People were in rooms together, who weren’t normally in rooms together, trying to figure out hard customer/user problems. Not just IT, UX, Product, but operations, customer service and other functions across the org.

So the first challenge was the challenge of working collaboratively in this new world — particularly where these groups of people didn’t share the same process or language, etc.

Not to mention work should be fun!

The second challenge we saw was what we were actually designing for. Moving from *just* single touchpoints — say, a single digital product. But instead for *experiences* that spanned time, space, and most importantly different touchpoints and channels. Call centers, digital products, physical environments.

So we had more complicated experiences, with a collaborative cross-functional teams — those were the first two challenges. Once this group was in a room together solving for these complicated experiences, it brought about the third challenge we wanted to address in the book…

The tools we use. We needed new tools, or to adapt the tools we use, or socialize existing tools with our new partners.

By tools, I mean the methods, or process, or ways we approach solving for various parts of the problems.

We wanted to address those three problems – and as Patrick chimed in — this needed to feel like a fun, rewarding, way to work, or it just wouldn’t stick.

The companies I’ve worked with talk a lot about being collaborative, creative, and customer-centric… and about solving complex problems. But., they aren’t very good at.

The hardest part was deciding what to include and what not to include, because there are already so many good approaches to solving various challenges in the design process. Determine what to highlight that specifically address those challenges of cross-functional teams, working collaboratively with new shared tools to solve those complex experience challenges.

They just don’t know what it looks like.

Orchestrating Experiences is about changing how we work together and changing how we look at what we are designing together.

Relatable

One thing I think both Patrick and I are most proud of is, even though there’s a lot of content there, we specifically made it practical — we’ve included specific workshop guides so people can go into rooms with these teams and feel armed with how to facilitate and meet team objectives.

Yes. There are many example of deliverables and artifacts, but our goal was to help you get people in a room (or virutally) and work on these challenges together.

I just stepped out of workshop for this chat in which 10 people from different functions are collaborating for how to create a new service and they need to work differently to pull it off.

We frame any artifact not as a deliverable, but as a tool, and specifically seek to have anything we make (experience map, service blueprint, storyboards) be intended to use as a working tool.

Yes! The workshop I just mentioned is using a journey model to plan out how they will each contribute to each customer moment and the intended outcomes.

How they are making meal together, not each bringing something to the pot luck. :slightly_smiling_face:

The image Patrick posted above — of an experience map with the stickies on it — is an example of this. When we created it, we specifically went through a working session to align on what the opportunities were and what principles should guide different steps in the journey.

@risdon – It seems like getting everyone in the same room together for a workshop when working on complicated experiences with a collaborative cross-functional teams seems like the key ingredient to success. I wonder if you could achieve the same success when you work with cross-functional teams that all live remote in different cities… :thinking_face:

Ok – question time! Shoot…

One thing to mention, we specifically wanted to blur the lines between UX, Service Design, and Customer Experience — all have influenced us and have important meaning and roles. In the case of this book, we just wanted to help designers of whatever tribe put these principles into action regardless of affiliation.

And beyond designers. The goal was to propose common frameworks and language for the organization to truly collaborate around the same outcomes for customers, employees, and the business.

Let me see if I’ll do this right…

@sarah.johnston asked… It seems like getting everyone in the same room together for a workshop when working on complicated experiences with a collaborative cross-functional teams seems like the key ingredient to success. I wonder if you could achieve the same success when you work with cross-functional teams that all live remote in different cities…

The short answer yes! It can be a challenge, but definitely doable. We’ve set rooms up to help teams see each other, and had a home-base where the workshop was being facilitated.

One of the keys is for remote participants to be prepped to still don some hands-on activities — such as writing things down on stickies.

joining in from Amsterdam, been a while since I attended these talks :slightly_smiling_face:. @risdon @pq185 you mention you encourage the use of your artifacts as tools. How do you ensure these deliverables are actually used in the further stages of a project, i.e. the delivery phase?

Do you use any collaborative software/apps to help facilitate workshops?

Another are tools such as Mural (http://mural.co) and other virtual whiteboards, that allow collaboration.

When I’ve done any kind of experience mapping in the past it’s always been with a particular user in mind that’s been backed up with qualitative research. If that kind of research is missing, and all we have is anecdotal experiences with the user is there any value in doing a service blueprint or journey map?

@glennveugen First, we put a lot in the book, but we don’t prescribe that everything we cover needs to be in every project. So first is to make sure you’re only doing (and creating artifacts) that are needed. When someone says, we should do a journey map — ask what the purpose is for? Is it for organizational planning?

@risdon @pq185 the biggest challenge I have at my company is getting stakeholders time and energy. What are your key tips for getting buy in across the organisation and linking these workshops to financial kpis?

Or to understand the experience?

@glennveugen you mention you encourage the use of your artifacts as tools. How do you ensure these deliverables are actually used in the further stages of a project, i.e. the delivery phase?

Often, the artifacts are tested out as a tool before being completed. It’s basically usability and usefulness testing. With experience maps, I often make an initial version, use it in a workshop, refine it, and then distribute with instructions on how to use in strategy and design activities. Testing it out also is a way of teaching people how to use them.

Or to align people to get buy in on doing additonal work. When you determine that you can plan ahead on how you will use it as a tool to be a catalyst for the next steps.

@glennveugen you mention you encourage the use of your artifacts as tools. How do you ensure these deliverables are actually used in the further stages of a project, i.e. the delivery phase?

The other appraoch is to create living documents rather than static ones. I’ve been experiement with digital tools that position blueprints or storyboards as objects that dowstream requirements and design artifacts are connected to.

@hello207 When I’ve done any kind of experience mapping in the past it’s always been with a particular user in mind that’s been backed up with qualitative research. If that kind of research is missing, and all we have is anecdotal experiences with the user is there any value in doing a service blueprint or journey map?

To answer your question @hello207…

@risdon you said earlier “We frame any artifact not as a deliverable, but as a tool…” could you elaborate on that idea a little bit more, please?

Re: Service Blueprint — yes! Service blueprints aren’t qualitative…they are about what are the processes, people, technology, to support a service. You can always do those, without research.

Re: journey/experience map @hello207 — it is more of a challenge. What you can do is create a “proto” journey map — one framed specifically being from internal knowledge, but not fully fleshed with the qualitative and quantitative data you might need.

And then you use that proto-map to highlight gaps in knowledge, and possibly get buy in to do focused research in that area.

@zimmerman1181 you said earlier “We frame any artifact not as a deliverable, but as a tool…” could you elaborate on that idea a little bit more, please?

@hey the biggest challenge I have at my company is getting stakeholders time and energy. What are your key tips for getting buy in across the organisation and linking these workshops to financial kpis?

When a culture is not used to collaborating, workshops can be challenging. It’s like going to the gym for the first time after sitting on the couch and watching TV for year.

With workshops, you have to design the experience before, during, and after to carefully set expectations on the benefits of blocking out a day and getting away from their devices. You have to ask for feedback throughout the session to ensure people are having a good experience. And then gaving participants help spread the word that’s it worth the time.

I’ve not had to develop specific KPIs. Typically, the word of mouth after a well designed workshop helps get more people interested in being in the next one.

To piggyback off of this comment, any collaborative software/apps that might help facilitate workshops for remote teams?

I mentioned a bit above @zimmerman1181 — but it’s planning ahead to determine and get alignment on why *exactly* you want to do an exercise that will produce a specific deliverable (why a persona, why a journey map, why a service blueprint), and once you know that, you can plan ahead what type of working session/workshop you might do once that’s produced in order to drive the next phase.

To the above point, I work closely with engineering folks, and encounter sometimes severe cynicism or resistance to these types of show-and-tell exercises. Some will hate you for forcing them into any new bureaucratic process, they feel are a waste of time thereby undermining your future good will to GSD. How do we demonstrate ROI, or make the case for participation. Does it have to be top-down?

An experience map can help determine where to prioritize opportunities, or define experience principles which will guide new solutions — so if you know your producing an experience map to be a catalyst for those things, you’re using that map as a tool.

@zimmerman1181 you said earlier “We frame any artifact not as a deliverable, but as a tool…” could you elaborate on that idea a little bit more, please?

Often things—maps, blueprints, storyboards—are made to document previous activities, but they are also props to engage stakeholders in downstream activities. So, you have to think about not just how the artifact is used to understand previous thinking, but also as a way to support the next steps of design process.

@harpo – to your question about resistance, it’s a good point. We definitely can’t prescribe a silver bullet for getting buy-in. You have to have people that are at least *a little* receptive to the idea of doing new thins in new ways to get to better outcomes — similarly when teams want to apply new approaches, like Lean, or Dual Track Agile, or JTBD — all new approaches that require buy-in.

@risdon @pq185 Have you found that you can apply experience mapping across orgs in all industries? Would it be specific/unique to that industry?

e.g. Non-profit would be different than Oil & Gas corp.

@harpo I’m having the same problem at my organization… but it’s not just the devs, it’s the product owners that are driving our UX projects that don’t see value in workshops like these. They think it’s a waste of time unless additional requirements come out of them that they haven’t already documented from their “research”.

But, it first has to start with conversations, and then ideally doing something really small, but with a measurable outcome. But I also try to develop a strategy for getting buy-in, give myself a timebox for seeing some results (say 6-9 months, since things can move slowly), and if I don’t get traction, I get a sense of whether this org will ever change. Sometimes change is just slow, other times its hard, and other times it just won’t happen.

@harpo To the above point, I work closely with engineering folks, and encounter sometimes severe cynicism or resistance to these types of show-and-tell exercises. Some will hate you for forcing them into any new bureaucratic process, they feel are a waste of time thereby undermining your future good will to GSD. How do we demonstrate ROI, or make the case for participation. Does it have to be top-down?

To some degree, top down helps not in any particular instance of collaboration, but culturally in that each discipline should be experimenting with its practice to find new ways to be more effective and/or efficient. If there isn’t support/expectation of continually improving how you work, then you do risk resistance when you try to.

The other thing to keep in mind is to be clear about which methods are to support what outcomes. To zoom out and look at the journey of the customer when the product team focuses on one small part does require the right buy in for the value of zooming out.

@harpo if you work in a product-centric environment, then the most important person to get buy-in from is your product manager. If you can find something small, but with a measurable outcome, then they will often buy-in.

@dave Have you found that you can apply experience mapping across orgs in all industries? Would it be specific to that industry? e.g. a non-profit would be different than an Oil & Gas corp.

Experience mapping is a very felxible approach that is about experience over time. As long as you have a person who experience crosses channels and touchpoints and whose context is greater than just the product or service (it always is), then experience mapping can be valuabel exercise.

@dave Have you found that you can apply experience mapping across orgs in all industries? Would it be specific to that industry? e.g. a non-profit would be different than an Oil & Gas corp.

I think yes, it can be — the key is if there’s a journey to support. For example, pure digital products that want eyeballs — like Twitter, or Slack, etc. — may/may not need a journey map. But things that have operations, or an array of touchpoints (digital app, website, mailed bills, customer service) often can benefit from understanding the experiences people have with the product/service over time. It may not always feel like a linear journey, but it can benefit mapping out what people are thinking, feeling, and doing at different times.

We’re at the end of the question queue. Keep ’em coming.

@risdon I agree with the methodology, I think it’s a positive net result. Just wondering if there are studies that prove it changes culture, in terms of either employee evaluation, or just bottom line profit, or shorter time to market. Thank you for your tips and presentation, good food for thought

@risdon – if you ever discover a silver bullet for this, I’d love to know! :wink:

One way, from a UX perspective, is to think about empathy maps — which can often help understand what someone is experience at a certain moment or environment…

Once you know you have many of these (when someone onboards, when someone pays a bill, when someone calls, when someone checks out on the app), you can imagine having some understanding of this string of empathy maps to tell a larger story.

I think workshops should be part of the research, I’ve had experiences where admins and other professionals, share their experiences with much greater details in group. I think is because people like telling stories.

Love that everything discussed is pure design thinking

@pemarroquin yes, and it’s also about systems thinking.

That’s a good question @harpo — I don’t have any studies on that. I have found people love working with each other and enjoy breaking some silos, but no specific studies. Related, there is a book called Outside-In, focused on Customer Experience, that does cite studies showing customer-centric companies do better on the stock market. I cite that a lot for evidence of being more human-centered.

@pemarroquin when you start digging into ecosystems and organizational culture, you’re really going beyond design thinking and crossing over into some other methods and toolkits.

One reason we’re a fan of the journey framing is because it can be this hub of empathy, understanding, and strategy — we have found that different parts of an organization are experts at a distinct part of the system/experience, but everyone lacks a holistic view. When you get people aligned on a journey, they can see the whole, and how their part is connected to, and influences, the other parts.

Outside In –> https://www.amazon.com/Outside-Putting-Customers-Center-Business/dp/1491514221

That will lower silos just a bit.

That’s interesting! @pq185 the need of both worlds so the output’s quality can be assured

Then when you’ve aligned on what people are experiencing — what people are thinking, feeling, and doing — across that journey, you can zoom in — design a specific touchpoint with better understanding of context, and how it’s connected to what happens before it, and after it…

Or zoom up, and have more insight to help planning, roadmapping, having conversations with parts of the org for solutins that are dependent on each other, or start to transform/change the org.

Depending on what area of focus you are responsible for.

What hasn’t come up yet, is downstream — really getting a shared ‘north star’ — as people need to go to their silos to execute, if you all share in understanding what future you are heading towards, you can make better independent decisions as you go to your respective areas to execute.

levels of zoom is a powerful conceptual model we talk a lot about in the book. our former colleague, Brandon Schauer, wrote a nice medium post about the topic. https://medium.com/@brandonschauer/design-leadership-tricks-zoom-out-1x-33017513c650

I can imagine that sometimes bringing cross functional teams together to collaborate could result in frustrations. e.g. “the developers aren’t really listening to me”. Is the outcome of this kind of work always positive in your experience?

Nice question @hawk If you start asking people to show up to working sessions without getting buy-in or prepping them for what the larger purpose is, then you can really have a negative experience.

One reason to start small, you can tackle principles and activities from the book in as little as two weeks.

@hawk it’s a bell curve with participants. not everyone is an innate or positive collaborator. so you always run into some friction. In the grand scheme of things, collaboration as a skill is more and more expected in organizations. You have to push against the business as usual and keep modeling how we should work. it will be good for your career.

Ok everyone, we have 5 minutes left in the session! (Where has that hour gone?)
Any last questions? Now’s your chance…

@hawk the other thing to keep in mind that collaboration and innovation require different people to participate. it shouldn’t just be product and developers. experiences are bigger than product and technology so it’s best to have other functions involved.

There are also ways to bring people along for the ride. I have been surprised how many developers ask to sit in — as a notetaker — on customer interviews. If they have zero interest, that will tell you a lot. If they are interested, then that’s a great first activity for them to get exposed to this part of the design process, without really affect anything in their day-to-day work.

How would you recommend bringing cross-functional teams together when those teams work remote in different cities? I feel like that adds to the challenge significantly.

Good question!

My org is fully distributed

Thanks for your insights! I was wondering if you have any book recommendations on this topic. Thanks!

What kind of expectation setting do you do or “pre-work” do you have folks do prior to workshops?

It is definitely a challenge @sarah.johnston — it adds to the difficulty. One way I have started small is to use a tool like Mural to do sprint retros — it gets everyone used to collaborating on a document (or in a virtual space) together, instead of editing a Paper/Google doc, or watching someone update a Confluence page…

@sarah.johnston video meetings with screen sharing is a key. having facilitators in each location also helps. also having people work on paper tools and then sending to one location to print and display; or using tools like Mural for building things together.

Also, like others that have mentioned in this thread, in addition to dealing with the challenge of working with cross-functional remote teams, I too am dealing with resistance with getting stakeholders to participate in collaboration activities such as workshops. Our product owners think workshops like journey mapping and especially empathy mapping are a waste of time :disappointed:

As they do something small in that virtual space, it won’t be so abstract to say you’re going to review a journey map there, and everyone will label what they see as an opportunity area, and then to do a prioritization on opportunity areas (as an example of something I’ve done recently)

@sarah.johnston
REMOTE WORKSHOPS
Before moving on to the last workshop of the book, I’d like to put in a good word for remote workshops. While it’s more effective to get people in a room together to collaborate, your timeline or budget may not accommodate this idea. Here are a few tips when you need to go remote:
•
Keep it hands on. While remote collaboration tools (in which you type and move objects around digitally) have some benefits, they lack the tactile interactions that come with analog tools. A better approach is to use video to see one another and show your work, while still having people work through exercises with paper tools.
•
Give yourself more time for activities. Everything takes longer to do in remote sessions due to lagged communications and synthesis steps that require more time in this format. You may have to split what would be one in-person workshop into a couple of shorter sessions to keep peak focus, energy, and attention.
•
Design templates. Without you in the room, people need more instruction and structure to work effectively. For this reason, avoid blank sticky notes as much as possible. Design simple templates with instructions that help people understand the form their ideas should be documented in.
•
Leverage mobile phones or scanners. Many ideation methods follow a generation and then evaluation cadence. In remote sessions, have participants work individually and then send in photos or scanned documents of their work. Give them a break, and then magically print and cut their work and place it on a large board. You can then walk through the items on camera, moving and organizing them as people give input and see the results.
•
Train cofacilitators. If possible, assign and prep cofacilitators at each stakeholder location.

@pq185 – Thanks for the tip. I feel like we need to hone in on a good collaboration video sharing software that aids collaboration and do testing prior to make it easier for remote teammates to participate in the workshop activities.

other than their’s of course. Haha. :joy:

Nice @pq185 ! :ok_hand::skin-tone-2::clap::skin-tone-2::clap::skin-tone-2:

@pq185 – Thanks for providing this info!

I wish I had a silver bullet for that @sarah.johnston I feel your pain. I’ve been fortunate to have success with this, but I haven’t had success every time. Earlier I mentioned, you likely need to define a strategy for getting people to buy into it, and give yourself a timeframe. 6 months? 12? you’ll determine. There are cases where an org just isn’t receptive to change. You need buy-in *somewhere* — the middle (product managers, team leads, etc.) or from the top. You try small, with little impact to the status quo, and if you can’t get traction over a certain time, there is a point where the org may just not accept that change.

Ok team, we have time for Yancy’s question and then we’ve hit the top of the hour!

I’m also ok if you just hit up @innerpeacesjc’s question about book recommendations.

@zimmerman1181 What kind of expectation setting do you do or “pre-work” do you have folks do prior to workshops?

It depends on the session, but a minimum is prepping them for what inputs are being leveraged for the session. Distributing prior research, for example. Sometimes, I also assign so solo activities to bring to the session. Such as bringing in ideas based on a prompt.

@risdon – That’s the sad truth!

Book recommendations:
Meeting Design
Service Design Thinking
Service Design Doing

Living in Information (Jorge Arango)

Especially https://rosenfeldmedia.com/books/meeting-design/

Given all the questions about creating engaging sessions!

I’ve got one more tip for getting buy-in…

We had Jorge in this channel last week.

The transcript of that session is here https://uxmastery.com/transcript-living-in-information/

If you’re working with product people, they are often data centric. If you’re expecting them to buy into your human-centered tolls and processes, you should meet them halfway, and buy into their data analytics. Bone up on data analysis and business intelligence, so you can speak their language, and they will likely relate to you and see you aren’t saying that they’re doing something wrong and you want to introduce something right, but that you both share in expanding your toolkit for better outcomes.

Excellent tip!

Thanks so much for that (and all the other wisdom shared today).

It’s been an honour to have you both here.

I’ve learned a lot.

Ok gang, I have to get back to a workshop

I enjoyed this a lot!

Thank you!