Designing with Scenarios: Putting Personas to Work

September 27, 2016

This article is an excerpt from the podcast that Kim recorded after her virtual seminar, Designing with Scenarios: Putting Personas to Work. You can hear the full podcast or read the transcript on the podcasts page.

Adam Churchill: Is it a true that scenarios only work if you have have data-driven personas? Have you seen scenarios used effectively, even if the research can’t be funded?

Kim Goodwin: Great question. I think that you can do scenarios without data.

It’s better to have data if you can because it has a few benefits. One is, you’re more confident that you’re getting to a good answer. And it makes it a lot easier to make design decisions because instead of wondering how a person would react, you actually know. This is assuming you know them well.

Think of it like you’re planning an event, or buying a gift for someone close to you, versus, say, buying a gift for your child’s teacher or an acquaintance you don’t know well.

The first one is a whole lot easier than the second one, and data gives you the confidence that you’re doing the right thing. Secondly, the data helps you persuade stakeholders. It’s not you, the designer, who is probably pretty low on the totem pole, saying this is how it should be. It’s you, the designer, channeling the users and saying, “Look, based on our data, here’s how people think and act, and so here’s why this is a great solution.”

So, data is best, but not always necessary. I definitely do scenarios without data. A few weeks ago, I was working with some subject matter experts on an idea for a medical device. Four of us sat in a room, and we didn’t have data. The point was to get to some design ideas fairly quickly, so that they could explore the feasibility of this idea.

It didn’t make a lot of sense for us to go get data, and we said, “OK, let’s build some shared assumptions about the kinds of users we’re talking about.” We came up with what I call provisional personas, which are like sketchy representations of what we think the usage patterns and goals are. Then we used those to create scenarios just as we normally would.

Regardless of the absence of data, scenarios are a design tool you can always use. You’re just going to be making decisions and communicating with a bit less confidence when you don’t have data. But the tool still works great.

Adam: Can you explain the difference between scenarios and a storyboard?

Kim: A scenario is the story, it’s the script. It’s the words that describe the action. A storyboard, on the other hand, is the graphic depiction of that action. For instance, the movie extras on your DVDs or your Blu-ray where they show scenes building or sketches stuck on the wall. That’s what I mean when I talk about a storyboard.

It’s essentially at a thumbnail level, but the key to storyboarding is the depiction of sequence over time, right? A storyboard can be a very rough napkin sketch. If you’re talking about a high-level service design, like getting through the airport, you might have stick figures walking through physical space. If you’re doing just a screen-based design, you probably won’t storyboard your first pass at the scenario because it’s so high-level, you’re not really getting into solutions.

But then as you start to get into more detail in design, you’re going to keep storyboarding at the whiteboard, drawing multiple instances of a screen and how it changes over time. As you start to express that design and share it with stakeholders, you can have storyboards at that wireframe level, where they’re pretty much content and control complete, but you haven’t really incorporated any visual design.

You can still use that storyboarding approach down at the pixel level where you’re showing changes in screen state over time like putting them in a PowerPoint presentation or something similar and flipping through them. It’s similar to keyframing, like they do in the movies. So storyboarding is essentially a sequence of pictures that tell a story, and the scenario is the text of the story itself.

Designing with Scenarios: Putting Personas to Work

At times organizational processes get in the way of real solutions. Using powerful sketching and collaboration techniques will align your teams to build user-driven experiences. Join Kim in her workshop on Using Scenarios to Solve Problems at the UI21 Conference

Signaling a Process Change with a Discovery Phase

August 24, 2016

It’s easy to find people frustrated with their current product design and delivery process. They’ll list any number of maladies, from missing their customers’ true needs to forcing a buildout of unwanted features. Much of the time, many of their co–workers share that frustration.

Yet, those organizations are petrified of changing the way they do things. They know they need to change, but the act of change frightens the life out of them. This ironic justification of desire and fear keeps them from making things better.

Sure, they’ll announce “we’ll do it differently this time.” The executives will make proclamations about how they’re now a design–driven organization and how they’ll put the needs of customers first. There will be meetings about the new process, complete with powerpoint decks filled with box and arrow timeline charts.

Then, after all that, they’ll return to doing things the way they’ve already done it. The next project will start the same way every previous project has, often with the ritual called The Gathering Of The Holy Requirements. A product owner will spew forth the two or three dozen new features they believe are required for the next release. User stories will be crafted and sprints will be scrummed.

This new project will start like all previous projects have started. And it will end the way they’ve all previously ended, with the delivery of less–than–satisfying results.

Discovery Can Change All That

A thoughtfully–crafted, well–executed discovery phase can set an organization on a completely different path. More importantly, the discovery phase signals to the organization that, this time, the process truly will be different. And it does it with little fanfare and pomp. In fact, it’s often most effective when done in a bit of stealth mode, when only the direct participants are seeing the process.

Dan Brown has spent the last few years taking apart discovery phases to learn how they can be most effective. He’s created a great framework for them.

Dan Brown’s Discovery Activities Matrix

Dan Brown’s Discovery Activities Matrix

In Dan’s framework, he splits the activities of the discovery phase into two main groups:

  • framing problems, where the team dives deep into the problems customers and users experience
  • setting direction, where the team explores potential solutions and matches them up with the customer problems they’re solving

Each of these groups has:

  • an early stage, where the team first diverges, exploring the range of problems and solutions
  • a later stage, where the team then converges, honing in on the specific problems and solutions they’ll tackle

If you’re already conducting design sprints or employing Lean UX, those are likely your discovery phase. However they aren’t the only approaches a team can employ. Experienced design leaders can create a bespoke workshop that includes activities such as user visits, competitive evaluations, group sketching, day–in–the–life narratives, and insight prioritization. The leader can tailor this to fit the needs of their specific projects.

Dan recommends using the discovery phase to bring your design’s influencers together. When you lead the assembled group through the discovery phase activities together, the team will gain a shared understanding of both the customers’ problems and possible solutions. Using the discovery phase to frame the problem and set the project’s direction gets everyone on the same page.

How The Discovery Phase Signals Change

Space is indeed the final frontier. Nothing signals ‘something is different this time’ more than when you reserve a conference room for a week (or several). The same is true when you ask a group of important people to clear their calendar for a workshop. Organizations hold the space/time continuum as prime real estate and to reserve it means something big is happening. Add executive support and encouragement and now you’re sending a message that this is a big deal.

The activities within the discovery phase also signal change. By drilling deep into the problems of customers, the team breaks the tradition of starting a project by jumping to the most obvious solution first. These activities focus on learning about the problem, such as customer visits, observing the customer support, interviewing salespeople, and exploring how well the competition meets your users’ true needs. The team will gain insights about their users they’ve never considered before.

The leader of a well-designed discovery phase will recruit a multi-disciplinary team and assemble people who have different viewpoints about the project. These folks will participate in the project all the way through.

A multi–disciplinary team likely breaks with tradition of only involving key people in small slices of the project, because it’s deemed wasteful to have them contribute outside their expertise. However, when they’re involved all the way through, they get the benefit of seeing what goes into a design. And by contributing their own expertise much earlier into the process, they provide insights that have previously been absent or discovered too late.

Having these different folks contribute from the very beginning breaks with another long–standing tradition of relying on organizational seniority over who truly has the necessary knowledge and experience. The activities of a discovery phase equalize the role power in the room, letting everyone have a voice. It quickly becomes obvious that solid contributions can come from anywhere in the organization. For many organizations, this is a new way of doing business.

Making It Difficult To Fall Back Into Old Habits

One of the best benefits of a well–run discovery phase is the discomfort the participants will experience with the old ways things were done. What used to be considered acceptable (if not desirable) practices now are seen as non–productive. Instead, the team now wants these new practices that emphasize a shared understanding of what the team is building.

The movement from requirements gathering to assumption validation is one common organizational shift that comes from introducing discovery phases. Teams realize they’ve been spewing requirements without any sense of whether they are truly needed or not. Now the team sees them as tools to, from the project’s start, understand what the customers’ need and what won’t matter. This creates a culture of questioning beliefs in a healthy way until they’re validated through research.

Once shifts like these have started, the team finds it very difficult to fall back into their old habits. They’re more comfortable when everyone has a shared understanding. They create a common vocabulary to describe problems they’re solving. And they find they can move faster to produce better results, which in turn, makes the entire executive staff happier.

