005 - Why human-centered design matters

What is human-centered design?
How do you balance qualitative and quantitative data?
What role should empathy have in product development?

Mariah Hay discusses these challenges, and offers a look inside Pluralsight’s design process.

• Mariah’s LinkedIn profile
• Observing the User Experience: A Practitioner's Guide to User Research
• Measuring the User Experience: Collecting, Analyzing, and Presenting Usability Metrics

If you enjoy this episode, please consider leaving a review on Apple Podcasts or wherever you listen.

Please send any questions or comments to podcast@pluralsight.com.

Jeremy

Hello, and welcome to All Hands On Tech, where today's leaders talk tomorrow's technology. I'm Jeremy Morgan. Design is everywhere. Everything you use, from a fork, to your cell phone, to the roads you drive on came from a design. When a designer takes their work seriously, it can become almost spiritual. For human-centered designers, the passion comes from making someone's life better through your designs. It's putting the human front and center, empathizing with them and using their needs and desires to drive your decisions.

Today I'll be talking with someone who puts human-centered design to work every day. Whether she's designing a product or even designing a team structure, Mariah Hay is our Head of Practices here at Pluralsight. And we're going to talk today about human-centered design. So let's welcome Mariah Hay. So tell us about what you do for Pluralsight. 

 

Mariah

Yeah, I'd be happy to. My role at Pluralsight is Head of Practices, and I know that that's a title that's a little unfamiliar in our industry, but the people that report to me a lead, how we do work for engineering or data. And that includes data science and machine learning. For product management, for product design and because we're a learning company or instructional design. And they have groups of principals who are very senior individual contributors that report to them and those principals are deployed out across groups of product experienced teams that are the cross functional teams that actually build our products. We are there to help support and how we do the work that we do and try to keep consistency and uphold quality across all of the different business units that exist within our experience work.

 

Jeremy

That's awesome. What kind of challenges are you facing right now? 

 

Mariah

The biggest challenges that we're facing right now, we're kind of at an interesting point in time because practices did not exist until March 1st when we changed our org design. Before that we didn't have practices, we were a bit smaller and we didn't have business unit leaders over groups of teams. We just had lots of teams. So now we've got these excellent business unit leaders over groups of teams that are really tasked with the strategy of the entire product and all of the things that we're delivering to our customers, both internally and external to the company.

And so we are learning now how to be very good collaborative stewards at the leadership level, so that we can provide really clear strategy and support the teams. And I feel like we're moving in the right direction with that, and it's been really positive, and there's even more that we can do. We're looking now at cadence, on timing and level of fidelity and how those things impact teams, being clear on the outcomes we're trying to create so that the teams can go use our pract product and design and engineering practices to be creative and find the right solution to go create those outcomes for the customers.

 

Jeremy

And what kind of background did you have previously before getting into this role?

 

Mariah

Yeah, that's a great question. So if we go to the way, way back, I actually have a master's degree in industrial design. And for those folks that don't know what industrial design is, it is the development of physical products. So a lot of engineering and design work, people that create your iPhones or your cars or the chairs you sit in are typically industrial designers in partnership with engineers. And so I started there, but the how that has segued into a career in digital product development was my love of applying human-centered design methodology to figuring out what problem are we solving for a person with this object, with this digital interface, with this service design and its environment.

And then I guess when the B2C app store hit the market with Apple, you started seeing these really well designed apps that were succeeding more than other apps, which didn't have as much thought and care about the user behind them. And everybody started going, "Oh wow. Digital design, easier to use things actually do better." You know, like surprising. And so I kind of... My career segued at that point into digital product development. 

 

Jeremy

So after talking with you at Pluralsight LIVE, I started getting interested in human-centered design and kind of researching it, and I realized that this is a pretty big movement. What do you think the driver is behind that? 

 

Mariah

I think the driver is that when you put the customer at the center of what you're creating and you really understand what it's like to walk in their shoes, you can create product that is more useful, more usable and more delightful to use. And when you create products like that, especially in the noisy space of applications today, those are the ones that win. So it's better for companies. It's better for the people that use them. And it's actually a lot more satisfying for the teams that are developing those, including the engineers because they get to see the things that they build, flourish and succeed. And that drives even greater motivation to continue to create a lot of career satisfaction.

 

