Empathy as a Service: Applying Service Design to the Homelessness Issue

July 20, 2017

Empathy. It’s an unavoidable word in the world of user experience design. Too often it is applied to designs in too narrow a fashion. Your empathy should come from the problem your design is solving, not measured in the level of frustration or delight experienced with your design.

Ariel Kennan is the Director of Design and Product at the New York City Mayor's Office for Economic Opportunity. She has been working on the HOME-STAT initiative which is an effort of the City of New York to properly provide services to the city’s homeless population.

In this episode of the UIE podcast, Ariel shares her story and is joined by Marc Stickdorn who offers his insights on how service design can be done on such a massive scale. Marc is the CEO and co-founder of More Than Metrics and author of the book Service Design Thinking. He will also be teaching a daylong workshop at the UI22 conference in Boston this November 13-15.

Transcript

Jared Spool: This is the UIE Podcast. I’m Jared Spool.

In the pilot episode of the TV show Futurama, we’re introduced to Bender the robot as he waits in line at a suicide booth. He states that he can’t go on living once he found out that the girders he bent for his job were used to make suicide booths.

Empathy is a word that comes up nearly every time there is a conversation about user experience and oftentimes in a way as misguided as Bender’s logic. We speak of having empathy for users as they experience our designs. We speak in terms of frustration and delight. But it’s actually a step bigger than that.

If you are measuring your empathy in terms of your own product or service, you are potentially looking in the wrong place. Design is about solving problems, and if you are paying attention solely to the experience of your design, you run the risk of ignoring the problem it is intending to solve.

Ariel Kennan: Homelessness is one of our most visible quality-of-life issues in any city. A lot of cities face this. New York City has a right to shelter policy that's been enacted for quite a few years. But we have a lot of people in shelter. We have about 60,000 people in shelter. Then, we have a street population that rises and falls. It's a little under 3,000 people. Even though we're providing services to them, it's very visible. People notice it. People I think also just have a lot of compassion for people they see on the street and say, "Why? Why in such a wealthy and otherwise vibrant city do we have people who are suffering?"

My name is Ariel Kennan. I'm the director of design and product at the New York City Mayor's Office for Economic Opportunity.

Jared: In social services, there is often a balance you need to strike with the users of your product. Many times, there are direct users and indirect users, and you need to be aware of the needs of both groups.

Many organizations face similar balancing acts between their employees and their customers. Whether it’s a call center or other customer support or sales efforts, you need to have internal services in place for your employees to help your users get what they need.

In Ariel’s case, her team focuses on her direct users, which are the city’s outreach workers. At the same time, her team needs an in-depth understanding of a group of indirect users, the homeless for whom the outreach workers are serving.

Ariel: A lot of government and a lot of civic tech stuff talks about the residents often at the end of the service. We spend a lot of time with the people who actually deliver the services. I think they're users that are sometimes overlooked and undervalued, that they need good tools and resources to do their jobs as well. Especially when you're looking at vulnerable populations who may have a hard time making decisions for themselves or may be otherwise impaired, that we need good people working on their behalf as well. How do we support them in doing their jobs?

Marc Stickdorn: I consider it as an organization using a new way of working, using what I called service design, you might call differently, to improve both. That's what I really like about it. Both the customer experience, if you like to say so, the customer in this case, homeless people, or people living in a shelter. As well as the employee experience, those people who are out there on the street working with homeless people. I really like both aspects of that because this is something we need to see much, much more in any industry.

My name is Marc Stickdorn. I'm a co-founder and CEO of More Than Metrics. I will be teaching the workshop Service Design: Creating Delightful Cross-channel Experiences at UI22 this year.

Jared: One challenge Ariel and her team faced was the sheer size of this effort. New York is a big city, and each borough had multiple agencies touching services that they were providing. A critical aspect of empathy is understanding the exact nature of the experience.

Ariel: We hosted an all-day workshop with the providers and the government staff and invited them to help correct our journey map. We made this beautiful artifact. It was about 20 11x17 pages, every single step detailed out, broken out into the major sections or chapters of the journey. We did a facilitated session where we asked them to help correct our mistakes, tell us about things we didn't hear yet, add things that were details that helped elaborate on a point that we were making. That alone was really great consensus-building around this work. These are folks that don't always have time to reflect and share quite in this way. They spend their days responding to emergencies, and so giving them the space for it.

As designers giving space for all of those voices to be part of it, without being opinionated or necessarily critical, but being based on the experience of what they had been going through trying to get this service or deliver this service. We weren’t trying to voice opinion, we were trying to voice what was seen as fact from multiple different people.

Jared: Even though Ariel’s work was being done in a social services department of the government, Marc says her approach was familiar.

Marc: I really saw a lot of the stuff I see in many different organizations, how important visualizing stuff is, visualizing data, for example, as a journey map to create what we academically call a boundary object. People from different backgrounds can look at that thing and interpret that however they need it. They're looking all at the same thing and they make sure that they talk about the same stuff.

Let's take a very simple example like at Telco. Somebody's going to a shop buying a new phone, and you do a focus group about that and people talk about experiences. They talk about their last experience and they have discussions about that. I would bet on that that if you have 10 people in the room, 10 people think about something completely different, because they don't really understand each other.

If you add a boundary object to it, like a journey map for example, and those 10 people create this journey map together, they know exactly what they're talking about. You know exactly. Are we having a shared opinion on that? Or actually do we still have two different stories? Boundary objects help a team to look at, for example, a customer experience, and then interpret or translate that into their domain language. If an IT person looks at a journey map they see something different than if a marketing person or a salesperson or a human resource person looks at that. You can extract the data which is important for your domain, but you make sure that you have a common understanding across all the different departments, or in that case across all the different people in the room.

Jared: Co-creating a boundary object like a journey map helps people confirm the accuracy of their understanding. If they didn’t get in the room together and go through the journey step by step, they could be leaving out important aspects that someone who intimately understands the process takes for granted. For Ariel’s team, gaining that shared understanding can literally be the difference between life and death.

Ariel: This was definitely the first time in working this way. A lot of these folks all know each other. They have to work with each other. They rely on each other for the different services because they're critical to the population that they're providing. But they weren't always able to come together and have these more facilitated conversations. That's something that I'm realizing in government, that in addition to the design materials that we produce, just being good facilitators of conversations and thinking about who's in the room at the right time, who are we pairing with whom, and how do we then have a constructive and also safe conversation that hopefully doesn't escalate to an area of aggression or conflict, that we can talk about the hard stuff and still have good movement on the other side, that we're making progress on real change.

Marc: One of the biggest challenge is that if you co-create with people from different backgrounds, they might have studied different subjects or they're working in different departments. They all have their unique language, the language they use among their peers, but it also is a certain way of thinking.

For me, service design is actually this kind of common language you can use. Through having simple boundary objects like a journey map, I mean it's not rocket science. There's no magic behind that. It's just a way to visualize data. That's all. But it helps a team to work together. I would say that the key factor of working in a co-creative manner is to have a good facilitator. I would say when you practice service design, being a good facilitator, helping a group to go forward within the process, is the absolute key aspect of doing service design.

Jared: Ariel’s team was in the center of this massive effort to gather all of this data from these varying sources. Not only did they need to arrange for this gathering, but they also needed to communicate with each department that influenced the journey. The team used the journey map to achieve their common language and understanding, and to facilitate these conversations.