Starting with a discovery phase for new design and development leads to better quality products and enhancements. Crafting it well can also signal that the organization is changing, by setting an example of how things are better from the beginning.

At UI21, Dan Brown will show you how you can create effective, tailored discovery phases that are perfect for your organization. Learn more about his workshop, Crafting the Ideal Discovery Process for Critical Designs.

The Right Way to Train the Wrong Way Research • A Podcast with Cyd Harrell

August 12, 2016

When we’re training teams on our design methods, what we perceive as ‘proper’ may in fact become a hindrance. Our dogmatic approach to our processes may prevent people from ever employing the techniques. Is it better to do it the right way, or to teach a wrong way that will get the job done?

Cyd Harrell encountered one such situation, while working with a government design team. They would’ve never conducted user research if she’d taught them the proper way to do it. By breaking “the rules,” she empowered the team to embrace good design and improve the life of their citizens.

Cyd has a wealth of great techniques for successfully teaching guerilla user research. You can learn them all in her full-day workshop at the UI21 conference October 31 – November 2, 2016, in Boston, MA. For more information about Cyd’s and the seven other workshops, visit uiconf.com.

Transcript


Jared Spool:
This is the UI Conference Podcast. I’m Jared Spool. Part of becoming better at something—becoming more experienced—is learning that there’s a right way and a wrong way to get things done. Yet, when you become a master, well, that’s when you learn that sometimes the wrong way might in fact be better than the right way.
That moment, when the wrong way is likely the better way, often happens when you’re thrust into a situation where time and resources are at their most limited.
Cyd Harrell: Something that I always try to tell myself is that it makes sense, for me, to refine your techniques and practices over a couple of decades like I have, but if you are an underfunded government person, you might be able to get a lot out of any time you can give to this.
My name is Cyd Harrell. I am a UX researcher by trade, and I do a lot of training and mentoring of people in the civic technology space.
Jared: Through her work in the civic space, Cyd has encountered a number of outdated designs in government websites and software.
Cyd: Most government software looks like the ’90s, and design is not a priority, particularly the sense of design, as in visual design that most government people would attach to that word, is not a huge priority for software, unless it comes to something like the graphics on the front of the city website.
Jared: As our design influence expands, we need the teams we work with to take on more of their own design process. This is especially true when their resources are constrained, like Cyd’s underfunded government teams. And like all design teams, if they don’t get their design in front of actual users, they may not learn how frustrating they’ve made it. To teach her teams this lesson, Cyd’s come up with a clever and simple trick.
Cyd: I found the whole bunch of sets of instructions for Origami Giraffes. What I do is I actually provide people with inappropriate materials. I put regular eight-and-a-half by 11 sheets on the tables. I don’t offer any scissors. At the end of the set of instructions, it wants you to draw spots on the draft. I don’t give them any pens as the paper isn’t colored.
The instructions do a couple of common failure mode things that a lot of websites do like use vocabulary that no one but a power user would be familiar with or the diagrams really aren’t clear. If you think about the way that Origami instructions would be provided and in fact like a video might be the best way, but we look at them either on paper on a flat screen.
Jared: Cyd’s origami giraffe trick works. Teams get the message.
Jonathan Feldman: She gave these instructions about how to make the giraffe. Of course no one could do it because the instructions were so God-awful bad, which in city government, we see that all the time. We think it’s very clear when it’s really clear as mud.
Then Cyd stepped everyone through what if you made the instructions based on how people like to take in information. I think a lot of light bulbs went off in my staffs’ mind at that point.
Jonathan Feldman. Chief Information Officer with the City of Asheville, North Carolina.
Jared: Like many in government positions, Jonathan has experienced the constraints that come with of a shortage of resources.
Jonathan: We had never done usability testing before Cyd’s workshop.
If we just start designing things in this way where we start doing usability testing of everything, we’d probably be in a lot better shape in terms of actually being able to help people.
That was the understatement of the decade because when we did usability testing and we gave folks objectives, man or woman off the street, employees, whomever.
We gave people objectives, we found that they were taking sometimes 15 minutes to figure out how the heck to achieve that objective.
A couple of redesigns later, it was taking new people, not the same people but cohorts of those people, under 15 seconds to achieve those same goals. That’s pretty strong.
What’s interesting is it just wasn’t hard to do. It was tedious. It required time. But it was so effective that my staff became very enthusiastic about doing it. Frankly, the folks in the public information office also became enthusiastic about it. Because who doesn’t want their stuff to be easily accessible?
Cyd: One of the first slides in my presentation at that workshop is it’s not rocket science.
I tell them that if you are someone who can have empathetic phone conversation with someone you care about, about something that’s happened to them. You have the necessary skills to do this, well enough, to get something out of it that will make your development better.
These are a bunch of practices that I would not use largely in a study that I was doing for a client of mine that I’m recommending to people in different relationship. It’s actually influenced the other way and it’s like “Well maybe I need to be a little bit more flexible,” carefully considered of course in some of what I do myself.
It’s not that it works better. It’s because it works well enough and a gold standard might be unattainable.
Jared: Now some might say Cyd is breaking the rules: She’s teaching these teams a sloppy way to do research and any professional would know better. But, the teams she’s teaching aren’t professionals and they’d never have a chance to work with professionals.
The choice isn’t do it the right way or don’t do it at all. Cyd’s approach is that doing something is better than doing nothing. Can we teach teams how to move the needle and get results, using a method that isn’t the proper method, but is more effective than nothing?
Cyd: I try to provide people with an enticing bite of something that isn’t necessarily wrong, but that probably isn’t all the way right, either, when I’m doing it in that compressed of a timeframe. One other thing I was thinking about is why does this work. In part it works a little bit because I’d been willing especially in working with government people to do it wrong.
Jonathan: I think that a lot of us in our department are very customer focused. I think that we’re a little bit unusual of an IT organization because I believe we all think that IT is a people business, not a technology business. We’re here to help people, not harm people.
Of course we would not go back to that old way of doing things because it just doesn’t help people as much.
Cyd: Jonathan was just in for lunch, and he left, so I had to call him back and say, “How did you guys do this? Did you hire a designer?” He said, “No, we just decided to pay attention to design, and we did two or three rounds of testing with real users. Then we listened, and we made it better, and now we’ve come up with this.”
The thing that he said to me, and made me really believe it’s permanent, is he said, “Cyd, we have never had an opportunity to delight our users.”
Jared: That moment—when the team realizes there’s something they can do to dramatically improve the quality of their design work—that’s the moment we are all work for. Showing them that, as long as they have the user in mind they can achieve great results, that’s the core of a good design practice.
This means we need to challenge our assumptions about what research needs to be and, more importantly, be much less dogmatic about our processes. Just because a technique might not be textbook perfect, doesn’t mean it’s the wrong way to get our teams focused on delight.
The UI Conference podcast is brought to you by the User Interface Conference, October 31 through November 2, 2016 in beautiful Boston, Massachusetts. That’s where Cyd Harrell will give her full-day workshop on Low-Cost Guerrilla User Research.
Cyd walked me through everything she’ll teach that day, and it’s fantastic. She’s packed the workshop with practical, real-world techniques that will help you show your teams how they can get immediate and inexpensive information about who their users are and how to design great experiences that’ll meet their needs. If you’re working with teams with constrained budgets and schedules, you’ll definitely want to check out her workshop.
You’ll find the complete description of Cyd’s workshop, and the other great full-day workshops at uiconf.com. That’s U I C O N F dot com.
The UI Conference podcast is produced by myself and Sean Carmichael. We’d like to give special thanks to Cyd Harrell and Jonathan Feldman for being a part of this episode.
You can find more information about the UI Conference podcast on iTunes and at the User Interface Conference web site, uiconf.com.
You’ve been listening the UI Conference Podcast, part of the growing UIE Podcast Network. Thanks for listening and encouraging our behavior.


Building Scalable Design Systems and Style Guides • A Podcast with Nathan Curtis

August 11, 2016

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 Curtis has been swimming in the deep end of the UX pool since 1996, when he started focusing his creative energies on IA, ID, usability, and front-end development. He's also an entrepreneur at heart, having founded, along with Dan Brown, the renowned EightShapes in Washington, DC, where he continues to make a splash today.

Nathan’s been a top workshop speaker at the User Interface Conference before and his All You Can Learn seminars are loved by our audiences. We’re excited to bring him back to deliver this brand new in-depth workshop. You’ll see why.