Jeremy

Let's say you're designing an interface, for example, for users of an application. How do you get that feedback to know what's working and what isn't?

 

Mariah

Getting user feedback or soliciting user feedback is really important at lots of different levels of product development. For example, you might start with going and understanding what users are facing in solving a problem. You might then go and solve that problem in a low fidelity prototype. We call it a stimulus that we can put in front of a user. Now stimulus, depending on what you're solving could be multiple things. It could be a clickable mock-up that is really easy to create in a software like Envision. It could be printed papers that you're putting in front of people to solicit feedback. It could be testing a new algorithm on a small group of users in a live product and experiment. It could be any number of those things, but all of those are helping kind of vet that you're solving the right problem in the right way very early before you send something to market at scale.

Then you also have the flip side where you've already got a product at scale and market, but you're making upgrades or changes to it. You might want to test it by releasing in CodeLive, a beta version or even users might not realize that they're in a new version to a small subsegment of people just to see how they're reacting to it. And then measure those results to see if that behavior is what you were trying to achieve as the cross functional product team.

 

Jeremy

Well, a lot of this sounds familiar to me, coming from a DevOps background. One of the things that we tried to do was build a feedback loop with smaller changes and smaller units of work. Do you follow that same pattern and if so, does that make it easier?

 

Mariah

Absolutely. That is exactly the practice that we follow today. It is quicker. It's more iterative. You're getting feedback faster. You're not investing just a boatload of time in something before you release it. And that feedback loop really helps dictate how you go down the path of solving the problem for the user.

It also helps teams be flow efficient and focus on one thing and releasing it to a customer. Our philosophy is to... You could spend six months developing a really big thing and finally release it to the customer at the end of six months. But the reality is the customer has had that problem the entire six months, and you haven't given them anything. Or you could take that big thing and break it into smaller pieces. And then every week or two you could be releasing a small thing that brings value to the customer. And then by the end of the six months, you have the same result as to the overall thing they're getting. But during that six month period, they've also been getting value. So that's another upside of why we kind of use a flow efficient practice of releasing smaller things.

 

Jeremy

So that kind of ties into the empathy for the user.

 

Mariah

Yeah, you can see how it's working for them or not. And that's the danger with waiting the full six months and releasing the big thing. Now I know that's not possible in every industry. Sometimes there is change management and there are heavily regulated industries and finance or medical that that's not possible. But I would say for the majority of folks that create software, you don't really have those constraints.

 

Jeremy

Some of the people I've been talking with recently are thinking more about ethical design. For instance, when I talked with Scott Allen, he's been a developer for around 25 plus years, and I asked him what are some of the things that he knows now that he wished he knew then when he started out. And the first thing he mentioned was empathy for the user and building more ethical designs.

 

Mariah

I think that that's probably something a lot of folks feel that have been in the industry for a long time. But it gives me a lot of hope that that has been echoed, and I hear people like Scott saying that.

 

Jeremy

I've also noticed there's been an accessibility movement lately, more of a focus on making websites and applications more accessible. Is that something that you're seeing as well?

 

Mariah

Yeah. I personally am not an expert in accessibility, but it is something that we do look at on the teams. And we have a really great consultant that works with us who is a blind developer who goes through and does very thorough evaluations on accessibility. And we use that internally to help solve a lot of the problems that we might inadvertently create as well as learning what to avoid in the future. And we're actively looking to hire somebody to bring additional domain knowledge just because it's really so important. Our whole mission is to democratize technology skills, and we will have failed for an entire population of people if we don't also focus on accessibility as part of what we're creating.

 

Jeremy

What does bad design mean to you?

 

Mariah

I would suppose with bad design is design that frustrates users. We've all had these experiences. It could be a service design that is a dark pattern like a cable company that makes it really difficult to cancel your contract with them. It could be a chair that causes you back pain. But you still have to use the cable company, you have to use the chair. And it can get even worse within digital products. I think that as an industry we're moving more towards better design, but if you think about all of the software that was used in internal to business positions for a long time, the person that was actually doing the data entry or using the software was often not considered. And so it actually slowed that person down on their job and made their job harder, because they were having to use that software. And in my head, that's the epitome of bad design.