Marc: Being a good listener. That's really for me one of the key differences between a facilitator and a moderator. A moderator often interferes into or put content into a discussion, interferes within a discussion. Whereas a facilitator helps a group to have a discussion, to come forward. In service design we like to say that we are never experts on the subject matter. On whatever a company's working on, an organization is doing, we are not the expert. The people who are doing that are the experts. Our role is rather is to facilitate the design process of that and stepping more and more out of the content. Asking rather dumb questions to really understand and then listen to whatever they say and learn from that.

Ariel: The session was, I would say, both reaffirming that we're pretty good listeners. However, there were a lot of things that we didn't know yet. It was more of a time constraint of we just needed to do more listening. We just needed more time. It also was a great leaping off point for us to know other people we needed to go talk to, to find out more to figure out where the deeper gaps were and also identify places that we were hearing different things from different people.

Jared: First hand experience will always be the thing that elicits the most empathy. Ariel and her team had the journey map and could listen to various people’s stories about their own interactions with the service. They now needed to step through that journey themselves to see where they may be missing things, or where the real challenges of the journey were. It was time to go out and do the work themselves.

Ariel: In addition to doing the journey map, we did some, what we called, stories from the street. Helping tell real stories of things that we saw, both from actual clients that we met on the street but also these workers, and showing both when they had successes but also some of the real challenges. We also encourage more people to go out into the field and shadow this work as well, so when they can, seeing through our eyes, but also trying to build additional empathy as well by directly experiencing it. There's actually a really cool ... it was picked up in the press, but the mayor and the social services commissioner actually went out and did frontline outreach one night, which was very cool to see.

Marc: Doing research. I think that is the most crucial thing. Really learn how the experience, how the reality is there. Don't work with assumptions. One of the typical mistakes we see nowadays is that people hear about certain tools, like a customer journey map for example, and then get together in a room, throw some post-its at the wall, create an assumption-based journey map, and never validate their assumptions. Then they base strategic decisions on these assumptions, and that just will go wrong. What you can learn from this case is do research, be out there, both with the employees and with the people you design for, your users, your customers. Do a lot of research continuously and base whatever you do on this data, on whatever you really find out there.

It is important that your team members see it with their own eyes, that you use qualitative techniques, if possible even ethnographic approaches, to really go out, that you do contextual interviews in the situation and context where the people that you really see it with your own eyes. Then over time it is important to keep your research data present, and not the quantitative data but the qualitative data as well, so photos you took, quotes from your users.

We often create what we call a research wall, where you hang up some defining quotes, photos, screenshots of videos and so on, artifacts you collect, and keep it present throughout the entire process.

Jared: Qualitative data is one of the most powerful tools we have at our disposal.

Ariel: We went out in a variety of different ways. We're looking for people. For people who are known, they have a client list. They map where they are, et cetera, so they know where to go back to find that person. Sometimes when we were doing, especially with some of the winter stuff, it's what we call a code blue, which is critical for saving people's lives because it's so cold outside.

We're going and checking on people to make sure that they are warm enough, to try to convince them to come inside with us. Some of that was more surveying from a car and driving around out in the outskirts of Queens looking for people, but also finding new places. We were out driving by a park out in Queens, and we saw something off on the back hillside of the park that looks like it could be somebody's stuff. We ended up getting out of the car and walking across the park and the outreach workers climbed up the hill and found a guy who had actually built an encampment up there. They offered him services, trying to get him inside. He declined that night.

We saw a lot of either just ignoring the workers, refusing, saying that they're okay, people who were very visibly suffering saying that they're okay. In New York, we have very good laws about protecting people's rights. They really have to be a danger to themselves or life critical in order to remove them from the streets, which I think is also something really important to understand, that we're not just doing enforcement and forcible removal of people, that they're having a choice in this as well.

Finally, one man said he was ready to come inside. They took him. They had to find a spot for him. They found a spot in one of the transitional housing locations, brought him in. He couldn't believe he had his own room. He was just shocked that he could have his own room, that that was even an option for him. But that was the only … We witnessed hundreds of interactions, and in all of that we only saw one person fully accept services.

Jared: There is no substitute for experience. The old adage about walking a mile in someone’s shoes rings true. We can’t design appropriately if we don’t know what we’re designing for.

Ariel: Pretty early on we were like, "Man, you get rejected just constantly by all of these people. How do you keep going?" That was something we asked every outreach worker, "What keeps you going?" I'm going to tear up talking about this, because it's so beautiful, but they told us the most beautiful thing they have ever had happen is when they give someone the keys to their own apartment. That person that they rescued got to come inside. When they give them their keys and they now have their own home and they have their services … Sorry. I really am going to cry. That's why they do the work. That really stuck with us, was the giving the keys to people's own homes.

That's why the outreach workers do their work, but that's also why the city does this work.

Marc: It's such a visual picture of a success moment, actually of the defining success moment for outreach workers. This is why they're doing it. This is why they go through the valley of tears of frustrating moments of getting rejected again and again and again, because they're working towards having this success moment of passing over a key. I think it's just a wonderful picture which helps me as an outsider to have empathy with the outreach workers and understand a little bit why they're doing it.

Jared: In any service interaction, trust needs to be at the forefront. If your customers don’t find you to be trustworthy, they won’t use your service. But trust is also a major factor internally. Your workers need to trust the systems that are put in place so the promise or value proposition doesn’t disintegrate once the user engages with your service. Once you have a breakdown of trust it can be extremely hard to re-establish.

Ariel: It sometimes takes hundreds of contacts with somebody who's been let down by society to want to regain trust again, and so really saying, "No. We need to emphasize that."

Once they've built that relationship with this person and finally get them inside, get them willing to accept services, we need them to be ready and trusting once they go into that public assistance office or into that housing interview. We can't have it all break down because something further up the system broke.

Marc: How can they promote a product if they know it doesn't work? How can they promote any services if they know probably we won't keep it? That's a horrible experience for an employee.

What can service design do? We look not only at the employee experience or not only at the customer experience, but we also look at the internal systems. What are all the backstage processes behind there? How can we make sure that if somebody promised something we can keep it? It's the same idea there.

Jared: In any journey, you need to have a destination. If you don’t know where you’re headed, wherever you end is arbitrarily your endpoint. But you will never know if it’s the place you’re supposed to be.

When you’re designing a journey, knowing what you define as a success gives you a destination to move towards.

Marc: Before we start journey mapping we often ask: What is the most defining moment in the story? Another mistake many people do is they start journey mapping at the very beginning, which leads to a group having a huge discussion: So where does the story actually start? Instead start with the most defining moment. In this case it could be the moment when the outreach worker passes over the key. This is what we're designing for. This is where we want to go. If you compare that to web analytics, that would be what you define as a conversion. This is what you aim your designing for. Then think backwards. What are the steps that lead towards this moment?

You might come up with discoveries which helped for this conversion and you might find thing which does not help for it. These are then, again, different stories. Then you're going to have different journey maps, a successful one and maybe something where something went wrong, which will help you to understand and to actually do more research asking why didn't it work, to then understand what you could do differently to achieve this main aim you're working for, this defining moment of passing on the key. I really love that picture by the way. I think it's fantastic. It's a very visual success moment.

Jared: Empathy is a powerful driver. True empathy can change the way an organization approaches its designs or services, because they fully understand the issues that they are designing to solve.

