Chris Strahl: Content in Design Systems – Episode 110

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Google Podcasts | Stitcher | TuneIn | RSS

In just a few short years, design systems have been adopted by most digital organizations.

These systems free designers from many mundane design-production details, letting them focus on the creative aspects of their work.

To this point, content has been an afterthought in many of these systems. Chris Strahl sees that changing in the next few years and predicts that content concerns will assume an important place in design systems.

We talked about:

• the origin story of his design-system startup, Knapsack, a SaaS platform that helps designers and engineers collaborate better
• the origins of design systems, going all the way back to Christopher Alexander’s book on architectural design patterns
• his breakdown of the elements of a design system: asset libraries, component libraries, the documentation of the system, and the actual delivery of code to production systems
• some of the benefits of design systems, in particular the way they encourage empathy for enterprise users
• different ways that you might work with content in a design system
• levels of maturity and sophistication in design systems
• the unfortunate tertiary role of content in many design systems, behind design and code
• how adopting a design system is like going from waterfall to agile
• how discovering and using content patterns in a design system could help with things like personalization
• the importance of structured data in incorporating content into design systems
• the ongoing movement of content from monolithic storage and use to more of a content-as-a-service model
• the ongoing breakdown of old publishing models
• the convergence of content, design, and code issues in activities like localization
• the future he sees “where people are actually building with design systems and thinking about the rules and structure and intent of content as a part of that building process”

Chris’ bio

Chris Strahl is the CEO of design-system-as-a-service startup Knapsack. He’s a seasoned startup executive, entrepreneur, sales leader, and management consultant with a founder exit under his belt. As the CEO and founder of design system consultancy Basalt, Strahl gained experience building design systems for enterprise clients — and built Knapsack’s revolutionary product along the way.

Connect with Chris online

• LinkedIn
• Twitter
• The Design Systems Podcast

Video

Here’s the video version of our conversation:

Podcast intro transcript

This is the Content Strategy Insights podcast, episode number 110. It’s unusual nowadays to find design teams building one-off mock-ups of new digital products. Most modern design organizations use a design system that helps them follow well-established patterns, reuse code components, and create consistent user interfaces. To this point, the role of content has been an afterthought in many of these systems. Chris Strahl sees that changing in the next few years and predicts that content will assume an important place in design systems.

Interview transcript

Larry:
Hey, everyone. Welcome to episode number 110 of the ‎Content Strategy Insights podcast. I’m really happy today to have with us, Chris Strahl. Chris is the CEO and co-founder of Knapsack Design System software platform, I guess, we’d call it. Welcome Chris. Tell the folks more about yourself and what you do there at Knapsack.

Chris:
Yeah, so we founded Knapsack a little over a year ago. It came out of an agency that was focused on doing a lot of custom or DIY design systems for big companies. And so, we been working in this space for about three years, building design system platforms out of individual pieces, things like storybook or pattern lab or envision tools and mixing them together into these custom workspaces. And we saw a need in the market that was pretty exciting for us. And so, we built a SaaS platform to kind of create this common workspace for design and engineering, to collaborate around building patterns.

Larry:
Nice. The way you just said that, it’s a perfect explanation of a design system, but a lot of my… I don’t know this exactly but my audience is content strategist, and I think there’s probably a lot of people who are super familiar, probably as familiar as you and I with design systems but I have a lot of folks who aren’t. So, could you just kind of walk through what a design system is? Sort of the origin story of the system because it’s a fairly new idea.

Chris:
Yeah. It’s actually kind of like a new implementation of an old idea, which is pretty common for the technology space. A lot of this started with physical design way back in the day, this guy, Christopher Alexander looked at patterns in architecture and in the physical world and understood that most homes and buildings were built out of the same 200-ish patterns, I think. Things like windows, doors, sinks, bathrooms, living rooms, roofs, that sort of stuff. And this got applied in the web context in a lot of the early days of the internet with site building tools and the original note code platforms like, DreamWeaver and stuff like that used to have a bunch of kind of pattern-like concepts in them. But really a lot of that was very difficult to do because modern design systems sort of necessitate you to be a craft person while also at the same time, understanding that pages are constructed of component parts. And it was really Brad Frost book about Atomic Design, that kind of solidified that as epic in the modern world of web design.