Transcript

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.
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: 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.

 

Using Scenarios to Solve Problems • A Podcast with Kim Goodwin

August 5, 2016

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

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

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

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

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

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

Transcript

Jared Spool: Hello there. You have dialed into yet another episode of the “Spoolcast.” I am Jared Spool. I’m the guy in charge of these things, but today we have the real person in charge of all things Awesome UX. We have Miss Kim Goodwin, who is one my favoritest people in the world. This will be podcast number 751 with her and she is going to enlighten us about how we get scenarios to work in our organizations.
Kim Goodwin: I’m well, Jared, especially after that fantastic introduction. How could I not feel pretty good?
Jared: That’s how I feel. That’s how I feel. I’m putting together this conference. Every year I go out and I find speakers who are talking about things that I’m most interested in. I invite them, and your stuff always ends up on the top of the list almost immediately.
I’m putting them together, and I’m writing up the description of why I have each session. As I’m writing it up I keep finding myself writing the phrase “Get on the same page.” We have Bruce McCarthy talking about production management, so it’s like, “Get on the same page with your product manager.”
We have Jenn Lukas talking about creating a living style guide out of CSS. It’s like, “Get on the same page with a living style guide.” Nathan Curtis talking about design systems. “Get on the same page with your teams through a great design system.”
Of course, scenarios help us get on the same page. The thing is that I didn’t do this on purpose. I crafted the conference in terms of the people I wanted to hear. It just occurred to me that everything I wanted to hear about was about getting people on the same page.
This is because this is the thing that I deal with most when I’m talking to the companies I’m working with. I was wondering if you’re seeing this, too. Are you talking to people a lot about “How do we get on the same page about what we’re doing?”
Kim: Very much so, Jared. That’s a huge focus for everybody working in this space right now. I think 20 years ago when your conference first started…
Jared: Yes, 20 years.
Kim: We were all trying to figure out what our profession was. We were trying to figure out the techniques for solving the design problems in the first place. Our message were just starting to come together and certainly drawing from other fields, like industrial design and HCI and other things.
But I don’t think we generally had coalesced a method. Where nowadays, I feel most practitioners have had some contact with pretty similar sets of methods in a pretty well understood way that we can solve problems.
Now that that’s done, everybody’s focused on, “Wait, why are we still not getting stuff done?” Ultimately, it all comes down to aligning the organization around where you want to go.
Some of that’s about process. Some of that’s about skills. Some of it’s about culture, but it all comes down to alignment.
Jared: Yeah, that’s exactly right. I’m thinking about the first UI conferences that we did. We had sessions every year about the basics of usability testing, for example, and the basics of what we would now call “Interaction design.” Back then that wasn’t what it was called, and the basics of these things.
Now this year we have a session that is still usability testing and user research. But the way Erica Hall is going to deliver it, it’s about coming to a shared understanding, getting to a common knowledge about it.
It’s the elements of that type of research that get everybody on that same page. I think you’re right. We have moved past the basic tools. Yet, we’re still struggling to produce great experiences all the way through.
So, it isn’t just having the tool in our hand that automatically makes us instantly producing a great UX, just like buying the most expensive blender does not make you a great cook. You have to know how to use those tools in a great way
Kim: Exactly. Alignment is honestly, not even just alignment within a product team, it’s alignment across an organization and especially as a user experience now might be partly digital. It might be bricks and mortar retail. It might be on the phone. It might be a thing you get in the mail. All of that is wrapped up into the user experience.
You have to get even more people on the same page. Now that I think about that, that’s probably another reason why, just in the last few years, that need for cross-team, cross-silo, cross-functional focus is probably bigger than ever.
Jared: Yeah. In a lot of organizations it’s like that old phrase about, “The future is here. It’s just not evenly distributed.” The knowledge of how to get to great designs is here, but it’s not evenly distributed.
Kim: That’s true. It’s not even evenly distributed within an organization. Generally, I find that in a given organization there’s one team that’s maybe doing really sophisticated work.
Where other parts of the organization, especially when they’re internally focus groups like the IT group, often maybe lags behind the product group, because it wasn’t that a customer facing driver for them, for example.
Jared: In this world where we’re now putting together multi disciplinary teams, do you think that means that in a given team, there’s going to be a distribution of knowledge of what it takes and just getting that entire team to have a shared understanding and being on the same page takes work? It doesn’t just automatically happen.
Kim: Certainly, within that team you want a distribution of skill sets because that’s why we’re multi disciplinary in the first place.
Where I find those teams often begin to struggle is because they don’t have a sure understanding even of the problem they’re trying to solve, they don’t have a shared language or a shared perspective on what it is the solution needs to accomplish in the first place.
It feels like requirements and even Agile user story, I think don’t really make it clear for teams. So, in my experience the first step is to come together around a tool that helps everybody see the problem from the same angle.
Jared: You’re absolutely right about that. Let’s hone in on the role scenarios play there. It feels to me like they play a really critical role in helping that team and the parts of the organization that has to interface with that team, interact.
Kim: If I can rewind a little bit and look at something that you want to do, ideally is a precursor to scenarios, journey maps do a better job of aligning people around the problem, to prepare them to develop scenarios of the future solution.
Some time ago when I first started teaching scenarios, which is probably more years than I care to count, I would find some people took to it naturally and others really struggled with the generative aspect of scenarios and didn’t quite know where to go with them.
When I started teaching journey mapping, which essentially takes your user research and lays it out in a timeline fashion. Imagine that you are outlining this person’s encounter with your tools and with other tools in some way and then you’re mapping that versus, “How do they feel about this? What are they trying to accomplish? What are they trying to learn at each stage of this journey?”
That’s a structure that starts to really open people’s eyes around, “Oh, boy, this stage in our journey is really awful.” Actually, we do OK here. People aren’t too stressed about this.
That’s first to align the team around, “Where should we focus our energies?” because a whole user journey is usually quite large and touches probably every part of your product and maybe other people’s products, too.
That’s a great starting point and it’s a good jumping off point for generating a scenario that tells the future story of the product.
Jared: When putting the journey map together, when you’re doing that, are people coming from the same place when you’re doing that, or is this a tool that you gather around to synthesize where everybody on the team is coming from?
Kim: You could do it either way. In my experience journey map works best when you have people who have a shared base of user research, rather than just discredited assumptions and experiences.
Ideally you pull together some qualitative research people have done and you start to map that out. In my experience actually, that journey mapping exercise tell people whether they’re good or bad at qualitative research because you can’t do a journey map that means it’s a lousy interview.
But if you want to use a journey map as a starting point when you don’t have that shared context, that’s not a bad thing. Because part of what it will probably reveal is that lack of shared context.
You can say, “OK, if you all think we understand our users, let’s sit down and try to do our journey map together.” That’s actually going to reveal the holes in the team’s knowledge and probably reinforce that actually it is worth you going down and sitting down with at least a handful of users in their actual context.
Jared: Being able to get that journey map built, once you have it built, it feels to me that now it’s a really useful tool to help people who weren’t involved in that research to pick up and get up to speed quickly and tell those stories.
Kim: Yes. It’s a way to make that tangible. It’s a way to express a lot of what you saw in those interviews in a pretty compact and digestible way. Then from that journey map you can start to get people thinking, “All right. Now let’s imagine what that future experience is like.”
You begin to tell the story of if you had a magic black box that you could put in people’s hands, what would happen? How would that story unfold differently? That’s where you start to build, Jared, understanding about the solution.
In a universe where you just have a bullet list of requirements or you have some acceptance criteria detailed in an Agile user story, which to my mind is not really a story per se.
Jared: You mean as an administrator, “I want to be able to log in” is not a story of my experience? [laughs]
Kim: Yeah, because there’s really no plot or character in that, is there?
Jared: No, no. You can see the authentication system as a villain. [laughs]
Kim: You want to log in, Jared? Tell me all about that. What an exciting story. That’s the thing. Agile user stories are good scoping tools.
They’re effective communication tools in many ways, but stories they’re really not whereas a scenario says, “Imagine if we had the magic new product or the improved functionality. Here’s how that would unfold.” That starts to imply a whole host of requirements.
It’s a generative tool that helps product managers understand requirements, helps designers influence those requirements, and helps all the engineers start to get a picture of, “Oh, that’s going to have to connect to this, and we’re going to have to build it this way.” It starts to take shape very quickly that way when you’ve got a story to tell.
Jared: This idea of being able to tell stories seems to be a key piece of this “Getting people on the same page.” Do you think this goes back to a basic human trait of just being storytellers?
Are we just taking advantage of what thousands of years of evolution and sitting around the camp fire teaching our children how to be good humans has all been about and we’re just moving that into the process?
Kim: Yes, I do. I think storytelling has to be our most natural form of communication as humans. It’s something that we all learn to do at an early age. The beauty in that is through storytelling. As children we’re generative.
We’re creative, which I think is a very critical part of the design process because if we can’t be imaginative it’s hard to come up with a future state that’s going to be more desirable. We absorb stories very well. There’s very little cognitive barrier to absorbing a story.
We don’t have to process a whole lot because everybody from Dr. Seuss and the star-bellied sneeches trained us to absorb the moral of the story without really having to think about it much.
Jared: It’s interesting that we can use that as our touchstone in terms of helping people get on the same page. One of the things that I’ve always been attracted to your approach to scenarios about is how it’s very much a human storytelling process. I guess going from the journey maps to the scenarios is really just a story-translation process.
We’ve got this journey. We now have the scenario of what it is today, and we can come up with an aspirational scenario of what we could do. What’s neat is in any given story what I learned about storytelling is it’s not just the details you include. It’s also the details you leave out. Scenarios are interesting because of what we don’t say explicitly in them.
Kim: Yes. First I think that we’re trying to be as human as possible in the design process, so we come up with the most human solutions. Why not turn to those tools that help us think in that form? You’re right that we do leave certain things out.
What I see often when people use cases or more formal structured tools is they’ll start talking about how we hit this database table or this server does something or this part of the system behaves in this way. Who cares?
Jared: Or we sell more cookies or we sell more hotel rooms.
Kim: Right. Who cares? Whereas if we focus on what does this particular human being that we’re envisioning, whether that’s a persona or some real user we interviewed that we’re using as a center point of our story, when we think about that and we just describe what they experience — what do they see and encounter — it doesn’t matter how the back end does it.
It doesn’t matter if we buy that capability and plug it in. It doesn’t matter if that’s built using OAuth. Whatever technology doesn’t matter because we’re just getting at the gist of it. That helps keep requirements at the right level because I see a lot of teams that will do requirements that are actually lists of solutions instead of lists of problems that must be solved.
The scenario focuses on, “This is the behavior we want to enable.” Then from there we can figure out, “Oh. Well, there are three ways we might enable that. Which is the best?”
Jared: That’s really interesting because that’s very similar to something that…when I was talking to Bruce McCarthy about his workshop, which is going to be on “How can user-experience people work with product managers effectively,” we got on the subject of something that separates a really good product manager from folks who are trying but don’t quite get there.
One of the things that separates is that the people who are trying go down that requirements route that you just talked about, but the people who are really good at being a product manager back away from the requirements. He has a word he calls themes.
Themes are the overarching problem that we are trying to solve, but we’re not going to make a list of requirements that are the solution. We’re going to talk about that we need to solve this problem. Maybe the solution that comes to mind first is the one we’ll take, but maybe there’s a better solution. We want to leave ourselves open to that.
When we talk about what the roadmap will be for the next three releases, we’re not going to talk about specific functionality and features. We’re going to talk about the themes we’re going to tackle in each stop on the road map.
It feels to me that pairing scenarios up with those themes would make them more human, more accessible to everybody, and more clear that this is the problem we’re going to solve when we get to that part in the road map, but we don’t necessarily know today what the right feature is. We’re not going to commit to it. We’re going to commit to solving the problem.
Kim: Yes. Better yet, Jared, in an Agile world where a lot of people are focused on what they’re doing in the next one or two sprints…
Jared: People use Agile?
Kim: They use AgileFall or something of that nature…
Jared: Yes. [laughs] They use something.
Kim: …but they call it Agile.
Jared: They call it Agile, right. OK.
Kim: Don’t call it anything but Agile. In a world where people tend to be focused on the short term and the every chunkable functionality, what a scenario does when you attach it to one of those themes or whatever you want to call it is the first pass at a scenario is deliberately timeline agnostic. What I mean by that is it’s not going to focus on, “What’s the version one?” A scenario initially says, “What do we really want that solution to be?”
Then we’re going to pair that scenario with some sketches — fast, cheap, low-fidelity — but make it clear what we’re envisioning for the solution. Speaking of getting people on the same page, nothing beats a sketch paired with a scenario to do that.
From there you say, “OK, we all agree that this is the thing we’re aiming at. Hmm, how long is it going to take us to get there or to get 80 percent of the way there?” because maybe from a product management point of view that last 20 percent isn’t worth it.
Even so, in order to get there, we’re going to maybe come up with some interim sketches and figure out, “All right. Well, maybe this is a two-sprint project. Maybe this is a big, ambitious thing we’re going to have to work toward over the course of the next year.”
That initial fast, cheap scenario puts all of the subsequent user stories into context, so that everybody knows, “Ah, this is about enabling that stuff that we’re going to have fully implemented six months from now.”
Jared: That’s fascinating. I have this image of a designer standing in front of a wall with a whole bunch of sketches. They’re actually play-acting the scenario as they talk about each sketch and walk through each sketch.
The scenario…it’s like those Bible stories that we all know the basic plot to, yet we tell them over and over again, the Passover story, the Easter story, Muhammad going to the mountain, or whatever the story is, Luke discovering R2D2 and taking it Obi-Wan Kenobi, all those religious stories.
We all know the basic story and we can tell that story over, and over, and over again, but now we’re using the sketches almost as props for how that journey will happen going from here out.
Kim: Scenarios can operate at a lot of different levels. You can do very low-level scenarios that are about iterating that thing in front of you that you’re going to ship in a couple weeks. Scenarios also operate very well at the medium- to long-term vision level.
I think you and I both have found in our work that organizations that have a crisp longer-term vision of, “What is the thing we want to build?” and it’s not just a bullet point in a mission statement, but some concrete visualization of that thing, are more able to execute on that. Scenarios really help you with that.
The best example of that I found is one that kind of stole from you. I use it in my workshops from time to time, which is the “Apple Knowledge Navigator” video. What was it, 30 years ago? Apple put together a kind of hokey video that includes Siri, except Siri looks like Bill Nye the Science Guy.
It includes a clunky version of the iPad. It includes screen sharing and a whole bunch of other stuff that honestly has only shown up in the last 5 to 10 years. They’ve known for a long time roughly where they were going, and that’s probably been a big part of why they’ve been able to execute.
Jared: Did you know that that video was part of a set?
Kim: No, I’d love to see the other one.
Jared: The only other one I’ve been able to find is a version of it that involved a digital camera. Again, this was years before anybody had digital cameras. It was 1987, and I don’t think the first digital cameras showed up…Apple had one of the first digital cameras in the mid-’90s, like ’94. Then the Kodak digital cameras came out right after that.
All those were done by Hugh Dubberly. As far as we know, there were four done. Two of them have survived, and the other two, nobody seems to have any original footage of.
Kim: Definitely, for the folks on the podcast, I think that video is worth Googling and I’ll probably drag it out in my workshop.
Jared: Yeah, “Apple Knowledge Navigator” is how you find it.
Kim: It’s a great example of how putting it in the form of a story and illustrating it in some concrete way makes a huge difference in people’s ability to see, “Ah, that’s where we’re going.” Every time a team that I work with is able to start doing that, when you have a story and you have some sketches to go along with it, it really reduces the confusion and the swirl about what a requirement means.
If you have a requirement that’s just a bullet point, you can spin back and forth about what that means and whether the requirement’s been met for months.
Jared: It’s such a powerful way to get everybody talking about solving the same problems. It’s still surprising to me that we have to re-learn this lesson over and over again.
Kim: If I could wave my magic wand and make design schools better at one thing, it would be at helping people ask the right questions and better define the problem. I really think that’s the thing that many teams struggle with the most.
Jared: It’s funny you say that. I do have a magic wand over a design school, and the conversations that we’ve been having at Center Centre, as we’ve been designing the curriculum, is just that. It’s trying to push the emphasis less on finished product, and more on the process that got you there, which means you have to be able to tell the stories of why you did what you did and how you did what you did.
Kim: That’s actually very important in getting people on the same page. As a designer, you can come up with, whether it’s a crude sketch or a beautifully polished artifact…if you say, “Ta-dah! Here’s the solution,” you’re going to get all kinds of pushback because people don’t know how you got there.
One of the great things about this progression from user research, to journey maps, to scenarios, to story board, to finished sketches is, “Wow, you can see how that evolved from the previous steps.” People can follow you there, even if they aren’t folks who can immediately look at a sketch and grasp, “Oh, yeah, that’s the solution.”
When you show them the logic behind it, what that says is, “Oh, this isn’t the designer just coming up with something out of thin air. There’s a reasoning behind this and there’s actually an argument for why this design is good.”
Of course, you want to do usability testing and other things to help you make sure that you’re on the right track. But, in terms of selling that initial solution, you have a path that got you there that other people can see.
Jared: I sit through meetings where someone in a client is presenting a design they’ve come up with. They just launch into the screens, say, “Well, this is the home page, and this is the this page, and this is the that page.” They don’t talk about the scenario.
More importantly, they don’t talk about how they got to this design from the journey map or from the sketches. The audience is left to reverse engineer that in their head. Of course, they all do it differently. Then, there’s all this conversation that happens around what they think the path was that got them there that turns out not to match. All of this is sort of lost. It’s a struggle for a lot of folks.
The best representations I’ve ever been with, before we saw the design, there was this statement of, “The research taught us this, and so we learned that the customers are trying to get to this result, but right now they get stuck here and here.” It only takes a minute to say that, but they go back to that and make sure that everybody’s on the same page.
Then they say, “And then we tried a bunch of designs.” In many cases, in the best of presentations I’ve even seen, they actually show some of the designs they threw out and talk a little bit about, “Well, we first tried this, because it seemed like the obvious thing. But then we realized it didn’t work for this case or it didn’t work for this reason.
“And so we then evolved it and we got to this thing, and now here’s the design we ended up with. And let’s go back to that scenario. The user’s going to start by telling us what they need, and then they’re going to click on this, and that’s because we want to be able to give them the right information,” and then boom, all the way through.
Kim: In addition to that, an effective presentation is specific about which user.
Every product in the world has more than one user. Regardless of whether you are a fan of personas or not, you want to be specific about, “Look, we’re talking about users like this kind of person or that kind of person, and this is the one we’re focused on right now.”
When people inevitably say, “Oh, well why didn’t you design it this way?” or, “I think it should have this feature,” or, “This whiz-bang button, that’s my pet peeve as a stakeholder,” you can say, “Ah, yes, but help me understand when this persona or this kind of user would do that, because they actually don’t care.”
That way, you can take it out of the context of you, the designer, have a different opinion form the CEO — which is an argument you’re always going to lose — to you, somebody with access to information about user behavior, can bring the conversation onto some neutral ground so everybody sees, “OK, yeah. We’re using the same evaluation criteria here.”
That tends to make those conversations go so much better.
Jared: It’s interesting. While you were saying that, I was just thinking. Twenty years ago, when we started this conference, the conversation was all about personas. We talked about personas. Then scenarios were sort of this thing that dangled off the persona. It’s interesting now that the conversation is all about scenarios. When necessary, we bring the persona in to talk specifics about the users.
As I thought that through while you were talking, it occurred to me that, to this day, personas are still a little controversial. There are still people who stand up and, for whatever reason, say, “Personas are a dumb idea. We create stupid personas, then we design for them, and we create bad designs.”
No one ever says anything like that about scenarios. I have yet to see anybody say, “Oh, we should never use scenarios when we design.” [laughs]
Kim: It’s funny because, to me, the personas and scenarios are intertwined. If, for some reason, you’re allergic to personas, I think you can do something similar by picking an individual from your research who seemed to represent a behavior pattern. Either way, you really need to do the analysis about the behavior patterns, whether you give them fictitious names and faces or not.
There’s a lot of resistance to personas out there, mostly because people get them wrong. If people have had an experience with badly done, so-called personas, it tends to sour them on the tool. You get people who over-do the fiction part, who just make stuff up and don’t really use behavior patterns based on research.
Or, they focus on the creative writing aspect and worry about what the dog’s name is and everything else. Who cares?
Jared: The dog and the Hummer.
Kim: Yeah. The essence of the persona is the behavior and the goals. If 95 percent of your persona details are not drawn from the research, then, yeah, you’re doing yourself a real dis-service.
Jared: Have I ever told you my favorite dog and Hummer story?
Kim: Oh, no. Please do.
Jared: One of the red flags that I see in personas is when I get a persona description that’s got some clip art person, almost always white. [laughs]
Kim: And smiling. Don’t forget smiling.
Jared: Yup, smiling person, happy customer. They describe this thing in three paragraphs. They describe who this customer is, but there’s at least two sentences that describe their pets and what they drive.
Kim: Because somebody saw that on a checklist somewhere and decided it mattered.
Jared: It makes it personal, right? We have the CEO, and he’s got a greyhound and drives a Hummer. We’ve got the mom and she drives a Mini Cooper and she has an Irish setter, and they say what the name is, too, “The Irish setter’s name is Butch and the Greyhound’s name is Killer.”
A client says, “Hey, we’ve had another consulting firm. We worked with them to create a set of personas. Do you want to review them?”
I said, “Yeah! I’d love to.” Sure enough, first persona I read, there’s a dog and a Hummer. They’re both right there, and I’m like, “Huh. OK.” This was a firm I had a lot of respect for, so I’m like, “Wow, I can’t believe they went down that road.”
Then, as I got to learn more about the project, it turns out that the project was for the Home and Garden Television Network HGTV. The thing that these personas were for was a project search engine. The project search engine would help you find the best plans and recipes for home improvement projects.
Kim: So your Hummer is relevant.
Jared: Here is the deal. After doing their research, one of the things they found, and this surfaced in the research, was that if you’re doing do-it-yourself home improvement projects, the car you have actually dictates some of the materials you can cart back and forth.
People who have pets have special needs with regards to pet-safe materials. If you’re re-doing the bathroom floor, what happens if the dog runs into the work, as it’s being done, and gets into the grout or the chemicals as the flooring? Is it going to be a safe environment?
They were trying to incorporate in the personas the fact that some people had pets, and some people and big cars and some people have small cars. If you drive a Mini Cooper, it’s a different materials supply than if you have a pick-up truck.
Kim: Some of these biographic details in personas are totally legit. They’re meant to reinforce certain things. For example, if I tell you, “This persona shops at Walmart and that persona shops at Nordstrom,” that’s going to reinforce certain characteristics about those personas, and that’s totally legitimate.
Jared: The rule of thumb, I’ve sort of come to this, and you can tell me if you have a similar one, “Can I point to a design decision that would be effected by that sentence in that persona?”
Kim: Yes.
Jared: If I can talk about, “Well, people with small cars will need certain types of projects than people with large cars, with huge payload capacity, will have different requirements for the projects. Then, boom, it should go in the persona. But, if I can’t talk to a specific design element from day one, then maybe we should leave it out.
Does that work for you?
Kim: Yeah. That’s a fair criterion. One thing you have to be a little bit careful about is it’s not always purely interaction design decisions. Sometimes, it’s a visual design decision or a copy tone decision. Sometimes it’s about the emotional aspect of the design that part of the persona speaks to. It’s not purely functional stuff, too.
If you’re just telling me, “It’s the dog, Henry. They went to college here and they drive this car,” because you think in some formulaic way that should be part of a persona, no. All that’s going to do is undermine the credibility of the tool and make your team roll their eyes and go, “What is this fictitious crap that the design team is getting paid to make?”
Jared: Again, if you can’t tell the story of how this came from the research and how it makes a difference in the design, it gets in your way.
Kim: Right.
Jared: Wow. I always learn stuff when I talk to you. It’s always a pleasure. I’m so excited that you’re coming back this year for our 20th year to do this.
Kim: Twenty years, congratulations on that, by the way.
Jared: We’re just going to keep doing it until we get it right.
Kim: All right.
[laughter]
It’s pretty darn close to right, if you ask me.
Jared: Thank you.
Kim: I keep coming back, because it’s a really awesome event.
Jared: Thank you for that. We try really hard. We focus a lot on the design. It’s part of what we do.
Kim, thank you so much for talking with me today.
Kim: Always my pleasure Jared, thank you.
Jared: For all you who have been listening, thank you so much for giving us your attention. If you enjoy these podcasts, please take a moment, go the iTunes, click on the appropriate number of stars, leave us a comment. That really helps us a lot.
Thanks for listening and thanks very much for encouraging our behavior. We’ll talk to you next time. Take care.

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

