066 – How Alison Magyari Used Design Thinking to Transform Eaton’s Business Analytics Approach to Creating Data Products

Experiencing Data with Brian O'Neill (Designing for Analytics)
Experiencing Data with Brian T. O'Neill
066 - How Alison Magyari Used Design Thinking to Transform Eaton’s Business Analytics Approach to Creating Data Products

Episode Description

Earlier this year, the always informative Women in Analytics Conference took place online. I didn’t go — but a blog post about one of the conference’s presentations on the International Institute of Analytics’ website caught my attention.

The post highlighted key points from a talk called Design Thinking in Analytics that was given at the conference by Alison Magyari, an IT Manager at Eaton. In her presentation, Alison explains the four design steps she utilizes when starting a new project — as well as what “design thinking” means to her.
Human-centered design is one of the main themes of Experiencing Data, so given Alison’s talk about tapping into the emotional state of customers to create better designed data products, I knew she would be a great guest. In this episode, Alison and I have a great discussion about building a “design thinking mindset” — as well as the importance of keeping the design process flexible.

In our chat, we covered:

  • How Alison employs design thinking in her role at Eaton to better understand the 'voice of the customer.' (0:28)
  • Same frustrations, no excitement, little use: The factors that led to Alison's pursuit of a design thinking mindset when building data products at Eaton. (3:35)
  • Alleviating the 'pain points' with design thinking: The importance of understanding how a data tool makes users feel. (10:24)
  • How Eaton's business analysts (and end users) take ownership of the design process — and the challenges Alison faced in building a team of business analysts committed to design thinking. (15:51)
  • 'It's not one size fits all': The benefits of keeping the design process flexible — and why curiosity and empathy are traits of successful designers. (21:06)
  • 'Pay me now or pay me later': How Alison dealt with pushback to spending more time and resources on design — and how she dealt with skepticism from business users. (24:09)

Resources and Links:

Quotes from Today’s Episode

“In IT, it’s really interesting how sometimes we get caught up in just looking at the technology for what it is, and we forget that the technology is there to serve our business partners.” - Alison (2:00)

“You can give people exactly what they asked for, but if you’re designing solutions and data-driven products with someone, and if they’re really for somebody else, you actually have to dig in to figure out the unarticulated needs. They may not know how to invite you in to do that. They may not even know how they’re going to make a decision with data about something.  you can fail if you just give people what they asked for, so it’s best to be part of the problem finding not just solving.” - Brian (8:42)

“During our design process, we noted down what the sentiment of our users was while they were using our data product. …  Our users so appreciated when we would mirror back to them our observations about what they were feeling, and we were right about it. they were much more open to talking to us.” - Alison (12:51)

“In our case, we did have the business analyst team really own the design process. Towards the end, we were the champions for it, but then our business users really took ownership, which I was proud of. They realized that if they didn’t embrace this, that they were going to have to deal with the same pain points for years to come. They didn’t want to deal with that, so they were really good partners in taking ownership at the end of the day.” - Alison (16:56)

“The way you learn how to do design is by doing it. …  the second thing is that you don’t have to do, “All of it,” to get some value out of it. You could just do prototyping, you could do usability evaluation, you could do ‘what if’ analyses. You can do a little of one thing and probably get some value out of that fairly early, and it’s fairly safe. And then over time, you can learn other techniques. Eventually, you will have a library of techniques that you can apply. It’s a mindset, it’s really about changing the mind. It’s heads not hands, as I sometimes say: It’s not really about hands. It’s about how we think and approach problem-solving.” - Brian (20:16)
“I think everybody can do design, but I think the ones that have been incredibly successful at it have a natural curiosity. They don’t just stop with the first answer that they get. They want to know, “If I were doing this job, would I be satisfied with compiling a 50 column spreadsheet every single day in my life? Probably not. Its curiosity and empathy — if you have those traits, naturally, then design is just kind of a better fit.” - Alison (23:15)


Brian: Welcome back, everyone. This is Brian T. O’Neill. You’re listening to Experiencing Data. Today I have someone who recently popped up in my radar from the Women in Analytics Conference, which I didn’t go to.

