O'Reilly Design Podcast - O'Reilly Media Podcast

The O’Reilly Design Podcast: Quickly test ideas like a design thinker.In this week’s Design Podcast, I sit down with Julie Stanford, founder and principal of user experience agency Sliced Bread Design. We talk about how to get in the rapid experimentation mindset, the design thinking process, and how to get started with rapid experimentation at your company. Hint: start small.Here are some highlights: What is rapid experimentation? Rapid experimentation is a technique for figuring out if you have a good idea. As you're going around designing things, running a company, being an entrepreneur—whatever it is that you do in your work life or your daily life—you probably have all kinds of ideas that you're really excited about, and you're probably thinking, ‘Hey, is there some way I could tell early on without investing a lot of time and energy and resources if this is actually an idea that has legs for people?’ ... Rapid experimentation is a technique for creating experiments that actually test the use of, or engagement with, your idea in action. It's a process for creating experiences really quickly that are representative of an aspect of some idea you're excited about. Then, you can see how people are actually engaging with this thing or service or process  that you're trying to design. Why it’s so hard to get in the rapid experimentation mindset Starting at a young age, we're conditioned that when people ask you questions that are factual and have answers, you, as a reasonable, smart person are proving your worth and your knowledge by knowing the answers to those questions. Rapid experimentation is the opposite of that. It starts from a place of, ‘I don't know the answer to this and I'm never going to find out by sitting at my desk and thinking really hard,’ or even, ‘I'm never going to find out by hanging out with some other really smart people at my work and discussing it for a really long time. I'm still not going to get the answer.’ It's admitting that the only way you're going to get the answer is by running an experiment that might fail. It's in the word. It's an experiment. It could be true; it could be false. Who knows. We'll see. We have a hypothesis about how it might turn out, but a lot of hypotheses are disproven, and this may be a situation like that. Even if we learn that this idea in its current form is not a good idea, we're going to learn something about why it's not working as-is, and that's going to lead to an even better idea. The 5-second definition of design thinking It’s a cyclical process of understanding from users, having that inform some design that you're doing, and then going back out to users and getting feedback on it. In a nutshell, that’s probably the quickest description of design thinking I have from a process-oriented perspective. How to start using rapid experimentation at your company Start small—especially if you don't have a culture at your work that is okay with failure or that gives you time to do this. Pick a small thing that's on your plate, come up with a few ideas, and see if you can run a very small test that maybe only you're privy to. Then once you get the results—and I guarantee you, it's going to be super interesting—advertise the results. People will get really intrigued and wonder how they might be able to get that kind of data on their own.

The O’Reilly Design Podcast: Designing for the “six minds,” the importance of talking like a human, and the future of predictive AI.In this week’s Design Podcast, I sit down with John Whalen, chief experience officer at 10 Pearls, a digital development company focused on mobile and web apps, enterprise solutions, cyber security, big data, IoT,  and cloud and dev ops. We talk about the “six minds” that underlie each human experience, why it’s important for designers to understand brain science, and what people really look for in a voice assistant.Here are some highlights: Why it's important for product designers to understand how the brain works I think that by knowing a little bit more about the brain—what draws your attention, how you hold things in memory, how you make decisions, and how emotions can cloud those decisions...the constellation of all these different pieces helps us make sure we're thinking like our audience and trying to discover their frame of...literally their frame of mind when they're picking a product or service and using it. The “six minds” that underlie each human experience One is vision and attention. The second is memory and all your preconceived ideas and the ways you think the world works. The third is wayfinding—that's your ability to move around in space, in this case, move around a virtual world. The fourth is language, so the ability to have different linguistic terms. Associated with that is the emotional content there. And, finally, all of that is in service of helping you make decisions and solve problems in your world. What we look for in a voice-based assistant We studied how a diverse group of people use Siri, Cortana, Alexa, and Google Assistant, and then we asked, "Well, which one would be your favorite to take home? Which was your personal preference?" A lot of people did pick Google Assistant, which made all kinds of sense because that one did the best at answering questions. But then the second most popular by a wide margin was Alexa from Amazon's Echo—despite actually being the least successful at answering questions. So, that was intriguing to us and we kind of wondered why. It turns out that the folks who picked Google Assistant often described what they were looking for from these systems as things like, "I just want the answer fast, just the facts. Give me the answer; I just want to know what's happening." And some of the people who preferred Alexa said things like, "Well, it answered the question the way I asked it." Or, "I like that I can converse back and forth with it. It makes me feel like I'm speaking to a human." So, there are really humanistic qualities they gravitated to with Alexa.    ...We can't just go out and test our systems to be “percent correct” accurate, we also need to think about this human component. I think that's the thing I wasn't necessarily expecting to find from our study. We were curious about this humanistic quality, but we didn't know how important it was. How predictive should AI systems be...when does it become creepy? In our study, we asked questions like, “How much would you like this to know about you?” For example, Amazon knows how often you've bought toothpaste, so it could probably predict if you're running low on toothpaste. It could ask on a random Tuesday, "Gosh, Nikki, would you like some more toothpaste?" And you're thinking, "How did it know? And where is it looking? And did it have a camera? And who else is in the room?" There are mathematical models that can predict these things quite well. ...There can be all kinds of ways that devices can augment your cognition—and we already do this; we're already, in some ways, cyborgs, every time we use Google Maps or every time we Google a price to make a decision on choosing something. There are a lot of ways this works, and we are very comfortable with it now. Finding out the weather in advance is actually augmenting what we know, helping us make better decisions. It can keep doing this; it's just that we're not used to it doing it in space and time, and we're not used to it being as predictive. We're used to asking it a question and then receiving the answer as opposed to it anticipating that you might need an answer.

The O'Reilly Design Podcast: Designing in secret, designing for voice, and why improv is an essential design skill.In this week’s Design Podcast, I sit down with Cheryl Platz, senior designer at Microsoft for the Azure Portal and Marketplaces. We talk about the challenges of working on a top-secret design project, the research behind Amazon's Echo Look, the skills you need to start designing for voice, and how studying improv can make you a better designer.Here are some highlights: The challenges of designing secret projects The Windows Automotive project I worked on at Microsoft wasn't fully 'tented,' but it was kind of hush-hush, so I thought I was prepared when I went to work at Amazon on the Echo Look. But this was...I had never experienced anything truly this secretive. As a designer, being cut off and unable to talk about what you're working on cuts off a part of your process in a way that is a little disorienting. You cannot openly go to customers and ask them questions. You cannot openly go to other designers and ask them questions, and sometimes you can't even ask general questions without causing some kind of curiosity or alarm. ... You really need to get connected with whatever intrinsically motivates you because you're not going to be able to go to critiques and get validation or support or insights from other designers, for the most part. You're going to have to find other ways to gut check yourself to make sure you're considering all perspectives to make sure you don't have any blind spots. It certainly makes things a lot more challenging, and it creates a weird sort of career tension where you know you're on the cutting edge of something and you can’t...tell...anyone. Why voice assistants are all women There's some really good research that takes into account the way our gender perception influences our perception of digital assistants. ... The fascinating thing was that there was cognitive dissonance when a gendered voice talked about a subject that was not perceived to be in that gender's area of strength. For example, if you had a woman talking about the inventory at Home Depot, there was cognitive dissonance. If you had a man talking about fashion, that was cognitive dissonance. So, if you're a company and you're trying to release a product that's going to be very disruptive and cause privacy concerns—and I did not work on the initial release of the Echo, so this is me talking on behalf of myself and not on behalf of any company—but my guess is that if you're a company looking to make this really disruptive wave, you have to minimize cognitive dissonance elsewhere to get people to open their minds to a microphone in their home. For the American market—and the features that they planned for Alexa—Amazon knew Alexa would be used largely in the kitchen. Kitchen timers are super popular. Alarms. Household management stuff. I wish that we were just super gender neutral, but the fact of the market here is that cognitive dissonance exists. It's real. So, if you have a home-oriented product in America, you kind of have to start with a female voice. How studying improv makes you a better designer Doing improv has a direct impact on how you handle conversations, how you approach problem solving, how you approach question-and-answer sessions at conferences. The more you study improv, the more you learn that the world is not full of right and wrong answers. There are a lot of different ways to answer a question. For example, when I'm at conferences and I get tough Q&A, that improv training, where there are just a number of ways to handle a situation—none of them are wrong. There is an answer. Just have faith in your ability to find it. And to listen. That's the other thing. A lot of improv training is about listening to people, starting to understand their motivation—that's a very valuable skill, and I will be the first to admit that early in my career, I was not great at listening. I wanted to be right. I was as guilty as the next person of waiting for the other person to finish speaking so I could speak. Improv helps you get past that.

The O’Reilly Design Podcast: The sombrero-shaped designer, leading design teams, and designing for retail.This week, I sit down with Cynthia Savard Saucier, director of design at Shopify and author of Tragic Design. Saucier also is keynoting at Velocity in New York, October 1-4, 2017. We talk about moving from working in design to leading designers, the real and sometimes negative impact that design decisions can have on users, and how design is organized at Shopify.Here are some highlights: Design at Shopify At Shopify, we have more than 2,000 employees, so we're starting to become quite large. We don't have a design department per say; we have a UX umbrella, and under that UX umbrella, we have designers, content strategists, UX researchers, and front-end developers. So, it’s slightly different than some other companies, where front-end developers are working within the UX team. We try to have someone from all disciplines on every project. Some projects require many designs; for example, when we designed the checkout experience at Shopify, we needed a lot of designers because it's customer facing, and there are different pieces that had to tie together. Sombrero-shaped designers We often hear of 'T' shapes; I use something I call a 'sombrero shape,' or the Hershey Kiss shape. I want someone who is really good at one thing, but can be stretched at doing two or three other skills. These are my favorite types of employees. Once you have a bunch of sombreros, they usually cover the whole spectrum of design, and that's perfect. Another thing we always ask ourselves is, what would this new candidate add to our culture, add to our team? We actively want people who are not like us. Tragic design We tend to think design has an impact, but we only think about the positive impact. Our book outlines how designers need to ask the right questions when they're designing. In design school, we're taught to make things look beautiful or create desirable experiences. We are never once exposed to the consequences of terrible design decisions. For example, some designers design with a single type of user in mind, or they forget that they're designing for someone other than themselves; this leads to injustice and exclusion. As a designer you have to think of all the different situations and make sure you try to prevent any mistakes from happening.

