O'Reilly Design Podcast - O'Reilly Media Podcast

Julie Stanford on vetting designs through rapid experimentation

Thu, 17 Aug 2017 12:20:00 +0000

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.

John Whalen on using brain science in design

Thu, 27 Jul 2017 11:00:00 +0000

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.

Cheryl Platz on designing the Amazon Echo Look

Thu, 13 Jul 2017 14:00:00 +0000

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.

Cynthia Savard Saucier on design at Shopify

Thu, 08 Jun 2017 11:25:00 +0000

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.

Travis Lowdermilk and Jessica Rich on building a customer-driven culture at Microsoft

Thu, 25 May 2017 10:50:00 +0000

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.

Matt LeMay on the four principles of product management

Thu, 11 May 2017 11:00:00 +0000

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

Nate Walkingshaw on capturing the approaches and techniques of successful product managers

Thu, 27 Apr 2017 11:05:00 +0000

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.

David Farkas on how to approach user research

Thu, 13 Apr 2017 11:00:00 +0000

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.

Jonathan Shariat on the importance of identifying your ethical design red line

Thu, 30 Mar 2017 11:05:00 +0000

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.

Noah Iliinsky on design at Amazon

Thu, 16 Mar 2017 11:55:00 +0000

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.

Ben Yoskovitz on lean product development, using metrics to build successful products and companies

Thu, 02 Mar 2017 14:55:00 +0000

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.

Simon Endres on designing in an arms race of high-tech materials

Thu, 16 Feb 2017 12:00:00 +0000

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.

Kat Holmes on Microsoft’s human-led approach to tackling society’s challenges

Thu, 02 Feb 2017 12:00:00 +0000

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.

Randy Hunt on design at Etsy

Thu, 19 Jan 2017 12:25:00 +0000

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.

Andra Keay on robots crossing the chasm

Thu, 05 Jan 2017 12:30:00 +0000

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.

Jay Trimble on user-centered design, Agile, and design thinking at NASA

Thu, 22 Dec 2016 12:00:00 +0000

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.

Dan Mall on designing with friends

Thu, 08 Dec 2016 12:40:00 +0000

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.

Steph Hay on designing for Alexa

Wed, 23 Nov 2016 12:40:00 +0000

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.

Cathy Pearl on designing conversational interfaces

Thu, 10 Nov 2016 12:15:00 +0000

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.

Danielle Malik on mentoring the next generation of designers

Thu, 27 Oct 2016 12:20:00 +0000

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.

Kristin Skinner on designing design organizations

Thu, 13 Oct 2016 13:50:00 +0000

The O’Reilly Design Podcast: Design investment, the importance of mindset, and creating the right environment.

In this week’s Design Podcast, I sit down with Kristin Skinner, managing director at Adaptive Path, head of design management at Capital One, and co-author of Org Design for Design Orgs. We talk about managing design teams, scaling design, and what we can learn from the Golden State Warriors.

Here are a few highlights from our conversation:

Helping companies realize their design investment

There’s the famous Mark Andreessen quote about software eating the world. Back in 2004, Tim Brown was on the cover of Businessweek Magazine declaring that design can help shape business. That trend has been happening over time, but it’s really been over the last 10, probably even five, years where design teams are really starting to scale. We recognize the generative qualities for design can help to realize new business value, and that the old methods of management around development, specifically, that require a real keen focus on efficiency and a real keen focus on value that you’re getting out of every hour, every line of code, etc., doesn’t fit well. It doesn’t sync up with the generative qualities of design.

We also recognized that there’s a shift right now, or a trend, where you have the raw talent. There are a lot of schools and programs now where you can actually get your certification in certain disciplines of design, but there’s really a big gap in figuring out how to scale design. Most design books, most information that you find out there, and we found this in our research to be true, they’re mostly about design practice—so, what sort of tools, what sort of methods and approaches and processes for doing the design work exist and are shared broadly, and then the case studies to show how that work has actually affected products and services out in the real world. That target audience is really meant for those design practitioners.

We believe design should be a core competency. It should be on par with sales, information technology, development, marketing, etc., but it’s not as mature a practice. That’s why we really wanted to focus on helping organizations see a path to get there and hopefully in the future be able to talk even more broadly about what those success stories look like.

Hiring: Looking for the growth mindset

For me, it’s mindset. There’s qualifications, obviously, that once you’re talking to somebody, you assume that you’ve met all of those. First and foremost, it’s mindset—especially for the roles on the team I’m building or hiring for right now. It’s things like being able to read the room. It’s having confidence. It’s being a good facilitator, being able to understand when to really push and when to lean back, when to lean in and when to lean back.

Let me see if I can give you an example: soft skills, things like negotiation, facilitation. Those are the big ones. Really, communication was huge. That’s in a bucket in and of itself. The mindset for me has always been one of the leading indicators of how successful somebody’s going to be. You can assess that pretty quickly, even through a phone call, but certainly face to face I think it’s something you can really appreciate—really understanding how people approach different problems, to how people approach their work, how people approach collaboration. Those are the areas that I really like to focus on to help figure out who’s going to be successful and who may not be the best fit.

Design management: Creating an environment to succeed

I think from a design community perspective, what’s really been interesting is seeing a lot more activity—not just here in the U.S., but globally around design management. That’s been really fascinating to see and to hear how we’ve come from ‘I just need to get the design right’ to ‘I just need to get the strategy right’ to ‘I just need to get the design organization right.’ It’s part of why we wrote the book. We even talk about it situationally—just think about the Golden State Warriors. In 2013- 2014, they had a different management team than they have in place right now. They were a team of exemplary players, and they lost in the first round of the playoffs. Management is out, new management came in, and the very next year they were NBA champions. It’s not a coincidence. There’s a responsibility from managers’ perspectives to really, really focus on creating their environment.

Tom Greever on articulating design decisions

Thu, 29 Sep 2016 10:25:00 +0000

The O’Reilly Design Podcast: The CEO button, an IDEAL framework, and converting likes into works.

In this week’s Design Podcast, I sit down with Tom Greever, UX director at Bitovi and author of Articulating Design Decisions. We talk about how to effectively explain your design decisions, avoiding the CEO button, and how saying 'yes' is a facilitation superpower.

Here are a few highlights from our conversation:

The CEO button

The CEO button is an unusual, or otherwise an unexpected, request from an executive to add a feature that completely destroys the balance of a project and causes designers to cry themselves to sleep. You hear this referred to in other areas as the 'Swooping poop,' or as the 'Hippo,' which refers to the highest paid person in the room.

It's this very common sentiment that there is someone who doesn't know anything about design, they are in charge of us and our projects, and our destiny, and they're paying our bills, and they get to make that ultimate decision. They are the people we have to convince, and often it feels very much like what they're asking us to do is irrational, or it's the wrong choice, or it doesn't make sense to us, or they're not trusting our expertise.

In the case of the CEO button, there can be a disconnect between what the stakeholders and the business want or need, or what their felt needs are, and what we think needs to happen. A lot of it is because we focus so much on the user, on say usability, may be even on the visual design, or the beauty, or simplicity of our work.

I think we spend so much time, rightly, focusing on the people at the other end of our products that we forget about the people who are also in our meetings, and who have the authority to say yes or no to our positions.

Leading with a "yes" and the IDEAL framework

Using the word 'yes' is meant not to do anything, and everything stakeholders say, if they can just have their way with your work, but again to foster this idea that we agree we're going in the right direction. That's definitely part of the first step. In the book, I go into a lot more detail, but I have this acrostic that I call the ideal response to design feedback. It's an acrostic where each letter of the word 'ideal' stands for part of the message that you want to deliver to them. The I is to identify the problem, that the first step is to talk about, 'Okay, here's the problem that we're chasing after, right? This is the thing that we're trying to solve.' The D is to describe your solution: 'Here's how I've solved this, and this is what we believe is going to actually fix that problem.'

The E, then, is to empathize with the user. Again, we still have to bring the user into it because we may be the only window that our stakeholders have into the lives of our users, so it's absolutely important that we bring that to the table. Sometimes that is in the form of data, or a user test, or an interview, or something, but we need to remind them of the person on the other end. In the next one, which is the other side of that coin, is that the A is to appeal to the business because it's not enough to just say, 'Here's the solution for the user.' We have to let them know how that's going to help the business. This is going to be more about some sort of metric, or KPI, or goal that we have as a business. If we make these choices, we actually believe it's going to help us improve conversion.

Then the last one, which is absolutely critical, and it's kind of the crux of the book, the L is to lock in agreement. Getting agreement at the end of this process is super important because if you leave that meeting without agreement, then you're just going to languish in indecision. Even if you're not sure of the direction, it's better to do something, even if it's wrong, than to do nothing at all. You have to be direct in saying, 'Do you agree with this? Can I get your approval?' I think it's okay to be that direct and be sure that we force them to give us a clear yes or no, because if it's no, we need to restart that discussion and figure out where we went wrong. If you don't have that L at the end of the word ideal, then all you have is an idea, and we need something more than just an idea, something that we can actually get out into the marketplace and help people.

What you like vs. what works

One of the things that I hop on a lot is this concept of helping our stakeholders convert likes into works. That is, to get people to move from talking about what they like and what they don't like, which are just their preferences, and this purely subjective concept of design, to what works and doesn't work, which speaks more to the effectiveness of our work, or the usability of our applications. It's way too easy for people to come in and believe that our design's subjective, and what they like matters the most. 'Oh, well, I just don't like it, and so we can't do it that way.'

Paul Adams on Intercom’s mission to re-humanize customer service

Thu, 15 Sep 2016 11:35:00 +0000

The O’Reilly Design Podcast: Connecting humans at scale, bot philosophy, and failed attempts to defy the laws of physics.

In this week’s Design Podcast, I sit down with Paul Adams, VP of product at Intercom. Before joining Intercom, Adams had stints at Dyson, Google, and Facebook. We talk about his career path, building design teams, and Intercom’s goal to connect humans at scale.

Here are a few highlights from our conversation:

Human connection at scale

We are building a customer communication platform. The backstory here is really simple, to be honest. When you think of business—how businesses run in the real world, like offline, without the Internet—if you go back 20 years, before the Internet was commonplace, it was all personal. It was typically face-to-face, marketplaces and stores, and so on. People knew who they were buying from. There was a bit of a relationship there. There was trust and loyalty. The problem with that was that there was no scale. A local store could only sell to people within a certain geographic radius.

The Internet brought scale. Suddenly, anyone in business could now sell to anyone in the world, but with that scale came problems, like, ‘Oh, I just sold this product to a thousand people and now a hundred of them have a complaint, and I need to deal with those complaints,’ or ‘I'm sending this email announcing our new thing to these one million subscribers, but, oh no, if any of them reply, I'm screwed.’

The way this evolved was that the technology to support these things became impersonal. They kind of removed the personality and the human connection from it, so you've got things like ‘do not reply’ email tickets, and if you have a problem, you have to get a ticket and get in a queue. It's just inhuman, honestly. Our mission is to fix that, so that customer communication on the Internet becomes personal again. You see the names and faces of people; it's much more like real life—it's more rewarding, it's nicer, you feel some level of a connection; you get to talk to a person, not to some machine. We're building software, building tools for businesses, to connect much more deeply with their customers.

On bots

We've built a bunch of bots. We have bots in Intercom. We're working on more. We've tested them a lot, we've used them a lot, we've put them in beta. We've had customers use them, and we found out the use case for bots is quite narrow today. There are scenarios where talking to a bot is faster than talking to a person, but there are many scenarios where talking to a person is way better than talking to a bot.

If you work in customer support, a bot doesn't have empathy. A bot can't deal with someone who's annoyed, or angry, or upset. These are scenarios in which a person is going to be better than a bot. Then, at the other end of the scale, queries that are easily automated. If you simply want to know when your next bill is due, and how much it’s going to be, a bot can answer that way faster than a human. A computer can answer that way faster than a human. There's a range of interactions, and many of them will need people, for a long, long time, possibly forever. Some of them are better with bots, but that's kind of where we're at today.