August 4, 2016 by Nathan Curtis

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

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

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

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

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

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

Changing from a Project to Product Mindset

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

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

-@nathancurtis

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

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

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

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

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

Spreading Your System to Their Products = Product Marketing

To have a product means knowing and serving your market:

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

Sustaining Your System = Product Management

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

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

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

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


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

What is Good Product Strategy?

July 29, 2016 by Melissa Perri



“What is your Product Strategy? YOU NEED A STRATEGY.”

When I replay this scene in my head, I can hear the CTO very audibly yelling (slash pleading) with our product team. He was on edge. We had been experimenting towards a very concrete goal for two months, and had made a lot of progress. We had learned so much about what was preventing users from signing up on the site, and it was a lot clearer which direction in which we should be going. BUT we still had to test our ideas.

This didn’t sit well with the CTO because in reality he didn’t want a strategy, he wanted a plan. He wanted a list of what we were going to build, and when we were going to build it. He wanted to feel certain about what we were doing when we all came in tomorrow, so he could measure our progress based on how much we built. It’s not his fault though. This is the way we were taught to think about Product Strategy.

Most companies fall into the trap of thinking about Product Strategy as a plan to build certain features and capabilities. We often say our Product Strategy are things like:

  • “To create a platform that allows music producers to upload and share their music.”
  • “To create a backend system that will allow the sales team to manage their leads.”
  • “To create a front of the funnel website that markets to our target users and converts them.”

