Currently a Sr. UX Designer in McAfee's Enterprise User Experience group, Laura has over 20 years of experience as a designer and user experience practitioner. Prior to joining McAfee in early 2016, Laura worked at Intel on wireless display technology.

She has worked in corporate in-house, consulting and agency environments, and considers herself incredibly lucky to have gotten her hands dirty all over the digital world. Her industry experience includes IT security, technology, retail, healthcare, consumer packaged goods, financial services, agriculture, hospitality, and government.

Her biggest strengths lie in creating simple and elegant solutions to thorny problems, and making sure her team is solving the right problem in the first place. When not designing, she can be found enjoying all the tastes, sights and sounds the Pacific northwest has to offer.

Follow Laura on Twitter

Episode Transcript    

J: Hey everyone, welcome back to Design Driven. I'm super excited today to talk to Laura Thelen. She is working at McAfee ... did I say it right?

Laura: Mac-Afee, actually.

J: McAfee, so we had that debate a little bit before we got on the show, so if you have the debate about whether it's Mac-Afee, or McAfee, now we know. Laura, welcome to the show. Tell everybody about what you're doing there, what you're excited about, and actually how you got there in the first place.

Laura: Sure. Hi. First of all, thanks for having me. I'm very excited to be here. I ended up joining McAfee as a senior UX designer about a year and a half ago. I had started out at Intel. Intel had acquired McAfee several years back, and then ended up deciding to un-acquire them so the spin-off happened about a year ago. McAfee is back to being its own independent company. I am part of a pretty decent sized UX team on the Enterprise side.

We have two different groups. We have the Enterprise side, and then we have the consumer side. On the enterprise side, what our focus is designing enterprise security products. By enterprise, I mean think Fortune 500 larger or smaller companies. Basically, any corporate entity who has anywhere from probably 10,000 to 50,000 end nodes that they support, so they're security team would be managing all of the security products for those laptops, desktops, or servers. Our UX group supports those types of companies.

J: Wow, that's a note of nodes to think about. What kind of things: use cases, or tasks, are people typically trying to accomplish? What's a typical use case for your product?

Laura: In a nutshell, the goal of all of our products is to help Security Administrators in a company keep their environment safe and secure, and basically up and running smoothly. We're also trying to give the ability to manage their environment and make any adjustments to policies or settings that affect their users. We want to make sure that our software is catching any sort of malware, or viruses before it gets into the environment, and alerting the Administrator when there is trends ... like if there is a big attack going on.

I'm sure you and your listeners are probably familiar with the "wanna cry" virus that was big in the news a few weeks back. The majority goal of our software is to detect and protect all of the end points in an environment. The work I ... sorry, go ahead.

J: I was just going to say that's kind of interesting because on one hand you've got Security Expert Administrators, who are in charge of all of these machines. They are certainly someone you are designing for, but then you also have the end user, who might not be that sophisticated and really understand the threat or the risks that they have by just doing simple things like checking their email. How do you balance the designing for those two really distinctly different groups?

Laura: That's a great question. The user that we're primarily designing for is the IT security person. It's generally not the end user who is using the laptop or the work station. Ideally, that person shouldn't have to interact with our software at all, so they can focus on doing their jobs. If they're having to interact with our software, or even their work performance is impacted by it, we've basically failed.

Security just isn't something that you typically would leave up to the end user. Our user is really the security professional.

J: That's an interesting point. It sounds like the goal is to make the software and the security piece of what you're doing transparent to the end user, and make it very powerful for the administrator.

Laura: Yeah, exactly. The big role of our software is to help the security professional manage the security software and settings in their environment so they can monitor what is going on, and adjust any settings or policy that may be necessary for particular needs in their environment, if they have different types of users. Really to just give them a big picture of what's going on in their environment so they can make sure that everything is running swimmingly.

J: That's super fascinating, because it's an ever-changing world so you've got to stay on top of not just all of the threats that are out there, but how do you communicate that in a way that is effective for those designers?

Laura: I think the challenge, too, with the Security Administrators that we design for is that they're all incredibly computer savvy. They are very sophisticated users, and a lot of them have been using legacy versions of our products for many years. They consider themselves almost experts in our products. Their expectations are really high, and they're very sophisticated computer users, so they have a really specific vocabulary they use, they don't tolerate when things don't work very well, they're very vocal about it, which has actually been really great for the UX team, is that we have a lot of very vocal, passionate, engaged customers who love to talk to us.