We also have a philosophy that we don't blur the two. This is quite different than what Facebook is doing. Facebook is kind of deliberately blurring them, so it's unclear if you're talking to a bot or to a person. They're doing that for a bunch of reasons, but we're just in a philosophically different place. We think it's better if you know. If you know you're talking to a bot, you can have appropriate expectations, whereas if you know you're talking to a human, you can have other expectations.

Dyson’s approach to design

Dyson was an amazing experience. I was there for about two years. I originally joined a team called NPD, which is ‘new product development,’ and at the time, Dyson was having huge success, obviously, with the vacuum cleaner. The culture there was one in which we thought we could reinvent everything. Things like kettles, or toasters, or ironing, anything that was very stable and hadn't changed in a long time was ripe for a re-think. The first half of my time there was just crazy, working on crazy ideas, like how to think of new ways to boil water. Could we disrupt the kettle? The hand dryers, actually, that Dyson released shortly after I left—the genesis for that was actually trying to re-design the iron. We actually failed at a lot of the re-thinks. A lot of the physics didn't add up. It was the laws of physics that prevented us from making things better. That kind of lasted for the first half of my time there.

The other interesting thing about it was that Dyson kind of merged design and engineering. James Dyson's philosophy was one in which engineering and design are basically two sides of the same coin. My title there, I think, was actually ‘product design engineer.’ As I said earlier, I went to art college. I'm not an engineer. I think I designed a lot of things that can't be made. They just would never come out of a mold if you actually tried to make them. It's fascinating, because it was very much the expectation that in order to design something, you needed to know how it was going to be made. There was a very, very heavy emphasis on engineering.

Kristian Simsarian on design’s next big challenge

Thu, 01 Sep 2016 11:00:00 +0000

The O’Reilly Design Podcast: Design education, design thinking, and the need for more wisdom.

In this week’s Design Podcast, I sit down with Kristian Simsarian, founder and chair of the undergraduate design program at California College of the Arts. We talk about design education, design thinking, and the need for more wisdom.

Here are a few highlights from our conversation:

On giving back

I asked Kristian to comment on his colleague Ian Coats MacColl’s post, an open letter to Jony Ive:

There was something, and it was probably taken partially out of context, that Jony Ive had dismissed design education in some way or another. A lot of where that's coming from is that demand outstrips supply. There just aren't enough designers on the market, and companies like Apple and Google and Facebook and all the other ones are feeling it acutely. In fact, when we have our internship nights, we have far more suitors than we do students, which we like. In fact, we have the companies pitch to the students.

One of the big things, and you might have heard this from one of your other podcast guests, is that there's often this ratio of creative people to engineers. Either it's five-to-one or 10-to-one, and then the Obama Challenge of, I think, 2012 was we need a million more STEM graduates by...I think it was 2020 or 2022. If you were to use, say even the 10-to-one ratio, then we need 100,000 creative people to match them. All of the art and design schools together aren't going to create that. We're just too small. We have five or 600 graduates a year, and then there's 13 of us here. Maybe if all of those were perfectly aligned, we'd squeak into 70,000 or 80,000. If you're really going to meet the creative need of, honestly, this nation and the future of the economy here and the creative economy and everything, you really do need all the schools to start bringing design in some genuine way.

What we can learn from preschools

Very often, preschools and a lot of the flavors of preschools—like the Montessori and the Reggio Emilia and Waldorf as well—are really looking at giving students things they're passionate about, following their passions, nurturing their creativity, giving them agency in either an inquiry or a project. Then somehow it gets lost in our traditional K through 12, but I see a lot of the K through 12 working on that and really trying to break it down. It doesn't always work with national standards and things, but you see a school like Nueva or something that doesn't necessarily have to appeal to that. It's a school in California that really does an amazing job on social emotional stuff and project stuff and is pretty exclusive. To their credit, they also run an education program for other schools, which is really nice. In some ways, as a college professor, I'm trying to do something to get back to what kids were doing in preschool actually, which is getting back in touch with their impulses and what they want to do, and their making, and their own inquiry.

On teaching

There's the giving back. There's the sending the elevator down and letting other people rise up, and then there's also the things that it gives you, which is of course, we're more generous. That's a real gift in itself, to yourself. There's the transformation of finding your voice, and finding your leadership voice can be really powerful.

Working on what matters: Design’s next challenge

The first thing that comes to my mind around what's needed in the design community, especially around technology, is more wisdom. I say this because I think we are good—we often talk about making the right thing and making the thing right—and I think we're pretty good at that, to a certain scale or a certain scope. At the same time, I think we need to be thinking bigger and probably more systemically. I give a very tactical example that affects everyone's lives today.

Right now, phones have become this object that gets pulled out, and it steals people's focus, in a way. I remember about four or five years ago, I took a picture of everyone at the Cal Train stop, which is our local commuter train. Everyone was looking at their phone, and I thought that was astonishing. It made sense too. It's like, everyone's just disappearing for a few minutes, so instead of just gazing around or talking on the phone, they're staring at their phones.

When I look at that from a designer's perspective, I think designers who are doing an excellent job in meeting, for example, the KPIs—the key performance indicators of their organizations, like getting people to use this thing more, all those traditional web metrics, more impressions, more eyeballs, more consistent use, more messages, whatever those things are—I think they do an excellent job of that, but yet, I don't think any designer is really proud of the bigger culture that they've created. This everyone's focus being on the, as one of my friends calls, 'the fondle slab.' That they're just looking at these things and stroking these glass screens and people are disappearing. A lot of people are talking about that. I feel if we somehow had more wisdom about what we're doing, we'd be able to look at the bigger picture and have more influence on what we're trying to do.

I really like what Tristan Harris is doing with time well spent and saying, how can we design differently?

I don't know a Facebook designer, whether the most junior or the most senior, who doesn't say, 'We influence a billion people every day.' I'm not sure if we're able as designers to slow down enough to really think about what that means to influence a billion people every day.

Doreen Lorenzo on design becoming the core DNA of an organization

Thu, 18 Aug 2016 11:55:00 +0000

The O’Reilly Design Podcast: Designing women, avoiding the buzzword curse, and the F word.

In this week’s Design Podcast, I sit down with former president of Frog, Doreen Lorenzo. Lorenzo is currently the director for the Center of Integrated Design at the University of Texas at Austin. We talk about the design in education, women in design, and failing fast versus learning fast.

Here are a few highlights from our conversation:

On being a female designer

I can tell you that I think I went through the first 20 years of my career not even thinking about it. Putting my head down, doing the work that needed to get done. Working really closely with all my employees. Creating a great environment. Leading an organization. Making a business successful and profitable. I think I just did all those things. I never really thought about being a woman. I thought at one point, "Well, we've come far." Then I put my head up as we sometimes do in life ... and said, "Wow, we haven't come that far."

I would say the number one similarity I see with women is they're suited to be fabulous designers because they're so empathetic. Most women that I've interviewed are really empathetic and really understand the importance of understanding your user, understanding their employees and creating an environment where creativity and doing your best work thrives.

ROI on design

I have spent pretty much 20 years of my professional career trying to emphasize the ROI on design, the value of what design brings to an organization. I lightheartedly, but truthfully, say, ‘When I started out in this industry, designers weren't allowed to have a seat at any table,’ were barely allowed in the building—the people dressed in black, the crazy people who said silly things.

You can see the evolution where you were kind of allowed into the building especially when it was cold. They were nice enough and put us in the back of the board room. Now, what you see is design is all the rage.

I'm very happy about that, but I want to make sure is that it doesn't turn into the buzzword of innovation, that design really becomes part of the core DNA of an organization. This is the only way their change is actually going to happen, and design thinking by its nature, which is really just the name for a methodology that designers have always used. It's a problem solving methodology. Organizations have to understand how to be agile, how to work quickly, how to have creative, autonomous thinking that goes on in problem solving.

Learning fast vs. failing fast

We're in a continuous learning environment all our lives, at least I hope we are. In scientific methodology, the more false results you get, the closer you get to success. That's looked upon as something that's good. In business, if you don't get it right the first time, that's looked upon as something that's bad. I think what we're learning along the way here is that we have to make sure that people have the ability to learn and gain knowledge, because the more you can learn, the closer you can get to success.

I think that's what the design methodology allows you to do. You're testing, you're prototyping, you're getting the results, and you're seeing where you are along the spectrum. I think we should stop scaring people about the concept of failure. I see that in the university. These students are so afraid to step outside because they don't want to fail. That's a really bad thing. It's not about failure. It is in fact about learning. You get better at things when you know what doesn't work versus when you know what does work.

Giles Colborne on how AI is reinventing design

Thu, 04 Aug 2016 13:15:00 +0000

The O’Reilly Design Podcast: AI, understanding algorithms, and design diversity.

In this week’s Design Podcast, I sit down with Giles Colborne, designer, author, and managing director of cxpartners. We talk about how AI is reinventing design and the roles of designers; the balance of creating something that is different but familiar; and how, at its most basic level, AI is shortcutting user input.

Here are a few highlights from our conversation:

Artificial intelligence

The trouble is, there's a dirty little secret there, which is mobile; it's the platform that people want to use. If you give them a choice, they'll reach for their smartphone every single time. It won't work very well. You look at eCommerce sites, the average conversion rate on an eCommerce site is something like 4-4.5% average globally. On a mobile site, it's less than 2%. Although the conversion rates are rising, they're rising at the same pace. Usability of desktop is getting better, but at the same pace as mobile.

That's terrible. That means a lot of businesses are seeing their traffic shift to a channel that actually doesn't work as well, but people would like it to work well. At the same time, these devices have become incredibly powerful. At the same time, organizations are suddenly finding themselves flooded with data about user behavior. Really interesting data. … The interest in AI at its simplest, the crudest application of AI, is simply to shortcut user input. That's a very simple application, but it's incredible powerful. It has a transformative effect.

Understanding algorithms

What's interesting is, in talking to a lot of people who are incorporating this into their design practices, themes are emerging. Amber Cartwright at Airbnb said a very simple, profound thing, which is if you want to design a thing, you have to understand it. If you're going to design with algorithms, you have to understand them. Like all of us, she's running a design team. She can't just send everyone off for three years, get them a degree in higher mathematics, and we'll see you when you've done that.

She did the sensible thing, which is she said, "We're running mixed teams. I'm going to put the design teams and the data scientists next to each other, and I'm going to get them to draw out what it is they're trying to do." That's a very simple thing, but immediately, she started to see people sketching out, "This is what this looks like. This is how this works." By drawing it, the abstract becomes concrete. By drawing it, there's a common language. By drawing it, you get that spark.

Design’s balancing act: Different but familiar

On one hand, you have this globalization of design. Through the network, design patterns spread incredibly quickly. That leads to a great sameness in design. You see that when Apple or Google releases something; that pan spreads incredibly quickly and ends up everywhere. That's good, because it means that there's a familiar common language.

The challenge of design is, how do you have that familiarity and common language and respect preserve the diversity of design? People are going to, at some point, react against that, and they're going to say, "I want this to be different, but I want it to be familiar, too." I think diversity in the design output, diversity in the design community, also, is incredibly important. That's the input, if you like, to the design output.

Jim Kalbach on mapping experiences

Thu, 21 Jul 2016 11:00:00 +0000

The O’Reilly Design Podcast: Collective alignment, shared value, and design thinking.

In this week’s Design Podcast, I sit down with Jim Kalbach, designer, instructor, and author of Mapping Experiences. We talk about the relationship between design and design thinking, how to get started with mapping experiences, and the notion of shared value as a strategic competitive advantage.

Here are a few highlights from our conversation:

Mapping experiences: The great aligner

The strategic function of the activity of mapping experience that I focus on in my book, is about helping organizations to really see the world differently through the eyes of the customer to the degree possible. That's just one tool that helps us do that. It's not a silver bullet, and there's other things that people do, like personas and other types of research, and other types of activity, so I think it fits in with a range of things that we're doing to help us understand the complexity of end-to-end experiences.

How is that value perceived by the customers? Sometimes the value that we think we're creating isn't perceived that way. It's really about that outside-in perspective. It starts by aligning to the outside, toward the customer perspective. That's a collective alignment. It doesn't matter if there’s one user researcher, one business stakeholder who has that perspective. Is the team aligned? I talk about two levels of alignment in the book. That one is aligning the perspective toward the customer, but then it's getting on the same page as a team.