Ariel: I think we had great success in changing the narrative, and a lot of, in particular, the public-facing things around this population. I think the people who are delivering the service have some of the biggest hearts in the world, but there was a lot of stuff that was a little more enforcement and a little bit harsher toned. I really saw a dramatic change in how we were communicating just out into the public about what people can do when they see someone on the street who may be homeless, but also the official homelessness policy document that's called Turning the Tide, which was issued in March.

I found myself tearing up the first time I read it. I really heard the voices of all the people we had talked to come to life in this report, a report, mind you, that my policy colleagues wrote. I didn't actually write it. It was such a change in maybe just even some of the dryness that you sometimes see in other policy documents that are less about the people that were serving and are serving on our behalf. It was a dramatic change in showing that we're providing these services, they're critical, and this is some of the stories of how they happen.

Jared: In an industry replete with buzzwords, we run the risk of burning a good term simply by misusing it. Empathy, true empathy, is an incredibly powerful driver of design. When we step through the journey and experience both sides of the service we’re providing, the customer side and the employee side, we arrive at a greater understanding of what it entails.

This gives us perspective that we may have not had previously. Ariel’s team saw first hand what outreach workers experienced in trying to provide services to the city’s homeless population. They could feel for the work being done and could translate that into defining moments of the journey.

This UIE podcast is brought to you by the UI22 conference that’s happening November 13-15 in Boston, MA.

Marc Stickdorn will be joining us there to teach his full day workshop, Service Design: Creating Delightful Cross-channel Experiences. He’ll show us how to create a cohesive customer experience by expanding beyond digital and designing for every customer touch point. To learn more about Marc’s workshop, visit Uiconf.com.

Also, if you’re in an organization that is looking to hire more UX designers anytime soon, I want to point you to our new school in Chattanooga, TN called Center Centre. Our students are learning what it takes to become an industry-ready UX designers and they need your help.

To help them learn the craft, they need great projects to work on. Companies supply the projects and, while they’re at it, they get to see what our students are capable of. It’s a great way to help grow our field while you’re doing preliminary recruiting. If you have a project that you think might work, please get in touch. You can learn more at Center Centre’s website. That’s C E N T E R C E N T R E dot com.

This UIE podcast was written and produced by Sean Carmichael. We'd like to give special thanks to Marc Stickdorn and Ariel Kennan for appearing on this episode.

You can find more information about the UIE podcast on our newly launched UIE Podcast Network website: U I E dot F M. Go there now and look at all the great shows we’ve put together over the years.

This podcast is part of the UIE Podcast Network. Thanks so much for listening and, as always, thanks for encouraging our behavior.

Using Scenarios to Solve Problems • A Podcast with Kim Goodwin

July 19, 2017

After all if you don’t understand how users are interacting with your product or service, you don’t know what to design for. But how, as a team, do you come to that understanding? Telling the story of a user’s journey highlights areas where you’re right on point and where you’re missing the mark.

Kim Goodwin says that storytelling is the most natural form of human communication. She posits that if we’re trying to be as human as possible in the design process and come up with the most human solutions, why not use one of the most basic tools that we as humans have? The cognitive barrier to listening to and processing a story is relatively low. Being able to communicate that story is a key contributor to getting a team on the same page.

Using scenarios and personas you can craft customer journey maps to better gauge how and when people are using your product. Working through these scenarios, especially early on in the process can uncover valuable insights and allow you to iterate quickly to ensure you’re heading in the right direction.

Ask Kim any question and you’ll instantly get deep, thoughtful insights that come from her years of experience working on the toughest designs imaginable. (Seriously, try it!) In fact, as VP of Product and UX at PatientsLikeMe, she still takes on big design challenges daily. After all, the healthcare industry is ripe with potential for innovators to connect individuals with reliable information, trusted providers, vital historical data, and extensive support networks.

Kim has been dedicated to user-centric practices like this since her days running the training and design consulting practices at Cooper, a leading agency. There, she played a major role in crafting their Goal-Directed design process, which brought users into their clients’ most challenging projects.

We’re excited Kim Goodwin is joining us with this top rated workshop again this year.

Transcript

Jared Spool: Hello there. You have dialed into yet another episode of the “Spoolcast.” I am Jared Spool. I’m the guy in charge of these things, but today we have the real person in charge of all things Awesome UX. We have Miss Kim Goodwin, who is one my favoritest people in the world. This will be podcast number 751 with her and she is going to enlighten us about how we get scenarios to work in our organizations.

Kim Goodwin: I’m well, Jared, especially after that fantastic introduction. How could I not feel pretty good?

Jared: That’s how I feel. That’s how I feel. I’m putting together this conference. Every year I go out and I find speakers who are talking about things that I’m most interested in. I invite them, and your stuff always ends up on the top of the list almost immediately.

I’m putting them together, and I’m writing up the description of why I have each session. As I’m writing it up I keep finding myself writing the phrase “Get on the same page.” We have Bruce McCarthy talking about production management, so it’s like, “Get on the same page with your product manager.”

We have Jenn Lukas talking about creating a living style guide out of CSS. It’s like, “Get on the same page with a living style guide.” Nathan Curtis talking about design systems. “Get on the same page with your teams through a great design system.”

Of course, scenarios help us get on the same page. The thing is that I didn’t do this on purpose. I crafted the conference in terms of the people I wanted to hear. It just occurred to me that everything I wanted to hear about was about getting people on the same page.

This is because this is the thing that I deal with most when I’m talking to the companies I’m working with. I was wondering if you’re seeing this, too. Are you talking to people a lot about “How do we get on the same page about what we’re doing?”

Kim: Very much so, Jared. That’s a huge focus for everybody working in this space right now. I think 20 years ago when your conference first started…

Jared: Yes, 20 years.

Kim: We were all trying to figure out what our profession was. We were trying to figure out the techniques for solving the design problems in the first place. Our message were just starting to come together and certainly drawing from other fields, like industrial design and HCI and other things.

But I don’t think we generally had coalesced a method. Where nowadays, I feel most practitioners have had some contact with pretty similar sets of methods in a pretty well understood way that we can solve problems.

Now that that’s done, everybody’s focused on, “Wait, why are we still not getting stuff done?” Ultimately, it all comes down to aligning the organization around where you want to go.

Some of that’s about process. Some of that’s about skills. Some of it’s about culture, but it all comes down to alignment.

Jared: Yeah, that’s exactly right. I’m thinking about the first UI conferences that we did. We had sessions every year about the basics of usability testing, for example, and the basics of what we would now call “Interaction design.” Back then that wasn’t what it was called, and the basics of these things.

Now this year we have a session that is still usability testing and user research. But the way Erica Hall is going to deliver it, it’s about coming to a shared understanding, getting to a common knowledge about it.

It’s the elements of that type of research that get everybody on that same page. I think you’re right. We have moved past the basic tools. Yet, we’re still struggling to produce great experiences all the way through.

So, it isn’t just having the tool in our hand that automatically makes us instantly producing a great UX, just like buying the most expensive blender does not make you a great cook. You have to know how to use those tools in a great way.

Kim: Exactly. Alignment is honestly, not even just alignment within a product team, it’s alignment across an organization and especially as a user experience now might be partly digital. It might be bricks and mortar retail. It might be on the phone. It might be a thing you get in the mail. All of that is wrapped up into the user experience.

