Words as Data: The Future of Content Design

On February 3, 2026, we hosted a panel discussion on the future of content design with three industry leaders: Jess Ouyang (Co-founder, Ditto), Dave Connis (Lead Content Designer, OutSystems), and Chris Greer (Staff Content Designer, Stripe).

The conversation explored what it means to treat content as data, how content designers can move from static documentation to living systems, and what this shift means for working with engineering, product, and design teams.

Full transcript

The following transcript has been lightly edited for readability. Speaker labels have been added. No content has been removed or altered.

Patrick Stafford: [00:00:05] Welcome, everyone. Hello. Welcome to the webinar today. Thank you so much for joining us. We’re super glad you’re here. Just giving everyone a minute or two to enter the webinar. I know people will be jumping in for meetings and all sorts of things. We do have a chat, so feel free to say hello in the chat. You may have to change it to send to everyone and not just the hosts in the little drop down there. So we’d love to see where you’re logging in from and where you’re working. We usually get a pretty good international crew at these webinars. See, Romania, to start off a good international start. Wonderful. Thank you. Look, we got Mexico, we got the US, we’ve got Peru, we got Scotland. See, a wonderful international group of content designers here today. There was a lot of interest for today, so I do want to give everyone a couple of minutes, because there are people who will be still be streaming in. But thank you for attending today. We’re really excited to talk about this. And I’m not going to spend too much time on housekeeping because I want to throw to our three wonderful panelists. The topic for today’s webinar is Words as Data. And what is next for content design? I think we all know that content design is going through a massive shift, and today we’re going to discuss what’s happening and importantly, what you as content designers can do to respond and some actionable things you can do just to begin.

Patrick Stafford: [00:01:43] Just letting you know we are recording today. So you will get a link afterwards. So if you do have to drop off for whatever reason, you will get a link and you’ll be able to catch up. So please don’t worry too much about that. And as always, you can ask questions. Now, I should say the Q&A option in Zoom is there. Feel free to ask questions in there. We probably won’t get to questions until the end. So just be aware. We probably won’t be able to answer your questions in depth until the end. But I will be keeping an eye on them. So feel free to ask in the Q&A. I would ask you to please put your questions in the Q&A option in Zoom rather than the chat, because if it goes through the chat, I may miss them. Or both. Feel free. Okay, so we have a wonderful group of people here to discuss our topic. Today — Words as Data and the future of content design. And I think these three people represent the best of what content design has to offer from a range of different perspectives. And we’ll start with Jess Ouyang from Ditto. She’s a co-founder of Ditto. Jess, welcome to the panel today. Thank you for joining us.

Jess Ouyang: [00:03:09] Hey, everyone. Thank you so much, Patrick, for having me. Very, very excited for our webinar.

Patrick Stafford: [00:03:16] I know that there will be probably more than a few Ditto users in the audience. So this will be a good time for people to perhaps message you with some feature requests. No, I’m just kidding. Don’t do that. And Dave Connis, lead content designer at OutSystems and presenter of a systems thinking workshop. Dave, thank you for joining us today.

Dave Connis: [00:03:44] Hello. Thanks for having me. You can also ask me for feature requests. I don’t know what they would be for, but we’ll see. Sounds good.

Patrick Stafford: [00:03:53] You never know. There might be OutSystems users here in the audience, perhaps.

Dave Connis: [00:04:00] Sure, sure, Patrick.

Patrick Stafford: [00:04:01] Yeah. And Chris Greer from Stripe is here as well. And you may have seen on LinkedIn recently that Chris made a little bit of a splash when he created a Claude skill for UX writing that got quite a bit of attention. Chris, thank you for joining us today.

Chris Greer: [00:04:20] Yeah, happy to be here. Thanks for inviting me on. And always happy to nerd out about content design and all that fun stuff. So looking forward to it.

Patrick Stafford: [00:04:30] Now Chris, you also have a — you dabble in books, am I right there?

Chris Greer: [00:04:38] I have been known to dabble in books. Yeah. My wife and I own an independent bookstore where we live in small town Canada. So that’s my other job, I guess you could say, but big, big dabbler in books, for sure.

Patrick Stafford: [00:04:53] I think for a lot of people, that sounds like a dream. All right, let’s get into the discussion. So it’s a big question we’re discussing today — the future of content design. But really I want to focus on the first part of what we put in the title, which is treating words as data or content as data. And this is a perspective, I think, that particularly Ditto has been bringing to the table more. And I want to start by asking you, Jess, in terms of the future of content design, I know you and the team at Ditto have been trying to connect words and data and sort of package those two things together. I’d love for you to start us off by just answering that question. What does that mean? What does it mean to treat content as data, and why is that an important perspective?