J: That's kind of a UX Designer's dream, right? To have users that actually volunteer feedback.

Laura: Yeah, we have quite an engaged group of customers that we talk to very regularly. I think the downside of that is that they're not necessarily representative of everyone of our entire customer base, but I think it's really helpful to talk with them and get their feedback, and then for them to see us actually integrating their feedback and their input into our products. It helps them feel like they're being listened to, and actually seeing our products evolve with their feedback I think is really great for both sides.

J: Absolutely. Can you shed some light on some of the process around how you gather that feedback? I would imagine it's somewhat structured, and how do you take somebody who maybe came from a design background into a highly technical discipline and help them develop empathy around who they're designing for?

Laura: That's been all about talking to our customers. Our group is about 15 of us total, and we've got right now, I think, four user researchers and the designers, we keep them very busy. We've got this dedicated research group that they have a lot of different methodologies they'll utilize, but they mostly do one on one interviews and feedback sessions. Anytime we're working on developing or redesigning a new area, we will engage our research team and they'll actually go out and get a group of probably eight or 10 ... is the number we typically try to talk to customers.

We start with some of the internal customers because we actually have a pretty big group at McAfee that some of our support folks who are willing to talk to us will do a pilot study with them. They actually talk to customers quite a bit, and we'll have a lot of insights into not only the problem we're trying to figure out by using research, but they'll help us structure the study into a way that we're asking questions that make sense to the customer.

They kind of help us with their expertise. When we do these one on one research sessions, we'll show them maybe a concept that we're working on and we'll compare that against the current state. We even try to do some multi-variant testing once in a while, and really look at it from an analytical perspective. Are we making things better for them? Are we improving their experience?

J: How do you measure that? First you have to figure out what to measure, but then how do you measure if they're making the experience better?

Laura: Actually, we've been using the Net Promoter Score measurement for almost all of our products. That's something that McAfee's recently adopted. At first, I was not a big fan of NPS because as many UX Designers have probably experienced, it can be limiting in terms of what feedback and how actionable it is. Sometimes you'll get an NPS score, and it just doesn't tell you the whole picture.

The way we're using that is that we actually ... we're using it to help prioritize some of the major issues and problems that we're tackling, which I think is very cool. We actually have a dedicated group that goes through all of the comments. Some of them can be pretty scathing sometimes, but they'll go through the comments and help us prioritize what we are addressing.

The way we use it in testing ... if we're showing something new and improved against the previous experience, we'll ask the NPS question, "Would you recommend this? Based on just your experience with this particular part of the product, would you recommend this to a friend or colleague?" It's a little forced sometimes, but it actually gives us something measurable that we can compare in user research. It helps give us a number there. It's pretty cool.

J: Right. Some measurement is typically better than no measurement. Although, there's a long-standing debate about how to collect data and whether or not it becomes useful. It's interesting to hear that you're following a pattern that we're starting to see a lot in some of these large companies where they're going to their internal support systems and support teams as a proxy to figure out what some of the biggest challenges are for the user base, and going to those users and testing whether or not the solutions are actually effective for helping them solve their problem.

Laura: Yeah, that's exactly what it does, and helping to engage our support team ensures that we have a good pipeline of customers to talk to, and I think it helps them feel like they're heard and that the issues that they're dealing with every day with frustrated customers on the phone that they're being addressed and prioritized by the product teams.

J: Which brings up another interesting point. Somebody I was talking to in the last season of the podcast, I believe it was Nate over at LinkedIn, and was saying that one of the unintended benefits to using a stronger, more human-centered design process was that it built morale across the team. More people felt like they participated in the solution, and they were being heard across the entire organization. Have you seen something similar?

Laura: Yeah, I think that's definitely a shift that's happening. In the course of the work, McAfee's a pretty large organization, and there's so many different individuals and teams involved in almost every aspect. I think the more that you engage with more of your partners across the organization, it not only helps kind of evangelize the user experience process on our team, but we also start to get to know what some of these internal challenges are.

I think we're still coming from the fact that we're quite a siloed organization, which is something that I'm sure many folks deal with. I think the more connections we make, and the more we understand who to reach out to for what, I think that's helped everyone do their work a little bit more efficiently.