But I saw, I think it was an International Institute for Analytics had a great blog post, and Alison Magyari—my guest today—she was cited in this as giving a really interesting talk that had to do with how human-centered design or design thinking had been applied to her BI and analytics team. And since we had our first call, you’ve actually moved on into a new role over there, but some of these principles are actually going to be dragged over to that new department if I understood. So, I thought this would be really interesting because that team apparently wanted some of these skills.

So, first of all, welcome to the show. Thank you for coming on here. Why does someone who’s working in dedicated application platforms, why does the leadership there care about design?

Alison: Hi, Brian.

Brian: [laugh].

Alison: Well, thanks for having me.

Brian: Yeah.

Alison: Yeah. So, the new role that I’m in, manager of dedicated application platforms, is really on the more technical side of the house. So, it’s looking at how do we actually set up the infrastructure for some of our major platforms such as Oracle, SAP, Exadata, Cloudera, and some of our legacy systems, too, like the mainframe Superdomes, AS/400s. So, it’s really looking at our infrastructure from a different angle. And why design thinking was intriguing for this role was just to get more of voice of the customer.

I think in IT, it’s really interesting how sometimes we get caught up in just looking at the technology for what it is, and we forget that the technology is there to serve our business partners. So, part of this role will really be working with our business users: how are they working on some of our major platforms? What is their experience when they have to do things daily in Oracle or SAP? Was the performance going well? Are they noticing lags when we’re doing things such as patching? That’s really the voice of the customer is what we’re hoping to gain in this new role.

Brian: Got it. Got it. And can you tell people what Eaton is? I forgot to mention your organization’s name is E-A-T-O-N. What is Eaton, and what does it have to do with electricity?

Alison: Eaton is Cleveland’s largest corporation. So, we’re just over $21 billion in sales. And we really have two pieces; so we have an industrial side of the house, and within industrial, we have vehicle, we just have sold off our hydraulics group, and then aerospace. And so we make a lot of components that go into things like airplanes, vehicle motors, so basically just keeping a lot of the manufacturing pieces working. And then on the other side of the house, our electrical side, we do everything from stadium lighting, to hospital generators, to LED lighting.

So, it’s a really robust business and that’s growing quite a bit, as well. So, two big sides to it. It’s a really interesting product line because our products are basically in everything, but you would never know because they’re kind of small components in literally millions of overall products.

Brian: Right, right. So, tell our listeners a little bit about the talk that you gave at that Women in Analytics Conference.

Alison: Yeah, so I was really excited. That was my first time being a part of the Women in Analytics Conference. But really what I talked about there was all-around design thinking. So, this concept of how do we really create a mindset, when we are doing requirements gathering—this was specific to analytics—of getting people’s sentiment of, one, when they’re using data, how they’re making decisions, how they’re doing their job, and how are they feeling while they’re doing it. And that’s really different, I think, than a lot of things in IT. Again, where we [crosstalk 00:04:13]—

Brian: You used the feeling word. [laugh].

Alison: Yeah.

Brian: Ew. [laugh].

Alison: I know.

Brian: With analytics. Ahh. [laugh].

Alison: I know.

Brian: I can hear listeners cringing right now.

Alison: I was met with some resistance on that, for sure. [laugh]. I guess how I got into that, too, was, just like you said, as kind of the oddball in the group. So, I’d been managing the business analyst teams. We had a pretty large group of analysts and our entire team, so solution designers, architects, business analysts, project managers, we all took a test called Insights—it’s kind of like a personality type test—and we had 52 people in our department at the time, and 51 out of the 52 of us, led with blue energy, which basically meant that you want the details in a meeting upfront; you want to lead with data, you want to know all the facts and figures as a way to kick off a meeting.

I being the only one—so I was the one out of the 52—that led with yellow energy, which was really, “I want to get to know you first. I want to talk about your weekend. I want to see how you’re feeling in your day for a couple minutes, kind of get comfortable, and then we can get down to business.” [laugh]. So, it was a lot of me Googling why I had been successful in my role when I was so vastly different from the other 51 members on my team.