Jess Ouyang: [00:05:52] Yeah, definitely. I think a lot of what we feel really passionately about at Ditto is not only just the craft of writing. I know a lot of us, especially content designers, just really care about the words, the value that they deliver to users. But also zooming out — where does that exist on so many different surfaces? It really takes the shape of something very similar to how other types of data is managed. It’s something that gets moved across a lot of different processes. It’s touched on by so many different roles. It’s pretty dependent on different layers of context where it exists. And because of that at Ditto, we’re quite opinionated that it should be systemised. It should be something that you’re able to reuse, you’re able to work on in a single source of truth. I feel like answering what does content as data mean is really clear when there are examples when content really does not feel like data. It’s like when you’re writing an error message for the 15th time in the same context, you’re just doing it ad hoc, where systems are really brittle. A lot of it is just manual labour. I think that’s kind of the opposite end of the spectrum. We’re really excited about what does it mean to put content designers and product teams in a position of being really high leverage, being able to move that and utilise that in a way as powerful as they can. And to us, that is really the heart of content as data. I could keep going, but I know Chris and Dave also have a lot more to add there. So happy to share more. But I think high level, that’s what we’re really excited about at Ditto.

Patrick Stafford: [00:07:38] Yeah. Dave and Chris, do you have any thoughts on what Jess just said?

Chris Greer: [00:07:43] Yeah, absolutely. It’s an interesting framing of the question because in some sense, content is literally data. It’s part of the code. The strings are there. But in another sense, you can only really call it data if you treat it as such, which I’m not sure has always historically been the case in a lot of companies. And what I mean by that is giving it the proper sort of infrastructure and observability, to Jess’s point, so we can see where this content lives, what the surrounding context is. And then the other piece that I’ve been really interested in lately — you know, being a content designer, I do care a lot about writing quality and just writing generally. Can that be quantified? Like, can you measure that? And I think that’s where things like evals with LLMs get really interesting. Can you break down good writing into a set of binary tests or similar that you can run against the content and spit out a score or quantify it in some other way? Or is there some tacit, magical thing that makes the writing good versus not? I think you can only really get to those answers if you treat content as data. So by and large, it just means that it’s measurable. I think that’s the key part for me.

Dave Connis: [00:09:06] The interesting thing for me is I saw a definition for the word user interface a while back, and the definition said it’s a place where two systems meet. I’m going to butcher this, so sorry Webster’s, but it’s basically the idea that it’s a place where a bunch of different systems meet together. And I thought that was fascinating, because a UI — when you think about a UI like a UI designer, you think about all the pixels. Not necessarily somebody who’s like, oh, this is eight pixels instead of 16 and you gotta have it on the eight-point grid — all of that stuff. But if you take that seriously, then the matter is that you are now writing and designing for a place where your systems are meeting, which is very different than just drawing boxes and getting paid money. So now you have a different set of considerations that you have to take into account if you actually want to build and design systems. So because of that, everything you see on a screen is a representation of something else. Almost everything is. A word, a box, a state, a hover — it’s all representing something.

Dave Connis: [00:10:31] And words are doing a huge lift for that in terms of representing. And words are typically representing a bunch of different things, and a lot of times those things are dynamic. So you could answer this question in a bunch of different ways, because you have to deal with the fact that LLMs read data, not pages. So you have to talk about that. You could talk about the idea that you have JSON files where strings could live. You have the idea that not all JSON or not all strings in JavaScript are exposed to give you the chance to even put it into a JSON file. There are some strings that are just locked away into a dark box forever, but it’s all representing the system underneath. So when you are writing for that system, you are literally working with all of the data, the objects, the metadata, all of the stuff underneath. So to treat content as data is also to understand the fact that it is representative of something and not just words on a screen.

Patrick Stafford: [00:11:42] I think that’s a good explanation. I’m interested to hear you guys talk about why is this important now. I feel like content designers understand that we’re experiencing a very big shift, not just in content design, in technology generally. And obviously we’re coming here and we’re saying, well, you need to treat content as data. I guess the question I would like to ask is why? Why is this important now? Obviously, it’s always been important to treat content as part of a product system. Chris, I want to start with you on this one, because I know this is something that you have an understanding of. You’ve posted on LinkedIn about working with LLM tools and new technologies like that. Why do you think that this type of approach is important for content designers to understand now? What sort of shift is happening?

Chris Greer: [00:12:40] Yeah, I mean, you alluded to it there. There’s this newfangled thing called AI that’s been in vogue lately. Maybe you’ve heard of it. Maybe not. I think it’s more important than ever, given the prevalence of LLMs. And I think for me, I look to our friends over in the engineering department and the transformation that they’re going through, in a lot of ways maybe a few months or maybe a year ahead of us, in which AI has really fundamentally altered the way that they’re working, down from the tools they’re using to the things that they’re doing day to day. Most engineers that I know at least, or speak to — they’re not writing much code by hand right now. It’s largely generated by Claude Code or Codex or one of these things. So if you follow the throughline of content being data and an integral part of the system, and these systems are now being by and large built by LLMs, it raises a lot of interesting questions about how can you provide LLMs with the correct context so that the content being created matches your style guide — all these other attributes that we just tacitly know and understand as content designers when we’re writing a string. Are the ways that we can feed that into a system? I think that’s up for debate. And I think where it gets interesting is that if that is true, if that is possible, the types of things that you’re seeing our engineering friends do now, where they can build things in hours that used to take weeks or months — it also becomes possible to scale content in that way, if we can accomplish a similar unlock there. So I think looking to them, I see a likely, although not guaranteed, future for content design, and how potentially content either gets created or is governed at scale. And I think treating it as data or as part of the infrastructure is a big part of that.