… I think there are five questions that you need to ask. I recently just wrote a blog post on this. ... The five questions are, what's your point of view? What's the scope? What's the focus? How are you going to structure the information? How are you going to put it to use?

Design vs. design thinking

Design thinking is not what designers do. I always say, 'Designers design.' Design thinking is a way to apply that type of thinking to other problems, so we use design thinking to solve business problems, or we use design thinking to solve marketing problems, right? Obviously, we use that to solve service design challenges as well. What design thinking does, in my opinion, is it kind of demystifies that magic wand that they think designers have.

Designers feel comfortable with uncertainty, I think—you have to be to be a designer, because you don't know what you're going to end up with at the end of the day. To some people, that's kind of scary, and I think what design thinking does is it gives them a framework to feel comfortable. To say, 'It's okay if you don't know the answer. We're going to show you a way that you can consistently get an answer, even if you don't know what that outcome is before you get started.'

Shared value: Doing good while turning a profit

Shared value is a concept that Michael Porter, the famous strategist, Harvard Business Review professor, literally wrote all of the classic volumes on business strategy. The concept of shared value is something that he pioneered, I think it was 2012; it was articulated in a landmark article in the Harvard Business Review called “Creating Shared Value.”

He's thinking about, what's the next thing? What he's saying is companies aren't solely about maximizing profit anymore: it's about maximizing profit and contributing something back to society. He's saying that's where companies are leaving money on the table. It's actually a strategic and a business move—he's saying that we have to not only think about the products and the services that we deliver and what the competitive advantage of those are, but also how are we creating those? Who are we partnering with? What are the materials that we're sourcing with? What's the environmental and educational and societal impact of the way that we do business? You can turn that into a competitive advantage. … I think this idea of moving from shareholder value, maximizing your bottom line, to shared value, how do we maximize the bottom line and contribute back to society—I think that's just a fascinating movement.

Mike Kuniavsky on the mindshift needed to design for ecosystems

Thu, 07 Jul 2016 11:00:00 +0000

The O'Reilly Design Podcast: Designing for IoT, service design, and predictive analytics.

This week's episode of the Design Podcast features a conversation I had with Mike Kuniavsky last fall. Kuniavsky is a user experience designer, researcher, and author currently working at Parc. He's also a speaker at the upcoming O'Reilly online conference "Designing for the Internet of Things," September 15, 2016. In our chat, Kuniavsky talks about designing for the IoT, service design, and the mindshift needed to design for ecosystems.

Here are some highlights:

Every new medium is the old medium

I was reading this book that was published by Philips Design on their Ambient Intelligence project. They actually thought through the entire Internet of Things thing about 15 years ago, and then they couldn't make any money on it, and all those people went away. Now it's actually a real thing. They left some really good documentation. I was reading the Philips Design book, and they had a very interesting point from mine and probably one of Tim O'Reilly's favorite theorists, Marshall McLuhan. McLuhan essentially said that the content of every new medium is the old medium. Every new medium subsumes the old medium of the content until you actually figure out what the new medium is.

When television came about, the stuff that was initially on television was essentially radio, until they actually figured out what television was good for. When radio came out, it was people reading the newspaper on the radio, until they figured out what radio was good for. It's like that going all the way back. Right now, in the Internet of Things, we're in this place where the content of the Internet of Things is the pre-Internet of Things world. It's all of the things that are either currently not connected, which are everyday objects, or it's the electronic things which are being shoehorned. What we're trying to do is we're trying to get over that hump and trying to figure out what are the natively interesting qualities of the Internet of Things that make it really different than home automation, which has been around for 30 years and has been an abject failure on every front, or simply connecting appliances to the Internet.

On UX design and service design

We're really looking hard at service design as a model. The funny thing is, service design isn't even a mature thing. It's not like we can import an entire discipline. Service design was a just a couple puzzle pieces just a couple years ago. It wasn't a finished product as it is. We're trying to take those puzzle pieces and we're trying to say, OK, now what happens when all of these different components of a service, these different things that service design is looking at—they describe front of house, back of house, different kinds of players and actors within that space—what if we replaced some of those with devices? What if we replaced some of those things with sensors and actuators? What happens to the service in that situation? That's how we're trying to envision an entire ecosystem without actually having any of the pieces of it in place.

There's this slippery slope between service design and UX design. I think UX design is more digital, and service design allows itself to include things like a poster that's on a wall in a lobby, or a little card that gets mailed to people, or a human being that they can talk to, and what does that human being say and under what circumstances do they say it. Service design takes a slightly broader view, whereas UX design is still—and I think usefully—focused largely on the digital aspect of it.

Pattern matching and predictive analytics

I'm interested in, broadly speaking, predictive analytics—I should say, machine learning, statistical modeling, but specifically in predictive statistical modeling, predictive machine learning. I think that really that is the new superpower. That is literally looking into the future with some degree of confidence. In a place where you would never normally be able to look into the future, like identifying how often I pick up my cup of coffee. My cup of coffee would never have been able to tell me that before. Now it can. Again, to some degree, and that's really interesting. That's really a different relationship. That's to me a big shift in our relationship to our everyday objects and their relationship to how they can—as per my earlier point—how they can make our lives better. That's why I'm really interested in the predictive stuff right now.

We as humans have no idea how limited our sensors are, our own personal ability to sense the world. We're really good at pattern matching in certain ways, and we're really not very good in many other ways, and we've never really had a very good way to compensate for that. Now, to some extent, we do, and that's really interesting.

Martin Charlier on progressive approaches to IoT design

Thu, 23 Jun 2016 11:30:00 +0000

The O'Reilly Design Podcast: Designing for the IoT, design's responsibility, and the importance of team dynamics.

This week's episode of the Design Podcast features a conversation I had with Martin Charlier last fall. These days, Charlier is a freelance design consultant and co-founder at Rain Cloud. He's also a contributing author to Designing Connected Products and a speaker at the upcoming O'Reilly online conference "Designing for the Internet of Things," September 15, 2016. In our chat, Charlier talks about designing for the IoT, design's responsibility, and the importance of team dynamics.

Here are some highlights from our chat:

Holistic IoT design

How I got into the Internet of Things is an interesting question. My degree from Ravensbourne [College of Design and Communication] was in a very progressive design course that looked at product interaction and service design as one course.

For us, it was pretty natural to think of products or services in a very open way. Whether they are connected or not connected didn’t really matter too much because it was basically understanding that the technology is there to build almost anything. It’s really about how to design with that mind.

I’ve always looked at products and services that way, that they might be connected or they might not be. It’s really almost like electricity. You might have an electric product or you might have something that isn’t powered.

When I was working in industrial design, it became really clear for me how important that is. Specifically, I remember one project working on an oven. ... In this project, we specifically couldn’t really change how you would interact with it. The user interface was already defined, and our task was to define how it looked. For me, that was where it became clear that I don’t want to exclude any one area, and it feels really unnatural to design a product but only worry about what it looks like and let somebody else worry about how it’s operated, or vice versa.

It seems to me that products, in today’s world especially, need to be thought about from all of these angles. I think you can’t really design a coffee maker anymore without thinking about the service that it might plug into or the systems that it connects to. You have to think about all of these things at the same time.

Designing with the environment in mind

Designing a physical object is less, I want to say, less task-driven. The usability, the task aspect of it, is only one facet of the whole experience. You have to think about the aesthetics and much more about the emotional qualities of a product.

I think materials and manufacturing processes as well, and that also relates to an environmental responsibility, for example. As an industrial designer, if you design a physical object, you have to think about where that goes when it’s at the end of its life cycle and what kind of material do you use to make it and where do those materials come from.

The Fairphone project, for example, is interesting. One of the things they talk about is that they use only conflict-free materials. It’s not just about the material being renewable or coming from a sustainable material source, but it’s actually also about the social responsibility and how do these, especially precious metals, for example—where do they come from? What are the labor conditions where they come from?

Combination interfaces

What I see already is that there are new combinations of input and output types that are being put together to form interfaces. A really good example is the Nest Protect. It speaks to you; it uses synthesized voice to give you information, like which room was smoke detected in.

I think that’s a really interesting one because it’s not really a voice. I wouldn’t classify it as a voice interface because I’m not interacting both ways through voice. Voice, for me, would be something like Siri, where I’m speaking to it and it responds to me.

What I’m interested in seeing is products that come up with a certain combination of some kinds of inputs and some kinds of outputs that happen to be appropriate and make sense for their particular product. I think that’s where it starts to feel natural, where you don’t really think about whether Nest Protect is a voice interface or another kind of interface. It just makes sense that the device would try to give you more information through the medium of speech because that’s actually the best way for it to do that.

Equally, I think touchscreens are probably going to stick around for a very long time because they’re such a commodity. Everybody knows how to use a touchscreen now. People now go to screens that aren’t touch screens and want to touch them because they have this expectation now that you can touch a screen and interact with the elements on it.

I’d like to see these new combinations. A former colleague of mine from Frog, Jared Ficklin, did a brilliant demo. They call it RoomE, which is a connected room. They’re exploring the idea of what room-sized computing would look like. What if the computer was my house, effectively?

One of the things they’re doing in the demo is this idea of multimodal input. In his demo, Jared is pointing at a lamp and saying, “Turn this lamp on.” And it knows which lamp you mean and it’s able to make sense of, “What do you mean by this lamp? Which lamp do you mean? And why are you pointing at a lamp?”—it puts them together and figures out, “Right.” It feels like, “Why am I even explaining this? It’s so obvious.”

I think it’s a long way away to have that stuff in practice. I’m sure there are a lot of things we have yet to experiment with in terms of whether that actually catches on. I’m not sure.

Chris Maury on voice-first design

Thu, 09 Jun 2016 11:15:00 +0000

The O’Reilly Design Podcast: Designing conversational experiences.

In this week’s Design Podcast, I sit down with designer Chris Maury. Maury is the founder of Conversant Labs, working on projects intended to help improve the lives of the blind. We talk about designing for the blind (as he loses his sight), how chatbots might just make us better listeners, and principles for designing the best conversational UIs.

Here are a few highlights from our conversation:

Designing for voice

I found out that I was going blind. I was diagnosed with a genetic disorder called Stargardt macular degeneration—I was going to lose my central vision and currently was losing my central vision over the course of 10 years or so. That was about four years ago.

Throughout this entire process, I started looking at the tools and the technologies that were available to the blind community to use, or the tools that I would be using to maintain my standard of living and keep being productive, and was really disappointed with the quality of those tools. I set out to try and build a better experience. That's what got us started with Conversant Labs.

The realization that we had is the way that accessibility tools, especially for the blind, are constructed is fundamentally flawed. The core technology is called a screen reader. It takes what's displayed visually on the screen and then it reads that aloud to you. All of the work that goes into designing and optimizing this visual experience has been, really, thrown out the door and forced into this single-dimensional audio stream for people who can't see.

When you think of who the blind population is as a whole, the vast majority of people who are losing their vision are losing their vision from aging related disorders. They have trouble with email, let alone trying to navigate an email inbox with a keyboard and moving this cursor that's then reading each item out individually. Rather than follow this model, we thought: what if we built applications for audio first? What would that look like? How would you interact with that? We got to this point of voice and conversation being the best way to do that. It's a much more natural experience. You talk to the product and the product speaks back to you. That's where the name of the company comes from, Conversant Labs. Our goal is to create a world where everything that I can do on the smartphone that's in my pocket, I should be able to do non visually or without taking that phone out of my pocket.

The first thing that we did moving down this path was build a fully conversational shopping application and a partnership with Target, called SayShopping. It allows the blind and visually impaired, really anyone, to search for products, to get reviews, and compare those products, and then purchase them all with your voice. It was the first app that ever allowed you to buy something with your voice. It was received really well, and we learned a lot about what it takes to build a voice-first, and a primarily non-visual, application and the different design challenges there. We've taken those learnings and are trying to make that available to everyone else through developer tools. We're releasing an SDK for the Apple products so you can add voice to existing applications.

