Build Scalable Design Systems

November 2, 2017

Design Systems are critical tools for organizations to use to create a cohesive brand experience across products, devices, and platforms. They also allow teams to work more efficiently and quickly. However, the structure and maintenance of the Design System you create will determine its ultimate success.

Your Design System should be a living system that is relevant, flexible, and allows growth over time, and for that to happen, you need to have busy teams across the organization invested in its success. How do you do that?

As a starting point, Design Systems need to have a champion in management who gets it. Who understands the long-term value of creating a design system, and what it takes to support and sustain it. More companies, like Google and Airbnb, are releasing their design systems and pushing their business further in innovating ways.

A centralized team to manage your design system is a useful first step, but will fall short of success because of a lack of connection to other teams working independently. If teams aren’t invested in the success of the system, it will fail.

In addition to a centralized approach to maintaining a system, design leaders across product teams need to be identified and empowered to maintain the integrity and relevancy of the system. This federated approach in combination with a centralized group who maintains the systems creates a foundation for lasting success.

Make critical design changes in one place that seamlessly unfold everywhere.

Scenario-Driven Design Supports Team Alignment

October 27, 2017

What are user scenarios and why are the useful? To begin, they are based on real data, a firm understanding of your customers and their habits. With a scenario, we take that data and inject it with life. We can imagine, given a specific set of criteria that is based on what we know about our customers, how they might behave in a situation with our products.

Scenarios can help teams reach the brass ring of team alignment. Teams visualize potential problems better by using them. And more importantly, scenarios help product managers understand product requirements, designers to influence those requirements, and engineers to get a very clear sense of what the requirements are aiming to do.

Scenarios minimize gray areas where teams can fall into confusion about what the product is, how the customer may respond, and what the product goals are.

These days alignment doesn’t extend to just teams, but to all departments, offline and online, across an organizational that touches upon the user’s experience. With scenarios, we can use the power of story to imagine our customer’s future experience with our products, illuminate our intentions, and brings groups together on a shared vision.

Only you can stop feature creep and design debates.

Get Your Complex Information Architecture Under Control

October 24, 2017

We all walk through life with different mental models for how we experience the world, the work we do, and the part we play in it. In the workplace, frustration develops when different mental models, different perspectives, clash. How do we reach an understanding?

When we deal with language and taxonomy, make no mistake that opinions and tensions can run high. Labeling and structuring content is a battleground, and people hold tight to their opinions.

It takes perseverance and a real love of solving problems to roll up your sleeves and dig into language to understand those differences, often held across organizational silos. Information architects uncover those differences by bringing groups together to collaborate and find common ground. IA’s find patterns in language, and help simplify language and prioritize content.

Abby Covert shares her list of seven enemies that hide out in complexity:

Familiarity (being too close to the problem) Looking good vs. being good Not admitting ignorance when faced with it Including more detail than is necessary Believing more colorful/flowery language is better Belief that a better, shinier (etc.) will fix your problems When the how is defined before the what (solving problems you don’t understand)

It's time to disentangle your confusing interactions.

Align Teams and Persuade Stakeholders with Story

October 18, 2017

The stories we tell in our work are drawn from real data, real people. They are not based on fanciful, anecdotal collections of assumptions. We learn about the why of our customer’s behaviors by doing the hard work, like the many varieties of qualitative research we use, including interviews, ethnographic studies, and more.

When we create an effective, data-driven story that encapsulates a certain experience, we can pull members of a team together toward a singular product vision. We can use stories to set up scenarios for teams to problem-solve around and address those pain points that our customers experience along their journey. We can use them to connect the dots between our customer’s experiences and our design challenges.

Get hands-on and creative with the stories you tell and analyze by using personas, journey maps, sketches, cartoons, and storyboards to find your customer insights, and bring teams and stakeholders to agreement with solutions.

Stop designing In a bubble.

Put Your Money Where Your Maps Are

October 10, 2017

Drop the buzzwords that prevent user engagement.

The boundaries between our offline and online worlds have blurred. The connective tissue between them is the liminal space we explore when we map out customer journeys. Why is it important for us to have a deep understanding of our customer’s behavior?

Because the customer experience, explains UI22 workshop leader Marc Stickdorn, is the new battleground. Businesses are losing billions of dollars to poor customer experiences every year.

Look to the airlines, everyone’s favorite punching bag these days. The airlines were once an industry that epitomized luxury, a pampered way to travel even for us schmucks in the back of the plane near the toilets. Flying has since devolved into an experience akin to a third-rate bus speeding through the Lincoln Tunnel in flames in a post-apocalyptic Stephen King novel, with complimentary stale pretzels.

How do we collect data to inform our customer journey maps? Research is often conducted with limited budgets and time. Don’t be dissuaded, explains Marc, from qualitative research because of these constraints. As teams, we need to know the right questions to ask when we define our research; otherwise, we’ll drown in data. Qualitative research provides the why in the data that quantitative cannot do. Make sure you’re observing your audience: their habits and patterns of behavior.

Zoom-in on those moments of your customer’s journey that are failing, that can be improved upon to heighten the customer’s experience, and your bottom line.

The Tension of Art and Science When Communicating Complex User Research

October 3, 2017

Art versus Science is the quintessential Left Brain/Right Brain cage match. But in reality, math factors into great works of art as much as developing a treatment plan for a patient could be considered the doctor's design.

Andrew Shipe is a developer at MEDITECH, a company that makes Health Records software. Through his research he found that medicine can sometimes be as much art as science, a fact that was getting lost in the cold, analytical research data. He discovered that telling stories helped to span that divide in understanding.

Kim Goodwin, Author of Designing for the Digital Age, joins us on this podcast to share her thoughts on Andrew's approach of using stories and how that is the first step down the road of scenario based research. Kim will also be teaching one of the full day workshops at UI22 this November 13-15 in Boston. For more information visit uiconf.com.

Transcript

Jared Spool:

This is the UIE Podcast. I’m Jared Spool.
It’s unusual to think of the practice of medicine as an art form, but, when practiced, it is as much a science as art to diagnose and treat another living thing. When you think of the characteristics of both approaches, they might appear at opposite ends of a spectrum: one grounded in data and logic, and the other more humanistic, empathetic, and emotional. A friend may ask, “does your doctor have a good bedside manner?” What they mean is, is the physician personable and warm, instead of detached and cerebral?
We make the same assumptions about the expertise needed to build products. Engineers and engineering solutions are mathematical, governed by logic, while design is more aesthetic and responsive to human needs.
Of course, these assumptions are wrong. Dynamic problem solvers use analytical and creative methods. Science and art are intertwined, but in design we don’t always practice it that way, or even recognize it to be the case.
A recent study published in the Annals of Medicine found that physicians spend six hours (which, in the medical field, is typically half of their working day) documenting patient histories and treatment, ordering medication, and completing other required tasks within their Electronic Health Record Software (which they affectionately refer to as “EHR”). This burden takes a toll: less time with patients, longer days, weekend work, and more time navigating complicated interfaces that directly affect the health of patients. It leads to physician burnout. Some practices even hire scribes to assist in documenting patient histories. It turns out that a lot of EHR systems lack a bedside manner.
When faced with a complex problem, like making an effective EHR system, how do we, as designers, merge the humanity of art with the cold, hard logic of science?
Andrew Shipe:I think the stories have been effective because it's kind of a personality. There's a protagonist, there's some kind of conflict, which is usually our system, for better or worse, and I think we can be the heroes and we can make a better outcome for that story.
They take the complex medical decision-making and turn it into something we can all empathize with. We want to fix it, we want to make a happy ending to the story. I think that's been really motivating.
I am Andrew Shipe. I'm a software designer at MEDITECH.
Jared:Andrew’s company, MEDITECH, develops EHR software handling everything from booking appointments with physicians to documenting patient histories, treatment, ordering medication, and discharging patients.
Andrew:As a software designer at MEDITECH, we do a wider variety of things than the traditional software designer, all the way from the user research, research analysis, through the UI design, and even facilitating usability testing. We have a lot of incentive to streamline these processes as much as possible. How can we share the research we're gathering a little more efficiently with our stakeholders, and with the people we report to, the people we work with. How can we make it more clear, what we've learned, and get everyone on the same page about what the problem is.
The current software looks like it was made in the early 2000s. There's no consistency between another Windows or Mac or now iOS or Android application...It's kind of just overwhelming and disconnecting even right from there. It's very panel-navigation-focused, so our particular software is written in a bunch of proprietary languages, and so it doesn't hook into a Windows application framework or Mac or anything like that.
When our team of designers read articles and discuss them or read books about design, a lot of it's like, "Oh, but you can imagine yourself as the user," and for a lot of these situations, you really can't. You can't just jump into the mind of an oncologist and say, "Well, how are we going to treat your stage 3A lung cancer? Oh, we're going to use four cycles of carboplatin for 21 days, and we're going to throw dexamethasone in there if you have a reaction to whatever."
Without that domain knowledge, even if you're a really good developer or designer, you can't necessarily jump in and say, "Oh yeah, you just make it work this way or that way." I think in the same way, you couldn't empathize with, "Oh, we're doing e-commerce. We're going to have you check out your order." Everyone's done that before, and you can say, "Well, I can imagine me doing this or my mother doing this," like the personas and the user workflows and stories behind them become a lot more important.
Kim Goodwin:In any design process, well any effective design process, there's several different activities right? First you have to build a shared understanding of what is the problem you're trying to solve and whom. Then there's the phase where you're generating ideas about how you could solve it. Then you go through a process of analyzing and iterating those ideas to shape what you're actually going to build.
Research stories are a way to build shared understanding on the team, because in most organizations all the people who need to understand the users to drive the decision making, can't necessarily go along on every user interview with you. Stories are a great way to bring them up to speed and using a tool that has emotional impact to get them to understand at a more gut level what you're seeing.
I'm Kim Goodwin.
I'm teaching a workshop on using scenarios to solve problems at UI22 in November.
Jared:Because Andrew’s team had trouble empathizing with the habits and needs of oncologists through the cold hard scientific facts, Andrew turned to the art of creating research stories. He found these stories were surprisingly powerful at communicating what his team needed to hear. Through collecting these stories, he and his team were learning new things every day.
Andrew:We were researching how oncologists dose chemotherapy, and the drug manufacturer will say, "You'd get 50 milligrams of this med per square meter of your body surface area," which is also a thing I had to learn about. They can calculate that based on your height and weight and all these weird formulas. Then the doctor I'm talking with says, "I like round numbers so we just round it to 100." It's like, "What?" "Yeah, it looks nicer, so we round it up to 100. Or it could be down to 95, or down to 90. It's fine." I asked him, "Does that meaningfully affect their treatment?" He's like, "Not usually."
That was just really surprising, I guess, in that we think of medicine, or at least I thought of medicine as, "It's very precise, it's weight-based, it's body surface area dosed, great. We do the math, you give them exactly that much, and the cancer goes away," but there's this level of art when they're fine-tuning.
Once we got into how complicated the dosing the chemo meds was, we were telling these stories about, "Dr. So-and-So rounds to a nice round number, but his partner doesn't like to. Then at this other site in Canada, they have to report to their government body exactly how much medication they use and what patient it was for. They're much more exact with what they do." We talked with the pharmacist, and they're like, "These meds come in single use vial so you have to throw away the remainder, but these other meds come in reusable ones so you can keep using out of the same vial." Telling all these stories helped us converge on the theme that dosing is really complicated, and there's a couple of different factors that play into what they may or may not expect the system to do.
Jared:Andrew knew stories like these would be really powerful. But getting stories like these is not easy. To uncover this intricate level of detail for his team, Andrew had to employ a time tested research tool: The field interview. Other tools, like surveys and focus groups, just wouldn’t cut it.
Kim:I find that field interviews are by far the most valuable. I think that tools like surveys assume that you know what questions to ask. Whereas in field research you actually realize that you didn't know to ask about something and really unexpected things come up. If you just go in with the sense that I need to figure out how oncologists do their work, and they use information in doing their work. That's the research question that you go in with because you don't know what you're going to discover. Whereas if you say, "Which tool do you use more often", you might be glossing over, by far, the most important issue might be invisible to you.
Things like focus groups? You'll get a little bit better but they're not in the context of use and so you get a lot more self reporting error. You get a lot more loudest person in the room dominating the conversation. You can minimize that with good facilitation but you don't actually start to see the behavior patterns. You don't realize actually there are three kinds of oncologists. That gets lost in something like a focus group.
Because we're looking for the detailed flow, and structure, and mindset, and goals all those things that we need to design from, you're going get a lot more of those out of the one on one interviews. Preferably in the context of use.
Andrew:I was out in an oncology clinic for about a week in January of this year. That's far and away the best research. I got to see so much. Our main method though is just a Skype or WebEx or Zoom call. I have questions and sometimes we can have them share their screen if there's not a lot of patient information. Then they can actually show us what they do.
Just a lot of research questions, "Describe how you think about this, how do you choose what treatment the patient gets, how do you dose medications that are by body surface area versus weight versus kidney function?"
Oncologists that I've talked with are busier than even the other types of physicians I've met with before. A lot of our customers are in smaller towns, rural critical access, and they're maybe the only oncologists for 100 miles. That's actually one of the things we've been learning more and more with this kind of redevelopment project is, it's really hard to go from patient to patient, then you get a phone call in the middle of seeing all these patients. It's like, "Why are they nauseous? What's the deal? Are they on a new treatment?" A lot of that goes back to the physician's own documentation. They'll have their own unique styles about summarizing. It could be a paragraph summary that they write up every time they see the patient. It could be the three places in the system they always check, say, "What's the cancer diagnosis, what treatment are they on?"
Going deeper, there's another story where a nurse had accidentally discontinued the patient's oral chemo meds because they didn't know what they were. Like, "Oh, you're probably not on that." I told that to the team after that call, in the same kind of story."If they see these two meds, they're going to think one's a duplicate and they might discontinue it." We were starting from the user's perspective instead of how should it work, what should it do, what's good for the system, stuff like that.
Kim:I think the most important thing that Andrew and his team did was get out in the field themselves, and not rely on subject matter experts to be an interpretation layer between them and the users. I think that especially teams dealing with enterprise software, whether that's medical or accounting or whatever it is, there's an over reliance sometimes on subject matter experts. People who may be experienced users, who are part of the product management team or something, and treated as user representatives. You don't get enough diversity in that person's point of view, and sometimes their point of view is distorted because they've been too close to the product development over time. They're great resources, but teams that think those people speak for users tend to develop pretty incomplete understandings of the world. Watching people use the software. That's the foundation of great scenarios and great designs.
Jared:Andrew was talking to oncologists and their staff and collecting great stories about how they were practicing their medicine. His next big challenge? Get the team to understand the artful nature of oncology work. For this, Andrew started experimenting with the art of communicating research results.
Andrew:Every couple of weeks, we have a design critique with our stakeholders. We talk about the research we've done and how it's shaping what we're working on next. A couple of months ago. One of the designers I work with, he started making comics to describe his research findings. He works on health care, I guess, quality reporting. It can be really dry. "Dr. So-and-So met this measure for 90% of their patients, but this other doctor met it for 88%." It can be difficult to get people interested or excited about it. I'm like, "Oh, that's really cool. Let's try it out,"
We had a physician that we talked with. She took a day off of work, but to prepare for her day off of work, she had to order treatment for her patients that would be seen by one of her partners the next day. To do that, she spent three hours at night the day before her time off ordering all of this treatment for, it was 20 or 22 patients. I summarized that into the comic. That was more of a trial to see how it went.
It went well. It got them in the physician's mindset. It didn't really hit me until a week or so later that we're talking about this ordering process, and they referenced, "Dr. So-and-So is going to love this because it's faster for her." The light bulb went off that, if this is something they're engaging with and internalizing, this is a much more powerful tool than me sitting there and talking about what we heard.
Kim:I've never tried the comic book illustration of research stories. I find that photographs actually work really well in some circumstances, or video for research stories. I think that when you are envisioning the future in a scenario, sometimes a cartoon can work well. In a way, storyboards are exactly that. Rather than single static sketches, a storyboard walks you through what's happening in the screen state as the scenario progresses. It's really helpful to use those in conjunction, I always do that. Whether it sort of takes a step back and looks at humans moving through space and what the layout of the physical environment is and so on, depends on the design problem. If you're doing something that's more at the level of service design, then cartoons of humans interacting with people and spaces and so on makes a lot of sense. If all the action is happening on the screen, then a storyboard of screens makes more sense.
Jared:In addition to trying comics, Andrew also used other design tools, like user journey maps to visualize data and draw out the human elements of the nurses’ and physicians’ experiences when they interacted with MEDITECH’s EHR system.
Andrew:The story map has really helped be our architectural plan, and these specific stories have added some interesting color to it. When we get to a part on it, we can say, "This pain point is because it took her three hours to order these meds," or, "This suggested feature in phase three is because we don't want people getting treatment without doctors signing off on it." The nice part about the story map too has been, having that all compiled from all the stories is, even though we're doing a first slice where maybe there isn't a functionality yet, or it's a manual process, the team knows that. We're kind of testing and thinking about things with that longer term vision in mind. The story has value now in terms of, it might be frustrating now, but we know we're going to fix it later.
Jared: Andrew’s research stories and journey maps were taking on a bigger role. They were revealing unexpected user behavior patterns and upending the team’s assumptions about how oncologists approached the system. And in a moment of artistic inspiration, Andrew incorporated his research stories into the team’s journey maps. Now, the team could look holistically at the environment and problems within it.
Kim:It's a way to say here's what we're seeing across all the different research stories we heard. It's a way to make sure that you got all the data you need from research, so I actually use journey maps as an interview coaching tool sometimes. And it's a way to say what tools are people using, and what information are they gathering, what decisions are they making, and where are the pain points in all of this? So journey maps are kind of a research analysis and communication tool in my view.
What I encourage teams to do is to aggregate all their different research stories into a set of journey maps that describe the typical cases that they saw based on the usage pattern. If you have a set of personas that are distilled out of what you've observed, they each get journey maps that describe how they go about handling different situations, what tools they use, what information they exchange with the system. Those then become analytical tools.
Research stories are a way to help get at people's gut and help them see oh there's a problem there. Journey maps are a great analytical tool for making sure you really understand all the nooks and crannies of the problem, and that you understand it at a pattern level and not just an edge case.
Andrew:I think it's really empowered the team, that understanding the user is not just the designer's job. It's something everyone encounters everyday. As a programmer, you find all these edge cases, you find technical limitations we didn't think of initially, and they have just as good of a sense as I do about what an oncologist is expecting and general workflows. They're equally capable of making a decision, and certainly the team needs to be on board, but making those decisions and putting ourselves in the user's shoes isn't just the designer's job. It's everyone's job, something everyone's capable of.
Jared:These days, medical schools are incorporating into their training art studies to improve the observational skills of future doctors. The schools want remind these students of the human element. They’re trying to balance the critical importance of observing and interacting, against the cold, hard practice of analyzing and decision-making.
Andrew and his team at MEDITECH drew on user experience tools to understand the problem better, to humanize and communicate the research they uncovered, and to acquire an understanding of a user experience for which they had no firsthand knowledge. Their practice is both cold, hard analytical and warm-hearted human-centered.
It’s this balance between science and art, logic and creation, analysis and compassion. We embrace a deeper understanding of a problem, take ownership of challenges, and are empowered to identify the right solutions.
The job of the designer is not unlike that of the oncologist. It’s part science and it’s part art.
This UIE podcast is brought to you by the UI22 conference that’s happening November 13-15 in Boston, MA.
This year we’ve brought back Kim Goodwin’s full-day workshop, Using Scenarios To Solve Problems. Kim holds the record of being our most popular and highest rated workshop of any of our previous 21 UI conferences. That’s because she taps right into what designers require to get great designs out: a deep understanding of the users’ needs and contexts.
If you need your team to have a deep understanding of your users, you definitely want to check out her workshop’s full-day agenda. You can do that at UICONF.COM. That’s U I C O N F dot com. Get $200 off your full-conference registration with the promotion code KIMPODCAST17 (that’s K I M PODCAST 1 7).
Now, if you haven’t been to U I E dot F M lately, then you may have missed our recently revived podcast show, the U I E Book Corner. In this show, Adam Churchill and I talk about new user experience books that should be high on every designer’s reading list. Listen to the U I E Book Corner at U I E dot FM.
This UIE podcast was written by Kathleen Barrett and produced by Sean Carmichael. We'd like to give special thanks to Andrew Shipe and Kim Goodwin for appearing on this episode.

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