Patrick Stafford: [00:14:55] The “important but not guaranteed” line you just put there. That’s something, Jess, I want to ask you about, because I know that you have thoughts on the idea of content design as data versus craft and the idea of influence. And I know that you have mentioned before that if content designers want to have influence, embracing this type of approach is necessary. I’m wondering if you could expand on that.

Jess Ouyang: [00:15:26] Oh, definitely. I think exactly what you put into words — that tooling is essentially what empowers individual people to have different aspects of building a product really take a seat at the table. I think when — to exactly Chris’s point, especially in my own experience as an engineer and as a designer — there are a couple of ways you can see a conversation around how data management takes place that I think there’s a lot to learn from in terms of content. Like, one, data is treated as incredibly valuable. Managing it needs to be extremely robust because of how valuable it is. It’s measurable, exactly what Chris said. And tooling is also a constant conversation. Systemisation is a constant conversation about data because it is important. And I think that’s kind of the gap that we’re really looking to see content close, in order to have just as much say in building products as we want it to have in the future. We already — I’m sure this is preaching to the choir — but all of us are very bullish and have seen the direct effect of words in products. It’s extremely valuable, probably arguably more valuable than different things like colours, fonts, even different types of layouts.

Jess Ouyang: [00:16:48] That text is really driving how a user experiences that. But without being able to treat it as data, you’re really kind of at the whim of the other systems that are taking place around us and the structures that are existing as a result of that taking place. I think very similar to what Chris mentioned, with especially the rise of AI, we see a couple of different things. Iteration is incredibly fast-paced. Generation, or the ability to create things, is really democratised — whether it’s writing text, whether it’s generating code, that’s incredibly democratised. But on the flip side, it means that governance is even more important. How do we dictate, as a content function, the guardrails that we want to abide by? How do we ensure quality? Those types of things become only that much more important in a world where so many people have such powerful tools at volume in their own hands, in their own tool belts, and where that single source of truth and that systemisation just becomes incredibly powerful.

Patrick Stafford: [00:18:01] Dave, I see you nodding your head there in response to what Jess was saying. Do you have anything to add?

Dave Connis: [00:18:08] What if it’s just like a nervous tick and I just nod my head whenever somebody says a word?

Patrick Stafford: [00:18:13] Well, then I apologise, but I’d still like you to weigh in there.

Dave Connis: [00:18:16] Sure, sure, sure. Yeah. Okay. Panel, panel, panel. So, I was thinking about the fact that with LLMs and this idea of context — in order for an LLM to be powerful, it needs to have a ton of context. So much so that suddenly you start to think, well, where does this context come from? And that context is set by the company. It’s set by your organisation. So now you’re back to talking about data objects. Because what is your company outside of your main data objects? I mean, think about Airbnb. If they didn’t have trips, they wouldn’t exist. Trips is a data object in their system. So now you’re looking at, okay, what does it mean to define a trip? What is a trip at Airbnb? What is a transaction at PayPal? And those, I think, are the definitions now that are going to be providing context. And those are data. So how do we now look at getting concept and object definition into LLMs so that they can have these contexts? And I think that’s a very fascinating discussion, probably a completely different panel. But to the point of, you know, why now? It’s because we are now democratising the creation of everything. And suddenly when everybody can create, meaning matters more. So now you need to have a little bit more foundation in what are we actually saying and what are we working with. And that comes down to the concepts and the objects and the taxonomy and the ontology — blah, blah, blah, all the fancy -ology words. That’s what it comes down to. And I think that is where you start looking at, okay, how do we now get our definitions as a part of our deliverables more and more, because it’s going to be more and more important. So that’s why I would say why now.

Chris Greer: [00:20:17] Dave, I’m really curious for your perspective on whether you think some of the more qualitative aspects of writing can also be attached to those objects as part of the system, or the ontology or taxonomy or what have you. I’m thinking about things like tone. Do you think it’s possible to encode that in a system in such a way that an LLM could say, okay, this is an error message, I have this tone spectrum in my context that I can go reference and write accordingly? Or do you think that’s sort of the human element that can’t be replaced?

Dave Connis: [00:20:59] I don’t know. I think when you think about — so there’s JSON-LD, which is JSON Linked Data, I think, is the actual definition of it. But the idea is that you’re putting semantics — so meaning parameters — into objects. So if you think about APIs now, APIs are: what do they call, what do I get back when I get to them? Well, now, if APIs are the closest truth we have to a full object — the system’s objects — what does it look like then to start including meaning in our APIs? Well, if you call this object, not only these are the parameters that you get back, but this is what this thing means. And then that is what’s fuelling it. So could you add a tone to that? Potentially. It’s possible. You could probably add a parameter for anything. That’s my guess. Maybe Jess has some flavour there as a little bit more of the technical side.