We're also looking at design tools so that a designer can go in and build out a very rough version of the conversational interaction and then be able to sit down with a user and have them go through it, and then test it. How does someone express what you want? For a search, for example, how does someone express searching for a product. Are you going to say, "Search for a toothbrush," or, "I'm looking for a toothbrush," or, "I need a toothbrush, or, "I ran out of toilet paper"—all of these different ways of expressing this idea of wanting to search for something that you might not necessarily think of and being able to get to those at the design phase, rather than once the voice app is out in the wild.

Deeper insights into designs, problems, and tools

It's definitely given me something to focus on. When I was in the Bay area, I knew I wanted to start a company and I would have all these side projects working on things, but I could never focus on something for more a month or two before wanting to switch to the new, shiny idea that I had. It's definitely helped me to focus. In terms of the tools that I use, it's been a mixed bag. I do use the screen reader for everyday, and I use the free open source one called NVDA, with a mouse. I have a giant monitor with the color inverted and the font blown up pretty big. Then I use the mouse, and whatever the mouse highlights, that text is spoken aloud. It works pretty well.

I think I'm as productive as I was before. I do a lot less mindless web browsing, than I did before, because it's harder to navigate individual web pages, but when I do find something, I read so much more now because I've trained myself to listen to books at a much faster rate, because those books are being read to me using text to speech. I can listen to those at 650 words a minute.

It's one of these things... it's helped me to read a lot, but I think the realizations that I've had—and going back to this question of how it's changed the way that I think about designs and problems and tools—is yes, it's a disability in a sense, but in a broader sense, it's just a different way of consuming information, and there are pluses and minuses to that different context of interaction with a product. Yes, someone who has a visual impairment can't see the screen, and they're going to have to interact with that audibly. What impact does that have? Can you create the same level of intuition and experience and create as efficient an experience through audio as you did visually? I think when you think about things like being able to listen to something at a much faster rate, you can potentially have experiences that are even more efficient or more productive than what you would consider the normal or standard experience.

Lessons learned in voice design

The user should always know where they are. Being able to say, what can I say or where am I, or what can I do, and those types of questions are really important. The other is talk. Have the app speak to the user as little as possible, because the more it's speaking, it's latency and the experience are loading times for a page. It just makes the app feel less responsive. The user should always be able to interrupt the app when it's speaking because, again, waiting for it to finish talking is an unresponsive application. Present only the most important information first and then allow the user to ask for more detailed information. In the shopping example, just saying the title, the price, the star rating, and then a brief description and allowing them to prompt for reviews or product specifications or more detailed description and things like that.

Max Burton on what we can learn from Nike and Disney's approach to design

Thu, 26 May 2016 12:00:00 +0000

The O’Reilly Design Podcast: The future of wearables, hiring designers, and understanding the value of design.

In this week’s Design Podcast, I sit down with Max Burton, founder of Matter. Before starting his own firm, Burton spent the last two decades at places like Frog, Nike, and Smart Design. We talk about the future of wearables, what he looks for when hiring designers, and what tech companies can learn from Nike’s and Disney's approach to product design.

Here are a few highlights from our conversation:

Design at Nike and what tech can learn from their approach

When I was at Nike, the designers were instrumental in defining what products they were going to work on. We actually would write the briefs to our own products, and it was the designers who often came up with some of the most innovative products and product ideas. It didn't come from a separate marketing group, it didn't come from a strategy group, it often came from the designers. The executives at Nike understood and valued design and allowed the designers that level of autonomy and control.

I've worked with a lot of tech companies, and they tend to be either run by or founded by engineers. I love working with engineers. They're incredibly inventive, they know how things work, and they can put things together in meaningful ways. They're often very obsessed in their area, and that's not exactly what the end user might want. I think what designers do is they really think about the end user, they have that level of empathy. Also, companies like Nike are brand driven, design driven, and the focus is much more on the user. It's also the aspirational user—it's the emotional side of a product experience, not just the functional side.

I think that probably is the emphasis—that design or design-led companies understand the human, the emotional side, the artful side, and that that has an important value. That people who buy products at the end of day, these products have to fit into their lives, they have to be something they want, something they want in their home or to wear on their bodies. The emotional side has to be recognized, and perhaps a lot of the tech companies are still a little bit engineering-led.

The future of wearables: Disney

I worked on the new My Magic Plus for Disney, which is basically making the park into a smart park. Part of that solution was a wearable that connected to the park. The great thing about this product is that it was actually a really, really simple product. It had no display on it. It's a band you wear, but it's connected to the park, so it's connected to a series of sensors in the environment that enable certain things like entry into the park or payment for merchandise or food, or entry into your hotel door without a key, or access onto a ride without having to wait in line. A lot of these developments in wearables requires an environment that's networked and smart. I see that this is a very exciting new path for wearables, where it's not about just you and the wearable; it's about you, the wearable, and the environment you're in.

The work that was done at Disney is kind of indicative of where the future might go. For example, you can imagine in the future that a city like San Francisco could have a similar kind of network of sensors and at that the wearable could connect with the city, or you as a person in that city could connect with that city. I think that's a very likely future, and if someone thinks, "Well, that's crazy—cities like San Francisco are much more massive and complex than the park, the Disney park." Well, that's actually not even true because if you go to the Disney Park, they have more than 16 million guests a year; they have more than 100 restaurants in the park; they have complexity of all of the hotels and resorts that guests could stay in. It's almost equal to San Francisco, so I think it's very likely in future.

T-shaped designers + storytelling

IDEO define what they call the T-shaped designer—that's somebody with a deep expertise in one specific area, but a general knowledge of others. I look for that as well. If I'm taking on an industrial designer for example, I expect that they have an amazing skill and talent in their area of designing and making physical product. I also look for their ability now to understand the digital world, to understand interface, to understand experience design, and to be willing to think of their profession more broadly. In today's modern world, you need those kinds of broader thinking skills. That applies again for the interaction designers, that they must also be very skilled and adept at their profession, but at the same time, have an interest and passion for the physical world, and know how to work in the physical world as well.

We still have to deliver, we still have to make products, so that depth of skill and knowledge in one's area of expertise is required. The ability to work with others is also paramount. The other thing that I'm emphasizing a lot now as well is that design is, in a way, moving toward filmmaking, if you like, because with experiences or service-based design, you're thinking about a consumer's experience over time and space. The best way to design with that level of complexity is by creating narratives and stories with characters, and I find this is a very good way to anchor the team or to provide the guiding power for the designers to work toward. If they can share the narrative, then they can each go off in their areas of expertise and create the outputs from that narrative.

We always try to put some storytelling and a narrative into our project plans, and that might start in the beginning with defining our personas and characters. Then it's creating a journey map or a day in the life of a person; and then, throughout the UX track, we further that story and often we end the project with a short three-minute or five-minute film with live actors that basically explains how the product is used. That's a very good method of communicating a product idea that's physical and digital, and we've had a lot of success with that.

Carl Bass on design tools

Wed, 25 May 2016 12:45:00 +0000

The O’Reilly Hardware Podcast: Autodesk’s CEO talks about the future of design.

In this episode of the Hardware podcast, we talk with Carl Bass, president and CEO of Autodesk. He’s an articulate thinker on algorithmic design, collaborative tools, and the nature of craft, and we talked for nearly two hours when we visited him to record this episode.

Discussion points:

Bass tells us how Autodesk’s Fusion 360 used GitHub as a model for file management and online collaboration. Fusion 360 lives partially in the cloud and will be accessible through a browser in the near future. “The big thing we tried to do was get rid of this idea that you need 12 pieces of software and 12 plug-ins,” he says.

Autodesk’s Project Dreamcatcher illustrates the role that artificial intelligence will play in design. “In the places in which design can be easily quantified, I think you’ll see a lot of machine learning being applied,” Bass says. “When it gets to more aesthetic considerations, that’s still the domain of us.”

“The best way to introduce new tools in the workforce is through college students,” Bass says. “The next generation entering the workforce is totally fluent in tools, almost as fluent and expressive with design tools as someone with a paper and pencil.”

This week’s click spirals:

From listener Samuel Harrold: polymagnets, which have customizable magnetic domains. Here’s a video that demonstrates their unusual properties.

Jon Bruner: Before “telegraph” referred to the electronic telegraph, it referred to a system of semaphores that relayed messages visually. Inventors developed a variety of visual telegraph systems in the late 18th and early 19th centuries, and they were used widely in Europe for transmitting military and government orders until the 1840s.

David Cranor: A video of Claude Paillard making vacuum tubes by hand. Specialized glassware was commonly custom fabricated; MIT, like other institutions, had a glass workshop that made laboratory equipment (it now offers classes on glassblowing and related subjects to MIT community members). Another fun specialty manufacturing video: this one showing CNC wireforming at Scandic Spring in San Leandro, Calif.

Carl Bass: The arcana of MIG welding, which he’s pursuing in an effort to develop a large-scale metal 3D printer. The Dutch artist Joris Laarman has illustrated a similar technique using an industrial robot.

Here's Bass' talk from Solid 2014:

C Todd Lombardo on design sprints

Thu, 12 May 2016 12:30:00 +0000

The O’Reilly Design Podcast: Design sprints, Lean UX, Agile, and design leadership skills.

In this week’s Design Podcast, I sit down with C Todd Lombardo, chief design strategist at Fresh Tilled Soil and adjunct professor at IE Business. Lombardo is co-author of the recently released book Design Sprint. We talk about the relationship between design sprints, Lean UX, and Agile, and the skills needed to move from designing to managing designers.

Here are a few highlights from our conversation:

Design sprints, Lean UX, and Agile

Design sprints are really a mix of scientific method, design process and agile philosophy—and agile is really a philosophy. There's 12 principles of working collaboratively together to solve problems, to ship software to customers that satisfies and delights them. That's really the agile approach; it's a philosophy. In Lean UX, sometimes ‘Lean’ is overused, but Lean in a sense means reduction of waste. You want to be as lean as you possibly can so you're reducing any waste and making your manufacturing process really, really efficient.

That same thing applies to the UX process: can we take out as much waste from the UX process as we possibly can, calling it Lean UX. It does have a similar approach because user experience is essentially a design approach, a design process, so they're incredibly similar. Oftentimes, Lean UX, especially in the book that Jeff wrote, has a framework or a process that he outlines, a process I see happening after a design sprint. After you've done a design sprint, do the heavy thinking and problem solving part of it, and then you've got to do a little bit more execution; I would call them ‘jump starts’ at Constant Contact or we call them ‘intervals’ with our clients at Fresh Tilled Soil, but they're essentially a Lean UX cycle—the build, measure, learn wash cycle, I call it, of a lean startup type of mentality that you can use to continually iterate what comes out of a design sprint.

In a design sprint, you do build something, but you typically don't build a production-level product. Typically from agile, after a sprint, you would have something shipping to a customer. You put it into production after a sprint. With a design sprint, it doesn't necessarily get shipped to a customer; you might build what we call a ‘minimum viable concept,’ so it isn't necessarily something you're going to put in front of a customer as a production-level thing—you're putting it in front of a customer to test it with them and learn something. They both have that element of learning involved, so hopefully that clarifies the difference, a lot of overlap but still a difference between the three.

The challenges of design sprints: Common missteps

Be careful about boiling the ocean would be one mistake I see. It's really hard to tackle something too big in such a short period of time—not that it's not possible to think about, but you may end up with a lot more questions or a lot of stones that are unturned, and you may not have really had a prototype to get you in the right direction.

The other one is almost the opposite: sometimes I've seen this happen in organizations where it's like they’ve got to do a design sprint because they have to check a box. ‘Oh, yes, we're going to go do this for a few days, and then we're going to make whatever we think anyway.’ I've seen that sometimes where teams do this and they feel like they're doing it because management wants them to do it and not necessarily embodying the actual outcome. That's another mistake I've seen where the team goes through the motions but they may not pay enough attention to what's actually happening, or management is for forcing the mechanism on a team when it may not be 100% right, or management's thinking ‘I'm going to have a working prototype at the end that's going to mean these features are ready to go.’

Sometimes they're done to confirm bias, which can be a problem: we're just confirming what we already know and that's a bias; you've got to watch out for that. Sometimes people are only paying attention to things that will confirm what they already believe, rather than listening to something that may go against it.