The O’Reilly Design Podcast: What makes healthy teams healthy, being customer obsessed, and design and research at Microsoft.This week, I sit down with Travis Lowdermilk senior UX designer at Microsoft, and Jessica Rich, UX researcher at Microsoft; Lowdermilk and Rich are also co-authors of the Customer Driven Playbook. We talk about why failing fast is not always a good approach, sensemaking, and never losing track of the customer’s voice.Microsoft’s customer focus Travis: Over the past few years, Microsoft reemphasized its mission to connect and learn from customers, so we're seeing a sort of Renaissance period at the company where there's this kind of recommitment to being customer obsessed. This isn't something that's unique to Microsoft; you see this with other companies as well, that folks aregetting hip to the idea that in order to make great products, you’ve got to listen to your customers and you’ve got to do it in a procedural way—you can't just comb the feedback forums and come up with ideas; there has to be a process. We have the desire to be Lean and Agile, but I think what's unique to Microsoft and other big companies is we also have a kind of unique responsibility. It's great to want to be startup-y and embody those fail-fast type philosophies, but we also have to make sure we keep our customers’ best interest in mind. It's a hard ideology to swallow when this company's responsible for software that spans countries and cultures, we have these software products that militaries rely on, software that helps first responders respond in a disaster situation. The gravity of what we work on can't always be a fail-fast model. That being said, the challenge for us and anybody in UX, is to find ways to help them operate in a way that aligns with the responsibility we have, but still allows them to respond quickly. Quite frankly, to not lose the customers’ voice along the way. This is a big company, and we have big divisions. We're trying to do things as one Microsoft across the company that involves everything from Windows to Office to Skype, moving in a concerted effort, but then there are things our individual teams are trying to do. It can be easy to lose the customers’ voice in all that. That's why we have whole dedicated sections in our book to an activity called sensemaking. It's the idea that you need to periodically step back from your work and look at the bigger picture, to identify those patterns, and that's something that's really resonated here at Microsoft. We have a huge insider program with the Windows product, where we have hundreds of thousands of customers, millions actually, giving us hourly feedback. How do we step back from that and make sense of what do we do with the data we're collecting? Design and UX research at Microsoft Jessica: Travis and I are in the cloud and enterprise division, and we work on Visual Studio. Our UX team is both, as he mentioned, design and research, and we support and partner with our product teams, which include engineering and product managers. The interesting thing about our group is that it doesn't matter what role in the organization you’re in; everyone is customer focused. Our entire team is involved in customer development, and we all use different types of mixed methodologies. We use things like A/B testing, analytics, surveys, focus groups—the list goes on and on. The idea is that we want to learn as much as we can from our customers and make products that suit their needs. We share our results with everyone in our organization, so if a particular team is having conversations with a certain type of target customer, they share it with our entire organization so we can all have a shared understanding of our customer. The idea is that we've framed this as raising our organization’s IQ about our customer, customer IQ. Everybody's learning from these experiences so we can build on the learnings we have from all of our customer engagements, whether it's qualitative or quantitative. Healthy teams: Stepping outside your role Travis: The teams I enjoy working with are folks who have a mutual respect for each other and a desire for learning. Like Jessica was saying, they check their ego and their role at the door, andthey're hungry to learn more, not just from the outside world but from each other. I'm a designer who works with a bunch of researchers, but the researchers don't make me feel like, ‘oh, well, you're just the designer—you can't do the research work.’ There's no element of that. I think it’s critically important that we can go beyond our roles and say, ‘Yes I'm a product manager, but I want to do some research, and I want to try this hat on, and I want to talk to customers and do it in a procedural way.’ Or, ‘I'm a dev and I want to step outside and try a design thinking activity and explore some ideas.’ I think the best teams are the ones that are able to do that effectively, and also that they're willing to build off each others’ ideas and share knowledge with one another. That's not always easy at a company like Microsoft—or any other company where, especially in a large organization, it pays to stand out and be recognized as an individual. We're getting better at that, but it's still something each company struggles with. To be a member of a great team, you’ve got to want to serve or to assist the team and help others succeed. The best teams understand that, yes, we all have our personal ambitions and our own individual goals but the team, as a cohesive unit, is going to work better if we're all willing to assist and share what we're learning and also be willing to learn from others. I learn from a design perspective; I'm open and receptive to learn something that I can add to my ‘design toolbox’ from a product manager or an engineer. That happens because I'm open and receptive to it.

The O’Reilly Design Podcast: The connective nature of product management, “no work above, no work below,” and the importance of talking to people who aren’t your customers. This week, I sit down with Matt LeMay, product coach, consultant, and author of Product Management in Practice. We talk about the four guiding principles of product management, what he has learned about himself as a product manager, and how to conduct meaningful research. Defining product management To me, being a product manager is all about being the connective tissue, the glue that connects whatever the different roles are within your organization. The specific organizational roles might vary, depending on where you are. You might be working more closely with technical people. You might be working more closely with marketing people, but whoever those different players are, your job as product manager is to be the aligner in chief or translator in chief, the person who is ultimately responsible and accountable for everybody having a shared language and a shared sense of purpose. CORE product management skills The four guiding principles came out of the four CORE skills, which is an acronym for communication, organization, research, and execution. I wrote a piece on Medium a few years ago, which was my attempt to challenge the traditional three-way Venn diagram of product management with business, technology, and UX. Having worked at a lot of enterprises and companies where people might not actually be that close to the technology side or might not be thinking about user experience as a day-to-day concern, I felt like those three areas captured a common set of subject matter knowledge that product managers will encounter, but not the actual skills they'll need to connect between those different subject matter ideas. Some people commented and rightly pointed out that something seemed to be missing from it. That thing seemed to be an element of research, or the ability to actually glean information from the outside world. Erika Hall, in the book Just Enough Research, says that, "Research is just applied critical thinking," which I love as a way of defining research. I like using the word ‘research’ because it also makes it clear that it's not just about being smart; it's about actually doing the work of seeking out alternate perspectives, and explanations, and ideas. These four skills—communication, organization, research, and execution—each one comes with a guiding principle, and I stand by these four guiding principles. For communication, the guiding principal is clarity over comfort, which is really going back to what I was talking about earlier, about this idea that there are times as a product manager when you will have to state things that might seem painfully obvious or ask questions that you know are wading into really difficult political challenges for the organization, but if there is not absolute clarity in your team and in your organization about what people are working on and why, then you cannot succeed as a product manager. If people don't know what they're doing and why they're doing it, and know that really clearly, then it doesn't matter how good the thing is that you ship or how quickly you ship it; the team will eventually start to fragment and fall apart because that understanding is so fragile and so susceptible to miscommunication and to tomfoolery by people who are trying to steer the product direction one way or another. For the organization principle, we have ‘change the rules, don't break the rules.’ This was another one that took me a long time to understand. I come from music. I am not a process person. I think a lot of folks who start out as product managers are like, "Yeah. All this stuff is stupid. We shouldn't have 800 steps to do everything. We'll just work really fast. We'll move fast and break stuff, and it'll be awesome," but there's a downside to that, which is that when the rules don't work and people work around the rules, you're basically incentivizing rule breakers and people who are not communicating well. The people who figured out how to game the system accomplish the most, and the people who are trying to go through the system are dinged for not shipping enough software or not being performant enough in whatever way. For research we have to live in the user's reality, which is pretty straightforward, but also very difficult. When you work in an organization, you live in that organization's reality. That is your day to day. You believe the things people in that organization believe, and it's shockingly easy to become fundamentally misaligned with the reality of your customer, especially when the metrics are telling you you're doing an okay job, but your customers are actually not that engaged. Living in your customer's reality is about getting beyond just looking at isolated metrics, particularly vanity metrics, to understand your customers and really understand their perspective, their world view, how it's changing, how it's evolving, so you can continue to meet their needs as they change and evolve, rather than getting stuck in the way things have always been and the status quo of your organization. Finally, for execution, this is one one my favorite ones: no work above, no work below. This means that as a product manager, you have to do whatever it takes for your team to succeed. It's pretty well documented that there can be no work below you or beneath you as a product manager. Right? If you have to bring coffee and donuts to the team, that's what you do. If you have to learn how to do something that isn't super fun and exciting to you, that's what you do. Product managers who say, ‘That's not my job,’ or, ‘That's not something I like to do,’ do not generally succeed. Living in your user’s reality I'm a firm believer in qualitative research generally, but within that set of qualitative research, I'm a firm believer in talking to people who are not your best customers. I'm a firm believer in talking to people who are considered casual users or users who abandoned your product. There's a tendency, when companies do qualitative research, to over index on the power users and the good customers and to just keep building things for them, but when you talk about living in your user's reality, you're really talking about living in multiple realities for multiple users. In a lot of cases, the people you're talking to need to be the people you're most afraid to hear from or who you initially feel have the most tenuous and least passionate understanding of your project, because those are often the people who are going to make or break your product's success and who are going to be where your growth opportunities come from. When I talk about living in your user's reality, a lot of that has to do with getting outside of the closed feedback loop of looking for the vanity metrics that support that you're doing a good job and talking to the good customers who will tell you how much they love your product and also have a million product ideas. It's the people who don't really have any product ideas who are just like, ‘Yeah. I don't know. It's fine. Sometimes I use it. Sometimes I don't’—those are the people whose perspective you really need to understand the most because their perspective is probably the farthest away from yours. Not taking those people seriously, not considering them, is a very dangerous thing that I've seen a lot of product organizations do and fall into. It's funny. I was at a training with a financial services company a few weeks ago. We were walking through some qualitative research, and people were getting very tense, ‘Well, I'm talking to somebody, but they went totally off into left field, and they're not talking about my product anymore. They're talking about their life.’ I get that concern. Right? Because you're there to do a job, but there's an element, and this feels sort of esoteric, but I think it's true, there's an element of faith that goes into those kinds of conversations, where if you really trust and follow somebody's own line of thinking, there will be value in it, but if you go in trying to steer a conversation back to your assumptions or the things that you want to be true, that is exactly where the conversation will go. Related resources: Product Management in Practice—live online training course by Matt LeMay Product Management for the Enterprise—online video tutorial by Blair Reeves