Jess Ouyang: [00:22:06] Yeah, no, it’s a super interesting question. I think it’s been really exciting and interesting to observe. Like a feature we rolled out in Ditto in the last half year is style guides, which can take very many forms in terms of how people are using different rules. And then the AI will essentially be running in the background to enforce the adherence to the style guide. I think it’s really interesting because some of the rules that we’ve seen get created are very concrete. It can be like, do not use this language, instead use this terminology. And that’s more similar to, on the developer side, what you see as a linter — something that can pretty prescriptively detect text and then enforce it in a kind of find-and-replace type way. But I think we’ve also seen it ladder up a lot into exactly what you’re mentioning, Chris. Pretty open-ended judgment calls on how to actually enforce this. A lot of times that is voice and tone. Can be different types of things. I’ve seen people write things like — I guess this falls into the category of voice and tone — write directly, or write in a way that’s most delivering value to users. And I think to us, what that means, especially in the vein of content as data, is one, having enough systemisation there where you can continually build and improve on it. And a lot of that —

Jess Ouyang: [00:23:34] — a lot of times that means examples. Being able to provide examples of what is good, what is bad, continually being able to provide feedback for it — did this do a good job? Did this do a bad job? — as it encounters more and more edge cases and more applications. But also, I think that speaks to really the human element of a content designer that does need to take place. Ideally, content designers and design functions are in a position where they have a lot of leverage. They’re in that position where this is the domain that they own, and they’re the one assessing — this is adherence, this is a good example of this, this is a bad example of this. And also, here’s how I want to tweak my style guides. As opposed to being the one manually searching and finding for different types of things and writing out fixes for things. They’re kind of at a position where, with the right system, they’re essentially evaluating and being the experts that are providing inputs to these systems as well.

Patrick Stafford: [00:24:40] I think that’s a really great segue into our second question, which is: how do we actually move from static docs to systems? I think it’s really telling and interesting that the content designers who we’ve seen have more influence at the minute are those who are becoming more connected to engineering and dev teams. And I just saw a LinkedIn post the other day from a content designer — I’m sorry, I can’t remember who it was — but this person was saying the closer I’ve been connected to how the product is built, the earlier I’m brought in to decision-making. And so the answer to becoming involved — one of my lights went off, so I’ve become a little bit more dramatic looking — the answer to becoming involved is not to try and sort of exert influence through ham-fisted techniques of “I’m going to be in this meeting because I want to be here.” It’s becoming more involved with engineering and having more of a technical approach. And I think, as you’ve all just discussed, part of that involves creating systems that interlock with other parts of the product. The age of the static style guide, I think, is now over. We’re moving into something a bit more living. How can content designers move that process along? Open question to the group.

Chris Greer: [00:26:19] Yeah, that’s a good one. I think there’s something interesting here in that a lot of the old principles and best practices when it comes to governance and maintenance of these systems still apply. So if you have multiple style guides maintained in multiple places, you’re going to have the same issues with LLMs as you may have just with humans trying to reference those style guides and find the source of truth. So a lot of those things that we’ve learned over the years in terms of maintenance and upkeep of our standards still apply. I think the interesting thing now is that with some of these new technologies — like MCP servers, or web search, or tool calls, or whatever — agents can now go out and proactively access and fetch that context. And there’s lots of fancy architectures, which I’m sure Jess knows more about than me, but where you can use sub-agents to manage the context and just fetch a discrete piece of it and bring it back to manage your context window so that the LLM doesn’t get overwhelmed. And that seems to have been a lot of the technological development in the last few months, from what I’ve seen.

Chris Greer: [00:27:40] And I think what that means for content designers is that we need to think strategically about equipping agents with the tools that they need to go and fetch the relevant context for the given problem that they’re trying to solve. And then making sure that that context is up to date. So if you have an updated word in your terminology bank or whatever, but you forgot to update it, the LLM can only fetch that context and work off the information it has. It can’t infer that we talked about this in a meeting and forgot to write it down two weeks ago. So I think a lot of those maintenance practices still apply. What’s interesting now is that instead of being a static doc that people need to go to to get the information, instead we can sort of proactively distribute that context through agents and bring it to where people are working, which allows us to have a lot more influence and potentially a lot more partnerships — to your point, Patrick, with engineering or product or design or what have you.

Patrick Stafford: [00:28:47] Chris, Stripe is a famously engineering-heavy company. I’m wondering, what’s your feeling as to how content design is treated there, given everything that’s happening with AI? And I know there’s a big emphasis on agentic work at Stripe. How do you feel? Because one of the questions we get a lot of the time is, oh, if I work on these types of agentic systems, or creating content systems, am I going to lose my influence as a result? Because there’s some automation there.

Chris Greer: [00:29:20] Yeah, I think that’s a really good question. I think the short answer is no, because you still need that professional knowledge and judgment and taste and all the other things that make you a good content designer, to define those guidelines and those rules and things in the first place. It’s just the mechanism for which it’s distributed has changed. But, you know, garbage in, garbage out. You still need to have those really rigorous guidelines and things like that. Just because you’re making them available to an agent doesn’t necessarily change that fact. So that’s something that we’re exploring.