How Designers Turn Into Design Leaders

September 27, 2017

It often starts the way it did for LaiYee Ho and Nick Stamas.

LaiYee, a UX designer, and others on her team at the home automation company Wink were frustrated by what they didn’t know about their users. She put together a guerrilla effort, with no budget, to visit people’s homes. She brought engineers with her.

“When we brought engineers into the home with us,” LaiYee told us, “it was the first time we were able to see firsthand how the customer was really using it in the environmental context. What did the homes look like of the people that were using our product? Who were the other people that were interacting with it?”

From these trips, LaiYee and her team discovered users of their products the team never knew existed. Those newly revealed users became the focus of new product development, and the Wink team saw substantially increased product adoption as a result.

By taking the engineers into their customer’s homes in a no-budget guerrilla effort, LaiYee became a design leader at Wink. That got her promoted to become Wink’s Head of Research.

Nick’s story is a little different from LaiYee’s. When Nick arrived at WeWork as a Creative Lead for their internal tools group, he found there had been little UX design on the products he was looking to support. (This wasn’t a surprise, as the Head of Digital Design had given him a heads up on this problem.)

Nick’s team wasn’t happy with the quality of work they were shipping. He told his team, “Hey, we need to do something about this. I have some ideas on how we can start to tackle this as a team.” From that, WeWork's Plasma design system was born.

By seeing a problem and pushing for a solution to fix it with no budget, like LaiYee, Nick became a design leader at WeWork. He’s now overseeing Plasma and heading up future work on the team’s design systems.

Design Leadership Isn’t Design Management

While LaiYee now heads up the research efforts at Wink, she wasn’t a manager when she became a design leader there. Neither was Nick when he proposed what became Plasma.

Management and leadership are not the same thing. Management is about making the team effective at their jobs. Good managers ensure the team has everything they need to get their jobs done. They shield the team from the distractions that might come from others, while ensuring that each team member is given a chance to do their best work.

Management is essential for a design team to succeed. But it’s not design leadership.

Design leaders are stewards of a design effort. In LaiYee’s case, she stewarded the efforts to learn more about Wink’s users. Nick stewarded the definition and creation of the Plasma design system. LaiYee and Nick weren’t managing, but they were definitely leading.

The only requirement for being a leader is to have followers. Managers need to be promoted, but leaders emerge.

Managers walk around with a sign on their forehead that says, “I can fire you.” They get action from the people who work for them through their role power.

Leaders don’t have role power to get people to act. They have to use persuasion to make it happen. For design leaders, they often do that by riding the waves of important priorities inside the organization.

Some organizations try to appoint design leaders with titles like Creative Director or Chief Design Officer. For these individuals to be true design leaders, they need to gain followers just like they would if they didn’t have the appointment. Their efforts to lead won’t take hold if their ideas and how they express them aren’t compelling enough for others in the organization to want to join in.

Where Design Leaders Find Their Support

Permission isn’t necessary. While some design leaders emerge after asking for permission from their management, many take the Grace Hopper approach of asking for forgiveness later.

Almost always, the new design activity has to happen in addition to the design leader’s regular (and not leadership) workload. This keeps the leadership activity small and economical. If it garners good outcomes, people see the results, and they encourage more of it. That’s where the followers come from.

The followers are responding to the leader’s passion for taking them in this new direction. The most effective design leaders bring an effusive passion to every discussion of making design better. People on the team want to follow them because they’ve caught the bug and want to see better designs emerge.

Leadership Is Easier With Air Cover

It also helps to have some executive support. When an executive gives public support to a leader’s project, they are providing that leader valuable air cover. This is where finding the organization’s priorities help.

In most organizations, there are really only five types of high-level priorities. The organization is either interested in increasing revenues, reducing costs, increasing new customer business (also known as market share), increasing existing customer business, or increasing shareholder value. (Shareholder value is essentially the long term sustainability of the organization. If the market conditions change, will the organization still be viable and grow?)

Knowing which priorities are currently at the top-of-mind for executives can help a design leader gain support for their leadership initiatives. Wink was focused on growing their market. LaiYee’s initiative to learn more about their customers was right in line with where they were trying to get to. WeWork wanted to speed development, thereby reducing costs for each application. Nick’s push for a design system reduced development time and costs.

Smart design leaders are always paying attention to the business, so they know how to frame their initiatives to meet the needs of the business. They find hidden champions by identifying who in the organization feels the most pain from the current poor design. (See A Proven Method For Showing The Value of Good UX for one method for locating hidden champions.)

Organizations Don’t Get Great Designs Without Design Leaders

Just having a person appointed as design manager won’t get the organization great designs. Design leaders have to emerge for that to happen. Those leaders have to formulate a vision of what great design could be for that organization. And they have to gain followers among their peers throughout the organization, and support from the executive team.

A design manager can be a design leader, but it’s not common because growing a design department is a big effort in and of itself. (This is why someone appointed as Creative Director position may not be a successful design leader.)

Design managers can use their role power to give support to the design leaders on their team. When a design manager tells their team, for example, to use a design system like Plasma, they are lending their role power to the design leader’s efforts. However, in the end, if the system isn’t well implemented or designed, it will not take hold, and any efforts to push it forward will fail.

An organization can have more than one design leader. In that case, the leaders need to work together for a common vision. Good leaders know how to express their vision to get everyone on board. They coordinate to ensure that everyone is pulling on the oars in the same direction.

If the design team is to have a lasting effect on the organization, it needs to develop and support design leaders. These individuals must be identified and nurtured. LaiYee’s and Nick’s managers, whether they knew it or not, were doing just that.

Smart design managers will make this one of their primary missions. They’ll identity the individuals in their team who have an inkling of a vision, and grow them into a solid design leader. Design leadership works best when it’s an intentional act of the design team’s management.

Design leadership is a hugely important topic these days. That’s why we’ve dedicated an entire track of our UI22 Conference Featured Talks to helping you become the best leader you can be. Hear insights from Richard Banfield, Kim Goodwin, and Steph Hay on the key steps to up your leadership game.

More Human than Human?: Designing a Conversational UI

September 21, 2017

You can draw a direct line in the UX family tree from User Experience Design back to Human Computer Interaction. What if we could make the “computer” aspect of that interaction, feel less like a machine, and more like a human?

Robert Sens, the Lead Product Designer of the restaurant reservation app, Reserve, sought to create a conversational user interface to help users get seated at restaurants. They settled on implementing a chatbot to simulate the interaction of speaking to a reservationist.