The O’Reilly Design Podcast: Leadership, the design of product teams, and hiring optimists.This week, I sit down with Nate Walkingshaw, chief experience officer of Pluralsite and co-author of Product Leadership. We talk about hard and soft leadership skills, building cross-disciplinary product teams, and why it’s important to use the layover test when hiring.Here are some highlights: Hard and soft skills for product leadership The two different paths are hard skills and soft skills. From a soft skills perspective, don't be a jerk. That's the first thing. Aggregated data wins a lot of debates around the workplace. So, come prepared. Kindness, humility, living in reality—I think those are simple things that continually come to the forefront that need to be restated all the time when you're working in a cross-functional environment. The way people experience you and the way you experience others really has to do with two things: conflict versus context. I think great leaders have an ability to back away, look at how you work on the business instead of in it, and then really find a way to collaborate with others to come up with the best outcome for the company, the users, the customers, and everyone that's working together. We spend a lot of time around the soft skills because it's the nature of product development work, design work, and engineering work, requiring those teams to be cross-functional. We can't ship an experience without all of those teams working in concert together. We spend a lot of cycles investing in people, investing in the culture, investing in the soft skills of individuals. From a hard skills perspective, it comes down to you needing to have the hard skills in product management and design out of the box. The design of product teams The perspective we want to share is that we have a great mission and vision, and people are connected to it. From an organizational design, what's the strategy that lays underneath the foundation of that? That each individual who drives into work every day can see their role, the strategy, the mission, and the vision of the company, and they feel really connected to it. The reason they feel connected to it is because of the way we designed the teams. Everyone who sits inside the experience organization—which is the product management, user experience design, and content teams—could recite democratizing professional technology learning or closing the technology skills gap to you. The goal, the mission behind that is really creating progress through technology that lifts the human condition. Using the layover test when hiring The first thing that comes to the front of my mind is attitude and eternal optimism. Really great leaders, great product managers, look at a problem as an opportunity to unlock something they have never discovered before. When you interview folks or when you work on teams, you can smell that attribute pretty quickly, even in the interview process. You get a pretty good sense for it right out of the gate. The other thing is the old layover test. Does this person pass the layover test? That is, if I got stuck in the airport with Mary Treseler, after 24 hours would we still be friends? The layover test is a big deal. Is this someone I could hang out with, someone I would want to go out to drinks with and socialize with? Would I want to introduce this person to my family? Would I be proud to work with this person? All of those things really matter. It goes back to the fact that we spend more time at work with these people than we do with our families. Are you fun to work with? From a cognitive perspective, can you unlock complicated problems? Are you creative? Can you come up with creative solutions? I think those things really matter a lot.

The O’Reilly Design Podcast: Asking the right questions, conducting research in an agile environment, and conscious confidence.In this week’s Design Podcast, I sit down with David Farkas, associate director of user experience at EPAM and co-author of the book UX Research. We talk about his book, why everyone should learn to conduct research, and how to open up your mind to ask the right questions. Farkas and his co-author Brad Nunnally also are teaching a series of online courses: Learning UX Research: Understanding Methods and Techniques—May 8 or July 10, 2017. Learning UX Research: Analyzing Data and Sharing Results—May 22 or July 24, 2017. Here are a few highlights from our conversation: Asking the right questions The best way to understand if your product or service is resonating with the customers is through some sort of observation. Regardless of your role within an organization, I think everyone should have some awareness of the research going on and, at the very least, be observing it, if not directing and driving it themselves. I think there are two main areas people struggle with when asking questions, especially in the context of research. The first way is trying to craft questions so they can sound smart and really knowledgeable about the domain. What we always have to remember when we're conducting research is: this isn't about showing off my skills as an interviewer or researcher. It's about trying to learn something new. There's this discomfort in a lot of places—and I’ve felt it too and I still feel it, depending on the project domain—where we want to be able to go into a research session knowing everything we need to know to ask the smartest questions. That's counterintuitive in a lot of ways to what research is—the whole reason we conduct research is because we don't know something. The first challenge is trying to sound smart when conducting research, when the whole point of conducting research is to fill a knowledge gap. The second challenge is probably a little bit bigger: when conducting research, you really want to elevate the participant. It sort of comes second to wanting to look smart. You have to put that ego down and make sure the person you're conducting research with is able to look and feel like a rockstar. This is particularly hard when doing any type of product testing or product validation, where the participant might feel frustrated about not being able to accomplish a task. It’s important to make sure they know this is not about them or their skill sets. It's about their opinions, and putting them in the best light possible is a really hard challenge for even good researchers, but it’s an important skill newer researchers need to learn and practice. Agile and UX research: Debunking research misconceptions There's a bit of a misconception that thorough means long, time consuming, and expensive. Thorough really just means, in my mind, that it's ongoing. I think the real lesson in any type of Agile or Lean environment is that any research is better than no research, and to start as small as you possibly need to. If that's gorilla research, taking out sketches to a coffee shop and having a conversation there, it gets the ball rolling, it gets the conversation started. There's a lot of risk involved in doing gorilla research like that as opposed to doing something a little more formal and properly sourcing your participants, but any research is better than no research. There's another misconception that research has to happen at the beginning of a project, and if we missed the research, the ship has sailed. Really, we can do research at any time, and we should do research at any time. When we're discovering the problem, defining the solution, and validating the solution, all of those things can happen very quickly and become part of a sprint cycle and part of our design iterations. One of the most common misconceptions is that you need to be a researcher to do research. I've been on projects where everyone—business analysts, project managers, account managers, etc.—has conducted the research with me. With a five- or 10-minute conversation beforehand, they've been able to understand what our area of inquiry is and learn some best practices in terms of the participant dynamics between the researcher, moderator, and note taker. Really, with just a little bit of training and preparation, anyone can conduct research. The conscious confidence matrix The idea of the ‘conscious confidence matrix’ starts with actually being unconsciously incompetent. It's the idea that you start out not knowing what you don't know, and then you move into knowing what you don't know; knowing what you know; and, finally, subconsciously knowing what you do know. It becomes ingrained in you. That only happens through research, so the idea that you start not knowing what you don't know is like this: ‘David, you're going to be doing a project on a large health care application. Okay, I don't know anything about health care, I don't know where to start.’ That's actually the first question of research—then I can start to understand that the project is about these areas of health care, and I know I don't know about these three of the four areas, so let me explore that. Then, I learn about those areas and, on a very conscious level, I can pull the different pieces of knowledge out of my memory bank. Then, ultimately, by the end of the project, the knowledge is so ingrained in my brain that I don't have to think about what the answers are when people ask me about acronyms or workflow or process; it just becomes a natural part of my conversation and something I'm able to speak about naturally.

The O’Reilly Design Podcast: Design ethics and value systems, and what the Ford Pinto can teach us about the importance of human-centered design.In this week’s Design Podcast, I sit down with Jonathan Shariat, senior interaction designer at Intuit and co-author of the forthcoming book Tragic Design. We talk about his new book and survey some use cases that point a spotlight on the importance of ethical standards in design.Here are a few highlights from our conversation: The Ford Pinto This was the '60s, and they were trying to make a car that was very cheap, very light, and the market was very competitive. And, again, the reason we chose to put this story in, is that there are so many facets that apply directly to designers’ everyday work. Try to empathize with the business as well—even just an extra $25 dollars per car; the cars cost $2,000 at that time, so charging an extra $25 dollars per car could price you out of the market. The sensitivity on price was really big. And one thing that they were trying to do was make this really big trunk for the car, but what that meant is they had to move the gas tank underneath the car. And what that ended up doing was, when you got rear ended, even at speeds as low as 20 to 30 miles per hour, the car would crumple, and the gas would spill out. In many cases, of course, in a car accident, there's going to be sparks. So, in a lot of cases, there were sparks, and then you have all this gas, and the car would erupt in flames. To make matters worse, at slightly higher speeds, the doors would jam. So, you have this terrible situation where people are locked inside and the car explodes very easily at 20, 30 miles per hour in a very simple rear-ended accident. The engineers knew this, and they brought this issue up; they even came up with a solution of adding some rubber bumpers at the back that would really reduce the impact of this issue. But the price of it was a little too much—I think it was an extra $25 bucks, around there. The business did a calculation. And the calculation was this: they had a price for the vehicles, the extra price of this little extra bumper, and then the price of people's lives, which was actually given to them by the traffic administration. It's pretty sobering to know there's a price for heads, you know? And they calculated what it would cost to add all this to all these cars, and then they compared that to: okay, we estimate there's going to be about 180 deaths and 180 serious burns, and what would it cost to pay for those deaths and burns for being sued and whatnot?’ And through that calculation, they came up with, oh, it's cheaper to not add this safety feature to the cars. When you have a set of ethical values that you aren't willing to move against, to stretch, or to break, then you’re willing to challenge yourself to think of better solutions, and you're willing to challenge the situation and prod and poke and figure out: where can these numbers move, where can these numbers change? How can we do something that's going to match our ethical values? And just to reiterate that, once they did release the car, there was actually a worse number of deaths and the cost of the lawsuits was even higher—the CEO even said that it was the situation that almost bankrupt Ford. So, Ford might not even be around today if this had been even a little bit worse. Of course, they scrambled to fix it, and the engineers, within a few extra weeks, came up with a much cheaper solution that fixed the car. So, if they’d had a value system in place where they listened to their engineers and said, no this is a big problem we're fixing it; that's too much—can you do better? Can you do better, we won't release this car unless we can do this in a relatively safe way. Then these engineers would have had the possibility of pushing a little bit harder and figuring out a solution that would have been both cheaper and saved lives, and I think that's the most important thing. At the end of the day, your business has to make money. But, if your business also doesn't have these ethical values in place, you as a designer don't have ethical values in place, then these justifications, these calculations, which are somewhat valid in their own rite, lull you into thinking that it's okay to let go of some of the things that you hold dear in your ethical standards. The hidden cost of bad design decisions Oftentimes, dark patterns and harmful things really have a hidden cost. In the Pinto example, there was this hidden cost that people didn't trust Fords for a long time after that. It almost broke the company. In this example, yes the initial amount of income came up, but it was hidden. There were actually cancellations, the brand was getting hurt, and things like that. So, it really just involved trying to figure out what it took to change that person's mind, but in other times when there's no data, it's just a matter of being vocal and being consistent and saying, ‘hey, these are my ethical values’ and just making a fuss over and over again. You'll be surprised how often being consistent and making a fuss works. It's been proven over and over again, right? All the wonderful protests and things that have gone on, being consistent and being vocal. If you're at your company and there are things that you disagree with, first of all, you have to decide what scale do you disagree with it? Is it something that's in your ethical gray area? Is it past the red line for you? This is something I think each designer has to really decide for themselves, and a lot of times, you don't think about it. That's another aspect of the book—we challenge designers at the end to deeply think about it. Where are your ethical values? Because a lot of times we feel uncomfortable, but we do it anyway because we're unsure how we feel about it, and then we regret that later on. Another really important aspect is deciding what's a gray area for you that you're going push back on really hard, and then what's just a red-line subject for you. Another example is right when I joined Intuit, I sent out an email to the co-founder and the CEO, Brad Smith, and they both replied and they said yes. I just asked them, ‘hey, can I talk to you about design and ethical design?’ And they said yes. So, this is a tens of thousands of people company, and all it took was sending out an email and just asking. It was the same way with my previous companies, too. I worked at a 300-person startup and just emailed the CEO. He had been at the company for two days, he was a new CEO, and he was willing to meet as well, and, of course, many of the other managers and staff that I've worked with have been more than willing to have an open ear. I think once people know that someone disagrees with a particular thing, like if you say, ‘you guys, I don't think this is ethical’ or ‘I don't think this is to our brand,’ or what have you, once that's been vocalized, people are much more willing to start backing away from those practices. You'd be surprised. Maps reveal gaps I think, again, for both designers who are just coming into the field, but even some veteran designers, really take stock of your standard of ethics. Read through some of the examples or search on Medium for these types of things. There's a lot of stories out there. Decide for yourself, what are the things that I'm okay with, and what are the things that are a red line for me, and what are the things that are a gray area for me? What am I going to do about those? Make a plan. I think for young designers especially, it's something that you want to know beforehand, because like I said, when you're in the moment, you're not going to have a clear thought; you're going to be kinda confused about what you want to do about it. You don't always have the confidence to push back. But I want to encourage you to do so, and I think that's what you're getting paid for. So, if you're at a job, both paid and unpaid, in the beginning really, it's your job to stand up for your users as a designer. That's why I really think designers have a unique place in all this—of course, engineers, product managers, CEOs, everyone, we're all responsible for this, and I think they'll all have something to learn from the book. But designers especially are in a unique place in the process, where it's literally our job to understand and advocate for the user. I mean, it's everyone's job at the company, but oftentimes, the responsibility of the designer to make sure that happens. So, for young designers, make sure you have your standards in place and that you're willing and capable of pushing back on that and being vocal.

