Episode #183 Karen McGrane - Integrating Content Strategy into Your Design Process
In any website, there’s a lot of thought that goes into the visual design. But a great visual design is worthless if the site isn't useful. If the content is confusing, poorly constructed, or even just missing, your users are going to have a horrible experience. Karen McGrane suggests the solution was once much simpler. You'd determine your content, stick it into your design, and never worry about it again. With the web changing as drastically as it has over the past few years, content can no longer be static.
In any website, there’s a lot of thought that goes into the visual design. But a great visual design is worthless if the site isn't useful. If the content is confusing, poorly constructed, or even just missing, your users are going to have a horrible experience.
Karen McGrane suggests the solution was once much simpler. You'd determine your content, stick it into your design, and never worry about it again. With the web changing as drastically as it has over the past few years, content can no longer be static. As technologies change and web accessibility arrives on more platforms, it seems as though content is on the back burner.
Karen says good content strategy can solve problems a redesign can’t.
In this podcast, Karen joins Jared Spool for an in depth discussion about content strategy. You can also check out Karen’s daylong workshop from User Interface 17, now in our All You Can Learn Library.
Jared Spool: Welcome everyone to another episode of the SpoolCast. You guys are in for a treat today because I have the wonderful, the amazing, the dashing, the gorgeous Karen McGrane with us today. She's going to be teaching a full day workshop at the User Interface 17 conference, "Content Strategy for Designers," which I'm really excited to go to and to hear. I'm very happy she's joining us from beautiful New York City.
Karen, how are you doing?
Karen McGrane: I'd doing fantastic, especially with you buttering me up like that at the start of the call.
Jared: Oh, you bet. I actually only tapped into your amazing superpowers, but yeah. I'm really excited about User Interface 17 and really glad that you're on the program. It was a wonderful moment when you agreed to do this workshop because I think that content strategy is something that has been almost...I want to say not ignored. That's not quite the right phrase, but just not given the attention it needs because we've been so...
I think, personally, we've been so focused on just getting the pixels in the right places at the right times and figuring out the changing technology platforms that, in my mind, the content was the one thing that felt like it was staying the same so we didn't have to worry about it. And then we got in this habit of not thinking about it.
And then, well, I think bad things started to happen, don't you?
Karen: The web changed a lot. I remember when I got started doing this and you're right. It was like all we were doing was building these essentially very static, almost brochure like websites. And so, you had the luxury of saying, "Great, let's figure out the content and then we'll just stick it in there and we won't have to worry about that anymore because it's almost like we're printing it on paper."
The technology challenges of figuring out how do you build all these platforms? How do you code this up? How do you make the design decisions? Did seem like they were more pressing.
And then the web changed around us. All of a sudden, we woke up one day and we had cheap content-management systems. We had a variety of other types of platforms to get stuff on the web. And all of a sudden, the sheer volume of how much things changed and how much things needed to change and all the processes around the content, you realize, "Oh, wait a minute, we haven't put any thought into this at all." So I can see how one day everyone woke up and went, "Oh, right! The content."
Jared: Yeah. I was first really brought into the importance of content in the middle of a usability study we were doing. We were studying the Wal-Mart website against an electronics retailer called Crutchfield, and we were comparing the two sites. It was stunning in the differences, because we would watch people buy products. In this particular study, they were buying things that they actually wanted to buy.
So these were people making real purchases, not fake stuff on our behalf but making real, decisive purchases for what they were doing. And Wal-Mart had, for all of its products, basically used whatever content the manufacturer of the product gave them. So sometimes it was short. Sometimes it was long. Sometimes it had important details.
I remember one person shopping for the lightest-weight laptop they could get. And Toshiba made, at the time, the lightest-weight laptop, and Wal-Mart sold that laptop, but they couldn't figure out how much it weighed. They could figure out how much it weighed in the shipping box. And this was the big selling point of this laptop was it was the lightest one ever made, and it never said the weight, right?
Whereas Crutchfield, their website--and I believe it's still true today--they personally write all the product descriptions. They don't just take what the manufacturer gives them. They play with the products they sell and then they write up descriptions of what's awesome about the products and what it's good for and what it's not good for.
When we watch shoppers shop, people spent 237 percent more money on those Crutchfield purchases than they spent on the Wal-Mart purchases. The same products. They were buying more and they were taking more out of it. It was 100 percent because of these incredible product descriptions that the Crutchfield site had put on there.
This was really the first time I had turned my attention from the mechanics of buying to what do you need to know to buy a piece of electronics. You need a lot of good content that describes what's going on.
Karen: Yes, and then you need an internal process that will allow you to create and manage and maintain that content. And you need buy in from the rest of your organization that the investment that you put into creating great digital content is worth it. That it's not always enough to say, "Oh, let's just recycle whatever content we get from the manufacturer," or, "Oh, yeah. We can just put up a PDF of the brochure. That will be good enough."
Jared: Right. I mean that was what really struck me, was that it was clear how hard the Crutchfield people had worked on that content. And that they had worked on the content as much, if not more, than they worked on the actual mechanics of the website. It was clear that the Wal-Mart people were really trying to cut a corner here.
One could give them the excuse because Crutchfield is very careful about having a smaller number of products to sell because they want to be able to do this with every product they sell, whereas Wal-Mart wants to have as many different choices for the customer as possible, at which point they could justify, "Well, it's just impractical for us to do all this."
But people weren't spending the money on Wal-Mart, so I'm wondering if, in fact...And this was true of other retailers, like Best Buy and Amazon, too. They were not getting nearly the size of the sales that Crutchfield was getting. So it wasn't just Wal-Mart stigma.
I think that there really is something to say that when you have really carefully thought through content, you can actually dramatically increase the results of your business.
Karen: Absolutely. And I think some of my love for content strategy in this day and age is, in a sense, acknowledging that in many situations a redesign is not the answer. I've talked to clients all the time where they're like, "Yeah, we're not really seeing the traffic that we want to see so we're thinking we're going to redesign our home page."
I think that gets to this unspoken belief about what we think the power of design is on the web. And trust me, I'm not saying that design isn't important or that there aren't lots of problems that should be solved through a redesign process.
But for many organizations, I think the effort that they should be putting in should be in their content, and that rearranging things or changing the color palette or the font or changing the layout or figuring out even a new navigation system, none of that is going to be worth it if you don't have the content to back it up.
Jared: Well, isn't that just a narrow view of design, though? The idea that we've somehow gotten into our heads that we can separate the content from the design, that feels to me like part of the problem.
Karen: I agree. I think when people who have a holistic view of design are talking about it, they understand that the content and the content strategy is every bit as much a part of the design of the experience as anything else. I think that there is often sort of a naivete that when people hear "design," they think of it as being something smaller.
I think anybody who's active in the design profession is always trying to educate clients or always trying to make the case that design is a more holistic thing. That's why I'm such a strong believer that I really try to classify content strategy as part of user experience and not as something that is in opposition to user experience, or stop thinking that we're fighting for turf or fighting for budgets.
This isn't an oppositional thing. It should be, "Let's figure out, out of all of the different levers that we have to try to make the experience better, where do we think we're going to get the most traction?"
Jared: Yeah. I mean the lens I always take for these things, you can tell me if you do something different, but the lens I always take is that I spend a lot of time watching people use designs. And if I'm watching people shop or I'm watching people try and book a vacation at Disney or I'm watching people try and figure out how they're going to care for their father who's just been diagnosed with pancreatic cancer.
In each of those cases I'm watching people who are spending as much time trying to understand and absorb and work through the content in the design as they are trying to figure out what to click on next--and in fact, more time in most instances.
And in the best designs and the best websites and the best applications, it's the content that is what's driving the use. You take the content out, and this shell of an application is not interesting at all.
I was watching people use Yelp the other day, the review site that lets you figure out where you're going to go for dinner. And again, one could argue that maybe the ratings and the stars and where it shows up on the map is not quite content. But where did people spend all their time? They spent their time reading through reviews.
I watched people trying to figure out. They had already chosen the restaurant. Now they're trying to figure out what the best menu items are. How did they figure that out? They read the reviews. It was all the content. And one of the things that makes the site work is how easy it is to find the content.
Karen: Yes. And how do they make that content browsable? How do they surface the most interesting content or the most useful content? I'm sure you've seen this: people looking at reviews when they're trying to make a purchase. They already sort of know what they want, and then they're reading other people's reviews to validate their decision or not negate their decision.
Jared: Yeah. A lot of people go straight to the negative reviews, right? This is a really interesting thing about the way Amazon sets up their reviews, which is that they make it easy for you to find the one and two-star reviews and just go straight to those. And people do that. That's interesting to me.
That's a content-design decision, right, being able to surface those particular types of reviews. And then they go through and they read them and they say, "Well, this person's complaining about something that I just don't care about, so that doesn't change my opinion of why I want to buy it. The thing they're complaining about is something that won't affect my use."
Karen: Yes. I love that description, as a content-design issue. To me, a lot of these things are straight-up information architecture. It's what sorts of structures are we going to have in that content, and how do we make them visually available to somebody, how do we make them physically available to someone?
Jared: So this bridge between information architecture and content strategy, I think a lot of people are not quite clear on how much they overlap and where they sort of diverge, because people who've been either working with information architects or working on information architecture and now are looking at content strategy as this new thing on the horizon are having this sort of mixed thing of, "I don't quite understand everything they're telling me and it does feel like a lot of this is stuff that I'm already doing. So I don't understand what the big deal is."
Karen: Never underestimate the power of our industry to rename itself or relabel itself with some newly finely graded version of something before. I'm an information architecture person going way back. I've been in the user experience field for 15 years now. It's like I do think that content strategy is an extension of a lot of things that have come before. In many cases, where other people who have some experience with this, they can rightly say, "Oh, yeah. That sounds very similar to things that I've already been doing."
I think the challenge is that, as we discussed at the start of this call, there was perhaps maybe not the same focus on the content and particularly not the same focus on all of the underlying processes and business decisions and essentially the human side of what it was going to take to make some of those things happen. I'm fond of saying it's really, really easy to draw a picture of a faceted navigation system and go to the developers and say, "This is how this should work."
It's really hard to make sure that you have all of the back end infrastructure and all of the human infrastructure to deliver great content that has all of those structures in place to make that happen. In so many organizations, I think the reason content strategy has touched a nerve for people is that it is bringing together a set of skills that maybe were not always brought together and shining a light on them in places where they've been ignored in the past.
Jared: So would it be fair to say that traditionally...I know this isn't true of all information architects and all information architecture, but...
Karen: Are you trying to get me blackballed?
Jared: No. No. Well, maybe. But... the information architectures union will no longer let you pay dues.
Would it be fair to say that when we were doing information architecture in the olden days, that when the ancients did the information architecture, that they tended to think about, "OK, we're going to have these categories. We're going to have these things. We're going to populate the data this way. We're going to do this, this, and this."
But they never thought about who is actually going to write this stuff and how are they going to write it and what's the production schedule. How are they going to make sure it's got the right tags and metadata and all this stuff.
That's sort of human side of the production of the content. Is that what you're getting at?
Karen: I think that's a big part of it, yes. I think that it's that, again, in the past the content was a lot more static. There was less of it.
Jared: Oftentimes it was from sources that had already been created.
Karen: Correct. People were bringing in content from syndicated sources or...
Jared: Or just collateral they already had.
Karen: Yeah, or they're just wasn't the complexity in terms of having a dynamic content management system that was publishing things on the fly according to a variety of business rules. There wasn't the sense of, "Oh, hey. We've been dumping stuff on our website for the last ten years. Has anybody gone back and looked at whether we should get rid of some of it because it's not useful anymore?"
Just a lot of processes that were not put in place, probably because what we had were a lot of the people that were being brought in to say, "OK, build the website and then go away."
And then we realized, "Oh, wait a minute." The maintenance and the care and feeding and the ongoing responsibility for the website is every bit as important.
Jared: One of the sites that you worked on, that I found out recently that you worked on was the New York Times website that basically...The design we see today, that sort of look. That came out of your work when you were at Razorfish, right?
Karen: That it did. I led the major redesign of the Times back in 2005, 2006.
Jared: And so, at that time, when you guys were working on that, were you thinking about those sources of that content? Or were you in that mode that a lot of us were in those days where you were just saying, "OK, this is the content we have to work with. Someone else produces it. There's this magical thing, then content appears and I have to get it displayed on the site." Or were you taking into account that back end stuff when you guys were at Razorfish at that time?
Karen: I will say that right about that time, 2005ish, was when I feel like I had a real epiphany about content strategy. Some of it came from my work with publishers, and the Times, and some work I was doing with other major magazine brands. Some of it came from things that I was seeing internally at Razorfish as I was overseeing the user experience practice.
And even though Razorfish had had content strategists going back to 1998, information architecture was very strong there. It's like I remember somebody coming to me once and saying, "Karen, you know what the problem with this company is? It's that information architecture is the answer to everyone's problems."
All these pieces started falling into place to me where I was like, "You know what? Content strategy is the answer to everybody's problems." Or, "We need to build up this practice because they are solving problems in a different way than information architects will. Very complimentary, but we need to have that balance."
I think one of the things that I have learned from working with major publishers is that the content management system, the underlying technology that supports content management, as well as the overall content workflow and editorial process, are crucial to the success of the site. It's like, "You will never be able to deliver the experience you want to deliver on the front end if you don't have a good experience on the back end."
I would say that back in 2005 it didn't even occur to me that my role should be to go into these publishers or go into these corporation and tell them that they have to fix their CMS and tell them that they had to fix their editorial workflow.
But having been through a few projects like that, all of a sudden I got religion and was like, "You know what? I'm not even as interested with the problems on the front end anymore. There are a lot of people who can solve those problems." But on the back end, how you figure out what the workflow is, what the governance model is, how the tools need to evolve so that they're more user centered around the content creator. That's really interesting to me.
Jared: Yeah, that's a design problem that a lot of folks don't take into account, and if you think of this as a value chain, if you get the content production design wrong, how can you possibly get the content delivery part of the value chain right? You can't make the content better in the deliver portion if your tools are such that it's designed so poorly that you do the wrong things putting it in.
Karen: Exactly. I think we make a lot of assumptions about how great that the experience for our users will be, that are reliant on having people on the back end sometimes do things that are painful or cumbersome or don't make sense to them.
You talk to any developer that's done a major CMS replatforming and what they're talk about is how challenging it is to go in and peel back the layers of the onion of what people are doing with their CMS. And how they've taken a field that was intended to be used for one thing and figured out, "Oh, hey. Oh, if I put something in here, that means it's going to show up in bullet points in the right hand column."
Great, I'm going to use it for some completely different piece of content that wasn't "intended" to go there by the developers or the designers but they figured out how to game the tool.
When you really start digging into that, like right, why don't we treat the CMS as if is a user experience that requires an understanding of how the content creators want to work. Just the same way as we create any other piece of software.
Jared: Yeah. And it's interesting because there's a good chance that we can find those users, right? We can get access to them. One of the big complaints that a lot of designers have is they can't get access to their users, but the people who are actually creating the content, we know where they live. We know where they work.
Karen: Some of the most rewarding stories that I've heard, are stories of developers. CMS developers. They're not necessarily even trained as user experience professionals. I genuinely believe that there's a lot of people out there that want to make great products. And they want to make usable products.
And hearing developers say, "Oh wow! I figured out that I should go and talk to my business owners, talk to the people who are creating content, and I should try to understand their model of their workflow, and how they think about structuring the content.
I should start building prototypes and showing those prototypes to my internal users and getting their feedback on them. That's going to mean that I will develop a system that I can be proud of, because it's going to map more closely to the way that my colleagues want to work." You hear them tell these stories and it's like, you know you've independently just evolved user experience design in your own head, right?
And I think that there are so many great techniques that we have in the user experience field that can be employed on all kinds of projects like this, and it's sort of frustrating to think, wow, we are expecting content creators in these organizations to be using a clunky, out of the box CMS that's not optimized for their needs, as opposed to following a basic user experience practice and designing a system that works the way they want it to work.
Jared: Yeah. This is really sort of the underbelly of our processes that we really don't give much attention to, and we think we can solve just through training. The way you compensate for poor usability is you just train the hell out of it.
And that only gets you so far. And what ends up happening is you get a lot of mistakes. We were at one organization, and they had a staff member whose job it was for 40 hours a week, this person all they did was go into the system and fix mistakes that other people had made because the system was unusable.
Karen: Yes, exactly.
Jared: So, that's an entire salary that is being spent on dealing with the unusable nature of the tool that they were working with. And I'm sure that happens other places.
Karen: Oh, my goodness. I'm sure, I mean these are classics of return on investment and usability work. But it's like, I'm sure if you could find a way to add up all of the time that people were wasting fighting with a tool that doesn't work the way they expect it to, causes them to make errors, is frustrating and painful.
You could count up all that time and say how much money are we losing? How much business value is being lost here? Or, in my mind, what if the time that someone was wasting fighting with your badly designed technology could go toward creating great content. Or better structured content. Or more readable content. You'd be gaining value from that.
Jared: Yeah. I wonder how much really good content is not created because people are so anxious about having to use that CMS that they minimize the amount of time they spend with it and do their best to not go out on a limb, and therefore not go off and do something actually pretty awesome for the user.
Karen: Yeah. No, I worked on a project back in the day, this was one of my great epiphanies about how I was failing as a designer because I wasn't paying enough attention to content strategy, was that I had presented, I had done a whole redesign project, I had mocked-up concepts and gotten the executives all excited, and on board, and everybody was patting ourselves on the back about what a great experience we were going to create for our users.
And then we got well into development, and the executive team came back, and we had a meeting where they were just like, our editorial staff is not doing this. They will not enter this content. They will not add these tags. They will not maintain this. And we wound up having to go back and tear out a bunch of functionality at the last minute, and wound up creating what was again, a sort of mediocre experience, I would say.
Because we hadn't anticipated making sure that everyone who is responsible for creating that content understood what would be required of them, that the content management interfaces and workflows that were provided weren't a huge pain in the ass to make that happen, and we underestimated the level of effort that was required. And that was a huge mistake on my part.
Jared: Yes. It feels to me like we know so much more these days about how to do these things right, and you look at what business needs. Right, and so business needs more revenue for sure. But business also needs to reduce costs.
If our internal systems are creating immense costs, or preventing us from getting those revenue objectives because the editorial team will just refuse to take advantage of the technology that we're building. Or one system, I was watching people use, the person entering the data into the system would put in the same reference tag for every piece they put in. They didn't know what that field meant.
And so, everything was tagged exactly the same. So that meant that it was a completely useless sort field.
Karen: [laughs] Right. Right.
Jared: And filtering field, because everything had exactly the same tag. And when we asked her why did you use it, well that's what the person before me did, and I never understood what this is for, but they tell me I have to put something in here, it yells at me if I don't, and this is the only thing I know to put in here.
And the thing was, that their process was so broken, I mean this wasn't even just a technology problem, right. The process was broken, because she really wasn't the right person to think about what that tag should have been. That was sort of not quite her thing. She was just entering data at that moment. And so, that means someone upstream has to be supplying that information, and they may not even know that the system is asking for it.
Jared: And so that's a human-process issue.
Karen: Yes. Exactly. I do this a lot, these days, go in and look at companies' publishing processes, and you realize, like, wait. This is fairly complex. You need someone to supply the content, you need a writer to write and edit the content. You need someone to physically enter that into the CMS. You need someone who is responsible for the taxonomy and the meta-data, assigning those tags. You need someone to proofread it. You need legal review. You may need several levels of legal review.
And when you actually sit down and map out all the steps, it is a fairly complex process. But it's not impossible. If you just write it down, then at least someone knows what to do. Anticipating the places where oh, right, I should not expect the person who is entering the information into the CMS to also be the same person who is responsible for the taxonomy and the meta-data. Because those are two completely different brains. Just be aware of that.
Jared: Right. Right. The issue then becomes, well OK, now that we're aware of it, we have to redesign the process so the right meta-data gets in there.
Karen: Mmhmm. Yep. And perhaps even re-design the tools, so that the right systems talk to each other or that, I feel like one of the most frustrating things for me in this space is the realization that, for most organizations, they are still letting their tools define their workflow.
Instead of believing that, they need to figure out their own processes and workflow and the technology should be an enabler of that. Instead, you just see the content management system telling people how they should work. Which is crazy. This is why we made robots. We made them to do our bidding, not the other way around.
Jared: [laughs] Well this is sort of McDonald's thinking. Right? If you go into a McDonald's, the way the kitchen is laid out, the machines are very special-purpose. There aren't temperature knobs on the grill. There's the knob for burgers. Right? And the microwave buttons are all labeled with the specific products that they make. And so, if they want to add a new product to the product line, they actually have to put new machinery in.
And that lets them have this consistency from one store to the next, and it lets them lessen the training that's required, because you don't have to retain a lot of information, you just have to look for the button with the right label, and press it at the right moment, and you get the right product. And it's always exactly the same.
And so, that's one way to solve the problem, and a lot of organizations I think go down this road of saying, well we can just solve our problem that way too. But a lot of processes can't fit into that McDonald's model.
You need people to think about the work they're doing. You need them to ask the question, is this really the right way to label this piece of content. Is this really the matches here. Are we doing something we've never done before, at which point we have to step back and say, hmm. How does this fit into the whole scheme of things. And not let themselves be limited.
You know, McDonald's is completely limited into what they can offer because of the structure they've built. And organizations look at that and think, oh, that's a good place to start. But really, you, really only do that when you know you can cut everything down to 27 items on the menu and never anything else.
Karen: Exactly. I think one of the biggest myths that's been perpetrated by content management vendors is this notion that our tool and our process and our workflow and our interfaces will work for you, right out of the box. That your content is the same as everybody else's content, and we figured out the one perfect content model, and you can treat this like an IT project, where you can just come in and install your content processes.
It's like, that's just not true. It's the unwillingness to recognize that oh, you know what, our process and our workflow and our content model is unique, we need to sit down and figure out what that is, and we need to put the work into tailoring the system so that it will best meet the needs of our users.
Jared: Yeah. Yeah. I think this is fascinating. This whole idea that when we're designing systems like this, we have to think as much, if not more, about that upstream. How do we get the content in, as we do, how do we get the content out and in front of the users. And, not just assume that someone else in the organization is magically going to make that happen for us.
Karen: Exactly. And as I see more organizations moving toward a true dynamic publishing model, where I sometimes think of this as different eras, where we started out essentially just building static HTML, with no database or CMS behind it, and then a lot of organizations put in a content management system, but it was kind of dumb. It still forced them to think about laying out pages as if they were print. And it was very static choices about where things were going to live on pages.
Now, most organizations are moving toward what is a truly dynamic publishing model. Where they will have discreet content elements that have meta-data and business rules behind them, and that the content that appears on a given page will be driven by whatever rules are set up in the template, driven by some guidance about personalization, being able to tailor content to individual users or tailor content to individual circumstances.
And that just makes that whole process exponentially more difficult, because it means that...right, we can't just assume that all the right meta-data and all the right tags are going to be there. We can't just assume that content that was created for one context will necessarily work great if it shows up in a different context.
I think it's exciting. I think these are really fun problems to solve. But I think we're going to wind up with some organizations continuing to have some bad content out there before they actually figure out that this a human problem, and not a technology problem.
Jared: Yeah, I find this fascinating because it feels to me like there's a whole opportunity here for the folks who are in this content strategy space to really apply these neat design skills in this upstream place of getting this content ideally ready for production.
I can only imagine that it gets even more exponentially crazy when you add in localization and translation related issues on top of all this chunking things out into discrete components and allowing you to use it in all different ways on different devices at different times.
It just feels, to me, like there's going to be some people out there who are really going to have some fun figuring out how to solve these really hairy problems and pushing us into a new way of thinking as we learn how to do all of this better.
Karen: Yeah, it's like if you like to solve hard problems with information, then this is a great time to be in this field. You're right. The levels of complexity that you can layer on when you start thinking about getting content onto different platforms, when you think about having to localize the content, when you have to translate the content, when you have to think about all of the management and maintenance processes that go into that. When you think about what it means to have analytics on that content to value whether that content's working or not in all those different contexts. It's complicated, and that's what I like about it.
Jared: It's brilliant, brilliant stuff.
Karen, thank you so much for spending time today blowing my mind in this new way, thinking about these problems in a way I haven't thought about them before.
Karen: It is always a delight to talk to you, Jared, and I will look forward to seeing you again very soon, certainly at UI 17.
Jared: Yes, yes. Let me mention that, because it's probably a good idea. You're going to be speaking at the UI 17 conference in November, November 5th through 7th up here in the beautiful Boston area. You're going to be doing a full day on content strategy for designers.
A lot of what we talked about, you're getting into the nitty-gritties of those problems you're going to cover in that day. It's very exciting. I'm really looking forward to this.
Karen: I hope everyone can tell how much I love talking about this subject. And if I've enjoyed talking to you about it this much for half an hour, think about how much fun I'm going to have for a whole day.
Jared: Yes, I think that's exactly. It will be fun for us to watch you have fun.
Jared: [laughs] Beautiful. OK, well thank you very much for taking this time. I want to, once again, thank our audience for joining us and participating in these conversations.
You know, if you get a chance, go to iTunes and look up our podcast and leave us a little review. Those things actually help us a little. So if you wouldn't mind taking a moment and doing that, that would be great.
Thank you for coming and listening to Spoolcast yet one more time. And, as always, thank you for encouraging our behavior. Take care. We'll talk to you later.