J: That makes a lot of sense, and it's pretty consistent with what we've seen in other organizations. Can you talk a little bit about some of the shift that you've seen in the product, or in the process of creating the product, where you saw an unexpected benefit, or you saw something improve that you didn't necessarily expect to improve, it was just kind of a byproduct of using a better process?

Laura: I think just talking to customers first hand gives us so much insight into coming up with really innovative solutions for things that we may not have thought of. Just the process of going through user research, it can be a little time consuming, but I try to sit in on every single session that I can because you hear customers come up with an idea, and you may have never thought about that before. It ends up that no one else may have mentioned that particular way to solve something, but it ends up being something that can benefit all customers. Getting those little insights have been fantastic, I think at least for my work, in helping positively impact the work in general.

We've also really utilized our UX process, and I think what we're hearing from research, the number one thing is that many of our work flows are disconnected, and customers have to go to all these different places just to accomplish a single task. I think the UX process, and what we've done in a very short time ... our group is fairly young. I think we're about, in our current form, about two years old.

The work that we've been doing with research has really revealed that work flows were broken, so we're now trying to make more contextual work flows where the user would have everything they need to do writing context without having to jump around in different places in the application. That's directly attributed to just input we've gotten from doing our research. I think that's fantastic, because it's something that may not have been revealed when we had maybe a couple of different engineers or developers working on a product.

That's something that, I think, in the past because we're designing for this particular IT Administrator, or Security Administrator in the past engineering design, a lot of our interfaces, and I think it's been revealed over time that that just isn't working. You really somebody whose got more user centered design focus, and can go through the proper steps to make the right experience to support the user with where they are in their work flow.

J: Yeah, that makes a lot of sense, too. I'm glad you're talking about research, because I was curious. Securities are really fascinating, and can be a pretty opaque world. How are you gaining more knowledge about that entire space? About kind of the security ecosystem, and the types of things that you need to pay attention to, and the types of things that are important to your users?

Laura: This was a huge challenge for me when I joined the team. I had worked for a lot of different types of customers and industries in my background, but the sophistication of our users, and knowing about the IT and security space was a huge challenge. I picked up quite a lot from working on our products, and listening to customers and working with my partners and product management and engineering, but that still wasn't enough for me.

What I'm actually in the process of doing, there is a certification ... it's actually a fairly intense IT Security credential called the CISSP. It's the Certified Information Systems and Security Professional.

J: That's a mouthful.

Laura: I actually took a course in that. Yeah, it sure is, but I'm planning on actually taking that test. I've been studying for it. I took a course, and it was hugely beneficial in just explaining some of the fundamental concepts of networking, and I can now draw how a firewall works, and just getting some of the vocabulary has been critical. I've never worked for anyone ... of all the different types of industries I've worked for in the past, I've never had that desire to learn more just so I could really empathize with the customer that we're designing for.

I think it was such a leap from my background. I didn't have a technical background, but now that I've started to delve into this, I feel a lot more confident and can really understand what the products are doing. It's one thing to understand what your user wants to do, but it's a whole other level to understand what the product is actually doing, and how it all works together as a system.

J: That's taking customer empathy to a whole new level. It's actually really studying their world, and understanding their world kind of in the same terms that they do. At least to an extent.

Laura: Yeah, and I think it's something you get a little bit of that just from talking to customers, but you're still not in their world. You're not sitting next to them and seeing what they're dealing with on a daily basis, or what they care about, or what keeps them awake at night.

J: Or, really a kind of understanding the perspective that they come from when they're starting to think about how they're going to use the product. Their training is entirely different from the type of training a typical designer would come from.

Laura: Yeah, exactly.

J: You mentioned a little bit about your background. How did you get to where you are, like your career path, and what gave you ultimately the decision to kind of work in security?

Laura: I started out as a visual designer. Like many, I got into web design in the late 90's, and just kind of ended up in the agency world because I think that's where a lot of people end up. There was a lot of hiring going on at that time. I ended up working for a nonprofit shortly after, and had a really difficult design challenge where I started Googling something that I didn't quite understand, and it turns out what I was looking for was actually called "Faceted Navigation," and it kind of blew my mind where I started doing all this reading, and then later that day I ended up making the decision, "I'm going to go to grad school for UX and information architecture."