The O’Reilly Design Podcast: The importance of intentional thinking, user-centered data visualizations, and separating functionality from implementation.In this week’s Design Podcast, I sit down with Noah Iliinsky, senior UX architect at Amazon’s AWS group, co-author of Designing Data Visualizations, and co-editor of Beautiful Visualization. We talk about how design is organized at Amazon, 17 keys to success, and why being intentional will ensure you are working on the right problems.Here are a few highlights from our conversation: Design at Amazon Typically, design is organized at Amazon in one of two ways. The first category is, as a designer, you would probably work with the storage team, database team, and networking team. You're sort of the go-to designer for a variety of the product offerings that that larger class of technology has. So, you might be working on two or three products at once for a couple of weeks at a time. Get a new feature out, get a revision out, and then switch to some other product within that class. Those designers tend to sit with the big design pool, all on the same floor. All hanging out together. The other way that the designers typically work is, there are some groups that are large enough that they have a couple of designers working on a single product. So, for example, Quicksight has a couple of designers. And when a product is large enough or has enough UI work that there's more than one designer working on it full-time, they tend to sit with the technology and product managers, sort of dedicated full-time within that group. We're a young organization when it comes to really building a lot of these UI-based products, but it's a very exciting time to be here. We have really good, really supportive leadership in the UX space; there's a real mandate for us to build high-quality interfaces here. So, the designers are part of the very early conversations with product management and with the technology leadership. Typically, it's the product manager who writes the spec of the product we're building. But we have processes in place where that spec gets reviewed by designers who get to talk about whether this is the right product, is this going in the right direction, that's going to be interesting to implement, why are we doing it this way. So, it's a very exciting time to be here as these changes and these innovations are coming along, and how we do this work and really bring designers to the table in the conversation as products are being not just implemented but conceived. Data visualizations I don't think you need to be able to code or you need to know statistics to create good visualizations. Although absolutely it's a help, I wouldn't say, ‘Hey kid, you can't design visualizations till you learn R.’ That's just simply not true. There's plenty of tools that you can use to do it. The biggest flaw really, I think, with visualizations and how it's done today is that people lose sight of the user-centered design aspect. So, this is a thing that I have been writing about and teaching ever since I started talking about it and ever since I started writing about it 10 years ago when I was working on my Masters thesis. It's really bringing the user-centered design approach and this notion of what problems am I really solving with this visualization,  what questions am I answering? And the quick-and-easy approach is, we have some data; we're going to graph it. Done. And that's a really incomplete process because it doesn't actually take into account the customer and what are their needs right now and what questions do they need to have answered right now. I have a pinned Tweet on my Twitter account because a thousand people have said, ‘OK, but what graph should I use?’ This is like asking, ‘What car should I buy?’ I need to know a little bit more about your situation. What shoes should I buy? I need to know more about you. So, I thought, OK, I can compress this entire conversation into one Tweet, which I did. The Tweet says, ‘Step 5. What graph do I use? 4. What data matters. 3. What questions need answering? 2. What actions do I need to inform? 1. What do I care about?’ And the fun part, the cool part is playing with the graph types, so people want to start with Step 4 or Step 5—I've got some data. Let's graph it. Maps reveal gaps If I were to pick one thing I really wanted designers to do differently, I would say to be really intentional about the problems on which you're choosing to spend your life efforts. In terms a little less pessimistic and a little bit more grounded in day-to-day, there are two things I think everybody should do more of and would benefit more from. One is, draw your architecture maps. Draw your flow maps. Draw your swim lanes. Draw a diagram or a map of some kind because you can see where you don't understand the problem when you don't know how to draw the map. And if you skip the map phase and go right to the interface, I guarantee you it's going to be a mess. I've watched that happen. Even at the level where there's an icky part in the architecture map and I say, ‘What's going on there?’ They reply, ‘Oh yeah, yesterday, one of our customers called the PM and said they needed the feature to work this way, so the PM told us we had to do it. So we had to change it.’ And I say, ‘That icky part in the map means you don't actually understand what the requirement is because the PM doesn't actually understand what the requirement is because they got it from the customer and they just threw it over the wall.’ The maps reveal where the gaps in your thinking are and if you think you can draw a good interface when you don't have those requirements defined, it's just never going to work out. So, use the map as a thinking tool. Use a diagram, it's crucial. And the other is one of the ones I stumbled in to accidentally. I accidentally took a class in college. It wasn't the class I thought it was, but it was in the industrial engineering school at the University of Washington and it ended up being largely about this approach called axiomatic design, which is a theory put forward by Nam Suh at MIT. It's essentially this notion of separating the required functionality from the implementation—and we're super bad at that. We go to implementation right away. When I say implementation, I mean if you say a list, now you're talking about implementations instead of function. And really, really knowing how those are separate gives you so much more flexibility and room for so much more creativity and for the solution you're designing because as soon as you say list or window or screen or app, all of those things tie you then to this particular notion of implementation, and they remove from your imagination all the other possibilities of the way this particular problem could be solved.

The O’Reilly Design Podcast: Build measure learn, the One Metric That Matters, and balancing hubris and humility.In this week’s Design Podcast, I sit down with Ben Yoskovitz, investor, entrepreneur, and former VP of product at VarageSale and at GoInstant. We talk about using metrics in product development and why anyone building anything new needs to have both hubris and intellectual honesty. Yoskovitz is co-author of Lean Analytics, and is teaching a two-day course on product strategy as part of the upcoming O'Reilly Design Conference.Here are some highlights from our conversation: Lean Analytics and Lean Startup I think many people will have had this experience where they have an idea, they think it's a great idea. They go out and build something, and they invest heavily in that, from a people perspective, from an hours, from a dollars perspective. They launch it, and nobody cares, or not enough people care, let's say. You realize, wait a second, I've made all these mistakes through that, going through this exercise, going through the motions of building something. Now what do I do? Lean Startup is designed to solve for that, to get you to understand the risks in advance and ‘de-risk’ those things—applying some scientific methodology, or the scientific method, to building products. Lean Analytics is a way of measuring your progress through that process. You need the combination of a little bit of the theory and, well, how do I go about building things? How do I understand what a problem is or how to validate it? How do I do customer interviews? This sort of tactical stuff. Then, Lean Analytics is really about: how do I measure my progress through this so that I know I'm doing it successfully? Not for the sake of just doing Lean Start Up, but so that I can ultimately build something that my users or customers want. Build, measure, learn is at the core of Lean Start Up. When you see it, visually, it's a little cycle. Build, measure, learn—it goes around and around. It's an iterative cycle. We'll say, in Lean Start Up parlance, that you're trying iterate through build, measure, learn as quickly as you possibly can, as frequency as you can to get to the ultimate success. We’re all liars I'll start with ‘we're all liars.’ I say that almost every single time I present. Partly because it's kind of funny, or I'd like to think it is. Partly because it's true. Often, I'm speaking to entrepreneurs, where I think it's particularly true. The reason is, because I think you actually, as an entrepreneur, have to be a bit of a liar. There's a number of reasons for that. One is, you're creating something that doesn't yet exist. You're selling it, whether you're actually selling it or not, but you have to convince others that your vision is real and important. That might be for recruiting people. It might be users. It might be customers. In many ways, you're saying, I believe this thing is true. I'm going to create something to solve this problem or realize this vision. You have to believe me. Let's all agree, that we don't really know if the vision is true. That's where intellectual honesty comes in. Frankly, we say this a lot about the Lean Analytics book, which is, it's not about exclusively using data. It's not about being so wholly data driven that you ignore your gut or insights or anything else. There’s a little bit of lying there. Let's call it a little bit of sizzle before the steak. There's other ways of paraphrasing it. That's one reason. The other, I think, is that entrepreneurs need what I call a reality distortion field. We need to surround ourselves, and I put myself in this bucket as an entrepreneur, because being an entrepreneur is hard. We've all heard that before. It's 100% true. Early-stage employees, I think, would be put into the same bucket, the first handful of employees. You get into an early-stage company and all the risk is there. You have to get up every morning and fight the good fight for what you believe to be true and for the vision that you're working toward achieving. You have to surround yourself in this reality distortion field. Now, having said that, I think where the risk comes is when that reality distortion field gets so strong to the point where you're deluding yourself. That's when, as an entrepreneur, you're running a 100 miles an hour. Another way of thinking about this is ego. Entrepreneurs need ego in order to survive. I believe that to be true. But you can have so much, when you're ego is so big or so strong or so overpowering that you stop listening to other people. You stop recognizing when you're making mistakes. Then, you're going to fail. There's a balance there between ‘we're all liars,’ the reality distortion field, and intellectual honesty, which I believe is so important for entrepreneurs because it's so easy to delude ourselves into believing things that are ultimately not true.