Brian: Yeah, yeah. Can you talk a little bit about—like, first of all, this design thinking process, maybe you can tell us a little bit how it works? But before you do that, I’m curious, was there an old way of doing it, and then there was this other way with design? And where did that come from? People don’t just drop out of the sky and just decide, “Oh, I’m going to do it this other way now.” What happened?

Alison: Yeah. Well, it’s kind of interesting was—so when I first became a business analyst at Eaton, when we had kicked off any analytics project, basically, it was me meeting with—as the business analyst—meeting with one of our business users, and a lot of times that business user wasn’t going to even be an end-user to our analytics, but I was basically meeting with them and just asking them, “What do you want us to build for you from an analytics perspective?” [laugh]. And nine out of ten times, it was some crazy spreadsheet request. So, usually a spreadsheet with 100 columns on it because they were so afraid this was their only time that they were ever going to interface with IT, they didn’t want to leave anything out.

So, it was like, basically, a data dump. “Give me a data dump from the ERP, and then I’ll go in and pick and choose which fields I want to put together to create my report.” And so we started doing that on a number of projects, and was really defeating because it took a lot of time, obviously, to pull that data out of an ERP and put it into a data warehouse, that took so much time to validate 100 columns of data, and then by the time we got to go-live, we noticed that our adoption rates after go-live, were, like, 10% of what we had expected. We were just noticing it was just data dump after data dump, and our users weren’t happy, [laugh] that they hadn’t changed how they felt about their job in any way. So, it was really a lot of work and not good return on that work. That really led me to think there’s got to be a better and a different way to handle this.

Brian: Right, right. And the measurement of that satisfaction. Was that just, like, crickets? We never heard from them again? Or was that like, they weren’t really happy with it? Or how did you know that it wasn’t working? What was the signal?

Alison: Kind of a mix. So, at time of go-live—we’d always have our final conference room pilot, where the users would test everything, and then it would go live the following Monday, for example. And we’d go to those meetings, and there was—like you said—just complete silence on the call. There was no excitement, there was no—you know, we were trying to kind of rah, rah, rah cheerlead our way to the end, and nobody was happy about it or excited about it. And then we saw, too, after six months after go-live, the usage statistics on it were minimal.

When we talked to the users, they expressed a lot of the same frustrations that they have with an old toolset because they were following the exact same process. They were getting that 100 column spreadsheet and having to do all these things manually. So, there was just a lot of frustration, I would say, on their part. And they didn’t see the value at all that IT brought or that the analytics team really brought to them. We were just replicating a major pain point that they’d had for the last 20 years, but in a nicer tool, basically.

Brian: Just to reiterate this for listeners, you can give people exactly what they asked for, but if you’re really designing solutions and data-driven products with someone, if they’re really for somebody else, we actually have to dig in and you have to figure out the unarticulated needs. And they may not know how to ask for that. And they may not know how they’re going to make a decision about something. And you can say, “Well, you’re not prepared to talk to us yet.” Or you can be part of helping them decide, how will you make a decision with this information?

Let us be part of that problem-finding exercise with you, not just the solution part. Because you can fail if you just give people what they asked for. [laugh]. Right? So, how did you guys do that? How did you make the change? Or what happened such that you’re like, “There’s got to be a better way?” Or, can you tell me what your experience was?

Alison: Yeah. So, it’s a kind of a combination of, I think, our leadership really understood that they did not see the excitement either. They realized how expensive our projects were, how long they had taken, and the morale of our team was going down. So, at that point, I think they were open to, potentially, a new way of doing things. And it was kind of that married with the Insights profile where I was the only yellow one.

So, I had done a lot of research at that point on design thinking, a lot popped up as a result of empathy. So, between those two things, I kind of got leadership’s attention, and I said, “Let’s just try it on one project. And if it fails, if people make fun of us for talking about feelings in IT, we can go back to the old way of doing things.” But I think it was worth at least a pilot. And so at that point, I think both sides—the business users and IT—were really open to—it can’t hurt; it can’t get worse, I guess, [laugh] than what it already is, so let’s try a new way of doing things.