It just blew my mind that it was this entire discipline out there, and this was in the early 2000's, so this was when it was a fairly young discipline, and there weren't a lot of programs. It wasn't very widely known, but I ended up getting my masters in human computer interaction. I continued in the agency and consulting world for quite a while, and then I ended up decided I wanted to move across the country from Chicago to the Pacific Northwest. I took that as an opportunity to get out of the agency world, because it just wasn't really giving me what I wanted.

J: That's interesting. I can understand moving from Chicago to the Pacific Northwest. That, I understand. I've been in Chicago, my wife's from Chicago, it's a very cold, harsh winter. I can understand wanting to escape that, but leaving the agency world where you've got a lot of variety and solving different types of challenges for different types of clients as a UX Designer, at least for me that seems like the sweet spot where you want to be. Ultimately, what led to that decision to go in-house?

Laura: It was great for a long time, and I got a ton of experience out of working in the agency and consulting world. I learned a lot from a lot of very creative people. I think I got personally frustrated at some point, because I would always be handed a project like, "Here, you're going to make a thing. You're going to make an app or a website," and when you're told you're making a thing and what that thing is, you don't necessarily have a lot of say ... especially if maybe that's not the right thing to make.

Oftentimes we get our work very well-defined for us by account managers and strategy folks, but if you don't have a lot of say in it, it's hard to be more personally invested in the work. The project is over, and you're on the next thing, so it's not really ever knowing in a lot of cases it that helped the client solve their problems.

J: Yeah, right.

Laura: I think going in-house has really helped me be more part of a longer term strategy.

J: That makes sense. You can feel more invested in the product that you're working on because you get to see it all the way through the process from the initial customer request all the way through shipping it out and seeing people use it, and measuring those results.

Laura: Yeah, it's more of a long-term engagement that you have with it. You're able to actually tackle much bigger problems, and the problems almost ... I found that they reveal themselves. We are getting a lot of projects prioritized from the promoter score analysis we've been doing, but I think a lot of my projects are kind of focused around some of the same problems, or similar problems.

The other thing, too, to recognize is that not all of them are UX problems. They come from other parts of the organization, and they manifest themselves in a poor user experience, but you're actually able to work with those other partners I think a little bit more to really get to the root of what the problem that you're solving is.

I think being part of that multi-disciplinary approach to address really complex problems is one of the unique things I've gotten out of my in-house experience.

J: That makes a lot of sense, and you end up finding organizational issues, or other administrative problems that end up, as you said, manifesting themselves as an experience issue that are actually rooted in something completely different.

Laura: Yeah, exactly.

J: Would you mind talking a little bit about your process? We talked a little bit about the research side, and going and understanding what problems need to be solved, so what happens after that? Are you using some form of prototyping? Are you testing those prototypes, or are you going straight through to development? Can you talk a little bit about that?

Laura: Sure. We do have a defined process, and that tends to work very well for more of the larger scale, like newer products. What we do is we identify the major customer problems, we work with our partners in the product management group, and we try to do whatever ... we use whatever we can from research to help inform that. We identify what those major ... we call them "epics," and then we design work flows and story boards to support those.

Basically, at every stage we try to validate those with our customer research, or at least internal research because we do have a lot of expertise in-house, especially from our support group that works with customers every day. We try to then flush out the details and work very closely with development to make sure that we've got all the different scenarios covered.

I think one of the challenges of an organization the size of McAfee, is that we've got a lot of separate and different development teams that are working on a lot of different things. I support about up to 10 teams with the work that I do. On my project roster, it's 10 separate development teams, and they're all working in more of an agile process, which is really challenging because ... if anyone who works in agile and does it well, or feel like it goes well, it works a lot better when everyone's working closely together and you, as the UX person, are basically embedded in the team.

Because of the sheer number of teams we support, you can't really do that.

J: Right.

Laura: What we try to do is stay one step ahead and know what they're going to be working on in the next sprint, but we still have a lot of work to do to align our process with that development process. I think that those are some of the organizational discussions that are happening. Now that we're the new McAfee, and we're apart from Intel, we have the opportunity to really rethink some of our processes and how they work.

Our UX process is great, but we need to do a better job of working with the development teams to align our processes closer.

J: Sure. I think that's a challenge that a lot of big organizations have, especially if they came from a more traditional waterfall-style process where everyone is in a silo, and everybody is kind of doing their own thing, and there's not a lot of cross-functional, or cross-team communication as you start to see a lot of that. It's good to hear that the organization is starting to recognize that and move towards the right direction.

