Content strategy in UX teams (podcast)
Podcast: Play in new window | Download
Subscribe: Apple Podcasts | Spotify | Amazon Music | Email | TuneIn | RSS
In episode 134 of The Content Strategy Experts Podcast, Sarah O’Keefe and guest Jodi Shimp talk about the role of content strategy in UX teams.
Related links:
LinkedIn:
Transcript:
Sarah O’Keefe: Welcome to the Content Strategy Experts Podcast, brought to you by Scriptorium. Since 1997, Scriptorium has helped companies manage, structure, organize and distribute content in an efficient way.
In this episode, we talk about content strategy as a part of UX teams with special guest Jodi Shimp.
Hi everyone, I’m Sarah O’Keefe. Welcome to the Content Strategy Experts Podcast, Jodi.
Jodi Shimp: Hi. Thanks for having me.
SO: I am so glad to see you and/or hear from you. So for those of you who don’t know, Jodi and I worked together for many, many years on a lengthy project, and at one point, she introduced me into a big meeting as her content therapist, and I guess this is my revenge. So today we’re here to talk about content strategy and what the role of content strategy is in UX teams. And Jodi, what brought you into this? What’s your interest in this topic?
JS: Yeah, so I spent those many years working on that project with you, but a lot of years developing and leading content strategy from the ground up for a large manufacturing business, and even as part of product interfaces, and then I switched over to join Wayfair as part of their customer-facing content-strategy team. And by that, that team was responsible for the UX content for all five Wayfair brands in all locales.
So although we worked with branding and merchandising teams and content ops and a lot of different groups, we were really primarily part of the experience design team, along with product designers and user researchers. It was a real change from content strategy work when we’re talking about all the levels of structure and meta, and all of the different things that you think of with content strategy, and it was a big departure from working on physical products. So there was a really fast learning curve necessary for that.
SO: So what was the biggest difference? You came out of producing physical products, which by the way is pretty hard to say, and moved over to a digital product company. And from a content strategy point of view, from that lens into the organization, what happened? How was it different?
JS: Yeah, so coming from the physical product side where I had also built content strategy as a function from the ground up, and working with a product that requires a longer lead-time and a longer development time, and moving over to digital where things move very, very quickly, working with a lot of very intelligent people who have created things in a very fast-moving environment that changes super quickly, it was a lot harder to put the wheels on that vehicle as it’s moving forward at a really quick pace than it was in the physical product world that I had been used to before. Even though that had also been accelerating because of more and more content on the product itself in the form of digital displays, it was nowhere near the same speed as the technology companies move.
SO: So you come into a digital product moving at the speed of, I guess, electrons, and into an experience-design team. So I guess foundationally, I keep asking this question, how is UX different from content strategy? And also, please tell me the difference between content strategy and content design.
JS: Yeah, so I think that’s a blurry thing that maybe nobody knows the answer to quite yet, but I can frame it up in how I’ve been seeing things develop specifically at Wayfair, and talking with different content strategists that are at companies like Amazon and Spotify and Shopify and all of those.
So content strategy as a terminology is really starting to become something that people think of marketing as in the technology world. So they’re thinking of those marketing teams, because of marketing content strategy and whatnot. And then there’s the UX content strategy. We’re often starting to hear more content design in that, and I think that’s because those content strategists in UX design teams are often part of experience-design teams. So they sit with the product designers and the user researchers and work side by side with them in these user-experience-design teams.
So that’s starting to be called more commonly content design. But I’ve also seen it still called content strategy, as it was Wayfair. And some places it’s content strategy, some places it’s content design, and sometimes I think they’re really being seen interchangeably still. But I’m starting to see a little more definition between the two.
And then I still think of content strategy as an overall, more talking about that structure and adding the meta and making that smart content that it’s really able to be reused in different places, and it identifies itself of what it is and how it should be used and all of those things. So I hate to say that the lines are still really blurry, but I think they are.
And I think the other common thread that I’m still hearing, whether it’s at conferences like LavaCon or just talking to peers in other companies or on LinkedIn posts, is content strategists, content designers, UX writers, all feel like they spend a lot of their time explaining what they do to other people and trying to help people understand why they’re there and why it matters. Just because you can write in a particular language doesn’t mean that you really understand how to get a user from point A to point B in the most concise way, and most delightful way in a lot of situations, so they enjoy doing so and can do so effectively to accomplish the task that they’re trying to achieve.
SO: And it’s like you said. I mean, in a scenario where you have to say, “Oh, I’m a content strategist, but no, not that content strategist, I’m the other kind. No, not that kind, the other, other kind.” I mean, it’s just-
JS: Right.
SO: And we’re not even going to deal today, because we don’t have enough time, with the question of content engineering and content operations. We’re just going to put that aside and move on. I mean, we’re supposed to be content people, and we are super terrible at self-description, and we argue these terms for years.
JS: Yes. Yes. One of my most enjoyable things in joining that technology team was to the entire 180-person design team, I gave a presentation about what is content strategy and why does it matter to product design, and went through all of the pieces. Here’s why it matters. Here’s what we do. Here’s how we approach content. And we’re not just wordsmiths that come in at the end and make the words pretty, just like you product designers aren’t there just to make the interface pretty. It serves a function and a purpose to help a user achieve their end means. And I got, surprisingly, to me, a lot of feedback on that particular presentation from product designers and user researchers about how they now understood it.
And we also followed that for people who were interested in doing content workshops, content studios, where we took different product managers, user researchers and whatnot through the process of how we would think about content and how we would structure the content and why that matters and what it means in the long run for the content. So that was another effective way with those teams to help them understand the purpose of content strategy in design teams, and we had a lot of success with that over a longer period of time.
SO: So you’ve mentioned content designers, content strategists, user researchers and product designers, I think. And so what did that look like? So you’d have, I guess, an experience-design team that had those four contributors, and then what?
JS: Experience-design team works in a lot of technology companies as part of atomic teams, or sometimes called four-in-a-box model. And that four-in-a-box model really means user-experience design, which includes the groups or the individuals that you talked about. It also includes product owners or product managers, and back-end engineers and front-end software developers.
So the goal is that they’re working in an agile environment on specific features or digital products to, from start to finish, create new or revise existing product features or products together. And the goal is that they’re there from start to finish so that everybody’s working in lockstep and having different review points throughout that development so that what is designed by the user-experience-design team is actually what’s created at the end and tested and then published, released, for the end user, whomever that end user is.
And sometimes, that is super effective. Most of the time, it’s super effective. But there are a few drawbacks that I noticed, being in those technology teams. One of those is, because you have each of these individual atomic teams working on features, it can be really difficult for those teams to connect with other atomic teams.
And so as content strategists, we’re often really concerned with, “Okay, how does somebody get to this feature? Where are they going after they leave this feature?” Because a user might experience multiple features over the course of accomplishing one task: deciding what they want to buy, being inspired, looking through choices, all the way through that end checkout, and then maybe coming back. “Where’s my box? Where is the thing that I ordered?” three weeks later when it still hasn’t shown up, or things like that.
So as content strategists, we want to connect all those different groups together, but the atomic team wants to move fast and quickly, and sometimes that makes them separate from the other groups so that each can move independently and quickly. So there’s positive things to that model, and then there’s some drawbacks too for content strategists, and I’m sure the other teams as well, but especially for content strategists.
SO: You talked about the speed, the velocity at which you’re working in an organization like this. We haven’t talked about whether that’s a positive or a negative, but we’ll just say it was faster. But was there anything that you really missed coming from physical product that was different that wasn’t there, that you’re sitting there thinking, “Ugh, we used to have this and I don’t have it any more”? Was there anything like that? I’m curious about the difference.
JS: So I’ll start with the reverse of that, actually. The thing that I did really like about digital products is you have a lot different opportunity to iterate on ideas and introduce gradual improvements, where with a physical product, once you’ve released the physical product, apart from the actual user interface, it can be really difficult to make incremental improvements, and expensive to make incremental improvements.
So I think that is a thing that I actually enjoyed, was that opportunity to go from a true MVP product that can be released and then incrementally improved, where when you put an MVP physical product out there, there’s more risk in that, I think, and you can’t go back and, “Hey, I’m going to install this new feature on your car because we think it’s cool, so we’re going to add a new button,” after someone’s already purchased it, where with the digital products you can.
But the negative was not having that hands-on piece through the development where you’ve seen a 3D-printed model or the mock-ups and you’ve compared hand in hand, one beside the other. You’ve got A/B testing in digital and other user-testing opportunities where you can mock the different ones up in a digital environment. But it felt very different from the physical progression, to me, than the digital progression.
SO: That’s interesting. What about localization? I know that you had a heavy emphasis on localization in your former life, and what did that look like in this digital product world?
JS: Yeah, so localization’s my pet favorite thing to have around. I don’t know why, but it really is. So I look at every product, whether it’s physical or digital, through that lens of localization, and I’m constantly asking myself, whether it’s something that I have anything to do with production or not, “But how would that work if you put it in a different environment?”
And there’s some things that work great if you put them in a different environment. My blow dryer is one that doesn’t work great if you put it in a different environment. I’ve probably burned up a more than one hair dryer trying to use them in the wrong environment. But those are the sorts of things where that’s my lens always.
So in the technology teams, in the UX design teams, working for a company that did not do a ton of localization beforehand, that was probably… And originally the reason that I joined Wayfair was to work on localization and really help guide that map and create playbooks: how do we do this better?
So there was a lot of education, and one of the biggest things that I took away as a positive from Wayfair was a really cool look at what software engineers could do with localization, and having software-localization engineers on those teams, how cool that was, because I had always relied on outside vendors to do any of that before. But now you have software engineers who are creating APIs right into the work-stream of how to translate content right there.
So they’re building and testing and playing with machine translation engines. They’re building a platform, an interface, that takes whatever we feed it from whichever software within Wayfair, and then that can feed that out to the localization providers or a CAT tool or whatever that needs to be, an interface there. So that was really cool working with those localization teams.
But I did find the same similarities that I’ve seen in other industries, where a lot of the localization problems, they get blamed on the translators; they get blamed on that localization team. And they’re really problems of the source content, whether it’s problems because it wasn’t written succinctly and clearly, or if it’s problems because they didn’t think about the fact the expansion was necessary and the same words won’t fit in the same space when you translate from English to German. So lots of education back to those source-content teams and the source software-engineering teams to learn how to handle localization libraries for metric units and things like that. So translation problems often start at the source, and I found that to be the same whether it was digital or physical, the source.
SO: I just remember that incident, which I think you know about as well, where we were looking at a particular translation and the feedback came back, “Ugh. The Spanish translation is terrible.” They used five different terms for brake-pedal or some word or phrase that should be a single word. And they were like, “This is a terrible vendor. They used five different terms for this word, and we need a new vendor and localization is bad,” and et cetera. And then we went back and we looked at the original English source, and what we discovered was that in the English source, they used eight different terms for brake-pedal.
JS: Yes.
SO: And the localization team, or the linguist, had actually gotten it down to five, which was a big improvement.
JS: So much.
SO: And they were still getting yelled at for being bad and not getting it down to one. It is true that it should be one; it’s just that it wasn’t one in the source, which is where the problem originated, and they were getting blamed for not magically inferring that these eight different terms were actually a single thing, which seemed a bit unfair.
JS: Yes. It is unfair, and that’s why one of my… Well, actually at both the big companies that I’ve led, this type of thing, terminology-management program, is one of the most critical elements. And as machine translation becomes a greater part of localization, really it’s going to be for everyone, I think 50% of translations for customer-facing products are coming from machine translation at this point. And that’s pure machine translation. That doesn’t even include machine translation with post-editing. For companies to manage terminology well, whether they’re physical products or digital products, it doesn’t matter, that terminology is critical to having well-translated products, as with all the other content.
SO: And presumably it’s only going to rise.
JS: Exactly, because I hear a lot more already company leaders saying, “We can translate, so we should,” where in the past, when it was much more expensive and much slower, and machine translation wasn’t an option, you’re very, very specific about which content gets translated. And now the expectation is becoming that everything should be translated, so how are we going to do that effectively?
And a lot of the localization aligns with accessibility. If you make it so the source content is written well and well structured, and that metadata is there, then accessibility requirements serve everyone better, whether you need the specific accessibility adjustments or not. And the localization requirements drive the same thing. It’s talking in simple language. It’s talking in consistent terminology, consistent structure, that makes localization smoother too.
SO: Well, that seems like a perfect place to close this out: with a call to make your source content better and more accessible so that people can use it better, or we can translate it better, and/or it can be more effective out there in the world. So Jodi, thank you for coming in and sharing some of your hard-earned wisdom with us.
JS: Well, thank you for having me. It’s been a pleasure, as always.
SO: Yeah, it’s great to see you. And thank you for listening to the Content Strategy Experts Podcast, brought to you by Scriptorium. For more information, visit scriptorium.com or check the show notes for relevant links.
About the author