The O’Reilly Design Podcast: The guiding light of strategy, designing Allbirds, and what makes the magic of a brand identity.In this week’s Design Podcast, I sit down with Simon Endres, creative director and partner at Red Antler. We talk about working from a single idea, how Red Antler is helping transform product categories, and the importance of having a point of view. Here are some highlights from our conversation: Bringing the power of nature to the footwear industry One of the founders of Allbirds, Tim Brown, is an ex-professional soccer player. Obviously, footwear was really big in what he was doing. He also went through design school in Cincinnati, but he was being sent shoes and taking a look at the landscape, and he realized that there's no real innovation and thoughtfulness in the shoe category. There's definitely technology and a lot of graphical doodads appearing on shoes, but no company has committed to real innovation to benefit the industry or the world, actually. He was entering into the arms race of high-tech materials and new features. He was like, let's strip everything back and create something that's really elegantly uncomplicated, built around extreme comfort and versatility, and it's made from New Zealand wool, Merino wool, which is incredibly durable and soft. What he wanted to do was hand us the power of what's going on in nature and bring that to the footwear industry. That's kind of the overarching mission. Then he connected with San Francisco native, Joey Zwillinger. Those two started the company, and I met them in New York for a meeting when they were looking for a company to work with. They did a pre-launch on Kickstarter with a Merino wool runner. They got an outrageous response. They spent a lot of time trying to fulfill their orders. Through that learning and through that traction, they decided to double down and really create a business out of it. We were tasked, one, to build out the overarching brand and then build something that moved toward the launch of the Wool Runner, their first shoe. I think one challenge that they were coming to us with was how to bring a New Zealand sensibility without being a tourist postcard from New Zealand. That was really important: how do you translate that culture and the mindset and make it relevant for, initially, the American market? Being here for a long time, I've worked through a lot of brands and communications and advertising, so I felt like I was well positioned to do that. Both my partners love New Zealand and they love Kiwis, so there's a real empathy. We also really loved the mission to transform a category. I feel like with our experience with Casper, the mattress company, we really worked with them and helped them from the ground up to disrupt a really shitty industry, and there are obviously a lot more pain points in that industry. When we came on [with Allbirds], we were involved not so much in the industrial design of the shoe—a Kiwi guy named Jamie was working on that out of Auckland; he’s an amazing industrial designer who we're continuing to work through now. We worked with him, we worked on naming, we worked through the strategic idea and brand identity. The Red Antler strategy We're a strategically led company. Emily Heyward, one of the most brilliant people I've ever met that I have the pleasure to work with, leads strategy. She worked in bigger companies, doing on-the-ground research and groups across the country and the globe, really gaining insights from people and how they feel, what they think. That's been a real core tenant, a pillar of our company. We use that as a way to help companies focus. They find it difficult to get clarity about that single thing they stand for and how to really express that single thing in a lot of different ways. As a business, it’s very tough to have focus; what we do is bring a singular idea that everything we do ladders up to, and acts as that spinal through-line to, both the business and the work that we're doing, so it all feels like it's coming from the same place. In the end, we're trying to create belief systems that feel unique and believable and cohesive and different. You can only do that through having something that's singular. I don't think a solely mission-based brand is going to resonate and really engage people at the level that we really wanted. We wanted to ladder up to something, and this is a very Kiwi thing, the idea was like ‘get up and go’—no fuss, no bullshit, and just freedom. Flick your shoes on, get out the door and get going. To me, it's all about movement and travel and an unfitted life and a sense of ease. The Kiwis have a saying: ‘She'll be all right; just get on with it.’ Then we had other layers to the strategy. We have this big, singular idea that we constantly reference throughout the creative process. We have it up on our wall, we're measuring the work against it, but we also build in other layers to the conceptual framework. In Allbirds' case, we love this idea of curiosity. As a company, Allbirds is very curious about how to harness different materials from nature, how to make the industry better. From a design and brand identity perspective, we have photography and messaging and illustration that's very weird and curious. People are moving off-frame or they're moving in a very unusual pose. We have hands coming in from places and feet walking up stairs. All of these core ideas are great guiding lights for us as we continue to make things. Having a point of view I'm always looking for people who are great thinkers and also great doers. There are incredible design companies out there where the thinking is just incredible and sometimes academic, and the work is beautiful but somewhat abstract. For the kind of work we're doing, we need to be making stuff and doing it strategically. I'm really looking for critical thinkers and people who are curious. We need to be very empathetic with our clients and also the users, so an emotional intelligence is necessary. I look for people who are good listeners but also can communicate clearly. I still want people who have a point of view—I really don't want regurgitation of design blogs. I want people to get off their asses and their computers and get out there in the world, or look at other inspiration to feed into what we're doing. With that, I think having that point of view means you have to take risks. You have to be able to make those creative leaps into unexpected territory. For me, that's where the magic comes. If there's not that moment in the air that no one's ever thought of, even yourself, then that's what I think really makes the magic of a brand identity. Then, I wouldn't say ego-less, because I think you need to have an ego, but I think someone who can work well on a team, working toward a common goal. We have sort of a no-asshole policy here at Red Antler. We've just got an incredible team because of it. There are some really great, hotshot designers that I've met and worked with, but, ultimately, they just didn't stick around because we're just not built like that. We don't have a culture that enables that behavior.

The O’Reilly Design Podcast: Building bridges across disciplines, universal vs. inclusive design, and what playground design can teach us about inclusion.In this week’s Design Podcast, I sit down with Kat Holmes, principal design director, inclusive design at Microsoft. We talk about what she looks for in designers, working on the right problems to solve, and why both inclusive and universal design are important but not the same.Here are some highlights from our conversation: Thinking in systems, building bridges Broadly across Microsoft, I'll just say, there are so many different types of design challenges that we're working on. One of the things that consistently is true is that people look to take on some of the biggest challenges facing our society. There's a lot that comes across the plate of our designers at Microsoft. People who can meet those challenges with an open sense of collaboration and partnership, but also with a very human-led approach to those problems. Really being able to spend time with customers or even just observing people in environments. Not everybody needs to be a full-on researcher, but you do have to have the powers of observation. You have to have the power of human insight to some degree, or at least be able to develop that. Then, you need the ability to translate that into solutions that really, as I said earlier, address a sharp, pointed challenge that a person is having. That's broader across Microsoft. It's pretty wide statement. There's a lot of specialized skills. When it comes to inclusive design, one of the things that's most important is being able to think about broader systems. Thinking about things that are interconnected—if you change one thing at this end of the operating system, what are the downstream consequences and impacts of that? Because there needs to be a heightened awareness of the kinds of obstacles that are being either raised or lowered with every design decision that we make. Inclusive designers need to be thinking about that barrier specifically and help illuminate that for our partners across all product teams that are really driving quickly, but may not always see every consequence or obstacle that comes and goes. Another very important skill for a designer in this space is being able to build bridges across disciplines. To your question earlier about what does design look like at Microsoft, one of the things I'm most proud of and why I love working here is there's a strong emphasis on designing as an act, as a verb, as something that happens only when you have multiple disciplines in one space. There's designing as a way of working, unique and distinct from a designer with specific skills and a specific set of responsibilities. In a job here, when we hire, we’re looking for somebody who understands that kind of bridge building that's required to bring people into understanding the design mindset, the design application, design thinking—ways of reframing and looking newly at maybe very traditional problems or systems. That ability to build a bridge and help other people see as well how that designing journey and process can lead to a better result together is an incredibly important skill. Universal vs. inclusive If you design for everyone, no one is satisfied. It's one of the best and most common questions we get as we do inclusive design. There's an important distinction, I believe, to draw between universal design and inclusive design. Universal design, in a nutshell, could be summed up as one size fits all. It's taking a solution and finding many, many ways to adapt or ways to accommodate or add to to make that work for as many people as possible. Think of the curb cut. It’s certainly a great access enhancement, but you also have to think about the texture that's on the surface of the curb to make it distinguishable for people with low vision or who are blind, because curb cuts pose quite a serious safety risk for people who are unable to see them or notice the transition into the street. There's the chirping of the streetlights that also indicates when it's safe. There's a lot around that, trying to make that one curb cut, which increases access, safe and also accessible for a lot more people. When I think of universal design, it is incredibly important. There’s a long history and practice, especially in the built environment, but it is distinct from inclusive design. Inclusive design, in comparison, would consider one size fits one. The one-size-fits-one idea is really about how you adapt something that is plastic, that is flexible, that is malleable and adaptive, to fit not just an individual person’s abilities, but their contexts, their motivations for whatever they're trying to complete in that moment. One of my favorite examples is playgrounds. I worked with Susan Goltsman from MIG Consulting in San Francisco last year. One of the most important things I learned from Susan was that inclusive design is about creating a diversity of ways for people to participate in an experience so they have a sense of belonging in that place. When you think about a playground, you can look and observe and say ‘What's this playground really great at? Is this all about digging? Is it about climbing? Is it about swinging?’ Then look at how many different ways a truly inclusive playground will give children of all ages, sizes, and abilities—how many ways it gets them to participate in that experience of digging or of climbing. Can you reach the highest point in the playground both by climbing the rope and on a graded path that is accessible to a child using a wheelchair? That diversity of ways to participate really depends on understanding what you're great at, and that distinction in there makes it possible to find things that give people a way of participating with equity, with dignity, but it's not about that one solution having to be modified so that every possible contingency of human ability is considered. It's thinking about multiple ways that people will come into that environment and how they will use that space. “Designing for inclusion starts by recognizing exclusion” One of the most fundamental types of bias is, are we designing something that we ourselves could see? Are we designing something that we ourselves could hear or reach with our hands? One of the most fundamental biases is using our own abilities to design products for other people. Most of that design, at least in the years that I've worked in the industry, happens at a desk, in an office, under a certain type of lighting, in a certain type of environment—maybe not too loud, kind of quiet, or a by team that, for the most part, has pretty similar levels of vision or mobility. It is a real important thing to step back and think about not just how would this work for someone who is blind or has low vision or how would this work for someone doesn't have the use of both of their arms, but to think about how will this experience be used in a noisy, crowded bus? Or in a quiet library? Or a classroom with students with many different learning styles? Those kinds of biases really take a moment, we find with our teams, to just really sit and think about it for a moment. Then recognize who might be most excluded from using that experience. Who might have the greatest obstacles when using that product? We step back. We think about exclusion through, I'd say, three lenses of inclusion. The first lens would be physical ability. Is there something in terms of how we see, hear, touch, move that somebody would experience a barrier? The second one is cognitive—there's a lot to explore and learn there. Have we made the learning process for this new feature work for people with different learning styles, or is it all biased toward one learning style? Then the third one is social inclusion. Where in the world is this product being used? It's not just about language translation, but it's about cultural understanding.