You have to get even more people on the same page. Now that I think about that, that’s probably another reason why, just in the last few years, that need for cross-team, cross-silo, cross-functional focus is probably bigger than ever.

Jared: Yeah. In a lot of organizations it’s like that old phrase about, “The future is here. It’s just not evenly distributed.” The knowledge of how to get to great designs is here, but it’s not evenly distributed.

Kim: That’s true. It’s not even evenly distributed within an organization. Generally, I find that in a given organization there’s one team that’s maybe doing really sophisticated work.

Where other parts of the organization, especially when they’re internally focus groups like the IT group, often maybe lags behind the product group, because it wasn’t that a customer facing driver for them, for example.

Jared: In this world where we’re now putting together multi disciplinary teams, do you think that means that in a given team, there’s going to be a distribution of knowledge of what it takes and just getting that entire team to have a shared understanding and being on the same page takes work? It doesn’t just automatically happen.

Kim: Certainly, within that team you want a distribution of skill sets because that’s why we’re multi disciplinary in the first place.

Where I find those teams often begin to struggle is because they don’t have a sure understanding even of the problem they’re trying to solve, they don’t have a shared language or a shared perspective on what it is the solution needs to accomplish in the first place.

It feels like requirements and even Agile user story, I think don’t really make it clear for teams. So, in my experience the first step is to come together around a tool that helps everybody see the problem from the same angle.

Jared: You’re absolutely right about that. Let’s hone in on the role scenarios play there. It feels to me like they play a really critical role in helping that team and the parts of the organization that has to interface with that team, interact.

Kim: If I can rewind a little bit and look at something that you want to do, ideally is a precursor to scenarios, journey maps do a better job of aligning people around the problem, to prepare them to develop scenarios of the future solution.

Some time ago when I first started teaching scenarios, which is probably more years than I care to count, I would find some people took to it naturally and others really struggled with the generative aspect of scenarios and didn’t quite know where to go with them.

When I started teaching journey mapping, which essentially takes your user research and lays it out in a timeline fashion. Imagine that you are outlining this person’s encounter with your tools and with other tools in some way and then you’re mapping that versus, “How do they feel about this? What are they trying to accomplish? What are they trying to learn at each stage of this journey?”

That’s a structure that starts to really open people’s eyes around, “Oh, boy, this stage in our journey is really awful.” Actually, we do OK here. People aren’t too stressed about this.

That’s first to align the team around, “Where should we focus our energies?” because a whole user journey is usually quite large and touches probably every part of your product and maybe other people’s products, too.

That’s a great starting point and it’s a good jumping off point for generating a scenario that tells the future story of the product.

Jared: When putting the journey map together, when you’re doing that, are people coming from the same place when you’re doing that, or is this a tool that you gather around to synthesize where everybody on the team is coming from?

Kim: You could do it either way. In my experience journey map works best when you have people who have a shared base of user research, rather than just discredited assumptions and experiences.

Ideally you pull together some qualitative research people have done and you start to map that out. In my experience actually, that journey mapping exercise tell people whether they’re good or bad at qualitative research because you can’t do a journey map that means it’s a lousy interview.

But if you want to use a journey map as a starting point when you don’t have that shared context, that’s not a bad thing. Because part of what it will probably reveal is that lack of shared context.

You can say, “OK, if you all think we understand our users, let’s sit down and try to do our journey map together.” That’s actually going to reveal the holes in the team’s knowledge and probably reinforce that actually it is worth you going down and sitting down with at least a handful of users in their actual context.

Jared: Being able to get that journey map built, once you have it built, it feels to me that now it’s a really useful tool to help people who weren’t involved in that research to pick up and get up to speed quickly and tell those stories.

Kim: Yes. It’s a way to make that tangible. It’s a way to express a lot of what you saw in those interviews in a pretty compact and digestible way. Then from that journey map you can start to get people thinking, “All right. Now let’s imagine what that future experience is like.”

You begin to tell the story of if you had a magic black box that you could put in people’s hands, what would happen? How would that story unfold differently? That’s where you start to build, Jared, understanding about the solution.

In a universe where you just have a bullet list of requirements or you have some acceptance criteria detailed in an Agile user story, which to my mind is not really a story per se.

Jared: You mean as an administrator, “I want to be able to log in” is not a story of my experience? [laughs]

Kim: Yeah, because there’s really no plot or character in that, is there?

Jared: No, no. You can see the authentication system as a villain. [laughs]

Kim: You want to log in, Jared? Tell me all about that. What an exciting story. That’s the thing. Agile user stories are good scoping tools.

They’re effective communication tools in many ways, but stories they’re really not whereas a scenario says, “Imagine if we had the magic new product or the improved functionality. Here’s how that would unfold.” That starts to imply a whole host of requirements.

It’s a generative tool that helps product managers understand requirements, helps designers influence those requirements, and helps all the engineers start to get a picture of, “Oh, that’s going to have to connect to this, and we’re going to have to build it this way.” It starts to take shape very quickly that way when you’ve got a story to tell.

Jared: This idea of being able to tell stories seems to be a key piece of this “Getting people on the same page.” Do you think this goes back to a basic human trait of just being storytellers?

Are we just taking advantage of what thousands of years of evolution and sitting around the camp fire teaching our children how to be good humans has all been about and we’re just moving that into the process?

Kim: Yes, I do. I think storytelling has to be our most natural form of communication as humans. It’s something that we all learn to do at an early age. The beauty in that is through storytelling. As children we’re generative.

We’re creative, which I think is a very critical part of the design process because if we can’t be imaginative it’s hard to come up with a future state that’s going to be more desirable. We absorb stories very well. There’s very little cognitive barrier to absorbing a story.

We don’t have to process a whole lot because everybody from Dr. Seuss and the star-bellied sneeches trained us to absorb the moral of the story without really having to think about it much.

Jared: It’s interesting that we can use that as our touchstone in terms of helping people get on the same page. One of the things that I’ve always been attracted to your approach to scenarios about is how it’s very much a human storytelling process. I guess going from the journey maps to the scenarios is really just a story-translation process.

We’ve got this journey. We now have the scenario of what it is today, and we can come up with an aspirational scenario of what we could do. What’s neat is in any given story what I learned about storytelling is it’s not just the details you include. It’s also the details you leave out. Scenarios are interesting because of what we don’t say explicitly in them.

Kim: Yes. First I think that we’re trying to be as human as possible in the design process, so we come up with the most human solutions. Why not turn to those tools that help us think in that form? You’re right that we do leave certain things out.

What I see often when people use cases or more formal structured tools is they’ll start talking about how we hit this database table or this server does something or this part of the system behaves in this way. Who cares?

Jared: Or we sell more cookies or we sell more hotel rooms.

Kim: Right. Who cares? Whereas if we focus on what does this particular human being that we’re envisioning, whether that’s a persona or some real user we interviewed that we’re using as a center point of our story, when we think about that and we just describe what they experience — what do they see and encounter — it doesn’t matter how the back end does it.

It doesn’t matter if we buy that capability and plug it in. It doesn’t matter if that’s built using OAuth. Whatever technology doesn’t matter because we’re just getting at the gist of it. That helps keep requirements at the right level because I see a lot of teams that will do requirements that are actually lists of solutions instead of lists of problems that must be solved.

The scenario focuses on, “This is the behavior we want to enable.” Then from there we can figure out, “Oh. Well, there are three ways we might enable that. Which is the best?”