Chris:
We kind of think about a design system is broken into four parts. We think about it as a design asset library. So, that’s like all of your paper files or sketch files or XD files that are organized around modular encapsulated bits of UI cards, buttons, heroes, snaps those sorts of things. Then you have your component library, which is more on the engineering side, which is the representation of that code as rendered HTML or CSS, or if you’re using a native app, whatever native app platform you’re using. And that represents those modular encapsulated bits of UI that exist independent of their content or their business logic.

Chris:
And then there’s the documentation about these things. So where do these come from? What’s the intent of them? How do you use them? What are the right variations to think about in the right context? All the other bits about sort of the service model attached to the design system and then last but not least, there’s actually how you consume it. The delivery of the code. We’re really fond at Knapsack of saying that a lot of the design tools are really great for original creation, but ultimately users don’t look at Figma files when they go and use a website, they look at code interpreted by a web browser. So, you need some way of getting that code into the production applications that ultimately consume the design system.

Larry:
Right. So, it’s a way to organize all of this because this has been going on for years but it’s just better articulated, it sounds like now and better managed in how it all comes together.

Chris:
Yeah. And it’s also enabled by a lot of, sort of modern movements in the web. The idea of using JSON and schema definitions to define variants and props and children and slots and all these other sorts of things that exist inside of modern web frameworks. And really JavaScript also helped enable that, can’t forget the rise of things like React. And I think there’s also a lot with the decoupling of content and display. You used to always have these huge monolithic CMSs. I used to work a lot in Drupal and Drupal was predominantly a monolith, even though in the later time when I was working there, we were constantly trying to tease that apart into being more like a content service than an actual content management platform. And so having the idea that UI should be distinct and independent from the content you put inside of it and the business logic that ultimately impacts that content or that UIs behavior.

Larry:
And that’s where it really gets into my audience’s interests, I think, is that that overlap or intersection of the content management systems and design systems. You mentioned a couple minutes ago, the four main parts of a design system, you see. One of them is documentation, so there’s a documentation of the design system itself, but then there’s also the content, the strings and other content associated with the digital products themselves. Tell me about, from your perspective as an old-school content person and watching this evolution, how do you see that all unfolding now?

Chris:
I mean there’s some really obvious places where things are helpful. The ability to take things like strings that you would see in an application, the text of buttons, headers, navigation, those sorts of things and make those actual components in a design system that have different options. And you could see lots of really cool things for translation and localization attached to that kind of work. Likewise, legal teams and the ability to control legal language inside of a design system is a really powerful thing. But really all this relates back to what is the most empathetic way to build a system that people are actually going to be able to adopt and understand. Design systems are unique in the idea that their products that serve other products and so very often the people that are building the design system are not the people that are actually implementing the design system or consuming it in an end product.

Chris:
And so the ability to create content, which really is predominantly sampled data that exists within the design system that best mirrors, what it will look like in production, is really an empathetic thing to do. If you think about it, the creators of a design system, their users are usually other people inside of their organization that then have to consume their product. And so the closer that they’re able to make that look and feel like the end product, oftentimes through image assets or other bits of content, the better off they’re going to be.

Larry:
Right. So especially, I think I’m thinking of sites with a lot of user generated content. That would be a real interesting problem because, or not problem, but an issue because you have so much content to work with. But in other places you just have sort of… I mean, at some places you might be working with the actual content that would display in the interface. Can you talk about that spectrum a little bit from bespoke to completely . . .?