This isn’t a strategy, this is a plan. The problem is that when we treat a product strategy like a plan, it will almost always fail. Plans do not account for uncertainty or change. They give us a false sense of security. “If we just follow the plan, we’ll succeed!” Unfortunately, there is no guarantee of success here. (I wish there was, our jobs would be SO much easier!)

These product initiatives aren’t bad, they are just communicated at the wrong time and with the wrong intentions. When we lock ourselves into planning to build a set of features (ehem, Roadmaps), we rarely stop to question if those features are the right things to build to reach our goals. We stop focusing on the outcomes, and judge success of teams by outputs.

We need to have a plan but the plan shouldn’t be “build feature x.” Our plan should be to reach our business goals. We need to switch from thinking about Product Strategy as something that is dictated from top to bottom, and instead something that is uncovered as we learn what will help us achieve our objectives.

Product Strategy is a system of achievable goals and visions that work together to align the team around desirable outcomes for both the business and your customers.

Product Strategy emerges from experimentation towards a goal. Initiatives around features, products, and platforms are proven this way. Those KPIs, OKRs, and other metrics you are setting for your teams are part of the Product Strategy. But, they cannot create a successful strategy on their own.

We need a few core things for our Product Strategy to be successful:

Vision

The vision is your high level, ultimate view of where the company or business line is going. In large corporations, you want to narrow this to the business line or customer journey. In smaller companies, this will be your company and product’s overall vision. Think long term here, and keep it qualitative. This is a good chance to talk about competitors, how customers will see you, and ambitions for expansion.