Jared: That’s really interesting because that’s very similar to something that…when I was talking to Bruce McCarthy about his workshop, which is going to be on “How can user-experience people work with product managers effectively,” we got on the subject of something that separates a really good product manager from folks who are trying but don’t quite get there.

One of the things that separates is that the people who are trying go down that requirements route that you just talked about, but the people who are really good at being a product manager back away from the requirements. He has a word he calls themes.

Themes are the overarching problem that we are trying to solve, but we’re not going to make a list of requirements that are the solution. We’re going to talk about that we need to solve this problem. Maybe the solution that comes to mind first is the one we’ll take, but maybe there’s a better solution. We want to leave ourselves open to that.

When we talk about what the roadmap will be for the next three releases, we’re not going to talk about specific functionality and features. We’re going to talk about the themes we’re going to tackle in each stop on the road map.

It feels to me that pairing scenarios up with those themes would make them more human, more accessible to everybody, and more clear that this is the problem we’re going to solve when we get to that part in the road map, but we don’t necessarily know today what the right feature is. We’re not going to commit to it. We’re going to commit to solving the problem.

Kim: Yes. Better yet, Jared, in an Agile world where a lot of people are focused on what they’re doing in the next one or two sprints…

Jared: People use Agile?

Kim: They use AgileFall or something of that nature…

Jared: Yes. [laughs] They use something.

Kim: …but they call it Agile.

Jared: They call it Agile, right. OK.

Kim: Don’t call it anything but Agile. In a world where people tend to be focused on the short term and the every chunkable functionality, what a scenario does when you attach it to one of those themes or whatever you want to call it is the first pass at a scenario is deliberately timeline agnostic. What I mean by that is it’s not going to focus on, “What’s the version one?” A scenario initially says, “What do we really want that solution to be?”

Then we’re going to pair that scenario with some sketches — fast, cheap, low-fidelity — but make it clear what we’re envisioning for the solution. Speaking of getting people on the same page, nothing beats a sketch paired with a scenario to do that.

From there you say, “OK, we all agree that this is the thing we’re aiming at. Hmm, how long is it going to take us to get there or to get 80 percent of the way there?” because maybe from a product management point of view that last 20 percent isn’t worth it.

Even so, in order to get there, we’re going to maybe come up with some interim sketches and figure out, “All right. Well, maybe this is a two-sprint project. Maybe this is a big, ambitious thing we’re going to have to work toward over the course of the next year.”

That initial fast, cheap scenario puts all of the subsequent user stories into context, so that everybody knows, “Ah, this is about enabling that stuff that we’re going to have fully implemented six months from now.”

Jared: That’s fascinating. I have this image of a designer standing in front of a wall with a whole bunch of sketches. They’re actually play-acting the scenario as they talk about each sketch and walk through each sketch.

The scenario…it’s like those Bible stories that we all know the basic plot to, yet we tell them over and over again, the Passover story, the Easter story, Muhammad going to the mountain, or whatever the story is, Luke discovering R2D2 and taking it Obi-Wan Kenobi, all those religious stories.

We all know the basic story and we can tell that story over, and over, and over again, but now we’re using the sketches almost as props for how that journey will happen going from here out.

Kim: Scenarios can operate at a lot of different levels. You can do very low-level scenarios that are about iterating that thing in front of you that you’re going to ship in a couple weeks. Scenarios also operate very well at the medium- to long-term vision level.

I think you and I both have found in our work that organizations that have a crisp longer-term vision of, “What is the thing we want to build?” and it’s not just a bullet point in a mission statement, but some concrete visualization of that thing, are more able to execute on that. Scenarios really help you with that.

The best example of that I found is one that kind of stole from you. I use it in my workshops from time to time, which is the “Apple Knowledge Navigator” video. What was it, 30 years ago? Apple put together a kind of hokey video that includes Siri, except Siri looks like Bill Nye the Science Guy.

It includes a clunky version of the iPad. It includes screen sharing and a whole bunch of other stuff that honestly has only shown up in the last 5 to 10 years. They’ve known for a long time roughly where they were going, and that’s probably been a big part of why they’ve been able to execute.

Jared: Did you know that that video was part of a set?

Kim: No, I’d love to see the other one.

Jared: The only other one I’ve been able to find is a version of it that involved a digital camera. Again, this was years before anybody had digital cameras. It was 1987, and I don’t think the first digital cameras showed up…Apple had one of the first digital cameras in the mid-’90s, like ’94. Then the Kodak digital cameras came out right after that.

All those were done by Hugh Dubberly. As far as we know, there were four done. Two of them have survived, and the other two, nobody seems to have any original footage of.

Kim: Definitely, for the folks on the podcast, I think that video is worth Googling and I’ll probably drag it out in my workshop.

Jared: Yeah, “Apple Knowledge Navigator” is how you find it.

Kim: It’s a great example of how putting it in the form of a story and illustrating it in some concrete way makes a huge difference in people’s ability to see, “Ah, that’s where we’re going.” Every time a team that I work with is able to start doing that, when you have a story and you have some sketches to go along with it, it really reduces the confusion and the swirl about what a requirement means.

If you have a requirement that’s just a bullet point, you can spin back and forth about what that means and whether the requirement’s been met for months.

Jared: It’s such a powerful way to get everybody talking about solving the same problems. It’s still surprising to me that we have to re-learn this lesson over and over again.

Kim: If I could wave my magic wand and make design schools better at one thing, it would be at helping people ask the right questions and better define the problem. I really think that’s the thing that many teams struggle with the most.

Jared: It’s funny you say that. I do have a magic wand over a design school, and the conversations that we’ve been having at Center Centre, as we’ve been designing the curriculum, is just that. It’s trying to push the emphasis less on finished product, and more on the process that got you there, which means you have to be able to tell the stories of why you did what you did and how you did what you did.

Kim: That’s actually very important in getting people on the same page. As a designer, you can come up with, whether it’s a crude sketch or a beautifully polished artifact…if you say, “Ta-dah! Here’s the solution,” you’re going to get all kinds of pushback because people don’t know how you got there.

One of the great things about this progression from user research, to journey maps, to scenarios, to story board, to finished sketches is, “Wow, you can see how that evolved from the previous steps.” People can follow you there, even if they aren’t folks who can immediately look at a sketch and grasp, “Oh, yeah, that’s the solution.”

When you show them the logic behind it, what that says is, “Oh, this isn’t the designer just coming up with something out of thin air. There’s a reasoning behind this and there’s actually an argument for why this design is good.”

Of course, you want to do usability testing and other things to help you make sure that you’re on the right track. But, in terms of selling that initial solution, you have a path that got you there that other people can see.

Jared: I sit through meetings where someone in a client is presenting a design they’ve come up with. They just launch into the screens, say, “Well, this is the home page, and this is the this page, and this is the that page.” They don’t talk about the scenario.

More importantly, they don’t talk about how they got to this design from the journey map or from the sketches. The audience is left to reverse engineer that in their head. Of course, they all do it differently. Then, there’s all this conversation that happens around what they think the path was that got them there that turns out not to match. All of this is sort of lost. It’s a struggle for a lot of folks.

The best representations I’ve ever been with, before we saw the design, there was this statement of, “The research taught us this, and so we learned that the customers are trying to get to this result, but right now they get stuck here and here.” It only takes a minute to say that, but they go back to that and make sure that everybody’s on the same page.