Steph Hay, VP of Design for AI Experiences at Capital One joins us on this podcast to share her experiences in crafting conversational UIs and her insights into Reserve’s approach. Steph will also be teaching a full day UI22 workshop on designing conversational UIs.

Transcript

Jared Spool:

This is the UIE Podcast. I’m Jared Spool.
When people think of artificial intelligence, it’s usually in terms of the T-800s and HALs of the world. Or in more real-world terms, Siris and Alexas. But AI comes in gradations of fidelity. Siri isn’t HAL, and furthermore a chatbot isn’t Siri, but all have a level of programmed intelligence. People encounter far more of these lower fidelity AIs on a daily basis than they may realize.
The interesting thing is, from a user’s position, these interactions are still very human. That manifests itself in your voice becoming more stern after the third time Alexa says “Sorry, I didn’t understand…”
Users are expecting a comparable experience that they’d have with a human. How do you instill that humanity in something like a Chatbot that handles restaurant reservations?
Robert Sens:The traditional mental model really was this choose and go, right? Instant gratification. A diner would choose a time that was available, and they would get that. That's a lot of what users were used to. What we were trying to do is have this request model. What this did was mimic what really a diner would do when they called a restaurant, they called a reservationist to say, "Hey, do you have any availability tonight for a party of two?" "Oh, let me check the book." That idea of opening up the books and that negotiation process of, "I can't seat you right now, but I could seat you a little later."
Unfortunately, with that traditional web interface, web flow, that idea wasn't coming off.
I am Robert Sens, lead product designer at Reserve.
Jared:Robert and his team at Reserve needed to find a way to emulate that back and forth, negotiation-style interaction that a user would be accustomed to when calling a restaurant.
Robert:A lot of our research was going into restaurants and observing how reservationists and how hosts interacted with customers, specifically on the phone, people calling and asking for reservations.
What really struck us as interesting is watching, again, this negotiation process that happens on the phone. It's very conversational. It's very fluid. No matter what way a diner comes in, what they're asking for, what their initial request is, there's always a way through a conversation to get to the point where you're either presenting them with what they want or potentially presenting them with an option they want.
A key part of moving toward this chatbot or moving towards that was, how do we capture this conversational dialog? How do we bring this very conversational experience into a digital world without it feeling too robotic? It has to be a little bit about that negotiation and having some empathy for both the restaurant and the user. The diner is coming in looking for a specific thing for a variety of reasonings, and that could be special occasions, it could be I just want to dine, but how do we serve them and give them what they want while also taking into account the restaurant needs, right? The needs for an ebb and flow of the night or the need to fill different tables at different times, not have everyone come in at 7:30.
Steph Hay:They're totally new UX challenges, like when you think about a beautiful sentence as it exists on paper and it explains everything you need it to explain and then you put it in a chat window, suddenly it feels off because the natural behavior in texting is often just the thumbs and emojis and Y for yes and N for no.
So you realize that a lot of the things you've come to learn in designing for GUI need to some degree be thrown out the window.
I'm Steph Hay. I'm the VP of Design for AI Experiences at Capital One. I am teaching a workshop at UI22 in Boston on designing for conversational UIs.
Jared:In a traditional interface, a user interacts with content on a screen and it’s a one way conversation. You put content out and users consume it, and it either works or it doesn’t. But opening the interface for a conversational interaction requires a different design approach.
Robert:There was a lot of exploration and iterative ad hoc research ... it sat in two different camps, right? One was, do we completely think about a different way to approach this reservation experience?
The other was, how do we build traditional interfaces starting out with just thinking about, are there different ways to structure this UI? Are there different ways to design around the problem and make people understand that this is a request and that this is how the restaurant works and there's value here because traditionally where you would just run into a wall, we're giving you the opportunity to get seated.
What we really found while testing those is that the interfaces that had more human language, that had more what felt like conversational or organic flows or organic process were resonating with people. That was an interesting aha moment. In retrospect, it seems slightly obvious that the process we were seeing in the real world is something that people were used to and that that would resonate with them. However, we didn't go straight to the chatbot first. We were playing with, again, interfaces, different copy on the screen, "Where are you looking to dine tonight?" Or, "How can I help you tonight?" Those things were really striking with the users we tested with and saying, "Oh, this feels good." "Yeah, this would be interesting."
That was the main catalyst for moving toward the chatbot and the conversational UI is, how do we mimic a human experience in a digital way while maintaining some of the human attributes of negotiation and understanding and staggered empathy, right? This idea of, I know what I want and I want what I want, but I know what you can offer, so how do we bridge the gap and make both parties happy?
Steph:In some ways it's automating the judgment of the booking agent. However, the work that has to go into that again, is so nerdy. We're all getting into some really deep discussions about how do you manifest judgment? How do you build judgment into a system so that it can actually serve as an intermediary confidently? Because we all have examples top of mind of where something was so automated that it completely cut the humanity out of the equation.
That is the last thing that any of us wants, but is in some ways almost the easiest to achieve is just the automation itself. The judgment is the thing that makes the UI, or the CUI in this case, the AI's, the intermediary, really special. That takes a lot of work to build into the constructs of the system that's powering it.
Jared:Those constructs lay the foundation for not only what the chatbot itself is, but also whether it has a specific voice, how it communicates with users, and what users should expect out of it.
You want to mimic the human interaction with a non-human entity. That can be a tricky thing to balance.
Robert:We had a lot of conversations, early on, about potentially naming this thing, a lot of the early Reserve branding or Reserve tagline was, "Your concierge for a better dining experience." However, the real dynamic here was, we as Reserve are working with you, the diner, on behalf of the restaurant. We don't really want you to understand this is a bot, and we don't necessarily want to name it, 'cause again, we're that middleman, we're the negotiator that's helping you work with the restaurant to get seated. We never revealed that we were a bot, I think for a number of reasons. Again, one, like I just mentioned, we wanted to be that voice of the restaurant. And two, we were offering a very discrete service that had a finite start and end point.
Steph:The end to end journey when you think about a service design, mapping that end to end journey, whether it is point A to point B conversation is absolutely essential for any thoughtful design process. In the case of a bot interaction, one of the challenges is that some end to end journeys are really short. They are someone looking for a single answer and when they have that single answer they are satisfied and they go away.
Being confident as a provider that that is effectively a success is tough because what you want to see is the natural reaction that you want to see these long conversations, rich conversations that prove that your design is "engaging."
Robert:I think a lot of the bots that name themselves are something that you can ask for at any time, like Alexa, I can ask it anything at any time, it's very on demand. It needs to have that human personality, whereas we wanted to be a little bit more of that middleware in between the restaurant and the diner. There's a little bit of an illusion there, right? Yes, you're talking to the restaurant, and are you talking to them or are you talking to us? How do we make that a little shadowy and a little interesting so that you feel like you're being taken care of? There's a potential for the restaurant and the diner to have that relationship. That was really the goal of facilitating better hospitality.
Steph:The foundation here is the brand and the voice that pre-exists that we want to manifest in this new entity that we hope takes care of a lot of the things that are sort of the day to day top of mind of back of mind kinds of use cases that might come in and out of your head as you're just going through your day.
Those are the kinds of daily behaviors that a bot is really well positioned to serve. The fact that it's always with you on your phone and that you can ask during a meeting where it comes in and out of your mind, that is the sort of always on, everywhere, accessible, 97% of people who have smartphones have used text messaging, that is the ubiquitous nature of designing for this interface.
Jared:That ubiquitous access added to some struggles for Robert and his team. Restaurants keep specific hours. Prior to the conversational approach, Reserve’s users weren’t sure what was happening with the app. The Reserve team had to gauge what users’ expectations were and appropriately set the context.
Robert:The factors we were working up against was this problem of waiting, right? Again, we were working with the restaurants directly. We were the intermediary between the consumer, the diner, and the restaurant. Inevitably, there was a slight bit of waiting time there, a little bit of context setting that we're actually talking to the restaurant. We, Reserve, are a company you're working with, but we're actually your conduit to the restaurant. You might have to wait, the restaurant could be closed. At primetime it might be harder to get in touch with someone. There's some context setting there.
A big catalyst for the conversational experience was that, right? How do we just set that context that maybe an answering machine or not talking to someone can't set. "We're working with the restaurant. We received your request. We really value it. It's just gonna take us X amount of time or a few minutes," or, "While you wait, what can we offer you? Are there other restaurants you may want to get into? Can we get you seated somewhere else? Being that intermediary and attempting to set context and help the user get seated either at the restaurant they want or a comparable experience.
Steph:The second layer is setting the customer's expectations when the particular use case is highly nuanced, highly contextual to the customer's behaviors or their goals or their particular financial situation or their geography for example.
It would reset the status quo, having the context and having the data available to us to be able to make decisions about what to say when to whom is almost necessarily a design challenge because we need to have restraint. We need to have empathy. We need to have judgment.
Jared:Humans are conversational. The majority of their interactions in any given day are conversational. Designing interactions to align with what customers have in their day-to-day activities and experiences can have some interesting effects.
Robert:We had a general idea of our flows. We knew the general dialog that a restaurant used on the phone, so I think a little bit of the assumptions we made around tone were potentially erroneous at the beginning. There is an interesting give and take on the phone, that immediate back and forth, and also a little bit of the context around talking to someone in person that, I think, lends itself to an understanding, on the diner part, that they're asking someone for something and that they're waiting for an answer.
In the digital world, that was also true. However, we couldn't be as punchy and direct with our dialog. We had to use a little bit of a softer tone, maybe a little bit more fluff, again just to make people understand, make them feel welcome, have a little empathy there, whereas on the phone I could be, "Well, I don't have that time, how about this time?" Obviously, we couldn't necessarily say it that direct. We had to say, "Well, unfortunately, we do not have 7:30, but we can offer you an 8 p.m." Again, adding a little bit of that fluffy dialog and a little bit of that voice that felt more like a concierge, felt more hospitable, was a learning that came quickly, but not something we had expected in the beginning.
Really, one interesting learning was just looking at the things that people said, again, after they submitted that request and they got to the point where we let them know they were waiting. A lot of it was very gracious, like, "Thank you," or like, "Great, can't wait to hear." Just understanding the impact of that experience, I think, could have really changed the way we potentially thought about structuring the whole experience, right? That goes back, not even just from the interface, but thinking about how that affects the business as a whole, right? How do we work with our operations team to better empathize with our users? Can we leverage that human tech experience in a different way to facilitate better hospitality, better engagement, or potentially even different experiences with the user?
Jared:Choosing the right tone can instill trust within your users. But like many decisions, there is a potential unintended consequence. Human nature is variable. Depending on where someone lives, or where they are in their life, they could have different expectations. And those expectations could be further complicated by the company’s brand or identity.
Creating an interaction that feels human while remaining universal brings with it some deeper questions.
Steph:You can't even imagine the number of variables, right? But like regional dialect is one example. Age, there's also the behavior that folks exhibit in channel. Like my dad, when he sends me text messages, he writes Dear Nooch, which is my nickname that he gives me. Then he signs it Love, Dad.
Every text comes from him like that, like it's an email and I love it. It's like my favorite. This is to some degree a business question more than it is a system question, at least at first, which is who are the audiences we want to speak with in a really complementary way and to what outcome? Because there are tons of research out there about a way people want to interact with other people and what they're drawn to. There's similarity bias, et cetera.
But interestingly in the research we've done so far there is a not actually so fine line between what a customer exhibits in their channel or in their behavioral language and what they expect from the language of their bank in our case. So if we started signing our emails Love, Grandpa Jimmy or whatever, that would actually raise a huge red flag for a lot of our customers. It wouldn't feel like the brand that they've come to know and rely upon.
Even though our system, we could, by looking across a variety of data, make some assumptions about how to go about speaking to that person because in the Midwest they call it pop and in the east coast they call it soda so therefore all of our stuff that goes to Midwesterners should say pop. Those are actually, interestingly, moments that from a business perspective start to enter us into conversations about how we're showing up differently depending upon those customers on aspects of our conversation that may not actually drive a deeper level of trust or connection.
On one hand you could argue that well yes, of course it would because it shows that we understand who they are and where they are and what language they use. This is a journalist thing. That too by the way, right? But on the other hand, if it gives somebody pause for a moment to say huh, that's interesting that they used language or I wonder why they did that, then ultimately it may not actually outweigh the potential benefit of the connection because it's actually raised into question why we were doing it in the first place. It's not coming across to that person.
So this whole field of anthropology, especially for bot systems, is raising both the sort of business brand trust discussion as well as a system level delivery discussion, which is how do we make sure that our language complements and builds trust with our customers versus just reflects what they use.
Robert:What really surprised us is how quickly things get extremely complex. As we're mocking up these Gator boards and these conversational flows, it's just amazing how much we're blossoming out into very complex storylines and how much conditional logic becomes a huge X factor of how we structure our flows.
Steph:It is a challenge to imagine designing a conversation that could go anywhere at any time. Everything that we know about information architecture and our human nature about that to put things in a bucket, to categorize things and make things fit together suddenly has exploded and everything is atomic level. Anyone can go anywhere. Sure, there are going to be some patterns, but designing the happy path is no longer the priority, you know? Designing UX constructs into a system that can handle any path and every path is a happy path is the priority.
Jared:User experience design is ostensibly, designing for humans. Humans are communicators, storytellers, texters, tweeters, and posters. Meeting users within the context of their normal methods of communicating creates interesting opportunities to allow them to stay within familiar flows while experiencing your designs.
Building conversational UIs, whether they are voice-based interactions, chatbots, or simply structuring your content in a more conversational way, makes designing for humans, a little more human.
This UIE podcast is brought to you by the UI22 conference that’s happening November 13-15 in Boston, MA.
I’m very excited about Steph Hay’s full-day workshop, Designing for Conversational UIs. She’ll spend an entire day sharing her approach to crafting compelling content to structure interactions that feel more like a conversation, whether you’re designing voice-based interactions, chatbots, or any kind of app.
You definitely want to check out her workshop’s full-day agenda. You can do that at UICONF.COM. That’s U I C O N F dot com. Use the promotion code HAYPODCAST17 for $200 off your full-conference registration.
Now, if you haven’t been to U I E dot F M lately, then you may have missed our recently revived podcast show, the U I E Book Corner. In this show, Adam Churchill and I talk about new user experience books that should be high on every designer’s reading list. Listen to the U I E Book Corner at U I E dot FM.
This UIE podcast was written and produced by Sean Carmichael. We'd like to give special thanks to Robert Sens and Steph Hay for appearing on this episode.

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