Challenge

The challenge is the first Business goal you have to achieve on the way to your longer term vision. Which area of your customer journey or funnel needs to be optimized first? It’s communicated as a strategic objective that helps align and focus your team around a certain aspect of product development. This can be qualitative or quantitative. Try to keep these still in broad, high level terms. This one is the hardest for me to personally wrap my head around, but check out the example below for some clarity.

Target Condition

The target condition helps break down the Challenge. Challenges are made up of smaller problems you need to tackle along the way. These are set in terms of achievable, measurable metrics. When you set a target condition, your team shouldn’t know exactly how to reach it tomorrow. They should have a good idea of where to start looking through.

Current State

This is what the current reality is compared to the Target Condition. It should be measured and quantified before the work starts to achieve the first target condition.

These all contribute to something called “Unified Field Theory”, which is explained very nicely here by Bill Costantino and Mike Rother from Toyota Kata. When we are building products, we have a threshold of knowledge. We cannot start on Day 1 and exactly plan to reach our vision. There are too many unknowns and variables. Instead, we set goals along the way, then remove obstacles through experimentation until we reach our vision.

This is best explained through an example, so we’re going to use Uber. Let’s pretend you’re a Product Manager working on the platform that allows drivers to sign up.

Vision
The CEO has stated that the company’s vision is to make Uber the cheap and efficient alternative to both owning a vehicle and taking public transportation. (He really said this in an interview, but everything after this is hypothetical).

Challenge
So if we understand the Vision correctly, Uber wants people to use them as their sole source of transportation. They would first want to look at why other people are taking other transportation methods now instead of Uber. They may go out and interview people and find that in certain cities where Uber isn’t as popular, there is a very long wait time to get a car. They would compare this to other problems and determine how big it is in comparison. Let’s say it’s the biggest challenge at the moment.
So the first goals they may want to tackle is decreasing the wait times in cities where it’s exceedingly long. Let’s say anything over 10 minutes on average is too long, and we want to decrease that down to 5 minutes or less because we’ve seen in cities with those wait times, people are 80% more likely to use Uber.

This is now our Challenge: Decrease wait times in cities where it is over 10 minutes to less than 5 minutes by January 30, 2018.

Target Condition
As a Product Manager, you now want to figure out what is causing that long wait time. The problem in this case might be that there are not enough cars to serve that area. So our metric we care about now Acquisition of new drivers.

Our goal for our team should be measurable and achievable, something like: We want to onboard at least one driver for every 50 people in each city by January 30, 2017.

As the Product Manager responsible for the onboarding process for new drivers you would be tasked with contributing to that acquisition. You would first measure how many drivers per people in each city you currently have (Current Condition), then find the obstacles that are preventing new drivers from signing up today. Next, you experiment to remove each obstacle until you successfully hit your goal. The Product Kata explains how to do that.

So let’s step back and take a look at all that:

(You can download a blank copy of the Product Strategy canvas here.)

As a Product Manager, you don’t have control over all these numbers. The vision is set by CEOs, CPOs, Boards, and other C-Level Executives. The challenge is set by the next level of management (VP of Product for Each Journey or Business Line).

Direct Managers help their teams set effective Target Conditions. At the beginning these may need to be handed down from management. As teams get used to this way of working, the managers and team can work together to set them.

Once these four items are set and communicated, the team can start applying the Product Kata method to figure out how to reach the goals. It’s the Product Manager and their team’s responsibility to determine the user problems and other obstacles standing in the way of achieving that Target Condition. Then they experiment to solve them.

This aligns everyone around a strategic goal and vision. Every level of the portfolio has their objectives. Teams are held accountable for their progress towards the goal they are responsible for reaching.

Now you have probably looked at this and said “well this isn’t a product strategy, it’s a business strategy.” Yes, this does come off looking like a bunch of business objectives, but isn’t that why we built a product? To reach out business objectives? Product Management is the art of solving your customer’s problems to reach your business objectives. If you’re not doing both of those things, your product is just a fancy piece of code for show.


Lots of people can tell you what they think you should be doing differently. Few people know how to give you the tools and knowledge to get substantially better results. Melissa Perri is one of those people. You can get those tools from Melissa at her UI21 workshop.

Convince Your Boss

July 22, 2016

You know it’s worth coming to UI21, but does your boss? Use this information and cost summary to help you get the green light.

Four Overall Benefits:

  1. Push beyond legacy constraints with a highly refined problem discovery process.
  2. Defeat messy, convoluted information with organized, simple designs.
  3. Reduce project friction by infusing design into agile development methods.
  4. Lead the team and stakeholders to dynamic collaboration.

Proven Techniques and Best Practices for UX Designers

Move beyond inspiration and immerse yourself. Jared Spool curated eight master-grade workshops, each taught by an industry leader on groundbreaking UX design skills you won’t find anywhere else. Roll up your sleeves, get down to work, and change the way you design forever. Attend two full-day 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

  • Bring user-focused decision making into your development cycles with practical research techniques.
  • Craft powerful user stories that address users’ biggest pain points and unmet needs.
  • Align your entire team to effectively articulate problem statements and design principles.
  • Reduce your design’s confusion and frustration by implementing controlled vocabularies and taxonomies.
  • Deliver project-forming insights from day one by effectively mastering the creation of direction-changing MVPs.
  • Build a cohesive cross-product experience with defined standards and workflows.
  • Delve into journey mapping, create scenarios that identify and resolve design issues, and deliver solutions that delight users.
  • Create a thriving culture where design is involved at the beginning