What do you see as some of the tools that are helping facilitate some of that discussion? Even if it's like a piece of software, or just processes, or maybe a book that you've read that have helped kind of fuel that and push the organization in the right direction?

Laura: We're using Sketch and Envision, and Envision is actually helping us collaborate a lot better with our development partners. We are also using Zeppelin, and we have a living style guide. Those things ... once we get down to the design details where something's actually being built, we can work directly with our development partners to go and get the specs for a particular element or pattern. We can do a lot more easier collaboration with those tools.

We try to use prototyping tools like Envision, where partners and stakeholders can make comments right on the screens themselves. Organizationally, we're moving toward using JIRA. I think it remains to be seen how we're going to be using that overall, and what teams will be part of that, but I'm hoping that the UX will be a bigger part of that so we can work a lot more closely with our development teams to make sure we're getting them what they need, and making sure we're staying on top of the project.

Things move pretty quickly, and it's a lot to manage when you're working with so many different engineering teams.

J: It seems like that pace of development is just accelerating, right? As tools get better, and as people figure out better ways to communicate, things are just moving faster and faster. We see that in a lot of the companies that we work with, and incidentally when we had the guys from Envision on the show earlier in the season, they were talking about how they've seen some of the rapid change within organizations when they go in and show people how to use tools like Envision to really accelerate that process. It's good to hear that that's working for you, too.

Laura: Yeah, it's good because we're able to work a lot faster, and collaborate more easily, but I also think the expectations have gone up on the fidelity of the designs that we're creating. Instead of spending a lot of time creating a lot of different wire frame drafts, we're really going right to almost a more polished-looking design in many cases, because we have such a well established design system, and we have all these tools.

I think that can be personally challenging because sometimes you present the work and it looks like it's finished, and it looks like it's done. It's something that I think our expectations of our stakeholders have only gone up since we've starting working this way, which isn't necessarily a bad thing, but it can be a lot of pressure.

J: Yeah, of course. Since you're using tools like Living Design System and style guides, and all of that, it keeps things flexible and moving quickly enough. I'm curious, when you are taking something that's still maybe in the prototype phase, but it could be in Envision, and it looks like a high fidelity usable piece of software, if you take that upstream to stakeholders who might not be as familiar with some of the newer tools, what kind of reactions are you seeing around acceptance, and around their willingness to push back on that design or maybe feel if that design's already complete and already sailed, or do they still feel that it is still very malleable and you can go back and make changes?

Laura: I think it's a little of both. I think generally it helps to put a lot of polish if we're trying to sell a concept or an idea and get traction, especially if we're trying to make sure that some work gets completed, or make sure it gets prioritized. It does go both ways, though, because it can look fairly polished, but I think our ... we have so much expertise in-house that our product managers are really good about looking at something and evaluating it pretty objectively, and making sure that it supports what's needed.

I think as a designer, it can be very challenging because when you put something together and it looks so finished and polished, I think a lot of folks overlook some of the little minor details, and you sometimes have to go back. At least I found that sometimes I'll have to figure out all the details later, especially because we're trying to avoid doing a lot of heavy documentation. We're trying to stay pretty lightweight, and have it be more of a back and forth between the engineering team, or the developer and the designer.

A lot of times people think that a design is completely finished, where it's really ... there's still a lot of stuff to figure out, like a lot of edge cases.

J: Yeah, again that just goes back to having good communication and making sure that everyone understands that where you are in the process and what types of feedback are important at that particular step.

Laura: Exactly. I think we need to do a better job, too, of documenting requirements and using the tools that we'll have in place like Jira to make sure that we are identifying all of the user stories and epics, and identifying at what point that design will be delivered. I think it really will require being pretty much in locked step with those processes once we get that all in place.

J: Yup, makes total sense. Well, I really appreciate you coming on and sharing a little bit about how things are working for you, and the types of things you see evolving, and really it's interesting about how you approach in such a sensitive and deep and difficult topic like security, and still build a product that people can enjoy using. I really appreciate you coming on the show today and talking about that a little bit.

Laura: Yeah, well thank you so much for having me.

J: Yeah, sure. If someone wanted to reach out and get in touch with you or learn more about your process, or whatever ... what is the best way to reach out and get in touch with you?

Laura: Probably on my LinkedIn, so Laura Thelen, and I'm on LinkedIn.