Michael Haggerty-Villa: Design Systems and Content Strategy

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Spotify | Android | TuneIn | RSS

Michael Haggerty-Villa’s work with content and designs systems spans the history of these practices. From his work at eBay on one of the earliest design systems up until today, he has been at the forefront of both content strategy leadership and design system innovation.

This conversation focuses on design systems, but it was inevitable that Michael’s content strategy wisdom would shine through, too.

We talked about:

• his work as the Director of Content Strategy at Teradata
• the scope of the design system documentation at Teradata
• how he triangulates on the truthiness of the complex content ecosystem
• the structured-content infrastructure that he works with
• his preference to bridges silos, not bust them
• the style council he convenes to help align stakeholders on language and other topics
• the differences in content needs in design systems for B2C companies vs. B2B
• the tooling he uses to manage, and the scope of, the Teradata design system
• how they establish standards as documentation for new media formats like video are incorporated into the design system
• the importance of standards in communication and design guidance
• the requirements they’re developing for their design system management tooling
• his preference for a “reliable starting point” over a “single source of truth”

Michael’s bio

Michael Haggerty-Villa is the director of content strategy at Teradata and has also worked on the content design team at Blue Shield of California. He was one of the leaders who launched the Intuit Content Design System, and he has worked on design and systems for brands such as Compass, Disney, eBay, Mint, QuickBooks, and TurboTax. His articles about content in design systems have appeared in Content Science Review, UX Collective, and other sites. His content strategy clients include HPE Software, Kaiser Permanente, Yellowpages.com, and others. Just to make sure he has no free time, he’s also a father to three children and three cats.

Connect with Michael online

• LinkedIn
• ADPList

Video

Here’s the video version of our conversation:

Podcast intro transcript

This is the Content Strategy Insights podcast, episode number 184. Many people trace the origin of design systems to the release of Google’s Material Design in 2014. Almost a decade before that, Michael Haggerty-Villa was a lead content strategist in the Design Systems Group at eBay. He has since led content strategy and design systems initiatives at enterprises like Disney and Intuit. To this day, he remains at the forefront of practice where content strategy, information architecture, and design systems intersect.

Interview transcript

Larry:
Hi everyone. Welcome to episode number 184 of the Content Strategy Insights podcast. I am really delighted today to welcome to the show Michael Haggerty-Villa. Michael is a legend, I think it’s safe to say, in the content in design systems world. He is in my mind anyway, but he’s currently the director of content strategy at Teradata, so welcome Michael. Tell the folks a little bit more about what you’re up to at Teradata and in the design system world.

Michael:
Hey Larry, thank you for having me and again, you’re the legend and thank you for all you do about continuing to put out this information about content strategy and content design into the world because we need people like you and Paula Land and other advocates for our craft to be helping us. So thank you, first of all addressing the legend where the legend needs it.

Michael:
What I’m doing right now, in January, I just started as the director of content strategy at Teradata, a massive data analytics and data storage company, and we’re in the process of doing a digital transformation, actually migrating a lot of our business to the cloud. And as we do that, we realize that we need to create better experiences for a slightly different market than we have usually gone for, and the bar for those experiences is higher, the bar for what good content is is higher, and so we’re sort of transforming the content practice as we speak, really looking at content design, content operations, content systems, and a lot of the technical documentation that supports a lot of what we do, for a lot of our audience. So right now I have my fingers in all the pies of the content themes and that’s what I’m working on, including our young design system.

Larry:
What’s it called again? The name of the design system?

Michael:
The design system is Covalent.

Larry:
Covalent, okay. Yeah. Is it publicly, because I know not all of them are out in the world. Is yours publicly available or?

Michael:
We just started doing documentation on it, so we’re in very early stages. Of course we have bunches of Figma files that we can show, but we don’t have the documentation on usage purpose, the critical things as well as really we have a legacy number of content systems and style guides that we need to start to pull together into one unified resource. I feel like I’ve been here before, similar to some of the work that I did at Intuit, pulling together one style guide for them, and so we’re starting off on that journey at Teradata. It’s actually terrifying and exciting.

Larry:
Yeah, no, I love the way you set out this first, the way you just described your current role, it sounds great. You’ve got your fingers in every little bit of that pie at Teradata, which is really important, but then you’re ensconcing that knowledge, lore, wisdom, practice stuff in the design system as well, which seems really important. I also love that you kind of alluded to, I don’t know if you were thinking about it, but I love the way John Collins a couple of years ago set out the scope of content practices, strategy, design, engineering, operations, and you’re all over that, but tell me which, how much of that shows up in the design system documentation and elsewhere in the design system?