The O’Reilly Design Podcast: Collaborating with engineering, hiring for humility, and the code debate.In this week’s Design Podcast, I sit down with Randy Hunt, VP of design at Etsy. We talk about the culture at Etsy, why it’s important to understand the materials you are designing with, and why humility is your most important skill. Here are some highlights from our conversation: The code debate: It’s not about the code This is a hilarious debate at this point, in my mind. ... I could very confidently get on one side of it with a lot of arguments that I think are quite valid, but you can look at other products, at other organizations, other teams that don't work that way and are also making great products or experiences. It's not like there's one way. The sentiment in it, though, is that deeply understanding how things are put together, how they function, and why they work, makes you better at making them. I really believe that. I think this is true from a business standpoint. I think that you can stretch this metaphor to a CEO of an organization. It's like understanding how bricks can reveal to you the potential that you could take one of those bricks and turn it 90 degrees and create a design element out of the thing that sticks out of the wall a little bit. If you don't understand how that modular system goes together, you may not see the opportunity in how to manipulate the medium. I don't buy the argument that a pursuit of understanding technical implementation is somehow in contrast with or precludes the ability to think about things conceptually or otherwise. I think there's a dichotomy of, ‘Oh, the designer who codes is somehow not user centered.’ One side is about implementation and production, and understanding how things are built; the other is understanding why and for whom you would build those things. These are complementary sets of knowledge. This is an externalization of my own internal experience. I feel like I've been a better designer for this reason. ... I think it is an indication of other personality traits that are also good for designers to have. There is a degree of self-education, really. I think these things are basically learned by doing. You have to. You repeatedly fail when you try to build software, essentially, until you don't fail. It’s a commitment to gaining knowledge over a long period of time, a really applied effort—an ability to switch between sort of procedural logic in a way, A-B choices and understanding things like that, and what something looks or feels like more emotionally. I think that kind of well-roundedness is an indication of success in the kinds of experiences we're trying to create. Design and engineering working together When we're talking about how design and engineering work together at Etsy, the connection point for us is product design and engineering. A culture of change, being comfortable with change and adaptability, is one key factor. The other is a spirit of collaboration and openness. This happens a lot in engineering cultures anyway. It's very much like the DNA of the open source movement or something. The sense of the generous giving and sharing of learnings and things like that is shared across these cultures as well. So, because both those teams or functions have some common cultural themes, there's this natural bridge that helps them work together kind of in spirit. Then how does it actually work in practice? Well, as we built that product design capacity, we initially oriented toward a heavy focus on the designers delivering the pixel to the screen. Designers were executing front-end code, a part of the testing and deployment process that engineers were using. I mean, right down to designers using our deployment tools we've developed in our continuous deployment process, and chatting in the same chat channels with engineers, queuing up their changes to go out to the production servers to be live on Etsy. We really embedded designers in the same delivery workflows, which forced them to develop a shared vocabulary, use the same tools, appreciate the same constraints and lack of constraints in those cultures. You have the shared culture, then you have shared language, right? That helps them work well together. That continues to be true. Many of our product designers continue to work that way. The third part, I would say, is how the design and engineering teams are structured—like where the sense of team alignment is or team identity. They're effectively structured the same way. An engineer and a designer would as much self-identify as being part of the core seller platform team as they would being part of the design or engineering team, if that make sense. The logical chunks of the business or user experience that designers and engineers are assigned to—they're part of cross-functional teams that have an identity and an area of focus. They sit together. They fail and succeed together. It's in those relationships that a lot of the details of, ‘How does design and engineering work together?’ get answered. One of those groups may be much more, sort of, ‘We do these two week sprints, and we structure things this way,’ and there are designers and engineers together in that process. Another team may work a little different, but there's the designers and engineers together in that process. They have a lot of affinity, I'd say, for those kind of business teams in a way that they're a part of. I think that brings them together around shared goals, around shared user needs, around shared impact on the business. Hiring for culture fit I would say the biggest thing culturally—and it's funny because this feels to me like it trumps anything else—is really humility. In the nature of how customer-centric we need to be and how collaborative we need to be, and often how little we know until we've tried some things and learned them, I find that humility is a strong indicator of success in our culture. It can be easy, I think, to interpret that in some kind of soft way, but I actually see it as quite the opposite. It's a strong attribute to be comfortable with things like patience, and to be one of many voices in the room, not the voice in the room, and to operate in a way that is primarily listening mode for a long time before you go into answering mode. That tends to work well culturally for us, and I believe it tends to work well for creating great experiences at the end of the day as well. The nature of how we work is very, very much like a team sport. So we're looking for those kinds of characteristics. The nature of the roles I'm interviewing for and the people I'm hiring personally, versus what other leaders on the team are hiring for, has changed. I like asking people to teach me something I don't know. Like, "Okay, you've got 10 minutes. Teach me something I don't know." In that question, and in those constraints, I think are a lot of interesting things. One, it gives them the opportunity to introduce a topic that may or may not have anything to do with the job or the role they're interviewing for, or our company, or our domain of things. You learn a little bit in how they respond to that. Do they try to position it as being about the business or the role? Which is fine. You get to learn a little bit about their personality. Or do they pull something out of thin air that's probably some topic of interest to them or happened to be the thing they were thinking about that morning? Who knows what it is? You learn a little bit about someone's personality, learn their ability to think quickly. You learn about their communication skills. How can they take this thing and process it quickly, and turn it back around and present it to someone else in a way that will help them understand? It's like this quick, on-your-feet thinking, communication skills, and knowledge transfer. It’s the "What things are you into?" question that I find both fun and illuminating. I also like the time constraint part of it to see how people deal with it. There's this other thing that only a few people have really tapped into, I think, but there's the opportunity to be inquisitive back.

The O’Reilly Design Podcast: Identifying use cases for robots, the five laws of robots, and the ethics and philosophy of robotics.In this week’s Design Podcast, I sit down with Andra Keay, managing director of Silicon Valley Robotics. We talk about the evolution of robots, applications that solve real problems, and what constitutes a good robot. Here are some highlights from our conversation: The evolution of robots Silicon Valley is becoming the epicenter of robotics. I've been managing the Industry Group, which started as seeing robotics as a very small and new industry and Silicon Valley, as more or less an unknown area of the robotics.I think in the last five years, that's changed significantly; now, people look to Silicon Valley to see what is happening in robotics and AI. It seems like every major company and every government now has robotics and AI on their strategic road map. That's just the measure of how things have shifted in that spectrum between research and the real world. I think it was called ‘crossing the chasm.’ Various aspects of robotics are really crossing the chasm. When we say robotics is in its early days, we've actually had a very solid industrial robotics industry for the last 50 years, but it has been not very visible—and what I would call stupid robotics these days. It's large, rigid robotics, and they've been used for manufacturing, for electronics, automobile construction, welding, and dangerous materials handling; to a lesser extent, you've seen some of this technology used in areas like mining, port handling, and some of those logistics and defense industry applications. What's changing right now is the robots of the 21st century are more affordable. They're smaller. They're more flexible, more agile, both physically and in terms of how easy they are to program, to an extent. This is very early stages, but that's where things are leading. One of the critical things is that there are now more ‘collaborative robots’; we call them collaborative robots because they are rated as safe for operation around people. So it means that instead of having a closed-cell workspace, a workspace which is very, very clearly separated between where a robot operates and where everything else happens, we can start to consider ways of integrating robots into human activity, whether that's having a compliant, safe, collaborative robot on a factory line that can be moved around or whether that's having an autonomous vehicle that's navigating. While initially this may happen more in factories where people are used to applying robots as a solution, it's starting to happen in areas that are non-factory based—areas like airports, any kind of package handling facility, retail malls, and hospitals. Hospitals are actually early adopters. A real use case for robots: Farming One of the other areas that interests me is agriculture because if we look at where the world has big problems that need to be solved, one of the clear issues is that our population is continuing to increase. It's well over seven billion, heading toward 10 billion in the next 10 or so years, and it's not just that the population is increasing, but the demands that we're making on our food production resources are increasing beyond the population increase. Everybody is predicting that we need to double food production in this next generation. So, by the year 2040, how do we double the world's food production when we can't double the acreage? That's just not possible. In fact, we're losing arable land as the population increases because cities tend to be built on the exact same areas that are fertile and accessible.We're increasing our demand for protein in particular, which requires even more land to grow, to tend, or to harvest, and here's the other thing: we're losing farmers. Particularly coming from New Zealand and Australia, I'm very aware that we have one of the highest rates of urbanization in the world, but this is being realized around the world now. Australians almost completely live in cities these days, and the average age of a person on the land is looking at retirement. They're within five years of retirement age, and there is no replacement. Most farmers have sent their kids to university, and most of them don't want to go back to a backbreaking manual labor job. We've also lost, certainly in Australia and New Zealand, access to cheap, seasonal labor. So, I see shades of this same problem replicated in most every country around the world. The population is increasingly urban. ... If we look back at the spread of the automobile, it took 30 years to reshape our cities and our suburbs, and for the ecology of the car, the social ecology of the car, to come into place. It changed jobs. It changed culture. It changed law. It changed the infrastructure. So, we're at the start of the rollout of robotics. How can we do the best we can to see things rolling out in the best pathway? I've been tracking groups that look at the ethics and philosophy of robotics and also discussions around law and standards, and it seems to me that valuable as each of those groups are, they're often acting after the fact. Design is the field that operates ahead of time, as it were. So for me, this is the most fruitful area to look at how to get the best possible robots out in the world today. How do we engage with robotics as it's being built in the earliest stages? I think the design community can play a very important role there. 5 laws of robotics Let’s start right at the very high-level, top-down law that is the first one people will think of, which is that a robot should not be designed as a weapon.Secondly, robots should comply with existing law, including privacy law. What follows for me from this is the third one, that robots are products, and as such, they should be safe, reliable, and not misrepresent their capabilities. I think that is actually a very significant one that we're seeing a lot of companies stretch way too much at the moment. The fourth one is this more sophisticated argument that robots are manufactured artifacts and they convey the illusion of emotion and agency, and that should not be misused to exploit us. There are many situations in which that could be misused. Now, the final one is that it should be possible to find out who is responsible for a robot. Now that gets difficult. That seems very obvious, but it does get difficult. Who does own or control a robot? Is it the software? Is it the hardware? Is it the person who's using it? Is it the person who built it? Each of these laws or guidelines unpacks into some complex things that need to be negotiated in each situation, but it speaks toward the heart of what I think a lot of the ethical and philosophical dilemmas are about, and it points toward the fact that in many cases, we have an existing legal framework that says these are the things that society considers acceptable and these are the things that society does not. If you're following these good design guidelines, then you're building something that is going to fit into what we broadly know is considered acceptable social behavior. Unfortunately it's very easy for people to do something because it's new and it's unregulated, and then they can do something that turns out to be potentially very poor. I mean, 3-D printing weapons, there's one example. Uneducated use of drones is another example.