Dave Connis: [00:30:06] I think it’s interesting, Chris, what you said about a lot of the same principles are still true. Because when I was thinking about this question, that’s what I came to. I was like, it’s still the same stuff, just with a different flavour and a different application. And it’s going to look different for each company. So, you know, at OutSystems, a lot of our design system docs are on Confluence. So it’s not very sexy. It’s just not a sexy thing. So what does it look like for us to move from static to systems? Well, if we’re looking at an AI that is powering our docs — an LLM that’s going to power our docs — well, we need to be in Markdown. So for us it looks like we need to scale into Markdown and maybe do docs-as-code and maybe get some repos up and running and start changing our process. So for us it’s a little bit different than maybe for somebody else.

Dave Connis: [00:31:09] But the same is always true — we have to have governance of it. You can’t just let it kind of go. You have to have governance of agents. We’re doing a lot of stuff with agents for our product. We are letting people build their own agents in OutSystems. So you then have to ask all of these questions of, like, well, what does this then look like for us? And how do we use them well? And I think there’s two lenses. There’s the normal, traditional content lens of governance — have good guidelines. If you don’t have guidelines, make them. There’s that whole track. And then you have the track that is now kind of pivoting around the orbit of: what does it mean that machines are now going to become the number one reader of our documentation over humans? And that’s kind of the secondary lens. So I think the old stuff is still true. You just have to add the second layer on.

Patrick Stafford: [00:32:22] Jess, I was actually going to throw to you because something that Dave just touched on is the idea that every company and every organisation has their own constraints and their own existing systems. And I know you will have talked to many teams about how their systems or lack of system is set up. And I’m sure that you’ve seen a wide range of different sets of infrastructure put together. I think for a lot of content designers, a lot of them will think, oh, well, my organisation is set up like this, so I can’t do this or I can’t do it in this particular way. I’m wondering, do you have any advice or thoughts on people who are in this webinar thinking, well, this is good, but I mean, we don’t really have any infrastructure or I don’t even know where to start?

Jess Ouyang: [00:33:17] Very relevant question. Especially because a lot of these terms and things like that have their own barrier to entry. A lot of times people are intimidated by what at a high level sounds like a different way of packaging something that they feel is so near and dear to an expertise that they’ve developed. So definitely resonate with that a lot. I would say that, very similar to what Chris and Dave mentioned, take it one step at a time and build in the standards and governance at a layer at a time. If your team doesn’t have style guidelines, not even in a way that’s accessible to AI, but if it doesn’t have one that’s robust, reflective of what gets used — glossary, terminology guides, things like that — establish that first. Make sure that you’re clear on codifying what that means. Exactly to what Dave mentioned, the garbage in, garbage out. If your ad hoc human process isn’t working, then the same guardrails that you need to establish as a person apply to how you would then establish that for automation to kind of scale up. Maybe a level beyond that is making that type of standards and resourcing as accessible as possible to people and to other types of tooling. I think something that should be relieving for people to hear is that as tooling advances at an incredibly rapid pace, the ability for different types of human-readable formats to be ingested is continually expanding. And I think that makes it all the more important for teams to establish what are the systems that you use as a person. And pretty quickly — agents read PDFs, they read different types of things.

Jess Ouyang: [00:35:08] And it really comes down to how good those core aspects that you’ve developed as a team look. I think also to your point, that looks pretty different across teams. A lot of times it is really dependent on what types of business constraints you’re thinking of. Like financial services — they have to think a lot about compliance. Like health tech. We’ve seen all sorts of teams really bake what they’re thinking about as a business into the language that they’re using in their product. And I think that’s also why content is so core to the user experience. It’s so core to the products that we’re building — it is ultimately so specific to driving user experience and a successful experience, that makes it so important. So all to say that the work of one step at a time, codifying standards, centralising them, unifying them, will pay dividends. It doesn’t have to be all in one go. Whatever is most accessible and most helpful in that moment to yourself and to your team can get built on. And a system that really proactively surfaces these things is, of course, incredibly helpful for folks. But one step at a time.

Patrick Stafford: [00:36:29] Absolutely. I want to keep moving because I want to have time for questions. But this is a big question we’ve got here, which is: what does this mean for other teams? Chris, I want to pick up on something that you just mentioned before, which is about developers who are using AI at the minute. And there are a huge number of software developers now who aren’t even really looking at all of the code that they create. And that’s causing a bit of a crisis, I think, because for a lot of people who have spent their entire careers looking at every single line, this is now causing them to have some reflection on, you know, what is it that I actually do? Like, what’s my actual job? And I bring this up because the influence part, I think, is interesting here. We’ve talked about creating systems in order to do what? In order to just have nice content? In order to just have something that sounds nice to the user? I mean, yes, but also — it’s to facilitate, it’s to help other teams and to help the organisation as a whole create, build, ship good quality, faster. And so that, I think, means a tighter integration with engineering and other teams. But I’d love if anyone on the panel has some thoughts on moving from static docs to systems, to writing for AI, to thinking about treating content as data. What is all this for? And in terms of working with other teams, what does that mean?

