By Lisa Helminiak
September 8, 2017
Lessons from the Trenches: Human-Centered Design in Practice
Azul Seven Webinar: October 5, 2017 11:00 am (CDT)
Presenter: Lisa Helminiak
Just a few years ago, companies talked a lot about problem-solving with design thinking and human-centered design (HCD), but very few actually did it.
Well, times have changed! Silicon Valley startups were the first to embrace the approach, and now companies big and small, old and new, are in on the action. But are they really getting the most from the customer-centric practice?
Azul Seven has helped companies of all sizes develop their next products or services using a human-centered, design-led approach. We’ve seen what works and what doesn’t. Companies can spend a lot of time implementing these processes but without focus and attention on key skills, it’s easy to slip into the old way of working. Join Azul Seven CEO, Lisa Helminiak, to hear what we’ve learned (sometimes the hard way) over the years. She’ll discuss why working towards an MVP, instead of a launch date, is a good idea. She’ll explain why designers and developers should work on project sprints simultaneously. And she’ll offer research strategies that can improve your data and result in better outcomes. You’ll learn more about how human-centered design frameworks such as design thinking, lean startup and behavior design can help solve your next business challenge. Plus…
- Common mistakes (and fixes) in implementing human-centered design
- How to create a business culture that supports a design-led approach
- Success metrics for measuring human-centered design outcomes
To watch the webinar, fill out the form below:
Lisa H: Slide: Human-Centered Design: Lessons from the Trenches
I’m pretty excited about today’s topic. We’re talking about Human-Centered Design, Lessons from the Trenches. First, I’m going to cover just some of the logistics stuff about this webinar. We’ve got a number of people online to help me today. Jane Calvin is here, and Michelle Powers. They’re both colleagues who are going to start gathering information from you, questions that you might have in the webinar, so we can talk about it again. We are going to allow for questions and some discussion, because I’m going to be presenting and talking about things we’ve learned along the way, but I know there are people on this webinar who have their own experiences, and I’d like to hear your viewpoints, as well.
So, hoping to make this as much of a dialogue, especially at the end when we open it up to questions. Within the Go to Webinar control panel, you should see a questions area. As we go through the presentation, feel free to add questions there. Also, if you’re having any technical difficulties, can’t hear, can’t see, let us know that, too, by typing in a note and we’ll try to rectify the situation. Thank you, again, for coming and we’ll get started.
In today’s webinar we’re going to cover three things. Common mistakes teams make in trying to integrate design thinking and some of the ways we see to fix that. How to create a culture that supports human-centered design and this approach going forward. And, success metrics for measuring human-centered design outcomes.
We’ve been doing some work around that over the last few years because when things don’t get measured, it’s hard for companies that are measurement-based to see the value. It’s not easy to measure this, but we’ll talk about some ways that we’ve encountered that begin to help in that area.
Azul Seven is a human-centered design consultancy and we started, as more of a traditional digital agency. We transferred over to a human-centered approach and started integrating it into the way we worked about seven years ago. So, it’s been something that we have been working with over the years, and it’s been an interesting transition. In the old days, we really ran things by learning from best practices and traditional design methods how to best engage and design for people online? And through this work, we really came to realize that each situation and product is different, and we had to come up with ways to get to better outcomes. We had always learned from those we were designing for but we wanted to get more methodical about it. So, that’s why we turned to design thinking and human-centered design. They are good frameworks for discovering the unique needs and contexts for the people we are designing products and services for. Design thinking allows us to continually test and learn so we get results along the way.
Slide: Human-Centered Design (HCD)
So, let’s get into the meat of it. Human-centered design, let’s define what we mean here. It’s primarily an innovation method that develops solutions to problems by involving human perspective in all the steps of the problem-solving process. I’ve never found a great definition that really covers the whole thing in my mind. There are really a couple of key attributes at the core of human-centered design.
- Developing insight by gaining empathy for users to better understand their needs and contexts
- Reduce risk through ongoing testing and pivoting based on results
One of the benefits of it is that we’re developing insight by gaining empathy for users to better understand their needs and contexts. So, human-centered design, overall, to me, is a way to move forward into the unknown and reduce our risk as much as possible. We do that by better understanding who we’re designing for.
And then, second of all, we use prototyping and testing to learn about how well we’re doing things, and then pivoting based on results. This helps us reduce risk. We’re going to make changes based on the feedback we’re getting. And, if we do this properly, and we do this in a way that it iterative and we improve design through testing it allows us, again, to design into the unknown.
I would say 10+ years ago, when the Internet was newer, and there weren’t so many channels for products, it was easier to make design decisions because things were new. There weren’t so many challengers in the marketplace. Now, it’s so easy for people to do spin up new products and launch different ideas. We’re all inundated. So, how do we make sure that we’re following the best course forward to develop our own products and services and to find something that’s going to gain traction. So, that’s the fundamentals of how I define human-centered design.
Slide: Harvard Business Review Cover: The Evolution of Design Thinking
Why should we care about all of this? Because human-centered design started leaking into the consciousness of business, overall. This was Harvard Business Review’s cover in I think 2015, September. It’s been a couple of years, now. But, you can see design thinking, which is one of the processes around that it uses human-centered design at it’s core.
People are using it more than for just designing the next thing. We’re using it as a strategic framework when making decisions and guiding strategy. So, it’s really gotten into the consultant’s hands and everyone’s jumped on the bandwagon. It’s top-of-mind for people and I think people are trying to use it in their work and we’re starting to see it misused, too. So, we’re going to talk about that a little bit.
Slide: In the last ten years design-led companies (those using human-centered processes) outperform the general S&P by over 200% -The DMI Value Index
The only reason that I think people are starting to care about design-led strategy is there is more and more proof that design-centered and design-led organizations are providing value. And, so this is a stat I pull out because it’s one of the ones that’s been tracked over the course of the last few years. Design Management Institute Design Value Index has been tracking companies that they consider being design-led and you can guess who these are. Apple, Coca-Cola, Herman Miller, IBM, Proctor and Gamble, Starbucks, Target…you get the drift. These are companies who have put human-centered design and design leadership at the center of their strategy, and at top leadership positions within their organization. And they’re starting to show that, over time, they’re outperforming their competitors. And we know design is showing some value. People are bringing it in, and we think that’s good.
Slide: Diagram – Design Thinking
Now, I’m just going to show you a couple of diagrams. Because, humans-centered design, design thinking, and other processes have different models and slightly different focuses, people get confused on what frameworks we’re including. I just want to go through that a little bit. I’m sure some of you will recognize this one. Any guesses out there? Type it in.
Actually, this is the classic design-thinking method. You can see the overall process is really about empathizing, and it’s empathizing to create definitions, understanding user wants and needs and also prototyping once we think we have ideas that might work. So, it’s a way where we can go through a design process and come out on the other end where we’ve considered many options. We touch bases back with our customers or our clients, and those who we’re design for, and we are continuing to get ideas, focusing and flaring to get to a better answer.
I don’t intend this presentation to be getting into the details of how the process works. There’s a lot out there that you can read about. Check it out online by searching “design thinking”. But, this is one method that people discuss in trying to implement.
Slide: Diagram – Lean Startup
There are other methods, too. I want to who another methodology. Anyone know this one? This is a popular framework and we have lots of clients who are using it and especially in start-ups or developing new products. This idea is Lean Startup. The idea is that we’re incorporating some ideas of Agile and some ideas of design think to get products fast with quick releases. But, we’re doing it in a way that works as a continual learning cycle. We’re learning from our customers and measuring it. So, I would also consider this is another tool set that has human-centered design at the center of it.
It’s interesting Eric Reese has a new book coming out, The Start-up Way. I think it’s out now. I haven’t read it yet. It’s on my list. But there may be some other insights that he brings to the table in terms of how to implement design and development more smoothly for best affect.
Slide: Diagram – Fogg Behavior Model
Here’s another framework that I bring up a lot. Some of you may be familiar with this. It’s the Fogg Behavior Model that B.J Fogg designed that at Stanford. We use this design framework when we work on behavior design. We would use this methodology in designing things such as health and wellness applications where we are trying to help people change their behaviors. If you are familiar with Nir Eyal, he uses this framework as the basis of his popular book, Hooked: How to Build Habit Forming Products.
You can’t do behavior design without fundamentally understanding your users. And, so, it’s another design technique that really requires us to have human-centered design as a part of that tool set. Otherwise, we’ll not able to really understand users enough to make effective solutions.
Those are just three processes that we all know about and have used. I’m going to make the argument, here, that right now it’s not about the process. We all have these great processes. What’s getting in the way of these working for us in the best way they can, is putting them into practice. Again, we all read books and think we understand the process very well. And that’s all well and good. But, the practice is really what matters. That’s what we are going to talk. I also want to say, too, that none of these processes, or frameworks is set in stone.
We also believe that each organization has to find their own way of doing things. And I can say for sure that our clients have different combinations of frameworks they use. We have one client that’s focusing on Lean Startup and they use observational research, story telling, and product prototyping to get things done. We have another client that focuses on design thinking, research, and prototyping within their strategic decision-making processes. We have another client that’s combining design-thinking, Lean Startup, Business Model Canvas and Agile.
Slide: Process vs. Practice
Process is important but it’s the practice of that process that matters.
Everyone is doing this a little differently and we’re not against that, at all. But, I still think there are some fundamental issues that are cropping up no matter what you’re implementing. Process is important, but it’s the practice of that process that really is key.
Slide: So, how can we improve our practices?
So, how can we improve our practices?
Slide: What are the Common Issues?
Big, siloed companies but in startups too.
And, what are the common issues that we are running into? The ones we’re going to go through today, and again, I’m hoping some of you will be able to give me your thoughts on different things that you’re running into in your organization. But, we see these running across big siloed companies as well as small startups. So, none of these issues are exclusive to one kind of company or one-way of working. These are just some of the common things that we’re seeing across the board, mistakes, or issues that are popping up.
Slide: ISSUE: Understanding the difference between building a minimum viable product (MVP) versus meeting a deadline
The first one is really understanding the difference between building a minimum viable product versus meeting a deadline. This is a big problem, and we run into it all the time. I would say 100%, our clients come to us and say we need to develop X by this date. And I’m also going to venture to say that the date is chosen based on a budget cycle.
So, it’s usually six, nine months or one-year increments. I know people are pulling those dates out of their head. Somebody promised something out in the world by a certain date, and it has to launch. The problem is that when you are working on a new product, new idea or even new feature or functionality you are designing into the unknown. Using and human-centered design approach allows you to work on gaining empathy with our customers and then iterating an idea until we get it right. This doesn’t always happen on an expected schedule, so what can you do? We have found that working within in agreed launch timeframes is a better approach then work towards a specific date. We know it is not possible to completely ignore time. Funding is funding and you have to work together with the business interests, but if we can work in timeframes, say a two or three month window rather than a specific date and time, we have the flexibility to make better decisions on when a product is ready for primetime. You only have one chance to make a great impression; so don’t squander this because of unrealistic timeframes or expectation setting.
I’m going talk about an example. I don’t know if all of you know Slack. We use it. They’re great. Our goal in using Slack was to get rid of all internal email that flooded our inboxes. Slack lets us communicate internally with real-time chat and thread features to keep everyone informed about what’s going in. Slack says they are really not fundamentally a chat system, they say they’re “selling organizational transformation”, and I would agree with that, to some point.
There was a great case study that came out this last year about how they were working on one of their releases. Slack was trying to implement threading conversations, and as you know, threaded conversations are kind of a difficult thing to design. Think about your Gmail account. I use Gmail on a browser and email exchanges, the back and forth, are strung together in a way that can be very difficult to find a specific email that you want to look at.
I’ve gotten crap from my colleagues about why don’t you use a different system to read your email? But you can’t teach old dogs new tricks. There are just too many other things to learn. So, I just keep using this less than desirable method.
Anyway, Slack tried to solve this problem. As I mentioned, when they talk about their brand, they say they are selling organizational transformation, right. They were not about to put out a threaded conversation function, or a new way of doing it that didn’t support their brand proposition.
So, interestingly enough, they decided that they were willing to design it until they got it right. It took them two years and six iterations, and rounds of testing within that, before they released their threaded conversations design. I think there’s something to learn around that. I like this quote from Christina Holsberry Janzer, Slack’s Group Manager for User Research. She said, “It can be easy to build something that people request, but what’s really important is to build what they need.”
Imagine if Slack had said we’re going to release the functionality in six months, or we’re going to release whatever we have in that timeframe, where they’d be. Would this they be living up to their brand standards and would they align to what their users needed. I really do think that we need to rethink this whole way we think about deadlines and how would you will release your next product or upgrade? Fixing a specific deadline when you don’t know where you are designing to is not aligned with human-centered design.
- Understand what your MVP is through customer input, not internal deadlines
- Define not only features but required functional competency for launch/release
- Decide who holds the launch codes
So, in practice, to solve this problem, understand what your MVP is through customer input, not internally driven deadlines and released dates. Slack designed and tested their new functionality with people, and people they trusted in giving them information back in a way that was going to lead them in a better direction. So, I’m not saying we have to throw deadlines out, not at all. Slack obviously has control of their lives in a way that departments or product lines in big companies may not. Other than saying we’re going to release something on January 1st, maybe we say let’s look at the first quarter. We’re can agree to release something within this quarter, and that’s going allow us some time and some leeway to make sure that we have a real MVP, and the MVP is understood, and that we’ve got something of value for clients to use which is not based on deadlines.
Again, I think we each have to work on this our own way within our own organizations, but looking at giving teams leeway on when to release things is going to be needed, because again design thinking and human-centered design is about understanding through iteration so maybe we need to break things into smaller chunks, and allow for more leeway on release deadlines.
Second, is defining not only features, but required functional competency for launch. Think about what really needs to work? What’s going make or break and what’s going be align with our product and what’s going align with our brand and not align with our brand? I think some of those bigger conversations need to happen, while we’re in the heat of the moment of trying to release something.
And then, I also think besides just thinking about the launch date, who holds the launch codes. For this example, thinking about human-centered design, where does the buck stop? I think cross functional teams and putting together a group that can say hey, code’s good, content’s good, design is good, we’re going to release, is probably the best way to do it. How do you do that? Think about this decision more holistically, and how things are built. I think each company has to decide how they’re going to make the decision, but make it a thoughtful approach, and not just, we’re going turn release something half-baked because we’ve made a promise to somebody.
Slide: ISSUE: HCD practice gets dropped once the build or integration gets started
So, next issue. This is another one we see quite a bit. And I think this is because human-centered design is really a new practice for most companies, but many of our clients get super excited about, okay, we’re going to bring human-centered design to our next build, and our next product release. And you get aligned and use human-centered design for that first build, and then once that first build goes out, that’s it. We forget about it, because now we’re now into Agile processes and development takes over and then we get into development back log so, we just don’t have time anymore to think about it.
That is not going to be sustainable, and again, you’re not going to see the benefits of the practice, if you do it for a while, and then drop it. We have written a bit about integrating human-centered design with Agile. I’ve written a recent blog post about Integrating Agile with Design Thinking. You can find that in our blog sections on our website. This goes into more detail about this topic.
- Fully embed design & development
- Ongoing user input
- Developers and designers should be doing this research
One of the things that we feel is really important is fully embedding the design and development team to work together throughout a project. Many times, these disciplines are siloed. Design does some up front work or does some work for a while, and hands off their work to development. Also, we are often designing site patterns that development can use again, which is great. We want to empower development as much as possible to move ahead. But, we need integration, cooperation and collaboration between design and development going forward if we want to keep human-centered design methods going. We can’t forget about ongoing user input. I’ll talk a little bit more about this later in the presentation, but developers and designers should be doing their own research. You might have a research team, within your organization, and that’s great. I think as many people doing research as possible is great, but designers and developers need to be part of this ongoing empathy gathering with customers and clients. How do you do it in a way that’s not too disruptive to the process? How do you get that information out to everybody in a way that’s shared?
We’ve got to work on ways to keep people working together. Shared metrics can be an important tool for this. There are lots of different tool sets for that, but OKRs is one, OKRs stand for “Outcomes and Key Results”. You can delve into these a bit more by searching online. But the way to use these is to, let’s say, set a quarterly goal, for an outcome that we’re looking for. These can be bigger ideas and broader outcomes that want to see. A good OKR might be “We want to create the best user experience possible”. And so, how do we start actually looking for these results, and designing to that?
You can’t work towards these kind of big, broader goals in a silo, you need people working together. So, identifying the tools that will allow us to continue developing and working together, embedding people, it’s super important.
Slide: ISSUE: Communication silos cause teams to be siloed
So, this is kind of an obvious one. Communication silos cause teams to be siloed. But it’s amazing how many teams use different tools or systems depending on where the project is at and who is involved. Email, Jira, meetings, slack…designers might use one set of tools to communicate and the development teams use another. This then doesn’t expose discussions or decision-making processes to the entire team through the full process. This will cause misunderstandings and sometimes resentment and get in the way of teams working together in the best way possible. It ties back to that last observation that we really want to keep teams working together.
- Establish shared vocabulary
- Create clear channels & shared tools
- Craft clear decision points
- Require some face time between teams
- Consider using OKRs to keep teams working on common objectives
Here are some things that we see that cause communication silos. Often this is the outcome when we start trying to cobble different processes together depending on where we are at within the product development process. Maybe we’re using Agile part of the time and using human-centered design another part of the time. Again, this often happens because some of these processes are new for companies and they revert to their old ways unless someone is diligently working the process. Also, each process has its own vocabulary. Even within the human-centered design practices like Design Thinking and Lean Startup, it’s amazing to me how many different processes call similar aspect of human-centered design different words or terms.
So, let’s create a shared vocabulary. Each framework has a lot of jargon associated with it, so, how do we do we cut through that clutter and define terms at the beginning of a project. Also, this is important too, but create clear channels and shared tools. It doesn’t matter what type of product development you are doing whether it is building a building, developing a product that fits in your hand or working on a digital product. The silos happen in each industry. Architects issues handing off to the engineers and product designers have to work with manufacturing groups. Again, we’re more on the digital side so that’s the world I know, but I am sure if you’re working in architecture, if you’re working in any kind of product development, you have your own silos. So many of us are handing things over the wall to different skill sets, and everyone has their own channels and their own way of working. So, these shared tools become important. So, you have things like JIRA or GitHub. Often the designers are not in there. So how do we make sure that we are able to connect those dots for people?
Crafting clear decision points. Again when we get into the crunch of it, and we talked about this earlier, we’re launching things, we also need clear decision points throughout the process, again, connecting the dots for people.
I have a colleague, Bobby Broneak who just published an article about getting communication working better with development teams. One of the things he noted, in it, and I think it’s a really good article, which should come out soon, if it’s not up already in the blog is that teams need time to work together face to face and not just through digital tools. This is a pretty bold thing for a developer to say since the developer stereotype is someone who wants to stay behind their computer screen and not talk to other people.
He talks about an experience our team recently had. We’ve been working with a client on a big platform. It had to be developed quickly in a nine month sprint, and they had so many development teams working concurrently that we found that different development teams were developing the same templates, meaning team one was developing the same template as team two which meant they had to decide what to do. So, at the end of the day, we had these different templates that had been developed. They had followed the same design patterns but things were managed a little bit differently in each of the designs. First, we have an incredible waste of money by developing the same thing. The cost of the both teams working on the same thing when they could have been making progress on another part of the build, and second, you’ve got team morale. Which on of their templates is going to be the one that gets picked to go forward?
So, the key thing we’ve learned is that we need face time between teams. Sometimes, too, we need pictures of what we’re developing up on the wall, so we can see them and just check it off. We’ve got all these great tools, and we’ve got all these great systems, and sometimes, we just need to get out of them.
The big theme with all of this is human-centered design supports is that we’ve got to get out from behind our computers sometimes and actually talk to each other. I know that it’s difficult to do when we have teams in different countries, working on different things, but maybe we need a go-between. Bobby mentioned this in his article. He called this role a worker bee. You know somebody who could buzz between teams and actually talk less about Scrum checklists, and more about the big picture of a project and what needs to get done.
How do we keep pulling up from our deep depths when we’re doing these big projects to work with the big picture? And human-centered design to me is a good tool to keep getting feedback and checking in with our customers to allow us to make sure that collaboratively, as a team, we’re working together on things that matter. And I mentioned this earlier, focus your OKRs to keep teams working on common objectives.
Slide: ISSUE: Your old research methods don’t work
Here’s another thing we find. People want to do the human-centered design research, and they find that their current research methods don’t really support it. So, here’s an example, and I’ve used this before so some of you may have seen it. This is a Forrester report that came out a few years ago that talked about how our organizations gather voice of customer data today. And the thing that is quite amazing from this is that People are doing mostly surveys. And we see that all the time. You go on any kind of airline flight, you get a survey at the end of it asking you how great it was. And then they’re not going to really let you tell them how bad it was.
And so, structured surveys are a tool but they’re not the right tool for human-centered design. You can see also by this chart, that people do some qualitative customer research, but some of the other data that went along with this chart stated only 27% respondents said that they exposed their executives to customer one-on-one interview information. So, even through they are doing qualitative interviews, that qualitative data isn’t reaching those decision-makers. Also, only 18% said that they shared customer call recordings across the organization. So, even the people who are gathering that really good qualitative data that we need to be considered in our human-centered design practices, it’s not getting into everybody’s hands.
This is great information so that we can start really thinking about, if we are going to do human-centered design, how do we reorganize around doing the right kind of research?
- Don’t call your research department
- Observe customers using your product in real time in their real environment
- Listen to customer stories
First I would say don’t call your research department. I don’t recommend that research be done outside of the teams that are actually working on the product, for those day-to-day decisions. Research departments are great, and they’re good at potentially getting some of the metric stuff we’re going to talk about later. But in terms of actually using human-centered design, we’re talking about rapid iteration, and we want to get things quickly.
And often because research has been entrenched and done certain ways in the organizations, research will be done once or twice on a project, and then it’s too onerous to do on a regular basis. It is our opinion that we can do smaller scale research observations, and we don’t need that many of them. We do need to observe customers using things, and we want to do that on a more regular basis.
So, how do we do that in a way that’s not going to be too hard for the organization? I do think that you’ve got to get your team doing that research, and then also listening to customer stories. How do you get those stories? How do you go out and regularly engage with customers? There’s kind of that low-fi, I’m going to look at how do we gain input day-to-day so that we can keep information coming in; that empathy gathering going. And then, how do I get broader stories.
I do think tying that, tying this function to longer term objectives, like OKRs, will help us make sure that we’re going out and doing regular customer listening sessions that are open ended, and which allow us to hear stories. Listening to stories with the goal of listening for what their overall needs are outside of the specific functions that we’re working on.
So again, researchers should be the people working on the products so they can keep the big picture in mind. Observe customers using your products in their environment. This kind of research is really great for features and functions. And then we should also take a step back, and listen to those broader customer stories. Once we have the deep customer research and understand their needs, we can then go to our research department, sales department, customer support department for the additional information on customers so we can really start connecting the dots to understanding how are we impact our customer.
Slide: ISSUE: Design Thinking or HCD doesn’t replace DESIGN
Also, this is another issue we’re seeing. And again, this kind of comes down to a debate around is human-centered design working. Design-thinking and human-centered design don’t replace design, and I just want to put that out there.
- Design Designers still need to design
- Empathy/Understanding needs to be part of the metrics, not some fluffy goal
- Roles need to be defined
So, here’s the issue that we’re seeing. When we start training people on human-centered design, and we make it a cross-functional practice and process in the organization, we forget that we still need design. I’ve heard a lot of designers calling for more of a conversation around this issue. When we train a team to lead through design thinking it doesn’t mean that everyone is a designer. Design thinking core focus is to get us oriented towards what our customers’ needs are and to help us better understand those needs through regular empathy gathering. The great power of design thinking is that everyone on the team becomes the steward of this focus on the customer and keeps the team orientated towards empathetic design. Design thinking also helps individual team members lead with creative confidence to help them think more broadly and differently than the roles they’ve been given in their organizations.
The idea that design is still needed in design thinking was a critical discussion at the DMI conference we were just at, held by the Design Management Institute. Designers really have had an issue with this. And I also think, on the other side, that the idea that everyone can be a designer is great and helps unleash new creativity in a team and helps coordination, but at the end of the day, designers still need to design.
Design-thinking and human-centered design doesn’t replace the idea that we still need to design things. Design is a practice, and designers have ways of doing things, practices and skills that take years to refine. We shouldn’t take this for granted. Design-thinking is often touted as a way to come up with better ideas, and it is, but at the end of the day, ideas are pretty easy to come by. Functionally, making those ideas work for people is much harder. Human-centered design is great tool set for aligning teams around the idea of empathy, and this is what I would say, design-thinking is about. Empathy gathering through the whole process, and then testing the ideas early and often so we can reduce risk and make products work better for people. It’s nothing to do, at the end of the day, with the functional process of designing. It helps the process but doesn’t replace it.
We want cross-collaborative teams, but when we’re actually designing the thing, coders have to code and designers have to design, and business people have to make sure that the business model is working. We need to make sure that we’re not getting design thinking and human-centered design confused with the actual process of putting something together. And I do think there’s been a little bit of confusion about that. It’s great to train people on human-centered design. I think everyone should learn it and understand it. But it does take experts to actually make it work.
If you think about it, Malcolm Gladwell in his book, Outliers, talked about how you have to put in 10,000 hours towards honing a skill or studying something to become an expert at it. And I really do think that’s true with some of these tools. It takes practices and ongoing use of the process to become expert at it. It also takes time to learn how to become an expert designer, whether it is graphic design, architecture or user experience. So, we do need to let the people who are doing the actual design work and making things from every expertise, from engineering, through the visuals, to functionality. We need to let that happen in a way that it happens best. So, we still need critique for design. We still need quality assurance. So again, let’s not confuse the design frameworks that we’re talking about here with the actual production of product or the experience.
Also, I would say empathy and understanding need to be part of our metrics, not some fluffy idea that we talk about in the abstract. We need to be better about measuring some of these things, measuring our understanding. I’m going talk a little bit about that in next section of the presentation.
Finally, roles need to be defined better. There is confusion sometimes in working in design thinking on how to use our human-centered design tool sets. You know, who does make decisions? That still needs to be clear. It’s not that we want to do things the old way. Don’t get me wrong, and again, we talked about that earlier, you don’t want to slip into our old framework. There needs to be new ways of doing things, and we need to be more collaborative. But roles still need to be defined, and people still need to do their job.
Slide: Creating a Culture to Support HCD
So, creating a culture to support human-centered design.
Slide: Learn from Others
Get our of your office-that means EVERYONE
First, we need to learn from others. We need to get out of our offices and talk to people, even it is somebody down the hall. That’s better than nothing. Even if is not someone who exactly fits your demographic or target market.
Some people are better researchers than others. They know how to look and listen. Those, team members are like gold so treat them well. But no matter what, even if you don’t have research training, it is helpful to get out and learn from people interacting with your products or ideas, even if it’s just to observe what’s going on.
And again, research, in this case, is not about writing research reports. If you want research reports, go to your research team. In this case, it’s research to develop the next generation of a product. It’s applied research. So, don’t get so hung up on the research word, just go out and observe.
Slide: Fostering multiple methods to connect with your users & customers
Fostering multiple methods to connect with your users and customers. I think combining informal and formal, user testing is appropriate and helpful. We’ve been usertesting.com. If you want to do down and dirty, quick testing, it is helpful. It’s not that expensive and you can get results from the test in a day. Your product team can develop the test plan.
We’re fans of some types of customer panels. We’ve seen a number of customers use these well to engage and co-create solutions to product or service challenges. It is helpful to get to know your customers who are willing to engage on that level. They care and they’re willing to spend time with you to help you solve your shared challenges. They are usually people who will want to help, because the work that you’re doing is critical to their lives. So, why not use that to help? And then, we’ve worked with customers to try some longer-term formats for information gathering—customer diaries and that type of thing. We’ve had some challenges with that, but it’s worth investigating. Trying to get people to actually communicate with you on a regular basis can be challenging. Anyone who has any thoughts on or ideas for how they’ve gotten people to connect with them on a regular basis and provide information ongoing, let us know what has worked for you. We’ve done a couple of different approaches with that to varying degrees of success, but it would be great to know what’s worked for you.
Slide: Measure Empathy
Measuring empathy can be difficult, but it’s important to create benchmarks with the team around client knowledge, understanding and empathy. Measuring assigns value, so we want to get better at that.
Slide: Creating and support cross-functional & interdisciplinary teams.
And then, creating and supporting cross-functional and interdisciplinary teams. Let’s make information as accessible as possible; get designs up on the wall. Scrums are great, but we’ve got to make sure that the information is getting to the right people, and not just checking off the list.
So, a cross-functional team, an interdisciplinary team, we talked a lot about that and some of the problem areas earlier. I do feel like we need to work across skill areas on the bigger idea, but we want to have input from each skillset that is required to build out and develop the final product.
Slide: Learn to manage ambiguity
And then, learn to manage ambiguity. So, Stanford, and the Stanford’s d.school, who teaches and originated design thinking methods, has gotten away from just showing and teaching the process these days. They have gotten more into showing the mindsets we need to do human-centered design well. Knowing the process but not applying the mind sets, I think, is the one thing that gets in most of our customers’ way. One mindsets that is hardest for most of our clients is learning to manage ambiguity.
So, when you have a checklist of features that you’ve got to develop by a certain date, that feels really concrete. It’s comfortable. It’s what we’re all used to working with. It’s the old way of working. It’s really hard to get people off of that. And that, again, harkens back to the deadline MVP approach. Design-thinking is about moving into ambiguity. And when we’re working on new ideas, and new approaches to things, or trying to learn from our users what their needs are and what’s going to work for them best, that’s ambiguous. We don’t know what we’re developing yet. We’re testing assumptions. We’re testing ideas. It’s a little bit more aligned with the scientific method. We might have theories, we’re going to test them, but this, lack of comfort with ambiguity is the tough one.
So, this kind of is an over-arching thing that gets in the way of implementing design thinking across the board. So, how do you start developing the metrics and the data points around this and you can feel like it’s not so ambiguous? When we’re designing, everything’s ambiguous, right? I mean, we can have a checklist of stuff we need to design and our goal is X, Y, and Z, but we don’t know what the results of that is going to be.
So, it’s frustrating to see in so many cases that people are really excited about launching their new thing, and because they haven’t done the due diligence around it, it launches and it fails, and we know those stats, you know, what is it? 80% of new products and new companies fail? It’s true. So, let’s just embrace that. We can start from the checklist, or we can start from uncovering needs and use the design thinking methodology to learn if our solutions work. We have to choose which method is most acceptable to our organizations. Right now we are in a bit of limbo land in most of our organizations, working with both approaches.
So, I promised to talk about metrics. I think I mentioned I have a return on investment blog post, so, if you want to dig deeper into some of this thinking, go to our website and you can read a little bit more about it there. I recently did some digging around and some research about how different organizations are measuring success, and how they’re measuring their return on investment with their design thinking methods. Here are some things that we found.
Slide: Traditional Metrics—external metrics
- Customer Feedback
Customer satisfaction, net promoter scores, response to specific campaigns, usability metrics, client feedback
- Anecdotal Feedback
Evaluation forms, qualitative feedback at each stage of the design thinking process, surveys
- Traditional KPIs
Increased Sales, ROI per project, and other financial measures
Companies are using some traditional metrics to get started. Customer feedback, customer satisfaction, net promoter score, response to specific campaigns, usable metrics, customer feedback, this is the stuff that we’re using now. What’s been hard is that it’s hard to track this data back to a particular piece of work that we’re doing with human-centered design, because it is an ongoing way of working.
The thing that people have started doing is looking at change over time. If we’ve started the human-centered design work, is it starting to make a difference over time? Again, this is not going to be a quarter-to-quarter measurement, it’s going to be looking at broader customer stories and change over time. That’s the hard part about leading with tradition metrics to measure human-centered design.
Another tool that people have been using is anecdotal feedback, evaluation forms, qualitative feedback at each stage of the design thinking process, surveys. Actually, we do believe that you can you use those internally, not just externally. So, for example, how is your team working? I think using it to help inform working better on your team. Is a way that human-centered design could have an impact both internally and externally.
One of our clients that we’ve been working with for five years to implement human-centered design has said that the work has impacted their internal team more than almost anything. It’s obviously helped them save money and do some other things. But their internal team is much happier in the way they work, and that has had a significant impact on how they service their customers. They are seeing this change the culture of the organization.
Slide: Traditional Metrics—internal metrics
- Design Thinking Activities
Number of projects, people trained, coaches trained
- Quick Results
Concepts finished, projects launched, projects funded, projects in development
Team efficiency, engagement, collaboration, motivation
Other internal metrics to look at are number of design-thinking activities, number of projects, people trained, coaches trained. We’ve had clients measuring against this, who can start showing integration across the company. Quick results. How many concepts have we finished? Projects launched, projects funded, projects in development. Those types of metrics can show action and results, and finally, culture through efficiency, engagement, collaboration, and motivation. Measuring those activities is a way to start saying hey, here’s some things that we’re doing and we can then start aligning to their impact on the organization.
Slide: Measure Empathy
An important thing we need to start doing is measuring empathy. One way we can begin to do this is measuring customer interactions. How many times have we interacted with our customers over the course of the project? Another tool we seen used is measuring days between observations, with the goal of reducing time between interactions with customers. If you start incentivizing that, that can be helpful to keeping research going.
And then, alignment to personas. A lot of personas are made up out of thin air, and that’s not a way we do it in human-centered design. We want to build these from research. So we have personas, what are we learning from our customers, what is the insight and is it getting applied back to personas? So are our personas, right, based on the information we’re getting today? How do we ensure we getting the right diversity of voices in the room? Do we have the right people? Are our personas right, aligned and accurate? Users change over time. Again, I’ve seen many personas that have been based on the general demographics or third-party information on the type of customers that we’re looking for. That’s not human-centered design. We need those empathy metrics; we need to understand their desires. This is information that we can only get by talking to people. So, for measuring empathy, these are three ideas of we can begin to use to start ensuring we’re doing the empathy work that the human-centered approach requires.
Slide: Measure Business Value (chart – valuable/not valuable – novel/not novel)
And then, measuring business value. So when we come up with new ideas, new products new functionality for our customers how do we measure business value? We have a matrix here, valuable/not valuable, novel/not novel. So, if we’re looking at measuring human-centered design against how it adds value to the business this is a nice benchmarking tool. You can measure new product ideas? Or functional features based on this metric? And again, can you measure that both internally. What do your internal teams think about this? And then, measuring value with engagement from users. So, if you just want a business-value metric, here is one that is simple and easy to implement and use. When you’re looking at your OKRs or some of those other measurement tools, this might be a good tool to benchmark these against as well.
Slide: Measure Innovation
- Innovation is a numbers game
- Number of prototype iterations per feature
- Number of concurrent prototypes
- Study (Dow et al, 2010) suggests that developing prototypes in parallel rather than in series results in stronger outcomes
And then, measuring innovation. As we all know, innovation is a numbers game, right? The more ideas you have, the better likelihood that one of those ideas is going be right. So, here are some ideas we’ve seen clients use that have been focused on measuring innovation. Number of prototype iterations per feature. So, how many times, and how many prototypes have you come up with? When thinking back to that Slack example, how many versions did they go through before they came up with their final version? They went through a lot, and they tested it quite a bit. So, how many times and how many ways have we tried to figure out how to solve a problem?
And then another one that’s come up is number of concurrent prototypes, which I think is interesting. How many prototypes have you developed in parallel rather than series to get a stronger outcome. So, it’s not just a number but doing them at the same time. So again, you might want to do some multiple versions of how to solve a challenge or design a new feature and test them concurrently. This came out of study in 2010 that showed when teams developed concurrent prototypes they ended up with a better solution.
Slide: HCD is a practices
Which means you have to practice it!
So, just a reminder, HCD is a practice. Human-centered design is a practice. You’ve got to practice it, and you’ve got to make sure that we’re working on those areas that can be issues going forward. So, go out and practice. Doing this will lead towards better strategy, better designed products, happier teams, and at the end of the day, more revenue. All right.
I think that’s it for the presentation. We’re ready to answer some questions. Anyone have any questions or any thoughts about how you’re doing design thinking and how you’re managing some of these areas in your company that may be issues? We did have one question come in.
Question 1: What is the first thing teams should do to improve their design thinking process?
That’s a good one. I think it kind of depends on what your organization is using right now, in terms of the tool sets. I would say communication is the key thing. I mean, that sounds so fundamental, but it really is the thing that we see break down the most.
When you’re working together, and you’re working on large products, services, ideas that are going really impact and organization, because that’s what you generally human-centered design is applied to. I think the main thing that needs to happen is that we need to think about how communications works. It has to be different and again, get back to that managing ambiguity piece. When you’re managing things that you’re working into the unknown, I think we can learn some things from how scientists work.
So, what tools do scientists use to make sure that they’re communicating where they’re at, in status, with any given project? We all have to design something that ends up getting launched into the world. Having those communication points that are cross-functional, that work together, that everyone can share, along with just shared decision making, is the key thing here. So, I think it’s, in a sense, if we start with communications, that’s going be a good place to start.
Question 2: What is the main weak point with design thinking?
There’s another question. What is the main weak point with design thinking? Interesting question. I would say right now, it’s the understanding of it within organizations. Again, it’s easier to go out and take a class or read an article, and feel like you understand the process, because it’s pretty simple. It’s not that complicated. But, it’s a fundamental shift in how we make things. As I said, it’s a way to reduce risk and work quickly to understand what is working and what isn’t with customers. This is such a complex world that we live in. We’ve got to turn things over quickly. We’ve got to come up with new ideas faster than ever to stay relevant, and it’s a good tool set for that.
At the same time, we still are running our businesses, and running our organizations in the old way; where we took awhile. We had an idea of what we wanted to create, not based out of nothing, obviously. We were basing ideas on a theory. Every time we have a new product idea, it’s a theory, right? And then, we build it. The old way is we spend a lot of money, we build it, and we put it out there. And when there were less products and services in the market, and there was less competition, you could probably get away with getting something out there that did something different that interested people. Maybe it wasn’t easy to use, but it was just different enough that you could attract customers. There was just less competition.
But now, new products have got to work to a certain degree, and they have to work to a certain point for users to have them even consider it. So, I think the main thing that is the weak point is, understanding design thinking and being able to implement it into our organizations along with the way that is structured and supported right now.
Question 3: Who is Integrating design-thinking well, into their organizations?
Another question. Who do you think is doing this well? Integrating design-thinking well, into their organizations? Good question. I think, again, we’re in process with it. We have a good friend, Doug Powell, who works at IBM, and we’ve talked to him over the years. I know IBM is doing an interesting job of trying to get design processes and human-centered design embedded across the company, and they’ve spent lots of money, and lots of time, training people across the organization to become a design-led organization. I can’t tell you exactly where they’re at. I know they’ve trained a lot of people. I think that’s a good first step when people really have an understanding of it, and they can start practicing it. That’s getting back to that Malcolm Gladwell idea that you need 10,000 hours, or you need a certain level of practice to make this stuff work. It’s just doing it over and over again, and then looking at what’s working and what’s not working.
So, when you look at these items I went through today, you know what’s breaking down in your own organization and where do we start focusing our time on it. I understand Intuit is actually doing a lot of work on embedding human-centered design across the organization, too. I know they regularly have people getting trained at the d.school at Stanford.
The other thing I’ll say about Intuit too, they have an interesting way of doing metrics. Their whole company’s embraced the idea of using user stories and the bigger story idea around how it’s impacting, their design is impacting customers. So, the fact that they’ve been able to, as an organization, say it’s not just data streaming out of one metric set, or just surveys or whatever it is. We’re going to look at a holistic story about what’s impacting our customers. I think that’s pretty interesting. So, that might be a model to look at. But that’s what I know right now.
Let’s see. Anybody else? Any questions? You know what? I really would hope that you follow up with us afterwards. Feel free to email me my email address. It’s Lisa.Helminiak@azulseven.com, or you can just send it to firstname.lastname@example.org off of our website. We’d love to hear thoughts, your ideas about what’s working and not working at your organization, or things that we missed. What did we miss that is an issue that’s popping up in your organization? This is a topic of interest for us, going forward, and we hope to gather more information, and do some updates as we gather more input from clients.
But thank you, today. We’re at a little over the hour. I don’t want to keep anyone any longer. Thanks so much for sticking with us through this, and we appreciate your time. Thanks so much. Go out and do some human-centered design. Thanks, everybody.