Exploring the User Experience With Scenarios

September 18, 2017

While journey maps convey the customer experience across all the ways customers interact with our business, scenarios are the next logical step: an extension of that story and journey. We use scenarios to take real data and imagine how customers might respond to new product experiences. It’s an informed, creative exercise that helps teams identify potential problems in a product’s vision, and find human solutions.

It’s not uncommon to go from research to an immediate decision about how a product should function and work, but that leap from research to decision lacks an important step: the use of journey maps and scenarios to translate research and behavior patterns into an informed plan that reflects the customer experience.

Written and sketched scenarios can explore how customers might respond to our product vision. They reduce confusion, create team alignment, encourage understanding and empathy, and help teams avoid scope creep.

Sustaining A Design System

September 12, 2017

A living design system will save your business money and allow your team to work more productively and cohesively across business units.

To sustain your design system, teams need to be invested in its creation and maintenance, and to be communicating and sharing their work across the products and experiences that everyone is building and supporting.

What strategies can you use to maintain those lines of communication across teams? Nathan Curtis recommends that regular meetings can be useful and productive, if they are structured well.

  • Schedule recurring meetings
  • Invite designers and leaders across the organization to share concepts
  • Prep speakers at those meetings on system-relevant challenges
  • Avoid tangents in the meeting that distract from the topic and purpose
  • Encourage designers to take what they’ve learned back to their teams

Make sure your meetings are relaxed, informal, and allow presenters to discuss their work and get substantive feedback from the group on how to maintain that consistent look and feel your system identifies and maintains.

Emergent Principles: A Rebel Leader’s Secret to Better Team Design Decisions

September 11, 2017

Many eons ago… In a conference room far, far away, a rebel team reviewed their latest usability test results. They’d been observing people starting out with the Empire’s latest operating system: Windows Vista.

These rebels were now focused on the improvements for what would later become Windows 7 Desktop. They saw how flummoxed and frustrated users new to Vista became when besieged by all the settings and configuration options necessary to get started.

In that moment, a new design principle was born: UX over knobs and questions. For their new system, the rebel team would focus on turning down the volume of questions and deliver value to the user without them having to configure things.

A few years later… At a different company, another rebel team had just come back from a series of field studies. They’d watched their customers interact with a recent version of their small business point of sale application.

As the rebels were comparing notes, the team realized they’d seen too many bugs in the deployed software. Many of the bugs they spotted while in the field hadn’t shown up in their own testing, so were new to them. They realized just how broken their QA process was.

In that moment, another new design principle was born: Polish before new features. The rebel team realized they had been so intent on shipping new capabilities that they hadn’t adequately finished the existing software. Bugs were getting in the way so much that users weren’t using newer features. By fixing the bugs, they’d be delivering new capabilities to the users with code they’d already written.

More recently… Another rebel team, this time deep inside a government agency, was working on a complex workflow for approving benefits. They’d watched their agency’s field officers using the management application and noticed the interface kept asking officers for information they needed to look up elsewhere. In essence, the officers were calculating and typing information from one computer tool into another computer tool.

And in that moment, yet another new design principle was born: Don’t force users to do things computers are good at. The field officers had compensated by developing spreadsheet applications and other tools to answer questions in the workflow interface. The rebel team was intent on inventorying those tools and building them into future versions of the benefits approval software.

The Best Design Principles Are Emergent

These weren’t the only principles these rebel teams created. In fact, each team created quite a few more, based on what they’d learned from their users.

The rebels didn’t create these principles all at once. The principles came about as the team was learning, often deep in the middle of their projects. The list of principles was growing and the teams were embracing each one.

These particular principles emerged. They usually emerged from user research. The team would see patterns of broken things in the existing design. At that moment, a team member would propose they create a new principle to guide their future design work.

Teams latch onto emergent principles like these. They keep bringing them up in design discussions. They frequently have debates, where they argue about the semantics of whether something is or isn’t covered by the principles. Is that a knob or another type of control? Should we give the user an option in this case?

These debates are healthy, as they help the team understand the subtleties and nuance in their designs. Their new understanding of these subtleties helps them solve the real user problems they observed. The principles make it easy to see and agree on what needs to be different in the design.

Emergent Principles Are Not Divinely-Inspired

There’s another type of design principle that’s very popular with teams. These principles come from a team leader or committee that decides, for the entire organization, what the best practices should be. Facebook, for example, has beautiful design principles, like Bring clarity to complexity and Be accurate and predictable.

This type of principle doesn’t emerge. These principles are often declared, as if they were handed down from a higher authority through some sort of divine inspiration. The team doesn’t get a say as to whether they apply or not, and there are few specific examples of how they’ll use this to improve their designs.

While emergent principles become living rules that teams embrace, it’s rare for us to see a team embrace any of the divinely-inspired principles. We never hear teams bring these principles up in discussions. It’s only the emergent principles we see teams bringing into their work.

The Empire likes its divinely-inspired principles. Rebels, on the other hand, want to make their own rules. They favor emergent principles.

Principles Move Teams From Good Design to Great Design

Emergent principles become tools for making tough design decisions. It’s these tough decisions that turn a good design into a great design. Yet, before a team can work on making their designs great, they first have to turn their poor designs into good designs.

When a team tries to improve a poor design, the principles become easy to identify. If their current design is unusable, they fix it until it becomes usable. If the design frustrates users, they redesign it until the design is no longer frustrating. The team doesn’t need more nuanced principles than that, because it’s easy to see how to resolve issues by watching the users.

This is where the divinely-inspired principles come from. These simplified principles, like Bring clarity to complexity, don’t need to be useful in the day-to-day work, when the team is still struggling to make their designs good.

Today, we know how to make good designs. Now we want to make great designs. We’ve outgrown the divinely-inspired principles. That’s when emergent principles pay off.

Emergent principles go beyond divinely-inspired principles because they are rooted in the problems the team identifies from their research. They are unique to every project, even in large organizations.

Where a Facebook-like company could have a handful of divinely-inspired principles to cover every project, the emergent principles will be specific to individual projects. The UX over knobs and questions principle is perfect for the Windows 7 Desktop project. It wouldn’t work for a Windows system administration or network management tool, where configuration and customization is a core part of the user’s job.

Emergent Principles Become Our Rationale For Future Design Decisions

During the Rebellion, the rebel teams independently work toward a common goal. They need to make decisions to move their projects in the right direction, often without communication with other parts of the organization.

Emergent principles are an instrumental tool for making all those decisions. A good principle tells the designer how to make the call, when it’s otherwise not clear. Should we do this or that? When we’re not sure, we look to our principles for guidance.

The principles are there to help us make future decisions. They become the design rationale we’ll use to explain decisions we don’t even know we’ll need to make.

When the government application team decided on the principle Don’t force users to do things computers are good at, they were making decisions about future functionality they needed in each release. The point-of-sale application team would use Polish before new features as their way of pushing back on delivering functionality. Once everyone bought into these principles, it became easy to make these decisions.

Because each emergent principle comes from research, there’s an origin story associated with each one. Users had a problem that the team will solve under the guidance of the new emergent principle.

If every team member knows the specific story (even better if they saw those user problems first hand), then they know why the team is making decisions to support the principles. It’s very powerful when a team member can see a clear, positive outcome from their decisions.

Emergent Principles Eventually Fade Away

Eventually, the point-of-sale application team will build out an improved quality assurance process. They’ll be releasing polished functionality quickly and efficiently. At that point, the emergent principle of Polish before new features no longer serves any purpose. It can now fade away.

Other principles will emerge to take its place. The team will continue to do more research, and see more problems. Some of these new problems will now be easier to identify because the design has improved. Those new problems will demand new principles to guide future decisions.

It seems heretical to suggest a divinely-inspired principle may no longer be effective. Yet, this happens with emergent principles all the time. They are specific to a moment in the product or service’s evolution and eventually fall by the wayside.

The most effective rebel teams know when it’s important to create a new emergent principle, and when it’s important to let it fade away. This ensures the current set of principles are actively helping the team turn a good product into a great product.

Design principles are best used in conjunction with a solid design system. At UI22, Nathan Curtis will give a full-day masterclass on Building Scalable Design Systems. In this hands-on workshop, you’ll learn all the essential steps to building a design system that you can deploy across your organization. Get in-depth details on this fantastic workshop.

Start Making Sense

September 11, 2017

We’ve seen the following words sprouting across interfaces before, sometimes across a single website: Become a Member! Partner With Us! Join Us! Get Involved! Volunteer! Make a Gift! Donate!

What is the distinction between a member and a partner, getting involved and volunteering, gifting and donating? It’s not uncommon for businesses to approach language organically, often using different words to mean the same thing.

Duplicative language can bloom easily within an organization across marketing materials, customer service, organizational silos, and eventually into the website’s information architecture. It goes without saying that lack of clarity in language is confusing to customers.

Shout out to the information architects out there, sifting through all that language.

Information architects need to get into semantic discussions with stakeholders and teams, to bring them together to find a shared vocabulary to describe what they do. The goal is for customers to know exactly what a business means when it says something. It’s easier said than done, but Abby Covert has tips on how to facilitate those messy discussions collaboratively and effectively.

About Face: How About.com Changed its Design Process and became Dotdash

September 7, 2017

According to Heraclitus, the only thing that remains constant is change. The internet itself has evolved exponentially over a relatively short amount of time. Few relics from the early days of the web remain, and those that have, have been forced to change. Adam McClean is the SVP of Product at Dotdash. Dotdash was once About.com. The very same About.com that has been around for 21 years. Adam and his team were increasingly aware that the landscape around them was changing, and that they needed to evolve. They made the switch to a new brand, Dotdash, and a new process, to keep up with technological and market changes. Dan Mall, who runs SuperFriendly out of Philadelphia, joins the podcast to share his views on the evolution of dotDash’s process in support of their new brand. Dan will also be teaching one of the daylong workshops at UI22 this November 13-15 in Boston, MA. He’ll show how to develop workflows for the multi-device world we live in.

Transcript