If you want to take it a step further, you can even think, "Well, what's unethical design?" Because that's been a big topic lately, which is also in a bad design category. But it's design that the pitfalls are so bad that it blocks humans from opportunities. For example, it could be a software that judges educators on the wrong metrics. And so you start to have teachers that are fired or attrition based on things that have nothing to do with their performance, which you know is bad for them, bad for their students. Or you even look at kind of weaponizing of people's information. I know there's been a lot of talk lately about Facebook and about data gathering and what is done with our personal data. I would say that that is a bad design as well. But again, more farther reaching social impacts that can be quite negative for the people that are using a software, and they don't know that that's happening in the background.

 

Jeremy

Absolutely. In the last couple of years it's really come up a lot with the rise in AI and machine learning and how we're using it. It was something that we really didn't have to look at as closely before, because the technology hadn't matured and we're just in the beginning stages of tackling this issue now.

 

Mariah

Absolutely.

 

Jeremy

So what are some of your favorite projects that you've led or participated in?

 

Mariah

That's an interesting question, because a lot of the stuff that I've been working on for the past couple of years is actually how to design the organizational design and the roles and experience orgs to enable individual contributing teams to do their best work. That has been intensely exciting for me. And I've been able to take the design skills that I used to use creating products for users and actually use them to empower organizations that I lead. So incredibly satisfying there.

I've also worked on some really cool projects. Back when I was a leader of smaller teams and an individual contributor, there was one company called AMC Health that I worked for, which was telemedicine and telemonitoring. And that was a pretty interesting project, because you had a company whose whole goal was to extend the reach of care outside of the hospital. So say you have a total knee replacement or because you got in an accident, after you leave the hospital the doctors probably want to try to track some stuff around your health. And so they could send you home with a WiFi-enabled scale or a blood pressure cuff or even wound care management software on your phone, so you could take pictures of whatever wounds they're seeing is healing.

The company that I worked for and the product I worked on was helping gather that data and then present it to the clinical care team, usually nurses, registered nurses, who would make sure that you didn't need to come back into the hospital. Because typically when people are released from the hospital, they have to get pretty sick before they come back into the hospital. And if we can catch that and help mitigate a return trip to the ER, then that's really good for the patient. And it's also really good for the healthcare system as well as far as providing a high quality of care. And so really getting in there and understanding that patients in our worlds and the nurses and how they manage all of our cases and then looking at how we bring that technology together, combining wireless devices with an app on a phone, with a dashboard that shows up in a clinical care setting, was just a really fascinating thing to work on.

 

Jeremy

What can you tell us about the discovery phase of a design process?

 

Mariah

Yeah, discovery phase is a really interesting one. I think it's the one that has probably been the most neglected in the context of companies, because it's the phase where you go, "Huh, I think there's this area that we need to put a team on and have them do discovery around and see if there's something here for our company." The reason why I don't think that happens a lot is in a lot of companies, leaders have an idea and that's the idea that wins and they put a team on. But this actually means that a leader is empowering a team to really investigate an area instead of placing a bet on what they personally believe. And it's been shown time and time again that it's really powerful to do it that way, because you do a lot of due diligence.

In fact, a couple of years ago I had the opportunity to do that here at Pluralsight. We had seen a lot of talk in the market around a user-generated content. And we thought, "Hmm, I wonder if our users are generating content," and if maybe there's a play for us in that since we're a content, partially a content company. And I hired a team and they did a bunch of discovery, and it turns out that it wasn't really a play for us. But they did discover that our users needed something called performance support, which our platform wasn't really giving them, which means you have a moment of you're doing your job. You're an engineer. You get stuck on something. What do you do? You go Google it, because you're trying to figure out what is the solution to this? And we didn't have a great response for that on our platform.

And what that led to was a new content type called a guide, which really looked at, "Well, what is an engineer looking for in their moment of need?" How do they trust the information? How do they know that it's relevant? How did they quickly consume it and move on. And what can we provide to be able to help them accomplish their goals. And so that was a really neat kind of area of discovery. That is a perfect example of an early discovery phase.

 