Chris Greer: [00:38:15] Yeah, I can take the first stab at this one. It’s such an important question. I think, similar to the other thread around a lot of things staying the same, I think it does ultimately just come down to relationships with those other teams. And I think the nature of those relationships might change a bit, but I think like any relationship, it sort of depends on how you approach it. And it can be fruitful, or it could be perhaps annoying. Just one example — I’ve not opened Figma in weeks. My product design partner and I have just switched completely to building prototypes and working out of GitHub. And I’m just in Claude Code all day, using my UX writing skill that I put together to review the copy and help me speed things up. That’s cool, but it also creates a new way of working where we’re kind of figuring out together, like, how do we make sure our branches don’t have conflicts? And if you’re putting up a PR yourself — pull requests, I should say, in GitHub — maybe something you’re not used to doing. Maybe take a minute and research good PR etiquette. What should you put in the description of the PR so that it’s not just this big, annoying mess that your engineering partner now has to deal with, where you’ve changed 30,000 lines of code or something and you’re asking them to review it. So I think, like anything, it’s just learning about your partner’s ways of working and just being empathetic in that respect, and meeting them where they are. Because you’re also increasingly, I think, asking them to meet you where you are and be more involved in the process on the more technical side.

Patrick Stafford: [00:40:08] Dave, I know you’ll have thoughts on this, because I know in the past you’ve spoken about content design becoming more involved in working directly in code and becoming sort of more closely connected to that approach. What’s your response to what Chris just said?

Dave Connis: [00:40:31] Yeah, sorry, I’m trying to think. AI is thinking longer for a better answer. Anyone? It’s an AI joke. It’s fine. I’m just trying to think of what approach, how I want to approach it, because I know — I would imagine there’s a lot of people hearing Chris talk about PRs and working in GitHub and going like, oh my gosh, if I can’t work in GitHub, I’m toast. And while I think you should understand some aspect of Git and version control and trying to get into the more technical side of things, I think you can always be learning that and expanding that. I do think that there is going to continually be a place for people who just need somebody who’s good at words. So I’m trying to marry those two together in “what does this mean for other teams?” Because I know lots of engineers where I’ve had meetings with an engineer where I’ve been able to get on their technical level and talk about objects. Or, hey, let me just do that in the repo. And they appreciate that, and that’s what they need in that moment. And then there have been other engineers who don’t want me to be in the repo and who just want me to answer the word things. Just give me the words.

Dave Connis: [00:41:49] So I think there are two lenses to look at this. There’s the AI future lens — what does it mean for AI to be a part of this question and what is it not? And I think that there’s some foundational things for both answers. And it is always going to be: what does that person need? How can I best deliver value to that person? And I think, while I do think AI is going to continually push the need to the more technical side, I do think that there is going to be like — hey, we cannot generate a message that makes sense. It’s just not working. So we need somebody who makes sense. And I just think that you, as a good designer, as somebody who knows the language of the people they’re talking to — that’s always the case, right? You’re always trying to understand who is your audience. That’s a core tenet. That’s not going to change. And it’s just — you’re just adding a new audience member with a machine. Who is the audience? It’s a machine now. So you just kind of have to balance all of that. But yeah, I do think becoming more technical is a superpower. Jess, I saw you come off mute.

Jess Ouyang: [00:43:23] Yeah, it’s in the rotation. But I definitely resonate really strongly with both of you. That is going to be my line for this webinar. But I definitely agree. I think it’s really intimidating for a lot of folks in that — yes, AI has been developed by developers. A lot of times that results in developer tooling as kind of what has pushed forward first. But a lot of times, to me, what this boils down to for every role, not just content designers, is not that everyone’s moving to engineering, but that everyone is more empowered to move closer to business decisions and direct impact. And I think a lot of times people think about it as moving closer to code. That, of course, is where a lot of the tooling exists today. But ultimately, even engineers have to really think about — how do I make, now that I have so much leverage, how do I make decisions that are going to drive the business, the product forward? How do I drive our goals forward? Everyone is really close and working on that, as opposed to in silos doing their own thing, cranking things out. People are really close to the business logic, delivering value to what they want to deliver on these products, as opposed to kind of this mindset of, we need to start thinking as developers. I think everyone’s moving as close as possible to really the heart of the problem that they’re trying to solve. Hopefully people are bogged down less by the minutiae of the manual work that they’re doing.