Jared Spool: This is the UIE Podcast. I'm Jared Spool. At night, when you peer into a telescope and look out into the solar system, you are in essence traveling back in time across light years. You are observing a distant past, even though it might feel like the present.Imagine, if you will, that you could travel back in time to 1999. You might not believe it’s possible, but Billboard’s hottest song of the year is Cher’s Believe. You’re a kind person. You’ve just rewound a few VHS tapes that you need to return to the video store. You’ve printed out some MapQuest directions for an upcoming trip. The news is going crazy over this Y2k thing, like it’s one of Nostradamus’ lesser-known prophecies of doom. You’ve pulled up Netscape and searched About.com for a guide on the history of nutty doomsday prophecies.
The Internet was still a baby in the late 1990’s, or maybe more of an inquisitive toddler. In the age of web portals, About.com was king. It was the perfect model for its time, offering informational guides and articles on all sorts of subjects. But like all things, the site grew older, and bigger, and so did the Internet. And now our time portal is getting shaky and collapsing.
We’ve returned to 2017, and portals are a thing of the past. The Internet is in its snarky, know-it-all 20s now. The only constant we have is change, and for change to take place, we need to believe it’s possible.
Change is what About.com needed. The site had millions of pages of content, an outdated technical infrastructure, and still millions of daily visitors. But it hadn’t grown up. It needed to evolve.
Adam McClean:We took a hard look in the mirror and said, "What do users really want? The brand is 21 years old. It is older than Google. Everyone has experienced it in some fashion when it was a portal and heavily monetized with text ads. That is the perception regardless of what we did now. That is perception that is going to carry through.
We were all desktop oriented because we are on desktops at work, and so the designs would start there. Our competitive analysis would start there. Despite user research and then analytic showing that the majority of our users are on mobile. I just knew in my gut something had to change.
I am Adam McClean.
I'm the Senior Vice President of Product at Dotdash.
Jared:After updating the technical infrastructure, investing in people and skills, and doing all of the typical market and user research, About.com realized it needed to break its brand into six, unique theme-based sites with content from lifestyle to travel. These six sites live within a new parent company, called Dotdash.
Adam:We killed over half of our content, redirected millions of documents to the right corpus for each vertical and then went through this product development methodology change and built the brands in 12 to 16 weeks and launched them in the market and we're seeing phenomenal growth.
Jared:Building and launching a brand in 12 to 16 weeks sounds challenging to say the least. But for Dotdash, it was the culmination of a process they’d been working toward for years.
This process prepared the business to adopt a product methodology for rapid development. But it took time to get there. They started out like a lot of companies that want to embrace change.
Adam:We thought of ourselves as very traditional, agile oriented. We did two week sprints, we did the agile manifesto, we did scrum and stand ups. We still do all of those things. When it came to executing something where visual design was a component, it was a handoff. It was also a handoff between product managers and the engineering teams which is also a small mini waterfall where we gathered every requirement possible and then handed it off into small bite size stories.
We would iterate again and have feedback from a number of stakeholders and team leaders. We would be measuring things in weeks at this point. We would be at least a few weeks in. Then, we'd come up with the final design. It would most likely be desktop only and then we figure out what it should look like on mobile with another pass and then it would be specced out. Red lined, specced out, every color hex value, every pixel, font size, every piece of it, and then hand it off and estimated in engineering team who would then go and spend weeks executing it.
The time that it took to get to consensus for a design that had no code against it and was not actually evaluated in the real world, in the browser. The time and the amount of revisions that it took for us to get through those design reviews was painful when you actually look at it in a macro sense.
Dan Mall:In a lot of large companies, they are very siloed. Everybody has their jurisdiction, and they don't realize how connected their experiences are supposed to be. They just think we can operate in our little silo. And more and more, digital experiences are connecting consumers and customers. And if I'm using the website, I might also be using the mobile app. And if I'm watching a commercial, that's how consumers deal with brands, but brands don't organize themselves in that way.
And I think the spoiler to this process is it's got to be collaborative because people experience things holistically. People experience brands holistically even though brands aren't setup that way.
My name is Dan Mall.
I run an agency in Philly called SuperFriendly.
At UI22, I'm teaching a full day workshop on Design Workflow for a Multi-Device World.
Jared:Dotdash hadn’t organized its teams to work in a holistic, collaborative manner. To get their teams on the same page, Adam started with a component audit. It’s a simple exercise that measures how consistent their visual design is across their sites.
Adam:Our engineers found eight versions of a Facebook button in code and eight different designs of it as well on one site that should be consistent. That was also another light bulb moment of wow. Both from a design system standpoint, we need the consistency and the code standpoint, why weren't they able to reuse components? Why wasn't the architecture actually setup to make things reusable as opposed to one off specific isolated incidences.
We had a couple of engineering teams that could develop on the site. We had a handful of designers that could design various projects and they were just assigned to the next thing on the roadmap. No one was taking ownership of a responsibility for the full design system. It was, I'm tasked with this job to be done or this persona for this product piece that I need to develop and you locally optimized for that. They were some branding and some colors and some global things that we always try to be consistent with. When you got down to the actual code, things were different. Things could be coded very differently locally and so it was up to the engineering group and the designer at that time. They didn't have tools to see that the Facebook buttons were all different. No one was looking broadly. We didn't have a pattern library developed. We didn't have any of those tools to help us avoid some of those pitfalls.
Jared:That light bulb moment for Adam and his team was the lack of communication between groups, and the wasted effort of redesigning elements that should have been re-usable. They realized they needed to restructure and rethink how they worked together from the ground up.
Dan:With Agile, you can break down things into small chunks, but the problem is when you break things down into small chunks, people can work independently. And the thing that was really missing there was, and really part of the thing that we try to encourage more and more, is okay, let's sit together and work this out. So rather than a designer breaking out a small chunk and doing that work and then a developer or an engineer breaking out that small chunk and doing that work, instead we were trying to encourage them to go, "Let's sit together and do those small chunks of work together in front of a whiteboard, in front of a Sketch book, and talk about those things."
Adam:That led us down this road of trying to implement some change in methodology that was closer and would use that component based design structures and systems. Then we were tasked with re-branding into Dotdash and we said, "Well, this is the best playbook that's out there right now. Let's give this a whirl."
The whole team, product, design, engineering are working together collaboratively throughout the process. The amount of energy and time spent for each discipline changes from beginning to end but everyone is involved and everyone has input throughout. There isn't a spec sheet or requirements list that literally gets handed to somebody to then go design or to go engineer.
Jared:That playbook that Adam and his team chose was a designing in the browser, Atomic design approach. They looked at their design elements to create a library of patterns and components they could re-use. They restructured teams around each new brand to work collaboratively and cross-functionally.
Adam’s teams would now sit together to design and build elements and get them into the browser as quickly as they could to view, test, and iterate. And they did it all without defining product requirements…
Dan:Almost every organization I work with has this where we have to spec it first. And we have to spec it perfectly. And then as soon as we spec it perfectly, everybody can do their jobs after that. And I think that is a common misconception in doing software work because people that are doing software work, engineers and designers, they all have great ideas that can contribute to the work. The whole idea of Agile is the idea that you can flex. You're flexible. You're not following a plan, but instead you're responding to change. When you spec first, there's no ability to respond to change because what you do is you destroyed the spec as soon as you flex off the spec you destroy it. And a lot of teams see that as detrimental.
Usually the person writing a spec is a product manager. And a product manager isn't as intricately familiar with the engineering or with a design technique or with a way to build something or responsive images or whatever those things are. So if one person is responsible for the spec, they have to know everything about a project and about a product which is very unlikely. Instead if you're using the smarts of the team rather than the smarts of one person, you get a lot more ideas. You get a lot more riffing, and you get a lot of people to go, "Oh, don't worry about sketching that out. I can actually just do that in the build" or "Don't worry about even building that. Let me just do a little prototype for you so you know what I mean." It's an opportunity to save other people work whereas if you're writing a spec, you don't have to talk and then you end up doing that rework all at once.
Jared:Old habits die hard, and teams like Adam’s are accustomed to working in a specific way. It requires a leap of faith to fundamentally change how you do something. Dotdash experimented with their new methodology by first running a test project.
Adam:We did a special cross-functional, atomic design approach project for something that was a very specific one-off product. We were building our new map product for our travel site. It worked effortlessly, flawlessly, everyone across the entire spectrum of the organization really liked all the pieces of the process and how everyone was energetic about it and final outputs of everything from the time to market. When it came to trying to tackle six vertical brand build outs in a year, we felt like we had tested a playbook that would work but we had to shift the entire product development organization into this world .
Dan:You've got to have at least some amount of risk tolerance to say, "It's okay if this is a flop. It's okay if this doesn't work for us." [So] I find it more difficult at organizations that aren't willing ... that are just so tightly held to their previous process that anything new is such a big deal. If they're not ready to embrace the change, then this is probably not the right time for it. And I think timing is a big aspect of this kind of process. The organization has to be ready for it. The people that are going to be working this way have to be willing to do it, willing to try new things, willing to learn new things.
Jared:Time to market and risk mitigation were critical pieces for Adam and his team. They were on an aggressive timeline to launch the six new brands. Teams didn’t know what the final product would look like, but they had to start coding and designing. In a browser-first approach, rework happens throughout development. That was another thing the team had to get used to.
Adam:There was some resistance. At the end of the day, everyone really had positive feedback. The market liked it. The engineering and design and all the teams liked it. There is some resistance to this concept of feeling like there is rework. You code something up, you guys get it working, and then you see it, and you need to adjust it a little bit. That actually means everybody throughout the entire cross functional sec might need to make code changes to make that small change happen. That was a frustration point that we had to work through and talk about and deal with especially on the engineering side to get to a place where everyone understood that rework was possible, rework is going to have to happen. Instead of forcing all of the rework up front to the designers who were used to doing multiple revs, we spread it out and made time to market a priority.
A good part of it was being able to show everyone involved with the project how much better the end result was, and that instead of trying to make things perfect at every step you actually get something better faster if everyone is willing to be flexible and iterative in the moment. This was actually hard for our agile managers and scrum masters to fit into the traditional scrum model. We had to develop ways of basically time boxing some of this iteration. They always want to put points, they want to be able to track it, they want velocity, and that's all really helpful. But what it doesn't do is it doesn't always give you the exact flexibility. You have to have some gray areas, some unknowns and be comfortable with that and know that your team can work through them in the time allotted.
Jared:Not only did the team have to become comfortable with the unknown, with those gray areas, team roles blur in this methodology. It can be a challenging adjustment, especially for designers and engineers.
Adam:In the old mini waterfall model, the designer as the last piece would be thinking through, "Well, when they click on this, what is the IA? What is the open? What is the hover? What is all those little pieces?" Now we just go straight to the browser and we do the ... "This feels weird, why isn't it reacting the way I want with my mouse? Oh I know! I can do a button hover state." The engineer goes in says, "Yeah, I fixed that. It felt weird when I was building it so I just put it in for us to talk about."
They are designers as well. They're thinking through user interaction and hover states. Everyone is empowered but especially the engineers are empowered to ask, "Is this new or are we reusing something we already have because I can reuse something right now and then you tell me if it's working or not." We start from what can be reused, throw all of that on a page or the template, whatever it is first, and then try to figure out what's not working and figure out what has to be net new.
We, now, because we call it designing in the browser, we think of everybody on the team as a designer in a different way. They all have ideas and thoughts and they're all users of the web. They're all users of our sites luckily enough that we're so broad that everyone has a need for something that Dotdash can provide. The actual traditional designers, the ones that design tiles are coming up with concepts in sketch or in vision and they're trying to use real data to actually make it feel as real as possible. They get about 60% done. Then they put it in code and the engineers have a chance to play with it, break it apart, and actually design some of the UI and the interactions that this 60% done probably hasn't uncovered, hasn't really thought through.
Dan:I think one of the first parts of a process like this is you've got to break that down at least a little bit. Because in designing in the browser, who does most of the design? The front end developer. And that's often a new role for the developer because what a front end developer is used to is, "I get a comp and build what's in the comp. I faithfully reflect pixel perfect what is in that comp." Now all of a sudden you don't have a comp. And so it's a distribution of roles. It's a distribution of the effort, and so it means moving a lot of the designer's work to the developer.
And designers have a lot of fear of that, too. "Well, okay, if they're doing all the work, if they're doing all the design work, well what am I doing, too? Am I useless here? Am I redundant?" And what it means it's actually moving some of the development work to the designer. So that could be something like managing a design tokens file or managing a JSON file. So that the developer can work on things, and the designer can tweak colors to their heart's content. That's a very different kind of work flow than they're used to of "I'll figure everything out in Sketch, and then I'll figure everything out again in front end dev, and then I'll figure everything out again in engineering." So a lot of it almost requires breaking down these roles, and saying, "Even though your title is front end developer, you're going to be doing a lot more design work. Even though your title is designer, you're going to be in the code tweaking CSS values a lot." So a lot of it is just getting familiar and comfortable with that idea.
Adam:For the engineers, I also think there was some challenges and some friction with encouraging to have ideas and input and not just thinking through execution but actually thinking through discovery and solutions and how what we were building matched to the brand promise and design principles. These things that are usually off for the designers to talk about or off for the product managers to think about with marketing, we involve as much as we could all of the engineers in developing our onliness statement. What is our competitive positioning for these new things? What is our manifesto going to be? How are solving problems for users so that they have that information when they go to make design decisions in the code? They were exposed to things that we never exposed engineers to before.
Dan:A lot of people's identity is tied to their roles. They spend so much time at work, and one thing that's great about this industry is people love what they do. So they tie their identity a lot to this role. And if that role disappears or if that role changes, does that mean your identity changes, too? If you are the senior designer at a company, and all of a sudden somebody else is doing more design work in the browser than you, are you less valuable? So there's a lot of baggage that comes with that. And so I feel like any good consultant, a lot of your work is therapy. A lot of your work is getting people comfortable with this and making sure they're okay with it, and making sure that they're not losing themselves in their job or they're able to separate those two things.
Adam:Some people were very excited and very happy about it and some of them had experienced it at previous work environments and craved it. Then there were other people who thought, "This isn't the best use of my time. I should be coding right now. That's just what I want. I want to be a heads down engineer." But we have, I think, done a very good job of helping people see the value. Once they go through one of these, we did, everyone had to be a part of at least one if not two big vertical brand builds. By the end of it, everyone really understands the value and appreciates they're involved.
Our designers are now actively managing the pattern library, which they are able to commit code changes to our pattern library product. Our engineering or architecture actually auto-generates the pattern library from the components that are in the code. Then there's an orchestration and organizing structure on top of that that the design, everyone can, but mostly the designers take ownership over constructing and organizing the components in the pattern library.
Without this new working methodology, without the actual architecture that we helped to develop to make things, components and auto-generate pattern library and support this new design system, it's not just the design system and methodology. It's actually baked into our architecture and code now. Having all of that work allows us to launch some new verticals in weeks. We just launched liveabout.com which is our fashion, style, small, very seventh vertical, in three weeks start to finish.
Dan:I think one of the biggest things that they need is permission. I think sometimes you need someone to go, "You can do it. Give it a shot. And if it fails, it's on me. I've got that." And I think any good manager or any good consultant or boss, I think that's part of the job is to be able to say, "I'll give you a little bit of a safety net to try this." And again going back to that test bed or that experiment time, it doesn't have to be, "I'd like to try something for the next two years." It could be, "I'd like to try a process or a technique for two weeks and see how that works." And then if it doesn't work, we adjust or we revert back. But sometimes just giving people the permission to go, "Yeah, you should do that. I think that's good." I think gives them enough of a confidence boost to be able to do it.
Jared:There is no measure that we can use to tell us what the future holds. If we swap out telescopes for Magic 8 Balls, we get a “Reply Hazy, Try Again” as often as we get an “Outlook good.” It’s hard to believe in the weight of those responses.
We try to predict future outcomes so we can control them, mitigate risk, and feel safe about the choices we make. We often interpret change as something scary, hard, and involving a level of risk. But if we aren’t willing to change, change will come to us, eventually.
Adam and his team learned to believe. They created a level of trust for designers and developers to work in this new model. They fundamentally changed their process, how their teams work, and their business. They got permission to experiment, and they controlled risk by seeing things right away, in the browser, and course correct throughout their work to guide them to a successful place.
This UIE podcast is brought to you by the UI22 conference that’s happening November 13-15 in Boston, MA.
I’m very excited about Dan Mall’s full-day workshop, Design Workflow for a Multi-Device World. He’ll spend an entire day sharing his proven approach to taking designs from concept, all they way through delivery, across multiple devices. It’s a great way to quickly get your applications delivered while delighting your audience with the functionality they’ll love.
To learn more about what you’ll learn at Dan’s workshop, visit Uiconf.com. That’s U I C O N F dot com. If you use the Promotion Code DANPODCAST17 (that’s all one word DANPODCAST 1 7), you’ll get $200 off your UI22 registration.
Now, if you haven’t been to U I E dot F M lately, then you may have missed our recently revived podcast show, the U I E Book Corner. In this show, Adam Churchill and I talk about new user experience books that should be high on every designer’s reading list.
In a recent episode, we looked at Brett Harned’s wonderful new book, Project Management for Everyone. At some point, every designer finds themselves managing a project. Adam and I talk about why this book contains the critical knowledge necessary to succeed. Visit U I E dot F M and click on Shows to listen to the U I E Book Corner episode about Brett’s book.
This UIE podcast was written by Kathleen Barrett and produced by Sean Carmichael. We'd like to give special thanks to Adam McClean and Dan Mall for appearing on this episode.

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