Michael:
It all will to a certain extent because we are a lightweight to the house for technical documentation and we need lots of guidelines to do that correctly and that’s very, very challenging. We have a pile of documentation that helps us do that. Some of that documentation is not as useful as others because some of it has not been maintained, governed. So we have an opportunity for some of that tools usage documentation as well as some of the basic style guide information. We encountered yesterday three different terminology, indexes, indices, and we only need one. We have to have one, I hate to say one source of truth, but one reliable place where we can find the answers that guide us to do this content thing that we’re doing.

Larry:
Well, as you say that, I’m really curious about that because you kind of need in any initiative, a single source of truth to refer to, but the reality of a complex organization like you just described is that that’s really hard to do, but you still need to source your truthiness from someplace. How do you handle that in a complex org?

Michael:
I love that you used truthiness because I just used that in a Slack message yesterday because we have various sources of truthiness and so as a result, nothing is reliable right now. I’m relying on a lot of relationships right now, I’m reaching out to all people who do content design in the organization and we have contributors to the design organization on the developer side, software engineering, and they’re all valid contributions. Also reaching out to marketing because the end-to-end experience of content matters from the first door of Teradata is a thing, through when they finally sign up for the product.

Michael:
Most of my purview is the product experience, but I definitely need to know what our marketing partners, what our social media partners, what our bloggers are doing as well. So right now I’m in onboarding mode, drinking from the fire hose as they say, just learning all the content things about Teradata and figuring out where we lean in. It’s actually an exciting place to be and a lot of the discoveries that I’m making, I’m working collaboratively with a team and we’re going to document these discoveries and start to standardize our ways of moving forward.

Larry:
Yeah, as you said that too, you reminded, you set out the whole, I think of it as, I call it omnichannel. I work with Noz Urbina a lot, so I have to, but I think it’s a reasonable way to look at it. But when you describe accounting for marketing and the needs of the software engineers and all these other stakeholders that are involved, that sort of speaks to, and then you also mentioned lightweight DITA and sourcing your truth of the system. Is lightweight data, and actually we should probably describe that for people who don’t know because I’m a structured content nerd, so I love DITA and the DITA standard lightweight DITA is a more recent innovation that makes it a little more accessible to people who don’t want to go all the way into the XML world. Can you talk a little bit about lightweight DITA and how it came to be the system of choice there?

Michael:
This system choice was actually made probably a decade before my time, so we’re right now, full disclosure, evaluating if it is the right way to go. I am consulting with structured content experts like Michael Andrews, who I believe you talked to in the past, and I have a meeting on Monday with Carrie Hayne who wrote the book on structured content because we need to look at our current systems and say, are they serving us well for the things that we need to do as we modernize our approach to delivering content? We have an existing system using IXIASOFT, a handful of and Fluid Topics and oXygen and a handful of other tools. Is it as nimble as we need it to be? Is it as agile as we need it to be? These are all open questions that we’re exploring right now. We do not have a system that more readily helps us control in product content, and so we’re actually looking at some content management solutions that might actually assist us there as well.

Michael:
Tools is definitely something that is in my purview, and so we’re actually going to start, as I think about moving forward, I’m thinking content design, content systems and technical content strategy. I think those are the three pillars that we’re going to organize our practice on at this point. Talk to me in about another six months and we’ll see where we are because I’m only two months into this role and I’m learning every day and I’m willing to have my hypotheses proven wrong and learn and iterate as we go, but that’s how we’re going right now and that’s our current, to answer your question about our current tool stack, that’s where that is.

Larry:
And I think everybody has something like that going on because there’s this new, where it used to be it seems like 10, 20 years ago, it was a lot simpler that if you did technical documentation, you were just authoring an oXygen or something like that, managing it at CCMS, spitting out some, maybe even a printed PDF or something like that. Whereas now just this ecosystem that you’ve set out, there’s a lot more moving pieces. And you also mentioned that you’re kind of busting, or if not busting, at least spanning silos with the inclusion of marketing and developers and stuff like that, is it mostly about practice at the core of that, orchestrating all of that or do you have tooling around managing the complexity you’re dealing with?