Jess Ouyang: [00:44:54] And of course, it results in different types of changes. People likely have to be in more lockstep, because they’re working on a pretty similar problem together, as opposed to slices of different problems separately. I think it also means all the things that we’ve already referenced — a single source of truth is so much more important. That kind of thing. But I also think that it’ll be made more accessible to non-technical people in a pretty short amount of time. A lot of that tooling is oriented around developers right now. I think there will be more tooling and interfaces for people to essentially directly edit production as well. A lot of things — instead of having a waterfall of you make a doc, then you make a Figma, then you build it — a lot of people are just working directly on the product. But my prediction is also that it’s not going to be at a pull request level either. You’ll have more tooling to do exactly that to your product. It’ll be a lot more accessible to people. And yes, it might mean that there’s a lot of people working on the same thing. But I wouldn’t want people to worry about becoming developers, because of course, that is where a lot of the tooling is at right now.

Patrick Stafford: [00:46:20] Well, just to pick up on something you just said, Jess — being closer to the business decisions. When we can basically do anything and create anything with AI, taste and craft matters more. Because that’s your differentiator. It’s always mattered. But it matters even more now, which makes the job of craft people within the product even more important. So I think, you know, we’ve been very engineering-heavy this conversation. But I still think there is that relationship that remains and will still need to remain. And that leads us kind of into our last question before we take a couple of questions, which is: what can people in this webinar do today? Because this has all been very conceptual. And we’re talking about very difficult and complicated things about pull requests and GitHub and stuff that a lot of people may not even have access to or think about. But if we want to start treating content as data and prepare ourselves for this shift in the industry, what are one or two things that people can walk away and start doing immediately? I’ll open that up to anyone.

Dave Connis: [00:47:38] Being outside. That’s nice. That’s all.

Patrick Stafford: [00:47:44] Did you say being outside?

Dave Connis: [00:47:46] Yes. Touching grass. And looking at leaves.

Patrick Stafford: [00:47:50] Fresh air. Yep. That’s a good start.

Dave Connis: [00:47:54] Yeah. That’s good. Calling your mom. No, okay. I think — I do think there is so much value in trying to learn the foundations of the technical side. So that doesn’t mean you need to go be fluent in ten different — you don’t have to learn all of Python. You don’t have to learn… Yeah. So I think just understanding the basics of what is happening in the product development lifecycle. Understanding the language that your developers are using. Understanding the different phases of — what is an API? How does that work? What is actually happening? Like, again, a user interface is a place where systems meet. If you don’t understand those systems, you’re going to hit a ceiling in terms of how you’re going to be able to design for it. So understanding the systems at play that are actually going into the factors that you’re designing around. So maybe it’s just — I’m going to dip into JavaScript, I’m going to tell ChatGPT to make me a “teach me like I’m five” JavaScript course. You can do that now. Did it the other day with something, and it was awesome. It just walked me through it. So there’s tons of ways to do that. I would say JavaScript is a good place to start. I would say just understanding data systems and how things are working underneath the hood is a huge good place to start. Metadata. Understanding objects. All of that stuff will put you on a trajectory that will set you up really well for the future in terms of systems.

Chris Greer: [00:49:48] Yeah. Add to that, I really liked Jess’s point about still requiring that business logic and getting closer to the business side of things. I think that’s always been a bit of a superpower for content designers — if you can tie what you’re doing back to business objectives and user needs and all of that stuff. I don’t think that’s going away. I think it’s increasingly important because just because you can build something doesn’t mean that you should. Just because you can fire up Claude Code and push something to production doesn’t mean that you should. All the stuff that goes into those decisions is still tantamount. So I think doubling down on those skills — business skills, getting practice tying what you’re doing to metrics and being able to measure that, and making sure that the projects that you’re picking up — because if you’re like me and most content designers, there’s plenty to choose from, more than you could possibly do — try and focus on the ones that move the needle for the business. And really build out those chops, because I don’t think that’s going anywhere. And then if you do end up taking a more technical route, or maybe inversely, these things get easier to use, and you have expanded scope or influence, then ideally that’s more positive influence because you have those fundamentals in place already.

Jess Ouyang: [00:51:20] Yeah, definitely agree on that. I think the hope is that with better tooling, whether it’s AI or different types of tools, you’re freed up away from the manual work and you have more time to do what is driving the business forward and what you’re really great at as a content designer. And what I would personally push for is, of course, the tooling piece to make that happen. But being able to build all of the context of a great designer — understand how users are really using your product, understand what the business drivers are, understand where you think things are breaking down in the language and the product that you have. I would say, similar to what we were talking about earlier, revisiting your standards is a really great one. Teams that have weak standards result in weak governance. It’s really hard for that to be a really solid foundation to build on top of, especially as things move faster. So that’s one that I think pays a lot of dividends. And outside of touching grass and going outside, which I’m a big plus one to, I would say that, of course, my personal bias is that Ditto can help. We care a lot about it. It’s super interesting to me personally in terms of how teams are codifying different types of things, like style guides, making sure that it’s really easy to get up and running too. So it’s my one personal plug for this webinar — if that’s top of mind for you, happy to flesh that out on the Ditto side as you’re tooling, if things like Claude Code are intimidating or might have a barrier to entry on your own team.