Service Design: Creating Delightful Cross-Channel Experiences

August 31, 2017

Our understanding of customers—their behaviors and needs—has grown more sophisticated, because the experiences we design demand it. Our customers routinely dip in and out of contact with our products, both offline and online. They reach across channels to contact us, to share their experiences. They fall short of converting at points along their journey. What triggers these behaviors and why? It is in those unexpected moments that we fail the customer. As designers and digital professionals, we work as detectives, sifting through data, both qualitative and quantitative, to understand, define, and create the ideal experience.

However you want to call your process, whether it is design thinking, service design, customer experience design, or Lord Buckethead Supreme Intergalactic Design, your task is to explore, prototype, and test assumptions, communicate across organizational silos, and reach agreement over what that ideal experience is.

Systems and Stages: Building a Design System and a Systems Team

August 15, 2017

Design systems can organize and clarify a team’s design practice. Made of patterns and component libraries, they add a level of cohesion across designs. This, of course, can only occur once you have a design system in place. So how do you build one in the first place?

Nick Stamas, the Creative Lead on the Business Products Team at WeWork, set out to do just that. He surveyed WeWork’s existing designs, noting inconsistencies, and pitched the idea of a design system to help streamline the work being done. His challenge was building this all out while WeWork continued to grow.

Nathan Curtis, author of Modular Web Design, has identified stages that occur when implementing a design system. He shares his insights into Nick’s story and how you go from building the system to working as a systems team. He will be joining us in Boston, November 13-15 to teach one of the daylong workshops at the UI22 conference.

Transcript

Jared Spool:

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

Developing a design system is a process. If your organization needs a design system, where exactly do you begin in that process?

Nick Stamas:When I got to WeWork, I looked at the state that a lot of the products were in and there are multiple products even internally. We saw what you hope not to see when you come into a new job, which is that there had been very little UX or design thinking on the products at all. These are products that have mostly been built by developers, de facto design, as I call it. Everything is designed. It's just who’s actually making the decisions?

You had a lot of inconsistency. A lot of people have worked on it in a very rapid fire way. Some people had come on and off the projects and things like that. It was a worst-case scenario in some ways. There was pain that was felt both internally on our team, of course, and then obviously our users, which are all employees of WeWork.

My name is Nick Stamas. I work at WeWork. I am a creative lead on the business products team.

Jared:Inconsistencies create pain. This pain was felt not only by the employees using WeWork’s internal applications, but also amongst the business products team. Mockups were becoming monsters when they were translated into code. This was creating some friction amongst the team.

Nick:We would hear a lot of negative feedback. There was I think at one point mid 2016 last year, the team said, "We need to do something about this." This is not going in a direction that we like. We have to move very quickly. WeWork has very interesting needs, as far as scaling very quickly. That can be an enemy of quality a lot of times. We said, "Hey, listen. None of us are happy about the quality of the work that we're shipping here." That was kind of the foothold and to start to say, "Hey, we need to do something about this. By the way, I have some ideas on how we can really start to tackle this as a team." That was where I started to really pitch the idea for design system that became Plasma.

What I did initially was to start laying the ground for it and the seeds for it politically. This is where we started talk about selling the design system became such an important thing. This was not a team that had really had a whole lot of experience with design systems in the past. It wasn't really part of our DNA because the department was maturing. This was a relatively new concept.

We were operating with a very small team. We were just tasked with moving very quickly and that's just the hard spot to be in. Instead of shrinking from that challenge, I said, "A design system is not a silver bullet." It's not going to solve all of our problems. It's certainly something that if we can make an investment into it right now, I promise you that in a year we will be in a better place.

Nathan Curtis:What I typically see are, first, when a system starts to take shape in an organization, and it's endorsed by a designer or an engineer trying to do the right thing and be meticulous and organize their work, and they often make good inroads convincing their team.

Successes occur by having this system work being exposed in the products they have.

I am Nathan Curtis. I work at EightShapes. I will be teaching Building Scalable Design Systems at UI22 this November.

Jared:For WeWork’s design system to start taking shape, Nick started taking stock of their existing designs. This led to developing new approaches to how they had previously been designing. Lucky for him, he wasn’t alone.

Nick:Andrew Couldwell, a coworker, he started around the same time that I did at WeWork. There was just this confluence of events that gave us the opportunity to really to start to think about what a design system would look like at WeWork and almost seemed a gift from the universe. You don't generally get this opportunity where he was freed up at the exact moment that I started to get some buy-in around being able to do a system like this and to really go after something that was a little bit bigger and more ambitious than anything that we had done before.

We started the project by just taking a survey of the existing stuff. There was a certain set of things that we needed to make sure that we had all of our bases covered.

Then we started to see some patterns that had naturally emerged for better or for worse. Some of them were good patterns maybe. Some of them were not so good. Then we could start to sort through and say, "We like what's happening here and we don't like what's really happening here. Let's pull the best of that stuff and bring it in, and start to patternize it."

None of this work had been done at WeWork Digital.

Generally what would happen is product and design would work together to come up with just a very initial spec, break down of the problem or the feature. We would very early on loop in one of the lead developers, talk about what we want to do and how we want to approach it. When it came to actually getting down to designing something, there was no system. It's just you look at what's there and you try to do your best to match so that it doesn't feel completely out of left field.

Then at the end, you hope that something comes back out the way that you put it in and you know that's just almost never happens. It was frustrating.

Jared:As Nick dissected WeWork’s existing designs and identified patterns, things began to fall in place. He gained a foothold with his stakeholders. Through this work, he demonstrated to them how to approach design in a systemized way.

He had unconsciously reached the next stage in his journey.

Nathan:There are stages of growth of a systems team that I talk about and the terms I use is, stage one is spare timers, people fighting the good fight and incorporating it into their own work. The second stage is allocated individuals, where their management is carving time out of their day for them to do the work.

Nick is doing a lot of work and he's got deep relationships with engineers is a person that is seeing the rigor and the success that organizing your work around a systematic mindset can bring, they start to organize their own product, they start to deliver their work.

That is usually clear to me that some manager, say a designer's manager or an engineer's manager, recognizes the quality of that systems work and starts to allocate the time of that person to work on that stuff.

That person becomes the point person. They start to develop the reputation with their organization. They start to be the person that everybody's head turns to in a design critique to answer those questions and actually catalog the decisions the organization makes over time. So they're recognized. They have a recognized authority within their field in their org.

Nick:We started to say, "Here's our opinions on how we think the digital product be built." Then we started to get into Sketch and build out everything that you would expect, buttons, inputs, all that kind of stuff but then starting to think about slightly higher level components, too.

We looked at one app that is the beefiest of the apps internally. That was an existing app that we did an audit of. Then we basically took that and redesigned it using this still nascent experimental design system to make sure that like, "Hey, is this going to actually cover the cases that we needed to cover," forcing ourselves to stress test essentially the design system.

The promise of Plasma was that by developing a shared language between design and development that we would be able to continue to move quickly but start to ship higher quality work. In a sentence, that's what it was.

Jared:As Nick led the way, he continued to build and sell the idea to WeWork’s team. More importantly, he demonstrated how the Plasma system could not only address the minimum requirements of their existing apps, he showed how it could scale and flex across all of WeWork’s internal properties.

Nick started to see his team adopting the new design system, and whether he was aware of it or not, the team was rapidly approaching stage three.

Nathan:When you expand to that third level, it might end up having increasingly specialized people beyond the core of designer and engineer.

That third step, when you have a system team as a product team, can take a range of sizes. The smallest might be a pairing of designers and engineers, and, implied in that, a designer and or an engineer takes the mantle of product management, but sometimes stutters along with it because they don't have those skills sets. They don't understand how that discipline works. But medium-sized discipline teams, which is the kind of rigor that we bring when we're consulting is, you have an identified product manager, project manager, and scrum leader. Those are three other kinds of responsibilities on teams. Often times I'm doing all three, but at least it's recognized that, in terms of how a team operates, you have those things at play.

Jared:WeWork was growing as the work on Plasma continued. Nick had always been selling the idea to the existing team, but new developers were coming onboard. Those new developers were lacking some crucial information.

Nick:I realized this sort of job of selling and bridging that gap between where you are now and where you want to be ultimately doesn't end. It's not something that is this one time thing. It's something that really has to be this ongoing process.

We've had some interesting discussions. I've had to do more selling. I thought we were kind of past the hurdle. Again, our team has grown. We went from a handful of developers to now maybe 10 developers. Some of these are new developers who were not around six months ago. I realized I had not done a good job of really selling them on this vision. It was just because there are new people on the team. They didn't understand the effort that had gone into this thing and where we wanted to go with it. All they knew is that they came in and inherited this somewhat still immature component library that had some friction and things that they didn't like about it.

They knew obviously that it was something that we had developed internally. They were not around pre-Plasma let's say. They didn't experience the same pains that led us to why decided to move into something like Plasma. They were just more skeptical. I think they were right to be. I probably would have done the same thing if that was my viewpoint. I didn't realize until it started to bubble up a little bit more. It's just they don't have enough of the context to understand why we made these decisions.

There's still a lot of work to be done there. If you look at some of these open-source component libraries that have everything in them, they've been worked on by maybe hundreds of people. There's a lot of effort that goes into these things and so it's fairly ambitious to try to build one out ourselves. That's something that we continue to look at and to evaluate and say, "Should we be trying to pull in at the code levels some other stuff from third party things?" Some of the developers that's something that they were interested in exploring.

Nathan:Because there is a loss of efficiency, a loss of the specificity of the features that you've built, and, frankly, most importantly, a loss of autonomy and control that that person has to yield in order for them to adopt the thing you made.

Having a system product manager, or someone that's doing product management, is thinking about all those challenges and then aligning the team's priorities on what they're making, how they're supporting adoption, how they're operating their practice, and fostering all of those activities. When I think about that role within a system team, let's say that stage three, when you've got a system team acting as a product team.

I think there are three main facets to that. The first is the leader. How are they lead the visual and technical direction, or at least connect the systems work with the people that make those decisions within the enterprise. How are they gonna report on the progress of their own team in their system? How are they gonna be the person that is doing the talking at the beginning of every spring showcase to paint the picture of the big progress? How are they gonna direct the scope, present the mission to other teams? They're gonna be doing all the road shows to the leaders throughout the organization and so on. Also, how are they going to keep a mind on one-on-ones? Those conversations in the background that are ensuring that the systems team members are doing well, feeling like they are doing the right things. Feeling like they're doing the things they wanna do so they can grow that systems team and culture. That's the leader, in that sense.

Jared:Nick was no longer just the champion of the design system. He was now leading a burgeoning systems team.

Nick:I need to take a step back and really do a better job of continuing to sell them on this and not just why we should continue to invest in it but really what's the five-year vision for this thing and why are we going to be in a better place five years from now than we are today.

I almost want to have some onboarding for a developer to really sit them down and have them just understand the history of the team. I think that would be really helpful, because all of our current problems are colored by past problems. Everything is in the context of everything that's come before it.

Nathan:That is awesome! Because to me, onboarding onto the system a new team member, is the case of how good is your onboarding for anybody using your system to actually understand what the heck is going on, and what it provides, and how it's organized, and how it fits in with them. Sometimes onboarding a team member, and I've gone through this—I've sometimes resisted the outcomes of this as a person trying to manage priorities—is how does onboarding that team member reveal all your gaps and weaknesses? What the heck did they not get?

When I think about measuring success of a system, I often begin with the point of ... Well, when you're a systems team, you feel so more euphoria when you launch your first release of the system and it's out there and you do the big demo, everybody within your organization, you say, "Look at this wonderful library! Mission accomplished! We're done! Please use this, it's great!".

Then it gets kinda quiet. Everybody goes back to do the work that they’re supposed to be doing, and maybe they start to use a few things, but they didn't use other things. This uncertain future of what are we trying to do here.

The main thing about having a successful system isn't launching a style guide, it's actually seeing the outcomes of all that hard systematic work reveal itself in production applications and experiences that customers use. Seeing the quality bar that you've raised spread across products. Or the consistency as a customer experiences a journey that dances along six or seven products along the way, and having all those come together really well. That is success.