Then they say, “And then we tried a bunch of designs.” In many cases, in the best of presentations I’ve even seen, they actually show some of the designs they threw out and talk a little bit about, “Well, we first tried this, because it seemed like the obvious thing. But then we realized it didn’t work for this case or it didn’t work for this reason.

“And so we then evolved it and we got to this thing, and now here’s the design we ended up with. And let’s go back to that scenario. The user’s going to start by telling us what they need, and then they’re going to click on this, and that’s because we want to be able to give them the right information,” and then boom, all the way through.

Kim: In addition to that, an effective presentation is specific about which user.

Every product in the world has more than one user. Regardless of whether you are a fan of personas or not, you want to be specific about, “Look, we’re talking about users like this kind of person or that kind of person, and this is the one we’re focused on right now.”

When people inevitably say, “Oh, well why didn’t you design it this way?” or, “I think it should have this feature,” or, “This whiz-bang button, that’s my pet peeve as a stakeholder,” you can say, “Ah, yes, but help me understand when this persona or this kind of user would do that, because they actually don’t care.”

That way, you can take it out of the context of you, the designer, have a different opinion form the CEO — which is an argument you’re always going to lose — to you, somebody with access to information about user behavior, can bring the conversation onto some neutral ground so everybody sees, “OK, yeah. We’re using the same evaluation criteria here.”

That tends to make those conversations go so much better.

Jared: It’s interesting. While you were saying that, I was just thinking. Twenty years ago, when we started this conference, the conversation was all about personas. We talked about personas. Then scenarios were sort of this thing that dangled off the persona. It’s interesting now that the conversation is all about scenarios. When necessary, we bring the persona in to talk specifics about the users.

As I thought that through while you were talking, it occurred to me that, to this day, personas are still a little controversial. There are still people who stand up and, for whatever reason, say, “Personas are a dumb idea. We create stupid personas, then we design for them, and we create bad designs.”

No one ever says anything like that about scenarios. I have yet to see anybody say, “Oh, we should never use scenarios when we design.” [laughs]

Kim: It’s funny because, to me, the personas and scenarios are intertwined. If, for some reason, you’re allergic to personas, I think you can do something similar by picking an individual from your research who seemed to represent a behavior pattern. Either way, you really need to do the analysis about the behavior patterns, whether you give them fictitious names and faces or not.

There’s a lot of resistance to personas out there, mostly because people get them wrong. If people have had an experience with badly done, so-called personas, it tends to sour them on the tool. You get people who over-do the fiction part, who just make stuff up and don’t really use behavior patterns based on research.

Or, they focus on the creative writing aspect and worry about what the dog’s name is and everything else. Who cares?

Jared: The dog and the Hummer.

Kim: Yeah. The essence of the persona is the behavior and the goals. If 95 percent of your persona details are not drawn from the research, then, yeah, you’re doing yourself a real dis-service.

Jared: Have I ever told you my favorite dog and Hummer story?

Kim: Oh, no. Please do.

Jared: One of the red flags that I see in personas is when I get a persona description that’s got some clip art person, almost always white. [laughs]

Kim: And smiling. Don’t forget smiling.

Jared: Yup, smiling person, happy customer. They describe this thing in three paragraphs. They describe who this customer is, but there’s at least two sentences that describe their pets and what they drive.

Kim: Because somebody saw that on a checklist somewhere and decided it mattered.

Jared: It makes it personal, right? We have the CEO, and he’s got a greyhound and drives a Hummer. We’ve got the mom and she drives a Mini Cooper and she has an Irish setter, and they say what the name is, too, “The Irish setter’s name is Butch and the Greyhound’s name is Killer.”

A client says, “Hey, we’ve had another consulting firm. We worked with them to create a set of personas. Do you want to review them?”

I said, “Yeah! I’d love to.” Sure enough, first persona I read, there’s a dog and a Hummer. They’re both right there, and I’m like, “Huh. OK.” This was a firm I had a lot of respect for, so I’m like, “Wow, I can’t believe they went down that road.”

Then, as I got to learn more about the project, it turns out that the project was for the Home and Garden Television Network HGTV. The thing that these personas were for was a project search engine. The project search engine would help you find the best plans and recipes for home improvement projects.

Kim: So your Hummer is relevant.

Jared: Here is the deal. After doing their research, one of the things they found, and this surfaced in the research, was that if you’re doing do-it-yourself home improvement projects, the car you have actually dictates some of the materials you can cart back and forth.

People who have pets have special needs with regards to pet-safe materials. If you’re re-doing the bathroom floor, what happens if the dog runs into the work, as it’s being done, and gets into the grout or the chemicals as the flooring? Is it going to be a safe environment?

They were trying to incorporate in the personas the fact that some people had pets, and some people and big cars and some people have small cars. If you drive a Mini Cooper, it’s a different materials supply than if you have a pick-up truck.

Kim: Some of these biographic details in personas are totally legit. They’re meant to reinforce certain things. For example, if I tell you, “This persona shops at Walmart and that persona shops at Nordstrom,” that’s going to reinforce certain characteristics about those personas, and that’s totally legitimate.

Jared: The rule of thumb, I’ve sort of come to this, and you can tell me if you have a similar one, “Can I point to a design decision that would be effected by that sentence in that persona?”

Kim: Yes.

Jared: If I can talk about, “Well, people with small cars will need certain types of projects than people with large cars, with huge payload capacity, will have different requirements for the projects. Then, boom, it should go in the persona. But, if I can’t talk to a specific design element from day one, then maybe we should leave it out.

Does that work for you?

Kim: Yeah. That’s a fair criterion. One thing you have to be a little bit careful about is it’s not always purely interaction design decisions. Sometimes, it’s a visual design decision or a copy tone decision. Sometimes it’s about the emotional aspect of the design that part of the persona speaks to. It’s not purely functional stuff, too.

If you’re just telling me, “It’s the dog, Henry. They went to college here and they drive this car,” because you think in some formulaic way that should be part of a persona, no. All that’s going to do is undermine the credibility of the tool and make your team roll their eyes and go, “What is this fictitious crap that the design team is getting paid to make?”

Jared: Again, if you can’t tell the story of how this came from the research and how it makes a difference in the design, it gets in your way.

Kim: Right.

Jared: Wow. I always learn stuff when I talk to you. It’s always a pleasure. I’m so excited that you’re coming back this year for our 20th year to do this.

Kim: Twenty years, congratulations on that, by the way.

Jared: We’re just going to keep doing it until we get it right.

Kim: All right.

[laughter]

It’s pretty darn close to right, if you ask me.

Jared: Thank you.

Kim: I keep coming back, because it’s a really awesome event.

Jared: Thank you for that. We try really hard. We focus a lot on the design. It’s part of what we do.

Kim, thank you so much for talking with me today.

Kim: Always my pleasure Jared, thank you.

Jared: For all you who have been listening, thank you so much for giving us your attention. If you enjoy these podcasts, please take a moment, go the iTunes, click on the appropriate number of stars, leave us a comment. That really helps us a lot.

Thanks for listening and thanks very much for encouraging our behavior. We’ll talk to you next time. Take care.

User Interface 22 Sponsorship Opportunities

July 17, 2017

At the User Interface 22 Conference, participants immerse themselves in full-day workshops that go deep into the techniques and practices, delivering the theory and expertise.