Brian: Can you give listeners—make this concrete? Like, give a specific example of—because it’s not like, go in and we just talk about feelings all day. This is like—I could tell some listeners’, probably, skin is crawling with the idea of this. How are you using that to your advantage as a provider of an analytics solution? What are the questions you ask? And can you give an example of how that had a practical application?

Alison: Absolutely. So, the four pillars, I would say, of design thinking, or the process that we followed, were, ‘what is?’ ‘what if?’ ‘what works?’ And then ‘what wows?’

So, we started with the ‘what is,’ which is basically taking a really good inventory of current state. So, it used to be in analytics projects, we would document how the business users were getting data, how they were using it, but it was very basic. We’d put it into a Visio diagram and kind of call it a day, step-by-step. Where, with design thinking, you do that same step, but you also add in sentiment along the way. So, between your first step and your second step—so maybe you’re pulling from three different systems and putting everything into Excel—we also noted down what was the sentiment of the users while they were doing that?

So, a lot of times, they did say, “Oh, my gosh. It’s so frustrating. It takes so long. I am so scared when I’m doing this, that I’m going to miss one column of data, and then everything’s going to be wrong, and I’m going to report data wrong to the organization.” So, we kind of just noted down, in terms of feelings.

We didn’t ask them directly, “What are we feeling?” [laugh]. We kind of just noted down just things that they either told us in terms of their worry points, or just how it caused stress or frustration, and then we also as much as we could, we spent time with the users and really watched them. So, if we saw they got tense, or if they were gritting their teeth while they were telling us this, or they were putting their hands on their head, we really just kind of noted, what was our feeling of how they felt about that process. So, a little more indirect, I would say, [laugh] as a way—

Brian: And do you—as part of this process, do you talk to the customers about addressing that? Hey, we noticed you seem really concerned about data-entry problems on this screen,” or whatever. Do you talk about that? Or did you just build—did you just correct for that in the solution phase, not necessarily directly addressing it? How much was the user involved with these observations that you made about them?

Alison: At first, to be honest with you, we didn’t really include them very much. We kind of just noted it down and kind of took what we were noticing. But after a couple of projects of doing that, we thought it would be beneficial just to confirm our understanding—for one thing—of, we’re not misreading them, we’re not misrepresenting them in any way. What was interesting, though, is that our users so appreciated when we would mirror back to them what they were feeling, and we were right about it. I mean, they were much more open to talking to us.

Then they were much more open and sharing exactly what they were feeling [laugh]. So, it did, kind of, open them up even more, that we understood and that we did want to truly help them to make it better. And we could alleviate pain points; that’s what we were there to do in IT.

Brian: Mm-hm. Was there a particular project you did this on where you saw a big win? Or maybe a group you had kind of done it the old way, and you flip the script and you tried this approach and you had a different outcome? Something that you could share with us?

Alison: Yeah, so one of our key stakeholders is the finance team. So, it was a mix of accounts payable, accounts receivable, project accounting, general ledger reporting. So, it’s kind of the full gamut of the finance reporting. And when we first started working with them, we did not follow a design thinking approach. And they were probably the biggest offender of “Give me every single possible column.”

Brian: Right. [laugh].

Alison: They were doing a lot of manual work. So, that was one of our first customers that we did use design thinking. And they were the ones that really embraced it the most, too. I was a little skeptical because as you know, finance is typically just about the numbers, not really a touchy-feely [laugh] kind of group. So, I was a little bit nervous to see how they would react to trying this different approach and trying something new, but they were incredibly open to it.

They embraced it. They were our biggest champions, too, after the project and getting other stakeholders, like our supply chain group, for example, to give it a try when we were met with resistance from them, too. So, they became, really, our advocates for this approach moving forward in our business, as well.

Brian: Did you actually kind of go to them and say, “Hey, we’re having this friction with the supply chain group? Could you talk to them?” Or tell me about those dynamics?