Summary of Costs

Item Expense
Conference fee
Hotel costs $850 (for three nights)
Flight $300-600
Transportation to and from airport $15–$25
Food $100
Total $2,940–$3,250

Use promo code BOSS to save $300 on your full conference registration.

Download This as a PDF

Pleasure, Flow, and Meaning – The 3 Approaches to Designing for Delight

July 19, 2016

“THANK YOU! PLEASE TELL NONE OF YOUR FRIENDS ABOUT THE GREAT STUFF YOU BOUGHT, WE ARE TRYING TO KEEP MOOSEJAW A SECRET.”

That’s the big, black, all upper-case message dominating the top of the online purchase email receipt from the sporting goods retailer, Moosejaw. It’s hard to miss and it’s even harder to avoid smiling when you read it.

An email receipt has very important functions. It tells the shopper what they’ve ordered and how much they’ve spent. It tells them when it’ll be shipped and where the company thinks it’s going. It often gives the shopper a tracking number for the shipment. If there were no other words but these details in the email, the receipt would fulfill its function.

Yet, for years, retailers have co-opted the receipt as a touchpoint. They put in solicitations, offers, and pleas to encourage future business. The customer doesn’t ask for this additional marketing copy. In most cases, the shopper learns to ignore the extra stuff.

Sorry For Being So Mean About It

Moosejaw’s ironic anti-plea is delightful. And it matches the copy throughout the experience of using the site.

For example, the solicitation to sign up for their email newsletter says “We’ll send you great discounts, contests and a list of the best mimes in Portland.” In the rules for their loyalty program, they’ve rewritten the usual fine print about expirations to say:

Your points expire two years after they are earned so be sure to spend all your points before then. After two years are up, the expiring points will automatically be removed from your balance by our Rewards Points Overlord (RPO). The RPO is extremely cranky and insists that once the points are gone, they are gone. Sorry for being so mean about it.

Imagine trying to get your organization’s legal counsel to approve an apology for being mean. Yet, Moosejaw’s copy says things like this all the time.

Moosejaw’s trick is they insert these funny little bits into all those pieces of text we never pay any attention to. The user is rewarded for paying attention to the bits of the design that that every other site trains them to ignore. It’s a brilliant strategy.

Intentional Delight

If you agree that design is the rendering of intent, it’s easy to see how the thoughtfully humorous copy at Moosejaw is intentionally designed. It’s a great example of how we, as designers, can integrate delight into what might be an otherwise plain experience.

We can measure a design on a scale from frustration to delight. The middle of this scale is a neutral point, where the design is neither frustrating nor delightful. It doesn’t suck, but it’s not remarkable either. It’s just a neutral experience.

When improving a bad design, we first must remove the frustrating bits to get to that neutral point. Observation of the users’ experience, followed by careful rethinking of the design can remove everything that’s introducing frustration.

Improving the design from the neutral point, to introduce delight is a different process. It’s additive, whereas getting to the neutral point is reductive. We have to know what to add to make the experience become delightful.

Dana Chisnell’s Three Approaches to Delight

Back in 2012, noted author and UX expert, Dana Chisnell, introduced us to her framework about how to design delightful experiences. It outlines approaches that teams can take to start thinking about how they add delight for their users.

At the center of Dana’s framework are three different approaches to making an experience delightful: pleasure, flow, and meaning. Teams can pick which of these they’d like to tackle. For most teams, pleasure is the easiest while meaning will provide the most challenges.

Delight Approach #1: Pleasure

The Moosejaw strategy of embedding clever copy into the corners of the design people normally ignore is a great example of pleasure. It’s almost like the Moosejaw copy has adopted a strong personality – one that uses humor (with a tinge of sarcasm and hyperbole) to make for a distinctively pleasant shopping experience.

Humor isn’t the only way to make a design pleasurable. Something as seemingly simple as providing solid, informative content can also do it.

Great content is how electronics retailer, Crutchfield, has designed delight into their site. Where many electronics retailers just republish the manufacturer specifications, Crutchfield has their enthusiastic support staff provide the product descriptions. The Crutchfield support team includes simply-made videos demonstrating what the staff person thinks of the product, detailed product research that explains the ins and out of the technology, and thoughtful comparison data, to see how different products line up.

Because the content is written by the front-line support people, it’s written from the perspective of answering questions. Readers emerge feeling confident about their product choices. That confidence is delightful for many customers.

We could describe Moosejaw’s personality as mildly snarky and anti-bureaucratic. In contrast, we could describe Crutchfield’s personality as confidence inspiring and empowering to make smart decisions.

Both are different, yet both deliver pleasure to their customers. Pleasure is one way Dana describes how we graft delight into our designs.

Removing the Unnecessary

Few things have had a bigger affect on how we look at e-commerce user experience than Amazon’s 1-Click. In 1999, Amazon put a button on a product’s page that automatically shipped the product to a previously entered address and charged a previously entered credit card. This changed the world.

For the frequent purchaser, 1-Click removed six screens of the checkout process from their shopping experience. No longer did they need to review the shopping cart, enter their authentication credentials, provide shipping information, provide billing information, provide payment information, and confirm their order. Press one button and the product is on its way.

Before 1-Click’s introduction, every site had those six steps. They were a required part of the shopping experience, yet they offered very little value to the frequent shopper. At best, the forms might be pre-filled by logging into an account, but the shopper still had to visit each page of information and click to continue.

1-Click removed these steps, allowing the frequent shopper to focus on the part they loved most: selecting each product they wanted to own. Removing those parts of the shopping process that aren’t about selecting products kept the user focused on their objective. That focus increases their delight.

Delight Approach #2: Flow

Doing one’s taxes is another user experience with a lot of steps. Throughout the process, users enter data printed by one computer into a form that’ll be read by another computer, often using their own computer.

That’s why Intuit developed the mobile app, SnapTax. SnapTax takes a picture of the employer-supplied W-2 form. It scans the text off the form and plugs it into the requisite spaces in the 1040A or 1040EZ tax form.

Once the taxpayer has reviewed for errors, the application then files electronically on their behalf. The entire operation reduces filing taxes to just a few minutes. The user never re-enters computer-supplied information. For these users, the speed makes filing taxes much more delightful than spending hours filling out forms.

Both SnapTax and 1-Click remove steps that computers can do just fine. Removing unnecessary steps improves the flow of the design. Dana’s framework shows us that improving the flow makes the design more delightful.

Delight Approach #3: Meaning

Of everyone in our office, Brian is probably the most proud of the products he purchases. Ask him about any product he uses, from the teas he drinks to the bicycle he rides, and he can give you a story about the company. He can tell you exactly how the teas are made and which special sporting events the bicycle manufacturer has supported. The stories are compelling. They make me want to run out and buy the products myself.

Brian finds meaning in the products he purchases. Actually, I think ‘find’ is the wrong word. He ‘hunts’ for meaning behind the businesses that make the products. When he discovers it, he soaks it in and wears it proudly. You can hear the delight he has, not just with the product, but with the deep pride he has in being an active customer of those businesses.

It would be easy to brand Brian as a zealot or fanboy. It’s not hard to find people like him – people who are proud of the companies they support. Yet, this kind of passion is hard won for those companies. Building a devoted fan base is the hardest of the approaches for delight, but probably the most long lasting.

Delight Only Works When Basic Expectations Are Met

Similarly, I fly United Airlines almost every week. I thought it was cool when I learned United’s staff took special care of the Olympic athletes on their way to the Sochi Games.

However, you won’t hear me singing United’s praises because they don’t give me anywhere near the care they claimed to have given the athletes. I get treated like cattle, despite the volume of money I throw their way every year.

Meaning can only work to delight if it’s authentic. It’s got to be reflected in every touchpoint of the service delivered. Brian’s passion for the bicycle manufacturer is not just because of their event support, but because they make a solid product and deliver great service. My lack of passion for United comes because of the poor service I regularly receive.

Whether we aim for any of the three approaches in Dana’s framework – pleasure, flow, or meaning – the design will only be delightful if it meets the users’ basic expectations. Our work has to start by understanding what users expect the entry stakes to be. Then we can consider how we’ll infuse delight into our designs.

User Interface 21 is a conference tailored to raise your design practice to new heights. Join us in Boston to gain the super powers to tackle today’s most challenging design problems. 