Be a part of the conference experience with hundreds of designers as they roll up their sleeves, get down to work, and change the way they design forever. Our three-day event includes two days of master-grade full-day workshops, a day of featured talks, and a captivating keynote from Jared Spool.

Below are a variety of sponsorship options for the User Interface 22 conference, November 13-15, 2017 in Boston, MA.

Not seeing what you want? We’re happy to customize a sponsorship that works best for you.

1. Printed materials and marketing branding (limited to 2 sponsors)

If your main goal is for name and logo recognition, this is a great option, as you'll be part of all printed posters (and we print a lot of them). We’ll include your logo or company on each poster and attendee email template.

2. Lanyard Sponsorship (limited to 1 sponsor)

Everyone will see your company name and logo! All you have to do is send us a designated number of lanyards. We’ll give you the specs on size and color - what you put on the lanyard is up to you.

3. Printed Flyer or Give Away Handout (limited to 2 sponsors)

Everyone will receive an item or flyer with their registration materials. All you need to do is provide the item or flyers and ship them to the hotel. We’ll do the rest.

4. Exhibit Table (limited to 3 sponsors)

Get an exhibit table in the break area. You can market the table in any fashion you like and are welcome to promote give-aways and materials. Collect contact information at your table (since we are unable to share email addresses and phone numbers.)

*Your sponsorship includes additional benefits we list below.

5. Monday Night Peer Dinners (limited to 3 sponsors)

Treat a group of people to dinner on Monday evening, November, 13. We organize 1-2 tables of 8 in 5-7 restaurants for attendees to meet up and have dinner with you. Sponsor as little as one table to all 14 tables. You’ll have a company representative at each table. We promote this opportunity a week before the conference along with Sunday and Monday and attendees sign up in advance. Maximum number of attendees is 112.

This sponsorship does not include any conference passes or the added sponsorship items listed below.

6. Party Sponsorship (limited to 1 sponsor)

Be the host of our Tuesday evening conference reception. We’ll load you up with a stack of drink tickets to hand out so you can meet and greet with the attendees. You’ll be everyone’s best friend.

Additionally, you’ll have a small table during the reception that you can use for demos or for a general meeting area. We’ll promote your sponsorship throughout the day on Tuesday.

7. The Big Shebang (limited to 1 sponsor)

Get the best visibility and the most involvement when you participate with an exhibit table for all three days, branding sponsorship, and the party sponsorship.

*Your sponsorship includes additional benefits we list below.


*Additional sponsorship items automatically included in noted sponsorships

On Tuesday, during the conference, we'll introduce your company. Jared is great about weaving a story on why attendees should check you out, but we’ll need you to provide any key points you want Jared to say.

List of attendees - At the conclusion of the conference, you’ll receive an attendee list for those who attended the conference. The list will include names, companies, and titles.

Company handout – We’ll include a 1-page flyer from you to handout at registration on Sunday-Tuesday. We’ll need to approve the handout prior to distribution.

Should you want to send additional employees or friends to User Interface 22, beyond the number included in sponsorship, we’ll provide you a promotion code for $300 off the current price once you become a sponsor.

Please reach out to sponsorships@uie.com to learn more about these and other sponsorship opportunities.

Despicable Design – When “Going Evil” is the Perfect Technique

July 13, 2017

Once the product team was settled in the room, I delivered the instructions with the customary evil laugh:

I want you to come up with ways we could make the design much worse. How would we make a truly horrible experience for the user? What would make this product evil?

This isn’t how most teams choose to start working on improving their product. Sometimes, a difficult impasse requires an unconventional approach.

This team had gotten stuck. They were a dozen smart, experienced people, each with a different perspective on what their product needed. Nobody was giving in. The team’s executive asked me to break their log jam.

In the room were three designers, four developers, two product managers, a subject matter expert type, and a couple of executive “business owners.” Each had their own agenda on where the product should go. None of them were talking about their users.

As the team filed into the room that morning, I broke them up into small groups of three, spreading each role across separate groups. I then asked each person to grab a sheet of paper and make their own list of ways they imagined the product’s user experience could be made worse.

After validating they’d heard me correctly (“Wait. Did you just say _worse?”_), they started their list. They each had so many great ideas. “Make it respond slower.” “Add more steps.” “Add errors into the data.” “Have it crash randomly.” “Issue confusing error messages.”

After a few moments of working on this in silence, I asked them to share their ideas with the others in their small group. The room burst alive, as they compared their wild ideas. There was laughing, snickers, and exclamations of “Oh, that’s good!”

In each group, I assigned the person who spoke first as that group’s recorder. They were to track all the ideas the group had.

After they’d heard each other’s contributions, I asked them to build on it. What new ideas for a horrible experience were inspired by listening to their fellow group members? They should write that down, too.

Slowing Down The Designers To Make It More Fun

I love this exercise for many reasons. I love how it immediately gets everyone involved, no matter what their background is. It’s a perfect UX design exercise when you have non-designers mixed in with trained designers.

In many other exercises where you ask a group to talk about user experience, the designers often take over. They have the experience and generate ideas faster than their peers, so they dominate the discussion. This has the effect of pushing the non-designers aside.

Yet, in this exercise, making a design worse goes against every bit of training those designers have. It slows them down.

The people who believe they’re not designers can jump right in. A bonus is there’s no wrong answer. You can’t make something “not bad enough.” There’s always room for more badness.

Plus, it’s fun. Giggling. Laughing. Snickering. The room is alive and vibrant. This is a creative exercise with no downside. Everyone gets involved.

All This Fun Is A Seriously Important Exercise

As they’re doing this simple, fun exercise, they are focusing on the users. This is critically important, if we want the team to go beyond just building features to meet business objectives.

There’s no way to participate in this exercise without thinking about the user’s experience. To come up with an idea, a group member must think about what could make a user miserable. At the core of this is the user’s experience.

Every time someone presents a new idea to their group, you can hear an audible moan from the others. A moment of pity, followed by the glee of achieving the objective for making that user just a little more miserable. Those moments of pity? They are, in their strange way, building sympathy.

What emerges is the realization that the team could make their design’s experience much worse. No matter how bad they think it is now, there’s always room to make it much, much more miserable for the user.

That realization is important, because if they can make it worse, that means they can make it better. And if it’s this easy to imagine a worse experience, how hard is it to imagine a better one?

Mapping the User’s Journey Into Hell

After the groups each have a few minutes to conceive their list of ways to make the experience totally and completely horrible for their users, I ask each group to make a story. I call it the User’s Journey Into Hell. What are the sequences of events the user will encounter, where each event just delivers a bit more frustration than before?

By putting their evil-doing into a timeline, they see how a user journey map works. As they try to squeeze every idea they’ve generated into this timeline, they need to think about what their user is trying to accomplish.

I’ve learned that, in this exercise, the most frustrating designs are the ones with lots of steps, each getting increasingly more hellish. Groups who cut the user off in the first step with a solid Nope don’t get as much pleasure from the exercise as those who envision a long torturous sequence.

After they’ve got their journey mapped, I ask them to share it with the group next to them. As the groups swap their tales of user hell, I see them realizing that there are more dimensions of pain they hadn’t really considered before.

After the groups have shared with their neighboring group, it’s time to update their timeline with any new ideas they might have. They see how inspiration comes from many sources while also looking out for better ideas than what they initially come up with.

Pulling out the Attributes of Experience

Now, for a bit of reflection. I ask each group to look closely at each miserable moment in their journey-from-hell.