Nick:I think the biggest challenge right now is we're in the uncanny valley a little bit. We've gotten past the hump of getting the thing off the ground. It's being used.

One of the challenges that we have today is we're past that hump but we're not yet to the place where this is just such a super mature thing that just feels there's never any issues and it's just smooth sailing every single day. The selling is always bridging the gap between the painful reality that we may be in today and the future that we can promise or try to promise is better.

Essentially, the way I look at it is you have to convince people to come along on that journey with you. You can't do it by yourself obviously. All of this stuff is super collaborative. The selling is just saying, "Hey, look over there. Yes, today might be not exactly what you want. Maybe there's problems here." If we look down the road a little bit, if we go there together then I think we're going to be in a really great place. It's just you have to just continue to sell that vision. I think as designers we have a responsibility to sell and to be experts and know that these things will work. They do require some time and some investment and some love, and that's always the hardest part.

What I want is for us, as we continue to experiment and learn and refine our approach to how we think about interface that this is something that grows with us. It's not it's just as one and done thing where you say, "Here’s all the Lego pieces we'll ever need." We just put them in a corner and then we pull them out and play with them. It's just something that's constantly evolving and that is not where the story ends in my mind.

Jared:Building a new design system matures an organization’s entire design and development practice. Nick’s initial intention was to build a design system. As Plasma gained traction, he realized it was now more than just a collection of patterns and components, he was now building a systems team.

Selling the idea of the system was one thing, selling the vision and keeping the team on track is the real measure of success.

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

I’m so excited that Nathan Curtis is returning to teach his full day workshop, Building Scalable Design Systems. He’ll show us how to build a cohesive cross-product experience with defined standards and workflows and make critical design changes in one place that seamlessly unfold everywhere. Many of the designers who attended his workshop last year told me their design systems have improved how their organizations operate now. You can see that improvement in your organization too. To learn more about Nathan’s workshop, visit Uiconf.com. That’s U I C O N F dot com.

This UIE podcast was written and produced by Sean Carmichael. We'd like to give special thanks to Nathan Curtis and Nick Stamas for appearing on this episode.

You can find more information about the UIE podcast on our newly launched UIE Podcast Network website: U I E dot F M.

Narrative Virality: Changing Course from a Simple Story

August 7, 2017

Storytelling is an essential form of human communication. You likely have a favorite story, and it’s probably something really memorable. The more that story is told and retold, the further it travels and the more influence it gains. A good story can be infectious.

Stories can also come from unexpected places. LaiYee Ho is the Head of Research at Wink and joins us for this episode. Early in Wink’s research practice one story in particular resonated with the team that was uncovered during an in-home visit, the story of Dominic and Donna. That story spread throughout the organization and fundamentally changed the way Wink approached their products.

Also on the podcast is Whitney Quesenbery, the author of Storytelling for User Experience. She shares her insights about Wink’s discovery and how storytelling can be one of the most powerful research tools.

Transcript

Jared Spool: This is the UIE Podcast. I’m Jared Spool.
Humans. We’re social creatures. Even the most introverted of us thrive when we connect to other living things.
Storytelling is a reflexive part of human nature. As humans, we love to dream, spin fiction, cooperate, and create from our common experiences. These stories differentiate us from other animals. They may have carried us to the top of the food chain.
A gifted speaker or storyteller can spread ideas and feelings, like laughter, sadness, or anger through a room like a Hot Zone virus in a pandemic. We do the same online, when we share, like, and re-tweet posts.
Stories built from user research create context and meaning out of data and numbers derived from the people we study. These research stories can be as short as two sentences and still support the assumptions we’ve made about our audience and our products. They can shake us out of our collective knack for blind certainty.
 
LaiYee Ho: It's a trickle effect. Once people start talking about it in this user research debrief, they go back to their team and they say, "Hey, this is something that we learned today. There's this crazy story where the actual thing that mattered the most was this very simple interaction of a light being on when somebody came home. Didn't realize that." Then it catches on, and throughout the organization different people hear it and then they'll ask to see the video. Then, before you know it, it becomes one of those stories that we tell all the time, like, "Hey, are you designing for Donna or are you designing for the do-it-yourself person?"
I am LaiYee Ho. I am the Head of Research at Wink.
 
Jared: Some humans form deep and lasting connections to inanimate things, like our smart phones and devices, a favorite coffee mug, even a pen.
We find ourselves communicating with otherwise non-living things. Alexa, can you play some music? Siri, what is pi, without the e? Or the worst-case scenario: Open the pod bay doors please, Hal.
Wink’s products connect and automate elements of a home through an app. Music, lights, locks, heating/cooling, garage door openers—virtually anything that you connect, the service will accommodate. And, it’s a competitive market.
 
LaiYee: Our angle, as far as product vision, was to give people these custom features so that they can make anything that they want. The product roadmap was all about giving them things like if-then statements, custom buttons where people can set up what they want. Our user base was very creative. They like to build things.
Some of the feature requests that we were getting from do-it-yourself customers were making it more advanced, like adding "or" statements to the if-then statements, and more ability for them to customize even further.
 
Jared: As a young company, Wink’s startup culture emphasized building, testing, and shipping their product, without a lot of time for reflection. Those technical do-it-yourselfers were the customer base they knew—early, passionate, and loyal adopters of the product. They shared their feedback on beta forums, customer service reviews, and calls. These customers reflected the company’s own engineering-driven culture.
 
Whitney Quesenbery: I actually see this happen in virtually every successful project I've worked on in some degree or other.
I'm Whitney Quesenbery. I'm the author of a book called Storytelling and User Experience. I am teaching a workshop at UI22 called Storytelling as a User Experience Superpower.
Any new product idea comes from somebody saying, "The world isn't as I'd like it to be and let's change it." Sometimes that's a personal need or sometimes it's because you know somebody ... often I think especially in high-tech development, it comes from someone who really loves the stuff, right? Whatever the engineering stuff is. They want to play with it and they're fascinated by it and they want to figure out something to do with it that will work as well for millions of people as it works for them. The problem with all of those is that it starts with a very narrow angle, right? It's a sort of personal view out from either the small group or the single person who's the originator of this idea. At first all of their effort goes into kind of crystallizing, catalyzing their own idea. Then they're surprised to discover that not everybody has the same experience as they do or the same ideas that they do.
 
LaiYee: There was a pivot point, where we decided internally that we had to make a shift. Continuing down this path wasn't really going to work. For me at the time, I was actually a product designer, I kept questioning, "After we ship these products, what are people actually doing with them? Is it actually solving any of the problems that they wanted, and what problems were we solving to begin with?" We were moving so fast that we didn't have that time to reflect.
 
Jared: LaiYee couldn’t shake her curiosity over what customers did with Wink’s products, and why the product wasn’t taking off. Because Wink didn’t have a research team, LaiYee drew together a small, cross-disciplinary team, including Wink’s engineers.
They began conducting in-home studies. In one session, the plan was to interview Dominic, someone from their core base of users, but on that visit, they met someone they didn’t expect.
 
LaiYee: It was really interesting, because we always start off talking with the primary Wink user, and the primary Wink user here was also do-it-yourself, really into advanced customization features. There was a shift in this interview where we were able to speak to his spouse, Donna. Donna was a stay-at-home mom, and she actually wasn't totally aware of all the automations that were set up around her house. In fact, when she talked about Wink, she talked about it as if it were just a technology. They were silly automations that her husband set up.
But when we dug into it, there was one automation that really made her face light up. What it was was she said, "I love the fact that I don't ever walk into a dark house. I can be carrying the groceries and the kid, and not have anything to worry about." That blew our minds, because what she was talking about was a very, very seemingly simple interaction. We were spending all of our time on these crazy features like blinds, locks. How can you combine them? How can you automate them, use machine learning to learn about behaviors? But what she was talking about was something very, very simple.
 
Jared: And that was the rub--a feature that simple made a difference in Donna’s life. It was so simple that LaiYee and the team at Wink had never considered designing for behaviors like it, had never considered what the stories of the Donnas of the world could tell.
 
Whitney: I think that's actually how you know it's a good story. Because a story that's too complicated takes too long to tell. There's too much setup.
What makes a good juicy story is you can tell it fast. The other thing is just because you have a simple story and an anecdote doesn't mean that it's going to be a good story to catalyze change. Right? It has to be a story that people can look at and go kind of dope slap: "Oh yeah, right. I know someone like that." And they can begin to immediately connect that into that adjacent possible of "I know someone like that, what can we learn from them" and begin to expand that out.
 
LaiYee: The story took off when the engineering team saw the video. The person that went with me was able to also speak firsthand. I think what really made the impact was this visceral reaction from Donna about something so simple. I think the reason why it had such a reaction is because, from an engineering standpoint there's a thought like, "Just that? Something that simple is what's making this huge difference?" All these other things that the people at Wink poured so much of their energy into weren't getting the same level of feedback or reaction.
And, Donna's voice is also one that we just haven't heard before. Like I mentioned, a lot of the feedback that we hear firsthand are from people that are asking for more detailed features, advanced features. Donna, she wasn't asking for any of that. All she wanted was to come home, not have to worry about the light so that she can think about everything else on her mind, like taking care of her kids, putting the groceries down. There are a million things on her mind, and technology was not one of them. I think that was something that made a huge shift.
 
Jared: Stories can be the catalyst that takes us from self design, or thinking about what would make us happy as designers, to experienced-focused design, when we think about the bigger picture. We go out and observe people and identify their interactions with the product, how they move from one activity to the next, and then we optimize for it.
 
Whitney: I think that they encapsulate the moment when you suddenly see or understand that there's something else in your precious idea, and I don't mean precious with air quotes around it. I mean they are precious, new ideas. That your idea might work for you, but it has a bigger application if you can just expand the arc of your view of it. That's a nicer way of saying it then: "Well, you've got to get out there and understand other people because you're not the whole world." I mean, everybody is the hero of their own story, right? We're all the center of our world. We want our tools and our life to work for us, and to say "Go make it work for someone else" is actually not a very compelling argument. But to say "If you just look a little bit more broadly then other people will love the stuff you love too" is actually a much more compelling argument to people who are trying to make things.
 
Jared: We can place barriers on our products when we don’t connect to that broader customer experience. What are those barriers? In LaiYee’s Dominic and Donna story, it was the complexity of the product.
Donna only needed something simple to make her happy, to add value to her life—that simplicity was something Wink’s engineers hadn’t considered, because they were focused on all of the technical possibilities their product could offer. And they were only listening to the Dominics in their audience.
 
Whitney: If we go back to the Donna and Dominic story, it's important probably in that early adopter phase to have a Dominic. Right? Donna would probably not think, "I'm going to go out and buy a piece of technology and probably pay a fee every month so I can turn on the lights in my house." Once the Dominic has gotten that device into the house, then Donna can start to see the things she can do with it.
Maybe there's something around how you use your early adopters to open doors but then you have to understand who else is going to walk through that door and what they might need. Then you could start to say, "Well, let's make an easy recipe for lights come on as I walk into the room, and all you have to do is plug in your rooms and your lights and it works, and so now we can think about how to make it easy."
 
LaiYee: I think what we really realized was that if we continued to focus on do-it-yourself, you're not only containing it to just that market but you're also excluding some of the people they live with. By expanding that to make sure that we're being more inclusive with the types of people that we are catering towards and making sure that anybody can use it no matter how savvy they are with technology, we think the impact will be a lot greater. The experience is even better even for the do-it-yourself users, for their families, and then for people where they don't have a do-it-yourself person in the household.
 
Whitney: I want to go back to another piece of the story and what made LaiYee's story work, and that is context. Right? The reason why it's worth all of the really rather extraordinary amount of effort it is to find someone who will let you come to their house to invade their life, to see what they're doing, to talk to them in context, is because they will tell you or you will see them do or you will see around them the things that they would not think to tell you. If Dominic and Donna lived in a studio, her story would not have happened there, because it's a different story. Now they live in a house with halls in multiple rooms. I think a lot of what happens in story gathering is that we begin to learn what other people's lives look like as well as what they think about them.
 
LaiYee: There's so much rich information that you get when you go in home that you just can't get if you're at your computer looking at the data and analytics. Then, on top of that, there are the emotions of the other people in the home that you get exposed to, so a lot of empathy, not just for the primary Wink user, but also for the kids that they live with or their grandmother who doesn't understand how to use the light switch after it's been connected to something smart and it no longer works. And, there's so many different layers of emotions and context and people that you just don't have exposure to unless you go there.
I placed a lot of value in bringing everybody on the team onto research: data scientists, engineers, designers. That cross-disciplinary expertise that everybody comes with, once they're all grounded in the same user insights, the types of conversations they had when they got back to the office, dramatically different.
They're not talking about their function anymore. They're just talking about, "How can I get this user from where they are to what they want?" They're working together and there's just this fire and energy in that room, where there's so much creativity but it's bounded by this constraint of, "What is the real user need?" Then, the products that we came out with after that were a lot more useful, a lot more grounded, a lot simpler, honestly. We don't go off on these tangents of products that don't relate to what users want to do.
 
Jared: Despite the popularity of the Dominic and Donna story and the nascent user research practice that was developing at Wink, it still took time to win over stakeholders to the importance of building a research practice. And what won them over was...the story.
 