Michael:
We never bust silos, let’s be honest. We bridge them and just by going in with relationships and humanity saying, “Hey, I know you’re marketing and I know you have to be persuasive in your content, we have to be straightforward in our content.” That’s a different practice, but how do we make sure we’re consistently for the customer’s sake speaking the same language? So my biggest tools are spreadsheets and where I document absolutely everything, including bad ideas because bad ideas are the stepping stone to good ones and they can be refined. And also I document lots of questions like, why is this this way? Especially as I’m onboarding into a massive content ecosystem like Teradata’s, I have many more questions than answers and I suspect that will probably always be the case, but I just have to be able to make enough hypotheses for us to move forward.

Larry:
You mentioned something you just said reminded me that when you said something about using the same language across these, and you mentioned earlier that you’d come across three different, I assume they each assumed to be canonical terminology documents or indexes of things. How do you align people around language? I think in a design system or almost any content endeavor, that’s always a challenge. How are you approaching that?

Michael:
I’ve already approached the marketing team and I’ve told them we’re going to establish a content council. We may call it a style council as other organizations have done where we can just start to talk about style decisions. The terminology of our business is very complex and we need to determine when it is our internal jargon, in which case we need to bury it. And when it is customer facing language that is jargon, that is really helpful for them.

Michael:
I don’t think we have enough clarity on that right now because we obviously have at least three terminology indices and we need some more clear guidelines on those. We arrive at those things. I always do that in a very democratic open process. Everyone on my content team can play on the style guide team, team and everyone across the organization. I want to know what the bloggers and the social media folks need. I want to make sure we don’t set some guidelines that exclude them, but also understand that they have different use cases and different delivery channels, and I want to make sure that our style guidelines are flexible enough to accommodate most of the content use cases we need to meet.

Larry:
And you’ve done stuff, you had at least two things that I know of when you were at Intuit. You did the QuickBooks design system and then the full kind of integrated Intuit design system. So you’ve done this kind of big customer facing design system work before. Did you face similar challenges there? Was it a little, because that’s a more, I don’t know if it’s straightforward, but it’s that kind of consumer, just a few consumer products. Was that a different situation there?

Michael:
The consumer focus makes it different. Obviously the language issues are very different. I mean, when we have to include in a style guide something like TurboTax, which prides itself on its simplicity and ease of use, it really opens the door for us to have those content conversations about clear, usable, succinct content across the organization. So thank God there is that content simplification happening in TurboTax. And then we were able to extend that to QuickBooks, which is an accounting tool for all intents and purposes, often for small businesses who don’t ever want to do accounting. So how do we demystify the necessary compliance language of accounting for people who just want to sell candles on their Etsy store or whatever their small business may be. So it’s been a different content simplification journey, but even with this business to business challenge we have now with Teradata, people are people, they still need simple, useful content and that is of the quality that they need. And that’s the challenge that we’re facing right now with Teradata. It’s actually very similar to the Intuit journey, different customer focus.

Larry:
And it’s talking about, it occurs to me too that not all of my folks will have worked with a design system. As you mentioned earlier, I think it’s typically associated with product stuff. And if you’ve been doing web content strategy or other kinds of content practice, maybe even technical docs, you might not have come across a design system yet. Can you talk a little bit about what all’s in a design system, you’ve mentioned some of the benefits of a design system and the role of content in delivering those benefits?

Michael:
Right. Figma, this tool that has become sort of the defacto standard for creating product design, and actually our marketing partners use it as well. Pretty much anyone who does design knows Figma at this point, has a design system at its core that there will be core reusable design components and patterns to create consistent design experiences. So with that, and Figma is a visual tool. It does a really good job of documenting how we visually put these things together and with dev mode or their developer mode, now they have a pretty good way of us passing that off to our developer partners to make sure that those visual specs can be executed on in code. But what’s lacking is how does content fit into that? Figma is not a content tool necessarily, so we still need to figure out how to collaborate with our design partners in Figma, but then when there are the more complex user content that, where does that get archived?

Michael:
We still need tools to figure that out. Is this going to be a dynamic piece of content that flows into this Figma component? And we need to figure out how we document that. So the design system will have components, some of the basic pieces of the designed experience, banners, buttons, dropdown lists, forms, but also some of the more complex patterns like a form to sign in, for instance is a pattern. What is your sign-in form your security information, some of that recurring things that happen across the experience. Those patterns will also be documented, sometimes even more complex templates, but we also need to be documenting content types as well, as well as our style guide should be there because it is a critical design tool. And how content types, what are content guidelines about emails? Almost every organization, sad to say, sends those and probably too many of them, how do we make sure they’re effective? They’re within the design framework and following some content design guidelines.