What was it they changed to make it so miserable? What name would they give that attribute? If they made the design much slower, they might name the attribute “response time.” If they added errors into the data, they might name it “data quality.”

I insist they divorce each attribute from its evilness. Making it a neutral term means it could be used for evil or for good. By generating a list of the attributes, the groups see how they can control the user experience through a collection of independent knobs and levers.

Discovering The Good That Lives Within

After they’ve generated a complete attribute list from all the hell-making experiences in their user’s timeline, I ask them to think about improving the design. For each attribute, what would be an idea or two on how to improve the current design?

For example, how might they improve response time? Reliability? Data quality? Simplicity? What would that look like for the user?

Could they create a revised user journey—one that’s better than the current design—using each attribute from their journey-from-hell? Most of the time, it’s pretty easy for teams to do.

After the teams have built a better journey, I ask them to share with a neighboring group again. What have they learned about how they could improve the user’s experience?

Stealth-Mode Design Literacy

I’ve been this evil for a long time. When my kids were little, the only way I could get them to eat vegetables was to hide them in other food. My son loved pasta, so I’d mixed pureed peas into the tomato sauce. I had a dozen ways to hide vegetables in food he loved. Stealth-mode nutrition, I used to call it.

If I’d told this team that we would spend an hour discussing the basic elements of design literacy, they would’ve revolted. There was no way I could waste their time doing that.

Yet, here we are, an hour into this exercise and we’ve accomplished that and more. We’ve focused on the user’s experience. We’ve mapped the experience into a journey. We’ve broken the journey moments into attributes of design quality. And we’ve brainstormed ways to improve the quality of the experience. Most importantly, we did it with a cross-discipline team who contributed equally, no matter their prior design expertise.

Without them realizing it, I can get a team to see the power of great experience design. They now have the tools to move forward, breaking their log jam. And they can do it collaboratively.

I had an evil plan all along. And it worked! [Evil laugh.]

Techniques like this one are what you’ll learn at this year’s User Interface 22 Conference, November 13–15, in Boston MA. Bring your team to full-day workshops, like Kim Goodwin’s Using Scenarios to Solve Problems and Richard Banfield’s Leading Design Sprints to Jumpstart Team Collaboration and get the techniques and methods for delivering best-of-class designs.

A Design System isn’t a Project. It’s a Product, Serving Products.

June 29, 2017 by Nathan Curtis

Shifting Focus from Design and Development to Managing and Marketing a System

Design systems result in tangible, often gorgeous outputs like a living style guide or array of design assets. When getting started, it feels like a project, evolving from early concepts to a celebrated (first) release of those assets for other people to use.

“We did it! We launched a guide. Mission accomplished.”

Celebration is justified, no doubt. You did achieve something, and making useful things for others feels great. However, be careful, because you’ve not yet realized actual business value. An enterprise realizes that value — actual cohesive experiences, realized efficiencies in development — when other teams pick up the system and ship it in their product.

A design system’s value is realized when products ship features using parts from the system.

In those quieting days following a system launch, a systems team starts to realize “What do we do now?” Worse, they (and those managing their time) think “Now we can go back to doing what we were doing before.” There’s no funded persistence. No ongoing commitment. Questions of “Will it last?” start to emerge in thoughts and conversations.

Changing from a Project to Product Mindset

Focusing on style guide delivery as the climax is the wrong story to tell. A system isn’t a project with an end, it’s the origin story of a living and evolving product that’ll serve other products.

A style guide is an artifact of design process. A design system is a living, funded product with a roadmap & backlog, serving an ecosystem.

-@nathancurtis

Thinking as a product changes perspective: it’s now not about us, it’s about serving our customers. How do we do that? Applying well-established approaches for product management and product marketing is a great start. Once recognized, a system team can adopt familiar and predictable tools and terminology to help them succeed.

Additionally, the “system=product” model also helps team composed of product designers and developers to recognize:

Design systems isn’t just product design and development. There’s product management and marketing too. We’re not good at that, nor do we want to be.

They may lack the talent for “product management stuff” and may not have the taste for it. Now self aware, they can choose to learn and apply such skills to fill the gap or find someone else who can.

When I meet a design system team for the first time, I don’t start with “Can you show me your awesome living style guide?” It is awesome, they are very proud of it, and I love learning about it. But such demos rest in the shadow of a more essential understanding of their system’s – their PRODUCT’s – marketing and management approach.

Spreading Your System to Their Products = Product Marketing

To have a product means knowing and serving your market:

  • What products use or may use your system? Regardless of your system’s reach, know your target market. You need a strong sense who you serve, their relative priority in influencing your work, and where each is headed.
  • When will they ship using the system? It’s very rare for an entire enterprise to pause individual work in order to launch together using a system. Instead, discussing how a design system fits is a product-by-product endeavor that seeps into a their roadmaps, sprint planning, and story requirements.
  • How will you align with them? You may get to know product managers just as much or more than developers. A system’s product manager (if you have one by name or responsibility) is knowledgable of or even participates in strategic activities like quarterly release planning across a portfolio. That said, effective alignment with product managers usually results in “alignment” meetings as well as coffees, lunches, and hallway conversations.
  • How do you promote and sell to them? Your marketing, which often involve compelling demos and presentations, effective documentation, regular communications (such as email updates and blogs), onboarding activity, and training.
  • What will each type of customer need from your system? There’s a way to disarm the tension adopters feel when intimidated by the system’s vast scale or imperfect goodness-of-fit. Most systems contain areas like color palettes, icons sets, certain UI patterns, and more (I call ’em subsystems) that aren’t universally relevant. Everything isn’t always meant for everybody. So how can you succinctly tell each what’s most helpful for them?

Sustaining Your System = Product Management

Imagine what your VP thinks: “Should I fund 2.5 full time resources to work on a style guide full time if they can’t tell me what they’ll do in the next three months? They can barely muster a coherent definition of what they’ll do in the next two weeks. It seems everyone is doing everything and nobody is responsible for anything.”

For a design system to thrive and survive, it needs a sufficient level of management.

  • Who’s making the decisions? Modern design systems have a product manager who’s driving decisions, assertively aligning with partners, and serving as the go-to person
  • Who’s doing the work? Sustaining a design system can involve a significant amount of design, development, writing, and other work done by people committed (at least partially, > 4hr/week) to the endeavor.
  • Who’s paying for it? It’s near impossible for a system to survive long term without a sponsor deliberately providing budget in the form of properly allocated time.
  • What are each of you working on right now and where do you record and prioritize things you might work on later? Yup, time for task management, which many high-performing teams increasingly formalize into a backlog over sprints using tools like Github and Jira.
  • What can your customers (products using the system) expect over the next 6–12 months? Don’t discount the power of an effective, concisely communicated system roadmap. It generates awareness, discussion, faith that you’ve got your act together, and trust that what you do provides for what they need.

Enterprises are waking up to this, forming permanent positions, with titles at Salesforce and hiring product managers specifically for systems teams at companies like Etsy and Google. If you don’t have thoughtful, reasoned answers for the questions above, how can you expect someone to fund your effort?


Nathan Curtis has been involved in UX since 1996, when he started focusing his creative energies on IA, ID, usability, and front-end development. He’s also an entrepreneur at heart, having founded the renowned EightShapes in Washington, DC. You can follow Nathan on Twitter at @nathanacurtis.