Alison: Yeah. So, we basically just created kind of a roadshow, I would say, of what was successful on some of these big initiatives. Because the finance project, for example, it was a complete year key transformation project. So, they were taking two instances of Oracle, marrying it into one instance. It had thousands of users around the globe [laugh] that were using it, so they were really, I guess, acutely aware of how important it was to get the solution right the first time. So, when we saw that it was a win for them, we kind of recruited them, asked them to give a testimonial, and just really help us explain to other users why this was practical and usable.

Brian: I get asked this sometimes when I’m giving my seminar and training, and it’s, “Well, Brian, whose job is this to do this stuff?” And my typical answer is, “It’s everyone’s job. Design is a team sport.” Now, in practice, should someone own it or whatever, the role isn’t so important; I do think it’s probably important to have someone that’s championing this if it’s a new thing. Can you talk to me about whose job is it on the data team, on the data science, or the analytics team? Who owns that? Is that even the right question?

Alison: That is a good question. And I, too, think it is more of a team sport. At Eaton, we tend to have our business analyst team really take ownership of that. And that was after just kind of figuring out the different roles and who had the most direct experience with the customers. And so we looked at more of our technical resources, too, and they play a great role behind the scenes, but our business analysts are kind of on the front end, day-in, day-out, building those relationships with our business users, really trying to understand what they need versus what they’re asking for.

So yes, in our case, we did have the business analyst team really own that process. But we were more—I’d say towards the end, we were the champions for it, but then our business users really took ownership, which I was proud of. And they realize that if they didn’t embrace this, that they were going to have to deal with the same pain points for years to come. And they didn’t want to deal with that either, so they were really good partners in taking ownership at the end of the day, too.

Brian: Is this something you train them on? Or how did you even get these analysts to be, A) willing to do this, and, B) learning how to do it? I find there can be resistant people; the analytical mind tends to want to understand how it’s all going to work before they try anything; it’s about getting it right and not wrong. It’s very black and white, and design is a very gray space. So, can you tell me about how did they learn how to do it? And how did you get them to step into that role?

Alison: Agreed. So, there was a lot of resistance, I will admit, when I first brought this idea up, just because it is so vastly different than the way that we were doing things and did have kind of a friendlier feel. Because in one phase, we create little, even, drawings or, kind of, caricatures, kind of cartoons that represent how our users our feeling so that we can see from the ‘what is’ to ‘what if,’ if we change something, how that caricature would, kind of, grow and change. So, I think some people looked at it at first as being kind of childish, or maybe a little goofy, or not professional, maybe, in some ways, but really the proof was—so we did go through some training. So, as the manager of the team at that time, I can read a lot of books at that time, I had watched a ton of YouTube videos, and then I had actually tried it on the finance project and gotten success.

So, after I had gotten my first big win, then I took the training back to our business analyst team, where it was kind of a mix of articles—there was some articles, some more formal training, but then it was really, kind of, showing them, “When we don’t follow this approach, what were our results in finance?” And they were all very aware of that. And then, “When we did follow it, why did we see a usage increase really spike?” And that got their attention when there was some data to back up that this might be a viable solution or a way to do it. So, we really took it in small chunks.

So, when we first rolled out this process, we didn’t go through the entire design thinking process at first; we just got really good at first, that current state—so the ‘what is’ analysis—and adding the sentiment in. And once the analysts got good at that, then we moved on to ‘what if?’ And what if we could get rid of each of those pain points, and suggest different ways of, maybe, creating visualizations so that our users would feel more comfortable using them? Or what if we did things in a completely different way and maybe you only needed one performance tile with one metric rather than a 50 column spreadsheet, so that our executive team could see it? So, we kind of started piece-by-piece and just building.

Every time they got a little bit more confidence, every time they got a compliment on their approach, then it was kind of a wormhole in [laugh] to sinking in the next part of the process.

Brian: Yeah. You validated a few things that I tried to hammer home, too, which is the most important thing is to get started and try doing it. And I love that you went from take some articles and step into it because the way you learn how to do design is by doing it. Whether you call it design thinking, it’s—to me, it’s just design; we can call it design thinking, too, but you really learn it by doing it. And so I applaud your efforts to learn it by practicing it.