The other one probably would be the mistake of not spending enough time in the understand phase to really understand the problems. Sometimes teams assume they have a good understanding of the problem, and they don't really peel the onion back a number of layers to get into what the problem really is. There might be a symptom, and some people stop at the symptom level and don't realize that below it could be an even deeper problem.

Making the move to design leadership

Sometimes people think that being a good designer means they’re good at being a manager or a leader, and that isn't always the case. That was something that management has only started to really integrate into management and HR culture—somebody who gets really, really good at design, they're a good designer; if you turn around and now force five designers to report to that person and this person goes from designing everyday to now managing everyday, it's a significant switch.

Designers oftentimes may or may not have developed communication skills, so depending on what level of communication skills they've developed, they're going to have to really put an effort on that if they want to be a good leader because to be a leader means being a good communicator. Mike Monteiro talks about, if you can't sell the work, you haven't done the work. Part of making that jump from being designer to leader is your ability to communicate and essentially sell ... I need you to understand why I've made these design choices, I need to teach you. The ability to teach somebody will help you be a good design leader.

The ability to communicate and have that level of client [relationship], whether they be an internal client or not, even a coworker; ... if you're a designer in a product team, your product team is your client and you still have to be able to sell them on your ideas and your designs and your design choices and how they fit to the objectives that the business wants to achieve.

Ben Yoskovitz on using metrics to build successful products and companies

Thu, 28 Apr 2016 11:00:00 +0000

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 live online course, Product Strategy for Designers, on June 9, 2016.

Here are a few highlights from our conversation:

Hubris and humility: A winning combination

We're all liars. I say that almost every single time I present. I think as an entrepreneur, you 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. There has to be a little bit of lying there. Let's call it a little bit of sizzle before the steak.

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. You have to get up every morning and fight the good fight for what you believe to be true and your 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 100 miles an hour. You crash and you burn and you die. I actually think, 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. It's just about poking holes in that reality distortion field, so you don't crash, burn, and die.

Entrepreneurs need the ego. You need to have a strong vision for what you're trying to accomplish. You have to be able to get up in front of people and fake it until you make it. Having said that, when that goes too far, then you are doomed to failure.

Product management, product design, and product strategy

The product manager role, and even how we build products, changes company to company. There's obviously some similarities. For me, this is about helping product designers understand the different approaches to building products, and hopefully relating that to the experiences that they're having at the organizations where they work, whether it's large or small companies.

I think it's important for everybody at a company to understand how a business functions and operates, and how it makes decisions, so that I can tie my work, day in and day out, and the value that I'm creating, to the value for the whole company.

In the class I’m teaching, we’re going to cover things like business models. On the outside, that can sound pretty easy: my company builds a widget and we sell a widget. There's just so much more to business models than that. A customer or user's experience, the minute they start with us to the end. We’ll address questions including: How does this business function? How does it make money? How do users experience the product or the services?

Understanding things like pricing. Understanding the whole ecosystem of what has to happen for a business to function and be successful. Then, try to bring that down to my job as a designer and how that relates to product teams. Nobody in a company works in isolation. A product designer has to work with a product manager, has to work with a developer, has to work with customer support, has to work with sales. How do these things tie together so I have better idea of how a product gets built, so I can provide more input and insight into that and increase the value of the work I'm producing for that company?

There's no formula for success, but there's a methodology that you can work your way through in order to, hopefully, find success. We will cover this in the course, too.

Scott Murray on designing, coding, and data visualization

Thu, 14 Apr 2016 11:23:00 +0000

The O’Reilly Design Podcast: Staying relevant, design as a problem-solving process, and a creative coding approach for designers.

In this week’s Design Podcast, I sit down with Scott Murray, designer, creative coder, and artist who writes software to create data visualizations. Murray is the author of Interactive Data Visualization for the Web and the forthcoming book Creative Coding and Data Visualization with p5.js: Drawing on the Web with JavaScript. Murray is teaching an online course, Programming for Designers on May 11-12, 2016. We talk about why coding is a great skill for designers to learn (and it’s not just about earning more money); data visualization; and why design, at it’s core, is problem solving.

Here are a few highlights from our conversation:

Design and data visualization

We're swimming in infographics, and we have open government data, open data, API's data—data, data everything. You can't avoid data. It's a critical part of the modern world. The way I see it, to stay relevant, designers have to keep engaging in the modern world.

Visualization is a natural fit for designers because it's leveraging all the visual communication skills, all the problem solving skills that we've already practiced. It's just in a more specific domain. You might still be designing posters, or dashboard, or charts, or something, but your source materials are these rows and columns of values instead of unstructured text. It's just a more specific kind of design. It uses all the same skills, and then some.

Historically, everybody who’s practicing in the field now came from another place, so they're either coming from design, data science, statistics, architecture, computer science, cognitive science, journalism. Essentially, everybody was trained as something else and then found their way into this, which I love. Doing data viz, you get to meet so many interesting people and curious people. But it does make it hard—there's no one-size-fits-all solution when people are trying to figure out how to get into it. I point people to Alberto Ciaro's website or Andy Kirk's websites. Those are: thefunctionalart.com and visualisingdata.com.

Problem solving: The meaning of design

One of the challenges I see is getting design recognized as a problem-solving process, not just as a beautification tool, and not even just as a visual process, either. I think designers get this already, but design is one of those weird words that has different kinds of meaning and different contexts, so it's hard ... When I'm talking about design, I'm usually talking about this problem-solving process that you could apply to making a band poster, or making an interactive silly face, or do like IDEO does: change organization design, designing entirely new school systems from scratch. They're visual elements, but it's not really a visual problem. You apply the design process to political problems, social problems.

To me, that's one of the challenges, and the related challenge for the field is to figure out how to manage all this complexity that goes with increasing popularity and more and more people in more and more fields adopting the design language, and design thinking, and design process.

It can be super intimidating for new designers—and especially students I've worked with who are just coming out of school. They graduate and they're dropped into this whole world that is just ... I guess every generation thinks the world is more complicated than it was for the previous generation, but it really feels that way. The bar is so high. It's like to get any design job you have to already be familiar with these thousand different processes, and techniques, and tools. It can be really intimidating. I think managing that complexity is going to be huge.

How programming can help designers

Even if you don't go on to code as part of your job, learning to speak that language and learning the thinking process that goes behind programming is helpful. We call it computational thinking. Appreciating how the computer operates and how you have to think about your own design systems differently in order to fit them into that box that the computer can understand. That's really helpful later, even if you don't code yourself, because then you can talk to developers and other people on your team who are working with this stuff. I guarantee you'll start to understand, ‘Oh, they always get frustrated when I ask for x, y, and z. Now, I see why that's a big deal because I have a sense.’ Maybe you don't understand the details, but you have a sense of what effort had to go into creating that.

In the online Programming for Designers course, I’m using a creative coding approach to programming, which is to say that the philosophy I'm bringing to this is, ‘You figure out how to communicate to the computer to get it to do what you want’—that's pretty different from, ‘You figure out the most efficient way of solving a particular problem.’ That's not something I do. That's something computer scientists and proper developers do really well. [In the training course,] we're going to use this new tool called P5JS, which is a Javascript framework.

Dylan Field on designing for designers

Thu, 31 Mar 2016 14:00:00 +0000

The O'Reilly Design Podcast: Figma, measuring success, and meta debugging.

In this week’s Design Podcast, I sit down with Dylan Field, founder of Figma and former Thiel Fellow. We talk about the problem Figma aims to solve for designers and how they’re measuring success. Field also talks about how they debugged Figma in its early days: by mandating their own designers use it to design the tool.

Here are a few highlights from our conversation:

The beginnings of Figma

Designers are increasingly at the center of their organizations. They're not just working alone in a corner; they're actually working collaboratively with other designers, they're working with engineers, they're working with product management, with executives. They're extremely connected inside the organization, but their tools, in contrast, are still offline and disconnected. We decided we wanted to build the first online collaborative tool for interface design.

Design at Figma

We're 17 people now, which is awesome. It's a really cool size because you walk in the office and there's that buzz. In terms of our engineering and design, we have eight engineers and we have four designers right now. It's a one-to-two ratio. That said, two of those engineers are more back-end server side, so it ends up probably being a one-to-one ratio in terms of when you're working on a project; a lot of times, engineers are in one project and designers are in multiple projects.

We design everything in Figma. It's something you have to get used as you work at Figma and start designing things because you're inside the tool designing the tool, which is always interesting. That actually was a problem for a while when we were first starting off, before our software was at the quality bar it is now. It had a lot of bugs. This was maybe two years ago. We gave it to our designers and we mandated that everyone at Figma use Figma for design now.

Right now, we're supporting a class at Berkeley. It's a 220-person class for UI design, and it's been amazing to see students coming from pretty beginner backgrounds. They're learning a ton, and they're using Figma to do it. I just hope that we can do more of that as the company grows.

How Figma measures success

We can't just measure success by looking at the number of users that we have. Rather, it's about the people who are using Figma. The real interesting question for us is, "Are they deeply engaging with it? Is this their tool of choice? Are they using it for the things that we think they're using it for? Is our value proposition that we think is really important, is that being shown to be important by our customer base?" So far, it seems to be. That's our initial impression.

Really, it's about this depth of interaction. When we look at the data ... I wouldn't say average is a good way to look at it. For example, when you look a the distribution of how people use it, some people log in once and they don't log in again. That's just your standard Internet company. Everyone has that. Obviously, you try to reduce the number of people who do that. For the people who do use us, we're seeing them in it all day long.

I guess the next level question is more qualitative, which is, "If you're a designer and you're using us for your work, are we making you more efficient? Are we making it easier for you to work with other people in the company? Are we making your job easier?" For non-designers, going back to the issue of communication, "Are we teaching you how to visually communicate? Are we teaching you how to work with designers better? Are we teaching you how to contribute to the design process?" If we can do that, I think that's a huge win.

Joel Marsh on the science of design

Thu, 17 Mar 2016 12:30:00 +0000

The O’Reilly Design Podcast: Design as a science, designing for behavior change, and getting your first design gig.

In this week’s Design Podcast episode, I sit down with Joel Marsh, designer and author of UX for Beginners. We talk about design as a scientific way of thinking, what happens when you try to cash a check in Sweden, combining behavioral economics and design, and why learning design is like learning to play the piano.

Here are a few highlights from our conversation:

Design as a science

When people think of science, they often think that it's not very creative. That's wrong. There are two types of creativity. One is creative expression, which is what feels really good to you as the designer, and we usually call that art. Then there's creative problem solving. Creative expression is all about possibilities and creative problem solving is all about restrictions. You have to work within the rules or within the requirement or whatever.

There isn't really a lot of understanding about how the scientific process works. It's a perfect match for user experience. It works in every project in every company. It's super useful. User experience design, I could say, is different than a lot of other kinds of design because we can measure and prove things. When you have this constant process where you're making things and testing them, over time you start to realize there are things that are objectively true about design.

A lot of designers talk about design in terms of what they like or what's trendy or what's your favorite or what are you into, all that kind of stuff. In user experience design, none of that matters because it either works or works better or it doesn't. When you start to collect up a bunch of things that are objectively true and always get better results in the tests, whenever you start forming a kind of mental model of the way people interact with anything ... when there are a bunch of principles that are reliable and that describe behavior in general, it starts getting a lot closer to a science, where you can predict what people are going to do, even though you've never seen that kind of a product or that product has never existed before. You can predict how people are going to react to things or whether this option is going to be better than this option, just because you understand the model. It's a very scientific way of thinking about creating products and things, but it's not that common, so it's a good topic of discussion.

Design in Sweden

If you consider the fact that the population of Sweden is about a quarter of California, the influence that Sweden has in the world is very disproportionate. It's much bigger than it should be. Sweden is super trend sensitive. Sweden is often one of the first to hop on something. New tech becomes normal and mainstream really quickly. There's a disproportionate number of Swedes in a lot of online communities, including Dribble and Reddit. On Reddit, you'll see a disproportionate amount of news about Sweden for that reason. I think it's good for Sweden's brand. If you look at the number of billion dollar companies and the amount of money that's going into tech investments, Sweden represents way more of that money than the population should as a percentage.

