text:
Here's an excerpt from the article
I have to think about the user, so I typically start with a text file. I create the content in a text file based on conversations with the client and with end users. I then hand it to the designer and the designer really builds the site around that. Once I hand it to the designer and some comps come back, I might make a few UI/UX suggestions in the notations as part of the content.
Otherwise, I leave it entirely up to the UX designer to create wire frames around the content itself. In all cases so far, the designer has really loved this process. It's liberated that person from having to think about the content because it's already there and that's what's ultimately speaking to the user. It's created a structure and a process around the most important stuff to be communicated without requiring the visuals to lead back to it.
Read the article: Making Content More Usable for both Designers and the End User.
How do you begin your process of moving from content into design? Tell us about it below.]]>
Here's an excerpt from the article:
In many projects, people ramp up slowly, finishing up their old obligations before starting. Without having everyone in the same room and focused, the project takes forever to get to speed.
With a design sprint, everyone starts at the same time with this focused activity on the new project. Even if, the following week, they have to return to their previous project to tie up loose ends, the sprint has given the team this focused burst to start with.
Read the article: Design Sprints: An Ignition System for Innovation Project Teams
How does your team benefit from design sprints? Share your thoughts with us below.]]>
Here's an excerpt from the article:
I explained how Saying 'no' was an advanced approach for dealing with product teams that waited too long. The basic idea is to tell them you'll only work with them if they bring your team in early enough. Otherwise, they're on their own.
The approach works because it puts pressure on the product teams that aren't cooperating. It shows those team leaders they need to change their habits to get the help of the UX team.
Read the article: Every UX Leader Needs A Unique UX Strategy Playbook
What are some of your playbook strategies? Share them with us below.]]>
Register today for the UX Immersion: Interactions conference, April 18–20, 2016 in San Diego. But hurry because the event starts next Monday.
Your UX Immersion: Interactions registration Includes:
Save your spot, guarantee your workshops, start using All You Can Learn, and avoid missing out on what promises to be the UX event of 2016.
Is your organization serious enough about design? Do your products and services need great user experiences to stay competitive? What's your plan to counter the inevitable resistance to becoming a design-infused organization?
Every minute of this 1½-day workshop is about you, your team, and your organization. You'll evaluate dozens of UX strategy plays to identify the perfect combination for your organization, such as:
Return to your office ready to implement the smartest plays in your UX strategy playbook and drive your organization to becoming competitive through great design.
New practices and techniques meet theory and expertise at the UX Immersion: Interactions conference in San Diego, CA April 18–20, 2016. Move beyond inspiration and immerse yourself.
On Tuesday, April 19 have your mind expanded, as you explore the edges of what interaction design is all about with six industry leaders plus a keynote from Jared Spool.
Chris Risdon
Chris will explore the importance of engaging with users at the behavioral level. He'll explain prototyping's role in closing the feedback loop on your designs. Leave with an understanding of how to best observe and elicit behaviors.
Dan Saffer
Dan will share his easy, practical tricks for getting unstuck, as well as simple daily practices that you can use to keep your mind energized and your creative tank full. You'll be so inspired, you'll want to use them all right away.
Change the Story—and the Conversation
Marc Rettig
Marc will show you how to facilitate interactions between people and groups that lead to meaningful change. You'll leave this talk feeling empowered to go back home and start your own conversational revolution.
Crushing Enterprise App Navigation Issues
Hagan Rivers
Hagan will show you where to start, how to approach the problem, and what success looks like. You'll get a feel for the philosophy that guides her work, the decisions she makes during the process, and the types of user research she regularly employs. You'll go home with a whole new outlook on enterprise navigation.
Turbocharge Your Product Design With Game Thinking
Amy Jo Kim
Amy Jo will show you how a game designer approaches their product development and how they get to a design that their users love. From her research in how game designers think, you learn the value of refining and testing a simple, stripped down MVP (minimum viable product), long before you start adding all the fancy stuff.
Your Product Idea Is Great. But Who Cares?
Richard Banfield
Richard will show you how to stop making assumptions about your users, and figure out what they really want and need. He'll demonstrate the value in doing fewer things better, and using features to give your users superpowers. You'll leave his talk dying to put your new knowledge of biological design principles to work.
Jared Spool
Every part of the organization must be infused with an understanding of great design. Jared will show you which path organizations take to become design-infused and how a centralized UX team is a stepping stone to a more UX capable organization. You never thought design strategy could be so entertainingly motivating.
Save money and guarantee your spot in the workshops of your choice. Register for the UX Immersion: Interactions conference, April 18–20, 2016 in San Diego. But hurry because the lowest rate of $1,975 is only good through this Thursday.
Your UX Immersion: Interactions registration includes
Save your spot, guarantee your workshops, start using All You Can Learn, and avoid spending more of your money when you sign-up through this Thursday.
Here's an excerpt from the article:
Throw smart people together. Suffice it to say that working with smart people is satisfying and challenging. But collaboration isn't just about smarts. It's about providing a framework for working together. Just as important as intelligence is a willingness to work within the framework.
Put people in the same room. Collaboration doesn't just happen when people are face-to-face. Collaboration must be embedded in the culture of a team, such that the team thinks about working together—depending on each other, seeking out contributions and critiques—even when they're not in the same room.
Read the article: Misconceptions about Collaboration
What collaboration techniques do you find successful? Share them with us below.]]>
Here's an excerpt from the article:
Authentication is a necessary evil in today's world of trust, privacy, and security. It is designed to be selectively usable. A good authentication system needs to be unusable for unwanted intruders. However, it needs to be extremely usable for the legitimate users. Poorly designed authentication systems fail in two ways: either they let in the wrong people or they make it too hard for the right people.
But authentication shouldn't be the focal point of a users' experience with our designs. In fact, if the person is the right person, it shouldn't be anywhere on their radar.
Read the article: Focusing On What Our Users Shouldn't Focus On
Are you distracting users from successfully using your design? Share them with us below.]]>
Save $200 and guarantee your spot in the workshops of your choice. Register for the UX Immersion: Interactions conference, April 18–20, 2016 in San Diego. But hurry because the lowest rate of $1,975 is only good through March 31.
Your UX Immersion: Interactions registration Includes:
Save your spot, guarantee your workshops, get the lowest price, and start using All You Can Learn when you sign-up through March 31, 2016.
Corporate life expects us to be experts, to know the answer to every question. We make "requirements", which turn out to really be assumptions, but because we never call them assumptions, we never go about testing them. This is as much a social political issue as anything. The higher you are in the organization, the more you're expected to just know the answer.
In this episode, Jared and Richard Banfield explore the role of design sprints in cultivating an environment where it is ok to say "I don't know". Allowing yourself to admit this, and allowing your teammates to as well, leads to greater collaboration as you explore the answers together.
Richard Banfield is joining us in San Diego, CA on April 18–20 for our UX Immersion: Interactions conference. He's teaching a daylong workshop on facilitating collaboration across your organization bypassing the usual politics. For more information, visit uxi16.com.
Recorded: March, 2016
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]
Jared Spool: Welcome to the UX Immersion podcast, I'm Jared Spool.
Being a designer, leading a design project, means putting it out there, making the calls. Everyone expects great things from us. And, it's scary. Very scary.
That stops us from doing the right thing. From admitting the truth.
Richard Banfield: We are so scared of being wrong, we're so scared of saying, "I don't know," that we'd rather just not have the conversation.
I'm Richard Banfield, the Chief Executive Officer of Fresh Tilled Soil. I'm the guy at the office that everybody wants to avoid having in a conversation, because I'm the highest paid opinion. That's not very useful.
Jared: Richard's been studying what happens when people avoid these conversations. He's found the fear of being exposed as a fraud simply by saying "I don't know" and allowing for that conversation to occur, is very real.
For example, take how we start a project. The conventional approach is to create a list of requirements. More often than not, these requirements turn out to be assumptions. We're just assuming our customers need the things that are in that list.
Richard: As my very good friend, Dave Cancel often says, "The worst thing you can do is make these assumptions, because none of us are right any of the time."
Jared: Even though we're not right, we continue the practice of listing out requirements and making demands.
A large part of the problem lies in the hierarchical structure of organizations. The higher you are in the organization, the more you're expected to just know the answer. It's good to be king, most of the time. Sometimes, when that fear of exposure rears it's head, you don't want to seem like the one who's got shit all over them. Even when someone sits at the top of the hierarchy and is expected to have the answers, they can still be wrong.
Richard: The hierarchy may disincentivize them to talk to each other, but it also might be political. It might be that there are these victims that people are protecting, also protecting their personal space, their jobs, their titles.
In any system that has some kind of complexity or hierarchy, there is an inferred politic. There is a structure that decides who has the last word or who has the most say in any conversation.
In our organizations that we work in, the typical business, there is a hierarchy that is dictated to by somebody's title, their longevity with the organization, their domain knowledge, their gender, their age. All of those things help people understand where they fit into those conversations.
Even in the most non-political organizations out there, there is still some kind of societal influence or cultural influence over the politics.
Jared: Politics exist anywhere there is more than one person. If you're the sole inhabitant of your desert island, then your reign is supreme and everything you do pleases everyone, because, everyone is you. But, as soon as there are competing ideas from multiple people, they must discuss them to arrive at a consensus, and to evolve the those ideas. The trick is finding the right tactic to advance these discussions.
This is where design sprints come in. A design sprint is an alternative to the conventional requirements gathering process. The project leader brings a team together to list assumptions and validate them with real users and customers. The nature of the design sprint's structure turns saying "I don't know" into a good thing. This is because you just saved the organization the pain of going down the wrong path.
Richard: In some kind of accidental way, design sprints turned out to be this UN of design methodology, where you would just get people in a room together and you'd say, "Why are we fighting about this stuff? Don't we all really want the same things? Are we not trying to make something good for our users, our customers, our marketplace?"
What the design sprint is structured to do or designed to do, is to avoid letting the people who have those big opinions, or as we call them, the HiPPOs, the highest paid opinions, to allow those people to be quantified at the same level that the junior person's opinion might be.
If you're the CEO, and you have a strong opinion about something, it will be leveled against the person who has no political strength or power. By doing so, you'll start to see these things for the neutral arguments that they are.
What we've noticed, having done — I think we've lost count now — but let's say 100 design sprints, we've noticed that even the people who have a strong opinion, like this idea, because even they know that their opinions are based on assumptions. They secretly don't want to be found out either, that's why they speak so vehemently about their own choices.
They also want to know that there's a system that will validate the choices that they make and not just base it on assumptions. They're just as scared as everybody else. This design process gives everybody the opportunity to feel safer. Even the CEO. Even the COO. Even the founder of the organization.
Jared: Organizations, as we know them, were modelled after the structure of a military unit, with a commander at the very top. Orders flowed down and were never to be questioned. The commander could never be wrong. That sows dissent in the ranks.
Modern day organizations have inherited this structure without questioning it. This is what gets us into trouble. Those people in charge aren't any more right than anyone else.
Richard: Somebody recently wrote an article that was entitled, "The Hardest Three Words in the English Language to String Together Are, 'I don't know.'" Because we've got ourselves into this situation where we're all assumed, because of our title and our domain knowledge, and the roles that we have, to have answers.
People come to us and say, "We've got this problem," and we're immediately assuming that they're asking us to come up with a solution. Whereas, the right answer is to say, "That's an amazing problem. I don't know the answer. Let's figure that out together. Let's work on that together. Let's figure out what the best solution might be."
We just don't have the confidence to do that, because we were told right from the get go when we start school, that there's only one answer for something. You get given a math test, and the math test says there's a right answer and a wrong answer. You get given an English test and there's a right answer and a wrong answer.
We grow up with this belief that there are only answers. Instead of saying, "I don't know, but here's something else that we could consider." Or, "Let's talk about that and come up with the best answer." We're predisposed to think that for every problem out there, there has to be an answer and we're supposed to carry that in our back pocket.
Jared: Freeing ourselves of the dependency of certainty really opens up the possibilities for solutions to challenges the organization is facing. There's rarely just one way to accomplish anything. There may be preferred ways, or classic ways, but it doesn't necessarily mean they are the best, or even most applicable for any given situation. Fostering a culture where it is ok to admit that you don't know the answer instantly develops strong collaboration.
Richard: The thing that we notice most often is that once you've given permission to say, "I don't know," or, "This is an assumption," or, "We should go and test that," or, "These things that we've been basing all of our future roadmap decisions on, need to be made into facts, so that we can be clearer and less ambiguous about our future."
Once that happens, it's much more free. The conversation tends to open up. There tends to be less fear in the tone of that design or product conversation. That's the first thing we notice.
The second thing we notice is that, now that they've been given an opportunity to work through a process and that process is familiar to them, they immediately start thinking about how else they can use that process in other parts of their organization.
Jared: Allowing yourself to say "I don't know" is hard, but it is a skill you can learn. You need an environment that not only supports, but encourages it, so you can develop processes that assist in discovering the answer to what it is you don't know.
Richard: None of my school, or education, or experience could have possibly prepared me for that. What I need is a system or a process that allows me to face that ambiguity with a whole bunch of confidence and say, "I still don't know the answer, but I do have a process that's going to get me to the answer."
Jared: To create great designs, especially those that are innovative in the marketplace, we need knowledge we don't have today. Knowledge about our users, about how they work, about what they need to make their lives better. If we don't get this information, or we guess wrong, we'll fail.
Admitting that we don't know everything is what fuels our curiosity. Admitting it to ourselves is much easier than admitting to another person, or an entire team, especially when we've been designated the expert.
And for those other people we have to collaborate with, we also have to make it safe for them to admit that they don't know everything. Structured activities, like design sprints, make that possible. When we create safe, collaborative environments, we open ourselves up to learn the things that make our work great.
That's why we became designers in the first place.
The UX Immersion podcast is brought to you by the UX Immersion: Interactions conference, which will be April 18th to 20th in San Diego, California.
Richard will teach his full-day workshop, Leading Design Sprints to Jump-Start Team Collaboration. He'll walk us through what it takes to facilitate a sprint, showing us all the techniques he uses to make the magic happen and kick start projects quickly. We've put a detailed description of everything you'll learn from Richard on the conference web site, uxi16.com.
The UX Immersion podcast is produced by myself and Sean Carmichael. You can find more information about the UX Immersion podcast on iTunes and at the UX Immersion: Interactions conference web site, uxi16.com.
We'd like to thank Richard Banfield for being a part of this episode.
You've been listening the UX Immersion Podcast, part of the growing UIE Podcast Network. Thanks for listening and for encouraging our behavior.
Here's an excerpt from the article:
Step into the Wayback Machine, Sherman, and set the dial to 1994. You'll find me in a conference room, explaining to a room of developers and product owners (back then, we called product owners either product managers or business analysts) how we would design their new product in less than a week. The expression on their faces would be one of OMG! This dude is insane. (Though, "OMG" or "dude" wouldn't be common parlance for at least another half decade).
We look at paper prototyping now and we think how quaint. Yet, back in 1994, it was a radical departure from established practice. In those olden days, design wasn't done the way it is today.
Read the article A Bias for Making.
Does your team have a bias for making? Tell us about it below.]]>
Read more about how to convince your boss.
And here's how to close the deal:
Register for the full conference now and enter the code UXIBen to save $300.
You need to be there.
New practices and techniques meet theory and expertise at the UX Immersion: Interactions conference in San Diego, CA April 18–20, 2016. Move beyond inspiration and immerse yourself.
On Tuesday, April 19 have your mind expanded, as you explore the edges of what interaction design is all about with six industry leaders plus a keynote from Jared Spool.
Chris Risdon
Chris will explore the importance of engaging with users at the behavioral level. He'll explain prototyping's role in closing the feedback loop on your designs. Leave with an understanding of how to best observe and elicit behaviors.
Dan Saffer
Dan will share his easy, practical tricks for getting unstuck, as well as simple daily practices that you can use to keep your mind energized and your creative tank full. You'll be so inspired, you'll want to use them all right away.
Change the Story—and the Conversation
Marc Rettig
Marc will show you how to facilitate interactions between people and groups that lead to meaningful change. You'll leave this talk feeling empowered to go back home and start your own conversational revolution.
Crushing Enterprise App Navigation Issues
Hagan Rivers
Hagan will show you where to start, how to approach the problem, and what success looks like. You'll get a feel for the philosophy that guides her work, the decisions she makes during the process, and the types of user research she regularly employs. You'll go home with a whole new outlook on enterprise navigation.
Turbocharge Your Product Design With Game Thinking
Amy Jo Kim
Amy Jo will show you how a game designer approaches their product development and how they get to a design that their users love. From her research in how game designers think, you learn the value of refining and testing a simple, stripped down MVP (minimum viable product), long before you start adding all the fancy stuff.
Your Product Idea Is Great. But Who Cares?
Richard Banfield
Richard will show you how to stop making assumptions about your users, and figure out what they really want and need. He'll demonstrate the value in doing fewer things better, and using features to give your users superpowers. You'll leave his talk dying to put your new knowledge of biological design principles to work.
Jared Spool
Every part of the organization must be infused with an understanding of great design. Jared will show you which path organizations take to become design-infused and how a centralized UX team is a stepping stone to a more UX capable organization. You never thought design strategy could be so entertainingly motivating.
Here's an excerpt from the article:
Remember those "A–ha!" moments in science class when you came to understand a concept by testing it in a simple experiment? That's what we're talking about here. Of course, the teacher had explained the concept to you, but it was by performing the experiment that you actually learned it.
The same idea applies with tutorials. And if you follow the first three rules, this reinforcement will largely take care of itself. It could be as simple as accompanying an action demonstrated in a tutorial with a very subtle bit of visual or aural feedback.
Read the article: Rethinking Mobile Tutorials: Which Patterns Really Work?
How do you teach your users to use your apps? Share them with us below.]]>
Here's an excerpt from the article:
The big problem with a mobile strategy approach is it sends a message to everyone that mobile is somehow different from the kiosk, the desktop, and the customer agent. That it requires a special team, often in their own special place, separate from everything else going on.
That's ok at first, when teams are trying to figure out how they integrate a new technology into the overall experience equation. After all, at some point someone had to decide how the kiosks would work or what systems the customer service agents would use.
Read the article: The Curse of a Mobile Strategy
What is your mobile strategy? Share your thoughts with us below.]]>
Here's an excerpt from the article:
Sadly, animation is considered decorative by the bulk of the web development community. UI designers and interaction developers know better, of course. But when I'm teaching a workshop on animation for interaction, I know that my students face an uphill battle against decision makers who consider it nice to have, and tack it on at the end of a project, if at all.
This stigma is hard to shake. But it starts with us using animation deliberately or not at all. Poorly considered, tacked-on animation will often cause more harm than good. Users may complain that it's too slow or too fast, or that they have no idea what just happened.
Read the article: Five Ways To Animate Responsibly
How do you animate responsibly? Share your thoughts with us below.]]>
Storytelling is a powerful way to measure our understanding of our users and their experiences. But unfortunately, we don't always get the story right. User experience rests more on listening to what the users want to tell us rather than the stories research teams and designers tell themselves within the confines of their organizations. Perhaps it's time to first try story listening before recanting the tales.
In this episode, we hear a story from Mike Monteiro about design going wrong. Jared Spool then talks to Marc Rettig about how the team could employ a technique, the Collective Story Harvest, to take apart the problem and come to new insights. All by listening to a story.
Marc Rettig is joining us in San Diego, CA on April 18–20 for our UX Immersion: Interactions conference. He's teaching a daylong workshop on research techniques for gaining deeper insights. For more information, visit uxi16.com.
Recorded: February, 2016
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]
Jared Spool: This is the UX Immersion Podcast. I'm Jared Spool.
Storytelling is a power tool for user experience professionals. We tell effective, convincing stories to help others connect to the people we're designing for. We use our words to paint pictures about what frustrates our users and our customers and how we, as the agents of change, can make their lives better. Storytelling is an essential UX skill.
Another essential skill, one we don't hear about, is story listening. Story listening is how we enhance our own understanding of what it's like to be a person we're designing for. It's an important research technique. One that can push past the barriers of what we can only learn through observation or interviews, to get into situations that are tough to design for.
To explore how truly valuable story listening can be, I asked Mike Monteiro, who runs Mule Design in San Francisco, to share a story about what happens when design goes wrong. The story of Bobbi Duncan.
Mike Monteiro: The way the story goes is Bobbi Duncan was a freshman at UT Austin. She was interested in music. She played the piano. She sang. She got to school, and she decided that she wanted to join some groups, like you do, make new friends. She joined the queer chorus at UT Austin.
Bobbi is a lesbian, and she hadn't come out to her parents. She used Facebook like everybody does, almost everybody.
She managed through some Herculean effort to actually tweak Facebook's privacy settings to make sure that that happened, so that if she wanted to talk about something that hinted at her sexuality she would make sure that she would tag that in a way that her parents couldn't see it.
When she joined the queer chorus at Austin, the president of the group, he had also set up a Facebook group for the chorus. He made it an open group.
Here's the important part. Facebook made a design decision that when something was posted about you in an open group it overrode your own privacy settings. When he announced that Bobbi had joined the queer chorus at UT Austin, it got cross-posted to Bobbi's wall automatically and overrode all of her own privacy settings.
That's how her parents found out about her sexuality. Facebook told them. They were not happy. They disowned her. Her father disowned her. I hope that four years later, they've come to a reconciliation. I don't know. But that's where it was at the time when I read the article.
Jared: Facebook's design team didn't set out to destroy Bobbi's relationship with her parents. They didn't even know this had happened.
Bobbi had used the privacy settings the way the designers intended. The chorus president also used it the way they intended. The chorus president wasn't trying to override Bobbi's intentions. They were both using the system the way they thought it should work, believing the privacy system had their backs.
The interaction of the two settings combined to make a difficult situation. It took a while to understand how this all went down.
As a designer, listening to Mike tell Bobbi's story shines a strong light on the complexity of Facebook's privacy system. The story gives a deep background, while also showing where the edges of the problem come together. It's at the edges that designers do their best work.
Now, Facebook has an excellent user research team. But Facebook's team had never encountered a situation like this, because user research won't easily identify this type of problem.
Marc Rettig: If a company is relying on its UX or design researchers to be its ears, to be its connection to what's really going on in the lives of customers. That's not a very sensitive ear.
My name is Marc Rettig. I am Principal of Fit Associates, a firm in Pittsburgh. I teach about creating in social complexity, the Carnegie Mellon School of Design and the School of Visual Arts in New York.
Jared: Delegating all the listening in an organization to a small team of researchers isn't sensitive enough. Even a large research team, like Facebook has, is still limited, compared to the entire size of their organization.
Marc: In the bigger picture, we can talk about what it means for an organization to be listening, to open its sensors. So that its decision making, its strategy, its designs, its priorities are connected to what's really going on out there as opposed to the stories that everybody tells themselves inside the walls. They repeat these same stories over and over to each other until we believe that's what the world is like.
Jared: Marc believes that teams need to find a way to put aside the stories they keep telling themselves inside their organization's walls. They need to listen to people who are having a true experience out in the world as they tell their own stories, just like Bobbi Duncan. This is how we get a richer picture of where the design opportunities truly are.
Marc: You can hear it in their voice. Often, when people are telling stories, they overhear themselves saying details that they may not have known they were going to remember until it was in the act of telling.
As they talk about what the story means, they may overhear themselves talking about beliefs or values that show up as they're trying to let us know why that story is important to them, in a way that we wouldn't have thought to ask.
Jared: For the Facebook team to truly get a handle on what happened to Bobbi, Marc recommends they reach out to a bunch of people who were involved in incident: The choir president, other choir members, Bobbi herself, and, if they were amenable, Bobbi's parents. Maybe they bring in people from Facebook's own customer service or others who were involved once the situation became a big deal. The team would listen to each person's story.
However, Marc suggests this has to go beyond just Facebook's researchers.
Marc: If only the researchers listen, then they have this asking too much of them, responsibility of translating what they've heard to other people in the organization.
If you can bring the security people, the web designers, executives, managers, people from across boundaries in the organization to listen to these people tell the stories, that will change the conversation that you have after your customers leave. It's quite powerful.
Jared: This group of listeners participate in a deep research activity called a Collective Story Harvest. In a collective story harvest, you gather a bunch of people to tell their stories to a group of listeners, who will then harvest the stories they collect for the design insights.
Marc: In general, a collective story harvest, you can use it in lots of different ways. You can have a group of people listen to one or more stories in a way we're talking about in the harvest of learning's, and they ask how do we apply this.
Suppose now you've done that and now you've got a bunch of people from within your company, from within Facebook, and they're wondering what to do about it. Now you can have internal story harvesting.
The security team can tell stories about the choices that they've made in the privacy settings. The executives can tell stories about conversations they've had with advertisers and the importance of real names or something like that. The developers can tell stories about their struggles with these issues.
Now, the organization is listening to itself and you can use the same method for that. There's variations on it where you can listen to a lot of stories at once and compare what you've heard.
Jared: Hearing a story second hand invites the opportunity for personal experiences and biases to manipulate the original telling. It doesn't even have to be in a malicious way. One person's set of experiences to a point in their life will influence an interpretation of a story or event in a way another's might not. Having more people hear the story directly allows for a better understanding through discussion.
Marc: I always feel that way, is one of our terrific systemic issues is that we leap to making and don't leave time for, I would say two steps, listening. Then real reflection.
You think we've watered reflection down to grouping sticky notes on the wall, which is analysis, which is different than reflection. We've watered listening down to data collection.
Jared: What it boils down to is this: our users are people. They aren't bits of data that we compile into a design. Each person is different, and they all have a story.
Marc: Story is really powerful. This is not a new idea. There's been people talking about storytelling organizations for 30 or 40 years.
Jared: Story listening — truly listening to our users and their experiences — is an important way to really understand them. You don't have to guess about their needs or wants. Acting on the information you get from listening, especially with a team of folks, requires patience and careful consideration. Knowing your users and their stories is one thing. Reflecting upon those stories and distilling them into something actionable that can help our users in meaningful ways is another.
The UX Immersion podcast is brought to you by the UX Immersion: Interactions conference, which will be April 18th to 20th in San Diego, California.
Marc will teach us how to conduct a Collective Story Harvest, by actually doing it in his full-day workshop, User Research Techniques for Uncovering Deeper Insights. He'll also introduce other great techniques, like a World Café and Situational Modelling. These go way beyond the basic practice of usability testing and field interviews. I selected Marc for this program because spending a day with him will change the way you do research forever. We've put a detailed description of everything you'll learn from Marc on the conference web site, uxi16.com.
The UX Immersion podcast is produced by myself and Sean Carmichael. You can find more information about the UX Immersion podcast on iTunes and at the UX Immersion: Interactions conference web site, uxi16.com.
We'd like to thank both Marc Rettig and Mike Monteiro for being a part of this episode.
You've been listening the UX Immersion Podcast, part of the growing UIE Podcast Network. Thanks for listening and for encouraging our behavior.
Here's an excerpt from the article:
For each of the four techniques, there are variations that modify what they accomplish. For example, one team we recently worked with took a walkthrough and modified it to compare the user stories they'd created to the prototype they'd implemented.
As one designer walked through a piece of the prototype's flow, another designer pasted screen shots on the wall. The business analysts who created the user stories pasted the relevant stories underneath the screen shots they referred to. When it was done, the team could clearly see which parts of the flows were missing comparable stories, and if there were stories that didn't deal with the prototype. It was the first time the two groups had a chance to ensure their work was synchronized.
Read the article: Four Approaches to Share and Reflect on Our Work
How does your team discuss design? Share your thoughts with us below.]]>
Here's our March 10 agenda:
Noon ET / 9am PT • Using Visual Models to Solving Big Design Problems • Stephen Anderson
1pm ET / 10am PT • Timeless Interaction Patterns • Karl Fast
2pm ET / 11am PT • Agentive Technology • Chris Noessel
You'll see examples of current and future technologies that assist us in our efforts to sift through information. You'll leave with get tips and tools for designing for these technologies. Save your spot soon.]]>
Here's an excerpt from the article:
The employees had become accustomed to the intranet and knew how to find the things they needed. Even when an employee couldn't find something, there was always someone within earshot who could. New employees found complete support amongst the existing staff, making orientation quick and easy.
One day, last September, the employees came into work expecting things to be just like they'd been for 9 years, only to find that a brand new design had been launched. Not only were they not consulted on the radical changes, they weren't even warned.
Read the article: Designing Embraceable Change
How have you eased your users into change? Share with us below.]]>
Here's an excerpt from the article:
Hunkering, and its subsequent visual disorientation, can be a crucial tool for the designer. Used properly, it can prevent downstream errors and give new insights into the final results.
One common trap we see designers fall into, is they don't hunker often enough. By waiting too long to see what they are building, the resulting product gets further and further away from their concept. When the design is finally ready, it's so far away that reconciliation becomes difficult. A common trait that all the master craftspeople we studied had was that they hunkered frequently. In some cases, multiple times per day.
Read the article: Hunkering: Putting Disorientation into the Design Process
How does hunkering help your design process? Share with us below.]]>
Here's an excerpt from the article:
Session timeouts are commonplace, an artifact of how poorly our digital world integrates with our real world. If our laptops could accurately tell that someone else has sat in front of it, we could better protect our users from evildoers.
It's a good intention. We're protecting the needs of the business.
Design is what we do when we render our intentions in the world. The American Airlines session timeout frustrates its users, something which is likely not the intention of American Airlines' site designers. How could they have improved that?
Read the article: Deconstructing the Poor Design of a Well-Intentioned Microinteraction
What are some of your experiences with microinteractions? Share them with us below.]]>
When your user gets value from your design, they'll likely make using it into a habit. They'll keep coming back, forming more habits as they continue to get results.
When we add new features, we often force them to break the habits they've carefully formed. That's what makes our users upset when we change the design unexpectedly. Their old habits no longer deliver the value they once did, and now they have to form new ones.
In this episode, Jared learns from Amy Jo Kim how game designers approach the problem of introducing new levels, weapons, and other features. Amy Jo shows how the way game designers think can be easily applied to your designs.
Amy Jo will be joining us in San Diego, CA on April 18–20 for our UX Immersion: Interactions conference. She'll be teaching a daylong workshop on using game design approaches. For more information, visit uxi16.com.
Recorded: December, 2015
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]
Jared Spool: Welcome to the UX Immersion Podcast. I'm Jared Spool.
Imagine it's a day like many other days. You head into the office, only you're cutting it close to make that first meeting on time. That's when you suddenly realize you don't know where the meeting is. You fire up your calendar to find the conference room, and pray it's not too far away from your desk.
Only overnight, while you were sleeping, the upgrade fairies swept in and installed a new version of the calendar application. With a completely new interface. And it all works differently now.
That's a problem. You didn't ask for a new interface, but now you have to deal with one, at a most inconvenient moment.
Amy Jo Kim: There's a really, really simple solution, which is just create a different product for the newcomers, and let the old timers either opt in or not. Photoshop's been fighting that battle for years. Their answer is come out with something different. The old one isn't broken.
I'm Amy Jo Kim.
I am an entrepreneur, startup coach, and social game designer.
Jared: Abrupt, wholesale changes are a surefire way to alienate, and likely frustrate your primary users. Using the product has become habitual. Now your users are forced into a new landscape with no guidance or transition period. To quote the great American philosopher, Homer Simpson, "Going cold turkey isn't as delicious as it sounds."
This is a problem that application designers have been dealing with for eons. But there's a different community of designers who have developed successful approaches. Games designers.
Amy Jo: In game design, skill building and mastery are the through line in the sense of a narrative or a movie, because your experience over time does take the form of a narrative. You are the hero, and it's your journey. You, the user.
Jared: In Amy Jo's experience, framing your customer's journey in terms of that narrative timeline identifies what your users need at the specific point they are at. Whether you're designing for new users to help them to form those habits or introducing current users to a feature, you need to actually plan for and design both of those behaviors.
Amy Jo: When you're designing a customer's experience over time, there are different ways to frame it. The way I frame it, which is coming from game thinking, is to talk about four stages, discovery, onboarding, habit building, and mastery.
If you start with really who is using, playing your app, or your service, your game, you're using your piece of hardware, your fitness app, band, or whatever it is, that user is going to have that experience over time. Those four stages are useful for abstracting how you think about engaging the user at each stage.
Jared: No matter how good our first release is, our designs need to get better. We learn that the first version could always be improved. Our knowledge comes from users who have discovered and started to use the design. There's a better way to use it. There are always new features we can add.
But, there's a risk in adding new features. They can improve your design, especially for new and incoming users. But if not properly introduced, you can create headaches for the current users who have existing expectations of how the design works. How do you avoid failing your most loyal users?
Amy Jo: In terms of product design, and game design, and cool interface tricks, there's many, many, many things you can do to introduce new features. Many of them look like onboarding, because part of onboarding's job is to introduce new features. Every feature is new to the first time user.
The bridge there, in terms of introducing new features, is create experiences that make the features worthwhile. Then work backwards from there. That's where it's contextualized like sometimes it's a contest, sometimes it's a fun little thing.
Jared: An existing user is a new user when it comes to new features. When you introduce a feature, you're turning your most seasoned users back into beginners and restarting their journey. Making those new features worthwhile ensures that people will keep coming back. The first step in that process, though, might not be what you think it is.
Amy Jo: Section one is actually not onboarding and discovery. Section one is habit building and mastery. Even more so, habit building comes first when you're designing — bringing an experience to life.
For that, habit building and mastery those are the stages of regulars and enthusiasts. Regulars are people that are – it's day 21. They're using it. They're our regulars.
Jared: In Amy Jo's experience, it takes regular usage of 3 weeks before the user makes the functionality of your design into a habit – something they do comfortably all the time. Day 21: That's the critical target that you are shooting for to make beginners into regulars, and continue them on their journey.
Amy Jo: But enthusiasts are the people that go deeper and master your system, experts — the super fans. Whatever it is in what you're doing, there's always two to five percent of people that just go nuts. Then they often want to go deeper and they want something more.
Jared: You need to ensure that your new features are habits that your users want to build. Only when you're sure they want to build habits and master the new features, can you turn your focus to how they'll find out about those new features.
Amy Jo: Discovery is turning visitors into first time users. Discovery is like, "What is this? Should I even bother? Is it for me?"
It's your marketing. It's your ads. It's the word of mouth. It's whether discovery is social, or whether it's through ads, or whether it gets handed down through IT.
Discovery happens in different ways, so it's important to understand how this discovery happened for what you're doing.
Jared: You need to ask yourself, do you truly need your existing users to discover these new features? Are you clear what's in it for them if they do? Maybe they can get by with the existing functionality, while you leave the newer designs for your new users?
If your existing users need the new features, then you have to help those users discover them. But this doesn't mean putting a huge billboard ad in your designs, fighting for attention for every new feature. Some of the best products slip their new features in under the radar, letting users discover them almost accidentally, by having them appear at just the right moment.
Once users discover the new feature, you then need to help them start using it. That's where onboarding comes in.
Amy Jo: Onboarding is learning the ropes and you can define on-boarding in different ways. For some companies, it's two months. For some companies, it's the first time, 10-minute experience. But on-boarding is where people learn the ropes enough that they can get some value out of it.
Jared: If you're learning to play guitar, you don't jump right in and play complicated solos as soon as you touch the instrument. In turn, without any guidance, you don't know where to put your hands or what to strum when. You tend to approach learning in chunks: notes become chords, chords become scales and over time the act of playing becomes second nature. That's when you've made the activity into a habit.
Amy Jo: Habit building is beyond onboarding. Onboarding is usually either a simple loop that you do a few times, or it's a one-time experience that's an arc of an experience. But habit building is always some kind of loop. It's the day 21. What is the core activity that people are doing that's drawing them back?
Then mastery is what you give to that two percent that wants to really go deep, and if bothered to master your system. In gaming, we call that the "Elder Game." Usually, you're giving them a new kind of game to play — a different kind of role to play. Earned privileges, earned powers.
However you do it, if you model those stages. At each stage, you ask yourself, "What does this person need to learn right now? What is it they're learning? What skill are they building?" There's always something. It might be a trivial scale, but there's always something that people are learning.
If you start putting people into learning, what are they learning during on-boarding? What are they learning each time they log in on day 21 and day 60? What are they there to learn? What skill are they building? If you ask yourself that, then you're organizing your whole experience around the through line of skill building. If you want to create a compelling experience, that's a great way to organize it.
Jared: When you play a game, often the first few levels are the on-boarding process. You learn how to jump, run, access inventory, and make your way through your journey. Helpful messages and scenarios help you understand the environment and controls. You learn how to exist in the game and eventually master it.
Just like application designers, game designers add new features, such as levels or situations all the time. But they don't expect the user to figure it out on their own. The game designers return to onboarding, then help their users build new habits, guiding those users on their journey to mastering these new features. New is new, even for experienced players and understanding where they are within the context of their journey, the designer appropriately addresses their needs.
The users are the heroes of your design. Understanding what your heroes need at each point of their journey will turn beginners into masters. Even when we're changing the game by adding new features.
The UX Immersion podcast is brought to you by the UX Immersion: Interactions
conference, which will be April 18th to 20th in San Diego, California.
Now, if you're struggling to help your users master all those great features you're building into your designs, you need to spend a day with Amy Jo Kim in her full-day workshop on using game design approaches. She'll share the vast experience she's gained from working on games like Ultima Online, Rock Band, and my favorite The Sims. We've put a detailed description of everything you'll learn from Amy Jo on the conference web site, uxi16.com.
The UX Immersion podcast is produced by myself and Sean Carmichael. You can find more information about the UX Immersion podcast on iTunes and at the UX Immersion: Interactions conference web site, uxi16.com.
The music for this episode was provided by Eric Skiff.
We'd like to thank Amy Jo Kim for being a part of this episode.
You've been listening the UX Immersion Podcast, part of the growing UIE
Podcast Network. Thanks for listening and for encouraging our behavior.
Go beyond inspiration and immerse yourself in groundbreaking interaction design skills you won't find anywhere else. Get your team on the same page with proven UX methods, tools and clear-cut direction on specific actions and skills. Attend two full-day workshops and a day of talks to learn the latest strategies and techniques for building great products.
Use promo code UXIBen to save $200 on your full conference registration.
|Conference fee
|$1,775 (through February 25)
|Hotel costs
|$775 (for three nights)
|Transportation to and from airport
|$2,965 – $3,265
Download This as a PDF]]>
Here's an excerpt from the article:
Top Tasks Management is a model that says: "Focus on what really matters (the top tasks) and defocus on what matters less (the tiny tasks)."
Tiny tasks are a nightmare for web teams. On their own, these tasks seem innocent enough. It's just one more page, one more link, one more graphic. But gather them up, and many a web professional has found themselves nibbled to death.
Read the article: What Really Matters: Focusing on Top Tasks
How could your company benefit from Top Tasks Management? Share them with us below.]]>
Here's an excerpt from the article:
"Wait! What did you just do there?" In this case, I had just unlocked my iPhone by sliding over a notification's icon.
The person I was standing next to had never seen anyone unlock their phone that way. They'd had an iPhone since the very first days and had no idea you could do this.
Of course, why would they? There are no visual clues to tell you the notification icon is slideable. If you were told when you first got your phone, you probably wouldn't remember now, unless you used it all the time.
Read the article: Designing Intuitive Microinteractions
Have you designed intuitive microinteractions? Share them with us below.]]>
What are you waiting for? Register now to save $300. Price increases after Friday, January 15.
See you in San Diego.]]>
Here's an excerpt from the article:
Teams who have regular opportunities to meet with, talk to, and most importantly, observe their users turn out better designs. We've found if team members spend two hours every six weeks watching their users, they bring that knowledge to their design decisions.
In our experience, the first exposure is the hardest for the team. Design sprints help tremendously, because usability tests are built into the process. Once a team has that initial influx of data, subsequent sessions become easier to execute. When the executive shows up to review the design, the team will have the data from their repeated exposures to bring to the table.
Read the article: Preventing the Executive Swoop and Poop with Design Sprints
What is the process in your design sprints? Tell us about it below.]]>
Move beyond inspiration and immerse yourself at the UX Immersion: Interactions conference in San Diego, CA, April 18–20, 2016.
Six industry leaders teach master-grade workshops on groundbreaking interaction design skills you won't find anywhere else plus a keynote from Jared Spool.
Chris Risdon
Marc Rettig
Dan Saffer
Hagan Rivers
Amy Jo Kim
Collaborative Design Techniques
Richard Banfield
There's a saying that you can't know where you are going unless you know where you come from. Designing navigation for enterprise applications is a journey unto itself. One that UX Immersion speaker, Hagan Rivers is quite familiar with.
In this podcast, listen as Jared Spool discusses the importance of clear navigation systems in enterprise applications with special guest Hagan Rivers. They explore techniques for tackling complex navigation, how screen codes are perfect for those with in-depth experience, and how a balance with ease-of-learning is critical.
When you're sitting face to face with the wilderness that is an enterprise application, a map and compass would serve you well. Unless you're a tracker, know which side moss grows on a tree, or can follow the stars, you're likely not going to be able to navigate through on your own, much less find shortcuts and become proficient.
Hagan will be joining us in San Diego, CA on April 18–20 for our UX Immersion: Interactions conference. She'll be teaching a daylong workshop on how to guide users through the wilderness. For more information, visit uxi16.com.
Recorded: December, 2015
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]
Jared Spool: Welcome to the UX Immersion Podcast. I'm Jared Spool.
Nothing has plagued humanity through the ages more than the simple problem of getting from here to there.
Hagan Rivers: In general, a classic problem of Enterprise apps, I sit down and 25 or 30 percent of the pixels on the screen are dedicated to navigation. That's horrible, because Enterprise apps really need every pixel.
My name is Hagan Rivers.
Jared: Hagan spends her time working with companies to, among other things, clarify and streamline their navigation systems in large enterprise applications.
Hagan: They have big tables and lots of data and giant forms. They can't afford to lose anything to the navigation systems, and the navigation systems grow and grow and grow until…I literally had a client who had half the pixels on the screen lost to navigation of one kind or another.
Jared: The user's tasks should be relatively easy to accomplish. Yet, because of the lost screen real estate, these tasks become a journey across "quick links", tabs, sidebars, help links, and footer links. All leading away from the user's transaction. Much like Dorothy asking directions of the Scarecrow.
Hagan: I've run into apps, too, like this, where they have navigation on the top which is like tabs and menus, and then on the left they have a tree, and they go to the same places. I ask them, "Why do you have two navigation systems that go to the same tree?"
"Oh, we weren't sure if users would like the new one on the left, so we left the one on the top so that they could keep using that if they wanted to." You probably failed at that point. [laughs] If you don't have confidence in your new design, that's probably not a good starting point.
Jared: Every application that has more than a single screen requires some sort of navigation to move between them. Yet, there's no definitive style for how the navigation should look and work. If you don't have that confidence in your own design, you tend to look outward for examples that seem to work.
Hagan: When Amazon was using tabs, there were Enterprise apps all over the place that had 10 and 20 tabs across the top, and then Amazon moved away from tabs, but the tabs stayed. They just added a new system on the left. [laughs]
Then they went to menus. So, I think it's a real sense that they're chasing the right idea, but they haven't really sat down and thoughtfully designed it and tested it with users.
Jared: There are, of course, always people who know where they're going and how to get there. A business traveler moves more swiftly through an airport than a infrequent vacationer would, breezing through security, and advancing quickly to their flight's gate.
So-called "power users" have learned behavior that becomes almost muscle memory as compared to those unfamiliar or new to the product. Many enterprise applications were built with short screen codes that would jump you exactly where you wanted to be, making navigating with app of 600 or more screens really not that big of a deal.
Hagan: I worked on a healthcare app this year that they still have the screen codes. I watched users use them heavily. People who had been using this app for a decade and they knew the codes. They knew where they needed to go.
If you know exactly what screen you want to go to and you know the code for it, there is no faster system to get you there [laughs] than to type it in and go there. That's a great system. It's not easy to learn. It's not easily adjusted to change. It is a fantastic little shortcut for those users.
Jared: Traveling requires identifying the destination. Yet it also requires identifying the vehicle that will there.
Hagan: You start to build up a sense of, "This is a little application. How do these screens fit together in the user's mind, and how do they want to get to them?" The navigation in your application is just another application inside yours whose entire job is to get you to the right screen.
Jared: You want your users to travel quickly, so you need to avoid friction. Often, friction comes from not recognizing where to go or how to get there. Designing navigation is a balancing act, between speed of use and ease of learning.
Hagan: You need to be able to learn it. You need to be able to discover stuff in it. The whole features of your application will live or die by whether or not users find them in the navigation. There's got to be discoverability. Those got to be easy to use.
One of my guiding philosophies is I always try to design the navigation system last which really bugs most of my clients. They want me to start with navigation.
Both on Enterprise apps and even when we're starting an app from scratch, they say, "Let's do the navigation system first." That always seemed really backwards to me.
Jared: Designing your navigation system first is like installing the elevator before knowing how many floors the building will have. Without knowing the inner workings of your app, you can't possibly know the optimal path to guide your users through it.
Hagan: I need to spend time learning all the constraints and the screens and the users and the tasks and all that stuff. They always want to start with navigation. I say, "Let's do some other design work first. Give me an opportunity to understand this application and then we'll work on what navigation should look like."
That's the first thing. It's almost like, "Let's write the table of contents while we still have just the notion of what the book will be." Eventually, you might get to an outline, but exactly with the same process. You want to work your backwards from the screens you made to the navigation system that supports those.
Enterprise apps, people are sometimes are using these apps hours a day. This isn't the light touch like you get in Netflix or LinkedIn or things like that. These are apps that people sit down at for hours at a time sometimes.They don't want a navigation system that's clicky, clicky, clicky. They want to go fast. You've got to a lot of different needs to satisfy. It's hard.
Jared: When you go on a trip, you want as few obstacles as possible. There are reasons travel applications like Hipmunk sort search results by "agony". A direct flight is much less painful than five layovers to get you to the same destination. If your users have to traverse an incomprehensible menu system, or worse yet, they don't even know where to start, it's a clear indication that your navigation might be broken.
Experienced sailors can use nothing but the North Star to navigate their ships. But for the rest of us, we need clear and painless tools for finding our way.
The UX Immersion podcast is brought to you by the UX Immersion: Interactions conference, which is going to be April 18‐20 in San Diego, California. That's where Hagan Rivers is giving a full‐day workshop on all the tricks and techniques for simplifying complex enterprise applications.
Hagan has been helping teams redesign the navigation on their enterprise applications for decades, so she's seen and done it all. If you work on enterprise apps, this is a day of learning you can't afford to miss.
The UX Immersion podcast is produced by myself and Sean Carmichael. You can find more information about the UX Immersion podcast on iTunes and at the UX Immersion: Interactions conference web site, uxi16.com.
We'd like to thank Hagan Rivers for being a part of this episode.
You've been listening the UX Immersion Podcast, part of the growing UIE Podcast Network. Thanks for listening and for encouraging our behavior.
Here's an excerpt from the article:
Pushing beyond the obvious alternatives is what Chris calls "leaving the comfort zone." Sometimes, by giving ourselves a little time and space, we can find additional variations that didn't suggest themselves immediately, and these can have elements which are better than what we originally came up with.
We use these generative design techniques to explore possibilities. We haven't spent a lot of time on each one, so we have more time to generate new variations. In turn, we learn more about the problem's landscape.
Read the article: Jedi Designer Tricks for Exploring Multiple Variations
What are your Jedi designer tricks? Tell us about it below.]]>
UI20 OnDemand brings best practices and cutting edge techniques to help you understand your users' needs and create experiences that engage and delight.
Nine UX experts share the latest techniques, proven practices and important UX ideas. Use these videos for team lunch and learns or individual training.
Pay just $99 for lifetime access to all nine videos, and if you're part of a team, everyone gets access.
Kim Goodwin
Marc Stickdorn
Erika Hall
Jeff Gothelf
Nathan Curtis
Steph Hay
Jenn Lukas
Bruce McCarthy
Price increases January 24, 2016.]]>
Got $249?
Visit the All You Can Learn Library for hundreds of UX presentations on relevant and timely topics—watch, listen & learn. For $249 Get an Entire Year's Access.
Got $1,475?
Get our lowest price for UX Immersion: Interactions, plus you'll receive an Amazon ECHO. If you're going to be competitive, your products & services better have a great experience. This conference will show you how. For $1,475 Save Your Spot.
Got $7,500?
Gain the competitive advantage of experience design by having Jared Spool engage with members of your organization. Take the first step and start the conversation, because Jared's calendar does fill up fast. Starting at $7,500, Jared Spool will come to you.]]>
Enterprise applications are massive, often unwieldy pieces of software. You get a sense they were never truly improved or updated, they just had a continuous string of features tacked on until it got to the point where they are almost impossible to use. And they're old.
This focus on features let design fall to the wayside, making it less important than the application's perceived capabilities. Now, you're forced to stare at a screen straight out of 1995. You've become a time traveler, whether you were aware of it or not.
We've come across other time travelers in our journey. You aren't alone. One such person is Hagan Rivers, who has worked tirelessly to bring these enterprise applications into modern time, if not the future.
In this podcast, listen to Jared Spool weave a tale of time travel with special guests Hagan Rivers and Dana Chisnell.
Hagan will be joining us in San Diego, CA on April 18-20 for our UX Immersion: Interactions conference. She'll be teaching a daylong workshop on how to tackle what travails time travelers. For more information, visit uxi16.com.
Recorded: December, 2015
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]
Jared Spool: This is the UX Immersion Podcast. I'm Jared Spool.
If we want to immerse ourselves in serious design challenges, there's probably no better starting place than time travel.
Dana Chisnell: Yes. I'm a time traveler.
Jared: Now some of you may recognize that voice. She co-authored the Handbook of Usability Testing, co-founded the Center for Civic Design, and created the Field Guides for Better Ballot Design.
Dana: Hi. I'm Dana Chisnell.
Jared: And since Time Traveler looks a little weird on a resumé, she is currently…
Dana: Digital Services Expert, Executive Office of the President.
Jared: And since that looks intimidating on a business card…
Dana: On my business card, it says Generalist Problem Solver, U.S. Digital Service.
Jared: So Dana is a Time Traveler, sent by the government, and she is in fact, here to help.
Dana: So it's not a top secret project but it is government work. What makes it feel like time travel is that when I got a hold of what the design looked like, what the software looked like for the users all you had to do was look at the screens to feel like you had been transported back to the 1990s. Completely reminiscent of early Windows systems, really felt like I had been here before already. And I was going to get to do this again.
Jared: I know what you're thinking: it's 2015 and despite promises by Robert Zemeckis, Time Travel really isn't a thing yet. But it turns out that Dana's experience isn't all that uncommon.
Hagan Rivers: Whenever I sit down with Enterprise apps, it's back to the '90s. They're old. The apps are old. The code is old. The databases…Some of these databases have been around 25 years. [laughs] It's the same database that they set up the first time they built it.
Jared: That's our go to person for tackling time travel issues like Dana's.
Hagan: My name is Hagan Rivers. I am a User Interface Designer for mostly enterprise applications.
Jared: Hagan is the person that we at UIE turn to when it comes to taking old enterprise apps and bringing them into the future. She says that a lot of the problem of why these applications get stuck in the past is that they are narrowly focused.
Hagan: I find for most of them it's such a struggle to even get the features in. Thinking about design is something they just don't make time for, or have time for. They seem to be stuck in this, "Get the features in," mode. Honestly, when you look at the folks purchasing this software, they're often looking at, "Does it have this feature or that feature?"
Jared: This focus on features is something that I talk about a lot. When you keep adding feature after feature after feature, you actually reduce the usability of your product. It's called "feature creep". And the problem in this instance is that the people buying the software aren't the ones who are actually going to be using it on a daily basis.
Hagan: They're not paying attention to design. It's not a space yet where design is a big selling factor.
Jared: Now because of this disconnect between the purchasers and end users, the purchasers are only focused on what the product allows them to do. And the more things it allows them to do, the better because they can accomplish more tasks. But the thing that's lost in the shuffle is, if you can do these tasks that's great, but you also need to be able to do them well. And that's where the design factors in.
The companies that buy the software actually believe they can train their users, who are their employees, on how to use this complex software. They focus on the features and not the actual task at hand. So since features are the focus of the people buying the software, the people making the software in turn just keep adding more and more features into the product.
Now this type of problem isn't exclusive to the private sector, it's actually part of the reason why the US Digital Service exists. Dana ran into this when she first started working at the US Digital Service and had a look at some of the designs they were using.
Dana: They were horrible. They didn't reflect what users did one bit. It was like the programmers just barfed the database onto the screen.
Hagan: Yeah. Dana's very… visual. I like her. [laughs]
Yeah, the Enterprise applications, first of all, are very database oriented, because you're essentially manipulating data in a database. That's what they want you to do, is enter, update and maintain a bunch of databases.
For them, the design works if you can update the database, if you can adjust the fields, or make the connections, or remove the records, whatever you need to do. They don't care if it was easy or hard to do those things, because the only thing that matters is that you can.
It is true. There's this classic case of like, "Build a database, and then whatever's in the database you just throw that up on the screen with the switches and levers that manage it". But no real sense of, "How does the user do a task? How do they accomplish something?"
"How many steps does it take to add a patient, and to hook them up to the information, or to create a purchase order and send it to the next person who has to deal with it?" It sometimes is a lot of steps to get that work done.
Jared: So it may sound daunting, as Hagan was just explaining, but this is what she does. And if she wasn't successful in making these types of products and services better, she wouldn't have a job.
So the question then becomes, is this something that is a complete tear down from the beginning or are you redesigning the plane while it's in flight?
Hagan: The answer is it's a little of both. I'm a big believer in continuous improvement of software. I think, at any given time, you should have a good list of your user's current pain points. What's aggravating them in the software? Every time you do a release, you ought to knock a couple of those off that list.
I worked with a client. We did some field studies. We watched the users using the software. I made that list of pain points. We added the three of them. They were doing a rollout of new features. They have all these great new features and they were telling the customers about them. They were very excited about them. They had been getting asked for them so that was good. But I added these three troublesome spots that their users were running into.
One of them, it was seven clicks to do this one thing that people did a lot.
Honestly, I don't even remember the exact thing, but I remember it was a lot of clicks.
We fixed it. We fixed it so it was one click.
It got done. You went to a screen. You did everything you need to do and it was done. I have to tell you.
When we finally showed the new version to the users, they were more excited about that one little fix than they were about the six other new features that they had also wanted. But that fix was something that had been driving them bonkers. It was a pain point for them every single time they sat down to use the software.
Jared: So it seems that addressing users' problems as they have them versus adding new features that they might not even use will make the product and the experience of using it better than just bloating it with more and more and more and more features that can actually get in the way of the task at hand.
Hagan: I do believe you've got to know what the problems are. You should never let a release go out that you don't throw in your own, "Here's what we need to fix." At the same time, there are opportunities to make big changes. Typically, a software company might be going to a new framework. They're going to a new toolkit. They've acquired another company. There are these times in engineering and development that are good times for big movement.
In those times, that's a good time to sit down and really look at the design from a top to bottom standpoint. If you're porting the code to a completely new framework, that's a great time to say, "Have we got the right design? What do we need to change?" and to go through that process. But that doesn't happen very often. You have to also chip away at it.
Jared: And here comes the importance of research. If you want to find out what things in the product are annoying your users, you actually need to watch those users use the product.
Hagan: I say, "Take me along on a sales call," which these days I don't even physically leave the office, I just sit in on a sales call and listen to the questions people ask. I listen in on support calls, and I go out and I do field studies with the users.
Again, sometimes you don't even have to leave your desk. I just do a screen share with a user and I watch them for an hour, and occasionally I ask them questions, and I ask them to talk aloud. It's very traditional, old-school stuff.
I'm a consultant, so I'm not at the company. It's not that great to have me doing that. It's great, because I can help them with the design, but I always rope in their own people and I start them in this process of, "You have to be touching base with your users regularly, constantly, so that you understand their pain points."
I have yet to meet an engineer who can watch a user struggle with something that's broken and not want to fix it. That's an instinct for them. They love to fix problems.
Jared: When you get the developers, product managers, stakeholders, and other decision makers in the room and you actually watch these users struggle to use the product and you're there and you're living their frustration along with them in real time, it's a really good way of getting everyone on the same page. Because no one wants to ship a crappy product. And as Dana's experience with the U.S. Digital Service shows, knowing who your users are is a universal problem.
Dana: When we started out there was no attention paid to who the users were and what their needs were at all. The developers would get a story that was completely out of context. They didn't even know what task that user might be doing. And the users were treated very generically in addition. Internal users were this enormous category that might actually describe any number of different kinds users. Up to ten or twelve of them.
And so they were having to guess what needed to be done. And we were seeing a lot of "Well what if we did this?" and "What if we did that?" and "will this work for that thing?"
But as soon as we sent them out into the field to actually see how the work got done, meet the users, get a chance to ask questions of them about how they did their work and how they thought about their work, as soon as they came back we noticed an immediate difference in the work product they delivered. They had a much better idea of how to interpret the requirements and to translate the stories they were working on. They understood better, the context that any given story might be coming from. But now they also had met human beings that they were making this thing for and they didn't have to guess anymore.
Jared: Time Travel. The general idea of it sounds great. Fun and exciting. But in real life, in it's real world application, it's exceedingly frustrating.
You can alleviate that frustration by watching your users use your enterprise application. You need to exposure your team to what those users are trying to accomplish. Then you chip away one frustration at a time. Every frustration you chip away brings you one step closer to the present.
The UX Immersion podcast is brought to you by the UX Immersion: Interactions conference, which is going to be April 18-20, 2016 in San Diego, California. That's where Hagan Rivers is giving a full-day workshop on simplifying complex enterprise applications.
I hand picked Hagan to be a part of this program, to teach this workshop, for the people who have to deal with these problems every day. If you deal with these problems every day, Go to uxi16.com to read a complete description of Hagan's workshop and what you'll learn.
The UX Immersion podcast is produced by myself and Sean Carmichael. We'd like to give special thanks to Hagan Rivers and Dana Chisnell for being a part of this episode.
You can find more information about the UX Immersion podcast on iTunes and at the UX Immersion: Interactions web site, uxi16.com.
You've been listening the UX Immersion Podcast, part of the growing UIE Podcast Network. Thanks for listening and encouraging our behavior.
Here's an excerpt from the article:
It's your most loyal customers who will hate your flip-the-switch redesign the most. Designers are quick to declare, "Users hate change." But that's not it at all.
Your loyal users have invested a lot over the years mastering your current design, to the point where they are fast and efficient with everything they need to do. When you change it, even with something you want to label "new and improved," all of that investment is flushed down the drain.
Read the article: Extraordinarily Radical Redesign Strategies.
What strategy have you put in place when planning a redesign? Tell us about it below.]]>
New practices and techniques meet theory and expertise at the UX Immersion: Interactions conference in San Diego, CA, April 18–20, 2016. Move beyond inspiration and immerse yourself.
Six industry leaders teach master-grade workshops on groundbreaking interaction design skills you won't find anywhere else plus a keynote from me.
Chris Risdon
Marc Rettig
Dan Saffer
Hagan Rivers
Amy Jo Kim
Collaborative Design Techniques
Richard Banfield
Here's an excerpt from the article:
Two Dots' designers also needed to put in tools to control the play of the game, such as changing levels, turning off the sound or music, and adjusting colors for color blind players. These tools must be easy to find and use, not a challenge like the game play itself.
Game designers are experts at ensuring goal challenges remain in the users' focus, while ensuring that tool challenges are minimized or eliminated. By studying how the best game designers have made these trade-offs, we can learn how to improve the productivity tools we're designing.
Read the article Goal Challenges and Tool Challenges
What are your thoughts on goal and tool challenges? Tell us about it below.]]>
Using his entertaining storytelling style, Jared weaves together the threads of what was heard throughout the conference. We'll look at how to rethink the way we structure our teams, how they collaborate, and the implicit and explicit rewards that drive their achievements. Organizations need to approach every problem and decision from a design viewpoint. Jared connects the UX Advantage themes together to form a framework for how we tackle the amazing challenges ahead of us.
Recorded: August, 2015
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]
Jared Spool: …I actually want to step back first before I do that, and get to something that actually was part of the inspiration for this entire event, which was a realization we had when working with companies, about the maturity of how design works through organizations.
To start with that, I want to start with probably what was in my mind, one of the most important user experience stories of 2014. It never got much discussion, in the UX world. That was the Disney MagicBand.
The Disney MagicBand was a culmination of a four year project, where Disney invested more than a billion dollars on what essentially is a wearable.
They put in more money in than Apple did on the Apple Watch, so this is a big deal, and it doesn't tell you the time, or it doesn't count your steps, and I don't even think it vibrates when your heart rate gets too high. It doesn't do any of those things.
What it does do is completely change your park experience. For those of you who have never seen the Magic Band, or had one, the way it works is you order it when you book your park reservation, and it actually comes before you get to the park.
This was a realization that Disney had, that the vacation starts before the vacation. It comes in a box that is all decorated with your favorite Disney characters, and when you open it up, all the bands that you've ordered for you and your family are there, and each one is named with a family member.
You take your band, and you try to keep the kids from playing with it to death before you get to the park. When you get to the park, you don't actually have to check into your hotel, the Disney resort that you're staying at, you just go straight to your room, and the band opens the door to the room.
If you took their bus from the airport, your bags are already in the room, which is why they put big warnings over the box, "Do not pack this in your bags," because you can't get into your room. From that moment on, that band controls every interaction you have with the administration of the park.
It's your FastPass to get on rides, and the preferred line, and it's the way that you pay for food, or gifts in the gift shop, and it has three different radio transmitters in it, and it knows where you are in the park, to the point where if your kid has a birthday, your kid's favorite character will seek out your child in the park, based on the GPS that's in the van, and actually wish them a happy birthday.
When you go into the restaurant and you order dinner, the wait staff just knows that it's your kid's birthday, and will bring the cake at the end. The whole experience is orchestrated to be this completely different thing.
That's what a billion dollars will buy you.
But Disney wasn't always this way. Back in 1997 when we were doing our first studies on websites, the Disney site was actually one of the running stories we kept talking about. For years, we were teaching teams how to do website usability testing, and these were teams who had never done usability testing before.
By the way, it's a pet peeve of mine, usability testing, not user testing. We're not testing users, we're testing the design. Please, no more "User testing." The usability testing that we were doing, we would teach these teams how to do usability testing, and they'd never done it before.
We would pick the Disney website, always. This was because when we first studied the Web, one of the first studies we ever did of the Web, it was this simple study, when I think back on it now, it was one of the simplest things we had ever done, but no one had ever done it before.
What we did was we brought in a handful of folks, and we sat them down at websites, and we just asked them to find things. It's what we now call "A scavenger hunt test," where you give people a list of things to find. The whole purpose was to figure out how the Web worked.
We were watching people use sites that they'd never used before. We picked the Disney site because of all the sites, it was the prettiest. It was the one, in 1997, that had the graphics, and the images, and all the elements to it.
We learned so much. For instance, one of the things we learned was in one rendition of the site, for a period, while we were testing it, there was this animated GIF of a woman doing these sort of jumping-jack like motions. I don't know why she was there, or what she was advertising, but she was part of this thing, and she just kept doing this.
This is how we learned that people will scroll, because people would try to scroll her off the page. The page was less than two screens high, so if you brought the scroll bar all the way down, it wouldn't take her off the page, but it would get her close to the top.
I remember watching users just repeatedly trying to slam the scroll bar down, to throw her off the page, so that they didn't have to look at her anymore. That's how we learned that animated things piss people off.
One of the other things we learned was there was a task, and this was a real task that we'd gotten from a participant.
She had a six year old who loved trains, just absolutely loved trains. She wanted to know how to find the cheapest hotel on the monorail at Walt Disney World. She didn't know which hotel that was, and at the time, there were 14 different properties that she could have stayed at, but she couldn't figure out which one would be the cheapest one and on the monorail.
You could find out which was the cheapest, and you could find out which ones were on the monorail, but it was almost impossible to actually complete this task. It turned out to be a fantastic example task for teaching people how to do usability testing.
This would be the demo we would do, we'd bring somebody up from the audience, and we'd give them this task. Inevitably they'd fail at it, because practically nobody could succeed at figuring out that the Polynesian Resort was the cheapest hotel on the monorail.
In the process, we'd teach them how to observe, and how to work with a participant who was getting frustrated, because inevitably everybody got frustrated. It was a great task for us to do this, but there was something else we learned from this task.
I subsequently watched literally hundreds of people do this particular task, and what we learned was that approximately one out of every five participants would accidentally go to the Disneyland site, instead of the Disney World site.
Land-World, World-Land, what's the difference? It turns out it's about 3,000 miles. They would go to Disneyland, and when we first saw this in the lab, we were completely baffled by it. I remember sitting next to the first participant that this happened with.
We would go to the lab, and they would go and give them tasks, and they would search, and they would come to the contemporary resort, which at the time was the only hotel at Disneyland that was on the monorail. I think it was the only hotel at Disneyland, at the time.
They would look down, and they would say, "Well, this is it. This is the one." I would say, "OK, so that's the closest hotel to the monorail at Walt Disney World?" They'd go, "Yep."
"Can you take the monorail from that hotel to Epcot Center?" "I don't know." Click, click, click, click, click, scroll, scroll, click, click. "Yep."
Every time. Every time they would tell us, "Yeah, I could get there from Epcot Center." Just so you know, 3,000 miles, on a little train, no bathroom.
They didn't know. I remember, for a long time I was giving talks at conferences, and I would bring this up. I would mention that if you looked at Disney's analytics, they would tell you that one out of every five people, at least who were doing this task were showing up the Disneyland site, but there was nowhere in the analytics that you could tell that there was a problem.
At one point, I'm giving this talk, and I get off the stage, and some woman comes up to me, and she says, "I work for Walt Disney World." I said, "Oh, really?" She goes, "Yes, and I'm going to tell you something that's off the record." I said, "OK."
She says, "That happens all the time." I said, "Yeah, I know. It happens one out of five times." She says, "No, no, you don't understand. We have people who show up in Orlando with Anaheim reservations."
Audience Member: Oh, no.
Jared: Yeah, that's exactly what I said. [laughs] Apparently they actually are so prepared for this problem that they hold rooms in Walt Disney World for people who have Disneyland reservations, so your vacation is not ruined.
You will get a hotel at Walt Disney World. They have those set aside for those people, because they know that. This is a great example of parts of an organization not talking to each other, because the folks behind the website were not realizing that the folks at guest services were overcompensating for a problem that was well understood, without fixing the problem.
The problem went on for almost a decade. We continued to see the problem, over, and over, and over again. This is a big difference from the billion dollars they spent on the MagicBand. A lot happened between 1997, and even 2007, and now.
That's a lot of growth. That's a huge amount of growth. When organizations go through this path of discovering there is this notion of design, and user experience, the path, over time, has made itself fairly obvious to those of us who watch organizations go through this. It starts with a period that we refer to as the dark ages.
The dark ages are when the organization is just not thinking at all about the experience of their customers or users, usually because they are completely over their heads with just getting a product out with the features they need to be competitive, as far as they're concerned, and that's what they focus on, is all that sort of internal machinery of getting those things out.
Then, it works that somebody in the organization has the idea that maybe something could be better and there shows up little spot projects. If you could do an FMRI of the brain of an organization, you could see UX firing in little corners, just for moments, where some team, some manager says, "You know, we could do better here," and they apply some type of design, some type of user experience, and it takes, for a second.
But then they move on, and it doesn't quite continue. Then, over time, as the organization matures, you start to see a real user experience effort, and people start talking about the user experience. Maybe there's a designer or two, or least a UX person of one, or one of these grassroots efforts that takes a little longer.
People start building more user experience in, over and over, at the time. Then, that becomes sort of a centralized group that works on the user experience, those are the user experience people, those are the design people, and they tend to work on this stuff.
The next step for maturity is really interesting. They take that group apart, and they disseminate it out into the teams, and they realize that getting UX closer to the people who make the decisions is key. It's funny, because over the years I've been asked, "Where in the organization should the design group be?"
"Should it be in marketing? Should it be in engineering? Should it be IT? Where should it be?" Years ago we came to the answer, which was, "It should be next to where the decisions get made. It should be right where the decisions are happening."
It turns out that if it's a marketing-driven group, and all the decisions are made by marketing, then by all means, have the UX team be with that marketing group, and if it's engineering, it should be there. In this day and age, where things are now more cross-disciplinary, more multidisciplinary, even that answer doesn't really make sense, because those folks are all getting together.
This sort of embedded idea is that you have these teams where everybody is embedded in them, but then you run into this problem of the teams themselves, the members of the teams who are doing design, feel isolated, because they feel like they're back in that world of being the team of one, and they're there.
You start to have to create this sort of cross-communication, where the folks are combined, but they're also in the teams, which is why I really like what Adam is doing at IBM, where they have the studios where the designers are together, but they're completely embedded in the teams, at the same time, because of the ways that IBM does remote.
That works out really well, but you could have the inverse, too, where the designers are co-located with the teams that are not remote, but then are remote with their design compatriots, in that regard. It turns out that lately, we've been seeing a different sort of model, beyond embedded teams.
That's what we've started to call design infused culture that it's not just the designers, it's not just the UX people who are trained, and proficient, who are talking about design and user experience, that in fact, it's everybody talking about design and user experience.
The CEO is standing up in the town hall meetings talking about how, "Now we are a design-driven organization," and that they are actually doing all the things that they need to do to be a design-driven organization, and to put those things into place, and to make sure those elements are there.
We've seen that this is starting to happen, and we've talked to a bunch of folks that are different stages of this, over the last two days. That idea of being design-driven, and design infused, where everybody is part of this, is an interesting new way of doing it.
It's that last one that I want to take apart for a second, and talk about, because it is here where we see something that we call the UX tipping point. The UX tipping point has to do with how designs become real in the world, how they get shipped.
Before you get to a design infused culture, design always plays this secondary role. It plays this thing that you do, in addition to all the things you've always done. You're going to put out the product, it's going to have features, but now we're also going to make it well-designed.
It's that secondary thing, but when you get to design-infused culture, design is now at the forefront, it's driving the strategy, it's driving the products, it's driving what you're ending up doing, and it is the thing that makes it happen.
The tipping point happens somewhere in that process, because what you start to see is, every so often, a project will do the unthinkable. It will delay a shipment, not because the product is technically broken, not because the business goals have not been reached…
It's technically working, the business goals have been reached, but it's not being shipped, because the design isn't right.
If you look at any new Apple product, the ads of any new Apple product, when they release it, the clock on the product, whether it was the original iPod when it came out, the iPhone, the iPad, the Apple Watch, the clock is always set to 9:41 AM.
I don't know if you ever noticed that, but if you look, go back and look at the first ads for the iPod, set to 9:41 AM. The reason it's set to 9:41 AM has to do with the original announcement of the iPod. The original announcement of the iPod was during a keynote at Macworld.
The keynote started at 9: 00, they went through all sorts of stuff, and then Steve Jobs did his, "But there's one more thing," and that was at 9:41. The story goes a little deeper than this. It turns out that before Apple announces any new products, before that keynote starts, at 9:00 West Coast Time, they take their website down.
Apple.com just comes off the grid. They replace it with a static HTML page that just says, "We'll be back soon." This is just crazy in its own right. Here you have this streaming resource that's going down to the world, and they take down the website that everyone is probably going to find out more about the products as it's being talked about.
But they do that, and while it's down, that website, which had no previous mention of the products that are being announced, gets completely re-launched. At 9:41, it comes back online with the new products.
The way they do that, I found this out the hard way, the way I found this out was we had invited one of the people who was in charge of designing apple.com to a conference. We were all set to have them there then they called us and said, "I can't come."
The reason they couldn't come was that four weeks after our thing was a keynote that had just been announced and basically everybody who works on the website is locked down for the 10 weeks or 12 weeks before the new launch because they're just not allowed to do anything but get that website ready. They worked on that website.
It turns out that they don't find out what those new products are until that moment. All this stuff has been in development, but they read the rumors you and I read. Then they learned what's going to go on the website. They don't let them out partially because there are so much work to do and partially because they don't want anyone telling anybody.
The whole thing is locked down. They worked on that website that they can make that flip-the-switch change in front of all those people in that 41 minutes right then and there.
That flip-the-switch change is amazing because there are products that have been ready to launch the website for those pages for those products were all set. The order pages for those products were all set. Everything was there. Then someone high up, someone wearing a turtleneck decides that the product is not ready to ship.
It has happened Monday evening before the Tuesday keynote at 10 o'clock at night Pacific Time. They have between 10:00 PM and 9:00 AM that morning to pull any evidence that that product existed because people are going to read the source code of the website to figure out if there are references to things.
They pull any existence that that product ever existed off of the design of the site that they had readied and tested to launch. They have to retest everything in order to make that flip-the-switch launch where millions of people are going to show up in those next few minutes.
It's not because the product wasn't technically working or wasn't business-wise because it wasn't designed right. That's the commitment that they have to this UX tipping point. The UX tipping point is actually the moment when that happens for more than half the products or services that the product delivers.
That suddenly this organization is so focused on design that they will not ship most of their products. Occasionally things go out. That explains iTunes. Most things will not go out until they are ready, until the design is right.
There are not very many organizations that have reached this tipping point. Probably just a handful of them. This is the way you tell. This is the Holy Grail. This is place we are trying to get to, to tell us that we have reached what we're trying to do.
Now, technology itself goes through an evolutionary pattern. It starts with just being something that goes out that we just are happy that it works.
The first mobile phone was this massive Motorola device and that you could just make a call on it was all that mattered, that it cost 2,400 bucks and weighed four pounds and barely you could hear the connection on the other side, was not nearly as critical as the fact that I just made a call.
People who needed that thing would pay for that thing. It's a small audience. That's how that market starts. Every new technology starts with something like that first version of something. Then a competitor comes out with something and it becomes the war of the features where people go back and forth and they are like, "We have these features. We have those features."
You see this now with the health wearable wristband stuff as well. Do I get an app? Do I get a Fitbit? It's just really a list of features that are competing on that.
Then there's an evolutionary change where there are so many features people don't care about them anymore. We see the shift go to experience. That's like, "Well, which one delivers a better experience?" You saw this with the iPhone when it came out. It had actually less features than many of the flip phones and other types of phones that were on the market, but it had a much better experience.
I've been talking about that stage of moving from technology to features to experience as a way to describe this evolution.
One of the interesting things is that companies that were the top dogs when we were in the feature section, they were the ones with all the market share like Motorola quickly lose their market share because they're not prepared to have a conversation about experience. They have to struggle with that conversation about experience.
We can map that into the maturity that we see of moving through those different stages of having a design team that works on the design versus having embedded teams. It's in those shifts that we see people start to focus on experience. We see the investment that gets made to be there.
There are lots of business factors that cause this, but there's a fourth stage that I rarely talk about because you don't see much evidence in it. The fourth stage is a stage of commodity.
The first GPS systems that came out, the Garmins and the other systems that you would buy and hang on with those suction cups to your car and things like that, those delivered a great experience. Those had or some of them did, some of them were horrible, but over time the absolute points were experience was there.
After a while, those all went away. We didn't need to have explicit GPS devices because those GPS devices got sucked into other things. The phones have them now. The cars have them now. The wristbands have them now.
That commodity stage is when we take the experience bigger and we're not thinking about the specifics of the product, the specifics of the element and we're moving it further. The other piece of this is that in order to have this idea in your organization that you're not going to ship something until the design is right means you have to define what the right design is.
Not only do you have to define it, you have to get everybody in the chain to agree to it because all it takes is somebody in a tie or a turtleneck to say, "Well, that doesn't matter. We have to get this thing out," to overrule the decision.
There has to be this buy-in in order to get to this point where you're delaying ship because the product is not right. You have to have a clear shared understanding of what that means.
It's that phrase "Shared understanding" that came up several times over the last two days of "What are we trying to do? Who are we trying to build this for? Why are we trying to build this?" That turns out to be the key piece to answering the question, how do we know when what we're doing is good enough?
We know it can't perfect. That will never happen. We have to have a common definition of the term "Good enough". That turns out to be problematic.
To do that, we have to take all of that understanding we have of our users, of what they're trying to do, of what makes the products work or not work. We have to negotiate within the organization how that fits into the roadmap that we're going to create. How that fits into the plan of what we're going to build out. That turns out to be really tricky.
It's even trickier because we're constantly in an environment where everybody thinks they're a designer. Everybody has an opinion about design. Everybody has a thought about this.
I get to work with a lot of folks who are new to the design world and they get very frustrated that everybody thinks they're a designer. I know about design. I learned about design. I was trained in design. These people, they know nothing about design yet they're telling me how to make the logo bigger.
The reason everybody thinks that they're a designer is because in fact everybody is a designer. We are always designing things. In fact, one of the faults that we have in our school systems is we don't actually teach enough design early enough.
You think about in life, when you move into a new house, you're going to put the dishes away in the cabinets. How do you design the right way to do that? It's going to be really hard to take all the dishes out and rearrange them later. You'll probably have to do that when you redesign the kitchen. It would be nice if you had gotten that right the first time.
We're probably going to make a form for signing for Sunday school or the PTA or something like that and that's a design problem. In fact, people are doing design problems all day long. They're always designing.
When we get into companies, everything really is a design problem to some extent. That's the mantra behind this idea of design thinking. It's why design thinking is now on the cover of this month's "Harvard Business Review" that it's everybody needs to be going through those steps of exploring and understanding and sharing this stuff out there.
There is nothing magical about design thinking. Design thinking is just design. Design is going out and understanding what good enough is and how we present that. It's very much that we have to help the people we work with, bring out their inner designer. We have to help them understand and we have tools to do this.
A few years back, we did a project where we took a bunch of companies that were fantastic. About 20 different organizations that were fantastic at delivering great user experiences and great products to their customers.
We went and found direct competitors who were selling products and services into the same markets as those companies that were successful and we compared them. For example, we looked at Apple and we compared them to Dell on the hardware side and Microsoft on the software side.
At the time, Netflix was doing fantastic that we compared them to Blockbuster. We looked at non-tech companies like Virgin America and compared it to United. We looked at Cirque du Soleil and compared them to Ringling Brothers.
We were able to pair up these companies and look at what was there. Then we actually had the opportunity to go in and speak with the folks who were making design happen in organizations and making these things successful or trying to make design happen in the struggling companies and working really hard to make them successful.
When we compared them up, we found that there were basically three things that the companies that were successful at shared amongst each other that were rare in the companies that were struggling. The first one was exposure to users.
We heard today that user research is the catnip for executives. It turns out it's the catnip for everybody that in fact having constant exposure to users, constantly being able to understand what is happening with the product, what is happening with the service, and seeing it all the way through how people used it was absolutely key.
Those of us who spent time indoctrinating teams with things like field research or usability testing, you often hear the comment, "Wow. Why didn't we do this two years ago?" That's one of the first things you always hear.
It turns out that it's because it is such a powerful experience. Like you are hiding this information from us. The users aren't telling it. We try to supplement this with surveys and customer satisfaction forums, but those things miss the mark so badly because they don't tell us why these things are happening. They don't give us the sense of it and they homogenize all the data in this horrible, horrible way.
The idea that you get out and you meet people. We started to figure out, "Well, what's the right amount of time meeting people?" We realized that there's actually a number. It's a very simple number. It is two hours every six weeks. Everybody who has any influence over the product or service needs to spend two hours every six weeks.
One of the organizations that's been incredibly successful is the Government Digital Service for the United Kingdom. We've talked a lot about the US Digital Service. The US Digital Service thinks of the United Kingdom's Digital Service which is about four years older as the prototype for them.
The Government Digital Service under the work of Leisa Reichelt went and made it a policy that everybody in the organization had to spend two hours every six weeks if they wanted to have any say in what these products or services should be, just watching a user use the products.
It turns out it doesn't actually matter what you watch. You can watch one person for two hours. You can watch four people for half an hour each. It can be 15 minutes every week or it can be two hours at once then nothing. It's that frequent repeated exposure that makes a huge difference.
What Leisa noticed was that the meetings which used to start with, "Well, I think we should do this. I think should do that," started to be more of, "Well, we saw someone last week who I don't could do that." People would tell the stories about Mary, or James, or one of the participants that they saw.
The other thing that Leisa was very successful at was that she was very good at not just getting the developers and the designers, but product managers and product owners and the heads of the agencies and the ministries and all of the folks.
She basically said, "Look, if you want a say in how this product is designed, you have to have spent this time actually researching folks and actually going out and talking to them and seeing them." It was hard to get that on the executive schedule.
Once they managed to do it, that catnip thing kicked in. It wasn't that hard to get it a second time or a third time, and making the rule that says, "If you want to have a say, you have to have participated in the research," turns out to be something that got supported from the highest levels down.
The second factor that we found that was common amongst the excellent organizations and missing in many of the struggling organizations was having a vision of the experience. Now, a lot of organizations have a mission statement, "We want to produce the best market-driven product for our growth consumer business."
World class is a requirement for anything. It has to be world class. Best of breed is the other one. There's an Etsy store that just sells mission statement phrases that you can get.
A vision of the experience is different. A vision of the experience is being able to walk up to a member of the team and say, "What will the thing you're working on be like for a person who will use it five years from now? What will that be like five years from now?"
The immediate reaction I get is "The technology will change," but we're not talking about what the actual design will be. We're saying what is the experience like five years from now?
This is in fact how Disney got billion dollars of money out of the executive board of Disney to build this park system is they created a series of prototypes. A lot of it was foam core and just artwork. They worked with frog design and they built out in the back lot of Disney World, in the movie studio back lot.
They took over a sound stage and they built a working prototype of the band. The whole thing was smoke and mirrors. You would go in and you'd put the band up to something and someone behind will go, "Poop-poop," and it would let you in and the whole thing was just this fake thing, but they could share the experience.
The thing was is that when you went through it and you saw how the whole thing worked, you could talk about it. You could explain that experience. Anybody who worked on the team and anybody who was approving the team had the same description of this.
This turns out to be key. I often do these exercises where I'll go into an organization that say, "Yeah, we have a vision of what our product is." I say, "OK. Let's do a little exercise." I have them take out an 8.5 by 11.0 sheet of paper, put a landscape, draw a line down the middle.
I say, "OK. On the left hand side, we're going to do a little controlled experiment. I just want you to write down the story of Hansel and Gretel in bullet form." "OK. I can do that." "Give you two minutes, just write down all the major milestones that happened in Hansel and Gretel."
"Now, on the right hand side, I want you to write the story of what a user will go through with your product five years from now." People look at me like you're looking at me right about now, like, "What? Whoa, whoa, whoa, whoa, whoa." "No, no, just simple. Just bullet form, just write down the major things will make your experience your experience five years from now."
A couple of people put their heads down and start writing. Most people will just keep staring at me like I was speaking to them in German. The folks who write down what they wrote, it doesn't match what anybody else wrote down in the room, but everybody's story of Hansel and Gretel will match. Everybody else's story of Hansel and Gretel.
Here's the freaky thing about this experiment. None of the have ever talked about Hansel and Gretel at work before. It never comes up. Yet, they all had a matching version of that story. Theoretically, they've been talking about their product and service every day and nobody knows what the future of it is.
That vision of the experience and the ability for everybody to write down the same words on the page in order to make sure that everybody's marching towards the same vision is something that we never talk about but is critically important to our success. That's part of that shared understanding.
If we want to know whether the product is good enough to ship, we have to know what the current experience is. That's what happens when we visit our users. We have to know what our vision for the experience is and what our current cutoff is towards that vision. What baby steps are we going to be taking to get to that vision? Those are the key pieces of that.
Then there's a third piece of this. The third piece of this is a culture of continual learning. We've talked about culture a bunch today. Mark talked about it a great deal. Other people talked about it. I love the definition that we heard earlier from Steven which was that culture is the stories that we tell ourselves until we believe them about what we do and how we work.
Mark defined it as being the myth that underlies what we're doing that's so strong that we believe the myth. It's a common shared thing. That's what our culture is.
What's interesting here is a lot of organizations do not have culture of continual learning. Continual learning is the simple idea of understanding what did I learn that I didn't know before? It's reflection. It's a basic piece of what we're doing here.
What makes the reflection interesting is that it happens in small pieces, not big. Many of you know that I'm starting a school with Leslie Jensen-Inman who is sitting at the back of the room and we're starting a school for UX designer in Chattanooga, Tennessee. The team that we put together for Center Centre, we started doing daily stand-ups.
It's the common thing. The whole team gets together. For half an hour, we talk about the standard things that you talk about at standup. What did all do yesterday? What are we planning to get done today? What's in our way? What's the most important thing on our plate?
We added what we call the fifth question to this standup equation. We added this fifth thing which is what is something that you learned in the last 24 hours or since the last standup. Actually, what did you learn since the last standup that's important to you and how will you use it going forward?
It turns out this changes the tone of stand-ups completely. It changes the way they work in an amazing way. That suddenly, first, it's by far the most interesting part of the standup. We all know what people worked on yesterday and we all know they didn't get everything done. We all know that they've pushed a lot of it on to today and we all know that they probably won't get that done.
We know that there are obstacles and we can work through those and we'll take that offline and we'll deal with it. We know what everybody's priority is, at least we think we do and that's good too, but what did you learn yesterday? How are you going to use that going forward?
The conversations that come out of that ware often big and small. Sometimes, it's like, "I learned a shortcut in keynote that I didn't know before and I will use that in every presentation I do." Sometimes, it's, "I learned that I have this awful habit of interrupting people and I'm just feeling like I need to work on that because it just really came out to me that that's important."
Or, it's, "I learned the way that we are building this product is just not going to work and we have to sit back and rethink that structure." Everybody participates in that moment of learning and that reflection that happens. Just by doing that on a daily basis, you create a culture that makes learning happen all the time. It's not about failure. It's about success. It's about what did we learn.
At the US Digital Service, they have a motto which is, "Only make new mistakes." The idea is mistakes are going to happen. It's going to happen big, but we shouldn't make the same mistake twice. How are we going to learn? How are going to get things better?
When you think about it, there are some underlying themes that came out over the last two days that fit into this really well. For instance, one of the themes that came out was the theme of storytelling. That part of our job as the leaders of design is that we have to be the emcees of a massive storytelling effort.
It's the storytelling of what we're trying to do, how do we know it's there? If you think about it, what we learn from the users we have to relate to the people who didn't see those users. We have to tell the stories. There's nothing more potent than telling the story of a frustrated user alongside, as Chris pointed out, the importance of telling the stories of happy successful users.
Being able to tell the story of the current experience is key. The telling the story of that vision, what it will be like when we get this thing done, that's key too. Then the telling the stories of what we're learning every step of the way.
We have to foster this notion of storytelling that we're always communicating stories and more importantly we're getting other people to community the stories. We heard Bill Scott yesterday say that one of things he's had great success with as he boils these little mantras down to Twitter size statements. He keeps repeating them in front of the executives until the executives start repeating them themselves.
That's brilliant. That's storytelling. That's key.
The reason that all of us could do the Hansel and Gretel story, if I did that experiment right now, is not because we have prepped for this moment. It's because we heard the story over and over and over again as children.
We have to repeat our story. That's part of storytelling is repeating the stories and putting them in the current context.
Another theme that came out was this thing that a friend who's a brilliant product manager coach, Bruce McCarthy, says which is we have to focus on themes over features. It is so tempting when we hear a problem to immediately come up with a solution. What we really want to do is come up with the theme of what the problem is.
There's an old saying which is, "The best designers don't fall in love with their solutions. They fall in love with the problem." They really get to know the problem. Bruce says that in your product management roadmap, you shouldn't ever list features you will ship.
You should list the problems you will solve because down the road, you may come up with a way better solution to the problem than the feature you can come up with today.
By making the roadmaps be theme-based, themes of problems that the users are having and how we're going to address them, then telling the stories of those themes, that's what a product manager does. That's what a great product manager does. That's not a whole lot different than what anybody else in the design process should be doing.
We get to this idea that I've been saying for a long time which is that great design is actually invisible. Bad design shows itself all the time. It's like the air conditioning in the room. You don't notice the air conditioning in the room if it's set perfectly. You only notice the air conditioning in the room when it's too cold or when it's too hot or when it's dripping on you.
I know you know this, but I'm going to guess that the collective here, if I were to measure the collective of all of us here, if we were to look at all the hours we each individually have spent in meetings in our lifetime and added them up, we'd probably be way over 5 or 10 million hours of meetings. I know that's very sad, but it's probably close to true.
I'm going to guess in all of those 10 million hours of meetings, there's never been one meeting for any of us where someone raised their hand and said, "Excuse me. Excuse me, I just want to say whoever set the air conditioning in the room, you did an amazing job.
I brought a sweater, I haven't needed it. I usually do, but you did a fantastic job. So, I just wanted to say that. I didn't mean to interrupt the meeting. We can get back to talking about the layoffs."
Really good solid design is invisible. What costs a billion dollars for the MagicBand was not the band. It was everything they had to do to the parks to make those three radio transmitters work at every moment.
They had to build a radio receiver into every hotel room door. They had to build tracker and elements all over the park. As your family goes through the on this experience throughout the multiple days that it's there, the park is constantly taking pictures of you for which when you get home, you receive an email with a link that brings you to a photo album of your vacation.
It's pretty awesome. A little creepy. Pretty awesome. Uber taught us that pretty awesome and a little creepy are side by side partners.
This idea that design is something everybody should see is in fact the inverse. We will do our job well when the experiences are so awesome that nobody notices the design that went into them. For many of us, that's a sad notion because we have worked so hard to get noticed.
I don't know if you're an amazing designer, how you put together a portfolio and visible things. Maybe you put together a portfolio of all the things you didn't build like, "I didn't make that. You would've noticed that. I didn't make that either. You would've noticed that."
I want to touch on something that's been gnawing at me. I got my head around it over the last few days. That's this word that we keep using which empathy. I've been hearing this [inaudible 52:15] . I go to a lot of conferences now where people talk about we need to teach empathy. The people who we're working with, they don't have enough empathy.
Everybody has empathy. Sociopaths not so much, but most of us don't work with sociopaths on a regular basis. There's that one person, but everybody else isn't a sociopath. The thing is you cannot teach sociopaths empathy. They are neurologically incapable of having empathy. That's a waste of cause.
Everybody else already has empathy. The problem isn't that people don't have empathy in our organizations. The problem is we designed a structure to our organization that prevent their empathy from happening. It prevents the empathy from happening, because we're not giving them any exposure to users. We're not giving them any way to iterate over the designs, and see the causal effects of what they build.
We don't build the structure of empathy. This is not a problem with people not having it, we don't let them take it out of its little satchel. We tell them that they have to be objective, and distant, from everything that actually will drive great emotional response to design.
If we really want our coworkers to bring empathy to the table, we have to design our process for that. That's what this idea of alignment is about, that Karen talked about. It is not just getting them to agree with us, it's building the substructure that allows everybody to come to that same "Aha" moment.
They tell you in negotiation school that the best way to get your way, if you want someone to do something, is to let them think of it as if they'd thought that this was a good idea, on their own. That's a fancy way of getting to alignment.
Alignment is everybody in the room having the same "Whoa. What if we did that?" moment. You get there with the tools that we have, but then to put those tools into perspective, you have to make sure that you are getting them out.
Our job, as the leaders in design, the ones who are trying to make our organizations competitive, our job is not to convince people that UX is important, but to bring out the current experience, to bring out our vision, to put in that culture of learning, to remove all those obstacles, all those elements, so that we can get there.
If we want the lawyers, and the procurement people, and the executives, and all the other stakeholders to come to that same moment, saying, "This is what we're all trying to do," we have to bring those stories out. We have to bring that forward, and make that culture, the story we tell ourselves, about telling the stories of design.
We have to in essence, design how we're going to make UX be a competitive advantage. That's what I hope you've gotten out of the last two days. Thank you very much for encouraging our behavior.
Here's an excerpt from the article:
If they understood the situation, they could interview the mechanics, pilots, gate agents, and operations personnel after the fact. However, that presents its own problems. It's hard to ask the right questions to get to a deep understanding when you don't know what questions you need to ask.
The old tried-and-true methods of observation and interviews won't cut it. We need something else to get us the deep insights that will tell us how to design for complex independent systems dealing with infrequent, edge condition issues.
Read the article For an Edge Condition, Seeing The Problem is a Problem
What are your thoughts on designing for solutions? Tell us about it below.]]>
I've put together this great UX conference to focus on these challenges and their solutions. You'll gain actionable insights on:
That's just a small portion of the techniques and practices you'll bring home.
You need to look at what we've created to see why I am so excited about what will easily be the best design conference of the year.]]>
Now I look at the basic usability test protocol like it's a column of wet clay, ready to be molded into exactly the research instrument we need. Over the years, we've invented, borrowed, and stolen different variations, all to help us better understand our users and what we're designing.
In today's article, I talk about five of our favorite variations. You'll see how we bend and twist basic techniques to discover new things about what we're designing.
Read the article: Bending the Protocols: Useful Variations on Usability Tests
What are your favorite variations on usability testing? Tell us below what you're doing.]]>
Here's an excerpt from the article:
For many designer candidates, your ad is the first thing they'll see. It's the only exposure they'll have to your organization until after they've applied and you've called them back. Everything in your ad needs to convince a candidate to apply.
No, that's not quite right. Not just apply. It needs to convince them that they want to work for you. It needs to convince them to put your job as their first choice. A great job ad goes way beyond just encouraging a potential new hire to apply. It inspires and creates desire to be part of your team.
Read the article Your Job Ad: The Start of a Great Hiring Experience.
What do you think talented designers look for when they're considering a new position? Tell us about it below.]]>
Here's an excerpt from the article:
Those folks who learn how to do a good enough job have become consciously competent. They can make good results happen most of the time, though they often don't know the underlying theory as to why. (Think of someone who can follow a baking recipe and create great cupcakes, but doesn't understand the chemistry of baking.)
Read the article Designing without a Designer.
What challenges has your team faced in reaching conscious competence with their design skills? Tell us about it below.]]>
Here's an excerpt from the article:
As we were studying the different teams, we realized the outcomes in the more effective meetings didn't happen by chance. They were quite intentional.
These teams had built up a toolbox of tricks and techniques that they regularly employed to get the most out of their meetings. The less effective teams tended to walk into the room and improvise how they were going to get their results. "How do we want to do this?" was a familiar starting refrain in many of these meetings.
We noticed the more effective teams spent more time preparing for the meeting than the less effective teams. In setting up the meeting, they'd discuss the approach they'd use and exactly what they wanted to get out.
Read the article: Perspectives over Power: Habits of Collaborative Team Meetings
What methods do you use for successful and productive meetings? Tell us about it below.]]>
That's one of the topics that Steph Hay and I discussed in a recent podcast, Designing with a Content-First Approach. Here's an excerpt from our conversation:
There were a couple projects that had been in usability testing and the teams were saying "I know that there's something here and we just can't get at it." What we ended up doing, taking a content first mindset, is actually extracting the content from the interface, from the prototype that we were testing, and putting it in a Google Doc or in a Word doc and then going in and testing the language agnostic of the interface.
We would figure out where the ah-ha moments were and we would pay attention to the language that they were using, so that we could really understand what specifically were the compelling words that would make somebody want to move forward.
Listen to the podcast interview or read the transcript.
In Steph Hay's UI20 workshop, Content-First UX Design: A Lean Approach, you'll learn how to:
If the users of your product are requesting what seems to be a simple fix, such as moving a button, perhaps there are greater underlying reasons. So rather than just accepting the request and acting on it, using research to uncover that "why" can lead to a new use case that you weren't actively supporting. This in turn can lead to greater opportunities for the business as a whole.
Bruce McCarthy and I spoke at some length about this in a podcast around UX and Product Roadmaps. Here's an excerpt from the podcast:
If all you're doing is getting into a feature-checklist war with your competition, that's just a recipe for becoming a commodity. You and all your competition will have the same list of features, and the only thing left to compete on will be price. That's a terrible place to be operating.
I would much rather be the product or the company that really gets a particular segment of buyers and users. Really understands them in depth and can, as a result, serve them better than anybody else.
Listen to the podcast interview or read the transcript.
In Bruce McCarthy's UI20 workshop, Collaborative Product Strategy: How UX Can Influence Product Decisions, on November 2, you'll learn how to:
That's why we've asked Jenn Lukas to give a full-day workshop at the UI20 Conference in Boston, November 2–4, on Mastering CSS to Build a Living Style Guide. Recently, I interviewed Jenn about her topic. Here's an excerpt from our conversation:
When we understand the tools that we work with, we all become better at our jobs. The same way as a developer understanding design principles can make me develop better. I know what to QA for, I know how to keep a consistent grid, I know what goes into good typography. These are the rules that make you more well-rounded.
Going the other way, to be able to know what CSS and technology is capable of really helps people to create better, stronger designs. To know where you can push the limits of design, to know where things can be scaled back, to know what goes into the building blocks of creating something.
Listen to the podcast interview or read the transcript.
In Jenn Lukas' workshop, Mastering CSS to Build a Living Style Guide, you'll learn how to:
See what else you'll do during Jenn's full-day workshop at the User Interface Conference, on November 4 in Boston.]]>
The client had hired us because they were concerned about checkout-process abandonment. Their analytics were showing a 13% drop off in sales, which, based on the average value of the abandoned shopping carts, was worth about $1.2 million a year in additional revenue.
Checkout-process abandonment is common in e-commerce sites and something that you can easily detect with your site's usage logs. You just look at the number of people who get to the first screen and then the number of people who actually complete the transaction. Everyone who doesn't make it is an abandonment.
Two weeks of usability testing on the live site (and on competitors' sites), followed by two weeks of iterative paper prototype testing produced a streamlined checkout process, which, once implemented, showed a dramatic increase in revenues. It's amazing what you'll learn when you actually watch your users.
Here's an excerpt from the article:
It's hard to imagine a form that could be simpler: two fields, two buttons, and one link. Yet, it turns out this form was preventing customers from purchasing products from a major e-commerce site, to the tune of $300,000,000 a year. What was even worse: the designers of the site had no clue there was even a problem.
Read the article: The $300 Million Button.
Have you seen results from changes to your forms? We'd love to hear your experiences. Share them with us below.]]>
Here's an excerpt from the article:
It's not news that the content is the important part of the design. For years, Karen McGrane has told us that working on the design without considering the content is like giving your best friend a beautifully wrapped empty box for their birthday. They'll enjoy opening it, but will be sorely disappointed with the entirety results. And recently, Steph Hay reminded us that "content is the entire reason people come to the design in the first place."
The new thinking is that content creation and management cannot be a separate endeavor from design creation and management. That we need to inseparably integrate the two, structurally and organizationally, to create great experiences.
Read the article: Content and Design are Inseparable Work Partners.
If you are struggling with getting everyone on the same page with the conversation your design will have with your users Steph Hay's full day workshop at UI20 will help you.
What can your organization do to make design and content feel more integrated? Tell us about it below.]]>
If getting your team on the same page is critical for your design success, then you won't want to miss this year's UI20 conference. Go explore the full-day workshops and discover how they can make your team stronger and more in sync.]]>
Attend this seminar if you want to:
Save your spot in this October 15 virtual seminar.
Here's an excerpt from the article:
Breaking large efforts into small teams makes sense. However, it also creates silos of effort. The outcome is a disjointed user experience. Employing a service design approach helps feed information into the project prioritization process, to ensure a better experience.
Read the article: Prioritizing Opportunities Across the Customer's Experience.
How could you re-prioritize to provide a better user experience? Leave us a note below.]]>
Recently, I interviewed Nathan on design systems and style guides. Here's an excerpt from our conversation:
Oftentimes, style guide refers to a core part, or a foundation of the library of parts that everybody has at their disposal. People have been building those for years. It's been 10 years since I worked with the sun.com team, and they had a massive component library.
All these component libraries aren't new, but they're starting to get used by more and more people. When you start to think about all the people that participate in that, and all the products they apply these things to, suddenly you have to think more systematically, and that's where the term "design system" comes from.
Listen to the full interview or read the transcript.
In Nathan Curtis' workshop, Building Scalable Design Systems and Style Guides, you'll learn how to:
See what else you'll do during Nathan's full day workshop at the User Interface Conference, November 2 in Boston.]]>
One way of determining that is with a customer journey map. Being able to visualize the path a customer takes while interacting with your product is a powerful thing.
A few weeks ago I interviewed Marc Stickdorn on this topic. Here's an excerpt from our conversation:
The journey map is as good as the data we use to create it. When we talk about journey mapping and getting everybody on the same page, we also need to make sure that the customer has a word in there. That means that we either have data about the customer, solid data, not so much talking about content of data, but rather qualitative research methods, ethnographic research, to really understand, "What is their experience?" from a customer perspective, step-by-step throughout the whole journey. Then based on this data, we can start to redesign or improve it.
Listen to the full interview with Marc or read the transcript.
In Marc Stickdorn's workshop, Service Design: Creating Delightful Cross-Channel Experiences, you'll learn how to:
See what else you'll do during Marc's full day workshop at the User Interface Conference, November 2 in Boston.]]>
Here's an excerpt from the article:
User research isn't the only aspect of digital UX practice that we need to change when we start doing service design work. We need to look at how we prototype services, how we think about the information organized in the service delivery, how the service looks, and what behaviors we want each party to have when interacting in our designed experience.
Read the article: Service Design: Pushing Us Beyond the Familiar.
How have you blended your digital and non-digital channels to create better user experiences? Leave us a note below.]]>
A few weeks ago I got together with Kim Goodwin where we discussed how journey maps and storytelling plays into scenarios and the design process. Here's an excerpt from our conversation:
If we focus on the story of what this particular human being that we're envisioning is doing—what do they see and encounter—it doesn't matter how the back end
does it.
It doesn't matter what technology we use because we're just getting at the gist [of the story]. That helps keep requirements at the right level instead of having teams that do requirements that are actual lists of solutions instead of lists of problems that must be solved.
Listen to the podcast interview or read the transcript.
In Kim Goodwin's workshop, Using Scenarios to Solve Problems, you'll learn how to:
Being able to use just enough code to create an interface element that not only shows how it should look and work but actually displays it in action, is a powerful communication tool.
Recently I interviewed Jenn Lukas on this very topic. Here's an excerpt from our conversation:
When we understand the tools that we work with we all become better at our jobs. The same way as a developer understanding design principles can make me develop better. I know what to QA for, I know how to keep a consistent grid, I know what goes into good typography. These are the rules that make you more well-rounded.
Going the other way, to be able to know what CSS and technology is capable of really helps people to create better, stronger designs. To know where you can push the limits of design, to know where things can be scaled back, to know what goes into the building blocks of creating something.
Listen to the podcast interview or read the transcript.
In Jenn Lukas' UI20 conference workshop Mastering CSS to Build a Living Style Guide, you'll learn how to:
When: December, 2015
Hello there,
What a difference you've made to our team. I'm super impressed with what you learned and brought back to us from the User Interface 20 Conference in Boston. It was just this past November and already you've put what you learned to work and made significant positive impact on the company.
You weren't joking that your goal after the conference was getting everyone on the same page.
Here's just a sampling of what you've put into action.
And there's so much more valuable input you've provided. What a great decision it was to send you to UI20. I wish we sent more of the team. And you saved us $200 with the promo code BOSS. You rock!
This could be the type of praise heaped upon you after you return from the UI20 Conference in Boston, November 2-4. Come explore what the conference has to offer.]]>
A few weeks ago, I interviewed Steph Hay about content-first, a method she promotes. Here's an excerpt from our conversation:
What I actually learned is that they were testing usability and they were adding language where things were breaking down from a usability standpoint to try and help clarify the process. Adding to it wasn't necessarily making it more understandable. It wasn't even necessarily making it more usable.
There were a couple projects that had been in usability testing and the teams were saying "I know that there's something here and we just can't get at it." What we ended up doing, taking a content-first mindset, is actually extracting the content from the interface, from the prototype that we were testing, and putting it in a Google Doc or in a Word doc and then going in and testing the language agnostic of the interface.
We would figure out where the ah-ha moments were and we would pay attention to the language that they were using, so that we could really understand what specifically were the compelling words that would make somebody want to move forward.
Listen to the podcast interview.
Steph Hay has conducted numerous workshops that focus on content-first design. In her workshop at UI20, Content-First UX Design: A Lean Approach, you'll learn how to design conversations that engage and motivate your users, which in turn allow you to design fewer iterations overall.]]>
Attend this seminar if you want to:
Save your spot in this October 1 virtual seminar.
Here's an excerpt from the article:
Now, more designers code. Now, more developers design. Product managers have their hands dirty with everything. They all work tribally in teams spread throughout an enterprise. You can't legitimately tell them what to do anymore. No one is that omnipresent, omnipotent or omniscient. You have to work together to build something bigger and cohesive.
So, how do you form a team that best helps you stay cohesive with a system? It depends on who you are and what you are capable of.
Nevertheless, modern design organizations are making their way from solitary teams making a library available or a centralized team serving disconnected products towards a more federated approach.
Read the article: Team Models for Scaling a Design System.
How could your company benefit from a federated design system? Leave us a note below.]]>
Here's an excerpt from her article:
In my opinion it's much much harder to write a good survey than to conduct good qualitative user research. Given a decently representative research participant, you could sit down, shut up, turn on the recorder, and get good data just by letting them talk. (The screening process that gets you that participant is a topic for another day.) But if you write bad survey questions, you get bad data at scale with no chance of recovery.
What makes a survey bad? If the data you get back isn't actually useful input to the decision you need to make or if it doesn't reflect reality, that is a bad survey. This could happen if respondents didn't give true answers, or if the questions are impossible to answer truthfully, or if the questions don't map to the information you need, or if you ask leading or confusing questions.
It's worth reading the full article.
You can also hear Erika's interview with me on team-based research and the need to shift away from an academic way of thinking about it.
Using a team-based research approach and skillfully analyzing the data is key to getting your team on the same page when trying to figure out who your users are and what problems you're trying to solve for them. Erika Hall covers this in her full-day workshop at UI20 on Cultivating Shared Understanding from Collaborative User Research.]]>
Recently, I interviewed one of the folks on the forefront of Lean UX, Jeff Gothelf. Here's an excerpt from our conversation:
If I had to list one of the biggest challenges in winning teams over, and providing concrete insight about how to make this work with everybody on the team, visual design is, by far, the biggest obstacle. There's a subjectivity there to the level of fidelity that's necessary to learn what you need to learn.
I think that [the definition of MVP] has been where some of the biggest challenges have been. One of my favorite exercises to do in workshops is to go around the room, and have half a dozen people define "MVP." You'll get half a dozen definitions. I always come back with, "It's the smallest thing that you need to make or do to learn the next most important thing."
Listen to the podcast interview or read the transcript.
Jeff Gothelf has conducted dozens of workshops all around Lean UX. In his workshop at UI20, Lean UX: Agility Through Cross-functional Collaboration, you'll learn how to deconstruct business problems into assumptions that drive product direction. You'll then understand how to prioritize the best product ideas and test these assumptions so that you're building the right product.
Enjoy the podcast and we hope to see you at UI20.]]>
Here's an excerpt:
Part of solving a customer's problem is making sure you don't make it worse. By having the problem as the starting point for the project, the development team has an instant baseline to measure against.
Given a customer problem, the team will come up with multiple solutions. Picking the best solution becomes a trade off of effort against the improvement they can deliver. Determining these factors is easier when they start with a clearly defined problem. Without a commitment to specific solutions, the team has flexibility.
It's worth reading the full article.
You can also hear Bruce's interview with me on UX and product roadmaps where we discuss how the importance of good user experience shifts the product-management world thinking.
Without a doubt, UX can influence a product road map. Bruce McCarthy covers exactly this in his full-day workshop, Collaborative Product Strategy: How UX Can Influence Product Decisions.]]>
Here's an excerpt from the article:
Part of solving a customer's problem is making sure you don't make it worse. By having the problem as the starting point for the project, the development team has an instant baseline to measure against.
Given a customer problem, the team will come up with multiple solutions. Picking the best solution becomes a trade off of effort against the improvement they can deliver. Determining these factors is easier when they start with a clearly defined problem. Without a commitment to specific solutions, the team has flexibility.
Read the article: Themes: A Small Change to Product Roadmaps with Large Effects.
How could Themes improve your customers' experience? Leave us a note below.]]>
Traditionally, user research has taken on more of a scientific identity. You would do usability testing and research, take a ton of notes, and then compile all of your findings into a report. The effectiveness of that research depended on whether anyone read the report, and then if they could do anything actionable with that data.
Erika Hall, of Mule Design, has taken a more effective approach she calls team-based research. She says her goal is to shift the focus away from a more academic way of thinking. Rather than being concerned with doing high quality research, determining how much the research actually helps you will allow you to build and create better.
Another part of team-based research is to view research as having its own customer. Research is sometimes done as a checklist item and doesn't go much further than just being able to say you've done it. When you consider that the "customer" for your research is the people who are going to change or design the product, research becomes more of a service itself. You can measure how well you're doing the research by how well the results help that "customer."
Erika will be presenting one of 8 daylong workshops at UI20, November 2–4, in Boston. For more information, visit uiconf.com.
Recorded: August, 2015
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]
Jared Spool: Hello everyone. Welcome to another episode of "SpoolCast." Today I'd like to introduce you to a wonderful woman who is one of the smartest people I know when it comes to user research. She is the author of the fantastic book "Just Enough Research." We're of course talking about Erika Hall.
Erika is going to be teaching a workshop on November 4th at the User Interface Conference which is going to be in Boston, Massachusetts, November 2nd through 4th. She would be doing a full day workshop called "Cultivating Shared Understanding from Collaborative User Research."
Ladies and gentlemen, let me introduce you now to Miss Erika Hall. Erika, how are you?
Erika Hall: I am fantastic. Thank you for having me on your podcast.
Jared: Thank you so much for coming. Your session is an interesting approach to user research that is a change from the way a lot of us have done it over the years. I've been doing usability testing and ethnographic research, gosh, since the late '70s, early '80s. When we used to do it, we used to approach it very much like a scientific project where you would go out and you would collect all sorts of notes.
You'd come back and you'd assemble the notes into a giant report. You would write the report in passive voice, and then distribute it. Of course, the thicker you made the report, the more of a thump up it made when you dropped it on the table, which was, of course, the most impressive way to do reporting, and then nobody read it. Then you wondered why it was there.
I remember one of my clients having this wall, this bookshelf wall of all the research data ever done. They didn't know how to deal with any of that. That ineffective thing I think has given way to a more effective thing, which you're calling team based research. Am I right?
Erika: Yes, absolutely, because the goals are maybe not different. But I've really looked at changing the focus, because especially when people who come from more academic backgrounds think about research, they really have a focus. It's not necessarily the long focus on the rigor, on finding new information, and thinking of the research, the goal of the research being to do very high quality research.
Because I've been working in client services for a very long time, my goal is always to create the most effective design. While the research should still be sufficiently rigorous, ethical, and sufficiently documented, the goal and the way you measure the success of the research isn't the fun factor of the report. It's how much it actually helps you create something that changes the world to some degree.
Jared: To me, that's really fascinating because this idea that research has a customer and the customer is the people who then use it to change the product or service is not something that I have seen a lot of discussion of. It's a new idea that we don't just do this research as a checkbox part of the process, but it's actually a service we provide and that there are clear ways that we can measure whether we were good at it or not and whether we did a good job.
Erika: The way you measure it is I think it can be a little bit uncomfortable for people who come from a more traditional research background. The person is introduced me to this way of working, who really got me interested in doing research at all, did come out of academia. But he had a much more collaborative perspective and approach than a lot of other traditionally trained anthropologists or ethnographers.
Jared: Who was that?
Erika: Jared Braiterman. I worked with him at Studio Archetype way back in the day.
Jared: How was what he was doing a bit different?
Erika: At the time, I didn't know it was different and that was the beauty of it, because this was the first time, working there was the first time I had worked with a research based process.
I thought it was completely normal and the way things were done to have somebody who was academically and professionally trained as a researcher act as more of a point person, a facilitator, and a coach to our team while the whole design team, everybody, was involved in the research, the developers, the strategists, the project managers.
We all conducted the activities together. Jared led the planning and assisted with the documentation. But we, because we all participated in it directly, we had that direct experience and we contributed to compiling and creating the insights and had him there to keep us honest essentially. I thought that was the way it was done.
Of course, you go out in the world, work with other people, and you find out that was a very special way of doing things. That, while it seemed to make sense, was not necessarily the most common.
Jared: I wonder if what happened…I was part of the very first usability tests that were ever done on software. We were back at Digital Equipment Corporation, and we had one of the first usability labs that was ever built. Now I'm talking like 1980, 1981. We were building out process, and equipment, and stuff.
We had no idea what we were doing, literally making it up. A lot of the protocols, a lot of the things that we take for granted about how to moderate a session, or how to do a usability test plan, even just how not to ask a leading question, we were completely naive.
There wasn't any rules, about any of this. There had been some work done in the way of psychological testing in the past, but to actually work on behaviors, and then change the design and see if the behavior changed, that was all very new. I'm trying to think now as you're talking about, how did we evolve into this very scientific thing?
I think maybe what happened was that we had gotten it into our heads, that if we didn't somehow suggest that there was a lot of science behind what we were doing, that people wouldn't pay attention to the outcomes. They wouldn't pay attention to our recommendations.
They would just say, "Well you know, you just asked four people. So how scientific can that be?" We created this illusion of scientific rigor, and then used the structure of the reporting, and the methodology. All of our reports had these long sections on the protocols, and you put the whole test script in the appendix.
You did all your data analysis, out in the open. All of that was to prove, that we had used science. It had the effect of alienating anybody, who actually wanted to use it.
Erika: No designer is going to go back in, and read a report. Realistically.
Jared: There was a period where if you didn't have statistical P values, to show the statistical significance, you couldn't say a finding was true or not. It was so silly. The whole thing was silly [laughs] . I'm embarrassed. It's like when you look back, and you imagine what it was like to watch black and white TV, and you go, "Really? People liked that?"
Erika: That's the whole problem I set out to solve, and the whole reason that I bothered to write a book. I'm really concerned about in design, the basis people use to make decisions. They're just saying that we have in our business…that a design project is just a series of decisions.
As a designer, I want those decisions to be as good as possible. I saw what was happening was that, all of this work and effort was going into the research. If you were lucky enough to get a design project with a research budget, then the focus was on creating these reports, which were then going to be ignored.
The design decisions were still made based on politics, or the designer's preferences, or things that had inspired them. All of the value in that research was lost, and that was killing me. If you get the research done, then the problem wasn't that the research was insufficiently rigorous, or insufficiently statistically valid.
The problem was the knowledge wasn't making the leap into the heads of the people, actually working on the project together, and actually making decisions.
Jared: It would take us so long to get the reports done, that by the time we got them done, the project had moved on. It was no longer an issue. Back in the day, we were working on fundamental things. One of the things we had to figure out was when you have arrow keys on a keyboard, what's the best configuration?
When I started, the arrow keys were in a row, up down, left right. It was pretty clear that was wrong. The idea that we use now which is the inverted T, that was something that came about in the early '80s. We did it first on the DEC LK201, and then IBM copied it.
It took us months to prove the data that that inverted T was the best. We tried an actual cross configuration. We tried like six other configurations. A sideways T where up and down and then left and right were to the right of it. We did all these different types of studies where we were looking at how fast could someone arrow around a text editor.
It was all crazy stuff. Months. Months it took us to do these things, and analyze the data, and prove that we had removed all of the flaws from our hypothesis to get to the results that we needed to get to. Now, none of that rigor helps. It made sense back then for very specific tasks, but it was completely gone.
Given that, where we're at is a different place now in that we need something different from our teams.
Erika: Everything's moving much, much faster, for one. People have to move very quickly. I had a funny conversation with our lawyer about terms of a contract and talking about the software we were creating. I said, "I'm not sure if front-end code really qualifies as software."
We're working with so many existing conventions, and so many constraints, and so much that we don't control. When you're talking about the configuration of the arrow keys, you really are going to control the material they're made out of, the location they are on the keyboard.
Now, we're talking about creating something that's 1 of 50 apps on somebody's phone, and you don't control the design of the phone, or you don't control which model of the phone they're going to have, or you're talking about something that's going to exist in 1 of 50 tabs that someone has open.
It's not the foundational things. It's really finding the things that will differentiate you and finding the things that will help people the most and get their attention. All of those things are changing very quickly, because everything you don't control is changing just as quickly. What you find right now is true might not be true in six months.
It's not about the rear, because you're going to be wrong. The value in research is not the answer. This is something I talk about a lot. It's not finding the right answer. It's creating that culture where you're constantly asking the same question, and you're in a position to keep asking the question, finding what today's answer is, and finding a way to respond to that in your work.
No one person can do this. You can't have the research specialist off in the corner finding this stuff out and then running back saying, "Hey everybody, I have a new answer."
All of the people working together on an interface or on an experience have to be aware of this and have to be attuned to this or you're going to be having a constant argument over whose interpretation of reality wins, and you're going to waste a lot of time.
Jared: That's interesting. There's something to this idea that people come in with a different notion of reality. There might be a person on the team who keeps looking introspectively and saying, "This is how I would use it. If it were me, this is how I would want to use this." That's an important part of reality, but it's not necessarily the right part for that project.
Erika: Right. That's something that a lot of startups get criticized for is the founders come in and say, "I'm designing a product that I would use, and I'm going to design it for myself." Without taking into consideration that there are far more people who aren't like you in some critical ways than who are like you.
There are far fewer people who share the qualities of, say, a Silicon Valley entrepreneur than there are people with other lives, and other priorities, and other ways living out there in the world who are going to be potential customers or users for your product or service.
Jared: Then, there's the product owners who say, "My customers talk to me all the time, so I know what they want." That's similar, right? Customers are coming to them and saying, "Wouldn't it be cool if we actually had the text upside down on the screen, because then I could read it when I'm hanging from the ceiling?"
Erika: That's actually one of the criticisms of research is that you're asking people what they want. People will speculate, and this is something you have to be really careful of when you do research about people and their actual behaviors and habits.
If you ask the question the wrong way, what you'll hear is what people are speculating about, which might have no connection to how they actually behave. We humans are terrible, terrible reporters of our own behavior.
That's one of the key research skills is getting through that. Through how people think of themselves, which is usually a little bit more optimistic than how they actually behave. The product owner's going to be really optimistic about, "Our customers are going to work a little bit harder to get what we offer." Whereas, people in the real world are actually pretty lazy and pretty habit-driven.
If you talk to people about, "Would you use this feature? What do you like? What do you want?" they'll imagine these scenarios that may have very little relationship to what they actually do, and what they actually need, and the choices that they make if they're using something in a real-world scenario.
Jared: How does team-based research, how does that approach change this?
Erika: It changes this by making the documentation secondary. The goal is not to produce a report. The goal is to create this shared understanding so that everybody in the team knows here's what our goal is, and we're very clear about our goal. Here's what our constraints and requirements are.
To really think about the assumptions together and develop the shared vocabulary about here's what we're betting on, and here's our evidence that those are good bets.
Once you work together to establish that, and figure out what your research questions are, and work together to find the answers to those questions, then throughout the entire rest of the design process, you don't have to have a discussion about what your basis is.
You don't have to argue about, "This is the behavior we're designing for." "No, this is the behavior we're designing for," or, "This is the most important business goal," or, "This one is…" What you can say is, "Given that we all know the same things, then you use that as a basis to evaluate something," and say, "This design is going to be more successful based on what we already know."
It changes where the discussion happens to a much more productive place. I'm not trying to eliminate arguments, because I think having strong different points of view on a team is very, very productive and very useful.
That's one of the greatest things about working in client services is we have a perspective, and our clients have the perspective based on their business, and we argue things out. Through that debate, you get the really strong solution. What you're doing is not arguing about your givens or your fundamentals. You're arguing about how you're going to achieve your goals.
That makes everything more more quickly, and it makes everything more productive. It's also a lot more fun. That's what gets lost in the whole rigorous research, writing a report. The research process is actually really fun and interesting. There's all this resistance.
There's this stereotypical resistance you get from clients, or designers, or engineers who just want to start working, start coding, start designing. You say, "We have to do some research first," and there's this collective groan. It's like doing homework.
Once you're actually in the process, once you're doing the user interviews, or doing the contextual inquiry, or doing some competitive usability testing or something like that, everybody participating in that is all of a sudden seeing the world with new eyes and really enjoying this new information.
Not just pecking their own heads thinking about what they already know. It's an amazing experience that makes you want to go out and do more and do more. It also removes that antagonistic relationship, which is not really antagonistic, between the researcher and design and development team.
It's like everybody's on the same team. Everybody's on the same mission to have the best possible information that they can get given their time and resources in order to solve a problem.
Jared: I could see how researchers that might feel that they're somehow giving up control if they let folks participate in the research this way. Somehow, they might not see the same problems that I see, or they may not come to the same recommendations that I see.
That would frustrate and potentially push someone who's been doing research for a while back from taking this more collaborative approach. Do you think that that transition from the older approach to this is difficult, or do you think that this actually is something that if they give it a shot, they may realize that times have changed and there's a new way of thinking about this stuff?
Erika: What you're talking about is absolutely a real thing that happens. Researchers can really feel that they've lost control or, even more than control, that they've lost value in an organization, or in a project, or in a process.
Jared: That's true. If everybody can do research, what do you need me for?
Erika: Right. I was on a panel at a grad school…
Jared: I'm sorry.
Erika: [laughs] …last year. It was really interesting. It was a user experience class. That evening's class was about research, so they brought in various professionals. I was the only person at the table who didn't have a PhD.
Jared: If you pay enough money, you could have bought one that evening.
Erika: Yeah, seven years of my life and a lot of money. The instructor asked the panel, "Which do you think is more important, specialists or generalists?" Of course, I raised my hand, and I said, "Generalist," because of my perspective. There was a woman sitting next to me who was like, "Specialist, definitely."
She was a career researcher who had worked in a couple of very large corporations, and she loved being able to really go deep, and go rigorous, and do these very expansive studies, and work with her team of specialist researchers.
As she was talking, I felt this cold feeling in the pit of my stomach, because the way she was describing her career was pretty much the opposite of everything I enjoy about my work and what I do. It took me a few minutes to really separate that and realize she's the great person. She's really smart, and she really enjoys her work, and she's a delightful person.
It's just like what she likes in her career is very different, and that's OK. I had this whole set of feelings about what she was saying.
Erika: I'm like, "You're fine, but wow, I'm glad I don't have your job." She told this really heartbreaking story about an organization she was working at, a giant Internet company. She was working with one executive who was advocating for this new product direction. They were going to be redesigning some things.
She knew that he was wrong in some of his assumptions, and she said, "You know what? Let's talk, and I'm going to go over some of the work we've been doing that I think is really pertinent to what we're talking about here." She set up a meeting with this executive, and then she went back to her research.
She spent days, she described it. She even worked over the weekend going back over her findings and making sure she had her case all laid out. She put together a really nice presentation and an accompanying report. She was all set. She walked in Monday morning to find out that this executive had canceled their meeting and never rescheduled their meeting.
That right there, to me, is the crux of the issue. It doesn't matter how good your research is if you're not integrated into the decision-making process. You will be ignored, and it doesn't matter how good the research is if it doesn't have an impact.
That's very different from the academic perspective, where you are doing research for research's sake. There isn't this sense of your research is valuable to the extent that it assists some external goal. When you talk about applied research, not pure research, what we do, the research only matters…
When you come right down to it, you're not doing this for publication in a journal. You're doing this to help a business, so the value of your research is measured against how much it helps the business. I'm saying business in the broadest possible sense.
For people who still have that academic perspective, that can be just as distressing and repellent as I saw this career path. [laughs] That whole moment and that whole conversation both helped me empathize more with people that come from that type of career and that type of background and made me feel much more confident in my own position.
When I go out and talk to people, a lot of times I get researchers who are very happy that they have a way to bring people into the process, but I do still find that there are people who come from academia, which is not a traditionally collaborative environment. A lot of it has to do with that.
When you get your professional training in an environment that absolutely does not reward collaboration and then you go into an environment where you're really supposed to help make a team succeed, you don't have the tools for that. This is one of the things I really emphasize and what I've really been working on.
People think that working together, talking about the same things in the same room with a group of people means you're collaborating. Collaboration, really, really doing it, is both unnatural for people and very difficult and requires this high level of attention and commitment.
The nice part about working with research is doing this research together makes teams more collaborative. By being collaborative and doing the research, it makes the research more effective. It's this really virtuous cycle, but it doesn't happen on its own. It absolutely does not happen on its own.
Researchers, as humans, will do what's habitual and comfortable for them, which is want to be a specialist, and go off in a corner, and do a rigorous course of study, and write up a report. Then, designers and developers will do what they want to do, which is not read anything and go off and do things that are interesting and feel productive to them.
You have to recognize that changing these behaviors is not insurmountable, but it requires intentional effort on the part of everyone involved. Once you have that, then it's all great, and you get people working together. Sometimes, you have to make a change if people come from a much different culture.
If people come from a really strong, engineering-driven Agile culture or people come from an academic research culture and you get them all together, you have to work on change.
Jared: In order to make change in the team, part of it I think people run into is this idea, "Well, if I'm going to do research and the team's going to be heavily involved, now I have to train them how to do the research. What if they do it crappily and the research is not as rigorous as my standards allow?" They get themselves wrapped up in this.
There's all this practice that has to happen that if it doesn't happen, we've made something that we can't base decisions on. One of the things that I've seen when people start to do this collaborative stuff is that none of that really matters.
The real epiphany is that moment where, I don't know if this has ever happened to you, you have a stakeholder or developer or somebody who has been working on this project for months or maybe even years. The first time they see a real user using the thing that they worked on, they go, "Oh my, why didn't we do this two years ago? It would've settled so many arguments."
Even though it was one participant, or even half a participant by the time they come to this epiphany, they're suddenly all engaged, and they're like, "Wow, this is so different than what I expected."
Erika: That's an amazing moment. That just points out what a sociologists are studying right now is the fact that data doesn't change minds. It's just like that researcher in that big organization who couldn't physically reach that executive. People's minds are very good at shutting out data that they don't want to hear.
The first thing you've got to do is rally everybody around what the goal is. Once you know what your goal is, yeah, then you start showing people how going through this process makes you more likely to reach that goal. It's a very experiential thing.
If you come from a place of, "I use data to make my case," and you say, "You've also got to be a sales person," which, again, is something that most academically-trained researchers aren't accustomed to being.
That's a sales moment for research, when you bring a stakeholder in and you're like, "Watch this, and see the power, and feel the change in your own mind when you see all of your assumptions blown away." Those are really, really powerful moments.
It's incumbent on everybody working to think, "What is my real goal?" and try to be honest with yourself. That's how working with a team really helps. People can check each other's biases. One of the big research biases is to be treated as special because you have the keys to these methodologies.
Once you break it down and explain that when you really boil it down, the fine statistics is hard, but humans aren't naturally statistical thinkers. The actual process, the research processes that we talk about, is really, really straightforward.
You have to make sure, as you talked about, learn how not to ask leading questions. Learn how to ask open-ended questions. Learn how to identify things like sample bias or confirmation bias.
If you distribute that into your team and say, "Here's what these things are. Let's all keep each other safe out there and learn to check each other and say, 'Gosh, I think your interpretation might be a little off, because I think you were looking to see that pattern. That pattern's maybe not really there…"
One of the other big obstacles is that that open dialogue is also not a part of every organization's culture. The idea that you could just ask questions or that you could challenge somebody's interpretation of data, that's really scary for a lot of people. They're like, "I'm going to ask a question, and I'm going to get in trouble because I'm going to be challenging authority."
That's what research is. Research is challenging given ideas, so it's naturally anti-authoritarian. If you're in an authoritarian business culture, you have to work very carefully to change that.
Jared: So many organizations say they're data driven, and then ignore all the data that they have at their fingertips. They want things put on a chart and so they'll use data like net promoter score, which asks people on an 11 point scale whether they would recommend this product to a friend and then say, "Look. Our number has dropped from 7.2 to 6.9. We obviously have a huge problem."
But then they don't ask any questions to find out why it might have dropped, or whether that data's even meaningful. Maybe the difference between 7.2 and 6.9 is just noise.
Erika: That's what happens with a lot of decision makers is they like the idea of making decisions based on quantitative data, on things you can count. There's all these industries that have popped up to turn really sketchy data into something measurable. Then people who want to think of themselves…it's the great irony.
People who want to think of themselves as more logical and more rational end up irrationally preferring this numerical stuff over really useful, qualitative information.
Jared: That's fascinating to me, right? Because this whole idea of people…let's say you serve a thousand people and you get back a hundred responses, which would be a good return on something like a net promoter score. First, no one's asking the question, "Would the other 900 responses have mimicked the data we saw?"
Maybe people are so fed up that they don't think you care anymore. They don't bother to answer your survey. If that's the case, then the other 900 people would not rate the same as the hundred people were in love, and were like, "I'll do anything for you. Let me fill out your survey." That's the first thing.
The second thing is, let's say out of the hundred people — I don't know — half of them, 50 percent rate you an eight. If we asked each of those 50 people why they rated an 8, would we get the same answer? And none of these questions get asked. We just look at this result and say, "Our MPS is 7.2."
No one asks, "What does that actually mean?" It feels like to question it is crazy, but then you go and you have some qualitative research. The qualitative research involves this question where you say, "This thing I just showed you, can you tell me how this would be useful in your work?"
They go, "I can't imagine a single time I would want to use this. It doesn't do the thing here, it doesn't do the thing there, it doesn't do the thing there." They're telling you all these things that when you're listening to them you go, "Yeah, it doesn't do that. That would be something it would need to do."
You're doing all this and then you have some product owner say, "That was just one respondent. How statistically significant is that?" It's really statistically significant, because everything they said made perfect sense from what we just learned.
It's like" I have a car, and I don't have a way to turn it on." It's almost like the way we develop our products, if we developed bridges the way we develop online products, the way people seem to want to do it, we would build the bridge and then we would send a car across it. We would watch the car inevitably plummet into the depths below, and then we'd go, "Huh. Maybe there's something wrong with the bridge."
Someone on the team would go, "I don't know. One car doesn't seem statistically significant. We should watch a thousand cars and see if they go." It's like, seriously? That sort of formalization of thought that wants to ignore the data that's right in front of us which is telling us the story about our products and services in such rich, meaningful ways…sorry, you've caught me on a grumpy day.
Erika: [laughs] It's true, because this is what we're up against, especially surveys are so seductive and so dangerous, because they seem objective. That's what's going on here. We always talk about it in our work. We're dealing with ego and fear, when you think about how people make decisions.
People are afraid of a situation where there's something to interpret. But that's how humans work. You can't reduce humans to an engineering problem to solve. There's been a lot in the news lately about the failure of Google+. We can call it a failure now, I think the business press is calling it officially. That didn't work out so well.
Jared: You mean it's supposed to do something more than just keep track of Google employees?
Erika: [laughs] One of the things that has happened there is that Google is very good at engineering problems. They're excellent, that's why the search is fantastic. Everything having to do with data is amazing and fantastic, and all the mapping is fantastic.
But if you're designing something to be used by humans not by other computers, you have to get comfortable operating in this irrational, subjective realm, because it's not like you plug data into a human. People are so irrational. That's the whole problem with traditional economics — if a rational actor was selecting this product at this price, or this other product at this price.
That's not how people make decisions at all. There have been all these fascinating studies. You've probably seen the studies with juries and the verdict they'll return might depend a bit on whether the deliberations were before lunch, or after lunch.
Jared: Yeah. There's all sorts of crazy stuff, and other types of bias too, right? I read this study about they would pass resumes…some place where they were interviewing for a police chief. They were passing resumes, and the resumes, they had two flavors of the resume.
One was very academically oriented, the other one was very street oriented. They were giving it to people who were saying, "Yeah, we don't have any gender bias," but then they would have the male name on the academic one, and the female name on the street experience one.
The people would say, "This position requires a real academic approach, so that's why we chose the male candidate over the female. It wasn't because they were male. It was because it was academic." But then they would switch the names on the resumes so that it was obvious that the female was now academic and the male was street.
Then they evaluators would say, "This job requires someone with real-street smart, so we chose…but we're not biased." Then they found — this was interesting to me — then they found that if they had the folks rate up front which is more important, street-smarts or academics, and they were to write that down before they looked at the resumes, then they were more likely to choose the person based on the actual criteria they had decided, not based on gender bias.
The thing is that these people were completely unaware that they had this built-in bias in them.
Erika: Right, and that's the metaphor that I always use is, if you have a sprained ankle, you know that you can't run. Your body will give you some feedback that's like, "Oh, I have an issue." But if your thought process is biased, there's no signal. There's like, "Oh, you can't think clearly about this issue, because there's a bias."
There's no sensation that you have for that. We get a lot of great signals about our physical well-being, but we get no feedback on our cognition. That's why you absolutely work with a team, because somebody else can help check you.
You get your meta-cognition buddy to say, "OK, we're going to work together. We've agreed that we want to remove as much bias as possible, and so we're going to help each other."
Jared: Is part of this team-based approach to have conversations up front about what does success in our product look like, and how will we interpret the data?
Erika: Absolutely, because you need to know what your overall goal is, that the research is supposed to be helping you with. You really need to know, why are we doing research at all? We're doing research so that we can be more successful in this way. Then you say, "OK, what are our major assumptions that we're betting on, that carry a lot of risk?"
You're like, "OK, so we all agree that these are the major assumptions and these are areas of risk." Then you say, "OK, what questions do we need to ask? What are we trying to find out before we get down to work, or as we continuously work, to help us validate our assumptions?"
Once you agree on those questions, then you can go off and say, "We're going to do these activities to get the data." Then you use those questions in your analysis of the data, because you can't look at what you get out of any data, whether qualitative or quantitative. The value of that absolutely depends on your goal, and on the quality of your questions.
Otherwise, the human brain is a pattern recognition machine. It's so easy, if you don't have a really clear question, and those really clear priorities and that focus, then you'll start seeing patterns. This happens a lot with that bad quantitative data that you were talking about, that you'll have some data without a clear question to ask the data. Then you'll start seeing things that might not be there, because people want to see patterns.
Jared: Yeah. I've been calling this, "Agenda amplification effect."
Erika: [laughs] I like that.
Jared: I believe that we need to change our pages. I go and I look at some analytics, say bounce rate. I see that the bounce rate's really high on the pages that I think we need to change. I walk into the meeting and I show the statistic and I show how the bounce rate, which is measuring is this the last page that people visit on our site, or do they continue on to the site from visiting this page?
I say, "Look at this high bounce rate. We need to change the page so we lower the bounce rate." I've got this rationale that this bounce rate is bad, but then maybe my thing is that I don't want to change the page. The page is fine the way it is.
I go to the analytics and I find the exact same bounce rate and I say, "Look at this high bounce rate. People are finding exactly what they want. They don't need to look anywhere else on the site. The page does everything it needs to do for them. Our bounce rate's perfect." It's the same data, we're just interpreted it differently. It's through the lens of whatever agenda we walked into the room with.
We use the data to amplify our agenda, but that's much harder to do with qualitative data when you have someone sitting at the page and they're going, "Yeah, I came to the page and the page did what I wanted it to do. I probably would have stayed, except I couldn't find anything on the page that told me where I should go next." That seems a lot more valuable to me.
Erika: The truth is you really do need both together, right? You need to know what's going on, what you can measure. You need to know why it's happening. But neither one of those things is helpful unless you actually know, what does your business need to happen? That's why people ask me about, "What about net promoter scores? What about your KPIs and all this?"
I say, "You have to start with what makes your business successful?" No metric matters except the ones that draw a direct line to the things that make your business successful. What needs to happen to cut your costs, or increase your profits, or do something else that means your business is thriving and doing what you need it to do?
That's why people talk about these vanity metrics. Some people get really excited about it like, "Oh, we have this many visits, or this much time on site." I still hear people talking about time on site, whereas it might be that you are very, very successful if people get the information they need and get out. Time on site might mean people are lost, and really frustrated.
Jared: Or engagement.
Erika: Engagement, [laughs] I like that one. The only company that makes money off engagement is De Beers.
Jared: Yes. That's good. That's tweetable.
Erika: You like that one?
Jared: I do.
Erika: [laughs] It's true, it's actually true.
Jared: Yeah, the engagement thing is like, "Oh, yeah. We need to increase engagement on our website." What does that actually mean?
Erika: It means you don't know what actually makes your business successful. I think in the case like especially out here…you're more in the Boston area where you have companies that actually have a business, that need to make money. But out here, we have a lot of early stage companies that don't have a business model yet.
They need something to show somebody so that somebody gives them more money to keep doing what they're doing, because they can't just talk about profit and loss, or something normal, or old-timey. They have to find something that's going up and to the right, and I think that's where you start to get these other things.
We can't measure things that don't exist, so what do we have to measure, and then let's put some spin on those.
Jared: You know, it's the same thing in large organizations. You can be a large multi-national company that makes monitors for shipping crates, or something like that. You still don't know what the value of your home page is. You still don't know how to measure the press part of your website.
You don't know how to tell if you've done a good job on the knowledge base, FAQs that you've surfaced. It's not just start ups that have this problem of not understanding what to measure. In large organizations, particularly large organizations with a lot of moving parts.
I heard Tony Hsieh of Zappos go on about how he hoped that every customer of Zappos at some point would have a problem, so that they could call and see how amazing the customer support team is. As a customer of companies that often has problems, I'd really prefer not to learn how amazing the customer support team is. That feels to me like a reactive solution to something that shouldn't have happened.
But that's often the metric that folks use, is some crazy thing like, "We've put so much investment into our customer support, we should actually create problems so people need to call them." They're not looking at the whole experience.
Erika, this has been really fun and exciting, and I'm really thrilled about the workshop that you are going to be giving at UI20, which is going to be November 4th in Boston. The workshop's on cultivating shared understanding from collaborative user research.
You're going to go into this team-based research approach, and talk about creating strategic research plans, and running studies and then presenting results for the biggest influence. It sounds like such a fun and fantastic day to be able to get a research process that really is actionable, and makes things happen in New York. I'm really looking forward to that.
Erika: Yeah, I am too. It's always really fun for me, because people who attend this workshop really walk out with a different perspective, and maybe more optimism and optimism based on having tools to start. There are things you can start doing right away, to get more of that collaborative research oriented question asking mindset going in your organization, that makes everybody more successful at working on anything.
Jared: I really want to encourage people to go check out the workshop description, because we've put a lot of great information about what you are going to be talking about. People have a really good sense as to what they're going to get.
Again, that's at the UI20 conference. If you want to check it out, it's uiconf.com. It's going to be one of the really popular sessions. If people want to come, they're going to need to register early because it's like to fill up.
Erika: I'm looking forward to it a lot.
Jared: Thank you for taking the time for talking to me today.
Erika: Thank you, it's been a fantastic conversation.
Jared: I want to thank our audience again. If you want to check out the conference it's uiconf.com, and UIe.com. We have a lot of great stuff there. As always, thank you for encouraging our behavior. We'll talk to you soon. Take care.
Fast Forward Six Months…
We'd like to thank you for doing a fantastic job as our Fall/Winter Web Developer Intern. You've excelled at maintaining, editing, and documenting our stable of web properties. You spent much of your time creating all of our outbound HTML emails, and managed those campaigns through MailChimp.
Your site development skills are top-notch, as you worked closely with our web team to improve our online subscription program. You worked your magical HTML5, and CSS3 skills to get our next version closer to what our users want.
To top it off, you've even helped us improve the documentation for our Git-based development process to make life easier for future interns and mined useful data from multiple databases for our Director of Marketing.
Thanks for your energy and enthusiasm during your internship. We know you'll succeed at your future ventures.
Now back to today…
If you'd like this to be your story, send us:
While we're less concerned with your skills and qualifications, we won't compromise on your ability to deliver team results. We'll be back to you in 48 hours if you can follow these simple directions and have what it takes to achieve something special.
You might even want to check out our web sites— http://ui20.uie.com/, aycl.uie.com, and www.uie.com—for some insight into our current efforts. Best of all, hear what past interns had to say about the experience. We think you'll be excited by where we are today and the challenge to get us where we're going.
You will work in our North Andover offices. (Sorry, we don't hire remote interns, or those not already in the United States.) We'll provide all the equipment you need, including Apple hardware and Mac software to bring out the best in your talents and skills.
We'd like this internship to begin by mid-October, with the ideal individual working up to 40 hours per week, but offer flexibility to the right candidate.
Send your resume and write-up to: email@example.com
or: Adam Churchill / Director, Online Products / User Interface Engineering
510 Turnpike Street, Suite 102 North Andover, MA 01845]]>
The expansion of the web past a desktop-based world into more of a multi-device ecosystem has caused organizations to re-evaluate almost everything they do. Style guides have had to grow to accommodate this new reality of multiple screens sizes and resolutions. When you start incorporating the multitude of products across devices and all the people working on them, organizations are forced to think more "systematically."
Nathan Curtis, co-founder of EightShapes, has worked with component libraries and style guides for years. He says that when you're thinking about all the platforms that comprise the totality of an experience, these patterns (such as a sign-in form, or elements like buttons) need to be more broadly applicable. It's one thing to create the structure and layout, then thread all the pieces together for a single app or web page, but when that app needs to scale across platforms, it suddenly becomes a very different animal.
This requires alignment throughout the organization. Different design teams will have different stories to work with, and managing something at a much larger scale means that these stories need to be coherent when it comes to the brand. The designers don't necessarily need to be working on the same products, but they need to design pieces that fit well together.
Nathan is presenting one of 8 daylong workshops at UI20, November 2–4, in Boston. For more information, visit uiconf.com.
Recorded: August, 2015
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]
Jared Spool: Hello, ladies and gentlemen. We're here for another episode of SpoolCast. Today, I have the amazing Nathan Curtis, who has come to us before. Over the years we've been talking to him about design patterns, and modular reusable components.
Today, we're going to talk about Scalable Design Systems and Style Guides. It's a coincidence that he's also going to be talking about that at our UI20 Conference. It's going to be in November, November 2nd through 4th. He's schedule a full day workshop which just coincidentally is called "Building Scalable Design Systems and Style Guides." Today, that's what we're going to talk about.
Hey Nathan, how are you?
Nathan Curtis: Good, Jared. Good to talk to you again.
Jared: Good to talk to you. When we first started talking years, and years ago, we were talking a lot about components. Then we got into pattern libraries. Somewhere in the process, I remember us talking about style guides.
Now, it's design systems. Is this just a change in the marketing, or are these things actually different from one another?
Nathan: I characterize them as fairly different, and synonymous with the expansion of design within the enterprise. When I think about the simplest thing that preceded my work in the industry, really were the style guides.
You think about print style guides, and it's the establishment of the base visual language that a company has, or some organization wants to project — the color, the typography, the logo, the tone, the essence of the brand. Oftentimes those things are comprised in a style guide.
Even that, as a label, can overlap with other people's work, particularly like technical communicators, or editors that have an editorial style guide that oftentimes gets lumped in, or confused, with those two things.
As a UX designer, I work a lot with creating layouts, and the structure, and the navigation, and threading it all together in a cohesive experience. A lot about all of the parts that I have at my disposal. That's where the term library comes to mind.
You have the library of design patterns, like a sign-in pattern, or a search pattern, or whatever the pattern might be, but all of the real, tangible parts, too — the buttons, the form controls, and all the components that you have to modularly build Web pages, in my history, or types of applications.
Oftentimes, style guide refers to a core part, or a foundation of the library of parts that everybody has at their disposal. People have been building those for years. It's been 10 years since I worked with the sun.com team, and they had a massive component library.
All these component libraries aren't new, but they're starting to get used by more and more people. When you start to think about all the people that participate in that, and all the products they apply these things to, suddenly you have to think more systematically, and that's where the term "design system" comes from.
You think about the relationships that those people have, and you think about the platforms and different parts of the experience, and the devices that these products apply to, and suddenly you're weaving together a complex, threaded system of things that you need to maintain. Suddenly the parts need to be more broadly applicable, like a button, and how a button appears in all these different contexts.
Thinking about it like a component, suddenly a person making a Web application thinks, "OK, that' a library of things. I'm going to take the code. I'm going to inject it right into my experience, and it's just a component that I can reuse over and over again."
But the systems, the practices and the way that those people participate, and the way that you ultimately need to consider how that's going to play out over time, because of how complicated it gets, and all those interchangeable parts, not just of the experience, but of how the work gets done.
Jared: Having that sort of larger system, it feels to me like that's going to involve more people, more discussion, getting more different opinions onto the same page. How is it that teams grow into that in such a way that it doesn't feel like suddenly you're mired in crazy politics?
Nathan: There's always going to be politics, and a way to flip that around and talk more positively about it is you need to talk about alignment. A larger scale digital design organization is going to have value of different products, and designers are going to be working across all those different products.
Part of the alignment that you need to have is aligning the vision of how those different designers are thinking not just about the stories that their product teams are working on in each brand, but also about how the pieces that they're designing fit with the pieces that all the other designers are working on.
One of the things that I've seen a number of companies do really effectively is cherry-pick a set of core designers that effectively get partitioned off into this design system team. They're still participating with their product team. They're still leaders, more often than not, in the organization. They have some legitimacy associated with them, but they're also a cross-section.
For example, one team divided it out by discipline. They cherry-picked an experienced designer, a visual designer, someone who is really strong in interaction and motion, and then someone who is really strong with content, and so you have this cross-disciplinary field within the design organization of those different considerations, and they also happen to be a lot of the leaders.
They were the people that would employ and engage with other members of the design organization that would influence it over time, or contribute different pieces to it. Like this person does the iconography on the motion designer's team, whereas somebody else is working on color, because they're part of the visual designers team, and so you have all these different designers that you need to work with.
The other part of the alignment that's more difficult is aligning with the other disciplines outside the consideration of design, particularly the developers that want to reuse different pieces in different ways.
You have the product managers that you really need to work with to convince that the design system and the application have a cohesive experience, and making things more usable isn't another separate thing they need to do to replace features in their backlogs, but instead those are features in their backlog.
Then finally, working outside of the product groups that are creating products, but more aligning with the brand team, and with other organizations, maybe marketing, outside the space of those building digital products.
It does get complicated, but the best thing that I've seen those teams do is identify a core set of individuals, even when they're starting, even when they're a bit undercover, even when they're just trying to feed that system with something to start from. Identifying, usually the team is around four to six people that start building something from the ground up.
Jared: Is this a centralized activity, or do you have clients who are doing this by committee with representation from all the other groups? What's that sort of governance?
Nathan: It depends on where they're at, or what moment in time they're at, because I've rarely seen success in a company saying, "We need a design system," and one doesn't exist. None of their designers are working together, and suddenly they need to carve it out as a specific investment that's going to detract from their ability to deliver products.
I've never seen it work that way. I've actually seen it work better when you have this formative stage, when you have a small group that care about it a lot, are passionate enough about it, can show some results, and maybe start to get some top-down executive buy-in, but it's more undercover.
It's more across products in a way that isn't really engaging something to deliver immediately, but then they start to build that story, and by the time they start to spread it around to everybody else, they have artifacts that demonstrate how the system works and proof of concept, or journey, or set of prototypes. They have documentation of how it's supposed to work.
They have essentially the conversations with the product teams where they're starting to deliver stuff, then the conversation turns into, "Is this sort of an enterprise service? Is it horizontal across the design teams? Is this something that we need to carve out half-time of a certain array of designers to form a team that is more persistent?"
Because once they get into that mode where they have all these artifacts, and they have this energy, suddenly, they need to start treating it like a product and that design system itself is something that might have a road map. It might have a back log of things they're going to do. It might have a specific person managing that backlog and really projecting out what that vision is.
Essentially, the design system itself internally as a service has a product manager to think about it. But that's a later stage. That's when they're in that sustaining mode. That's when they've actually built something and it's really starting to grow and evolve. But nobody starts there.
Jared: I could see this as, "I need a bunch of reusable components for me, so I've built those. I'm working with a bunch of other folks, and they like it. So we started building it for ourselves, and now we're starting to think about, 'OK, there are other groups that could use this.'"
It feels like it could go a couple of ways. It could just be, "Hey, we're going to put this out for people to use, and if you use it, great, and if you don't, that's OK too," or it's going to be mandated across the organization and people have to start to think about switching to it. Do you see those different approaches happening, and if so, what tends to happen when they choose one or the other?
Nathan: I think you need to broaden your spotlight, because I don't think either of those approaches is the best approach. The first one that ends up being a really negative approach is a mandate, coming out with some design system that everybody has to use. It's massive. It's sort of monolithic.
It's created by, hopefully, a representative subset of people, but to all the other people that didn't have a voice, they won't see it as legitimate. And so, mandating, particularly early on, isn't going to work really well.
The other thing that I have sensed doesn't get as much traction is when people build things for themselves and then just open it up for other people to use if they want to, because think about platforms.
If you're designing for a Web-based marketing site, and you have all these Web-based products, and you have all these Android and iOS apps, and you might have a bunch of Windows apps that you also sell to your customers that are embedded in things like SQL Studio. All these things that don't necessarily carry through all of the aspects of the core design language, for example, but could still benefit from aspects of the system.
All these other people are going to dismiss you. Instead of like, "OK, that's great. It's a Web component. I have to use their big monolithic CSS file just so I can get a button. I'm not going to do that. I'm just going to build it myself."
The best teams can see beyond themselves and start to look at their design system as, in part, somewhat of an abstraction, and also they try to think about their design system in a more modular way.
If you look at Google's material design, I don't know if this was exactly their intent, but there are separate parts that you can engage with. There's the spec, there's the description of how the design system works, and all its key parts of motion, space, color, the fab button, and so on.
Separate from that, there's a polymer library to build apps with. Separate from that, there's a material design lite library to build sites with. Those are two separate things that if you're building a site that if you want to use material design, suddenly that's your ticket. But material design as its core is not necessarily a mandated, single toolkit for people to use. It's a lot bigger than that.
I think that the other thing that I've observed Salesforce writing about some is that they actually break down their design system into all its composed decisions. Essentially, their design system at its core is a bunch of design decisions that you break down into different property value pairs, primary color 1, primary color 2.
How can you actually think about it in that way so that somebody building on a Window's platform can suddenly engage with the iconography, the editorial concerns, and some of your design patterns, even though they're not going to use your header component that goes on top of your website, because it's wholly inappropriate in that kind of environment.
If you can break it down into those different pieces, you have a better chance for not just having other people sense the value that you can provide for them, but you take a different mindset of instead of designing just for the product you're working on, you're just myopically, with horse-blinders on, you're thinking a little bit more broadly about what you're doing and the impacts it might have.
Jared: This feels like it's not something folks don't do on a whim. This is really a concerted, thoughtful effort that folks need to put together. If they're going to say, "OK, we're doing the design system thing," this is something that really does require resources. It requires some thoughtful approach to it, and really looking into the future and saying, "OK, what are we going to do with this, and how are we going to make it work?"
Nathan: I think so, but that scares a lot of people. Unless you've got a design organization where obviously you've got 150 designers all going all sorts of directions, and you realize you need to corral that, there's going to be a bigger investment that you're going to recognize, but most teams don't find themselves in that position.
I tend to think that you start smaller and you choose the most important thing that everybody has to do right and/or will be most broadly applicable to everybody else, and John Wiley, from Google said, that's when he said, "Make the right thing to do the easiest thing to do."
How can you think about your design system's core parts? Think color. Spend more time on color than you spend on the dynamic nature of some very specific widget that's important for two of your most important products, but irrelevant for everybody else.
How can you think about the way the color needs to be applied, that you've got accessible contrast that you can essentially think about the range of choices, and tints and shades of these colors, that people are allowed to use, or not? How can you show them examples of good and poor use of those colors and context, because you're involved enough with those other teams to gather those things naturally?
If you start to build from that core, you'll find that starting small and building it progressively with a smaller dedicated team, or not dedicated team in terms of dedicated to the design system, but passionate about it, and working across those different teams will work better than thinking, "I need a design system competency. Time to hire five people," and those five people have no clue what's going on in any other product team, whatsoever.
Because then it's a separate team that really isn't engaged, and it will take them a lot more time to realize the value of that investment as they start to guide and facilitate everything else.
Jared: The sort of factors that push companies into going in this direction, this idea that everything we're producing feels like it's going in lots of different directions, is there an ideal point where a team might say, "Now is our time to do this, or, if we wait any longer it's just going to get worse." Or is it just really you do it when you do it? And there is no good time, or there is no bad time?
Nathan: I can't say, especially, what the magical tipping point is, what that trick wire is that some organization trips over and realizes, "Oh my gosh. We have to have a design system."
I do think it's associated with a few different things that have happened in our industry. You have the whole designers that can code, and coders that can design, and it's overlap in skill sets. One of the things we've seen is there's a mutual appreciation across those disciplines for the structure and the value that each can provide, particularly in how they overlap.
This rise of living style guides, all of these different component ties, manifestations of a design system in HTML and components [inaudible 16:14] design system is a really strong example of that, but also the fact that people can look at Bootstrap and Foundation from Zurb, and now things from Material Design.
All these other industry examples of these component libraries and these design libraries, or living style guides, is now creating a sense of, "Wow, people are organized," and they're starting to see the patterns of how they're communicated and how they're structured.
Another thing is there's this big in-house design movement. As a design agency owner, I'm acutely aware of how the competencies of user experience design, and just design as a competency digitally, has started to garner more and more investment.
As that happens, companies are going to get more and more serious about the processes or practices that they have to make those things happen and conduct the work more efficiently, and share the load across all those different team.
And so as you think about it that way, Google and others have done really well to be public in how they're not just creating those artifacts, like Uber has a great online style guide, but Google, if you go to material design these days, there are highly polished videos that talk about all these different perspectives.
I think, Jared, actually, one of the things that they ask is, "What is this thing called?" and they all say it's eight different labels for a design system and style guide, all these different, what they think that material design represents, but at least it's provoking other companies that want, "What would Google do?" They ask themselves that question, and they can see how this organizations happening, and they can start to model their own behaviors or progression of how their teams model to like that.
Jared: You mentioned Brad Frost and foundation ZURB, one of the things that I occasionally hear is, particularly you hear it with Bootstrap, you can look at a website and you can say, "Oh yeah, they did that with Bootstrap, and it starts to all feel the same."
There's this push back that you sometimes hear from designers about design systems limiting the creative capability and sort of making everything look and feel the same. How much of it is, if we're going to start our own design system, are we better off inventing some whole new style, or are we better off taking something like Material or bootstrap, and then iterating on that?
Nathan: I think more often than not, companies of any particular scale of design are inventing their own design language that they use as their core. I think that there's a recognition within those companies by their design leaders that they don't want everybody conceiving of a different blue and red as their primary brand colors.
What I've been really encouraged by is the designers are open to the fact that there are some core decisions that need to be shared by the entire organization. At the same time, the system needs to afford them the latitude to solve a problem in a way that's optimal for their environment.
One of the examples that I share in the workshops I conduct is about iconography. The fact of the matter is there's a language in a particular character and tone that icons carry through that is a portion of the expression of the brand.
As the teams adopt this use, imagine yourself having 20 different product teams that are all supported by different UX and visual designers and so on. They still can utilize a core set of icons across all their products fairly effectively, until you start talking about Android, because Android and iOS have different sets of icons that carry the same meaning.
When you're on Android, should you have an iOS-inspired icon, or should you be using something that's specific to Android? That's a question where it's obvious that the designers are going to expect to have not just autonomy but the freedom to create an optimal solution for what they're working on.
The challenge becomes in all of those other less clear parts of the system, should they be able to shift how sign in works? Should they be able to innovate and create a new sign in that's based on a gesture rather than a username-password pair?
That's where innovation needs to be fairly delivered because something like that could be a real breakthrough. At the same time, it's going to potentially cause all of the other products to start to change.
The design system isn't necessarily hindrance for that. The design system is an enabler to help you set up all the decisions that you can essentially reuse without concern. Then you can push back on that system to either essentially change it or extend it by the work that you do as an individual designer.
Design systems can't live, can't persist. You can't sustain them, unless they're willing to deal with the outside forces that cause them to change. If you take the concept that it's a centralized thing, you push it out to everybody else and everybody else just has to use it, then it feels like governance. Then it feels like dictation. Designers will, in a sense, reject it or do what they can to work around it.
Jared: What I hear you saying is that the system itself has to have flexibility built into it.
Nathan: Yeah. It needs to be mutable in a sense. They need to be able to look at it as something that will respond to their needs. Back to the sun.com example in 2006, that's nine years ago. It's still today the best component library I've ever seen.
It was all managed by primarily one person. We called him The Overlord. He created components for a wide array of different Web properties. He had a team that worked with him to build a lot of stuff. Honestly, if you couldn't get on his calendar, guess what? He's not going to add to the library. Thus, you're out to lunch, can't do anything.
That doesn't play anymore, particularly because it's not just on the Web. You've got all these different platforms. You have a much richer array of teams. You have a much more diverse set of products that have all their different needs.
If you look at a system as an overlord that you just have to get on their clock in order to get to change it, it's not going to work. The systems that are more enabling and more encouraging, not just usage but contribution, are the ones that will work really well.
You need to have someone that's moderating or a team that's moderating that contribution, making sure that the quality is sustained and that it fits in right and all of those other considerations.
Everybody expects that. If you can actually get people to contribute, that is when a system really starts to live because then it just bleeds into everybody's work, rather than feeling like this resource that you employ and then you have to extend yourself and change yourself independently.
Jared: That change from the overlord to having this more flexible, adaptable, mutable system, does that mean that you have to be better at predicting the future?
Nathan: No. In almost all engagements, at least that I've worked on, I try to discourage folks from predicting the future. A design system to me is about meeting the needs of your organization to make sure the stuff you're building now is cohesive and that you're building it as efficiently as you can.
Predicting the future, in a sense, you start to get into innovation. While there are innovations in how systems work…I'm most curious about those, of course.
In terms of innovating your product line, I believe that that innovation actually rests within the product teams themselves, those teams that are engaging in design thinking and taking the risks and prototyping and getting feedback from their user bases on a biweekly cadence. That's where the innovation is going to occur more.
To me, the system itself is a reflection of the collective decisions that those teams need to sustain their synchronization with, rather than where all the innovation actually happens in an org.
Jared: That idea of sustaining and keeping track as the organization changes, this is…Design systems, it sounds like, are a long-term investment. What can a team expect if this thing really takes off and becomes useful? What can they expect that long-term investment need to be?
Nathan: There are a number of tangible things that probably will require investment. The first is investing in a practice by which designers share their work, try to converge on the decisions that they have. You could think of design shares. You could think of just how you have more temporal periods and intense work to move a particular portion of the experience forward, putting a bunch of designers in a war room for a week.
You could think also of a tangible investment in the documentation. Oh my gosh, shudder. I can't believe I'm saying the word documentation. That material design site is documentation.
Those toolkits are, in large part, documentation wrapping the actual pieces that you can use over and over again. Investing in that experience of explaining what the system is and explaining what all the different parts are that you can employ and how they relate to one another is going to be an investment.
That said, it also depends on how it fits into each of the orgs. I worked for an organization last year, who had a very significant investment in recurring design research. They were running multiple studies a week.
The design system and all of those parts that research team continually was investigating week after week after week, part of the question I wanted to provoke with them was, how can you actually start to synchronize how you communicate what the decisions are, like about color and the research you've done on those color choices and how those color choices work or don't work in different contexts.
The investment also comes more naturally. It's not like I suddenly built a hundred-hour project that I wanted to do to blend those two things together. It's more how can I than just talk to those people to figure out how we could weave those stories together better.
I'd like to think that as the designers in an organization work within their product teams, that they are still going to be able to carve out those moments to either contribute more naturally as the system works or they start to drift towards being committed to that system team as it begins to scale up.
I haven't seen it being much larger than a team of three to five people at its core and then all the non-quantifiable contributions of all those other folks participating that are actually designing products themselves.
Jared: Three to five people for long-term stuff and then all the different folks. I love this idea that as research is being done, as parts of the products and services are being tested, that observations that they had about the design system elements get put back into the design system documentation. People can see not just what they should be doing but what research has shown works and doesn't.
Nathan: Those are two examples of what might be a small number of enterprise-level concerns that all designers are going to care about, or at least the ones that I would be working with in an organization I'd hope they care about.
Another one is just what products are we working on? What are we innovating? How can you generate the visibility and the awareness across all of those different teams? The design system just becomes one of those vehicles to generate that awareness and actually bring people together.
It doesn't mean that people need to become experts on every nook and cranny of the design system. Being aware of the ongoing research, being aware of the ongoing cohesive converging design that the team has is going to be part and parcel to everybody, all of the different designers' participation.
Jared: It would seem to me that it would give a nice foundation for critique, too. When folks are needing to deviate from the design system, you can get into the rationale and really talk about that in a critique setting. That would be really educational, plus it would really help define where the design system needs to be helping and where it gets in the way.
Nathan: You hit upon a really good opportunity that the design system provides. There are structured design shares that the design system can sometimes provoke. Think of a weekly session, where all of those key influencers of the system plus other designers that are welcome to attend.
Then you get these presenting designers that bring their stuff that they're working on. They might bring it once every quarter or once every two months or something like that.
There are positive and negative things that happen there. The positive things are that everybody is seeing more design that's bubbling up throughout the organization. They're also getting critique from all the design leaders, who happen to also be the stewards of the design system.
At the same time, those conversations sometimes go south because then the conversations become a critique of the product design's quality. In that forum, that's not necessarily the best thing to talk about.
I'm not saying that you shouldn't critique quality or try and raise the quality of an individual product. That forum affords you the opportunity to talk about things that are relevant to all of those people, that cross section across your enterprise.
The conversation that I have tried to surface through those is by talking to the presenting designer a couple of days before. We talk about their product. We ask, "All right. What questions do you have about how you're employing the design system? Do you think you're doing really well? Do you have a new idea? Are there questions around how you are less confident about the decisions you're making?"
I try to help them form three to four questions that are…Honestly, if they have half an hour and they don't belabor that endless context to describe what their product context is, because nobody else wants to hear about that, they get really bored really fast.
Instead, they show their stuff. They ask pointed questions that are relevant to the system and relevant to everybody in the room. Suddenly, you're talking about the application of a tint of the shade of blue for their off-canvas menu.
"Should you really do that? It's kind of a muddy, middle blue." When you open up the off canvas, suddenly you have this really big block of color that's muddy, whereas the design system and the design language is to use vibrant, strong colors of blue and red.
Everybody talks about, "Should you use these tints on larger blocks of the interface?" The answer was no. That's a relevant discussion that will keep that product cohesive with the rest of the products. You can incorporate and publish that content into the design system. Honestly, you should do it.
"Hey, guess what? Don't do this. Here's a negative example. We've got a polishing platform that somebody just logs in and commits to change." Suddenly, you have another example. That designer is taking back critical feedback that will both help their product be better but also help it be more cohesive.
Balancing that product quality aspect of the critique versus the application of the design system is a tough one to do. If you're talking about both of those things, it's going to justify the rationale for convening all those different important people for half an hour or an hour during their Thursday afternoon.
Jared: That just seems like a fantastic way, particularly when you have teams where you're always adding new people, to just constantly have the design system conversation be front and center. People who are new to it can sit back and listen to the folks who are using it really take apart pieces and explore where the boundaries are of what's acceptable, what isn't, what the philosophies are, what aren't?
At the same time, it doesn't feel like, "OK, today we're going to have our brown bag lunch, and we're going to walk through the 17 approved ways of using color."
Nathan: No, gosh. That'll be so boring. Everybody would check out. They'd come once, and they'd be like, "This is so stupid. I'm never coming back to this thing again." I've seen that happen. It's really unfortunate.
If you re-factor how you're marketing that kind of event, that you've got a person coming in. They've already prepared their two to four key questions they want to ask. You put that in the actual announcement of the program that day that people will look at a few hours earlier to decide if it's relevant for them.
Also, an event like that manifests the values of the organization in terms of how they think about the design system. Whether or not they consider it something that everybody should transparently be able to see. You get all those leaders together. They're demonstrating their commitment by attending. They're also in the open critiquing, and honestly still problem solving how the design system should work.
The design system is not this fix thing. This decided array of design choices that everybody should just use. It's malleable, it's mutable, it's going to need to change, it's going to need to evolve, because guess what, maybe that off canvas should use a muddier, but more neutral color. Oh wow, now we should think about how we're using neutral colors differently.
If you do that in the open, you do that transparently, it's going to be a lot more engaging for others to see, and then be able to express their own voice eventually. Rather than feeling like that product review is a gated design review. Near the end of your project, when you need to go in front of the Design Review Board and have them tear apart all the design decisions that you made inconsistent with the system, which is the wrong way to go.
Jared: Nathan, this has been fantastic. I think that this workshop is going to be so informative. People are going to be able to really get a solid understanding as how to get started. How to build up a really useful, flexible, and most importantly, contributory design system into the organization that brings the level of cohesion across the design.
At the same time, helps the team become smarter about design, just by talking about it. It's really exciting.
Nathan: Indeed. I'm looking forward to it.
Jared: If you guys want to come to Nathan's workshop, it's going to be on November 2nd. It's part of the User Interface 20 Conference. You can find out more information about it at uiconf.com. His workshop is called "Building Scalable Design Systems and Style Guides." It's going to be in Boston. I'm expecting that this session is going to be extremely popular. If you think of coming, you want to sign up early.
Nathan thanks for taking the time to talk to us today.
Nathan: It's my pleasure. It's a lot of fun.
Jared: I want to thank the audience once again for talking to us. As always, thanks for encouraging our behavior. Take care.
Here's an excerpt from the article:
A good roadmap inspires. It inspires buy-in from executives, inspires confidence from customers and salespeople, and inspires development teams to produce the groundbreaking products that drive significant growth.A good roadmap keeps your organization on course toward its destination. Stating what you will do and when makes it easy to judge when you fall behind schedule or get detoured by good ideas that just don't fit your strategic vision.
Read the article: The Dirty Dozen Roadmap Roadblocks.
What roadblocks have challenged your organization in creating product roadmaps? Leave us a note below.]]>
Attend this seminar if you want to:
Save your spot in this September 17 virtual seminar, or make it part of your 6-month program of virtual seminars.
Here's an excerpt from the article:
Surveys are the most dangerous research tool—misunderstood and misused. They frequently straddle the qualitative and quantitative, and at their worst represent the worst of both.
In tort law the attractive nuisance doctrine refers to a hazardous object likely to attract those who are unable to appreciate the risk posed by the object. In the world of design research, surveys can be just such a nuisance.
Read the article: On Surveys.
How does your company select its research methods? How could it improve its ability to measure success? Share your thoughts with us below.]]>
The notion of being a "designer who can code" has been a prevalent topic in recent years. Delivering static PDFs and working in photoshop is seen as inefficient in some circles. Being able to create a clickable or even responsive mockup to present to developers and stakeholders can be a better way to show your intent. It's also much easier to iterate by changing a few lines of code.
One of the greatest benefits of using CSS is speaking the same language as your developers. Jenn Lukas takes it a step further. She shares the example of using a unitless line-height. Instead of looking at it in terms of pixels or em values, view it as a multiplier. This allows you to keep a coherent size across multiple devices and screens. Having this common language aids in creating a more collaborative feel to conversations with developers versus dictating to them what to do.
Designers don't even necessarily need to know the whole gamut of CSS in order to design this way. Being able to use just enough code to create an interface element that not only shows how it should look and work but actually displays it in action is a powerful communication tool. Additionally, you create this living style guide that more closely resembles what the actual finished product will look like and how it will behave.
Jenn will be presenting one of 8 daylong workshops at UI20 November 2-4 in Boston. For more information, visit uiconf.com.
Recorded: July, 2015
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]
Jared Spool: Welcome everyone to another episode of "The SpoolCast." I'm Jared Spool, your cruise director for this next few minutes. Today, we have the wonderful Jenn Lukas visiting us. She's going to be speaking at the UI20 conference, November 2nd, through 4th, in Boston, Massachusetts, where she's doing a full day workshop on "Mastering CSS to Build A Living Style Guide."
I am so excited about this, and I'm so excited that Jenn's going to be there. Today, I'm excited about talking to Jenn. Jenn, how are you?
Jenn Lukas: Yeah. I'm excited too. That's how I am, excited.
Jared: Excellent. One of the things that I love about your presentations is how you make things that feel technical and complicated feel very accessible. I've seen you speak on a variety of topics, including on getting started with CSS.
You take this thing that has all this mystery around it, because when you look at CSS code and you don't know what you're looking at it's a bunch of letters, carets, semicolons, and lots of brackets. It's filled with the brackets.
There's a rhyme and reason to it and once you take that apart for us you make it really easy to understand what's going on and how it works. It's one thing to master something like CSS, it's another thing to master teaching something like CSS.
How long did that take you to do?
Jenn: That's a good question. [laughs] I could give you the overnight or I could give you the still working on it answer, I suppose.
I don't think I would ever say I completely mastered something because I think if I ever did I'd be bored because I wouldn't be learning anymore. I'd say I'm still doing it, always improving doing the stuff.
One of the things that worked really well for me, and I believe in general, is the more that you teach and speak about things the more you understand it yourself. Becoming a teacher, leading workshops, and talking a lot about the subject of CSS has helped me to really fine-tune and cement my own skills in it.
There's that idea, someone was talking about this recently, the rubber duck programming idea, where if you run through a problem, explain it as if you're talking to an inanimate object like a rubber duck.
Jared: Really?
Jenn: Yeah. I think it was Mike Monteiro. Someone was telling me about this.
It's interesting because once you have to speak about what you're trying to do, the problem you're trying to solve, sometimes speaking about you'll solve the problem yourself. You begin, when you have to vocalize something, to understand what it is that you're doing.
Jared: You've been teaching groups like Girl Develop It, right? Am I correct that that's teenage girls?
Jenn: No, Girl Develop It, it was started in New York by Sara Chipps and Vanessa Hurst.
Jared: Right. I was thinking of…there's another one.
Jenn: Yeah, Tech-Girls is one of the ones maybe you're thinking of? There's a few.
I worked here with Yasmine Mustafa to start it in Philadelphia. I taught the first class — it's been four years ago now? — an intro to HTML and CSS class.
It's geared towards women. We have had teenagers with parental permission. Want to make sure that you're not off rogue-learning code at a young age. [laughs]
Jared: That's definitely something you need parental oversight on.
Jenn: [laughs] Don't want to go down the wrong path.
It's really fun. I like teaching anywhere from 16-year-olds to 60-year-olds about this subject.
A lot of the reason that I've been successful in it is because I love it so much. I found a passion when I got into front-end development and I really enjoy it.
The more people I can talk to about it and teach, the more I'm like, "Yes, let me tell you about this thing I love." Because I've tried talking to people about my love of sports, and the Phillies, but you can't really find the right crowd for that, I've got to tell you. [laughs]
Jared: No, even at a Phillies game it's hard to find the right crowd for that.
Jenn: [laughs] Yes, exactly, so I'm sticking with what works, and what works so far has been my love passion for CSS and speaking about that.
Jared: When you and I first started talking about this what I was looking for — for the program — was what do designers need to know to be able to code. Because there are some that jump right into, but there are a lot of folks who are really hesitant.
They believe that programming is a technical art that is to be done only by those who are well versed in the craft and it's not the realm that a designer should be in, but it's not hard to learn basic CSS, right?
Jenn: I would completely agree. I think a lot times learning anything new can be really intimidating for people, myself included, all the time.
We think about things like sewing. If you don't know sewing right now, if you jump in and you're like, "You know what I'm going to do? I'm going to sew a dress," you'll probably be like, "Hmm, maybe I should start a little smaller, like with a pillowcase or a bag."
Starting to learn sewing is something that when you first start you're like, "Wow, I know nothing about this." Then as you move through it you're like, "Oh, I understand these steps," and you build on them, you progress over time, and you learn more about it.
It's the same thing learning anything, learning CSS, as well. You might not jump right in, you might not sew a dress, you might not build an entire website by yourself, but you take these little steps in learning and understanding the language, what it is, and how it works to build the websites that we design and build and code-write for these days.
Jared: Once you start down that road of learning it, it actually can be a really powerful thing, right? As a designer it's not like you're going to get sucked into the development team and be expected to produce the production code, but there's some real advantages to having a knowledgeable access to that dialect of the design.
Jenn: Completely. It's so important to have an understanding, even if not the 100 percent thorough understanding, a good grasp of what it is that's being built to create your designs.
When we understand the tools that we work with we all become better at our jobs. The same way as a developer understanding design principles can make me develop better. I know what to QA for, I know how to keep a consistent grid, I know what goes into good typography. These are the rules that make you more well-rounded.
Before I knew that you might look at something, I'll make it a design, and I'll be like, "Oh yeah, that looks bold," but maybe it turns out it's really semi-bold. You want to be able to identify these things.
Going the other way, to be able to know what CSS and technology is capable of really helps people to create better, stronger designs. To know where you can push the limits of design, to know where things can be scaled back, to know what goes into the building blocks of creating something.
If I was going to make a table, certainly I could throw something together. It probably wouldn't last, but I could put something together.
But if I knew what wood was going into my table I could help make better decisions about what table would last longer, what stains would work well with that. It's understanding the tools that go into it.
As a baker I could look up a recipe to make biscuits and certainly follow it, but if I understood more about things that go into the type of flour, maybe then I would understand that they actually say White Lily Flour is a great type of flour to make biscuits, to help them rise better.
I'm going from going, "Oh, yeah, I can make these biscuits," or "I can make these biscuits super-awesome."
Jared: It's interesting because when I hear people push back on the idea that designers should learn this stuff one of the answers they often give is, "Well, no one's telling the developers they need to learn design." I'm like, "Yeah, actually we are. We just don't need to say that here."
Jenn: [laughs] Yes, that's true. It's interesting, I think I've heard that before, too. Certainly design is development.
I sent a link to someone the other day about the difference between em dashes and en dashes in smart quotes. These are the things that, even basic copy rules and learning about serial commas, can help make everyone better at their job.
Jared: I saw you stand in front of an audience of 500 developers and explain to them good typography habits and how to master fonts. Val Head has taught them how to design with animation.
We spend a lot of time telling developers how to design.
Jenn: Yes, I would say that's true. I wouldn't get up there and tell a developer how to create a typeface from scratch, nor would I be capable of doing that.
There's the limit. You don't need to go as far as that, but there are basic rules and principles that are great to learn and know to get better at what you do.
Jared: Some of it is is that if we're all speaking the language, then suddenly things that come naturally to me, when I pass it over to you as a developer, you can look at my intention and see beyond the surface imagery.
Jenn: Exactly.
Jared: If I want the line-height a certain spacing because I think it's going to make the text more readable I can set that in the CSS. Then you're not guessing that I picked this or think that might be an attribute of Photoshop that caused these lines to be this distance, and you take whatever default comes with whatever and not explicitly set it, even though I was being quite deliberate.
You can't tell what that intention is in terms of what's deliberate and what are we leaving off the table right now without seeing some sort of underlying markup to tell you what was played with and what was left alone.
Jenn: Completely. Even you using he word line-height instead of something like leading would let me know that you gave some thought into that.
Exactly, using the correct terminology when we're describing what we're hoping to achieve really helps people communicate together.
We talk about things, going back to type, the difference between describing typefaces and describing fonts. From a technical place I might describe fonts is the actual files that we're including on the site.
You might say, "Ah, we shouldn't use so many fonts." I might be, "Oh, maybe you don't want this many typefaces, or maybe it means we shouldn't use a bold weight, an italic weight, a light weight of the actual files that we're including.
Jared: Exactly, "Maybe we should cut down on the files because we want better performance," or whatever it is we're going for versus, "We've created a ransom note."
Jenn: [laughs] My favorite kind of design.
Jared: [laughs] Yes, it's so freeing. It doesn't constrain.
Jenn: [laughs] "Get out of here warnings, Typekit, about how many fonts I'm including. I'm going for this."
Jared: It doesn't constrain me.
Jenn: [laughs] This is my web.
Jared: That's right. The web should be free. [laughs]
Jenn: Don't worry. We'll not be creating any of this in the workshop. [laughs]
Jared: That's good. No ransom notes?
Jenn: No ransom notes, unless that's like really wrote then I'll support you in smart ways.
Jared: The thing is that to be able to do this, you don't have to know every little nuance and subtlety of CSS. There's a subset of CSS that you can master that isn't that difficult and will get you from a designer perspective a lot of the distance of where you need to go.
Jenn: Completely. I'm certainly saying, "Hey, learn this," then go out and just become a one person team. Again, the idea here is that we're learning enough to be able to communicate better with our team, our clients, our employees, our vendors, and be able to talk to them better about how we want our designs actually translated.
The idea is to learn enough to be able to say, "Oh, you know what's happening here? We actually need to bump up the font size," or, "You know what? Let's actually use this color variable instead of this one," or, "I see we're adding another font-face rule here. Let's actually use the conventions that we've already set up from this place."
The idea is that we're learning these sort of parts of CSS that help us better say to the developer, to the team around us to describe our designs in a more technical way without going sort of over the top of having to know everything.
Jared: That makes perfect sense to me because it seems like people get intimated. I don't want to learn how to cook because I think I'm going to have to become Rachael Ray.
Jenn: [laughs] Then you also need to spell out your acronyms all the time. Please, don't do that.
Jared: Did she do that?
Jenn: She does that thing where she's always like, "Put a little EVOO on it, Extra Virgin Olive oil." Then sort of going down, "Don't forget your EVOO, Extra Virgin Olive oil." I'm like, "I get it. I know what EVOO is always at this point."
Jared: That's so funny which it doesn't actually take that much effort to say extra virgin olive oil. Actually, after the first time, you don't have to tell them that there's still extra virgins in it.
Jenn: You just say, "Here, put in the oil," like this is what we're doing here. I will say she has engrained that into my head, maybe what she was trying to do.
Jared: That's so funny. I've actually never watched her. I've only read her cookbooks.
Jenn: I've never read her cookbooks. I'm a Martha fan.
Jared: Her cookbooks are really awesome. Now that we're on the subject. She has this set of cookbooks called "30-Minute Meals" which when I was learning how to cook, I found those cookbooks to be really helpful because they have all these interesting combinations of ingredients, but each meal is really easy and really fast to make.
Jenn: It's almost like setting a series of conventions for you to follow as you learn how to cook. [laughs]
Jared: Exactly. There's a lot of similarities here. It works out really nice.
Because we don't need all of CSS to do, what I had asked you for because one of the things that I'm seeing a lot of designers now take on is pattern libraries and style guides. A pattern library style guide is a great way to communicate with your whole team.
The basic conventions are that you're going to follow as a team to make sure that the interface all looks like it comes from one company and one organization and that across different products and service you have what Nathan Curtis cohesion which is basically this sense that all of this stuff was meant to work together.
The idea of creating a sort of living style guide, this idea of not only do you describe what the interface element should do and how they work, but you actually create enough code that people can see them in action and see them working. That we can do that with a subset of the full CSS language set.
That's what I ask you to sort of explore and see. Could we teach a workshop on just enough CSS to do this? You've done a good job. It's going to be a great workshop. I'm curios how you decided what parts of CSS were perfect for this.
Jenn: Totally. Thanks for the compliment. I'm happy you enjoy it so far.
I'm currently consulting for a group that I've help craft a style guide with and sort of done some basic training. I have a lot of conversations there and I identified a lot of sort of where trouble spots and where parts go smoother.
One of the things that we've discussed and implemented there is sort of getting people more on the same language about how they're describing things. A perfect example, it comes down to describing your font rules in CSS, one of those things that comes up a lot is something such as line-height.
We talk a lot about line-height and make sure that we're calling line-height because that's the technical term in CSS for it and that we sort of don't get anything awesome translation. Then we take a step further.
You're in your Photoshop and it's a font size of 12 pixels and line-height of 16. Let's go easy math right now. Let's say your font size is 10 pixels and your line-height is also 10 pixels. You hand off the specs to your developer. You say, "OK, this is 10 pixels and the line-height is 10 pixels."
One of the things that we like to do in CSS is instead use a unitless line-height. Unitless line-height means that we sort of drop the pixel value or points or ems or anything that we could use for describing the line-height. Instead, we think of it as a multiplier. Something like a line-height of just one would be one times your current font size.
The thing that's great about things like unitless line-height is when it comes to designing across small screens and large screens and all those sizes in between is it becomes a multiplier for whatever your font size changes through throughout the document.
You can keep this coherent line-height throughout your screen even if you're bumping up your font-size from 10 to 20 depending on what size device you're on. Describing things like this makes it easier too to fine-tune your design as it goes through different screen sizes.
I looked at the things especially in designing and this like we all know mobile growth. We all know small screens. We all know other crazy devices that are happening right now. That's me designing certainly more of a handful than it used to be.
I looked at a lot of the CSS that would help us conquer that. We'll talk a little bit about things like media queries because I think it's important, not just for developers to know how media queries work, but also for everyone else involved in the process to know how exactly with technical is working.
If we're designing Mobile first, when do we apply this min width? The section of saying, "Oh, when we hit 600 pixels, why do we want something else to happen?" We'll talk a little bit media queries because, again, that's something that knowing about how that works will really help us design better.
Knowing where the changes happen. How to apply those. To show, basically by yourself, you could pass off documents that says, "At small screens, I want my font size to be 20 pixels and at large screens I want it to be 16 pixels." Being able to write the code yourself that you can even test it in the browser then pass that off to a developer.
Jared: The whole idea is that as a designer, I have intentions of what I'd like to see the design be, but I'm not the one who's going to produce the final code to get there, so I have to communicate that to that person, and so things like specifying the line height, using multipliers to show the proportions of things, and using media queries to be able to demonstrate the change in behavior that I want the page to have when I move from one thing to the next.
That's important. In a style guide, if I'm trying to get everybody to have the same changes in behaviors when we go from the smaller screen to the bigger screen, having a way to demonstrate that in the style guide itself would be powerful.
Jenn: Completely. We talk a lot about these things, but it's certainly easier to show it. That's why prototypes have been so valuable over the last few years, because it's really more important to get things into a browser sooner than ever before.
Jared: There are lots of things that people can learn by reading books. There are lots of things people can learn by scanning the Web and seeing blog posts, but my experience in learning coding in general, and CSS in specific, is that it's something that you want to practice with.
Some of it's just teaching your fingers the right sequence of things. When do the curly braces happen? When do the semicolons happen? All those things that, when you leave one of them out, the machine interprets it differently, and then you've got a problem. In the workshop that you're going to do, you've built in a lot of practice.
Jenn: I have. I've also built in self-QA and debugging, so I think you've nailed it. One of the biggest issues when we learn on our own, and there are certainly amazing valuable resources on the Web to learn a lot of things these days, but what happens is when your code breaks, all of a sudden you're like, "Oh no. What do I do?"
One of the things that I like to talk about when I teach is how to identify the problems in your own code, so you can learn how to fix it yourself. The good news about CSS is that most of the problems you'll run into are a pattern of each other, so if things like typos, things like missing semicolons.
We'll go through how the easiest ways to find out where your code is breaking and why that's happening. We've a lot of tools at our disposal to use, so it's really great the amount of ways that it's made it easier for us to bug our own code.
Jared: That's very exciting, because for a lot of people basic user experience design says that nobody likes to feel stupid, so we shouldn't create environments and tools that make us feel stupid. Having to face these technical things and not know how to get out of a problem, and having to ask for help is one of those instances where it's like, "People are going to think I'm dumb."
If I know how to start the process, solve it myself, and have the tools to do that, that saves so much of that effort, and then there's that feeling of accomplishment.
Jenn: For sure. I go back and forth on this a little bit. It's important to know, I guess, you should always feel comfortable asking for help, but it's when to ask for help, so one of the things I do generally in life is I work on something. If I hit a problem or a bug, I give myself…it's the 15-minute rule.
I give myself 15 minutes to fix it. If I haven't fixed it or figured it out after 15 minutes, I'll ask someone for help.
Jared: That's a good rule.
Jenn: It works well, because it gives you that chance to use your own skills. I know these tools I have for debugging. Can I figure this out, or let me Google this, and see if someone's answered this on Stack Overflow, or any of the other resource sites out there.
If I'm still not getting it, then I want to turn and ask someone, because if it's something like there's a typo in your code, you're not seeing it, you still can't find it, and someone walks over and, "Look. You wrote position absolutely, instead of position absolute."
That's something that you don't want to spend an hour on it. You want to spend your 15 minutes, see if you can solve it. If not, move on.
Jared: Position absolutely.
Jenn: Allison Wagner, who I used to work with, and I, used to always joke about that. That was one of her favorites. She would write it all the time. You're going to have it, because you're just used to writing real words, and there's definitely a lot of real words in CSS, which is also a really nice part about it.
That was one of the jokes we always used to joke about. "What's the problem?" "It's position absolutely, when it should be absolute."
See, CSS if full of fun times.
Jared: That's right. Part of me wants a T-shirt that says "Position absolutely." That's my new favorite band name.
Jenn: It's good. [laughs]
Jared: I'm really excited about your workshop. I'm tickled pink that we're doing this, and I think that it's going to be a fantastic day, and that we're going to learn a lot.
Jenn: That makes two of us. I'm excited about it.
Jared: If people who are listening would love to come to her workshop, and who wouldn't, the way you find out more about it is you go to uiconf.com. That's U-I-C-O-N-F.com, and you'll see the workshop from Jenn Lukas, who is talking about mastering CSS to build a living style guide.
That's going to be November 2nd through 4th in Boston, Massachusetts at the User Interface 20 Conference. It's our 20th year of doing this conference. Isn't that crazy?
Jenn: That's awesome.
Jared: It's nuts, because we're not that far away from having audience members that are younger than the number of years we've been doing the conference.
Jenn: [laughs] So cool. It's so cool.
Jared: It is. We're just going to keep doing it until we get it right.
Jenn: [laughs] This is the year.
Jared: This is the year, then we don't have to do it next year. That'll save us so much time. You can come, and you can see Jenn at the conference and all the other great speakers. Check out the website. Again, that's uiconf.com. Jenn, thank you so much for spending this time today, and talking to me.
Jenn: Thank you. I'm so excited. I'm excited for getting to the workshop and eating clam chowder.
Jared: [laughs] We will get you some awesome clam chowder. There's a place just around the corner from the hotel, which has amazing clam chowder.
Jenn: Fabulous.
Jared: I will take you there myself. It's a fabulous little place called the "No Name" that is right on the wharf. Their clam chowder is some of the best in Boston.
Jenn: I can't wait to prove it.
Jared: Everybody who's listening, we'll all go to the No Name. It'll be fun. Fantastic. Jenn, thank you again.
Jenn: Thank you, Jared.
Jared: I want to thank our audience for listening, and as always for encouraging our behavior. We'll talk to you soon. Take care.
Five Overall Benefits:
UI20 Delivers Proven Techniques and Best Practices for UX Designers
Get your team on the same page with proven UX methods and tools. Develop a shared understanding about the designs that will delight your customers. Attend two daylong workshops and a day of talks to learn the latest strategies and techniques for building great products.
Tackle Critical UX Topics and Move Projects Forward
Summary of Costs
Bring this printable version to help convince your boss next time you meet.
Here's an excerpt from the article:
It takes a long time to become a design-infused organization. Many have yet to make the transition. Some organizations are approaching it. These organizations value design enough to hire and embed designers in every project. They see how design is a competitive advantage.
Getting a UX designer embedded on every team is a fantastic achievement for most organizations. It shows commitment to producing great experiences and is very difficult to accomplish. However, there's still room for the organization to grow.
Read the article: Preparing Organizations to Become Design-Infused.
How could your company improve to become more design-infused? Share your thoughts with us below.]]>
Understanding is what user experience as a field hinges upon. 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.
Kim will be presenting one of 8 daylong workshops at UI20 November 2-4 in Boston. For more information, visit uiconf.com.
Recorded: July, 2015
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]
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.
That's because she is an expert on this and because of that, we have her teach a full day workshop at our "UI20 Conference" this year. She's always been a big draw and the audiences have always loved here. If you have not had the opportunity to take this workshop with her, then you have missed something awesome and you should fix that right away and you'll see why as we talk to her today.
That conference is going to be in Boston on November 2nd through 4th. She does a full-day workshop on scenarios and designing with them. Kim, how are you?
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.
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.
If you are listening, if you've listened to all of this and you are just excited about learning more about how to make scenarios work for you and to tell the stories that will get your team successful, then you're going to want to go to Kim's full-day workshop at the UI20 conference — the User Interface 20 conference.
It's going to be in Boston, Massachusetts, November 2nd through 4th, and you want to sign up for Kim's session right away, because that's one of the ones that fills up pretty damn fast. To do that, you got to U-I-C-O-N-F, uiconf.com and look at all the great sessions we have. In particular, make sure you sign up for Kim's, because that one's going to be pretty damned good.
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.
Service design seems to go by an increasing array of names: Customer Experience, Cross-Channel UX, or even just "design thinking." In most cases, these terms describe a holistic approach to your users' and customers' needs, no matter where or when they're interacting with your product or service. In traditionally siloed organizations, it can be no small task to ensure that you are providing the best possible service.
Communication is at the heart of service design and Marc Stickdorn knows the core of it is getting everyone on the same page. He says that the importance of this lies in the fact that customer experiences sometimes aren't tangible—a user or customer could be experiencing an internal event. It's important to understand how different customers come in contact with the design.
One way of determining that is with a customer journey map. Being able to visualize the path a customer takes while interacting with your product is a powerful thing. It allows you to see the moments where they are engaged or perhaps need your service, but it also allows you to have a conversation about what happens between those moments. Being able to design for the exact moment your customer needs the design to function in a specific way creates a very delightful experience.
Marc will be presenting one of 8 daylong workshops at the UI20 conference, November 2–4, in Boston. For more information, visit uiconf.com.
Recorded: July, 2015
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]
Jared Spool: Hello there, everyone. Welcome to yet another episode of the SpoolCast. I am Jared Spool, I am the person who guides you through these lovely discussions.
Today, this lovely discussion is going to be with Marc Stickdorn, who presented at last year's UI19 conference. He did such an amazing job that we've invited him back to present on service design at this year's UI20 conference, which is going to be November 2-4 in Boston, Massachusetts.
Marc is really the person who, for me, made service design be more than just a buzzword. He really understands what it is that we're trying to do and how, as people who are in the user experience business, we can use what we already know and also learn the new tricks that the service world has. His sessions are always fascinating and I thought we'd have a chance to talk with him today.
Hopefully, he's here. Marc, are you there?
Marc Stickdorn: I'm here. Hi, Jared.
Jared: Hi. I love it when the technology works.
One of the things that has become a theme as I was putting together the UI20 conference. It's funny, because the way I put together these conferences is basically I pick the sessions I want to hear most about and then I invite people. Then people like you are silly enough to say yes and then the conference comes together.
When I first saw you in Brazil a couple of years ago, what you were saying about service design and how you were teaching it then was really a jump ahead of everything I'd heard in the past, which is just the same old rhetoric about, make sure you take care of your customers.
You were actually talking about how this happens and the tools that we could use for it. That's intrigued me to a great extent.
But this year, as I was putting the conference together, I realized that all the sessions…it came out when we were writing up the initial marketing pieces. Every session had a sentence in it that said something like, get your people on the same page. It's like, every session is about getting people on the same page.
In service design, getting people on the same page is the big deal. That's really my understanding, is, as I've heard you've talk about it, that's at the heart of what good service design is, is getting the entire team, all the people who have any influence on what the customer or the employee experiences, onto the same page about what a great experience is and how to go about fixing it.
Did I get that right or am I making stuff up?
Marc: No, absolutely. That's absolutely right.
There's always a bit confusion about what the heck is service design. For me, it's not so much about the name. There are many names about the same stuff. It depends on the country you're in, on the company you're working with. They might call it, some just call it design thinking. Some call it multi-channel UX design or customer experience, whatever.
I don't care that much about the label we give it. I rather care about how we do it. The core part of it is, exactly as I say, it is getting people on the same page.
Which means, of course, it includes a process, some tools and methods, but the core of the work what we do is actually facilitation. That means we facilitate a group of people, mostly from very diverse backgrounds, from different departments, different companies. But also, customers through a process using specific methods and tools to talk about the same thing.
The problem we have, when we talk about services, is that services, customer experiences, are not tangible. They're sometimes just conversations between people, and sometimes it's really simply something happening in the head of the customer. It's really hard to get all the people on the same page.
Academically speaking, what we need to create to achieve a consensus between everybody is to create a so-called "Boundary object." Some kind of object which clearly phrases what we're talking about and what we're not talking about. Most of the methods we use in service design is actually to get those people on the same page, using different boundary objects.
Jared: Give me an example of a boundary object.
Marc: Probably the most quoted one would be a customer journey map. What is a customer journey map? Everybody uses them and I really like your talk when you go in stage and say, "Well, I have to put in customer journey maps because then I get more money paid." That is something we see quite often.
But what is a customer journey map? It's simply visualization of customer experiences. It's a visualization of data and it really depends on the quality of the data if the journey maps are really useful and make sense or not. But they can make sense when you work with a group of people to visualize the experience you're talking about, so that at least between the group of people, you're talking about the very same thing.
Jared: The journey maps that I've seen, basically talk to the experience of a customer or a group of customers. When you're using them, they're across, basically, for lack of a better word, all those touchpoints that a customer has, all those moments of interface that the customer has between the interactions.
But one of the things that I've always loved about journey maps is that they allow us the opportunity to talk about what happens between those moments of interface.
Marc: That's why I've really struggled with the word "Touchpoint." I think everybody struggles with that. Because, if you take a look at where touchpoint comes from, it comes from marketing, from branding. Typically, what is a touchpoint was like the billboard at a highway or something, "Oh, it was a touchpoint."
I often like to leave that word out now when I talk about journey maps, because it confuses people. If we just say a journey map is a sequence of steps, and the step could be an interface. A step could be conversation between people. A step in a journey map could be just somebody thinking about something.
You can compare journey map to a movie. A movie is a sequence of scenes telling this story of a main actor. A journey map is a sequence of steps telling the story of the main actor of a service, which could be, for example, a customer.
Jared: But that space between…first, why is it that the touchpoints bother you?
Marc: The first thing is the name. A touchpoint, I think we talked about that last year already. A touchpoint is sometimes nothing you can touch, because it might be conversation between people. It's not a point, because it's often, or it should always involve a specific time. Touchpoint, the word itself, is quite misleading in terms of a journey map. That's why I prefer steps.
But then, also, it depends on what kind of journey map you're talking about, because there are many different journey maps. The first thing is, "Well, what is the scope of the journey map? What is the timeframe? Are we talking about an experience, like a high level perspective of, let's say, a mobile phone contract where the overall high level journey might be like three years, including the time we search for a new phone, when you look for a new contract?"
When you do it, then you have a contract for 24 months. Then maybe you quit or you renew. That's a pretty long journey. But you could also zoom into specific steps, like the moment when you choose your phone in the shop, and have a journey map with a scope of, let's say, an hour, the time you spent in the shop.
Or, you could even zoom into more and have a more detailed journey on one very specific aspect within that one. It really depends on which level you want to work on what makes sense. At the services end, we often switch between these levels. We always consider the context of the overall journey.
But then when we zoom in and we try to improve the experience at a very specific moment within the journey, then we are down to the details. Then we need to look up again, take a look at the overall experience, and how does this fit into that?
Jared: As we're looking at that experience, part of the goal here is to get people who are working on this, all the stakeholders, all the different people who can influence these activities, to actually have a shared understanding of what those experiences are. Often times, this comes as a real surprise to those people, right? They don't realize how hard we've made it.
Marc: Yeah, absolutely. That brings me back to what I said in the beginning. The journey map is as good as the data is we use to create this journey map. If you think now of, let's say, a classic example of a middle or upper management workshop, maybe in the marketing department, and they're sitting a bunch of people around saying, "Let's trade their journey map and see how their experience is."
They do a so-called assumption based journey maps. They make the steps of how they think their experience is. They don't use real data, research based data, but they make it. How useful is such a journey map? But, yes, they are on the same page. They might talk about the same thing, but they're all talking about the own assumptions and not on the real customer user experience.
When we talk about journey mapping and getting everybody on the same page, we also need to make sure that the customer has a word in there. That means that we either have data about the customer, solid data, not so much talking about content of data, but rather qualitative research methods, ethnographic research, to really understand, "What is their experience?" from a customer perspective, step-by-step throughout the whole journey. Then based on these data, we can start to redesign or improve it.
Jared: It seems to me that this is an extension of what a lot of people are already doing when they are thinking about how the website should work, or how an app should work. We're now pushing into all the places that are outside that app.
Now, we have to involve all these different people, and they come at the problem from very different perspectives. Once we have the journey map, is that just the magic formula? Is that the magic touchstone as it were, or is there more work that has to happen to get everybody on the same page.
Marc: No, not at all. In fact, in many services and projects I do, we actually don't do a journey map. A good friend of mine, Adam Lawrence from WorkPlayExperience, he always says, "If you do services, and if you do, only two things in service design. You should do research, and prototyping." Sometimes, you don't need a journey map for that.
When you do research, you see very obvious things where you state like, "How can that be?" Then you prototype a solution. You test it in reality, and you change it. If you do only one thing in service design, I would really say you should do research. That is the most important thing. To get a good understanding of the customer experience.
A journey map is useful as a boundary object. It's useful to get a team talk about the same thing, to visualize that, and then to be able to redesign that to work with that. It's far from the silver bullet, and you do just a journey map, and then you're done. It's just a tool.
Jared: The prototyping aspect of it, when we were at the workshop, you were building, in some cases, full scale experience elements. Like what it would be like to create a ticket station for a bus system.
That helps you physically go through the motions of understanding, "If I have suitcases, and shopping bags, and how easy is it to get the card out of the wallet, and then put my credit card in?" and all that stuff.
That, in itself, is a type of research. Just getting everyone to see that this system can be incredibly complex. So many times in the real world. I was just in Paris, and the Metro ticketing stations, if you are not a French speaking person are actually a bit challenging.
Marc: [laughs] I can imagine, yeah.
Jared: The screens are actually pretty good on the main display, but it tells you to insert your credit card. The messaging on the credit card unit which, I assume, is a third party unit, those are all in French.
Sometimes, you put your card in, and you remove it immediately. Sometimes you put it in, and then you take it out, and then the transaction happens. Sometimes, you keep the card in for the entire transaction. If you don't read French, you don't know which one of these that is.
Marc: Even if you speak French, these machines are just horrible. Even if you speak the language. Sometimes you don't know that there are all these slots for cards. There's another slot for the ticket. Sometimes, they look exactly the same. You'd try to enter your credit card in the slot where the ticket comes out, because you don't know which one is the right one.
These prototypes really help us to explore different solutions. More so, it's about simplification. How can we make it more visual, more simple, and help customers throughout this process, and actually get rid of unnecessary steps within the customer journey map?
What is a prototype? Basically, it's the same as we use in the UX from your buyer framing, but it depends on the channel we're on, what kind of prototype we're doing. If we are, for example, talking about the channel of telephone, say a call center, it doesn't help us a lot if we build a prototype with card board.
Then we rather use theatrical methods like improv theater, raw playing to prototype these situations. When we talk about physical objects like ticket machines, like the check and desk at a hotel and swan, we can really simply build it with card board.
When we go up there on a larger scale, and you think about, for example, a hotel layout, or a tourism destination, then we can use desktop walkthroughs. Where we build a simplified version of a building, of a city, of a destination on the table, and visualize processes, prototype processes with Lego figures, or papered card board.
Really simple methods, but it depends on the channel, and the cross channeling experience which method makes sense in which situation.
Jared: You mentioned that prototyping, and research are the two pieces of this. The research part of this, in its simplest form, it's just observation, but the way you do the observation, particularly since many of these parts of the service experience happen away from the touch points as it were. They're out of sight of the organization. Collecting that data can be tricky, right?
Marc: Absolutely. We use different methods to collect data. Of course, we use plastic methods like Big Data, Google analytics, and also quantitative analytics like surveys, questionnaires, desk research.
We try, always, to use recent…what's already out there, and not reinvent the wheel. Then the most valuable methods for us in service design are qualitative research methods. Ethnography like different kind of observations. Observation, there's a whole bunch of different techniques behind that.
We use interviews. Mostly contextual interviews, so we do interviews in the context of a situation. If we're going back to the ticket machine, we could do an in depth interview retrospectively. Which means we invite a customer, and then talk about the ticket machine, and the experience with their last experience of buying a ticket.
It makes much sense to do an interview in the very situation when they are operating the machines. That means we need to go out in the field, and talk to the people in these situations. We also use stuff like diary studies, cultural [inaudible 17:25] , or we ask people to document their own experiences.
Actually, what I will be talking about at UI 20 will be the result of my PhD, and my latest startup, which is ExperienceFellow. Where we developed a new way to do research where we include real customers as active researchers in our projects.
It's called "Mobile ethnography," where you can set up a project. You can invite your customers. They have a simple app on their smartphone, like a little diary, and they can document, step by step, all their experiences. We see the data coming in real time, visualized as journey maps with different options then to analyze that.
The interesting part about this research approach that many companies think, "Well, it's just qualitative research. Its' not solid data," but that's not true. If you just follow a few rules of thumb, and you use not one method, but, at least, three.
You triangulate your results, you use different sources of data, you work with different researches, you get very solid data with limited bloodshed. It's just a question of how do you do that? That will be one of the things I'll be talking about at your conference.
Jared: Being able to do this with a limited budget, that's absolutely how this has to work, because nobody has an infinite budget to pull this stuff off.
Marc: No, and that's always the biggest restriction. That's why in any project people are hesitant to use qualitative research methods, because they think, "Well, we only have a limited budget, so we could talk or get feedback from 1,000 customers if we do it quantitatively. But if it's really about going out and talking to the people, observing them, including them as research in our projects, we can only get…I don't know, 20 or 30, maybe 50 people with the same budget."
But then, if you ask yourself, "What kind of data actually makes sense?" If you compare, let's say, a questionnaire or stuff like Net Promoter Score, where you get data. Like, let's say, 80.7 percent of our customers are satisfied. 20 percent are not happy with our service on this channel. That that is kind of the level of detail you get from that. That doesn't really help us to innovate.
What helps us to innovate is to observe them and to see patterns in their behavior. It goes back to usability testing more in UX. I mean, if we go back to literature, the early work from Nielsen, what he said, how many people you should ask to find the main bucks, that's basically what we're doing, just on different channels.
We're not interested in finding out if 80.7 percent or 80.5 percent are not happy with that. We try to find out what are the main bucks in our customer experience across all our channels. Then we should take the top three bucks, so the most urgent problems in our customer experience, we should prototype that, fix it, and then start all over again.
It's the same thing as Agile development or Lean startup or Lean UX. But across channels, it's the same process. That's basically what design is. That is an iterative design process.
Jared: Of course, all that iteration just builds up the accumulated knowledge of what customers are doing and what they're trying to do.
It seems to me that we still have some opportunities to do better at this in a lot of organizations. What would you say are sort of the big places that you think people should be focusing on to sort of expand their thinking into the service domain?
Marc: It's really to understand how important customer experience is. To get that idea, how important customer experience is across the whole organization.
There was research from Gartner, Gartner Research, who said that — I hope I get the numbers right — that customer experience will become the new beta field. That 89 percent of companies think that they compete on customer experience in the future, where only four years ago, there were only 34 percent of companies who said that customer experience is important.
We're on that page now, that they understand how important that is. But we don't have the processes within the organizations yet to constantly observe and understand customer experience, because that doesn't work only with quantitative statistics. That's only for monitoring. What we need is qualitative research methods who get the same status as quantitative research methods in organizations. I think that will be the next step.
Jared: The quantitative stuff, though, that's tricky, right? A lot of organizations start their quantitative stuff by just diving into these massive piles of data and asking, what patterns can we see here and then trying to put inferences behind those patterns and then make all sorts of decisions on that.
Lately, I've been seeing organizations that have been going the other way around. They start with the qualitative, they go out and they watch a bunch of people, see some patterns in what they're watching and then ask the question, "How often does this occur in the real world? Can we figure that out?" That tends to produce, really, sort of more actionable results that have fascinating outcomes.
Marc: I absolutely agree. Often we just need to know which question should we ask. If we don't know that, we will drown in data when we try to find patterns and for sure, we will find patterns. Some of that is a starting point, but often that's just leading to not so important or very subjective analysis.
Even though we're talking about quantitative data, because we try to interpret something into these numbers which we didn't really observe in reality. That's why I think we need both. It's not an either/or, it's not that I'm saying we only need qualitative, we need both.
Jared: Marc, thank you so much for taking the time to talk to us today about service design and prototyping and research. It's really fascinating stuff.
I'm really excited about your workshop that's coming up at the UI 20 conference. It'll be November 2-4. The day long workshop that you'll be doing on service design was a lot of fun last year. Everybody spent most of the time doing research and building stuff, it was really a very interactive session. It was so much fun, we learned so much. I'm looking forward to that this year.
Those of you who are interested in the workshop, you can get more information about it at uiconf.com, that's U-I-C-O-N-F dot com. Marc, thank you so much, this has been great.
Marc: Thank you. I'm excited already to come back to Boston. It was a great experience last year, and a great bunch of people. I'm really looking forward to it.
Jared: I want to thank our audience for listening. You guys are awesome. You can learn more about the conference, uiconf.com. If you're listening to these podcasts, if you like them, please go leave us a review on iTunes, that helps us quite a bit.
Thank you again for spending the time with us, and of course, thank you for encouraging our behavior. We'll talk to you soon.
Here's an excerpt from the article:
There are numerous benefits to remote work: flexibility and better work-life balance for employees, and wider talent pools and reduced costs for employers, to name a few.
But what about remote design? Surely, designers won't be required to work in distributed contexts. After all, our work is highly visual in nature. We need to be able to draw and point and gesture. We're meant to work shoulder-to-shoulder.
…With a little forethought, remote design can be as productive as working in person.
Read the article: Effective Remote Design.
How has your company taken steps to improve its remote design implementation and collaboration? Share your thoughts with us below.]]>
Get Your Free Designer's Toolkit
At UI20, you'll choose from 8 different daylong workshops on scenarios, Lean UX, service design, product strategy, CSS, scalable design systems, user research, and content strategy. Plus you'll have a full day of 75-minute presentations to hear from workshop leaders you didn't choose. Three days you shouldn't miss.
Register by 8/20 for this free designer's toolkit
Attend this seminar if you want to:
Save your spot in this August 27 virtual seminar, or make it part of your 6-month program of virtual seminars.
Here's an excerpt from the article:
As we were studying the different teams, we realized the outcomes in the more effective meetings didn't happen by chance. They were quite intentional.
These teams had built up a toolbox of tricks and techniques that they regularly employed to get the most out of their meetings. The less effective teams tended to walk into the room and improvise how they were going to get their results. "How do we want to do this?" was a familiar starting refrain in many of these meetings.
We noticed the more effective teams spent more time preparing for the meeting than the less effective teams. In setting up the meeting, they'd discuss the approach they'd use and exactly what they wanted to get out.
Read the article: Perspectives over Power: Habits of Collaborative Team Meetings
What methods do you use for successful and productive meetings? Tell us about it below.]]>
That's why I designed this year's UI20 workshop topics and speakers with you in mind. You deserve to learn from the very best on the most critical challenges you face when it comes to user experience.
Don't miss the opportunity to come to Boston, November 2–4, to gain skills and soak up knowledge from these full-day workshop leaders:
Explore all the workshops and sign up early. Year over year, this conference sells out and to guarantee the workshops of your choice, it's best to register now.
And do make sure you track me down at the conference and tell me about the cool user experience designs you're working on.]]>
Here's an excerpt from the article:
Game designers start with the story. What they add to the experience complements and builds on the core story; it doesn't distract from the priority of "accomplish goal," even when that takes a year longer than expected, as was the case with Journey, Sony's award-winning game from thatgamecompany.
They design for discovery—learning in the moment not only increases retention and engagement, but it's delightful and emotionally empowering.
Read the article: Content-First Design.
How could your company benefit from designing for discovery? Share your thoughts with us below.]]>
The speed of Agile delivery fundamentally changes the work process and puts new demands on the design cycle. What happens when the notion of deadline dates is replaced with a continual stream of experience enhancements by everyone in the organization?
That is just one of the questions being addressed at the UX Advantage conference. Karen McGrane and Jared Spool will be your hosts as they have meaningful conversations on a series of topics with top design executives.
In this podcast, Karen tackles the UX Advantage topic, Shifting to Continuous Deployment.
Join us in Baltimore August 18-19 for UX Advantage. For more information, visit uxadvantage.com.
Recorded: July, 2015
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]
Sean Quinn: Hey now, everybody, I'm Sean Quinn. Today is another very special UX Advantage podcast. You see, for the past several UX Advantage podcasts, I've been joined by Jared Spool, which was pretty sweet. Today is even better, because we are all really lucky to be joined by the co-executive producer of the UX Advantage Conference, Karen McGrane, who along with Jared has been working really hard on putting together a unique conference that focuses on UX strategy issues no one else is talking about.
How are you doing today, Karen?
Karen McGrane: I'm doing fantastic. Thanks for having me.
Sean: It's great to have you here. The speed of Agile delivery fundamentally changes the work process, and it puts new demands on the design cycle. What happens when the notion of a deadline date is replaced with a continual stream of experience enhancements by everyone in the organization? It must put some strain on the top, all the way down to the bottom. What do you have to say about that?
Karen: It's just such a fundamental shift in the way that we work. As far as I can tell, it's moving our design and development practices into a truly digital space. When you think about all of the historical models from other industries that we have been basing software development on, whether that's…I do a lot of work with the publishing industry.
The idea of, you're going to print a magazine every month so you've got to have this big push up into the printer, where the magazine gets sent to the printer and then you can't make any more changes to it, or architecture, obviously. It's like you either have a building or you don't have a building. It's not like you can be continuously adding to the building.
Even thinking about software development, the idea that up until, just a handful of years ago, all software development was essentially products that were bought in boxes on the shelf. You have the marketing plan behind them and TV commercials and what not.
Now, the idea that we would be creating websites that where apps or digital products that are only ever going to be delivered through the web or through the Internet, it just doesn't make sense. Why should we be following that sort of offline, box-centric model, when we could be continually updating and iterating on these products?
That's just a fundamental shifts in the way that we think about our workflow, the way that we think about our processes, how do you make decisions, who do you have working on the team, who has the power to make changes. I think it's quite transformational for organizations to start thinking that way. I also think it's probably a pretty hard shift.
I do a lot of work with the publishing industry, and so moving an organization away from "we publish a magazine every month" to "we are constantly writing stories and publishing them on our website."
You might think you can just get them to start being like, "We'll publish things all the time," but it doesn't work that way. It changes the whole culture. It changes the whole value system of the organization to be working that way.
Sean: I imagine it also changes the perception outward, inward of your consumer base, what's the value of this thing if I don't have to wait 30 days for this?
Karen: It changes the economic structure. It changes the revenue model. It changes the level of quality in some cases. How do you decide whether something is good enough?
All of that, I think we talk about those decisions as if they are purely technical decisions. How are we going to decide if we're ready to ship something? How are we going to evaluate success? It really gets to some really deep-seated cultural issues, some really deep-seated values around how the organization describes what it does, what the right way to do things is. Those things are harder to change, I think.
I think even organizations that say they want to work in a more agile method or say that they would like move toward continuous deployment, it's going to take them a while to get there. It's not that technically they couldn't get there, it's that culturally they can't get there.
Sean: Whenever you couple fundamental shift or fundamental transformation followed by the word organization, if an organization could cringe, I believe that those terms, "fundamental shift", would make that happen.
As organizations become more calcified with the systems and the habits that they have, how do you go about getting everyone in the organization on board to not only embrace the concept, which just seemed really hard enough, but to then put the concept into action for execution?
Karen: I think we're going to have some great speakers at UX Advantage. We're going to be able to talk about how they did that at their organization. Bill Scott from PayPal, I know, has some fantastic stories of how he has moved PayPal to a Lean UX-focused organization.
I think that all of our speakers are going to be able to describe much better than I probably could what it actually takes to get your engineering team, to get your design team, and to get your executives on board with what it means to do this and to do it right.
Sean: We've talked about in our other conversation how these topics are intertwined with one another. I'm thinking as I'm hearing you talk about the incentives and rewards, there must also need to be a fundamental shift in how those are conceived of and then distributed when you're changing the rate with which things are deployed. Is that an accurate statement?
Karen: Yeah. One of the things I'm most fascinated by is, how does an organization tangibly reward people for performance? I genuinely believe that you can look at how particular executives in the organization get their bonus and diagnose what that organization really values.
They may pay lip service to caring about design or caring about the user experience, but where they put their money is what really motivates them. I think Jared is fond of talking about this, that many, many organizations are motivated by ship dates.
There's the sense of, we've got a product and we think it's got to launch by a particular date, and somebody's going to either get a bonus or get fired, based on whether that product actually meets that date. I know I have definitely worked with organizations that have said, "This thing has to launch by such and such a date, and we will give you more money if you hit that date."
That sets off some really perverse incentives. That sets up some incentives to launch something, even if it sucks. Even if it doesn't meet the needs of the business, if it doesn't meet the needs of the users, but my god, you have that hard deadline and you needed to have something to show for it.
I think that when you poke at that problem, you realize that, there is a deeper ecosystem of goals and motivations that also needs to be changed in order to make something like this happen. You may need to ensure not just that the continuous deployment or that you're moving to an agile method, you might need to ensure that HR is on board with writing, job descriptions, or writing bonus plans that don't use ship date as one of the motivations.
You might need to change the way that your contracts are written. You may need to get your legal team on board with working in a different way. We're going to have representatives from the US Government, Digital Service, the White House, and from Fidelity, talking about how you change the legal and procurement processes to make things like that happen.
I'm really fascinated by how changes like this happen in large organizations, because you realize it isn't just the engineering team, for example, saying, "Hey, you know what will be great? Is if we stop focusing on ship dates and instead move to a continuous deployment model."
The rest of the organization has to be on board with that as well. You've got "little ducks", you need to get in row there before that can happen.
Sean: Let me ask you this then. Is it possible to apply what we've been talking about to the actual process of getting everyone in the organization on board? Could we be continuously deploying as we move towards getting everyone on board?
I'm not sure if it makes sense, but that popped into my head when I was listening to you. Can you move before you have everyone on board?
Karen: I think many of the guests who we're going to be talking with will be able to speak to the small changes that they've made. Yeah. I think there's no way that anybody would ever get anything done if they believed that they had to make one massive shift in the organization overnight.
I think that one of our guests said something. You got to eat one bite at a time. How do you figure out what the small incremental improvements are that you can make in your process so that over time, you get to the place you want to be?
Big changes are scary. They're risky. They're something that people really don't want to take on. Can you do a pilot project? Can you start hiring for some new roles that might start working in this way? Can you change the way that you structure your contracts or change the way that you structure your weekly meetings so that you're moving in that direction?
I would never encourage anyone to think, "We're a failure if we can't do all this all at once." Instead saying, "Where are we at right now? What are the baby steps we can take in the right direction?"
Sean: That's great. Where we are right now is at the end of this podcast, so I wanted to thank you for your time today, Karen.
Karen: Thank you so much. It's always a pleasure to talk to you.
Sean: Watch for other podcasts that'll be covering more of the conference topics. Be sure to check out our conference speakers and all the topics at uxadvantage.com. You definitely don't want to miss this event. It's coming up fast. It's in Baltimore on August 18th and 19th. You can register at uxadvantage.com.
Bye for now.
Monday, November 2 workshops
Prevent endless design debates and feature creep with a shared understanding.
Design for every touchpoint across your customer's entire journey.
Build a cohesive cross-product experience with defined standards and workflows.
Learn structured processes for product strategy, priorities, and roadmaps.
Wednesday, November 4 workshops
Cost-effective techniques to bring user-focused decision-making all through your project.
Establish a content-based roadmap to guide design, development, and usability.
Communicate your design's intent with the same language your developers use.
Bake user needs into the process from start until product launch (and beyond).
There are always burning questions about how to get organizations to be more design-centric and what better way to learn than from someone who has done it. Marc Rettig has been helping organizations make the transition for 30 years. In this podcast, Karen McGrane shares why he was chosen as one of the keynote speakers for UX Advantage.
Join us in Baltimore August 18-19 for UX Advantage. For more information, visit uxadvantage.com.
Recorded: July, 2015
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]
Sean Quinn: Hey now everybody. I'm Sean Quinn, here with another "UX Advantage" podcast. Today, I'm joined by the co-executive producer of the UX Advantage Conference, Karen McGrane, who along with Jared Spool, have been working really hard on putting together a unique conference that focuses on the UX strategy issues no one else is talking about.
How are you doing today, Karen?
Karen McGrane: I am doing fantastic. I hope you're doing well too.
Sean: I'm doing exceptionally well. That's my default setting. I think it's why people like to be around me.
Will you take a few minutes and share with our listeners how Marc Rettig was chosen to give one of the UX Advantage keynotes, and what makes him uniquely qualified to do so?
Karen: I am so excited that Marc Rettig is going to be joining us. I personally find him to be genuinely inspirational.
Marc, a while back, wrote a little talk called "Interaction Design History in a Teeny Little Nutshell" that was so interesting, and exciting to me, that it genuinely sparked years of research. I wound up teaching a course at the MFA in Interaction Design program at SVA, a short course on the history of interaction design, basically as a result of seeing Marc's research.
I think that if I was that inspired just by one little talk that Marc put together, think how inspiring it will be to have him share what is literally his 30 years of insight, research, and case studies on how you move organizations to be more design-centered.
I just don't think there's anybody better out there to speak to a range of different companies, a range of different types of problems, and what he has learned in working with all of these companies over the years to make this sort of change happen.
Sean: Then what do you think would be the most valuable things people will take away from Marc's UX Advantage keynote?
Karen: He's going to speak to what it actually takes for organizations to become more design-centered. I would imagine that pretty much everybody who's going to be in the audience is attending UX Advantage because that's one of their primary goals or concerns.
To hear Marc talk, not just about some of the case studies and examples in his past work, but he'll also present a framework for what organizations do, or what kind of transitions that they need to go through.
I would imagine that Marc's talk will be both inspirational and practical, that it will give people in the audience a sense that there's some genuine hope, that there's something that they're moving toward, and that there's some things that they can start doing in their organizations today to make that happen.
Sean: Do you think that this talk, this addition of Marc to the line-up was a key to making this a more valuable experience for attendees?
Karen: When Jared and I were thinking about who would be the right keynotes for this talk, Marc was one of the very first names that came to mind. There are so few people in this industry that have 30 years of experience with guiding organizations on how to be more design and user-centered.
Marc is, I think, one of the people who has the most solid understanding and experience in this space. I'm really excited he's going to join us.
Sean: In listening to you talk about this, having never heard or seen Marc speak, I know I'm looking forward to it. [laughs] I'm counting down the days to UX Advantage in Baltimore on August 18th and 19th.
It was short, but informative, and I thank you for your time.
Karen: Thank you again.
Sean: Be sure to check out the conference speakers and all of the topics at uxadvantage.com. You don't want to miss this event. We hope to see you in Baltimore August 18th and 19th. Check it out and register at uxadvantage.com. Bye for now.
Here's an excerpt from the article:
As we learn more about the current cohort of design leaders—the ones who are making their organizations more competitive through design—we find they are nothing like this mythical ideal super-designer. Their superpowers aren't turning everything they touch into beautiful works to be idolized.
Instead, they focus more on leadership than on design. That isn't to say they ignore design, rather that great design is the touchstone by which they bring everyone together.
Read the article: The New Design Leader Emphasizes Leadership.
How do you define a successful design leader? Share your thoughts with us below.]]>
The belief of public failure or marketplace irrelevance can drive an organization to change. How does a UX leader exploit this corporate fear? What transforms the momentum from fear into positive change within the organization?
Those are just some of the questions being addressed at the UX Advantage conference. Karen McGrane and Jared Spool will be your hosts as they have meaningful conversations on a series of topics with top design executives.
In this podcast, Karen tackles the UX Advantage topic, Taking Advantage of Fear.
Join us in Baltimore August 18-19 for UX Advantage. For more information, visit uxadvantage.com.
Recorded: July, 2015
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]
Sean Quinn: Hey now, I'm Sean Quinn. Today is a pretty special UXA podcast. Why? That's a great question. For the past several UX Advantage Podcasts, I'd been joined by Jared Spool, which was great.
But today I'm super lucky to be joined by the co-executive producer of the UX Advantage Conference, Karen McGrane, who along with Jared has been working really hard on putting together a different type of conference focusing on UX strategy issues no one else is talking about. How are you today, Karen?
Karen McGrane: I'm doing great, very happy to be here.
Sean: In this podcast, we'll dive into the UX advantage topic of taking advantage of fear. Public failure can put the fear in you. The healthcare.gov disaster is a good example of a public failure. My first question for you, Karen, is how can you use this fear and turn it into positive change within an organization?
Karen: I think the healthcare.gov example is instructive, that up until they had a huge, spectacular public failure, the US government was able to treat web services technology, services, digital services, what this hands-off business is usual approach. "This is the way we've always done it. It must always work."
It wasn't until they had the media and the public attention pointing a finger at the problems with that website and those processes that they were really inspired to change.
I think in our conversations that Jared and I have had with some of the guests who will be at UX Advantage, fear is something that's come up. I think it's one of the hardest things for people to talk about.
There's the sense that people want to say, "Oh, no. We really are inspired and we're excited, and we're not motivated by fear at all," but I think honestly, most organizations really are motivated by fear to some extent.
The fear of a big, spectacular public failure, or perhaps having a big, spectacular public failure is what drives companies to day, "Hey, we got to work differently." I think companies that can recognize that and take advantage of it can harness that for good.
Sean: This seems to parallel, then, with the idea of getting the executive buy-in from the top down and not just paying lip service to that, because I imagine this fear transcends the organizational chart.
Karen: I think that many organizations probably find that it's difficult to get genuine C-suite attention for some of the digital initiatives that a lot of times the web and other mobile and other initiatives like that are treated as if they're more of a tactical implementation detail.
That they're something that once executives have said, "We need to have that," it's expected to just run and be managed and not actually influence or drive other aspects of the business.
I think what we've heard from so many of the guests who will be with us at UX Advantage is that that mindset, that approach just really doesn't work, that you need the genuine involvement and support of C-level executives to ensure that digital initiatives which touch a variety of different groups across the organization, so marketing and IT and customer service and sales, all over those groups have to work together.
You might need something that shines a big, bright light on the fact that those groups don't have a really effective way of working together and that that is painfully obvious when you look at the website. That might be what sparks someone's attention to say, "Hey, we got to fix this."
Sean: I've been thinking a lot about this particular topic. It's one that I think a lot of people can get something from. Do you think that the different industries have to deal with different types of fear?
What I mean by that is, do you think, say, Fidelity, because of the scope of their business and what they're actually providing their customers, they're dealing with a different sort of fear than, say, Marriott?
Not that they're not in a very competitive space but there is something, it seems a little safer about the fear they might be experiencing than the fear of the transactional relationship that Fidelity seems to have with folks.
Karen: As you're talking, I found myself thinking that we're going to have a range of guests that cover the needs of private companies, privately-held companies, public companies, publicly-traded companies, and then civic or government organizations.
While I think that the challenges that many of those organizations face are, in many ways, quite similar, I agree. I think that there probably is some different motivation, some different fears that come to play.
Whether you are a government institution and beholden to your citizens or whether you're a public company and beholden to your shareholders or whether you're a private company and, to some extent, you maybe have the luxury of dealing with some of these things behind closed doors.
I think that the types of problems organizations are solving also probably, can cause some different motivations or different fears. I know that Stephen Turbek from Fidelity will probably mention some of the concerns that they have around changing their transactional experience.
I've had some great conversations with him about the work that they've done to build a beta version of their account servicing so that they can go responsive but have the ability to test and learn and not be making changes on the core transactional experience because that would be really risky.
I'm sure that we'll get some great stories from organizations like Marriott about how they've managed risk as they move into global markets. Yeah, I agree. I think that there's just all kinds of interesting stories here about how organizations recognize their fear and then deal with it.
Sean: It sounds like beta mitigates fear. That's potential bumper sticker slogan, I guess.
Karen: I definitely think that organizations that have moved toward a more data-driven and perhaps even continuous deployment model, which is another thing that we're going to be talking about at UX Advantage.
How do you get around the fear of the one Big Bang release? Maybe you're doing more frequent testing. Maybe you're supplementing what should be a really rigorous approach to in person user research sessions with also some ongoing AB testing or split testing that you're running on the live site.
You're continuously deploying a variety of different objects into the live site so that rather than waiting for the one big reveal, you're constantly evolving the site.
If I was thinking about ways that I might mitigate my fear, making lots of small incremental changes rather than one big bang might be a really good way to do it.
Sean: Listening carefully to you talk, it's clear that what's going to be really exceptional about the UX Advantage Conference is that all of these topics were obviously very well thought out, because they're seemingly interwoven together.
I guess you'd be lucky in an organization if you only had to deal with one or two of them. It sounds like they come part in parcel with another.
Karen: As Jared and I were planning the topics for this event, we realized that most of the leaders that we were going to speak to would be able to cover probably the majority of the subjects.
While we have some guests that are going to come in and give us a really focused look at topics like globalization or how you get your lawyer on your side, I think most of the interviews will be able to cover a range of different topics.
Everything really is an interwoven look at all of the different steps and all the different processes that organizations take as they become a more design-centric, more user-centric organization.
Sean: Taking this full circle, this idea of fear and how can leverage that to make better decisions and release better products, what are some valuable lessons that you think every organization can learn from the challenges that healthcare.gov launch uncovered in spectacular fashion?
Karen: I think first and foremost that fear and even the risk of failure can be a good thing. I don't know that we would have the US digital service or 18 F right now if we didn't have healthcare.gov. I think organizations being able to look at a failure and say, this is an opportunity to change is probably one of the most powerful things they can take away.
I think I'd also like to say, you don't have to wait for a healthcare.gov fiasco in order to make these changes. One of the benefits that I think organizations will get from coming to UX Advantage is a chance to hear from organizations that have already been through this transition and hopefully walk out with some tools that they can use in their own companies to make this change happen.
Sean: That's great. I think this is going to be an excellent event that people will be well-served attending. I just want to thank you for your time today, Karen.
Karen: I think it's going to be a fantastic event too, and I hope to see everybody there.
Sean: Watch for other podcasts that will be covering more of the conference topics. Be sure to chack out the conference speakers and all of the topics at uxadvantage.com. We hope to see you in Baltimore, August 18th and 19th. I'll be there. I'm excited for the event. We hope you'll be there, too. Bye for now.
You'll hear how:
Usability in products and websites is what most organizations strive for. The more usable the product, the more likely that people will use it. Through research and testing, you can root out many issues with clunky interactions that hinder the experience. What isn't as immediately clear is if some perceived usability issues are actually understandability problems. Your content could be the culprit.
Steph Hay is the Director of Content Strategy at Capital One. She's an advocate of using a Content-First method. At the base level, if your content works, it goes a long way toward improving your entire experience. Rather than letting the design dictate what the content can be, starting with a focus on what the content is can influence the design in positive ways.
Even testing the content in a Google Doc with users can uncover some serious hurdles very early in the process. This allows you to objectively evaluate the usefulness of the content without what could be the distraction of a beautiful design or layout. After determining the appropriate words, you can then plug them into your design instead of using placeholder text that could be creating inappropriate line lengths. A beautiful design can be really nice to look at, but a beautiful design with the right content will be far more usable.
Steph will be presenting one of eight daylong workshops at the UI20 conference November 2–4 in Boston. For more information, visit uiconf.com.
Recorded: July, 2015
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]
Jared Spool: Hello, everyone. Welcome to another episode of the Spool Cast. I am Jared Spool, your cruise director for the next few minutes. We are honored today to have with us the amazing Stephanie Hay.
She is joining us to talk about designing content first, the subject of her wonderful workshop. Hey, Stephanie, how are you?
Stephanie Hay: I am great, Jared. Listen. Do you know that the conference is following right after daylight savings time?
Jared: That happens frequently that we end up having it right that weekend. It has worked out that time.
Stephanie: How many people are going to show up super early to their first day of workshops on Monday, the 2nd?
Jared: I think everyone will be there, partially because we serve a lot of coffee for the breakfast. Second because they'll be excited about the amazing workshops, that the odds of them sleeping the night before are just slim.
Stephanie: [laughs] It's like Christmas, in other words.
Jared: Yes. That's right.
Stephanie: Good to know. Plus you have pancakes.
Jared: South By always has their conference, over the other. This one is the one where you get an extra hour of sleep, but the South By one is where you get one less hour of sleep, which means you get one less hour of party the night before. They have Sunday sessions which means, whoever has that first session on Sunday morning, has it an hour earlier than everyone's expecting it to be.
Stephanie: This has bit me twice, when I was an undergrad at Ohio University, and the bar was closing an hour early. We all stood in the street, and partied. It was fun. [laughs]
Jared: I had a designer that worked for me once, who loved to pull all-nighters that weekend, so that he could say he worked 25 hours in a day just to get the job done.
Stephanie: Wow. That's commitment.
Jared: Yes.
Stephanie: That's real commitment.
Jared: Yeah. Then we threw out the work, and started over.
Stephanie: [laughs] Yeah, of course. I once overslept. I overslept for a choir concert too.
I walk in, and everybody's up on stage. I stood in the wings until the conductor got done with the song, and helped me come on, which was important because I had a solo.
Jared: [laughs] Yes, there you go.
Stephanie: That was a panic moment.
Jared: Yes. I bet it was. I bet it was. After you've woken up, from having the extra hour of sleep that weekend, you're going to do a full day workshop again.
Stephanie: That's right.
Jared: Now last year when you did it, it was the first time for doing it at the UI Conference. You had also only been giving this workshop for a few months at that point, if I remember correctly.
Stephanie: That's right.
Jared: Now it's a year later. Have you learned new things about Content first, in that year? Are there things that the year has revealed that will make people love your session even more, because you have that much more experience?
Stephanie: Of course. Of course it's true that over the last year, I can't even tell you how much Content first has been put to the test as a practice. I joined Capital One last September, to build a content strategy practice on the design team. Not on brand, or marketing, or communications, where you might normally find content strategy, but very squarely in the product design team.
When I gave the workshop last November, I was maybe I think five or six weeks to that gig. I hadn't hired a team yet. I was really trying to understand the landscape, in order to figure out whether or not Content first could apply, and if so, where? So many projects are happening, at any one time.
My experience prior to that had been…I was been part of a project, from inception through launch. I was really able to start with the content, with relative ease. Now I'm in an organization, where there are more than a 100 initiatives happening. They're all already started.
Where does Content First fit? Since last September, I hired 10 folks on the team. That's all from demand for this practice, because of the number of ways that it scales within the organization, which I can get into more detail if that's not going to bore you to tears Jared. [laughs]
Jared: No. It probably won't.
Stephanie: It's just the nerdy stuff I love.
Jared: This idea of coming into projects in the middle, and trying to do Content first. You're right. It's actually a unique rear opportunity, to be at that inception moment, where nothing's been done. You have a green field, a blue sky, a blue ocean, an open canvas, a blank metaphor.
Stephanie: More metaphors, more metaphors.
Jared: I think I've run through all the metaphors, for the rest of the month. Fortunately I was working off role over metaphors, from the previous month.
Stephanie: Why is that I work like that?
Jared: Yeah. I think most people are more commonly, in the middle of stuff. What did you learn about doing stuff in the middle, and what was that adventure like?
Stephanie: A big moment of clarity came to me when I realized, how often we conflate understandability with usability.
Jared: That's interesting. Say more about that.
Stephanie: I would run into a situation where I would say, "Did we try seeing this instead, or did we test this sort of language?" I would often hear…we're a very test driven company at Capital One and I would often hear, "Yeah. We tested it." I was like, "With whom did you test it?
Did you give them different options and listen to the language and really hone in on the words that they were using to understand which ones were the triggers?" Of course, they hadn't, because they didn't have that content focus yet.
What I actually learned is that they were testing usability and they were adding language where things were breaking down from a usability standpoint to try and help clarify the process, when really adding to it wasn't necessarily making it more understandable. It wasn't even necessarily making it more usable.
There were a couple really incredible projects that had been in usability testing and the teams were saying "There's something here. I know that there's something here and we just can't get at it." What we ended up doing, taking a content first mindset, is actually extracting the content from the interface, from the prototype that we were testing, and putting it in a Google Doc or in a Word doc and then going in and testing the language agnostic of the interface.
We wouldn't show the person we were talking to in the customer interview…we wouldn't show them anything, but we would talk to them as if they were interacting with us, as if they were interacting with an interface.
We would figure out where the ah-ha moments were and we would pay attention to the language that they were using, so that we could really understand what specifically were the compelling words that would make somebody want to move forward when we were otherwise just using what you I think would expect as marketing language, something like "safer" or "faster" or "easier" — the kind of words that you would expect to see from anyone, really, these days.
But what does that actually mean? We really focused by removing all the content from the prototype, removing the content from the design. Spending an hour copying and pasting language into a completely blank text file is a much faster, lower-risk way to isolate the content and test it with people than it is to just continually iterate on the design when you're not really sure what the problem is. Is it a usability problem or is it an understandability problem?
Once we knew that we had it understandable — we were using the right language, we were able to iterate within this text file — then we would go back in and make the changes we were required at that point. There were some slow changes. We might have to move some things around or move some screens. Then bingo Bango, we were back in business moving forward.
Jared: Bingo Bango…is that official content first?
Stephanie: No, absolutely not.
Absolutely not. I would not recommend anybody use it, because typically the reactions are exactly what you just [laughs] did, which is "Did you really just say that?"
Jared: This idea, though, of having this discussion back and forth…did that feel awkward to folks when you first started doing it? Did you have to push them to not just put screens with text in front of people?
Stephanie: Oh, yeah. I think the biggest shift that the design team goes through, or product partners we work with, and this was actually true before I started at Capital One too, the project managers, was that we wouldn't start with the design.
The biggest shift was to be OK with starting with the content, to embrace that, to see that by using a tool we all know how to create — words on a page — we actually could start the important design work of making sure that we were nailing our story.
The shift from the traditional mindset of "I've got this idea," let's make something. That "make" doesn't necessarily have to be lines on a page. That "make" doesn't have to be an interactive prototype. That "make" could be words in a document, could be a conversation that we design and test.
That shift has been the hardest shift to make, but the reality is, most of the time we as the content strategist are not the subject matter expert. If we do a great job of coaching, really, of showing people how this is such a powerful design tool, the writing is such a powerful communication and design tool, they will run with it. We have to help them get there and I think a couple of the conversations I've had…like, I'll give a content first design talk.
Someone came up to me after a presentation in April and said, "I had heard your stuff before and tried to do content first design and created a content workbook," which is tactically, it's usually a Google Doc or a Word doc, and it's where we put all of the content and invite stakeholders to participate in crafting the language so that we can test it or so that we can use that to design something from.
He said, "I tried to do it but they just never wanted to use the Google Doc." I said, "OK, so what did you do?" He said, "We just went back to using the prototype." They never wanted to the Google Doc.
Back to your original question, the real challenge is always to be willing as the person who is trying to shift the entire team towards designing together early on using tool like word. Like the written word is to be OK with the fact that people are not going to immediately get it and jump on board and start using it the way you're using it or the way you see it.
That's your job. That's your challenge. Your responsibility to help them see why it's so valuable for them, that they don't have to rely on strategy or vision briefs or requirements documentations. We could actually just start doing the design work now together in the written word.
The only way to really convey that appropriately is to do it together. There's got to be some degree of rigor as part of that. Like we, on my team now, Capital One will plug in for an hour or two a week with a particular team and say, "OK, show us wherever you are and make some recommendations that we capture in that workbook and then unplug and walk away."
Over time, they started to understand what this really means by practicing it with us. Only through that practice and that regularity do we actually start making change happen and getting the person who the idea starts creating the conversation. Creating the interaction without having to worry about whether or not he or she knows how to create wireframe or whether or not the APIs will be available to make the impossible.
Let's just design what is the ideal end state. We can test that. Get it right. Then go off and build it.
Jared: What else did you see over the last year that has either sort of reinforced your understanding of content first or sort of surprised you a bit?
Stephanie: One of the most professionally fulfilling moments of my career was about, I would say, three months ago now, the head of our user labs, a wonderful woman by the name of Mave. Mave came over to me and she said, "I've been listening to all the content first." We had been doing some internal trainings and workshops that she had been part of.
She set up user testing labs in I think eight different locations now. There are daily interviews that we run, empathy sessions, and that sort of thing. She has 15, 20 years of experience having created research methodologies and user testing sessions and that sort of thing, executing those.
She came over and said, "One of the things I took away from the content first approach was that it doesn't even necessarily need to be a content strategist creating the content. It could be a designer. It could be a product manager. It could be a brand strategist. It could be a senior level stakeholder. Somebody who knows how to write what they're imagining would be the conversation that they're trying to design for."
She says, "I also thought maybe the researchers could do this." She created a template that they could use in testing sessions. It's talk bubbles. On one side of the page is an avatar with a talk bubble coming out of it. The other side of the page is like a computer with a talk bubble coming out of it. It's just page after page of this over and over again.
She says, "Give this to people and ask them, 'Hey, if you had to design a kind of conversation you'd want to have with your bank about X problem that you're having, how would you want that conversation to go?'"
When she came over to tell me about this, she was holding the template. Then underneath the template were 30, 40 pieces of paper that were just scrolled on in the backs of them. People had written on the backs of them too because the customers that she had put this in front of knew how to do that work.
When she asked them that the question, they started writing the conversation they wanted to have with us. They were designing what they wanted us to make. That only came out of the content first approach that she could then adopt for what she knew from a research perspective.
What she said is, "I have never somebody be able to complete these exercise that we've given people." I think it goes back to what I said at the beginning. I think the main difference is we're oftentimes sitting in front of people asking them to test usability and asking them if they understand.
What we're really doing in the conversation first approach, talk bubble approach, is asking them to tell us their mental model. To tell us how they understand a particular problem and how they would love to interact with their bank in order to help them solve that problem as a starting point.
Ideally, then we could, from a usability perspective, design something that's automatically usable and it's already understandable because it came from the customer.
Jared: This is intriguing because you're sitting with one of your customers or potential customer or a competitor's customer, I guess.
Stephanie: Maybe.
Jared: Not that you guys would ever do that.
Stephanie: Of course not.
Jared: Are you asking, "How does this conversation go today?" or, "How would you like to see this conversation go?" or a little bit of both.
Stephanie: We've mostly been focusing on the latter. Often, we know how the conversation is going today which is probably why we're trying to do something better.
Jared: That's true.
Stephanie: That said, asking them questions along the way, like what do you love about this problem before we get to the actual conversation design exercise. Like what do you hate about this problem? Like what is it in the interaction with us or the interaction with your bank that really just like gets under your skin?
Often, the language that they'll use when you ask them questions like what do love about something or what do you hate about something is so emotional by giving them those two choices. What do you love and what do you hate? So emotional, you can learn a lot about somebody's real reaction to that situation.
If they're mediocre like, "Well, something I don't really like about it," it's almost an indicator immediately that this person doesn't really feel that particular pain point. Maybe that particular interview is not going to be as powerful as the person who goes, "This ruined my life."
Then you want to pay attention to that person because that's actually not an outlier. That's the real opportunity there.
Jared: You guys screwed up and it took me years to fix the problem. That seems really powerful.
Stephanie: To your question about what I've learned, where to plug in in the middle of a project and extracting language from an interface that already exists and isolating it. Also, using words in the customer interviews and asking them to design a conversation they want to have with us.
It seems like common sense. We as designers, especially customer development in lean startup methodology or design thinking is all around empathy interviews to say, "What is the customer problem here? What is the real need of the person I'm talking to?"
Only until I understand who this person is and where they're really coming from can I design a great solution. We designers feel like it's our responsibility to create that solution of that conversation. Where the content strategy piece comes into play and [inaudible 18:48] content strategy is to say, "We're going to pay attention to the language that you use to talk about your problem, to talk about your needs."
Then if we as a company are brave enough to use that same language, if we as a company are brave enough to let you design a conversation with us, to not over brand something, to not dilute it with marketing language, then we'll actually do a better job of speaking to you in the most like plain text human way that's going to make us better as a company that's going to make you feel better.
There's just going to be natural trust there because we're going to all do a better job communicating with each other.
Jared: Since you did this year, you've spent an entire year at Capital One. Capital One is not a small company. It's a huge company.
Basically, the problems that you'd run into at Capital One are different problems. You probably run into on the projects that you brought content first to before that. What are some of the things that happen at scale that you don't see on smaller projects where you can get all the stakeholders in a room at one time?
You've got huge amounts of content. You've got a huge amount of stakeholders. You've got endless numbers of diversity in terms of the project's portfolios that you're working on. How does that change this or does it?
Stephanie: That's a great question.
Jared: That's what I get paid to do.
Stephanie: Fundamentally, it doesn't change the practice of our work. The scale at Capital One, what it does do is introduce new levels of content first that are in arenas that I've never participated in. Like legal and compliance regulations in Capital One.
Terms and conditions, I can't go off and rewrite terms and conditions to be plain text language without putting the company at risk. [laughs] There are so many levers in place that would keep that sort of thing from getting to market and rightfully so.
However, we are doing and I think really speaks to the evolution of the industry as a whole frankly is pushing the envelope where humanly possible. Before I started working at Capital One I was working with companies like Ben and Jerry's, with you, with Annie E. Casey Foundation.
I haven't run into anyone yet who says we absolutely cannot speak in human terms, in customer terms. We absolutely cannot use the data that we could pull from site search terms or Google Keyword Planner or call center data and use that as a jumping off point to create something better.
I think what ultimately has happened is when design and particular visual design became a thing. People wanted design and content was sort of put in the backseat as an asset to be addressed later after the design was figured out.
What's happening is the Ubers of the world, the Airbees of the world, have said design plus understanding how to communicate with people, understanding their experience, is actually greater. It's all of the experience. An experience is the product. The only way you can really rise above just this website redesign and actually create something more meaningful and sustainable is to connect all of the parts together.
What that means is at a company at the scale of Capital One, legal is no longer the part of the production timeline that we get to later in the process. Copyrighter is not the person that we get to after we get that redesign.
Instead, we're morphing the processes to enable those people to be part of the design process itself. We're bringing together the desperate projects that are overlapping and saying, "Hey teams, you should be figuring out what the commonalities are so that we can create experiences so we can map all these things together."
As you know in particular with Capital One, I think when Adaptive Path joined our team, that wasn't an accident. [laughs]
Jared: They didn't like back in. It was like, "Go."
Stephanie: That's right.
Jared: They got themselves locked in the wrong room.
Stephanie: [laughs] That's right. What are we doing here?
Jared: It's like, "How do we get out?"
Stephanie: This isn't unique to Capital One, of course. This is my experience that I can only speak to. The important takeaway here is that I think there are new standards being set for what experience feels like. Pioneers who came way before us in different aspects like Disney. That's a perfect one.
Didn't you go to Disney in Paris just now or something?
Jared: We did.
Stephanie: The example of the towels, the towels that are folded on the hotel beds.
Jared: The origami animal towels.
Stephanie: You got it. This is experience design. The only way to achieve experience design is to have cohesive design processes that involve all the elements that are part of that experience. Not to treat it like a production cycle.
That's a really long way of saying I actually don't think that my previous experiences as a consultant and before that at an agency are even comparable in a way to what's happening inside Capital One. It's like apples and oranges.
Because we're designing experiences here and it's not a project in a way that like we're re-launching a website and we hope that it works. In a couple years, we'll redesign it. It's like this is part of a history that we're designing right now.
Jared: A lot of what you guys do and I assume you work on is transactional. You're working on the transactional side. Some of those transactions are things people do multiple times a week. Some of those transactions, they might do once a year. Like if they're tax return data and that sort of intermittent frequency. That plays a role in the type of content you create too, I assume.
Stephanie: Absolutely. It's our responsibility to understand exactly what you just said. The three pillars that we follow…
Jared: I don't even understand what I just said.
Stephanie: [laughs] That's it different for everyone. That it's dependent upon behavior. The three pillars we follow of content strategy at Capital One, one is natural language which we use data to determine and also A/B tests. We really need to speak the exact same language to our customers. We need to be brave enough to do that. That's what natural language is.
The second thing is use case specific. This gets to what you're talking about. Like there has to be a reason for this content to be there in the first place. It has to serve some purpose. In isolation, it's an asset. You can't look at it in isolation. You have to look at it in the context of the greater conversation that we designed for it.
If you're trying to make a payment, the only way to really analyze whether or not this is the right language here is to understand what the use case is and go from end to end. Then do that over and over again with the additional use cases.
It was natural language, use case specific. Then the third part is contextually relevant. Is this the right place for this language?
If the use case is if this person is probably going to be looking at this on his or her mobile phone and it's the fifth time today, that changes when and where you would serve particular pieces of content versus somebody who's coming for the first time on their desktop to do something that they've never done before or that they only do once a year.
Without those three pillars, we just look at content like a piece of this screen. That's not experience design. That's asset management. We're beyond that now.
Jared: It seems to me that what you've sort of gleamed from this helped to sort of round out this content first approach in a way that is going to make it more robust going forward and more flexible for folks who are finding themselves in an enterprise situation.
Are there specific things that you haven't talked about yet that people who work in smaller organizations that are not these large behemoth banks like Capital One that are still useful? It's like, "Oh, OK." I guess one is that if Capital One can do it, you have no excuse.
Stephanie: [laughs] That's right.
Jared: To some extent, people might turn around and say the opposite, "Well only an organization the size of Capital One would have the resources to pull this off. We don't even do usability testing or we don't even do A/B tests."
Stephanie: The reason why content first became a thing in my life is because I had been working on my own as an independent content strategist for a few years. Along the way, I had been part of a couple of startups. One of them, in particular, a mobile app called the Fast Customer Rep, where you don't hold for customer service.
It was a small team where we had to wear too many hats. I wasn't fast in designing layout. I was fast in designing the conversation that I wanted to have with the person when I was creating the on-boarding experience. For example, when you launch the MVP, you basically showed up and you had to know what to do. There was some marketing language on this site.
As we rose, we followed the sort of traditional Silicon Valley approach to starting to grow our team and build an infrastructure for scale. We realized we need an on-boarding experience that would help us learn who was actually using the app.
I was, at the time, trying to find a faster way to get the guts of what I was trying to say and the interaction I was trying to capture on paper. When our designer who only worked part-time with us was online, he could see the vision I had and not have to worry about the language. He could bring that to life.
It started with almost just like, "This is all I can do because I'm not really that good at design and I don't really want it to be a design because there are people who really love it and they should do it and I really love the words, so I should do that."
From there, I started practicing that content first approach in bigger and bigger ways. It went from an on-boarding process for a mobile app to the other startup. I was a co-founding editor of Work Design Magazine which now has a few thousand subscribers and a team of people supporting it.
That was a WordPress site with content. It was a content marketing play. If we could get people to come to this site to learn about the changing nature of work, then we would've validated the business idea which we did. From there, it just kept growing and growing. There are so much we could do with content if we just put it at the front of the process.
I remember when I gave the talk on content first design which is also largely influenced my experience on video game design of crafting the interactions and nailing the story and having the characters develop to almost like Hollywood style script writing before there was ever a character look, before there was ever a game design. The story is there.
Drawing on those sorts of things, I had put together this talk. I was talking about it on a stage in Nashville when some folks from the Capital One design team were in the audience and said, "Geez, we should work that way. Why don't we bring in Steph to do a talk?"
I had only been doing it at such a small scale and increasingly involving more and more people. Like Ben and Jerry's and Annie E. Casey Foundation, were the first projects where I tested whether or not a content first approach would work with the director of PR and the marketing person and the IT person. They did.
When I gave the talk at Capital One, they started saying, "Maybe you should come here and build a practice here." My first response was no way. [laughs] This will never scale because I've come to know that this is design. Content is design here. It's not audit. It's not the way that I think governance plans and editorial processes that had been part of I think content strategy's foundation.
I wasn't doing information architecture. I was designing all the content then figuring out what the architecture was once it was designed. I just couldn't believe that scale and I was totally wrong.
Ten folks on the team, looking like we'll probably double over the next year. It's because the demand for a design-focused content as design is real. It's not just a tool for me as the independent content strategist or team of one for any content strategist who's listening right now, or writer who's listening right now. It's anybody. That's how it scales. Is it anybody around you is capable of doing this?
They may have some chip on their shoulder, concern that they're not a copywriter. We hear that all the time. "I'm not a copywriter. Can you help us out with this?" It's like, it's not even about being a copywriter. It's just being comfortable being willing to put something out there that speaks very plainly to someone, and knowing that that's actually better than making it sound flashy.
Sounding flashing doesn't make an experience. In fact, it probably works against the credibility, because it sounds like you're trying to sell me something.
Jared: Right. I was just thinking that to some extent, if you have copywriters involved, you probably have to break them of the bad habits they have being copywriters.
Stephanie: That's right. Exactly! Well said. [laughs] To scale it up, it's just involving people and coaching them to feel comfortable that they can write customer-facing language, and that as long as it speaks very plainly to solving real problems, it's great!
Jared: How important is it that this be done in the product organization, versus in the marketing communications, or customer service, or wherever? Is that an essential element to this, or does it not matter? If I'm a content person that's not in product development somewhere in the organization, do I have to go sell this to the product people, or is this something I can make happen from where I'm standing?
Stephanie: It matters, and you can make it happen from where you're standing. What I've found always works, and this is true as well at Capital One. That there are copywriters, brand strategists, and legal folks who understand, get it, want to be part of the design process, are willing to come sit in on usability testing. And want to create content with us earlier in the process, versus waiting until everything else is figured out. And then, "show me what you got, and then I'll come in with my red pen," sort of thing.
Those are the people who are sitting in other places within the organizational silos who are participating in the new way of working, the new way of creating, designing experiences together, and they absolutely need to be there because we're better for it.
If people are waiting for permission, or trying to sell it, versus just saying, "Hey, could I come be part of that meeting, because I'd love to do this?" Putting themselves out there and saying, "Why don't I take a stab at writing the introductory email, and you can tell me what you think?"
People who do that, who take that initiative, who are willing to go outside of the bounds of their, I would say, organizational responsibilities, or silos, are the people who are making change happen. If you're waiting for permission, it's not going to happen, but you're going to be bored anyway, so why not just do the thing?
The worst thing that's going to happen is you'll create a Word document with some language in it that no one pays attention to! What's the real risk here? I think that's why content is such a leveling agent, because if you can write an email, and chances are if you've got a job it's because you put in a resume, because you were able to articulate who you are, and the value you bring to the table, jump in.
Be part of the creative process. Make things together. That's how experience happens.
Jared: Steph, this has been awesome. I'm excited about your workshop because it sounds like that even though it was one of the highest rated from last year, you're going to make it even better!
Stephanie: [laughs] I hope so! I aim to please.
Jared: This has been fantastic. For those of you who are listening who want to get more Steph, and why wouldn't you want to get more Steph? You will be able to spend an entire day with her talking about content first, where you'll actually get a chance to go through the process and create a design based on content at the UI Conference, November 2nd-4th.
She'll be doing a full-day workshop there. It's going to be absolutely fantastic. You're going to love it. You'll be able to go back immediately and do awesome stuff the day you get back to the office.
Stephanie: True.
Jared: You need to check her out. You can find out more information at UICONF.com. That's where you'll find out about the entire conference, but in particular about her Content First Design Workshop. Steph, thank you so much for spending the time talking to us today.
Stephanie: It was my pleasure. Thanks, Jared.
Jared: I want to thank our audience for spending the time listening to us today. You're always awesome. If you have a chance, and you haven't done so, if you can go to iTunes, and leave what you felt about the podcast, and other podcasts there, we appreciate it.
We read all the reviews. It's fantastic. Thank you for listening. As always, thank you very much for encouraging our behavior. We'll talk to you soon…
Kim Goodwin tells us that scenarios put the design into the context of how and why the user will interact with it. In 2011 Kim presented a UIE Virtual Seminar, Designing with Scenarios: Putting Your Personas to Work.
Today's UIEtips article is based on a discussion UIE's Adam Churchill had with Kim. It's based on two questions from the seminar: Do you need data to effectively do scenarios, and what's the difference between scenarios and storyboarding?
Read the article: Designing with Scenarios: Putting Personas to Work.
What's your experience with scenarios? Are you using data when developing them? Share your thoughts with us below.]]>
Attend this seminar if you want to:
Save your spot in this August 6 virtual seminar, or make it part of your 6-month program of virtual seminars.
When some people hear the term Lean UX, they dismiss it as simply a nouveau buzzword. There can be some confusion as to its relationship to Agile, both the methodology and the adjective. Some of the biggest resistance came from the idea that Lean UX was shortcutting and lazily undoing much of the groundwork to get organizations to buy into the value of UX. But as waterfall development increasingly becomes "the old way" of doing things, teams are operating in more agile, or Lean, ways.
Jeff Gothelf co-wrote the Lean UX book with Josh Seiden. Over the years since the book was released, he has seen the initial resistance to the idea die down. The conversation has shifted to domain-specific challenges and how Lean UX can address those.
It all comes back to research and the idea of the Minimum Viable Product. This isn't to confuse an MVP for the "first conceivable thing we can ship." Getting your product in front of customers early in the process lets you test any hypotheses you have about both the product and your customer base. Uncovering misconceptions up front allows you to iterate and pivot to arrive not just at the best design, but the right one.
Jeff will be presenting one of 8 daylong workshops at the UI20 conference. For more information, visit uiconf.com.
Recorded: July, 2015
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]
Jared Spool: Hello, everyone. Welcome to another episode of The SpoolCast. I have returning star, and author, Jeff Gothelf, who is going to be speaking at UI20 this November 2nd through 4th in Boston, Massachusetts. He's doing a full day workshop on bringing "Lean UX" to your organization, and using it as a tool to collaborate, and get everybody on the same page. It's really going to be awesome.
We were talking about it the other day, about the content of the workshop. It's just going to be a fantastic workshop. A necessity for any team that really needs to push the boundaries on what they're delivering to their clients and customers. Today we get to talk to Jeff about it.
Jeff, how are you?
Jeff Gothelf: I'm well, Jared. It's great to be back. Thanks so much for having me, both back on The SpoolCast, but as well at the event.
Jared: Yes. Yes, it is something that I've been looking forward to having you back. This is your fourth time, right, third or fourth?
Jeff: Third or fourth, yeah.
Jared: You've been a very popular and very highly rated workshop presenter. I don't know if you know that.
Jeff: I knew some of it. I credit it all to my boyish good looks. That's what it's about.
Jared: Yes.
Jared: That it is. You're the Bieber of the UX world.
Jeff: That's right.
Jared: Speaking of Lean…
Jared: It must have been four or five years ago when you did the first workshop for us. At that point, that was before the book had come out.
Jeff: Yeah.
Jared: That was when Lean UX was one of these new buzzwords, and everybody seemed to have different ideas about as to what this phrase, Lean UX, meant. There were all sorts of common misconceptions. People thought it was UX without any effort, we just cut out all the items, and just claim that we've done user experience. People thought it was just massive shortcutting of good technique and process.
Has that changed? Do you run into less of that? Do people seem to know what it is now? I mean, the book has been out, and you've been talking about it, other people have been talking about it. Has that changed a bit, or do people have new misconceptions as to what it is?
Jeff: Yeah. It's definitely gotten better. It was very, very tough the first couple years out, teaching and talking about this stuff. There seemed to be a genuine desire to figure out how to bring many of the UX and design practices into worlds that were becoming increasingly more agile, both lowercase a as well as the religion, uppercase a version of Agile.
Back then it was, "Hey, this is shortcutting. This is lazy. This is undoing years of training that we have worked so hard to get our organizations to finally buy into UX. "I don't see that as…
Jared: You bastard.
Jeff: Exactly.
Jared: You're ruining it for all of us.
Jeff: There was some of that, for sure. I don't see that as much anymore. I think what's been super helpful is five years of really putting the message out there, and then practicing the work, then case study, after case study, after case study.
Now look, what's working in our favor, in this case, is that…again, speaking from my anecdotal experience, but my anecdotal experience means that I stand in front of hundreds of people, almost on a weekly basis, whether it's a conference, or a workshop, or a keynote, or something along those lines.
When I ask the question, "How many of you work in an Agile environment," 100 percent of the hands go up. There's always a couple of hands in the back that are kind of waving in that [deliberating sound] kind of signal that they're making, but essentially every organization is at least using the language of Agile. They're not necessarily practicing it, or practicing it well, but they're using the language.
There are very few people who will raise their hand, and actually and admit to being a Waterfall organization these days. There is a desire and a drive, both from the folks running these organizations, as well as the teams working in these organizations, to figure out how to do great design in this increasingly Agile world.
The resistance has definitely come down. The conversation has gotten a lot more realistic, which is really what I find to be the fascinating part now.
It's not so much, "I don't believe in this, I don't think we should do it. It's poor design practice," but it's more like, "OK. I buy into this and my org is interested in doing better design. How do I do this in healthcare? How do I do this in medical devices? How do you make this happen in financial services? How do you deal with a 150-year-old brand that's not very comfortable running experiments?"
I'm really happy to say that the conversation has moved from resistance to the idea, to domain specific challenges more than anything else. That's encouraging. That means people are trying it. That means people are interested in trying it. They just need to figure out how to make it work in their specific domain, or corporate context.
Jared: Is the myth that we are reducing things down so light that we're going to miss important stuff? Do you still run into that at all? Do people really understand that this shifts the way the conversation happens?
Jeff: The biggest obstacles right now, when it comes to is this too light, or is this not informative enough, generally comes from the visual design space.
I'll be honest with you. If I had to list one of the biggest challenges in winning teams over, and providing concrete insight about how to make this work with everybody on the team, visual design is, by far, the biggest obstacle at this point because there's a subjectivity there to the level of fidelity that's necessary to learn what you need to learn.
The conversations that we have with teams that ask us those questions, "Where does visual design fit into all of this," really relate back to their brand, and back to the definition of what, ultimately, the conversation ends up around minimally viable products. People try to pigeon hole that conversation as, "An MVP is X and, therefore, it can't be anything else."
I think that that's one of the biggest misconceptions and challenges. For example, take a brand like Warby Parker. Warby Parker is a fashion brand.
They're a startup, and they were running on many highly risky assumptions that they could really bring low-cost, high-end fashion to eyewear, and, somehow, deliver this through technology. Now, when they're going out to test these assumptions, and these hypotheses that they have about their business, they can't go out as a fashion brand with an MVP that looks like Craigslist.
It's not going to work. Their brand, their audience, and their hypotheses rest on some assumptions that they can create a desirable brand for glasses, for eyewear.
The amount of visual design, and brand work that they require to build their MVPs, that they required to build their MVPs, would be significantly higher than if you are running a landing page test for a top-of-the-funnel, B2B sales service. There's an amount of visual design that you don't need in building MVPs for the B2B sales service that you would require for a brand-conscious or fashion-related brand.
I think that that's been where some of the biggest challenges have been, and really comes back, again, to the definition of MVP. Which again, one of my favorite exercises to do in the workshops is to go around the room, and have half a dozen people define "MVP." You'll get half a dozen definitions.
I always come back with, "It's the smallest thing that you need to make or do to learn the next most important thing."
Jared: Right, and that learning part is the thing that I think trip a lot of people up. What I see happens is someone who's higher up the food chain in the organization hears the term "MVP," and thinks that it really does mean "Oh, we're just going to ship something faster."
Jeff: Yeah, phase one.
Jared: Right, exactly. Then, you have this conflict of mindset in the organization where the people who know what MVP means think it means what it really means, this idea of producing something that'll help you find out the next piece of information versus the first product.
To some extent, the acronym gets us into trouble. It sets an expectation that it's a product. "Minimum viable product" actually sounds like something that is got all the attributes of a product that will sell and be profitable.
Jeff: Look, that's why you see blog post, after blog post, after medium article, after minimum lovable product, minimum viable effort, minimum viable experiment, minimum marketable feature, all of these variations on it. It's a confusing term, and you're right.
What it boils down to, I think, is the overwhelming majority of organizations, big or small, value delivery over learning. When they hear, "Minimum viable product," they say, "OK. Product, ship it. I'm on board with that, because what I want to do is ship features, or ship product."
It's extremely difficult, especially in a large company, but also in small companies, as well, to move people, to shift the culture, and the value that the organization places on delivery to one of valuing learning. That's the key.
I think if you can successfully start to shift the organizational mindset to one that values learning first and, then, delivery second. In other words, let's figure what we need to ship, and then ship it, then it doesn't matter how you define "MVP." As an organization, you're focused on learning, first.
I won't lie. It's a rare organization that truly embraces this particular shift in culture and shift in values. When it's done right, the products do better, the teams do better, the risks that the organization takes are significantly smaller. That's really the goal of all of this.
I joke about this all the time. All of these, Lean UX, "Lean Startup," "Lean Enterprise," all of these approaches to working. They're risk mitigation, that's what it is. Ultimately it's just risk mitigation, which perhaps doesn't make a sexy book title, but that's the end of the day. We want to make sure that we're not wasting our time working on things that don't stand a good chance of succeeding.
Jared: This brings me to another thing that I've been having conversations with folks about. I was talking to somebody about something that had happened to one at my clients.
We had a client who was really into Agile, was really thinking they were doing Lean UX. Then they said, "We've got this important project coming up. Before we get the Agile project going, we're gonna spend six weeks gathering requirements so we know what the Agile project's going to be."
I'm like "Wait, wait, wait, wait. What do you mean spending time gathering requirements?"
"Well, you know, we have to hone it down to something that we can do in the Sprints. We have to scope it, so we need to talk to all the stakeholders, we need to find out what they think this needs."
"Of course, none of the stakeholders agree, so we have to negotiate with all the stakeholders to get the requirements down to a set. We're gonna write these documents, and then we're gonna start our Agile process, and our Lean UX process once we know what it is we're trying to build."
Jeff: Right. Again, this is obviously a holdover from the Waterfall world. It provides a false sense of security to the people involved in that project, the people who've been tasked with delivering that thing. First of all let's start with that, right? Those people who have been tasked with delivering something, a set of features. Let's be clear.
Jared: What I'm sensing is there's a little bit of frustration, and fear, outright fear, of just going into a project having no sense of scope.
Jeff: Yeah, and that's perfectly OK. It's perfect you got to have that fear. You should have a sense of the business problem that you're attacking. You should have a sense, at a high level, of the type of solution that you're considering building to solve that problem, and that should give you a sense of scope in the T-shirt sense of scope, small, medium, large, extra-large.
That's the sense of scope. This is potentially a massive effort, because we're thinking about reinventing e-commerce, or it's a relatively minor effort in that we're just changing the way that people authenticate into the product, hypothetically speaking. Again, it's about how the projects are framed.
If I'm a middle manager, and I'm tasked with shipping an iPhone app, that's my task. Then, I'm going to go figure out what needs to…then, understanding the requirements that need to go into the app, feels like the next natural step in the process. "OK. Let's figure out what are the features we want to build in the app, and let's go build the app."
That boils right back up to that discussion that I had a second ago about a culture of delivery. We've given a team a mandate as the iPhone App Team, perhaps they're even known as the iPhone App Team, in which case, they must then deliver an iPhone app.
Seeking the requirements, and then chopping these requirements up into sprints gives the leaders of that project that false sense of control that we know what we're going to build, and we know exactly how long it's going to take, and when it will actually ship. Of course that inevitably breaks down.
Now, if you take that situation, you flip it on its head, and you change the name of the team from the iPhone App Team to the Mobile Commerce Team, and then you change the way that you task that team, you no longer ask them to build an iPhone app.
You say, "Your job is to increase mobile commerce, increase the amount of sales that we do through mobile channels." That fundamentally changes the task of that team. They don't necessarily have to ship an app, they don't necessarily have to ship anything.
Jared: They just have to improve commerce.
Jeff: They have to improve commerce. What happens there is the measure of success changes. It's really easy to manage delivery. Delivery, in the sense that if you are the iPhone App Team, and your job is to ship an iPhone app, then that's a fairly binary thing. You either shipped the app, or you didn't, and so you won, or you lost.
It's a lot more difficult to manage to this type of outcome. You say, "Hey, your job is to increase mobile commerce by 15 percent. We're not gonna tell you what to build. You have to figure it out." At the end of a period of work, let's say 6 months or a quarter, your team comes back up in front of the organization, and says, "Well, we increased mobile commerce by 4 percent. Did we fail? Should we go again?"
It's about learning, "Well, terrific. You did 4 percent, how did you get there? Can you scale that up, or is there another approach?" Again, what they build is not required. There are no requirements upfront. The requirement is an outcome it's an objective, "Achieve this particular business goal."
They get to figure out whether it's an iPhone app, or whether it's geolocated SMS alerts to buy certain things based on where you are, or maybe it's a WhatsApp integration or, who knows. Facebook messenger integration for customer service like they're doing with some brands right now. Ultimately, the team decides what they're going to build based on how they're affecting customer behavior.
The concept of requirements, at least upfront requirements, goes out of the window. The team then has to experiment, and learn which ideas drive customer behavior in that particular direction. Then they define the requirements for the ideas that actually move customer behavior towards their stated objective. It flips the whole conversation on its head.
The scope becomes time. Let's say we're going to work on this for three months, and then we'll figure out at the end of the three months if this is something that we should continue to work on, because we'll know if this is something we should continue to work on. Because we've been trying to achieve this particular outcome for three months. Again, this assumes that it's then safe for the team to come back and report their findings very openly, very frankly.
Because they may come back and say, "You tasked us with increasing mobile commerce by 15 percent, we don't believe this is achievable. We've been working for three months, we think this is a waste of time. We need to figure out a different way."
Or, they may come back and say, "Hey, you know what, it's been three months, we hit 15 percent. What do you want to do next?" Whereas, an iPhone app would have been given a year. Maybe you don't need a year. Again, it's about shifting the conversation.
Jared: Other than shipping an iPhone app, it doesn't have any business goal that you can point to the bottom line and say, "This was worth it."
Jeff: Yeah, exactly, the "so what." No one is asking, "So what?" Few organizations ask that question, "Hey, we shipped this feature, we shipped the app." "So what?"
Jared: Do you have different ways you phrase that question? One of the ways that I've been using is "Imagine we do this project, imagine we ship this app, and a year has gone by since we shipped the app. What's different?" I find that oftentimes, when I do that, I get this deer in the headlights stare of, "Well, we shipped the app. [laughs] There's an app in the world that wasn't there before."
"OK, but what's different? How is the business better?" "Well, because they're using our app." "OK. What are they using our app for?" "Well, we have to figure that out, that's what the requirement thing is for." "No, no, no. [laughs] What outcome does the business need that an app is the right way to get there?" Sometimes that conversation's really hard to have.
Jeff: It's extremely difficult because most of the people tasked with doing that work have never been asked that question before. It's not how they're incentivized.
They get their bonus, or they get to keep their job if they ship on time, and on budget. It's not about, "Hey, did you actually move the needle?" It's, "Did you ship it?" That's what they're test with and that's what the incentive structure is. That's unfortunate.
The conversations we have, similar kind of things. My favorite question when I talk to new clients is, "How do you determine success in your organization?" Invariably, the response is always, "That's a really good question."
Jeff: A hundred percent of the time, that's always the first thing that comes back, because they have to think about it. They have to think about it beyond shipping.
Jared: You would think that that would be the thing that everybody could just come out off the top of their head, as if they said it a thousand times. This should be the thing they wake up and talk about every day.
It should be the first conversation. "We're Pinky and the Brain."
Jeff: [laughs]
Jared: "We're going to do what we always do. We're going to try to take over the world." At least they knew what they were trying to do. [laughs]
Jeff: That's right. It's amazing. Again, it's because of the way that they're being tasked, and the way that they're being paid.
Jared: Right. No one's paid for success. People are paid for getting shit done. [laughs]
Jeff: It's true across the board. There's this perception that, somehow, delivering stuff is valuable.
Jared: Yeah. You're absolutely right.
Jeff: Again, no one…Not no one, but very rarely does anyone ask the question, "So what?" One of my favorite, and I'll probably use it in the workshop at UI20, but it's one of my favorite photos, there's this guitar. I forget the name of it, but I used a photo of it.
It was a guitar that was custom made for Pat Metheny. It has dual necks, and 18 or 20 different strings on it, a variety of knobs and controls and so forth. I always reference it as the Microsoft Word version of a guitar. 95 percent of the things that are included in this particular guitar are useless to 95 percent of the population. Only a couple of people can actually use a hundred percent of these things.
Microsoft Word is exactly the same way. We all use the same 10 features. There's a thousand other ones that only five other people use. That's the conversation that I like to have with people that I'm working with.
It's a question of…shipping features is not a measure of success. Let's figure out what customer behavior we actually want to impact, and then decide how we're going to impact that customer behavior.
Jared: I'm looking at this crazy thing. This is the Picasso guitar by Manzer. I found it by just googling "Pat Metheny custom guitar." This is insane. It's got 42 strings.
Jeff: 42 strings, yeah, exactly.
Jared: And four necks. [laughs] Apparently, he actually played it in concert a couple of times.
Jeff: Yeah. Again, awesome. If you're the Pat Metheny of Microsoft Word, terrific. All that bloat has value to you. This is why products like Sketch and Pixelmator are clawing at the Adobe Creative Suite products. Because Photoshop is Microsoft Word of photo editing.
Jared: Right, it's got 42 strings, and 4 necks. Deep inside is a feature that somebody asked for that no one's ever used.
Jeff: Yeah, and then you fire a Pixelmator, and you're, "OK, I can crop. I can resize. I can put a couple of filters on there, tweak the levels a little bit, and ship it. That's what I need Photoshop for 97 percent of the time.
Jared: Right. This is exactly, I think, what the problem is. Are there tricks that you've learned, like having everybody repeat first thing of the day, "Our goal is not to ship an app. Our goal is to increase e-commerce, mobile commerce sales"?
Jeff: The trick that we use, the trick that I've used repeatedly, and it's UX 101. It's go meet your audience. Go talk to your people. This comes back to UX, which is the beautiful part about all of this.
We've been here all along. Now is the time in that, this is customer experience. This is go meet, go see how your users currently solve these problems. Go talk to them about what's valuable to them, what they actually need the thing to do.
Get a sense of what's getting in their way, what's keeping them from solving these tasks today and then solve for those problems, for those real problems, not for the thing that you think that they actually need.
I know you promote this in everything that you do, and everything that you've done in your organization. People have been talking. It's not that I invented this, or that Eric Ries invented it, or Steve Blank invented it.
It's so easy, and yet, practiced relatively infrequently. It's to have just a continuous qualitative conversation with the market, so that you always have a sense of what your audience is doing, and what they're struggling with.
I have another story that I'd love to tell, which is back from my days at The Ladders, we used to talk to three customers every Thursday.
Jared: Three customers every Thursday?
Jeff: Yeah, three customers. We'd recruit them on Monday, and we'd figure out what we would talk to them by the time they showed up. I did this every week for three and a half years. When we started this in 2009, late 200, early 2009, every conversation with a customer starts off with a little context setting. "Tell me a little bit about yourself."
In this case it was, "Tell me a little bit how you look for a job. Tell me about your family situation. When we started in late 2008, early 2009, the context setting conversation revealed that text messaging was not a legitimate form of communication for our target job seeker audience.
We're talking about executives with 25 to 30 years of experience, typically in their mid-50s, or older, teenage kids. Text messaging in late 2008, 2009, was something that their kids did. Maybe it was something that they did with their kids.
That was simply learned…It wasn't a direct question that we were looking for. We weren't looking for features to build text-based features. We just simply learned that by having this regular conversation.
Now, having this continuous conversation over three and a half years, by 2012, late 2012, early 2013, it became very clear that there was a significant shift in the mental model of our targeted audience when it came to SMS and text messaging.
All of a sudden iPhones are much more prolific, and text messaging becomes this way for executives to get around their corporate firewall, their Blackberry corporate firewalls, and have private conversations that their bosses can't see. Especially if they're job seeking, this is really important.
Again, we weren't seeking out this information. But by having this continuous qualitative conversation with our audience on a weekly basis, we began to see this shift, and then, ultimately, start to take advantage of it.
That's the trick. The trick is to know what your customers are trying. Why were they doing it? Because they needed a private channel. They needed something that their bosses couldn't see, and this provided that.
All of a sudden you've got a sense of what problems are arising and opportunities. Then that's where creativity and genius comes in to creatively solve those business problems.
Jared: This has been really enlightening.
Jeff: I'm glad. [laughs]
Jared: I think there really is this nice idea of reframing what you're trying to do, and getting everybody back on page, and then using the users as the way to keep them on the right page.
If it's resonating with the users, as you're testing your assumptions, as you're testing your hypotheses, then you're going in the right direction.
It doesn't dictate the deliverable or the outcome from the get-go when you don't go down this rut of saying, "Well, we have an app, and if we have an app that must mean that we have a splash screen. On the splash screen we have to have this, and this, and this."
It's like, "No, it doesn't say that you have to have any of that stuff."
Jeff: Yeah, we discover. We call a part of discovery, you'll hear the other folks in the space talk about it, Marty Cagan, Jeff Patton, and all of those guys talk about product discovery.
That's what we're doing. We're discovering the product. We have a sense of the business problem we'd like to solve, and we're discovering the solution as we go.
Jared: That makes it sound so much easier than the way so many folks want to do it.
Jeff: And yet. [laughs]
Jared: And yet…which is why you have to give this workshop at UI20. Did you know you're giving a workshop at UI20?
Jeff: I did, yes.
Jared: Did we tell you that?
Jeff: You did.
Jared: That's good. Our communication's working. For the rest of you, if you want to hear this and spend a full day with Jeff talking about exactly how you can reframe these problems in your organization, you want to come to UI20.
You want to sign up for Jeff's incredible workshop. You will not regret this. You want to do it soon, because his is always one of the first ones to fill up and sell out.
You want to make that happen. It's going to be November 2nd through 4th. It's in Boston, Massachusetts. You can find out more about it at uiconf.com. I'm so excited that we're going to do this. Thank you, Jeff. This has been really awesome.
Jeff: Thank you very much, Jared. It was my pleasure. Always fun chatting with you. I look forward to seeing you in the fall.
Jared: Yes. To the rest of you, thank you so much for spending time with us today and listening. As always, thank you for encouraging our behavior. We'll talk to you again. Take care.
Here's an excerpt from the article:
Lean UX is deeply collaborative and cross-functional, because we no longer have the luxury of working in isolation from the rest of the product team. We can't continue to ask our teams to wait for us to figure it all out.
Read the article: Why Lean UX?
How do you implement Lean UX? Tell us about it below.]]>
Register you and another for the UX Advantage Conference in Baltimore, August 18–19, and you'll get rewarded with a half price ticket for yourself.
Learn from 14 inspirational pioneers who are delivering user experience as a competitive advantage to their organizations. In live, on-stage interviews, Jared Spool and Karen McGrane talk with design leaders who are at the forefront of redefining their industries.
You and your co-worker will hear from UX leaders at PayPal, Capital One, Fidelity, GE, U.S. Digital Services, and more as Jared Spool and Karen McGrane interview them on how they are using UX as a competitive edge.
Register someone at the current price and you'll get 50% off your ticket. This is a combined savings of over $900 off the registration price. But hurry, this offer ends on Friday, July 17.
Save money and guarantee your spot in the workshops of your choice. Register for the User Interface 20 Conference, November 2–4, 2015, in Boston. But hurry because the lowest rate of $1,475 ends July 16.
Your UI20 registration includes:
"Both the workshops and speeches were extremely useful and inspiring. The whole experience was beyond my (high) expectations!" —Juha R., past UI conference attendee
"This was a stellar conference. It reinvigorated me. Mad props to the presenters. I learned an incredible amount of stuff, socialized, ate well, and loved all of it." —Mackenzie R., past UI conference attendee]]>
Here's an excerpt from the article:
In the last few years, companies like GE, Fidelity, Marriott, MasterCard, IBM, Paypal, Nasdaq, and Capital One have realized they can gain a competitive advantage by producing better downstream user experiences. They're driving change in their industry by helping their customers' organizations deliver better experiences in their own products and services. It's not good enough to delight your direct customers. You have to delight all the customers and employees down the supply chain.
Read the article: Making Companies Competitive by Expanding Design's Role.
How are you using design to become more competitive? Let us know below.]]>
Product Managers are responsible for the success of a product. As we've seen, UX is not misaligned with business goals, in fact it helps achieve those goals. If UX has become a necessity in terms of a driver of business, product managers need to adapt to it. Those who have a respect and understanding for the value of UX, and incorporate it into their product strategies, can better serve their users and customers, as well as the business.
In business, competition is the core of what drives innovation and consumer loyalty. But this doesn't mean catching up to your competitors in some feature-checklist war. What sets your product apart from others and what about it delights your users? Engaging in user research can tell you how your customers use your product but more importantly why they use it that way.
That question of "why" can be very important. If the users of your product are requesting what seems to be a simple fix, such as moving a button, there could be a greater underlying reason. So rather than just accepting the request and acting on it, using research to uncover that "why" can lead to a new use case that you weren't actively supporting. This in turn can lead to greater opportunities for the business as a whole.
Bruce will be presenting one of 8 daylong workshops at UI20, November 2-4 in Boston. For more information about his, and the other workshops, visit uiconf.com.
Recorded: June, 2015
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]
Jared Spool: Hello, everyone. Welcome to another episode of SpoolCast. I am very excited today that we have Bruce McCarthy, who is a product manager extraordinaire. He's been doing a tremendous amount of work over the last few years, teaching product managers how to do product management.
I've run into him a few years ago at some workshops that happened here in the Boston area called Product Camp, which is this fantastic day-long set of sessions. He gave a great talk on roadmaps. I realized there's a lot of intersection between roadmaps, user experience, and what we're doing.
We talked a bit and today we're going to talk to him about these roadmap and UX things. Bruce, welcome!
Bruce McCarthy: Thank you very much. Good to be here.
Jared: Product managers, they are this force in a project. There are good project managers, and like everything else, there are not-so-good project managers, just like there are good designers, and there are definitely not-good designers.
One of the things that I've learned over the years is that when you have a great product manager on your team, things get done and they get done well. All of the plates seem to keep spinning.
Bruce: That's a good way of describing the product manager's job, as the team's plate spinner.
Jared: I don't know if you're old enough. You're probably old enough. A lot of people I talk to are not old enough to remember "The Ed Sullivan Show." There was always that dude who had the plates on sticks, where he would spin them.
He would have like 20 of them and his entire act was, to some Siberian dance music, keeping all the plates spinning. I never understood what the point of it was, but apparently this is a career path for people.
Bruce: Apparently! It's a good analogy for product managers. Some people call the product manager the CEO of the product. I don't think that's exactly quite right. I think of them more as, to use the business position analogy, a COO.
Because they are still operating within the strategy set by the executive team usually, but under that mandate, they are empowered to tap any resources necessary for the success of the product. Their job is to direct all the activities cross-functionally and make sure that they're all pulling in the same direction.
Jared: That's how I see it. They tend to run interference with things that want to take the project off track. They tend to be trying to predict issues that are going to come up while they're still early and easy to deal with. I remember when I was doing software development back in the '80s, I worked with a couple of really awesome product managers.
They were sharp people, but at the time I did not sense, like most people in the world, that they saw design and user experience the same way I did. You've been around long enough. Has the perspective on how the importance of a good user experience shifted in the product-management world?
Bruce: Dramatically, I think, over time. I've always been a big believer in it, myself. Initially not so much as a business driver, but just because I was interested in the topic. It's become a necessity for product managers over time, especially, with the shift to SaaS.
If you think about it, the product manager's responsible for the success of the product, for the business outcomes of everything that they do. The perspective of the product manager has changed with the business necessities.
If you're in a SaaS business, then that business is not just about winning RFPs as it might be in a big-enterprise on-premises software installation, or selling units as it might be in packaged software, which is all about the promise on the box, if you will, of all the great features that you're going to get. Instead, the real key to winning in SaaS is retention and renewals.
Jared: SaaS being Software as a Service?
Bruce: Software as a Service, where you're paying for the software as a subscription over time. That means you can stop paying for that service as a subscription at any time. Which means that, if I want to be successful as a purveyor of Software-as-a-Service tools, then I need to be able to make you happy as an ongoing user.
I need to have you engaged and using my product every day or at least every month on a regular basis, so that, come time for the annual renewal, it's a no-brainer for you. "Of course I will sign up again." Even if it's a B2C product that's more month-to-month, then every month when the bill comes, you're happy to pay it.
You're happy to put in your corporate credit card or set up a PO and just set it and forget it. That means if I've got to keep you happy and engaged as a user, as a product manager I'm much more focused on making sure that that's likely to happen, that you can do what you need to do in the product.
That you can accomplish your goals and that you don't dread logging in to the product every time. If I go back to when I was a young product manager in the '90s, it was much more about features. It was much more about, "Do we have the checklist of features that you want, compared to the competition, so that you will buy at first?"
But actually, now that I think about it, my perspective about usability being important may have been informed by my first real official product-manager job. I worked for a little company called iMarket back in the '90s.
Jared: I remember them.
Bruce: Yeah. You could buy data on CD-ROMs. It was marketing data, so we sold to marketers. It was a subscription product. It wasn't delivered over the Internet, not initially. Later on we did that. But it was a quarterly CD that we sent you. It was an annual subscription. Also, the more you used it, the more data you bought from the platform, the more money we made.
Jared: That was a Lotus spin-off, right?
Bruce: It was.
Jared: I knew those guys. I remember I worked with them when they were at Lotus. They had a great product.
Bruce: They really did. It lasted quite a long time. It lasted into the new millennium. The company was eventually bought by Dun & Bradstreet.
Jared: Yeah, D&B. I remember that.
Bruce: We had a subscription product and we tracked our renewal metrics. We tracked how often people actually used the product once we had a phone-home feature built into it, because we knew that the renewal rate was a big lever for the success of our business. We had a renewal rate around 80 percent and we were always working to try to optimize that.
Jared: I remember. I worked with a lot of teams back in the day. The not-so-great product managers, they seemed to focus on customer surveys, getting customers to rank what features were best, and then just constantly catching up with competitors.
Bruce: I've got to tell you, those are two hot buttons for me. They are really common mistakes, rookie mistakes in my mind. They bug me, when people rely on those things, because both of them are really abdicating your responsibility to think strategically about what's going to make your business successful and what's going to make your customers successful, which hopefully is what drives the first one.
If all you're doing is getting into a feature-checklist war with your competition, that's just a recipe for becoming a commodity. You and all your competition will have the same list of features, and the only thing left to compete on will be price. That's a terrible place to be operating.
I would much rather be the product or the company that really gets a particular segment of buyers and users. Really understands them in depth and can, as a result, serve them better than anybody else. We did that, I think, pretty effectively at iMarket. There were a bunch of imitators — CD-ROMs where you could buy marketing data — that came out afterward.
They all ended up either going out of business or for a while they sold for $79 once a year, instead of our price, which was hovering around a thousand dollars for a year. The difference was that we really did understand the marketer. We really did understand their needs. We really got into their heads. We had a usability lab right there in the building with a one-way mirror.
We'd invite people in and watch them use the product and take notes. As the product guy I sat through all of those tests and took notes. We debated about what to test next, based on what we'd seen. It was a real driver for us.
The competition thing, I always think, is a bad idea. If people want to look at my blog, productpowers.com, I have an entry that's been very popular called, "Don't be better than the competition!" That's about this particular issue.
Jared: That sounds like a great entry. We'll get a link to that posted out.
Bruce: The other one you mentioned was voting.
Jared: Voting, yes. Oh my gosh, the voting thing.
Bruce: There's tools out there that are enabling in the bad sense of the word, like UserVoice and Salesforce and others, that allow you to set up a voting system, so that your customers can propose ideas and vote on them. I have a blog entry on this, too.
Dell came out with something called IdeaStorm back when they were having some financial difficulties and having difficulty growing. The whole idea was there would be a forum where customers could send them ideas for products or features, and other customers could vote on them.
Very quickly, a bunch of Linux zealots took over the forum and, because they were really passionate about it, went in and voted every day and managed to put Linux on Dell boxes up to the top of the list. But that wasn't going to drive Dell's business. That wasn't innovation. That was just the hobbyhorse of a small but dedicated group of people.
Jared: Yeah, and so many times people ask for things that they're not going to use. Or they're asking for a solution that isn't the best solution for them and others.
Bruce: That's exactly right. Usually, I find when a feature request comes in or a design-change request comes in from customers or from a salesperson or a customer-support person who got it from a customer, it's that person's best guess as to a solution to a problem, but a problem that they haven't articulated. They're not telling you why they want it. So you collect this list.
Product managers usually have hundreds of things on this sort of list, somewhere in Excel, of feature requests or feature ideas that they try their best to prioritize. But they haven't usually gone and dug underneath the request to understand the real underlying need, to understand the problem that the customer wants solved.
What I recommend the product people do, actually, and this is something that UX people can help with, is to figure out the underlying need by going back to the original requester — the customer, the user — and saying, "I got your list of 57 things that you want to change in the product. Can you tell me why you want these things? Let's start with number one."
"You've asked for this button to move from here to here. Why do you want that?" "Well, the button is on the opposite side of the screen from the other controls that I use while I'm doing a particular task." "Oh, wait. You're doing what task?" "I got this thing I need to do every day." "Oh, you're the first person who's ever told me that you have to do that thing."
"I didn't know people did that thing with my product. Tell me more about that." Pretty soon, you understand that there's a whole new use case, or a set of use cases, among your customers that you didn't know about, that your product does not serve well.
If that turns out to be common, that a bunch of people are using or could use your product in that way and derive some value, you can come up with a whole new approach to solving that use case that might involve moving that button where the customer asked for it, but more likely involves completely rethinking that workflow.
If you successfully do that, you might expand your market. You might get a whole bunch of new customers. Even if it's not new customers, you might have more engagement and a bunch of much happier users who are more likely to renew.
And a bunch of the little onesie-twosie-type of requests like, "Move this button, or change this color!" will all evaporate from your list of 150 things to do, because you solved that one underlying need that you didn't know existed.
Jared: People who are off doing user research in the UX space, they're running into this all the time, where one of the mantras of good user research is you don't actually listen to the customer, but you watch what they're doing and you ask lots of questions. There's a technique that's popular amongst UX people called the "Five Whys", which has its good sides and bad sides.
I like the "Five Whys" because it basically says, "Don't just stop at the first answer. Keep going!" What I don't like about the "Five Whys" is that it implies that there's only one "why" to everything. If you follow it down, "Why do you want this feature?" "Because I need to produce this report." "Why do you produce this report?" "Because I have to get information to my manager."
"Why does your manager need that information?" "Well…" You start to drive down this stuff. It implies that at the end of the fifth "why", you've got all the information, when in fact there may be more than one reason for the report. There may be more than one reason that their manager needs the information.
Bruce: I love the "Five Whys" construct. I talk about it frequently when I do talks and when I train product people. But you're right, it's just a tool in the toolkit. Overall, I talk a lot about the need to do qualitative research with your users and your buyers, to go and watch what they do and ask why they're doing it, to understand the larger context.
You can even do a little bit of that over the phone, although it's not nearly as high-fidelity as if you're there in person with them. It all starts with a general understanding of, who is this person that maybe represents a persona in my world? What is it that they are trying to accomplish in their job or in their life that's relevant to my product?
Where is it that they currently have frustrations? All the feature-request conversations, including the five follow-up "whys", need to live in the context of that understanding of who is this person and what's important to them and where are they struggling.
Jared: Right. We're definitely on the same page with that. I think the "Five Whys" thing is a great thing just to get people to realize that you can't stop at the first answer.
Where I go with it is, there's a technique known as a fish-bone diagram, which I'm sure you're familiar with, which basically allows for the idea that there's more than one thing at each step and lets you draw them out and fill them out to completion, and then you get to prioritize. It just gives you a bigger picture. We digress.
What I'd really like talking about here is the idea that there's a lot of commonality between how a product manager is trying to figure out what's the right priority and direction for this thing that…
I guess one of my senses is that one of the differences that separates a really awesome product manager from a not-so-awesome product manager is that a really awesome product manager is always thinking in multiple releases. In fact, this is one of the things I remember about working with iMarket back in the day, when they were at Lotus.
I think after that, they would have on the wall what was in this release, what was in the next release, what was in the next release. If I remember correctly, you guys shipped four times a year. Two of the releases were bug fixes. Two of the releases were new feature elements.
All those things were planned out. If somebody wanted to add something to the upcoming release, "Oh, we need to put this in the…" You had to ask the question, "What's not going to be there?"
Bruce: All right. It's a matter of physics.
Jared: Right. The people who are not very good product managers, I think they just say, "Yes, sir. We'll do that. We'll get it in there somehow." Everything seems to be focused on the next release and this notion. But this idea that there's a long lifetime to a product is something that, I think, is just becoming understood to many people who work outside of product management.
Bruce: I think that's true. Again, it may have something to do with the increasing prevalence of subscription models. We appreciate that there is a kind of at least nominal or an opportunity for a purchase decision more frequently, not just once but over the lifetime of a relationship with a customer.
They're going to be making the decision to keep going or not keep going with you many, many times. You've got to continue to satisfy. In fact, because the competition is catching up and because there are always new alternatives, you've got to find ways over time to continue to raise the bar on satisfaction with your existing customers.
Going back to what you were saying about thinking about releases over time, I think really good product managers have always thought that way. They've always realized, "We're going to have to increase our value over time. We're going to continue to work on this thing and make it better and more compelling."
"Even if we do have a one-time sale, we've got to be able to get to a broader and broader market over time." I remember early in my product manager days, when we all operated more or less on waterfall and release schedules…Could be very long. They could be years. The prevalent question about any given feature was, "Does it have to be in the release?"
The release, capital T, was your sole focus, the next release. That's a difficult world to live in as a product person, because what you want to be making is decisions about increasing value to the customer and thereby to the company, over time. Exactly on what intervals you release that value is somewhat important, but not the most important thing.
The most important thing is that you do the most highly leveraged things first. The things that are the biggest bang for the buck. Things that add the most value for the least investment in time and resources, and that you set up an ongoing train of adding those things. That release schedule that you described, that we had back at iMarket, I remember it vividly. We had it up on the wall.
I was responsible for it for a good while. It was a road map. The prototypical definition of a road map is, we're looking four to six releases out and we're saying, at a high level, these are the things that we're trying to tackle in each of those releases. You hit it at the very highest level, feature release followed by bug fix, followed by feature release, followed by bug fix, very high level.
We also would bring it down one level from there. Instead of talking in depth about a bulleted list of 57 features or a bunch of tickets in JIRA that we were going to try to get to, we would talk about it in broad themes. We would talk about it in terms of problems we were trying to solve for customers.
Jared: I've heard you talk about these themes before. Remind me again, a theme is different than features.
Bruce: Yeah. A feature is like, "We're going to shorten up the number of steps in the checkout process on an e-commerce website." You go to Amazon, and you got five or six steps in the checkout process when you're buying something. You got to put in your credit card. You got to give it the shipping address. You got to verify this, that, and the other thing, and eventually you get to check out.
A feature would be like reducing the number of steps by, say, combining the shipping and financial credit card address on the same screen instead of as two steps. Then you have to ask yourself, if somebody has suggested this idea, whether it's design or engineering, a product or a customer, why are we doing that?
Jared: Yeah, why are we doing that?
Bruce: What problem are we trying to solve? It turns out that we have drop off during the check-out process. At each stage, there's a percentage decrease in the number of people who make it to the next stage. We figure that if we combine some stages, we lose fewer people along the way. Now we're trying to solve the problem. We're trying to solve a problem of abandoned carts.
We might actually decide that there are, potentially, many things we could do that would help us resolve this problem with abandoned carts. Maybe there are too many steps. We could test that as a way to reduce the fall-off. Maybe there's a problem with one particular step where people can't remember their credit-card number or something.
Or maybe some part of one of the screens is just incomprehensible to the user. They don't know what's being asked for. They keep putting in the wrong information, and we keep throwing errors. Maybe it's that people are just easily distracted, and they lose interest halfway through. They mean to come back, but they never do.
So maybe we need to send them email reminders. "Hey, did you still want those ski boots, because they're sitting in the cart, ready for you to checkout?" There's probably a dozen different ideas about how we could improve the experience of the checkout in order to lose fewer people along the way.
If I'm putting something on a road map that says that we're going that address that problem six months from now, I've got six months to figure out what the best solution is, and it might not be reducing the number of steps.
Instead of saying, "Six months from now on the road map we're going to reduce the number of steps in the checkout process," I'm going to describe a theme, a benefit-oriented, problem-solving theme. The problem I'm trying to solve is to increase the checkout rate or decrease the cart abandonment rate.
That's a benefit to me, the company, not to the user, but hopefully the user actually wanted the ski boots. It's a benefit to them and directly, too. That's what I'm going to put on the road map. I'm going to say, "We're going to reduce cart abandonment." I've got 12 ideas that we're going to explore along the way, and test our way what one or two or three of those are the best ideas.
Jared: So these themes really allow you to hone in on a problem, not the solution?
Bruce: Right.
Jared: It seems to me that that is where — if you have on your team people who know how to do user research, people who have good design skills — that's where they would thrive.
Bruce: Absolutely. This is where I work very closely with UX people. I actually use UX people to help me fill out my road map. I've got an existing product or a prototype for a product. I'm starting somewhere. I'm thinking about the next 12 months' to 18 months' worth of things that I want to put on the road map.
I have some ideas about that, but it's difficult for me to be certain of the priority of those things. It's also difficult for me to be sure about which solution is actually the right solution to a particular problem.
I'll put out problem-solving type of themes, like the ones we talked about, in a preliminary way, based on the feedback that we're getting from the prototype or from the current version of the product, the problems that are coming up from user research, or even from requests after I've asked my five levels of "why".
I'll put that out there. Then I want to work with a UX person to validate that these problems are in the right priority order. They're all real problems. The worst problems are being addressed first. For any given problem, we'll work through prototypes, clickable mock-ups or whatever, of potential solutions to that problem. We'll try them out on users and see what really works the best.
If we're working ahead like that, then my road map gets smarter and smarter and better and better, and more likely to actually solve the right problems in the right order as we go.
Jared: It feels like that's where you get to do some of the stuff that we're talking about these days around testing assumptions, and putting out hypotheses, and creating this notion of what people call a minimal viable product, but it's really just, "What's the least we have to do in order to see if, in fact, we understand the problem?"
Bruce: I'm a big believer in this minimum viable product, this MVP concept, but many people misunderstand it. It's a sort of…
Jared: They think of it as, "What's the least we can get away with shipping?"
Bruce: The crappiest-version one that we can possibly put out. In fact, it is, "What is the smallest amount of work" — you said it well — "that we can do in order to validate a hypothesis, to verify that our assumptions about our business plan…We're going to provide a product, a certain product with a certain feature set to a certain market. They're going to be willing to pay for it."
"We're going to be able to acquire them in a profitable way." You got to figure out whether those assumptions are all right before you actually go and build the entire product, and start to market and then find out that some of those assumptions were wrong.
Jared: Right.
Bruce: UX people are, I have found, highly, highly leveraged in those early days of testing your assumptions. I've done this over and over again, actually. We did it at NetProspex, and we are doing it right now with a startup that I founded called Reqqs, reqqs.com. It's a product for product managers that helps them with prioritizing and road mapping.
What we did early on with that product was to first do a bunch of research with product managers to understand their problems, and when they ask for features to ask them why they wanted them. Get those problems boiled down to the essential few, which, with product managers, it turned out, the worst problems are prioritizing and road mapping.
Both the decision-making part and the communications and getting-everybody-bought-in parts of that process. Then the whole question was, "Do we have a solution to those problems? Do we have something that will actually provide value in those problems over and above the alternatives," which right now, for most product managers are Excel and PowerPoint.
So we did mock-up after mock-up. I walked users through those mock-ups. We set them up in a clickable fashion. So you could go from one page to the next as though it were a real product with real data.
Kept optimizing it based on the feedback that we were getting and to the point where we had something that was in HTML and clickable and apparently responsive, even though there was no database behind it, that people said, "Yeah, this is great. If I could put my real data in, this is exactly what I would want." Then we went from there into producing the real code.
We used a whole bunch of the front-end code. Not all of it, but a lot of it. Similarly, at NetProspex, I was building a tool for salespeople that was basically a search tool for contact information. It was for telephone salespeople, for what they call BDRs, who just make lots and lots of outbound phone calls all day long and make appointments for salespeople.
This was a quick lookup-tool, essentially, for getting the right contact information for somebody you wanted to reach. We had a whole team of these BDRs. We had 25 of them at NetProspex in-house. So I said, "Perfect. I will produce a clickable mock-up and I will put it in front of them and see what they think." I learned a huge amount by doing that.
Then after we got beyond the clickable mock-up stage and into early prototypes, but the UI was still very minimal, I would put it in front of them have them actually use it in their job and see where it did or didn't work for them. I quickly learned to keep the UI simple.
It actually helped me reduce the feature count that we needed in order to get into our first release. Because I discovered that some of the advanced features that I thought people would think were really cool, that the salespeople couldn't figure out how to use them. So we just got them, and we had a better product for it.
Jared: It seems like these are such obvious things, yet many teams feel like they have to discover it on their own, and reinvent what's already known.
Bruce: I have some hope that the world is getting a little bit more educated about the necessity to involve design early and often, and about the value of crafting an entire user experience and buyer experience all the way from…
I think about it as a journey that starts all the way from the marketing and publicity stuff — where people do speaking at events or they write blogs or they have advertising to try to create some awareness…
All the way through the buying process, all the way through the first-use process, all the way through the repeat-use process and the renewal, and eventually hopefully referral to other potential customers. That whole process and the experience of your buyer and your user through that entire process, has to be optimized if you want to have a profitable business today.
Jared: I think that that entire sort of thinking of the experience is definitely the way that organizations are going, and that everybody needs to be ready for this. I'm really excited about your workshop at UI20. I think it's going to be a lot of fun.
I think it's going to be a great way for folks from the design community to understand how to influence the road map, and influence the strategy of the product, and to bring their super powers as UX people into the process and be able to build better experiences and be contributing to the team in even a bigger way than they already are.
Bruce: I'm excited about it, too. I think there's a lot of overlap there between those roles. Only good can come from closer collaboration between the two of them. I know people who have jumped the fence between those two roles, and found a renewal of enthusiasm for coming to work and new challenges.
I would encourage anybody on the UX side to think about whether product management is for them. It's a crazy job, can be stressful, but it's hugely rewarding. You really get to see the fruit of your labors when a product ships.
Jared: Yeah, I have many friends who started out as designers and user researchers and other folks on the UX side, and have found their ways into product management and working on the product team. We go to lunch and they're just as nice as they've always been.
Bruce: [laughs]
Jared: Nothing about them seems to be that different [laughs] .
Bruce: So you're saying it's not going over to the dark side.
Jared: No, that's a complete myth! Whoever is spreading that rumor, it's a complete myth. Bruce, thanks today for taking the time here.
Bruce: My pleasure. Thanks for having me.
Jared: To all of you listening, if you want to see Bruce in action and to hear how your work can influence product strategy and how the product-management world can make your life a lot easier, you want to attend his workshop at UI20, which will be November 2nd through 4th in Boston, Massachusetts.
It's a full-day workshop where you'll talk about all the things we've talked about today and more. You want to check that out. Thanks to Bruce, thanks to everybody who was listening. Thank you very much for encouraging our behavior. We'll talk to you again, soon. Take care!