The O’Reilly Design Podcast: Solving problems, user-centered design, and culture at NASA.In this week’s Design Podcast, I sit down with Jay Trimble, mission operations and ground data system manager, for the Resource Prospector Lunar Rover Mission at NASA. We talk about applying Agile, adopting design thinking and user-centered design, and what he and his team rely on to design and build software for mission control.Here are some highlights from our conversation: Agile at NASA As far as Agile goes in my group, it was probably around 10 years ago when we started to become Agile; we didn't really set out with a stated goal of being Agile, at least not in the beginning.  We were having issues with our software development and we were trying to make it better, and by iteratively solving problems, we found we were starting to match—what was then certainly much less mainstream than it is now—the Agile method. We had a six-month delivery cycle. We would take a set of requirements, and then we'd deliver six months later; we were out of sync with our customer because of that. One of the first things we did is shorten our delivery cycle. Now, we're at a three-week cycle and nightly builds. These are fairly mainstream things now, but they were more new then, and we went from getting feedback every six months from our customer—I mean feedback on software, not feedback on designs—to getting feedback daily. We would put out a nightly build, and every time we had a new feature, we'd get direct feedback from a customer the same day. That's just one of many examples of how we were trying to solve the problems that we had, and we also had a nice kick-start along the way from IBM. I talked to some colleagues at IBM, and they had been through some of this process of going Agile; because they were a large organization, it seemed very relevant, and we had some good technical interchanges with them to help us kick-start that. Management was very supportive, but once again, we didn't plant a flag in the ground and make a proclamation, ‘We're going Agile’; we just solved problems. Design thinking at NASA I think of NASA, really, as a hardware-focused system engineering organization. I don't mean to say that we don't use software and that we don't emphasize software, that it's not critically important—because it is all of those things—but really, when people think of NASA, they think of rockets rising up on launchpads or rovers landing on Mars or a spacecraft flying by Pluto. We couldn't do those things without software, so in terms of design thinking, and this is also true for our Agile development methods, we really started with software where we felt we had more familiarity with how to apply it. System engineering thinking would be, "What are my requirements? How do I validate those requirements? How do I reduce my risk?"  Design thinking—in that environment, at least in the way we have approached it—is providing a pathway to not getting overly focused on your first idea. We know this is an issue, right? It's an issue that design thinking addresses. I have my first idea, I take it and become very invested in it, and I run with it. When you're saying, ‘What is my requirement,’ it's very easy to go down that path. We try to provide an environment that is open to ideation, that is open to evaluating ideas early, where we prototype ideas, where we iteratively move things forward. We have also done user engagements through ethnography—in some cases, interviewing users, doing things you don't typically do in a system engineering process. Now, there are other groups here who apply human computer interaction and other things. My group is focused on just one set of design methods. We started, as I said, with software and we became Agile, then we integrated the user-centered design techniques we were using at the time into those Agile workflows, which goes back to something I was talking about earlier where we’re using the nightly build, the software build, and having our designers involved, getting daily feedback from our users. Now that we built some confidence in doing this with software, we're starting to move it to other areas, which is also very exciting. I mentioned the Resource Prospector mission to the moon, looking for water at the poles. There, we're taking some of the mission processes of, how do you drive a rover doing near real-time command and control? By that, I mean it's only a matter of seconds until we get the telemetry back, so we know what happened versus if you're controlling a rover on Mars, it could be up to 40 minutes before you know what happened. It's a very different way of interacting with a vehicle off-world. We are doing early prototyping, early simulations, where we put the team together and we'll try something, then iterate on those ideas, refining them and building on them. In system engineering, some of this prototyping would be called a ‘risk reduction prototype,’ so it fits the mindset. Some of this is a matter of mapping mental models, where you are bridging these different ways we think so that people can understand. If I say ‘a risk reduction prototype,’ that's a great fit in system engineering, and of course, prototyping is integral to design. The tools of NASA I mentioned ethnography; we do user interviews, we do user observations in context, we do a lot of wire framing, we do a lot of prototyping, and we do journey maps. We just did our first design sprint, which was a Google Venture-style design sprint; for that, we brought in an outside facilitator to help us out, but I will also say that we had spent years working on and applying participatory design techniques. The design sprint actually has a lot of similar methodologies to what we were doing in participatory design, but it certainly takes it much further and puts it together into this amazing way of validating a concept in a very brief period of time. I thought participatory design was a great way to bring in stakeholders and address some of the issues we were talking about earlier. We would sit around a circular table, and we had a facilitator who was an expert in these techniques; we would bring in all of the stakeholders, and through these participatory design methods, we would create a shared understanding, a common language, and we would get the user directly involved and invested in the design work we were doing. I thought it was great stuff. In order to do that, you have to have a tremendous amount of access to your users; we don't always have that, but when we do, participatory design can be a great technique.

The O’Reilly Design Podcast: Pricing design, charting your learning path, and working with friends.In this week’s Design Podcast, I sit down with Dan Mall, founder and director of Superfriendly. We talk about what skills designers should learn, pricing your work, and why getting to know yourself is just as important to becoming a great designer as learning the craft.Here are some highlights from our conversation: Working with friends I have a fairly non-traditional company, the design collaborative that I run. It's called SuperFriendly, and I'm the only full-time employee, but oftentimes the projects we do have multiple people on them. The business model is called the Hollywood Model if anybody wants to research it. Of course, I brand it and I call it the ‘Super Friend Model.’ Basically what that means is that for every project that SuperFriendly does, I bring together a team of people to work on those projects. Some of those are contractors, some of those are other shops, maybe design shops, or research shops. Sometimes it's moonlighters, you know—people who have full-time jobs who want to do something at night and on weekends. Depending on the project, as long as they're the right people, I try to make it work with wherever they're from or whatever they're also currently doing. It's kind of the way that Hollywood makes movies—a movie studio doesn't employ directors, or actors, but they bring those people together and they make a film together for a year. They all kind of go their separate ways after that. Designers should know how to... There's this debate that breaks out—on Twitter, or Facebook, or wherever designers are talking—every couple of months about whether designers should code, and people vehemently argue for both sides of this. I'm in the camp that says designers should “blank”—insert anything there, and the answer is probably yes because it's just to say, should you be getting better as a human and learning more things? Absolutely. There's no pain if you don't. If you don't learn to code, and you're a designer, that's okay, but I want to try to make the argument for why those things are actually beneficial to you as a designer. Some people see that as not part of a designer's job, but I see that as very much a part of a designer's job. That actually helps you, it helps your teams, it helps the products that you're building. The talk [I’ll give at the O’Reilly Design Conference in March] is really about how to manage this: should designers learn code, and then should they learn business, and then should they learn sales? Should they be strategists, should they learn Ruby on Rails, should they learn about the back end? The answer is yes if you can. If you can do that, absolutely, but how do you prioritize that stuff? In the talk, I'm going to be sharing some stories about stuff that I've learned along the way of doing projects as part of SuperFriendly teams, and how I've seen other people handle that. How do designers who code work differently than designers who don't code? Can both of them be equally as effective? I'm going to try to make a case for how coding, specifically, can help a designer's skill set, and how that could actually help influence a product, and product direction, and move even faster and more efficiently without losing quality. A lot of the talk is going to be centered around ways to prioritize this. Should you learn X code first, or should you learn HTML, or should you learn strategy, or should you learn Lean UX? How does that fit in—people are saying Agile is going to help, and people are saying Lean is going to help. How does all of that stuff fit in? Ideally, my goal for this talk is to help designers make sense of all these terms that are floating out there, and if they’re willing to learn, where they should start. Hopefully, I'll be able to shed some light on that. The value is not the craft learning. There are so many ways you can learn craft. There are all these great things that can let you learn how to code Ruby on Rails, or how to design, or learn flat design, or whatever. I think the tougher thing, the one that everybody experiences, and experiences in a different way, is that there's always some issue beneath that. For some people, it's self confidence, for some people, it's time management, for some people, it's feeling like a professional, for some people, it's imposter syndrome. Those are really the things that we work on. That's the thing that takes nine months to conquer or to work through. Learning a programming language, you can do that in 12 weeks. That's why there's all these boot camps out there that are fairly successful. It's really becoming a professional. Pricing design I wrote a book, Pricing Design, and the basic premise of the book is that people pay for things they really want. Not an unobvious concept, but sometimes we forget that when we're pricing in business. We think it needs to be so ‘businessy’—I’ve got to plug a bunch of numbers into a spreadsheet that does some fancy multiplication, and add some padding and accounts for this percentage, and subtract this thing, and then the discount thing, and then the magic number that gets output from the other side is a good qualified price. The truth is, it actually couldn't be further from the truth. As you described, pricing is emotional. We buy things because we want them. We buy things because we like them. We buy things that are logical and illogical. That's how people's minds work. Whether or not you're buying on behalf of a business or you're selling on behalf of a business, it's still people selling to people and people buying from people at the end of the day. There's a lot about pricing psychology. There's a lot about the way people think about money and value that I think we don't take advantage of as designers and developers and business owners. That's the basic premise of the book—just try to understand what you're selling and what your client wants to buy. I'll take web design as an example. A lot of web design agencies and shops and freelancers think they're selling websites. No one ever is selling a website. No one buys a website. Nobody wants to buy a website. They buy the thing that the website will do for them. The website is the thing that will let me sell this cool jewelry that I make. If I didn't have a website, I couldn't sell my jewelry effectively.