Digital life here, one of the advantages for the digital type designer is a lot of digital tech goes mainstream here really quickly. We can pay taxes with a text message. People are predicting that Sweden will be the first cashless society relatively soon. I can remember in 2008, I did a freelance project for Sony BMG from here. It was the American Sony BMG, but I was working from here. They tried to pay me with a corporate check. When I brought it to the bank, the guy at the bank was like, "What am I supposed to do with this?" Checks haven't really been a thing that exists here, even since before that.

Designing for behavior change

Sometime in the next 10 years or so, it's going to be a lot more common for economists and designers to either work together or start merging into some other kind of job. Behavioral economics is newish within economics. Those people study the behavior of buying, prices and markets, all that kind of stuff, but from a psychological perspective. UX design is kind of the other side of that, where we're designing people's behavior from a psychological perspective. On both sides, that's sort of the new version of designed economics. Already the senior people on both sides are starting to notice that there's a lot in common. It's real interesting where that might go, if you combine the idea of behavioral economics and design. Is there a way we could redesign democracy so it works better? Or redesign things to redistribute food or create incentives based on the way the system is set up so that more people donate organs, or whatever. I think over the next 50 years, the mindset will be different. We'll be designing the way an economy works instead of just describing how it works.

The designer’s challenge: mastering uncertainty and solving problems

Finding problems, wanting to solve them, and then loving the process of solving them, all of those are hard to do, but I think those are super important skills as a UX designer. I would say you need to have the ability to say no. That's definitely a life skill. As a designer, there are so many things you could do. You have to be able to say no, especially to yourself. There are an infinite number of ideas, and most of them won't help you. You need to know what you're trying to do and say no to everything that isn't going to help you get there.

Advice for breaking into design

Design is like trying to learn to play the piano. You can't read about it and get better. One of the questions I get really often is, “how do I get experience”? How do you get experience to get your first job? It's that classic “you need to get a job to get experience and experience to get a job.” In UX, the entry level is really low. You can get in pretty easily. You can have your own websites; it’s easy and free to do that. Tumblr lets you write your own code so you can get a theme and then put analytics on it for free. It's not even that hard. You can start changing things and trying to see if you can improve your numbers, get traffic by posting on Instagram or Twitter and see what happens. That's really easy.

You could also find a charity or agency and offer to intern for free in exchange for letting you test a few things. One of the best suggestions is to find an app—or just take any app, something famous, Facebook or Tinder, or whatever you want—get a bunch of people to use it one at a time. Just sit next to them and observe. Write a list of questions and ask each of them. See what they do. See if you can find an insight about something that might be confusing or something that could be better about that app. Wireframe a solution, then put it together as a PDF and send it to the company. See if you can get them to give you some feedback. Even if they don't give you some feedback, that's a real piece of UX user research. Now that's in your portfolio. If you just did a couple of those, you'd have more user research in your portfolio than a lot of people with years of experience.

Simon King on design at IDEO

Thu, 03 Mar 2016 13:30:00 +0000

The O’Reilly Design Podcast: Team dynamics and culture at IDEO, design education, and design’s next big challenge.

In this week's Design Podcast episode, I sit down with Simon King, director of Carnegie Mellon University's Design Center. King is the author of Understanding Industrial Design. We talk about team dynamics and culture at IDEO, extending design education to non-designers, and design's next big challenge.

Here are a few highlights from our conversation:

CMU's Design Center and the designer shortage

The idea is behind the Design Center is to bring design to more students across the whole campus and to create new kinds of research opportunities to work with organizations from outside of the university as well. There's really two levels to think about the designer shortage, and one is what I'm trying to do with the Design Center: increasing the overlap with design that many people might have, where there's this idea that you're able to hire someone who's design savvy, or design literate, or can bring some of the tools of design to their core discipline. That helps, but the bottleneck of 'there just aren't enough really skilled designers coming out of master's programs and that are true experts'—I don't have a good solution to that. I look at it and I think, 'design is something you have to learn by doing. You have to build up this set of experiences over time, and it just takes time.' There's no silver bullet in terms of meeting the increasing demand.

Combining it with formal education might be more about a bigger mindset shift and not as much about specific skill building. Another approach is something we're seeing at CMU, where there's now a variety of programs. At the master's level in the School of Design, there's now options for students that are one year in length, or two years in length, or if they didn't come in with a design background previously, potentially up to three years in length. It used to be there was just a two-year master's program. I think that universities are recognizing the need for flexibility there, so that, depending on people's goals or the time commitment that they're willing to put in, there's options for them.

Team dynamics at IDEO

The great thing about IDEO is the range of projects I was able to be involved in—and the range of industries. That's truly the value of a place like IDEO: the mix of experiences I had. I think there's a lot of learning to just seeing the patterns across those industries, seeing how much organizations play a role in the ultimate success of a project, and understanding that it's sometimes frustrating how we're able to work with or integrate with an organization as an outside party or not.

The other big takeaway is the power of teams and the team structure that was at IDEO. There's very autonomous teams that are working full-time on a single project, that ability to really dive deep and be given the autonomy to come up with unexpected process or ideas. It wasn't a formula; we restructured at the beginning of each project, and that was really powerful. It would vary depending on the context or the project, but typically, it was three to four people in terms of size. Everybody would be from a different discipline, though increasingly, and I think this was really valuable in the final years I was there, there would often be people from the same discipline paired up on a project. If it was a more complex project, it would be two interaction designers, might be two industrial designers in the mix. That's something that, at the time and now, I reflect on as something that is really valuable—for those people to build on each other's ideas or to provide that in team mentoring. I was playing a role of an outside guide or mentor a lot, coming in at various times throughout a project, but there's a lot of value in having that built into the team itself and thinking about how each person on the team might support the others.

It comes down to how you can work with others. If you're somebody who is able to contribute ideas in a broad way and be passionate about them but not protective of them, to where it's this concept of 'strong ideas, loosely held,' of being able to be excited but also take input and push back. That's one of the things IDEO rewards—that attitude and being open to input from anybody. A number of times I've seen an intern have an idea that's respected by everyone just as much as a director, and that's great. That's a great environment to be in, but you have to also feel okay with your idea being questioned or pushed back against, by anybody. I think that openness to input and ambiguity around, "Whose idea was this?"—you have to be comfortable with that and embrace that.

Design's next set of challenges

Design is always running into new challenges. I think it's at two levels, because there's always the challenges of ever-changing technology that we just don't know how to design for. That becomes a very specific, tactical challenge, whether designing with real data when it's a personalization model that's so complex you don't know what's going to actually show up, or designing with artificial intelligence, where you're not able to specify a real, "If this happens, then make that happen." So, how can you ensure that it's a good experience? There's things like virtual reality and augmented reality that people are only beginning to grapple with and thinking, that's just this never-ending cycle, which I think is fine.

In some ways, those are the small challenges because the other side of it is that design is being embraced by all kinds of organizations that traditionally haven't embraced design, and people are trying to bring design to spaces like health care, and education, and equality, and government services. They have these lofty goals for what design can impact, and the big challenge there, for the discipline, is figuring out how to make meaningful change in those environments. It's very, very context specific—how do you work through the organizational and cultural challenges in those complex systems to use the tools of design to make something happen. This is something I ran into when I was at IDEO, where a lot of times, it didn't feel like the small tactical design parts; the real challenge was figuring out how to get this integrated into the organization, how to take action, make sure that it gets out there in the world in a way that can impact something.

Scott Hurff on designing at Tinder

Thu, 18 Feb 2016 13:00:00 +0000

The O’Reilly Design Podcast: Design at Tinder, Awkward UI, and the UI Stack.

In this week's Design Podcast episode, I sit down with Scott Hurff, product manager and lead designer at Tinder, Inc. Hurff is the author of Designing Products People Love. In this episode, we talk about how Tinder approaches design, avoiding awkward UI, and why customer research is the most important skill for future designers.

Here are a few highlights from our conversation:

Questions of structure

At Tinder, the product team is about five people, six people. What's interesting is that we're trying to grow really quickly. There's a give and take on how we divide up product design responsibilities and product management responsibilities. There is a lot of engineering talent here, and they need a lot of product to work on. It's a matter of, how do we structure ourselves so we can give them thought-through, packaged-up, ready-to-go ideas and concepts while still hammering out the details in time.

Design as a full-contact sport

Design is such a part of the Tinder experience. It may not seem like that's the case because it's such a simple app, but that's only because everything goes through this distillation process. You have to really fight for real estate and your idea. Design's really a full-contact sport here. You have to bring in all the big guns to make your case. Sometimes these can be really long debates, but they're good; they're healthy. They get the ideas out on the table, and a lot of times, design really has to be put through its bases to prove itself.

Awkward UI

Awkward UI is that feeling you get when you're using a digital product and something doesn't feel right. I had been struggling on what to call that or even what it was. The example I used, because I use Apple TV a ton, is when I'm loading my library, my personal library—movies, or TV shows, or whatever—and I select "All Titles" or whatever the menu item is, and it just sits there, blank. There's no loader, there's no indication of activity; I think, "Oh, man. There's been some fluke." I do this every time. I use this a lot and I still feel this way every time. "Is the Internet down? Did Apple erase all my movies?" You start to go through these panic modes, and then, "Oh, there they are. Oh, everything's fine." It just snaps into place, it just appears out of nowhere. As humans, we need to see motion from start to finish. Things don't just drop into place out of thin air, unless you're in Star Trek or something.

Five states of the UI Stack

I call this the "UI Stack," where it's building on the idea from way back when 37signals, now Basecamp, wrote this great book, Getting Real, in '06; it was a big influence on me. They invented the "Three State Solution," where it was blank state, ideal state, and error state, I believe. Really, there are more. There's more to it than that, especially since mobile apps have introduced touch-based UIs. There's really, I think, five states. The UI Stack consists of those five states: blank, error, ideal, partial, and loading. When a UI doesn't have those states, it feels weird, and it presents you with a jarring feeling. Part of the whole premise of moving between these states is that you show the progression. You show the progression from blank, to partial, to loading, and back and forth.

Don't forget the past

An important skill for designers is being able to interpret customer research and being able to actually perform it. The big source of everything is that my products exist is to find a customer. If you don't know who that customer is or if you are thrown off by whatever and going after the wrong person or group of people because of that, you're going to waste a ton of time and money. I think designers need to be able to at least detect if things were done or if research was conducted soundly. If it's not, then find someone who can do that for them because I think technology has gotten a pass, where we've embedded in our culture this "raise a bunch of money, burn the ships mentality, ship it, fail faster," that whole thing. We've been able to get away with that because of this sheer mass of the market; there's so many devices coming online, there's so many potential customers out there, and I think it's led us to forget the practices of the past.

The staples of everyday life

Henry Dreyfuss, one of the greatest industrial product designers ever, like the Steve Jobs of the 30s and 40s, made reassertions and actually sitting down and doing what his customers were doing part of his routine. He invented the I Love Lucy black telephone and the round thermostat. It's these staples that are everyday life that you don't realize, like, "Wow, someone thought through this design and it's a massive success." Research, I would say, is the next set of skills.

Tanya Kraljic on designing for voice at Nuance

Thu, 04 Feb 2016 00:00:00 +0000

The O’Reilly Design Podcast: Moving from GUI to VUIs.

In this week’s Design Podcast episode, I sit down with Tanya Kraljic, UX manager and principal designer at Nuance Communications. Kraljic recently spoke at OReilly’s inaugural Design Conference (you can find the complete video compilation of the event here). In this episode, we talk about the challenges of moving from graphical to voice interfaces, the voice tools ecosystem, and where she finds inspiration.

Here are a few highlights from our conversation:

We’re seeing a renewed emphasis on design at Nuance—actually, much like in the technology industry as a whole. We’ve always had great engineers who are building this very complex, very cutting-edge technology. Now, we’re augmenting that with a human-centered approach to product strategy and development, which I think we’re already seeing as accelerating innovation in our own company and, hopefully, it will also help create better and more usable solutions as voice becomes available in all these different technologies.