Preparing Organizations to Become Design-Infused

June 28, 2016

Imagine what it’s like to have every co-worker, in every meeting and discussion, keeping the conversation focused on how to make your product or service deliver the best experience possible. With every hard decision you face, your team encourages you to do what’s best for your customers and users. Where the executives seriously consider delaying a release because the design isn’t the best it could be.

Sounds like an ideal world, but for a growing number of UX professionals, it’s becoming a reality. These folks work in design-infused organizations, where every individual contributor makes great design a priority in their work.

Spreading the Knowledge of Design

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.

Becoming a design-infused organization is the next level of maturity. These organizations realize that everything affects the users’ experience. If the technology is chosen poorly, the user will be frustrated by poor performance or limited capabilities. If the wrong functions are implemented, or too many are shoved into the design, the user will become frustrated by the complexity of completing their objectives. Everyone on the team needs to think about how they affect the experience.

A design-infused organization is one where every decision is made with design at the forefront. When choices are available to the team, they’ll all choose the one that provides the best experience.

Reducing the Need for Advocacy by Spreading UX Expertise

Embedding a team with a UX designer ensures that design expertise and knowledge is within easy reach at all phases of the project. However, that designer is still in the role of advocating for good design.

Teams mature when that advocacy is no longer necessary. The natural inclination of every team member is to work towards a great user experience as their primary consideration, even if it means choosing a harder path than one with a lesser experience.

To get to this level of maturity, the team needs to spread the knowledge and expertise of design beyond that designated designer. Every developer and product manager must become literate in the differences between bad design and good design. More importantly, they must also be literate in the differences between good design and great design, so they strive for excellence at every opportunity.

These non-designer team members must be fluent in the techniques and tools of great design. The re-emergence of design systems and pattern libraries are a great example of this. If the team is fluent in their design system—knowing how to use it and why each element exists the way it does—they’ll produce more cohesive designs faster.

Including Influencers into the Design Team

To truly be design-infused, the organization must ensure every influencer of a project has that same design literacy and fluency. When they don’t participate in the design decisions in the same way as the rest of the team, the resulting conflict produces less-than-desirable experiences.

Influencers are those organizational members whose behaviors and decisions affect the resulting user experience. These can be product owners or stakeholders who have final authority over the product or service. Influencers are also outsiders, brought in to ensure compliance, such as the legal team, or execution, such as local branch general managers.

Many influencers don’t realize the power they hold over the user experience. To overcome this, the team needs to seek out and include these influencers as part of the design team. Knowing that, somewhere along the way, the influencers will render a decision that affects the user experience, the team needs to prepare those influencers to make that decision in the best way to create a great experience.

To prepare those teams, including the influencers, we’ve uncovered three essential steps an organization has to embrace.

Step 1: Embrace Regular and Frequent Exposure to Users

Bad design (and often good-but-not-great design) happens because those people making essential design decisions didn’t foresee how their choices would play out in the users’ experiences. Providing consistent exposure to the users’ experiences is a major step to solving this.

Seeing someone use your design tells you whether the choices you’ve made helped or hurt the experience. It’s surprising how many organizations fail to provide this feedback back into their process, even when they say how important good design is to their success.

Design-infused organizations don’t skip this part of the process. They ensure their team members, including the influencers, regularly and frequently watch people using their products and services.

Watching someone use your product or service (or a competitor’s product) for two hours every six weeks is the bare minimum we recommend for exposing team members. (Many great organizations now do even more frequent and regular exposure.) This can be one person for two hours or four people for 30 minutes—it doesn’t seem to matter.

The two hour minimum ensures the observers see enough of the experience. Every six weeks is critical, so that the team members have a fresh memory of the users and how they’re trying to succeed with the product or service. It’s a fantastic moment when a developer describes how they’ve changed a design because they saw a user become frustrated the week before.

Making this happen is a heavy commitment for an organization, not to be treated lightly. They must put infrastructure in place to ensure everyone can observe as frequently as possible. They have to adjust schedules for regular observation. It’s a big cost to make this happen.

Design-infused organizations make it a priority and put the infrastructures in place. Many go so far as to include regular observation as a base criteria in performance evaluations. An organization that says it is design driven must have exposure to users as core responsibility of every team.

Step 2: Embrace a Solid Vision of A Future Experience for Users

Design-infused teams create a shared understanding of what a great user experience is. More importantly, they know which great user experience they’re heading towards. They have a solid vision of their aspirational user experience.

A vision is like a giant flag on a stake, pushed into the sand on the horizon. Everyone can clearly see it, but it’s obviously so far away that it’ll take years to reach. Because everyone can see it, they can follow a simple order: “March toward the flag.” Regardless of where they start or distance from their members or organization, if everyone starts marching towards the flag, they’ll eventually converge.

This is how a vision works. Everyone is marching towards the same goal. The key phrase there is “same goal.”

When a team has told me they have a vision, I like to conduct a little experiment. I ask the team members to take a sheet a paper and divide it in half. In one half, I ask each person to write the milestones of Hansel & Gretel, in bullet form. In the other half, I ask them to write the key milestones of what their vision of the user experience will be five years from now.

It’s amazing to see teams that can accurately describe what happens in Hansel & Gretel. Every team member has the same description of that story. Yet those same team members don’t have any idea how to describe the experience of their own vision. Their vision also must be told repeatedly.

Coming up with an initial vision is straightforward, especially for teams that have embraced regular exposure to users. Creating a journey map of the current users’ experience will show highs and lows—points where the users are delighted and points where the users are frustrated. Teams can craft their vision by just asking how they would eliminate all the frustrating points. Put that in story form, from the perspective of the user, and you have a user experience vision to aim for.

Of course, you can change that experience later. After all, the vision is just the flag stuck in the sand. Pull the flag out of the sand and move some place else and, as long as everyone can still clearly see it, the orders remain the same: March toward the flag

Design-infused organizations bring the entire team, including influencers, in on the vision from the beginning. They ensure everyone describes the vision story the same way. Those team members can now apply a razor to every design decision they need to make: Which option gets us closer to our vision?

Step 3: Embrace a Culture of Continuous Learning

“What have we learned from our last efforts and how will this affect what we do in the future?” This is an oft-repeated refrain in an organization that has embraced a culture of continuous learning.

The United States Digital Service has adopted the unofficial motto of “Make New Mistakes.” Their idea is that it’s likely things won’t go as planned, but they should learn from each one. A mistake repeated means that education didn’t happen as planned.

Another popular saying is “Good judgement comes from experience and experience comes from bad judgements.” Many organizations talk about failure as a component of that work, but the best ones talk about learning as the important outcome of that failure. While teams can’t be risk adverse (which means they won’t have a chance to learn from mistakes), they also have to mitigate the risk to prevent it from being too expensive or public.

Establishing a culture of continuous learning forces the organization to create sandboxes and experiments where the opportunity to gain new information happens in a cost-effective and safe way. The organization invests in capturing that knowledge and sharing it, to help other teams prevent similar mistakes.

Reflections, critique, and retrospective sessions are the basic tools of continuous learning. Opportunities to look back at what people have tried and evaluate how effective their efforts were are essential to gaining that new knowledge and experience.

Everyone on the team needs to be part of that learning experience, including the influencers. As the influencers see what’s been tried in the past, they can adopt their perspectives to ensure the future decisions are more likely to get the team closer to its objectives.

Becoming a Design-Infused Organization

It’s the combination of these three steps that brings out the best in the organization. Exposure to how users experience the design informs the team on where they are currently. Creating an experience vision describes where they want to be. Continuous learning happens when the team experiments with moving the needle from today’s experience to the one in their vision.

Keeping users at the center of the discussion is essential for becoming design-infused. If everyone, including the most distant of influencers, are involved in those discussions, it’s hard to avoid making a better user experience.

None of these steps are expensive or complicated in their own right. However, for organizations that didn’t start with these steps in their basic operating procedures, the shift to new behaviors can be challenging.

It’s worth the effort, as the returns from embracing these steps will dramatically increase the experience of using the organization’s products and services. Better experiences result in significantly more customer delight, which increases the word-of-mouth marketing that drives more business. It’s a virtuous cycle with a high return on the investment.

Preparation is key.

User Interface 21 is a conference tailored to raise your design practice to new heights. Join us in Boston to gain the super powers to tackle today’s most challenging design problems.