And the other second thing is that you don’t have to do quote, “All of it,” to get some value out of it. You could just do prototyping, you could do usability evaluation, you could do ‘what if’ analysis. You can do a little of one thing and probably get some value out of that fairly early, and it’s fairly safe. And then over time, you can learn other techniques. And it’s really a library of techniques that you can apply, and it’s a mindset, it’s really about changing the mind—it’s heads not hands, as I sometimes say.

It’s not really about hands. It’s about how we think and approach the problem-solving. So, I really, I applaud—it sounds like you’ve had some great success with that. And to think about that, if you went somewhere else and you were going to do this, again with a team, any learnings that you might share with another leader? Like, “I wouldn’t do that again. I would do it this way.” Or, “I would skip this and try this.” Anything you would do differently, now, if you were going to bring this in?

Alison: Yeah, at first, I think I really wanted to follow the process to a tee. When I first read about it, I wanted to follow each step of it, and I wanted to have people really excited when we got to the ‘what wows’ phase, and give me every wishlist item you could ever have. And I felt a little disappointed when there was kind of like, eh, one or two responses, or people weren’t really, I think getting as excited about pieces of it as I was. But I think I would just recommend starting small, feeling out the business users, too, asking questions, and if they seem receptive, or if they kind of light up, to really pay attention to that and what made them light up, and then take advantage of that piece of it. And not worry about really following the entire end-to-end process upfront, I think was a huge learning.

And then definitely, it’s not one size fits all, either [laugh]. And you can get creative with it. So, we always say, we’re following Eaton design thinking because we’ve added kind of our own elements that we know work for our users that are kind of unique to our industry and to our business that probably wouldn’t make sense to anybody else. Just cultural things, too. So, I think that’s important, too, that you can make it your own, you have liberty to take out pieces that don’t serve you, to add in other chunks, maybe even organizational change management or other things that might help your organization.

So, it’s really flexible, where I think at first, I wanted to make it a little more rigid or a little bit more, follow the process: do step one, do step two, and that’s not necessarily the case or where you’re going to see the most bang for your buck, either.

Brian: Do you feel like anyone that you ever hired on a team could do this, or you found out that there’s a special personality type or some trait about someone that lends itself more to this?

Alison: I think everybody can do it, but I think the ones that have been incredibly successful at it have, for one, just a natural curiosity. They don’t just stop with the first answer that they get. They want to know—I think natural empathy, too—they kind of want to know, “If I were doing this job, would I be satisfied with compiling a 50 column spreadsheet every single day in my life? Probably not.” [laugh].

So, I think it’s, yeah, the curiosity and the empathy, where if you have those traits, naturally, then it’s just kind of a better fit. But even people on my team that did not come naturally to and they were more, I’d say, hardcore IT their whole career. And this was completely foreign to them, they did get very successful, especially I would say in that current state piece and identifying the sentiment. So, there were small wins along the way, even with people that it wasn’t kind of natural for, I would say.

Brian: Did you feel like you had to spend any, like, political capital? Because sometimes with design, I know the concern can be, “We don’t have time. It’s slowing us down.” Because the return comes on the other end. No, you’re going faster and better, is what you’re doing.

It just feels slower because the extra work is mostly upfront. It’s not the end. It’s not building it twice, and three times, and then no one uses it. But that’s a hard thing to swallow, sometimes. Did you have any of that kind of friction where it’s like, we need to slow down a little bit to speed up? [laugh].

Alison: Absolutely, yeah. Because Eaton is a very metrics-driven organization, and so we do charge our time by phase of the project, too. So, to your point, if we were averaging, maybe, let’s say 10 hours on average in the requirements section of a project before design thinking and then maybe 30 hours in the design phase and 10 hours of testing or something like that, and now it was like doubled upfront. Yes, I did get a lot of pushback on that at first. But again, I think when people saw the adoption rates were so bad. [laugh].