Our team has been working hard this past year toward a new platform, a mobile developer platform called “Mix” and accompanying development tool called “Mix NLU" that enables third-party developers, everyone working from startups to large companies to use our speech algorithms, basically, to create their own custom language models that they can and then integrate to their own applications.

I think there’s probably two main reasons [the move from GUIs to VUIs can be difficult]. The first is just practically, I think, because it’s not something that’s been available; it’s a new field, really. I think people just aren’t sure where to start—so, you want to voice-enable something; what does that even mean in terms of what technology you need, or what infrastructure you need, or where you should begin designing?

There are a lot of principles of interaction design that apply to voice as well, but designing for voice or speech is really all about helping users; it’s all about filling in the blanks for users, in a sense. When you design for, say, the GUI for a mobile application, you can be very deterministic. You decide what functionality you’re going to enable. That functionality is easy to communicate to users, in a sense, because you put buttons and labels on the screen, and if there isn’t a path for something or a button for something, then it’s not available—or you might put something there but have it disabled, right? A user goes in there and it’s pretty clear what they can and can’t do. But, when you design for natural language, you’re flipping that script.

Chrissie Brodigan on user research at GitHub

Thu, 21 Jan 2016 00:00:00 +0000

The O’Reilly Design Podcast: Product development, user research, and identifying blindspots.

In this week’s Design Podcast episode, I sit down with Chrissie Brodigan, manager of user experience research at GitHub. Brodigan will be be speaking at OReilly’s inaugural Design Conference. In this episode, we talk about user research and product development at Github, and the blindspots in product development and organizational development.

Here are a few highlights from our conversation:

Our internal philosophy around research is about when we make our design decisions, we come up with hypotheses about how that design change will impact behavior as well as user experience. We may need to add a particular control to the workflow, but if it has a negative consequence on the overall experience of our users, we may decide that that's not the right decision for us. Even if it's helpful in one area, it causes unhappiness in another. We measure impact with controlled experiments, which a lot of people would refer to as ‘AB testing.’ We do do some variance testing, which is short term, but we also do longitudinal analysis, which is to study a cohort over a longer period of time. Internally, we're always asking ourselves ‘Why?’

We typically follow three steps for research, where a product manager will request to research something. They have to come up with a problem statement. Whenever they request research we say, ‘What's the problem? Does it really require research?’ We treat research a little bit more like a luxury good, so we want to make sure if we're going to devote time into a study, that we have something that we're really trying to solve, not just research for research’s sake. Then, members from the research team will design a study, specifically for that particular product -- so, we might do survey research, we might decide that we need to do a pre-release, or we might move over to a controlled experiment. Then, the last thing we do is we collaborate on results. We bring in the engineers, the designers, and the product manager, and if we're interviewing customers, at times they'll each take rotations, and they'll go on those customer interviews.

I think the thing that people find the most interesting about how we do user research at GitHub is we, our team, our research team, uses GitHub to research. I guess what's interesting about that is, I'm not a developer, so I had to learn Git and I had to learn how to use GitHub in order to bring research in closer to our code base. Everything has a URL because we use GitHub. Whenever we do a user interview, those notes are written up as a markdown file, opened up as a pull request, and a link to the video is part of that write up. That write up is then cross referenced over to the code base.

The other common mistake I see is that people skip pre-testing. You know, you've got a survey instrument, you're really excited about it, or you've put together a variance test and you're ready to roll, and you put it out there, and unfortunately when you do that and you don't look at the data as a pre-test set, either you have reached out to too large of a sample and it's hard to pull it back. Survey tools also sometimes have bugs.

Subscribe to the O'Reilly Design Podcast: Stitcher, TuneIn, iTunes, SoundCloud, RSS

Wesley Yun on GoPro’s design approach

Thu, 07 Jan 2016 00:00:00 +0000

The O’Reilly Design Podcast: Managing, mentoring, and recruiting designers.

In this week’s Design Podcast episode, I sit down with Wesley Yun, director of user experience on the hardware side at GoPro. Yun will be be speaking at O’Reilly’s inaugural Design Conference. In this episode, we talk about managing and recruiting designers at GoPro, Designer Fund's Bridge Guild, and mentoring the next generation of designers.

Here are a few highlights from our conversation:

Managing is humbling. My job isn't to tell my designers what to do. My job is to hire the best designers I know how to, or I can hire at the organization that's right for them and then create this space and the opportunity for them to do the best work of their life. That, to me, is what a good manager does. I very rarely tell my designers what to do. I help them frame problems. I help them sell ideas. I help streamline their thoughts.

[When recruiting], I look for things that are very unique, not something that you can see on a page or a resume. There are people who just bring a sense of joy and happiness and collaboration and trust; it's nothing specific that you can ever point out.

It's like if you're on a date with somebody and if the questions are one-sided or if one person is doing all the talking, that's a horrible date, and just as in human relationship, it's got to be a two-way street. I hate when people posture—you walk into an interview and they say, ‘Hmm. You tell me why I should hire you. Who are you? What have you done?’ I hate that. I hate that because it's not real. It's not authentic because it's not what this person is going to do for you. It's what we're going to do together. How do you arrive at that? The only way I know is through a real conversation where you're very forthright about all of the difficulties and challenges, and if those challenges are right for them, they're going to be excited. If they're not, then great. It's a good thing that you found out and no amount of talent is going to overcome the challenges at an organization if they're unwilling to deal with those challenges. I don't care how talented you are. You can't overcome it with talent.

I think that's where [Designer Fund] saw the gap or the delta between designers and their experiences and the needs of the startups, so they created this program called Bridge. Initially, people thought of it as an internship, but it's really for mid-level professionals. You reach year 5 or 6 or 7 of your career and you want to make a transition, but you just don't know how and you don't want to take a huge step back in terms of position. Bridge really connects some of the most talented designers to some of these startups.

What Bridge does is allow the designers to come together, form a community, and have skill sharing. They bring in experts in different spaces, not just tools in terms of prototyping. I remember going to a session where they were teaching improvisation. There was a professor from Stanford who came and gave a demonstration of how to build trust and break down barriers. He used improvisation as a tool for helping designers do that, and I saw people transform in a matter of 10, 15 minutes.

In my role as a mentor [at Designer Fund], I look for designers who might be a good fit, so I basically introduce them to Bridge. Then when they have candidates or applicants who come through, they have to get interviewed by these companies, so I help them put their portfolio together and think about the interview and then mentor them through that process.

Subscribe to the O'Reilly Design Podcast: Stitcher, TuneIn, iTunes, SoundCloud, RSS

Kathryn McElroy on IBM’s design approach

Wed, 23 Dec 2015 00:00:00 +0000

The O’Reilly Design Podcast: Prototyping for digital and physical, IBM’s bet on design, and diversity in design.

In this week’s Design Podcast, I sit down with Kathryn McElroy, author of Prototyping for Designers and design lead on IBM's Watson team. McElroy will be be speaking at O’Reilly’s inaugural Design Conference in January. In this episode, we talk about prototyping for digital and physical, design and diversity, and what it’s like working at IBM.

Here are a few highlights from our conversation:

I see the shift from an engineering feature-based product design to a user-centered product design across a 380,000 person company to be the most challenging but most impactful place that I can work. On a day-to-day basis, how this comes through is how we interact with our teams. As designers coming into this ecosystem, a lot of these people haven't really heard about user-centered design until they come to our design boot camps here in Austin.That's when we bring all of our product teams together—the business people, the engineers, and the designers—to center around their product and think about it from the user's point of view. ... What's the most interesting about this is just the fact that it's at this mind-boggling scale.

Specifically for physical prototyping, I learned mostly self-taught during my MFA program. I had a couple of great classes where we were focused on building electronics, and that was the first time I was introduced to it. I've only been doing it for three years, but it's something you can learn on your own. There's so many people with guidance out on the Internet and are willing to help you.

The other area that can improve [diversity] is the actual workplace design. Making sure that the physical environment is not geared toward one specific demographic. Having a variety of flexible spaces so that there's private rooms along with open offices is a great approach to that. Ping pong and kegs are fun, but it's more important to really make sure that everyone feels comfortable in a space and has some area of the office that they belong to.

It's really important to make sure gender and race and social orientation aren't directly affecting the [hiring] decision process through unconscious bias. We try to make sure that we're really looking at the work and seeing a person's process instead of deciding based on who the person is; it's more about their work instead of just a culture fit.

Subscribe to the O'Reilly Design Podcast: Stitcher, TuneIn, iTunes, SoundCloud, RSS

Robert Brunner on designing and building great products

Thu, 10 Dec 2015 00:00:00 +0000

The O’Reilly Hardware Podcast: The critical role of design in creating iconic products and brands.

Our expectations for industrial design have risen immeasurably in the last decade. Think of any piece of consumer electronics from 2005—a BlackBerry, for instance—and you’ll think of something that was encased in plastic painted silver to imitate metal, with a too-light heft and a rattle when shaken.

Now, nearly every successful piece of consumer hardware is the result of careful design and exquisite manufacturing. Apple deserves a great deal of credit for that shift by resetting the baseline with the iPhone in 2007, but new tools and processes have played an important role as well. Digital design has become easy and sophisticated, and contract manufacturers can do spectacular things with glass, aluminum, and semiconductors that were nearly impossible just a few years ago.

Our guest on this week’s episode of the O’Reilly Hardware Podcast is Robert Brunner, a founder of this new era of design. Brunner was director of industrial design at Apple from 1989 to 1996, overseeing the design of the PowerBook. He was the chief designer of Beats by Dr. Dre, the design-driven line of headphones that Apple acquired for $3 billion last year. And he’s the founder of Ammunition, which has worked with startups and large companies on a wide range of innovative consumer products.

Brunner spoke at Solid in June, and he’s also keynoting the O’Reilly Design Conference in January.

Discussion points:

Being “design driven,” and the importance of understanding design across the board
What makes a great product versus just a great design?
Brunner’s work on the Obi Worldphone, a design-driven mobile phone aimed at emerging global markets
The constraints of mobile phone design

Other things mentioned in this episode:

The June intelligent oven
The Polaroid Cube action camera—and Polaroid’s deal with Lady Gaga, who doesn’t usually feature prominently on this podcast
The Lytro camera

Image by Purpy Pupple on Wikimedia Commons.

Bob Baxley on Apple and Pinterest, company cultures, and the designer shortage

Thu, 10 Dec 2015 00:00:00 +0000

The O’Reilly Design Podcast: Culture, competition, and design staffing.

In this week’s Design Podcast episode, I sit down with Bob Baxley, who is keynoting at OReilly’s inaugural Design Conference. He compares cultures at Apple and Pinterest, talks about competition in the design playing field, and addresses the designer shortage.

Here are a few highlights from our conversation:

My observation is that although Apple really dominates the product culture of technology, certainly in Silicon Valley potentially globally, it’s really the Google culture that dominates how companies work.

By that I mean, a culture of engineering-centric, ship fast, let’s fix stuff, intense incrementalism based on metrics and experimentation, which is very different from how Apple works, at least in the time I was there, where it was much more deterministic. I think the difference maybe has to do with the business models, where Apple is creating a product that they’re going to sell and somebody has to pay money for.

...

Pinterest, I think, is trying to sit in between those two right now. The foundational DNA of Pinterest is definitely Google, where Ben Silverman, the founder and CEO, was before he started Pinterest, and then Evan Sharp, who’s the creative co-founder. Evan was at Facebook, and my experience of Pinterest is that it’s really in between a Google and Facebook culture—a lot of emphasis on engineering, but still a lot of input from product management and obviously design; having a design co-founder influences the company a lot.

I might argue that Google is still basically competing at the technology layer because they have the best technology. It’s not until the technology starts to get commodified that you move up to business and then eventually the business gets to a point where if you want to take it to the next level of value creation you move to design.

The goal of my talk at the O’Reilly Design Conference coming up in January, is to inspire the current generation of designers to go out into their neighborhood high schools and talk to those students about becoming UI designers because I firmly believe that if we don’t get more people involved in the profession, the future is not going to be great.