Michael:
What are our guidelines for salutations and closing? Do we even have those? And are we doing those in a consistent way to serve the customer experience and also to make sure you’re serving the appropriate brand experience. So there’s that. We’re also grappling with video and video standards because we’re going to be increasing the use of video in our documentation. We want to make sure we have clear guidelines for what is effective video in this technical space. It does not need to be a marketing video. It needs to be informative and direct and how do we provide guidelines for that? So all of that is emerging for us and will be in our design system.

Larry:
As you’re saying that, I’m reminded that the scope of our concerns just keeps going out and out and out or getting broader. And it seems like… I mean ultimately it’s a benefit to the end user because somebody’s thinking about this, all these media from the same place. But has there been either challenges around incorporating different, because from email to video, that’s a big jump and a lot’s in between, but I’m wondering about now, have there been opportunities to learn from practices in managing the design conventions around different kinds of artifacts? Does that kind of all feed into your design system practice?

Michael:
Absolutely. There have been numerous, let’s talk video because it is a content type that matters very much and it definitely needs to be crafted by a knowledgeable content person. So there have been numerous, I call them proofs of concept across the organization. Video has been done in the organization various times. There’s marketing videos available, there’s instructional videos as well. And so what’s great is we can learn from all of those as we establish a standard that we’re going to use for our technical documentation, for instance. So we’re learning from all of those what works, what metrics do you have on those? What are some of your guidelines? Some folks in product are a little bit resistant to get guidelines from the marketing and brand people. I’m like, bring it.

Michael:
You’ve established a line in the sand that I can start with, a foundation, and then we can evolve that as needed for the product experience, but at least we have that as sort of some foundation. All of this other work that’s happened, it might not be at the level and the standard that we want to drive to going forward, but it’s all things that we can learn from. That’s internally. And then of course we look externally how are our competitors using video? What are some of the good examples of video in the marketplace, in the industry as a whole? How can we establish the best standard for us going forward? And that’s kind of the practice of establishing almost any design system standards.

Larry:
And That’s right. And it’s all about establishing those standards in the system so that all these things you’ve mentioned before, the consistency, the experience, the efficiency of the workflows for the people working with us, that’s the whole point of having standards, right?

Michael:
Right, right. So all of those people who’ve done those different processes and come up with those on their own in the future, they won’t necessarily have to because it’s like, oh, this is how we do it. Follow these guidelines as much as you can. They’re not laws. We’re not going to go in and say, “Hey, you’ve broken the video guidelines law.” We don’t have time to be the design system cops, but we do have time to give you these guardrails and these suggestions for how to move forward more efficiently, more effectively.

Larry:
Yeah. Hey, one thing you said, and this is just me noodling on the history of design systems. I’m thinking of all the way back to, what’s his name, the architectural pattern guy, but then there was book publishers had this sort of font libraries and layout systems, and then branding guidelines became big in, I don’t know, fifties and sixties or something like that. We had these whole books of how you treat the logo and typography and stuff. And then Yahoo’s pattern library, I think in 2006 was the first kind of digital ensconcement of this kind of thing. So that, anyhow, just kind of thinking about that reluctance of people to adopt that because, and I don’t want to out you as a fellow old person, but you were doing design systems, the content in design systems in 2007, not even a year after Yahoo introduced their thing. So you literally go back to as long as anybody’s been doing this. Does it ever help to draw on that historical thing, because you’re obviously current and valuable now in the current moment, but does that history, that historical heritage serve you at all?

Michael:
It helps. All that experience helps. We were very aware of what Yahoo was doing. In fact, I think at times we deferred to the Yahoo style guide. And yes, I do have a paper copy on the shelf behind me right now.

Larry:
I’ve got two over here.

Michael:
Which was a gift from one of my managers. And yeah, I still find myself occasionally dipping in there for questions, as dusty as the book may be. That interest in standards has always been part of the practice, but it’s also just built into communications. Our standard as communicators has always been standards based. We’ve always had dictionaries and some basic style guides, Chicago or AP, as part of our guidance for how we do this thing. Because as we do this and we’re doing it well, we’re always going to have questions about, oh, how do I refer to this person? Do I need to capitalize this term? All of these are legitimate questions of our craft, and we thankfully are not doing it alone. As much as we as writers might like to be up in our garret writing the great American novel, we’re never doing it alone. We always have other influences that can guide us and other inspiration. And it’s always been great to be relying on that from way back in my history as well as some of the contemporary leaders and contemporary folks who are working in this space.