Patrick Stafford: [00:53:10] Awesome. We have time for a couple of questions. Before we do that, I just want to add one thing in terms of the practical nature of what you can go and do today. Go and find out where your strings live in your product. Where do they actually live? Go into some sort of prototyping tool, whether that’s Claude Code or something else. Build out a prototype of something, a very simple app, and then replicate — ask it to replicate how strings are managed in your own product. So you can then understand how you can actually go and edit things on your own. And figure out how to actually go and practice that in a setting where you’re not having to ask engineers for access and things — you can do it on your own. I’ve been building prototypes, and I basically just asked it, okay, I want to manage all the strings in JSON. So just create a master JSON file where I can edit all the strings for me. So experiment with different ways of doing that. It can help you become a little bit more technical. We have some questions here, and not a lot of time, so I’m going to move on very quickly. One question from Nick, who says: I appreciate that content as data predates AI, but does using AI as a booster or amplifier for that concept risk damaging its credibility if the AI bubble bursts? So I think we’re all pretty aware that we’re in a massive hype cycle in tech right now. There’s one every few years. And none of us know if that hype cycle is going to continue or diminish or whatever. So does attaching our work to this diminish it in case things go south?

Dave Connis: [00:55:03] Diminish the concept, or the content as data idea?

Patrick Stafford: [00:55:07] I should say that was my word. His actual question was: does using AI as a booster or amplifier for the concept of content as data risk damaging its credibility if the AI bubble bursts?

Chris Greer: [00:55:25] I don’t know about the AI bubble, because I think none of us can know whether that’s going to happen or not. I think we’ll probably have other things to worry about if that is the case, that are maybe more pressing. But I do think there is some risk there in that, if you treat content as data, one of the promises of what we’ve been alluding to is that you can have some sort of automated governance because you’ve beefed up your system, and you have a way of linting or checking the content as it goes out to make sure it’s compliant, and so on. But if you are not doing a sufficient job of checking, or maybe the evaluations that you did when you were setting up weren’t quite right, what you’ve essentially done is make it easier to ship more that is worse. So that governance aspect should not be understated, because if you build the tooling and you build the systems where content can be directly manipulated and distributed, and it’s less of a cumbersome process, but you don’t have that governance or those safeguards in place — you could be shipping a lot of bad stuff more quickly. Which wouldn’t be good. So I think that’s one note of caution, and I think that’s why it’s so important to make sure that your guidelines are really robust and that you are figuring out how to test the outputs of these systems. If the bubble bursts, I still feel like it’s good to have some part of that tooling where maybe you can measure egregious typos or something like that, and just have a way to visualise that and go chase it down. So I don’t think it would be wasted work, per se. But yeah, maybe not our biggest problem if the bubble bursts.

Patrick Stafford: [00:57:11] Yeah, I think we have other problems. But as you said before, you shouldn’t just do something because you can. You need to have that business logic and that sense in there of what you’re doing. Good answer. We have time for one more, and I think this is an interesting one. So, to the point in the chat: does all this leave any room for traditional design work, where content designers work closely with product designers on problems and solutions, versus serving agents with stuff to put in designs that are made by someone? So I guess the question is, we’re talking more about moving towards content as data. Does this leave any room for the craft?

Chris Greer: [00:58:02] I think it absolutely does. Like, my favourite part of being a content designer is pair designing with my product design partner. We used to sit down in the mornings and open up Figma and just jam on problems together. Now we’re opening up GitHub and jamming on those same problems and looking at the prototype instead. I don’t think the tooling changes that aspect of the professional that much for me.

Dave Connis: [00:58:32] Yeah, I would agree. There’s always going to be space for somebody who is good at something. There’s a reason that you were hired. It’s because you have good taste and you’re good at your craft. So there’s always going to be space for that. I think the fear — I understand the fear. There is going to be space for that. And I think we have to hold that in tension with this idea of the shift. These things, they can both exist. And they’re going to be at tension at times. And one might have to give to the other at times. And that’s okay. Daniel Tiger — my two-year-old’s favourite show — says you can feel two feelings at the same time, and it’s okay. So I’m going to say that’s credible evidence.

Patrick Stafford: [00:59:30] Your feelings are valid. Thank you, Dave, for that validation. Which brings us to the end of today. We’re on the hour. So, like any good show or presentation, we end with a moral — a Daniel Tiger quote. Thank you, Dave, for bringing that home for us. I want to thank you all — Jess from Ditto, Dave from OutSystems, Chris from Stripe. Thank you all for joining today. I think this has been really educational and a great experience for people. I think people have learned a lot. I’ll just point out that if you are interested in turning your static docs into systems, you can check out Ditto. And if you’re interested in a demo, you can get started at dittowords.com. And there’s some exciting stuff happening at Ditto, some neat things. So keep checking it out. I think there’s some interesting things coming. Let’s put it there. All right. Thank you, everyone, for joining. We will send out this recording to everyone. And I know some people had to drop off. And we’ll follow up. So thank you all for coming. Again, panelists, thank you very much. And hopefully we’ll see you all again at our next discussion, whenever that may be. Thank you, everyone. Have a great day.

Jess Ouyang: [01:00:56] Thanks, everyone.