The O’Reilly Design Podcast: Designing for trust in finance, conversational UIs, and the value of a weekly oasis.In this week’s Design Podcast, I sit down with Steph Hay, head of content, culture, and AI design at Capital One. We talk about designing for voice interactions, connecting with remote team members, and the importance of baking humanity into AI. Here are a few highlights from our conversation: Culture at Capital One ‘Follow the fun. What is your gut telling you? What is the challenge that you want to take on in your life?’ This was what it was, the culture at Capital One—we're a founder-led company, which I don't think many people know. We just started in the 90s. We're not that old. I think there's a natural entrepreneurial culture already here that I got to step into, and it enables me to still be entrepreneurial and enables me to still be curious. People want to do great work, and they're excited to come to work—and all of that makes for the kind of culture I'm describing. Designing for Alexa How people talk about money is completely custom and emotional and nuanced. The way that we have historically designed for that as an industry is to create our own language that you have to learn—things like ‘available balance.’ That's an industry term that has become, to some degree, accepted, but the way people talk about available balance when we ask what that means, they say, ‘How much money I have left on my credit, available to me on credit.’ Something that's about how much. It's not a label. It's like an outcome. When we're designing for any voice-based conversations, the more we can find the natural language that you use to talk about money and design that into the experience, the more we'll have enabled a new kind of interaction with us that mimics real life. That's the opportunity that we've been capitalizing on so far. Just a couple weeks ago at the Grace Hopper Women in Computing Conference, it was really a joy to be on stage with my coworkers, who all worked on this recent release together, announcing ‘how much that I spend.’ If you're a customer of Capital One and you've enabled the skill on Alexa, you can ask, ‘How much did I spend at Starbucks last month or how much did I spend at Amazon last week? How much did I spend last weekend in general?’ Because that's how people think. They're not going to look for transactions, but that's how we typically set things up. All that foundational work is so vital to us because now we can take all that foundational work—accounting and managing budgets and that sort of thing—and translate it with this new layer of conversational interfaces. What’s Up Thursday We started a weekly meetup internally called 'What’s Up Thursday.' I joined Capital One a little bit more than two years ago. There were maybe a few more than 100 folks on the design team at the time across 10 different locations. I wondered with my boss, a small group, whether or not we could actually do weekly share outs, design critiques, drawing on the work of adapter pattern weekly design sessions, that sort of thing. We said, ‘I don't know. Well, let's give it a shot.’ This conversation came up right before Christmas. I think it was like middle of December two years ago. I said, ‘Why don't we try for the first Thursday in January?’ Two or three weeks later, we tried to bring 100 people together over a video conference and have somebody present some work and then do a group discussion and facilitate that among the design team. It seemed like it wasn't going to happen, but it happened. We all looked at some work that people were doing, and there was great discussion. We continued to iterate on it over the course of the year. Now, every single Thursday, our team gets together, and it's a combination of group critique and just sort of what's up, what's going on. Somebody shares something inspirational. Sometimes people play their guitar and sing a song. Somebody juggled for 10 minutes while giving us a talk on user experience. It is this weekly oasis—or we try to at least make it a weekly oasis—for the entire design team, which now numbers more than 300. People come together, and we chat and Slack and learn what's going on— learn what's going on with each other and connect with each other and see the work that we're doing, and celebrate the work we're doing and celebrate failures.

The O'Reilly Design Podcast: The VUI tools ecosystems, and voice gender and accent selections.In this week’s Design Podcast, I sit down with Cathy Pearl, director of user experience at Sensely and author of Designing Voice User Interfaces. We talk about defining conversations, the growing tools ecosystems, and how voice has lessened our screen obsession.Here are a few highlights from our conversation: What constitutes a conversation? To me, I do have a definition of ‘conversational.’ I was talking about this at O’Reilly Bot Day last week. For example: my Amazon Echo. I don’t view the Amazon Echo generally as conversational because most of the things I do are one-offs. I’ll say, ‘What time is it?’ or ‘Turn on the lights’ or ‘Set a timer,’ and she’ll give me one response, and we’re done. If I go up to you and say, ‘How are you doing today?’ and you say, ‘Fine,’ and then we turn and walk away, I don’t really see that as having a conversation. That would not be a very good conversation. One of my definitions for ‘conversational’ is that it has to have more than one turn. A lot of times, with a lot of these voice assistants—let’s say, you can do multiple turns but they don’t remember what you said before. Each turn is like a brand-new conversation, which would be really annoying if you were talking to somebody and every time you said something, they didn’t remember anything you told them before. In relation to that, they really need to understand pronouns. This is something that humans or toddlers can understand. I can tell a toddler to, ‘Go get the red ball out of the green box,’ and it knows it. The kid knows that I want the red ball. Computers have a really hard time with that. It’s starting to improve. Google, especially, I think, is working hard on this task. I've heard that with Google Home, they’re going to be better about that kind of thing, but those are some of the things I think systems need to be conversational, and that could be either through voice or through text. Designing for how people talk not how you want them to talk My biggest principle and advice is to design for how people actually talk and not how you want them to talk. I think as designers and developers, we get very focused on whatever we’re building, and we think it’s very obvious: ‘Yes, the user will know what they can say here.’ It’s really not true. Especially if you're designing something like a virtual assistant, like Siri. She says, ‘How can I help you?’ That really sets up the user for failure in a lot of cases because you really can’t just say anything. There’s a limited number of things you can say. We need to spend a lot of time thinking about how will we communicate with the user, what they can actually say. There’s different ways to do that. One thing that’s really important is when you're first designing your system, spend a lot of time writing what we call sample dialogues, which are essentially back-and-forth conversations, like a film script between the voice user interface and the user. You write these down. Then, you read them out loud with somebody. You learn very quickly—if I wrote the system and I am reading my voice user interface prompts, and then I have someone else responding, I learn very quickly, ‘Really, someone would say that? I didn’t expect that.’ You can really build your system well from the beginning by doing some simple design exercises like that. Another thing that’s really important to understand about voice is that speech recognition is not perfect. Yes, it’s way, way, way, way better than it used to be, but it still makes a lot of mistakes. You have to build a graceful error recovery into every voice system no matter what. I don’t think, personally, that it will ever be a 100%. Accurate human speech recognition is certainly not 100% accurate. You have to spend a lot of time thinking about your error recovery. The tools ecosystem I’m actually very excited right now because I think we’re starting to see a lot of tools actually come out, and I’m looking forward to learning a lot of them. For example, there’s a company called PullString. They used to be called ToyTalk. They made the Hello Barbie and some kids’ apps like the Winston Show. They just put out an authoring tool. I downloaded it. I'm really looking forward to trying that for creating new sample dialogues, new stories. Then, there are things like TinCan.ai out of Conversant Labs, which I think will be really great for doing prototyping, which is something we’re solely lacking in the real world, the ability to do quick prototyping. Then, you’ve got a mixture other tools from places like API.AI, which was bought by Google; Nuance’s Mix; Wit.ai, which is Facebook. These allow you to build models by giving a lot of sample sentences and having that learned. For example, if you’re trying to build a calendar VUI, you might put a bunch of sample sentences in about how I want to schedule an appointment. It can learn from those examples so that when somebody says something new that you didn’t already write down, it can still understand. I’m just very excited that these tools are finally coming out. It’s always been the Holy Grail of the voice user interface, where we were always trying to build tools at Nuance. It’s very difficult to do. Hopefully, we’re really getting to the point where they’re workable.

The O’Reilly Design Podcast: Design education, mentoring, and what design skills matter the most.In this week’s Design Podcast, I sit down with Danielle Malik, designer, owner, and mentor at Design Equation. We talk about mentoring the next generation of designers, what she is learning from recent design grads, and the role fear can play in our work.Here are a few highlights from our conversation: Design Equation: Bridging the experience gap between design education and a job Most people who teach will tell you it's a great way to reexamine what you believe about a given topic, since you have to explain it and repackage it for others. I started Design Equation to address a couple of problems that I'd been seeing in my career. The first issue is basically around the cost of design. Very often in my career, there'd be a client that I wanted to work with. They had a really cool product or a really great mission, but the economics of it just didn't work, and there's only so much pro bono and discounted work that you can do. ... The second issue that I was trying to solve—I became more aware of ‘the other shoe drops’ after General Assembly for me because I was finding that some of my students who I thought were very driven and very talented, really poised for success, were having trouble landing a job in the field. Very often, they're hearing that they need more real-world work in their portfolios, and having been a hiring manager, I totally get it. People don't want to be the first one to take a gamble on a new designer. Designers are really hard to evaluate, the junior ones, because all their portfolios tend to look the same. They work in group projects, so you're never entirely sure what work is theirs. They don't have references related to design work. All this makes it a challenge to hire junior designers and definitely creates a wall that they're bumping up against when they try to get out in the field. Working with General Assembly grads The things I'm finding about junior designers—I was getting inklings of these things at General Assembly, but my work here at Design Equations really confirmed it. First of all, they're really capable of a lot. General Assembly is a 10-week program. You could realistically have very low expectations for these people, but they do fantastic work, and the thing I try to impress upon them, too, is the ability to explore. In that, I have high expectations for them. I do find that when you have high expectations, people will rise to meet them. Another thing I'm noticing about them is that they really value direct feedback. Not all of my designers are millennials, but I think about that millennial stereotype where everyone gets a trophy, and don't say anything mean or they'll get mad, and that's not true at all. The people that I work with, they really want direct feedback. They really want me to give it to them unfiltered and uncensored. They're here to grow. They understand that I'm here to help them, and they also understand that I'm doing it from a place of love. That's another misconception I think people have about these junior designers, that they should be coddled; I’m really finding the opposite is true. The last common thing that I'm finding about junior designers—and, frankly, this could apply to any of us at any age—is the role that fear is playing in their lives. They're especially vulnerable because they've taken a big risk on this new career. No promise of a job at the end of it. They come in and the fear could really sabotage them. It could really sink the work they do to be consumed by the self doubt, to be insecure, to worry about their abilities and also the qualities of their ideas, but I always address it very directly. We talk about it when it's coming up, and I also try to give them a space where they feel safe to take risks, and to try things and actually fail if they need to, within a safety net that I provide because I feel like we talk a lot about how failure is good, fail fast, all this, but then when they actually get in the workplace, it's like, ‘No, no. You put on your game face. You fake it till you make it. You cover up your mistakes.’ I try and provide a different experience around fear that hopefully helps them manage it better. The balance of what to learn UX is an incredible shapeshifting profession. I still feel like in my 15 years, the core of what I do has remained the same. I'm hired to be a critical thinker and a problem solver, and that really hasn't changed over the years, but in my time as a designer, UX has not only come to me and the full stack of UX activities from research to design to testing and prototyping, but these job descriptions more and more are including visual design, very often including code. Designers really need to be familiar with data and analytics now. Underlying all of this through my whole career has been our drive and our fight for strategic influencing companies. That, too, has a set of skills that are required, increasing your business acumen, being able to understand market opportunities, things like that. There’s already so much that we could theoretically be responsible for knowing. Then on the horizon, we have gestural products, IOT, robotics, there's AI. All of these things are pulling from different fields, fields that we'll be collaborating with. For some reason, UX is like this blob. Anything we touch, we have to assimilate and say, ‘I really ought to know how to do that, or I ought to be more familiar with those tools and tricks.’ I fear that we just keep growing and keep pulling in more of these skills as being required. I hope that we stay grounded in our roles as critical thinkers and problem solvers at the core, but this growth and this continuous requirement of new skills, I think, is a detriment to us.