Chris:
Yeah. I mean, if you’re looking at a really cool system, which we’ve built a couple of times with Knapsack is this idea of how do I connect my component library and my design asset library to a Restful API that is pulling in content from some external system and populating your design system with real, true production content, be that UGC or be that some sort of curated asset management system. This is really enabled by applications like Contentful, where it’s content as a service in a real sense and you’re able to sort of slice and dice and pull that content as JSON very easily into a design system context, that’s one end. Where you’re getting your actual production content in your design system and all the things like dynamic data and all that, all show up the way that you would expect them to. And so that in that case is sample content that is extremely close to production content. Then there’s sort of the other end of that spectrum, which I guess be like Lorem and I think that Lorem and Unsplash gets you at least an illustration of the right direction. But, if you think about the purpose here, it’s about expressing intent and the best expression of intent is what’s actually closest to the reality a user will experience.

Larry:
Right. How does that work with the design system? When you’re working with clients and I know Knapsack is almost, if not unique, one of the first entries in this. So I’m just, I don’t know that there are standards in this kind of software industry yet about how you do that, but talk a little bit about how you would work with a client at either end of that spectrum.

Chris:
Right. So I guess for people that have a much more mature way of thinking about how content works in their design system, those people tend to also have, by nature, much more mature design systems. And so they usually have thought about a design system as being something more than a library of components. They’ve thought about the contribution model, they thought about the decision making model. They thought about the workflow, that things need to go through to get into the design system, how that design system is changed and how those changes roll out to production applications. And so very often for us in Knapsack that’s a much easier sort of implementation, where we’re mostly spending our time wiring things up, connecting to the right code repos, connecting to the right design libraries and connecting to the right content services.

Chris:
On the other side of things, very often, those people are just getting started with a design system or don’t have a lot of experience with what design systems are. Almost everybody these days has something, right? Somebody has some components somewhere, and somebody has a well-structured design file or art board somewhere but oftentimes they need a lot of help connecting those things. And I think unfortunately content tends to be at the bottom of the stack in terms of priority for that stuff. People are so eager to get their design and code into the same place, that thinking about that empathetic content is oftentimes tertiary.

Chris:
The only other thing I think is interesting there is, in cases like that, we tend to have a very different starting point. We tend to start with principles and we start to think about the content of the design system itself. Why do you have a design system? Why do you use it? What is its purpose? How’s this intended to foster collaboration and trust through your team? What are the principles that this design system will achieve if it’s a successful product inside of your organization? And that kind of content has its own needs, its own strategy and its own kind of purpose in fulfilling the design system’s promise.

Larry:
I’m guessing from this last couple minutes, you just talking that the more mature organizations that principle’s articulation is just almost pro forma just filling the blanks kind of thing but whereas a less mature organization, do you have to do a lot of handholding and extraction of those principles or helping them articulate them?

Chris:
Yeah, certainly. And so you think about the pioneers in our industry, right? Things like Google Material and [Salesforce’s] Lightning and all of these other design systems that are out there. IBM’s Carbon that are these well established things. They’ve had a lot of time to spend thinking about and refining their content and a lot of organizational muscle memory attached to how you think about building with design systems. I mean, design systems aren’t just like, here’s a little tweak to your process. It’s very similar to going from waterfall to agile is how we describe it, where it’s a very different way about thinking about how you build an application, instead of saying, “Alright, let’s get a list of requirements and start making comps.” It’s like, “Let’s look at the patterns that we have and see how the patterns that we have fulfill these user needs that we’ve identified.” And you start with your patterns before you ever start thinking about what you create that’s original.

Chris:
And I would love to see that extension, in the content sphere someday of, hey, we have all this wonderful content that represents these needs for users. What are ways that we can take that content and similarly, think about the patterns inside of our content before we think about how we create something new?

Larry:
Have you seen examples of that yet? Or you clearly have thoughts about it? Tell me more about how we can identify and use those content patterns.