Jeremy

So if you're breaking things down in the idea process and taking ideas in from anybody, is there a certain amount of trust that's required there? Like if somebody has a hunch about something and the rest of the team says, "Oh, that's crazy," but you move forward on it anyway.

 

Mariah

It does require trust. I think usually the inception of putting people going into doing discovery around a concept, it usually is less like, "I had this idea in the shower," and more like, "Hey, we're seeing a pattern in their market around this thing. Maybe we should go investigate it." And we've got a really great product marketing management team. Our product marketing management team does a ton of market research, and that really shows a lot of patterns that creates a lot of signals for us. And it's from research like that that we might go and place some folks around an effort so we can go chase down if that's something that would make sense to our company and our customer base. And you do have to trust them.

But there is a certain set of rigorous skills that somebody needs to have in order to execute on that. And it's some really great qualitative and quantitative research skills and synthesis skills. And so you hire specifically for roles like that. There are discovery efforts that happen on a much smaller scale. For example, we have a content type on our platform called an interactive course. And the interactive course team might have been seeing something in their data around how people are interacting with interactive courses and might go, "Huh, we think we need to go spend a little more investigatory time on why that behavior is happening." And that's also an early, a different example of how discovery is applied early, because it's less somebody having an idea to go after and more somebody seeing a signal on a product and going in and investigating it. So those are two kind of very different use cases, but very common ones.

 

Jeremy

As we're moving along, say using AI and other big data type inputs, do you think there's a point where it might become data-driven design as opposed to human or needs driven?

 

Mariah

So it's funny, I hear people use the term data-driven design. In my mind there's two types of data that have to handshake with any kind of product development, qualitative data and quantitative data. And usually when people are saying data-driven design, they're referring to the quantitative data. But the quantitative data is very important, but it only will tell you what is happening. It won't tell you why it's happening. So if you can partner your quantitative data and look for patterns around what is happening, then you can go do qualitative research to dig into why is that thing happening? Because if you know why something is happening, you can decide, "Oh, that is something that we could do better for our users," or "It's something we have no business working in." But that's a very difficult call to make without the combination of those two.

So I would love for our audience and everybody out there to really start thinking about data-driven design as the handshake between those two. And that being said, you've got these products that are pulling in a lot more data than they used to. You think about AI where the AI algorithm you're training it to actually go learn something. I'd say that's the next generation of the handshake between those two things. You still would have to make a bet on, "Okay, we're going to train it and try this experiment and then we're going to go talk to people and understand why they're doing those things." If that's not apparent, which it's usually not. So again, I don't think you ever get away from that handshake between qualitative and quantitative. But if you are doing that data-driven design, I would say that you are maximizing human-centered design tools in order to create great experiences for people.

 

Jeremy

Do you see that as being a possible trend in the future with other companies that more of them will move in that direction?

 

Mariah

I sure hope so, because we are as an industry walking quickly towards more and more data capabilities than we've ever had before. And I want people to take advantage of those technologies and play with them and see what we can turn them into to create really amazing product services and experiences for people.

 

Jeremy

If someone is aspiring to get into human-centered design, what would be a good first step for them?

 

Mariah

Yeah, I guess it depends on where they're coming from. If they're somebody in high school and they're like, "Hey, I want to go develop software," learning about human-centered design will probably be part of either a self-taught curriculum or a bootcamp or a college, whatever path they take or even could be learning on the job. But if you're a professional and you're already out in the world and you're trying to learn about human-centered design, I think there's just so many resources out there online that even Googling it five years ago, you wouldn't have come up with much, but now you just see a ton. There's a ton of thought leadership blogs, books, videos, podcasts around that stuff. And so I think it's pretty easy to start to get up to speed and see the different angles of it.

And you have a general philosophy of kind of the process through it and how you learn from people, which is important. But then you have to go deep in the area that you're applying it and find out what tools work the best there. And it's that kind of breadth and depth that really makes somebody effective and applying it situationally as a skill.

 

Jeremy

Do you have any books or podcasts or anything that you'd recommend for learning about human-centered design?

 

Mariah