Larry:
In thinking about that heritage too, and you mentioned a minute ago, Figma and how its whole design metaphor, it’s built around patterns and components and things like that. I’m trying to remember, I’ve been a content person, I haven’t really been that close to the visual design systems like Sketch and InDesign and the ones before Figma. Has that been an evolution in that tooling as well to be more concerned with design system-like stuff like patterns, or were they more just Illustrator for the web or Photoshop for the web?

Michael:
Yeah. I think back to what we were doing at eBay in 2007, and I think it was very Photoshop based, if I recall correctly. And then moving into some other Adobe products. I believe Sketch may be playing catch up right now with Figma. Figma just does so many things brilliantly for visual designers and product designers. It is not necessarily the ideal content tool as well, but it’s also not the ideal tool right now to map out some complex workflows, but to make those workflows look great, yeah, you’re going to want Figma, but to actually think through some of those workflows to make them easy and straightforward for customers, you need that information architecture, content strategy, product design thinking to be in there to get those right before you start making them look pretty.

Larry:
Yeah. And in both, like you mentioned workflows, but also is just all those words, content management tooling has been famously lacking in the design and design system world for a long time. And you mentioned that you’re looking at some tools now, regardless of the exact vendors and stuff you’re talking with. What are the capabilities you’re hoping to get out of a content, like a management system for your design system content?

Michael:
We have a confluence page full of requirements. And in fact, as a fun exercise, we asked one of the AI tools, give us some content requirements for our content management system. And so we have those as well just for fun. And some of them are like, oh, that’s a good idea. So it’s interesting that there’s a lot of information out there. We need to actually look at some of our current systems and say, what does it do well? What do we love about this current implementation of our current content management system that we want to preserve? But also what are the gaps? What do we need to go forward? We know we need something that’s easier to update and doesn’t require both an information architect and a content writer to make a change.

Michael:
So we’re definitely looking at ease of use in our content tools and with an eye towards really helping the author experience. And we have a limited number of licenses with our current tool, and we need to democratize content creation a little bit across the organization. I want more software engineers and more other subject matter experts to participate in the creation of our content. And that’s going to be a little bit challenging with our current tooling. So yes, we’re working on the requirements for our content management system now. Democratizing content is one of our requirements. Localization and globalization is also one of our requirements because we need to make sure we’re looking at how this appears in Brazilian Portuguese and Mexican Spanish as well as Japanese, which is one of our key languages and one of our key markets. So this is a lot of content stuff that we’re facing. I just kept throwing everything at you.

Larry:
No, you’re reminding me too that like, “Okay, we got all this figured out. Oh, yeah. And then we have to localize it for the whole world. Oh, geez. Here we go again.” Yeah. Hey, Mike, I can’t believe that we’re coming up close to time already. But before we wrap up, is there anything last, anything that you’d like to revisit from the conversation or just want to make sure we share before we wrap up?

Michael:
I feel like I’ve gone in all different directions because I’m right now doing all the content things, but also I think I want to bring the conversation back to, because you want to talk about design systems, I’m not doing all of the things all at once. We’re definitely going to be doing some really ruthless prioritization of what we take on at what time, and including with our tools discussion, we know we have a massive content migration facing us. And with our design system, we know that it is critical infrastructure for the content team to go forward. We need, I don’t like the term “single source of truth”, but we need that reliable starting point that helps ground the practice of content design and technical documentation that this is our pool of knowledge where we start from and we share this and we evolve it together, and how do we grow from there?

Michael:
And I think that’s going to be a key part of what we do going forward. So I’m really looking forward to the evolution of the Covalent design system at Teradata and how it helps us scale content design and content strategy across the organization makes us better at it and makes us better, more powerful business partners for the company.

Larry:
Cool. And I love that you think of it as a reliable starting point. That just seems way more pragmatic than this canonical single source of truth, which seems really daunting. Well, thanks. Well, hey, one very last thing, Michael, what’s the best way, if folks want to stay in touch, what’s the best way to connect with you online? Oh, and I love that your cat has made an appearance. Now it’s an official internet event.

Michael:
This is Willow. Yes. She is named after a character from Buffy the Vampire Slayer, and she does have powers, and she’s also a content strategist, which may be her superpower. I’m sorry, kitty. If people want to get in touch with me, they can definitely reach out to me on LinkedIn. I’d love to continue the conversation with everyone because I learn from your questions. And you know what, you can also reach me on ADP. I’m also mentoring people on ADP list as well.

Larry:
Yeah, I’ll include your profile there as well in the show notes. Well, thank you so much, Michael. Always good to chat and good to catch up.

Michael:
Awesome, Larry, thank you for the time.