Chris:
Yeah. I think a lot of this has to do with personalization and that’s probably where we’ve seen it the most. Websites are trying to get more personal with the way they interact with users, trying to think about the content that is meaningful to a user within a context. So if you think about a healthcare application, you want to know probably about the things that you’ve been diagnosed with or the bills for these services that you’ve been rendered or the information about the physician that you’ve chosen or the medical procedure or medical office that you need to go to. All those represent opportunities for personalization of content inside of a system that would be a healthcare application. All of those also have structured data behind them. You have structured data about the content of a physician, a procedure, a diagnosis, a bill, all of those things that ultimately can maintain and build a similar structure to how we think about a component in a system or a piece of UI. There is probably some three plus year convergence horizon, where you start to see those systems rally around that same structured data. And it probably starts with the ability to pull in personalized content based on the context of a UI.

Larry:
Well, I know that there are some forward-thinking like content agencies who are doing stuff around that now, and enterprises doing that kind of thing now. And this three year convergence that you see coming is that… Because in those cases, those almost always come down to aligning the purpose of the content with the intent of the user and kind of meshing those in some way. And that’s more kind of in the actual delivery of the content, but you’re talking – we’re back up a couple levels in terms of the design. Tell me how that manifests in a design system.

Chris:
Well, it is all about the structure of the data, right? I think that the only place that you really see that sort of data structure really commonly – and I’m sure your listeners are going to just be groaning at this – is within digital asset management. Images have a lot of metadata attached to them. Audio files, video files have a lot of metadata attached to them and all of that structural data helps you understand the patterns that reside within that data and how you might actually want to present those to users in a similar way. This is all about patterns, and what is a pattern fundamentally? It’s a reasonable solution to a commonly recurring problem. And so if you have a commonly recurring user need for a particular type or kind of content, you can use that structured data to infer what content might be valuable to a user. And so that is a type of content pattern that you could see. What form it takes or what medium it takes, I still think that’s very much TBD, but the data that has the most structure is the one that fits best within the context of a pattern system.

Larry:
A lot of this is now reminding… You used the word decoupled a couple times earlier and a lot of this seems to be about the recoupling of whether it’s pretty high-level conceptual stuff. Some of this really makes my brain hurt sometimes, because especially when you get to this sort of pattern level rather than individual-instance level, but is that a concept that’s always kind of at the forefront in here that a notion of decoupled-ness and stitching things back together?

Chris:
Yeah. I always kind of think about it potentially an oversimplified system where you think about a three legged stool, that is an application. You have the business logic, the backend logic of an app. You have the content and you have the front end, the UI. And so between those three things, you glue those together in some form and you have a digital application. For a long time, we’ve had microservices. Microservices predominantly represent backend things. I need to charge somebody’s credit card and I need to go retrieve their billing amount from a billing system. I need to go perform this mathematical operation to find out what their loan payment is. Those are predominantly service based things. Content has been moving in that direction for a decade or so. This idea of, I don’t want this monolith where everything is tied together.

Chris:
I want my content as a service and I want structured data to give me back content that is relevant to the API call that I’m making. And I mean, there’s entire companies built around that. I mentioned Contentful earlier. There’s a bunch of digital asset management companies that also do very similar things. What we’ve never had before is that sort of ability inside of front end. And this starts to get into kind of woo-woo land of front end as a service, but that’s kind of what design systems are driving at. This idea of structured data to find your UI and you’re able to use an API to retrieve variants of UI based upon what you want out of that API call. And so, yeah, it is a decoupling, recoupling but it’s not a monolith anymore. It’s a set of interconnected services and I think that’s a really important difference because now you can evolve each of them independently instead of having to wait for the next version of WordPress or Drupal or Sitecore, whatever. You have the ability to advance your content discipline independent of your business logic and independent of your UI.

Larry:
Right. I mean, that’s the whole… Like you said, the last 10 years or so, the evolution of content to be increasingly decoupled and the rise of headless CMSs and whole new content platforms that…