As it turns out, the stats are this: the U.S. economy is poised to consume 1.4 million new software engineers in the next four years. 1.4 million software engineers in four years. If you assume a 10-to-1 ratio between engineering and design, which is the bare minimum where designers still want to play, that means you need a 140,000 new designers coming into the market in the U.S. alone in the next four years.

Subscribe to the O'Reilly Design Podcast: Stitcher, TuneIn, iTunes, SoundCloud, RSS

Vanessa Cho on GoPro’s design approach

Wed, 25 Nov 2015 00:00:00 +0000

The O’Reilly Design Podcast: Designing for hardware and software, and recruiting and building design teams.

In this week's Design Podcast episode, I sit down with Vanessa Cho, head of UX and research for the software and services group at GoPro. Cho, along with her hardware colleague Wesley Yun, will be speaking at O'Reilly's inaugural Design Conference in January. We talk about designing for hardware and software, building design teams, and what she looks for in new recruits.

Here are a few highlights from our conversation:

I started at GoPro 18 months ago. I was one of the first designers, and in that time, we've grown to 18 designers — 18 designers in 18 months. We've spent a lot time recruiting and honing down on what is really important to us.

At GoPro, we're building a hybrid model that allows us to harness specialized skills while delivering speed and scale. What we have is embedded UX generalists for each of the product teams who can champion the customer experience and help define the product and the value of it. Simultaneously, we have a group of shared services, which is filled with specialists, researchers, visual designers, content strategists, and then also me as a manager, that work to help support the UX generalists that are embedded in the team. They're ensuring that the team not only is working well together but it's delivering consistent, on-brand quality work. This model … requires a lot of collaboration and communication between the individuals. … It also helps significantly that I have a very tenured, and mature, and collaborative team that always helps, not only on the software side, but also on the hardware side. We have excellent partnership there.

You know, hardware and software are very much like apples and oranges. Your job as a designer is to invent a peeler that works for both.

Hardware and software are motivated for different outcomes. Specifically, I think hardware has to be solution driven. They only have one chance to make that one product perfect. They can't release the product and then quickly update it and be like, 'Sorry. That wasn't really good. Here, let's send another update to the app store.' Once it's out there, it really is out there. It's final. On the other hand, software is totally different in the sense where it's not about a final product at a specific point in time; it's much more about the process, about evolving the product itself. It's about hypothesizing, concepting, learning, iterating, and changing. I definitely think that a hardware designer does that, too. They must. They absolutely have to, but they still have to design for a finished product. A final, final product. The software designer, I feel, usually has the attitude that ... the product is never finished. You can always learn, and iterate, and go through betas, alphas and betas. It's like a public beta.

I think all you really need is to find great hardware peers or software peers, regardless of where you are, who share that understanding of design thinking about how you actually create solutions or concepts and test those particular things out. Once you have that shared thinking, you can make that ecosystem really sing.

Subscribe to the O'Reilly Design Podcast: Stitcher, TuneIn, iTunes, SoundCloud, RSS

Dan Brown on mindsets, managing designers, and mastering impostor syndrome

Thu, 12 Nov 2015 00:00:00 +0000

The O’Reilly Design Podcast: Mindsets, impostors, and self-awareness.

In this week's Design Podcast episode, I sit down with Dan Brown, designer at Eightshapes and author of Designing Together and Communicating Design. Brown is speaking at OReilly's inaugural Design Conference, January 20-22, 2016, in San Francisco. We talk about managing fixed and growth mindsets, embracing impostor syndrome, and the most important skill for all designers (hint: it's not empathy).

Here are a few highlights from our conversation:

Carol Dweck wrote a book called Mindset, which talks about the studies that she'd been doing over the years about attitude, and specifically her attitude toward challenge.The studies show that if someone has been called 'smart' all their lives, they are actually more reluctant to take on a challenge because they believe that if they fail at the challenge, they will sort of undermine their own self-identity. This is what she calls the 'fixed mindset,' the sort of inherent belief that I am who I am, and nothing that I do will change that.

The converse, which she noticed in doing the studies, is a 'growth mindset.' These are people who embrace a challenge because they understand that that's part of the learning process, and maybe they'll get frustrated, but they won't shy away from it all together.

When people ask me what's the most important skill to cultivate as a designer, I think it's self-awareness.We talk a lot about empathy. We talk a lot about putting yourself in the user's shoes or in your colleague's shoes. I think that's really important. I like working with designers who understand what's going to be hard for them because when they know that, they can ask for help — they're good at saying, 'You know what? Visual design is not my forte, so I'll take a crack at it, but I'm really going to need some help making sure I get it right,' or 'I know that front end development is not what you hired me to do, but I'd like to take a stab at it, and I know I'm going to need some mentoring in that area.' All those kinds of messages are enormously helpful for me as a lead, but also for the designer themselves to have an understanding of where they thrive and where the opportunities are for growth.

Impostor syndrome is the idea that even someone like me, 20 years into my career, still thinks, 'What am I doing here? Why are people listening to me?' Even for someone who's now decades into a career, the notion that maybe I shouldn't be here persists. I realized that I just need to be okay with that because part of being a designer is constantly doubting yourself. It sort of comes with the territory. That's the advice that I wrote in that particular article — being a designer means looking at your work and going, 'This could be better; this could be better.' You're almost constantly saying that to yourself. I think the hard part for designers is to look at that not as an excuse to stop, but as an excuse to keep going.

You can go too far in the other direction; you can get into the sort of analysis paralysis, where you're constantly churning on something because it's not perfect. I guess perfectionism and impostor syndrome are really two sides of the same coin. But there is a balance, I think, that designers seek, which is, 'I understand that I need to be skeptical of the work that I do because it's through that skepticism that I experienced discomfort and challenge myself to do better.' At the same time, they need to acknowledge that it's not just them, that everyone is sort of experiencing that because that's the nature of design.

Subscribe to the O'Reilly Design Podcast: TuneIn, iTunes, SoundCloud, RSS

Adam Connor on culture, codes of conduct, and critiques

Thu, 29 Oct 2015 00:00:00 +0000

The O'Reilly Design Podcast: Organization design, design critiques, and designing for good behavior.

In this week's Design Podcast episode, I chat it up with Adam Connor, designer at MadPow and author of Discussing Design with Aaron Irizarry — Connor also is speaking at O'Reilly's inaugural Design Conference. We talk about company culture and organizational design, the design of codes of conduct, and advice on running productive design critiques.

Here are a few highlights from our conversation:

I think there's a misconception around what culture is. A lot of people approach me asking if I can help them with their culture as if it is this separate thing that if adjusted, everything else — their work, their processes, their people — will fall into place. But what culture really is, is the rules, the invisible rules, that we all have in our minds of how we're supposed to interact with each other or behave in certain situations. Sometimes it's the values that we have and sometimes it's more reaction and an instinctual behavior to get at that and to really influence that in such a way that allows people to be creative, to explore ideas, to be collaborative and work toward mutual goals. It actually requires you to adjust things like the processes we have, the policies we have, the roles people play, the skills that they're using.

When it comes to things like code of conduct, I feel like they are tools, but they're not the solution. There are things that they help do, there are certain people that they will help steer away from that behavior, but they're not going to steer away everybody; there are other aspects of events that contribute to or maybe maximize or minimize the potential for jerks to be jerks. I wouldn't look at an organization that has a code of conduct and say because they have a code of conduct, they're safe. I would want to know about what other things they're doing, how do they plan to back up that code of conduct, what other arrangements have they made.

The code of conduct I think is effective for some people, for people who take the time to look at it and pay attention to it and think about it. There're going to be a little less likely to do something stupid, but like I said, you can't prevent jerks from being jerks completely. There will still be people who misbehave even when there's a code of conduct in place. I think it's great to have them. I just don't think they're the only answer.

Critique isn't just an event, an activity that you do at certain points in time in your project timeline; it's not something you have to schedule a meeting for and wait until you have everybody in that meeting to do. Critique is really just a way of thinking about and talking about what you're creating. You don't have to have a formal process and a set of rules and go out and teach everybody in your company what critique is. If you just think about what you say to someone and how you ask for information, you can have a much more productive conversation.

Subscribe to the O'Reilly Design Podcast: Stitcher, TuneIn, iTunes, SoundCloud, RSS

Airbnb’s design approach

Thu, 15 Oct 2015 00:00:00 +0000

The O’Reilly Design Podcast: Katie Dill on designing for seven billion people, hiring good people, and the triforce.

In this week’s Design Podcast episode, I chat it up with Katie Dill, head of experience design at Airbnb. Dill talks about Airbnb’s values; the relationship between design, engineering, and product management; and what Airbnb looks for when hiring. Dill also will be keynoting at O’Reilly’s inaugural Design Conference.

Here are a few highlights from our conversation:

We have a few different ways of looking at the values that are behind our work and the way we do our work, and the team behind it. For a starting point, our company has core values. There are six points, which are actually on our website, that drive the values of all the people that work here. Some of which are things like championing the mission or embracing the adventure and having an entrepreneurial spirit.

Pretty much behind all the design work — and the thinking and processes of the people that work here — are three values we hold dear: being a host, simplifying, and every frame matters. Those three become really powerful in our design decisions and we translate that to our work. So, in being a host, we think about how we use the digital platforms that we design for to help people along in their journey, to invite them into an experience or a new part of the world. … Even our content choices, the language that we use, we try to make it really comforting, accessible, very human, just like a host would. That same thing goes with simplify. We want to be clear and to the point, and so we reduce the noise. Every frame matters references the frames of a storyboard, so every frame meaning that every point in the journey matters. … It’s not just about one screen that someone looks at or it’s not just about the app; it’s not just about one moment in time.

We’re not design-driven, but we’re also not engineering driven and we’re not product driven. Our viewpoint is that a company is not going to create the best impact or the best experience or deliver the best value for users or stakeholders as driven by one of these particular disciplines or pillars. Our view is that it’s through the collaboration of these different pillars, which we call the “triforce” — product management, design and research, engineering and data science — it is through these three pillars working together that we have the most impact.

We look to hire is people that have humility, craft, and hustle. The reason for that is that yes, we want the best designers on the planet working here,and people that have exceptional craft and taste, and care about every detail and do their work with pride, but of course, that bit that you mentioned is that they have to leave their ego at the door. We’re designing for our users at the end of the day, and it’s not for us, it’s for them.

Data, design, and intuition

Thu, 01 Oct 2015 00:00:00 +0000

The O’Reilly Design Podcast: Pamela Pavliscak on designing for happiness.

In this week’s Design Podcast episode, I sit down with design researcher and data scientist Pamela Pavliscak. Pavliscak is the author of Data-Informed Product Design, a free report from O’Reilly, and will be speaking at OReilly’s inaugural design conference. Pavliscak talks about the delicate relationship between data and design, and why it’s not an either or proposition, as well as why designing for happiness is good for business.

Here are a few highlights from our conversation:

We like to think in dichotomies for when it’s either data or intuition. I think of it more like archaeology. Archaeology is not always about finding the big celebrities or what the important heroes and personalities of history do. It's about learning more about the everyday practices of people. You have these clues, these traces left behind. Like archaeology, the science gets more sophisticated. Archaeologists have remote sensing and X-ray guns. Data scientists have algorithms and AI. The big difference is, these people that we're learning about with data science are still around. We can learn about them in their own words and rely on them to share their feelings and their context. For me, it's not really an either-or, but more of kind of an improv ‘yes-and’ kind of relationship.

I always suspected that delight, that concept that we have in design, wasn't the full story of what made people happy. The small moments, the small pleasures certainly factored in, but it really seemed that the patterns fell into this kind of deeper meaning. I would see people for Humans of New York -- this is the happiest site in the world for people. Not in the sense that it's showing happy things, but because it makes people feel connected. It's connected to a story, and it's connected to a story that’s not complete. There's still room for people. Those are the kind of moments that came out.

You'll find that happier employees are more productive and they find more meaning in their work at the same time. Even way back to the 80s, I found some research on product detachment, and found that happiness and brand detachment are somehow linked together. There's Martin Seligman's PERMA, there's subjective well-being scale, there's Maslow's hierarchy, which of course we all know by heart. Countries are applying happiness initiatives to supplement their GDP. We're learning more about this through behavioral economics and these different models.