LaiYee: Tough stakeholders are a lot of times the ones that think that the research is going to take too long, or they don't understand what kind of value you can get from them when they think that they understand the user. Or, it could be somebody that already has a very clear idea of what they think the product should be and they're not sure how going into the home is going to really help them. In fact, doing the research will directly challenge somebody that has a very strong vision and isn't willing to let go of it.
I think a lot of trying to convince stakeholders like that is through being patient and showing them tidbits. It wouldn't work for me to go off in a silo, find insights, and just throw a report and say, "This is what the insights are. We must follow that." I think the way that we ended up convincing them internally was through a ground-up thing.
We actually ended up convincing those stakeholders by bringing engineers and designers on the ground with us, and then having these stories trickle up to the top, as opposed to starting from the top from the beginning.
Then, I think once you get people to tell these stories, it's really hard for those stakeholders to ignore them. At that point, we had this user insight movement happening, and all of the decisions that were happening on the ground were based off of that. Then the stakeholders start to listen, because it's not just the user research saying that we must do research. At that point, it is an engineer or a designer making a product decision and specifically referencing Donna in their decision-making process that makes them think, "Wait, I keep hearing about this person named Donna who wants to solve this particular problem," and it starts to marinate in their mind for a little bit. Then, before you know it, over time they're also embedded into this culture.
 
Whitney: A lot of the companies I've worked with, the knowledge is in their heads. They just don't know what to do with it. Especially if you're in the kind of business where you really are embedded with your users like people in education or people who build things where they send staff out to live in the hospital to actually run this stuff, they know what's out there. They just haven't figured out how it applies to what they're building.
 
Jared: How do we intentionally harvest and cultivate actionable stories from our research to inform the way our team will approach our products?
 
Whitney: I think the way you make it intentional is to be doing collection all the time. Right? To make sure that having input channels, whether that's usability testing or field studies or getting people on the phone or whatever it is you're doing, is to have that be something you're doing all the time.
 
LaiYee: We're constantly doing research. One thing that we do with these stories is that, once we have the story, we draw out a storyboard of how we believe our product would work. Then, once we have that, it's a visual of what the product vision is for Wink, and the research that we do is then trying to see whether or not what's actually happening out there in the field is reflective of the storyboard, of what we imagined the story would be. That's a little bit more validation. But then, through that a lot of times we also discover that we might have been wrong, and still wrong in some of our assumptions, and we still have to remap the story and figure out exactly how we need to make tweaks and shifts to make sure we are solving those problems.
The way we started was that we would conduct foundational research, which typically is an in-home study, where we would really understand the needs of the users. This was usually driven by some sort of business objective, like we might need a certain percentage of users to adopt a type of feature. That's how broad the prompt might be.
Then, when we go in-home and study these users, we have this process, which is pretty fun, where we try and think of the user as a character. We put together something that we call a user profile/character. It's a prompt where we would learn about the users and then create this character where, kind of like how writers would think of a character for their story, a user wants something, but they can't get it. There's something that's blocking them, whether it's a technical thing, environmental, or social. Then, now you have a user, which we would call a character, and we'd give them a name. They want something that they can't get.
These studies, we would bring the designers and the engineers with us. Data scientists, QA people, everybody would come and really understand this character. We would run a two-day workshop where the product is actually one where everybody on this team will take that character and map out a story about how we can take this user, apply what Wink has in terms of technical capabilities to get them all the way around to achieving what they want. That's what we create as a product vision. Usually, we think of it as: What can Wink do in the next two years to help this user achieve that problem?
 
Jared: The Dominic and Donna story showed the team at Wink the power that storytelling has to shift the conversation around a product, and a company. Research isn’t a one and done exercise. Wink realized they needed a team devoted to research to maintain an understanding of their audiences’ needs, and their stories.
 
Whitney: You can't just go out and do one interview or one home visit and wow, you get this fantastic story, because the first time you see that story you don't know if it's just one strange person. The second time you see that story you start to go, "Hmm," and the third time, fourth time you hear that story and then suddenly you're somewhere and maybe you don't even know you're hearing it, right? It's percolating in the back of your mind because you're the person organizing all of this if you're the UX researcher, and you're bringing different people along with you because of course you're bringing people along to see this firsthand. Suddenly someone says it in just the right way, and then you've got your story.
 
Jared: Stories are a powerful tool for the designer. They help us bring our users’ experience out in ways we can’t accomplish otherwise. The stories don’t have to be long. They don’t have to be intricate. They only need to connect.
We build worlds around stories. We make far-fetched ideas a reality. And we find an even greater license to create when we use research to illuminate our understanding of others, their habits and their interests. What brings them joy? Some people just like to have the lights on when they get home.
This UIE podcast is brought to you by the UI22 conference that’s happening November 13-15 in Boston, MA.
Whitney Quesenbery will be joining us there to teach her full day workshop, Storytelling as a User Experience Superpower. She’ll show us how to create journey arcs and storyboards that identify and solve real user problems. To learn more about Whitney’s workshop, visit Uiconf.com.
Also, if you’re in an organization that is looking to hire more UX designers anytime soon, I want to point you to our new school in Chattanooga, TN called Center Centre. Our students are learning what it takes to become an industry-ready UX designers and they need your help.
To help them learn the craft, they need great projects to work on. Companies supply the projects and, while they’re at it, they get to see what our students are capable of. It’s a great way to help grow our field while you’re doing preliminary recruiting. If you have a project that you think might work, please get in touch. You can learn more at Center Centre’s website. That’s C E N T E R C E N T R E dot com.
This UIE podcast was written Kathleen Barrett and produced by Sean Carmichael.
You can find more information about the UIE podcast on our newly launched UIE Podcast Network website: U I E dot F M. Go there now and look at all the great shows we’ve put together over the years.
This podcast is part of the UIE Podcast Network. Thanks so much for listening and, as always, thanks for encouraging our behavior.
 

The Back Up Question: Defining a Project’s ‘Good Enough’

August 1, 2017

All too often, the first time we hear about their project, they already have a specific solution.

Can we refresh the design of the home page? We’d like you to build a new form for our workflow. Can we get rid of the carousel on the landing page? We need tagging for all of our content. Can we add in a carousel on the landing page?

There was thinking. There were discussions. That all happened before they came to us. Somewhere in there, they honed in on their solution. And now they want us to design it.

We don’t understand why they are asking for this particular solution. There’s a high likelihood what we design won’t be the solution they’re seeking.

If we take their request at face value, we’ll design what we think they’re asking for. Yet, because they specify the solution in vague terms, we’re likely to miss the target.

We end up with something that isn’t what they’d hoped for. We don’t know what good enough is for this project.

The conventional reaction is to get them to specify their request in substantially more detail. What design would you like to see? Asking for more details puts these non-designers in the role of designing. That’s a role we should be involved in, if not taking over completely.

Instead, we need to know more about the problem. Why do they need this particular solution? There could be a better way to solve it. There could be a solution our design experience brings to the table, one that they wouldn’t know to propose.

How do we start to understand the problem their proposed solution wants to address? After dealing with this very problem for decades, I’ve come up with a simple question. I call it the Back Up Question.

A Key To Unlocking The Problem

The Back Up Question is simple: Let’s say we do a great job on this. A year later, what great things have our users accomplished because we delivered a great design?

I call it the Back Up Question, not because it’s an alternative to another question, but because it forces our stakeholders and clients to back up for a moment and talk about the outcome. By framing the question in terms of what our users accomplish, we focus that outcome on a benefit to them.

Now, there are plenty of ways to bend this question to our needs:

A year later, what causes our shoppers to shop with us more because we delivered a great home page? Six months later, what has improved our applicant’s lives because we’ve added this detail to our application form? A year later, how has a well-designed tagging system improved our users’ productivity?

To answer any variation, we start talking about improving the lives of our users. That’s what I find to be the beauty of the Back Up Question. It backs up the discussion to talk about how we help users. We’re no longer talking what the solution should look like, but what the overall outcome needs to be. We’re talking about the problem we’re trying to solve.

Steve Jobs once said, “You have to start with the customer experience and work backwards to the technology.” The Back Up Question becomes a catalyst for restarting the journey from the user’s experience (not all of our designs are for customers), giving us an opportunity to talk about how we’ll tell if we’re successful.

We Blame The Plumbers

It would be great if we didn’t have to ask the question. If our stakeholders and clients showed up at our door with a clear description of the problem, we could go from there. Collaboratively, we could work up possible solutions and whittle them down until we know exactly what project we needed to execute. But that doesn’t happen.

I think we can blame the service workers of the world—plumbers, mechanics, restaurants—for training our colleagues to find a solution before knocking on our door. You tell a plumber what you think needs fixing. You tell the waiter what you want for dinner. If they understood the problem we wanted addressed, they might have a better solution than what we’re asking for.

Yet, that’s not how the customer request goes. “Make my car run better” is a different request from “change my oil.”

The same is true from our stakeholders and clients. They start with the solution. We need a trick to back up into talking about the problem.

“Huh, That’s A Good Question.”

Much of the time, when I ask the Back Up Question, I seem to surprise the stakeholders. I’ll hear _“Good question. Let’s think about this…”

I can tell, from the length of the subsequent pregnant pause and the number of attempts they’ll take to form an answer, that they’re often crafting the answer in that moment. These stakeholders are searching for the benefits in real time.

Not everyone does that, though. Some stakeholders will have an answer on the tip of their tongue. “Removing that form will make for a smoother interaction, reducing the amount of time our project management users are fiddling with their projects. It will give them more opportunities to see where they can optimize their team’s resources.” They were clear on the problem from the beginning.

Fast Identification Of Solutions In Search Of A Problem

Other stakeholders will resist talking about the problem. We’ll have a discussion that echoes the technique of asking five ‘whys.’

“Adding the carousel will give us more places to advertise the new content we’re providing users.” How does that make for a better experience for our readers? “They’ll know about new things.” How does knowing about new things make a for a better experience? What will they do with these new things that they can’t do now? “Um, I’m not sure.”

From these stakeholders, we may have a solution in search of a problem. We see this with some roadmap-focused teams. They gravitate to providing more features over better quality experiences.

Talking with these stakeholders about their users and the challenges those users face is a collaborative way to get an answer to the Back Up Question.

“Our readers need descriptions of the latest techniques to be more effective in their work. We know that we’re producing videos that help them, but they aren’t discovering them. Our new design should deliver helpful information they can put to work right away.”

OK! Now we’re on to something.

Translating Outcomes Into Measures Of Success

The answer to the Back Up Question guides us to how we’ll measure if the project is successful. We can measure how much time project managers spend fiddling with dialogue box values versus how much time they’re spending resolving important resource management issues. We can measure if readers are employing new techniques immediately.

To collect our measures, we may have to go old school and talk directly with users. This helps us see the value. Seeing how our current users interact with today’s design will give us insights into how to make them successful with our future design.

Using these measures, we can now explore if any proposed solution is the best alternative. We can try out different solutions to see if one may fit the problem better. We may return to what the stakeholder initially brought us as the ideal course of action, but now we know how we’ll tell when we’ve done a quality job.

We’ve defined good enough. That’s an important milestone for any project.

Uncovering a deep understanding of the benefits of our designs is just the first step of a smart design process. We need an efficient process to take our team from a shared understanding to a successful delivery.

You don’t want to miss Dan Mall’s fantastic UI22 workshop, Design Workflow for a Multi-Device World on November 15 in Boston, MA. Dan will share his toolbox of design activities, and guide your team to craft an effective workflow that encourages collaboration and delivery. Read his workshop description for more details.

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

July 20, 2017

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

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

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

Transcript

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Using Scenarios to Solve Problems • A Podcast with Kim Goodwin

July 19, 2017

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

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

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

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

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

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

Transcript

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

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

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

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

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

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

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

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

Jared: Yes, 20 years.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Jared: People use Agile?

Kim: They use AgileFall or something of that nature…

Jared: Yes. [laughs] They use something.

Kim: …but they call it Agile.

Jared: They call it Agile, right. OK.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

That tends to make those conversations go so much better.

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

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

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

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

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

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

Jared: The dog and the Hummer.

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

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

Kim: Oh, no. Please do.

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

Kim: And smiling. Don’t forget smiling.

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

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

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

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

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

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

Kim: So your Hummer is relevant.

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

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

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

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

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

Kim: Yes.

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

Does that work for you?

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

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

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

Kim: Right.

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

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

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

Kim: All right.

[laughter]

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

Jared: Thank you.

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

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

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

Kim: Always my pleasure Jared, thank you.

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

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

User Interface 22 Sponsorship Opportunities

July 17, 2017

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

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

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

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

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

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

2. Lanyard Sponsorship (limited to 1 sponsor)

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

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

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

4. Exhibit Table (limited to 3 sponsors)

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

*Your sponsorship includes additional benefits we list below.

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

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

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

6. Party Sponsorship (limited to 1 sponsor)

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

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

7. The Big Shebang (limited to 1 sponsor)

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

*Your sponsorship includes additional benefits we list below.


*Additional sponsorship items automatically included in noted sponsorships

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

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

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

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

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

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

July 13, 2017

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

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

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

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

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

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

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

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

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

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

Slowing Down The Designers To Make It More Fun

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

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

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

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

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

All This Fun Is A Seriously Important Exercise

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

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

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

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

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

Mapping the User’s Journey Into Hell

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

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

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

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

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

Pulling out the Attributes of Experience

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

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

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

Discovering The Good That Lives Within

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

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

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

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

Stealth-Mode Design Literacy

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

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

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

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

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

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

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

June 29, 2017 by Nathan Curtis

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

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

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

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

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

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

Changing from a Project to Product Mindset

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

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

-@nathancurtis

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

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

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

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

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

Spreading Your System to Their Products = Product Marketing

To have a product means knowing and serving your market:

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

Sustaining Your System = Product Management

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

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

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

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


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