And our customer satisfaction scores were at an all-time low, and just kind of the principle of pay me now or pay me later. And give me a chance to show you that, if you pay me now, you’re going to get even better returns than if I paid you later, and we drug out these projects. Even from a morale standpoint, I think that it’s really defeating—at least it was for me as a business analyst—to, when you spent so much time on a project and then you got to the end, and nobody used it. It was like, I never wanted to be on a project again. So, I think even from just that kind of that psychological standpoint, how much better it felt when our users—or from our business analysts, saw that our users were getting excited about it, and actually did use it after just their attention rate on my team also improved because I think people felt more worthwhile and what they were doing was making a difference.

Brian: Yeah, and I think that’s a big—do you roll out of bed every day and dread going into work, or you’re like, “I actually understand the value I bring, now.” And I think that’s a strong—we don’t talk about that a lot. But it’s like, is it fun to make stuff that no one wants to use? This is going on. It’s, like, 30 years now, we’ve been talking about this.

The surveys on this, it’s just—there’s a tremendous amount of wasted time, talent, and technology, building stuff nobody wants to use. And it doesn’t have to be that way. And it’s more enjoyable. Everyone wins: customers win, the users win, you feel like you actually did something that mattered. And I think if that’s the only reason you decide to change how you make stuff is so that it’s better for you, it’s kind of in a way, okay, that’s a start, you know? [laugh]. But you will feel better. It does feel more rewarding when they’re like, “Yes, please. Can I have some more? When can we get the next one? When’s the next time you have availability? When can you help us with this other project?” [laugh].

Alison: And it is a tough sell. I mean, it really was. I did get a lot of resistance and skepticism, I guess, with the amount of hours that we were spending at the start of a project. So, yeah. But it worked out. [laugh].

Brian: Yeah. Well, no, that’s great. I’m curious if there were any learning moments that happened with your team when they were out, quote, “Doing this work,” and any moments that they had to get through or navigate tricky situations, resistance to—either from the customer side, your user, your sponsors, or them internally? Any moments that you can recall from that.

Alison: Yeah. No, I think a couple. So, one was, I think our business users at first, were a little skeptical of us looking over their shoulder to see how they were actually doing their job. I think a lot of our users were a little intimidated by that because they thought we were going to automate something, and that they would no longer have a job or something like that, which couldn’t be further from the truth. And then the other thing that we saw, too, was a lot of our business users, they have a really strong skill set in compiling data and bringing it together.

But their skills are not as strong and actually analyzing the data. So, the efficiencies that we could make by creating a dashboard where you could drill in from a summary level view down into the details. Where before, that may have taken them three weeks out of the month to do, [laugh] every single month, and we were able to automate that, I think there was a bit of intimidation to that they now didn’t have the correct skill set because now they’re actually going to have to make decisions off the data and to analyze the data rather than just wrangle and compile it. But that led us to rolling out additional curriculums and trainings and things to add more of that analyzing and making decisions off of data piece, too. But we did notice that upfront where, yeah, our users, I think, were nervous that we were trying to get them out of their jobs or something.

Brian: Yeah, I can understand. Especially if you’re—the word AI appears in your job title, now, it’s an understandable fear, I think. But onward and upward; I think there’s ways around that and I applaud you for the work that you’ve done here. So, where can our listeners follow you? Are you on LinkedIn? If they want to just kind of hear about how you’re applying this work in your new job?

Alison: Yeah, absolutely. I’d love to connect on LinkedIn. So, I am under alisonmagyari on LinkedIn, or feel free to email me directly to alisonmagyari@eaton—E-A-T-O-N—dot com, too. I love having these conversations, and I really like to see just the different ways people are applying design thinking to their work, too. I learn something new from everybody that comes in contact with me, as well. So, I think it’s really mutually beneficial, too.

Brian: Awesome. I will definitely link all that up for listeners. And thank you again for going on the show and talking about your experiences.

Alison: Yeah. Thanks for having me.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Subscribe for Podcast Updates

Join my DFA Insights mailing list to get weekly insights on creating human-centered data products, special offers on my training courses and seminars, and one-page briefs about each new episode of #ExperiencingData.