Chris:
Yeah. I mean, look at the power of Gatsby and Sanity and Netlify and all these things that are out there now. People eat that up because it’s suddenly something that you’re not blocked on a backend developer or a UI developer or whatever to start to put your content in a system. And that content can evolve and change independent of how far along the site design is.

Larry:
Yeah. And I think you are, just to articulate what some people call the Jamstack that decoupled, as opposed to… I think of this as the difference between content as publication and content as a service where instead of serving up templates, you’re serving up API endpoints to grab content from. And that changes your audience though too, because instead of serving, it decouples you from that end user in the sense that you’re really designing APIs, so the developers can get what they need to, like you just said, have that front-end as a service model.

Chris:
Yeah. People are realizing that web pages aren’t posters that you can grab the corner of and resize. They’re, in a medium and in a format that is fundamentally different than anything else that we have. And so a lot of these ideas that we took from print about publication or about how a website is just a magazine and each page is a different part of that magazine, all of those systems are starting to break down. That point of view is starting to become, I wouldn’t say irrelevant, but substantially less emphasized than the model of, you have a store of data, that data has structure to it and that data has meaning in a context. And it’s all about how you take that intent, that context and that meaning and you stick those things together.

Chris:
And that’s a much more powerful sort of way of thinking about the web as a new medium than what we’ve really been thinking about for, and this is happening in the design too. We’re not seeing page comps anymore. You’re seeing component comps or even better, you’re seeing fewer comps at all. You’re seeing a lot of original creation happen in design tools, but you’re not seeing people making giant sticker sheets of buttons. There’s a lot of people that went to a very expensive art school for a very long period of time and their job is essentially production inside of a big enterprise. And moving away from that production mindset into the mindset of, let’s all define systems and rules and structured data together that we can leverage so that nobody ever has to make another button or another hero or another card. I assume in the content space, nobody wants to ever have to realize that it’s “okay” or “confirm” or “cancel” anymore that goes into those buttons.

Larry:
No, the way you just described that too, it’s like we haven’t really talked about the benefits of a design system, but you just articulated one of the main ones, which is that it frees you up from those tedious production tasks to do more creative work and that’s going to apply equally to designers and content designers, I’m going to guess.

Chris:
Yeah. I mean, you get things in the medium that they’re destined for. Design tools are great, you need some place where you can start with a blank canvas and you can click on one part of that canvas and draw a box, because you can’t do that in code yet, that doesn’t exist in VS code and for good reason. But once you actually have the initial concepts and the rules and the ideas of what that design intent should be, those should be expressed as code. And then get that into that code medium because that’s ultimately what a user sees in a browser. And I think likewise in content, right? Whether you’re doing something in Microsoft Word or Contentful, it doesn’t really matter as long as you’re able to get it into a production site and actually see it in the medium its destined for much, much earlier in the process. And that’s where this convergence is really happening, is the idea that getting things into the right medium, more quickly in the process is what people want because it represents the reality of what a user consumes.

Larry:
Yeah. But there’s a difference between what you’re saying and WYSIWYG, right?

Chris:
Sure, right. Yeah. And I think that WYSIWYG in the web is thankfully also starting to be one of those things that we don’t talk as much about. How many break points, at what widths, at what fluid media query does what is? Something that people are realizing that the web is a very fluid thing and very dynamic in how it displays things. You cannot possibly account for all devices and screen widths and configurations of people’s systems, say nothing about assistive technology. And so thinking about the web as a much more fluid thing than a poster where you’re dragging blocks onto a screen and typing text, you need to think about all those edge cases. And that’s where a lot of the details are in the way that we produce the modern web.

Larry:
And as you say that you’re reminding me that one of the challenges that comes up all the time as just as content practice advances is bringing so many content creators and the content authors are used to that old linear, WYSIWYG model and creating content for these new decoupled systems is different. And I’m just wondering how design systems can help with that transition for folks.