It's hard without a starting point to point somebody in a direction other than Google, Googling it, because that's the most up-to-date stuff. I will say that most commonly people ask me, "How do I start to deepen my skillset around the qualitative and quantitative research aspects of human-centered design?" Because they kind of get the process. They get the like, "Hey you got to go do discovery and then you synthesize that, and then you turn it into something and then you release it and then you watch it." They get that process, but the how behind that is the tricky part.

There are two books, which I believe will be excellent books for many, many years to come that help with qualitative and quantitative. In fact, they are kind of like my Bibles of both of those. One is called Observing the User Experience. It's in its second edition, and it's an excellent reference book. And it teaches you everything from unbiased interviewing techniques to contextual research and contextual inquiry. It's really fantastic reference. It's actually a book. It was in its first edition when I was in grad school 20 years ago, so it's still incredibly relevant.

And then the second book is The Qualitative Companion, which is written by a different author, but it's also equally amazing textbook of how to do different qualitative research techniques, particularly within digital development and software called Measuring the User Experience. And you can search each of those on Amazon and they will both pop up. I would say that those research skills are just incredibly invaluable when it comes to doing any kind of human-centered design.

 

Jeremy

Thank you for those recommendations. Is there any danger in human-centered design? Like any way it could steer you wrong?

 

Mariah

I have never had human-centered design as a process steer me wrong. I very much trust the process. But the human-centered design is only as good as the practitioner behind it and their knowledge. Just like could a car steel you wrong? Well, it depends on whether it's a 16-year-old driver or a 60-year-old driver. 60-year-old driver probably is going to do a better job driving the car than the 16-year-old driver. And it's not the car itself, it's the person that's wielding it.

So one thing that I always encourage practitioners to do is to check their blind spots, because if you have... Everybody has blind spots. If you've done less human-centered design, you have more blind spots. And there's an amazing community of human-centered design, usability design, UX, products that is out there online ready to be connected with probably at local meetups in person if you wanted to as well. And I always loved to talk shop. And so if you're working through a project and you don't have a lot of people around you with a ton of experience and you're trying to try to do something, A, please try and do it. The only way we get better at this stuff is to go do it.

And I would say even doing it orally is better than just making it up, because, at least, you're getting some input, but check your blind spots and go talk to other practitioners in your area. People online, folks you admire. I know that I volunteer my time when people reach out to me to try to help push them in the right direction. I'm very engaged and involved with our local community here. And if not me, I can point you in the direction of the right person to talk to. So that's my recommendation for humans that are doing human-centered design for the first time or early in their early stages.

 

Jeremy

So any cool projects you're working on right now?

 

Mariah

We are continuing to evolve our organizational design. I think I mentioned a little earlier that what I'm working on is trying to make sure that all of the roles that support our individual teams are really effective in providing that support and we're not missing anything. Part of that is really understanding two areas of our organization that cross cut business units and projects and teams. One is how teams think about flow efficiency in regards to their end-to-end process of delivering product and seeing might there be an opportunity for us to present them data about the way they work. Just so that they have it when they do their retros and they can look for patterns in their own behavior as a team. Would that be useful?

And then the second thing we're really examining is how people think about their technical systems. The ones that they own because we're a polyglot organization, and all of our 50 plus teams own their own code bases within their own down to context. What data do they need that they don't easily have access today to understand the impact on the greater system or they're almost someone they make choices, particularly ones that are localized choices or optimization versus global optimization choices. And so between the handshake of full efficiency and systems, I'd say that those are the things that we're trying to chase down right now, which are exciting.

 

Jeremy

I just started reading a book called Team Typologies, and the premise of the book so far is to understand organizational architecture and how to form teams that could be arranged differently from your org chart. And the goal seems to be optimizing, taking different skills from different team members and optimizing flow. It's been really interesting so far.

 

Mariah

I'm going to have to read that one. Thanks for that recommendation.

 

Jeremy

Yeah, no problem. Thank you for speaking with me today, Mariah.

 

Mariah

The pleasure's all mine. Thanks so much for inviting me.

 

Jeremy

Thank you for listening to All Hands on Tech. If you like it, please rate us. You can see episode transcripts and more info at pluralsight.com/podcast.