Ask me anything: Boon Sheridan, principal and raconteur of coincidental arts

This AMA (Ask Me Anything) took place in Designer Hangout, a community of over 5000 UX design and research professionals. If you’re not yet part of the community, join up to participate in real-time UX discussion and upcoming AMAs.

Hi Boon. Can you tell us about yourself, what you do, and what a raconteur is?

I’m one of those folks who came into UX through the information architecture door a long time ago. (Oh goodness, almost 20 years it seems!) I started working between tech and design back when AT&T was building an online platform to rival AOL. The space between systems and users was well-defined for closed systems such as terminals, mainframes, and the like, but browsers blew it all to heck. No one knew what was going to happen, and someone needed to know enough about the code, the content, and the design to work on the fly. All the adults in the room decided to give it to me, and somehow I never set a machine on fire, so that’s good.

In a lot of ways, what I do and how I interpret UX has been much the same: helping teams connect the dots between what they want, what the business is trying to do, and what people in the real world actually will do (which isn’t the same very often.)

Over the last few years, I love that storytelling has come into the lexicon as a valuable UX and design skill because that’s what I’ve relied on all these years, helping to explain what is going to happen, what we’re trying to do, and what might happen if matters go a bit askew. So a raconteur is a storyteller, someone who spins a yarn and makes you want to put your feet up and listen. Now I find a lot of what I do is help companies figure out how to describe the problem in plain English. Some of my favorite projects have comprised traditional research, where you ask 20 people what the problem is and receive 22 answers. You have to translate, shape, and refine the problems. That’s it in a few paragraphs. Now if the cat will behave and stay off my keyboard. we’ll be all set.

How do you help people frame things as a problem rather than a bunch of solutions?

I spend a lot of time with the small stories and see if they connect. Once or twice I created “the dismal path” where a lot of problems or small failures built up to a big problem.

For example: an insurance company loses customers. A few customers up and leave a company for no reason.

I dug into all the aspects that drove people crazy about the relationship—where the missteps occurred (somewhere in the Jira development software, some in customer service logs). Then I worked to show how each was a contributor to losing the customer. So, I think it’s about taking the time to pull some of the stories out of Jira, seeing where they fit on the customers’ path, if and when they connect, and then telling a story with “connective tissue” that goes from three user stories to “Here are James and Mary shopping for home insurance because they just bought their first house.” I try to work backwards a bit and see what the little problems work up to.

I’ve done at least three projects where we started with customer retention. That made people sit up and say “yeah, we love our customers, we want to keep them” but then illustrate where the little things were mounting up that led to losing the customer.

Would you agree that deciding on the goals is the first part of your story, and how do you make colleagues and stakeholders understand the importance of goals?

I’m going to play a bit coy on whether deciding on the goals is the right way to go. I think there’s one approach where you look at a lot of little problems and search for the connections. Some naturally connect and the story leaps out at you; however, there’s also an approach that works by setting up the story goals and finding the material to build your story and make your case.

How do we avoid going down a negative spiral of problems and more problems?

Part of the answer is rooted in focusing on what the great results are for customers and clients. You can’t make it all sunshine, lollipops, and kittens, but you can highlight what our customers want and love us for, and make sure they get it. Describing how problems connect and get in the way of that often shows how systems frustrate people.

How granular are you with the problem pieces? Do individual user issues count, or do you lump them together into groups of bad experiences by interaction point?

Good question! I’ve often tried to step back and see if a problem can be smoothed out into something that is more than a one-person issue. I tried using a specific example once—a person from a call center log—and it backfired. The team went back to the specific call, listened to the conversation, and started arguing about the semantics of what the customer said.

“They weren’t angry, they were tired—this isn’t a problem.”

“This person clearly isn’t tech savvy—this is a help desk issue.”

While I was overjoyed we had a room full of people diagnosing one customer problem, it became specific far too fast and left us in one of those impossible places.

Be cautious about calling the users “personas” as opposed to “characters”, because they exist to help bring the story to life. As you’ve all probably learned, names have power. When you talk about “prospects” or “mainline customers” it lets you get a bit … callous. When a room talks about “James and Mary”, people pay more attention. We’ve shifted the discussion towards people, and that’s almost always a good thing.

When I do customer journeys, part of what I think makes them successful is spending a ton of time on the set up. “We’re here today to solve how James and Mary will make an appointment to visit an insurance agent for a quote.” When things open up, I ask, “Is this a problem for James and Mary? Do they see this, or is it a connected issue but unseen?” I abuse the phrase “open or close the aperture” a lot in these discussions. If you open the aperture and let too much light (information) in, you’re suddenly trying to solve everything, and nothing gets done.