Chris:
I think one of my favorite content examples is when you think about a card, and you have a headline under an image in a card and that looks really good with a single English word in it, it’s not particularly long, maybe a dozen characters, 20 at the most. And then all of a sudden somebody localizes it to German and instead of 20 characters, that word is 45 characters. And now all of a sudden you’re either overflowing your card or you’re creating this weird, mid-word wrap inside of your headline text under your image. Now that’s a design problem, but that’s also a content problem. And ultimately both of those things converge into a code problem. And so where a design system really helps you with that is the ability to understand before you ever end up in a production environment where you’re then sending to some poor team in Germany to localize, you can basically say, “I understand that if I’m creating a headline that exceeds some particular width, that I won’t actually reduce the size of that headline, so that it all fits in one space.” And that’s a very good example I think of a multifaceted problem that impacts content, it impacts design and ultimately it impacts the way that you engineer that card component.

Larry:
Yeah. It’s also the kind of thing that’s not trivially easy, but quite easy to do in a design system to say oh… And you could even have, “Okay, what’s my edge case localization scenario?” And just show me that and then you deal with it then rather than, like you said, when you get to production.

Chris:
Right. And I’m cherry picking a small example, but I think that applies in a broadly complex scenario too. Something like right-to-left, or something like an aesthetic that works in China or Japan versus an aesthetic that works in Mexico or Latin America. Just the concepts of spacing there are vastly different, let alone the way that people actually look at content. And so localization is a huge opportunity for the value of design system to shine through both in terms of design itself, as well as the content you put into the system.

Larry:
Hey Chris, I can’t believe that we’re already coming up close to time and I could always talk forever, but I want to make sure before we wrap up, is there anything last, anything that’s come up in the conversation or that’s just on your mind that you want to make sure we share?

Chris:
So I think one of the things that is really interesting is sort of this, what is a modern CMS question? We joke all the time at Knapsack like, “Wow, we’re one step away from a new kind of CMS,” because if you’re able to take the endpoint renderings of HTML and CSS in a design system that have a bunch of sample content in them. Now, all of a sudden you have HTML and CSS with content in them that is viewable as a webpage. That’s very nearly a production thing. You just need some server to stick that on and you could serve that page. So I do think that there is a future here, where people are actually building with design systems and thinking about the rules and structure and intent of content as a part of that building process and perhaps even backend development. And so it sort of remains to be seen, but there’s an interesting, at least academic exercise of, is the next iteration of a CMS really about patterns, and if it is a pattern-driven system, how do we think about building content, design, code, and services that fit within that pattern framework?

Larry:
Yeah. That’s a super interesting future to contemplate. I can’t wait to. I’ll definitely be following you to watch this unfold because I assume, is your intent to lead the way on that?

Chris:
Yeah. I mean, we’ll see. I think one of the wonderful things about a startup company is you get to do a lot of experiments because you’re trying to find out what works and what people gravitate towards while at the same time, getting people to see the vision of your future state. Right now, our future is design systems, but the really interesting stuff comes after a design system is broadly adopted. Things like analytics and data and the ability to use that data to help you make decisions about design or code. There’s a huge wide open field here that is this step change in the way that we think about building the web. And I think design systems are a really great next step in that.

Larry:
Nice. Well, I’m excited to watch how all this unfolds. Well, thanks so much Chris. Oh, one very last thing. What’s the best way for folks to stay in touch? Do you have a social media account or . . . ?

Chris:
Yeah, you can track me down on LinkedIn. It’s just in/ChrisStrahl and then @ChrisStrahl on Twitter. Always love to hear comments and then of course you can also listen to our podcast about design systems at The Design Systems Podcast.

Larry:
Absolutely. And I’ll link to all that stuff in the show notes as well. Well, thanks so much Chris, really enjoyed the conversation.

Chris:
Awesome. Hey Larry, really appreciate you having me on wonderful show and look forward to talking to you again soon.

Larry:
Likewise…