Agreeing on a focus and specifics go a long way towards solving the problem. It’s sort of why site and product redesigns are such problems: they try to fix everything, and solutions are slammed together. Usually it’s  “We’re here to help James and Mary, we’re going to figure out where we can fix the little things and make sure they connect. There’s no right or wrong right now—just stay focused on the needs and the people.”

Do you stand over it all like a UX dungeon master then, and adapt the story as needed?

Hahaha, that’s awesome. I’ve never thought of it that way, but I have often asked people to go further—what do they think will happen next, and flesh out the interaction with a real-world result. If you can have a group of people across disciplines agree that the best result is “James and Mary can schedule a meeting with an insurance agent in their neighborhood and don’t have to provide anything but their phone number,” that’s huge. Plain English.

How would one go about learning and practicing the art of storytelling?

I think you can learn a lot by reading great short stories. The sort of stories I tell in my UX work are small slices of life, done with the right amount of personality and color that get people nodding their heads. You want your stories to ring true, as my English professor said, “verisimilitude or death” (though he was probably overstating it). I was raised on the short stories of authors such as James Thurber, Edgar Allan Poe, and more, but dig into the short stories of any author you like. Conveying a lot in a few pages is harder than it looks, but it’s a muscle you can develop.

For your clients, do you tell these stories as written stories, or do you have a visual method that you prefer?

I string them together visually, often like this:

This is from a workbook poster I made for a Customer Journey session. From a handful of stories I made a story script, fleshed it out with real-world color, then strung it together. Underneath are a lot of parts of a site’s functionality, but what James and Mary see is what mattered in this exercise.

Talking from only one year’s UX experience, in the startup where I work I always find that we do not take the time to do our customer journeys. Do you have any clues on how I could change that?

Customer journeys are super helpful, but I think they suffer from perceptions of being time-intensive and possibly “throwaway” when done. I suggest keeping them simple and low-fi, and having more words than pictures so that you can edit and move. I do mine in Keynote so they’re hard to make too fancy, and they look great on a screen or printed 11×17 to share.

One of the best ways to gain traction is to show they have value that can come from a few different ways. I like to timebox exercises to limit the ‘noodling’ (super-technical term) and get them done. For example: “We’re going to spend 16 hours on a journey exercise.” Then figure out whether you get value from it. Did you realize, “Hey with eight more hours we could have done X and Y”? There’s no right or wrong way to do this sort of work. I could go on for days about the differences between a Customer Journey and a Customer Journey Map, but instead I’ll just say that a map represents all the places your customers can go, while a journey comprises the places they do go.

It sounds like a lot of the work is about getting multiple stakeholders working towards a common goal. Do you have any favorite collaboration-type exercises that you’ve found particularly helpful? I often hear that empathy exercises are helpful, but then flatline a little when asking customers or non-designers to problem solve.

You’re dead-on; it’s about getting people on the same page, building little agreements that ladder up to big changes. Collaboration exercises come in so many flavors, I often tailor what I’m going to use to the meeting, or what I know about the people who will be there. I lean on Gamestorming for a lot for ideas.

If you had one piece of advice for someone who’s just entering the field, what would it be?

Don’t worry if you think you’re doing something wrong. It’s too easy to get caught up in methodology and specifics. If you see a problem and have an idea, put it in action.

I’m sure you’ve seen the Stefan Sagmeister video where he levels an accusation at the design industry for taking on the term storytelling as a “mantle of bullshit.” How do you avoid that and where do you find that dividing line between storytelling for trendiness versus storytelling to accomplish something?

Ah, yes. I think there’s a lot of smoke there but I don’t worry about it too much. Sagmeister’s a great designer and a wonderful speaker—his talk on sabbaticals was a big inspiration for me. I took part of what he was talking about as “own what you do!” If you make rollercoasters then own it; why use another term when the first is so freaking awesome! Seriously, who wouldn’t love to say “Oh, I design rollercoasters” at a party some day? If I make something big enough that Stefan Sagmeister pokes fun at it, I’ll probably die a happy man.

If you had one piece of advice for someone who’s just entering the field, what would it be?

Don’t worry if you think you’re doing something wrong. It’s too easy to get caught up in methodology and specifics. If you see a problem and have an idea, put it in action.

I’m sure you’ve seen the Stefan Sagmeister video where he levels an accusation at the design industry for taking on the term storytelling as a “mantle of bullshit.” How do you avoid that and where do you find that dividing line between storytelling for trendiness versus storytelling to accomplish something?

Ah, yes. I think there’s a lot of smoke there but I don’t worry about it too much. Sagmeister’s a great designer and a wonderful speaker—his talk on sabbaticals was a big inspiration for me. I took part of what he was talking about as “own what you do!” If you make rollercoasters then own it; why use another term when the first is so freaking awesome! Seriously, who wouldn’t love to say “Oh, I design rollercoasters” at a party some day? If I make something big enough that Stefan Sagmeister pokes fun at it, I’ll probably die a happy man.