Steph Hay – Content-first User Experience

via UIE Brain Sparks http://ift.tt/1pxXdJE

By Sean Carmichael

June 24th, 2014

Podcast: Play in new window | Download (Duration: 33:59 — 17.6MB)

[ Transcript Available ]

In traditional website design and development it’s common to start with the design and add your content later in the process. You may even use “lorem ipsum” as a placeholder to know where the content eventually needs to live. This causes the content creator to craft words to fit the design instead of building a design to fit the content. Without the right content your users will likely have a lackluster experience no matter how good-looking the design.

Steph Hay is an advocate for a content-first approach. She believes it’s important to start with a simple document with all of the content that will be used to communicate with the user. By starting with a document, in plain language, as opposed to a wireframe or comp, all the stakeholders can have an informed discussion. No one needs to be educated on what they are looking at.

Starting with the content helps focus the message you’re delivering to your users. When you build the design out from there, you can more easily determine where the appropriate places are for each type of communication. The site map and hierarchy are born out of the real content that will exist in the final product. You end up with a more cohesive and clear experience.

Steph will be presenting one of 8 daylong workshops at the User Interface 19 conference October 27-29 in Boston. For more information, visit uiconf.com.

Recorded: May, 2014
[ Subscribe to our podcast via  ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]

Full Transcript.

---

Jared Spool: Welcome, everyone, to, yet, another episode of the Spoolcast. I’m so glad you’re joining us today. We’re going to have a wonderful type, because we have with us the amazing, the wonderful, the vivacious, Stephanie Hay, who is one of my favorite people on the planet.

Steph Hay: Aw, now I’m crying.

Jared: No, don’t cry. You probably don’t know this, but Stephanie writes a lot of the content that goes into our marketing. She’s been doing that for a while.

We are extremely fortunate to have her do that. This year, for the first time, we are having her do a workshop at the User Interface 19 Conference, which is a little awkward, because she’s writing the content for the conference and, at the same time, she’s doing a workshop at the conference. We’re all learning how to do that, but it’s working out fabulous. I’ve got to tell you, I’m really excited about her workshop.

We’re going to talk about that today. Stephanie, how are you?

Steph: I am fantastic. How are you doing, Jared?

Jared: I am doing fantastic. You are speaking.

Steph: Mm-hmm.

Jared: Not yet. But you will be speaking…

Steph: [laughs]

Jared: …see, now, you’ve got me watching my words.

Steph: Sorry. My bad. That’s what happens. I always hear that from people. They say, “I feel weird writing you an email or sending you my resume, because you’re a writer.” But that’s usually the reason why they’re sending it to me in the first place.

Jared: Good point.

Steph: Yeah [laughs] . It’s fine. I’m used to it.

Jared: I used to work with someone. This was years and years ago when I had a real job. I used to work with someone. It was a company where the culture happened on email. Everything happened through email — a company of about 150 engineers, almost all of whom came from MIT and they’re all very bright, very smart.

And what was interesting was, they had obnoxious writing skills. What would happen is, they would start to get into arguments or they’d get very passive-aggressive in the writing. There was a tech writer who worked amongst us who would, in a very politically sensitive way, she would take an email that you’ve written and rewrite it and send it back to you and say, “This is another way you could have said what you said.”

[laughter]

Steph: Let me help you learn how to communicate.

Jared: Let me help you learn this. It was brilliant. I can’t actually remember who it was. I just remember that there was somebody who did that. It was very funny. That was also many years ago. But that’s not what we came to talk about today. What we came to talk about today is content-first design, which is an approach to design that I first heard from you, and you’re going to do a full-day workshop on this at the conference. I want to know, what is content-first design?

Steph: I’m super-excited to be giving that full-day workshop, because most of the time that I’ve ever talked about it it’s been in those half-day sessions, which ultimately end with me wanting to get into a little more detail in each section. It’s going to be the first time I get to dig into specific aspects of it that I’ve done with clients that I haven’t had a chance to do before. Everybody that comes is going to get the greatest experience ever, by the way.

Jared: I’ll make sure that the copy promises that.

Steph: [laughs] Good.

Jared: When you say content-first design, what do you actually mean by that?

Steph: One of the things that I learned very quickly when I first started working in the web…it was 2003. I had just moved to Washington D.C., I was out of grad school from Ohio. I was working in a college of arts and sciences, and we were managing 30 different departmental websites.

There was no centralized content management system. There were lots of different content managers, all based in these different departments. They all had different ideas about the voice and tone and look and feel of their sites, and that sort of thing.

One of the things I started realizing back then was how important it was to each of these people that there be a specific presence, a certain look and feel, but not actually any content that said anything. They were basically just regurgitating the PDFs of the course curriculum, and that sort of thing.

We were in charge of redesigning these websites, and I would always find that at the last minute, 20 new pages of content would show up and they were all coming from PDFs, and it was a copy-and-paste effort and it was a big fire and everybody had to put it out so that we could launch on time.

But ultimately, it never cut down on the number of calls into the admissions office or into the department, even if they redesigned the website, because the content itself wasn’t giving the student, or the parent who was calling anything else of value. It was just a new look for the website. I wondered early on whether or not — this was back in 2004, 2005 — whether or not we would actually be more successful in communicating with students and their parents if we just put the PDFs online [laughs] .

Because we weren’t giving them anything else anyway, and they were getting tripped up in different problems with the websites themselves. It was a seed back then that developed further when I started working for agencies. The same exact pattern was continually emerging. We would focus a lot on design. That’s aesthetics, and then 2008, 2009 became much more about user experience design.

Then, we started introducing wireframes. We started getting into hierarchy and then content management systems were ubiquitous, where we started thinking about taxonomy and that sort of thing and adaptive content. But we still weren’t getting into the words themselves. Those were always, at the very end…and in fact, most of the time a designer was charged with writing the content in a traditional web development process, because the client wasn’t doing it or there wasn’t a copywriter on staff or something along those lines.

Often, whatever was in the comp would translate to the final product or to the near final product. Then, the stakeholder would come in and actually look at the site saying, “None of this content is right.” Then, we would go through the fire drill again. This is a pattern that I’d seen over the last 10 years across different organizations.

When I went into consulting for myself, I started pitching this idea of letting me start writing content first, the actual content that would be in the final product and that stakeholders could look at in the first several weeks and that we could build a design around.

I had a couple really great clients who were willing to cooperate with that and go through the growing pains of trying to do a completely new process that started with a Google doc and content and no design until the first several pages of content were already completed. The sitemap was born from content. The design was born from content.

It was a really monumental shift in traditional web development process, but ultimately, gave the clients and I and the teams I was working with a common language because we could all read the thing. We didn’t have to have a specialty in UX design to understand it. We all were able to communicate about what we were trying to say to our end users. That’s been the focus of my work over the last two years in particular that’s been truly rewarding.

Jared: This idea is that you boil down by thinking about the user’s needs just by focusing on the content you’re going to provide them at first. Then, you start to ask the question, “What does the rest of the design of the website or the app or whatever it is need to be to support this critical content versus building out this app and having these grey shaded wireframe boxes that say, content goes here.”?

Steph: Exactly.

Jared: But you don’t actually know if the content will fit there.

Steph: Often, that was the case. Designs would be over engineered to enable any kind of content or multiple types of content in various positions in the real estate of a UI, but, in reality, who was going to produce that content and was there a need for it?

Of course, content strategy certainly has a role in trying to minimize these by coming up with governance plans and that sort of thing. But at the end of the day, is it realistic for the client? What I started focusing on instead of, “What can the client maintain from a governance perspective?” to, “What does the user or customer actually ask for?”

I typically would go into these different organizations and say, “What are the top three questions that you receive on a regular basis?” It’s crazy because these organizations can just rattle them off. They can rattle off five or six. I’ll say, “Where are these questions answered right now on your website?”

50 percent of the time they didn’t have an answer, because it was some sort of, “We don’t really like to answer it directly because XYZ. We don’t really provide the best answer in the first place. We don’t want to give them bad news.” It was that sort of business level thing.

The other 50 percent of the time it was in a place that didn’t make any sense. It didn’t make any sense to the user, anyway, which is why they were getting the question. I think that’s where over engineering comes into play from a content perspective. If you create these verticals and taxonomies and navigation systems that are too heavy, what makes sense to me doesn’t necessarily make sense to you.

Instead of coming up with the categories first, what if we wrote the concept first and let those define the categories? Writing the concept, of course, takes time but what’s the difference if we take the time, the three weeks up front to write the first five or 10 pages of full content that really drives the entire reason why 75 percent of the people are coming to the site in the first place? Or, letting that three weeks wait until the end when now we’ve got all these different structures in place that we can’t work around.

Jared: I was going to say you’re basically buying time at the end by investing it up front.

Steph: That’s right. Frankly, I didn’t anticipate this early on. What the cool thing is about that is, the stakeholders are able to participate very early in those crucial first few weeks of a project, where normally, they say, “Let’s get together. Let’s have a kickoff meeting. Let’s all talk about these things. We’re going to go away and generate some wireframes, or some mood boards, or something like that.”

Then, you come back and you’re like, “Here’s some sort of traditional web industry document that isn’t in your domain expertise and now I’m asking you to give me some informed feedback on it.” It’s like if I had to go to a television expo, where all these TVs are on display and was told, “Here’s a bunch of TVs. You said that you wanted at TV. Here’s a bunch of TVs. Which one do you like?”

There’s no way I would be able to make a distinction between one or another. That’s one of the things that I’ve really learned with this content-first UX design, is that we are all looking at a written document. We’re all looking at the words that we would use to communicate with a customer or a user. It allows everybody in the room to communicate. We all have this shared language. It’s written English. It’s not a wire frame. Nobody has to be educated on it.

We say, “Hey, if you go to the home page, the home page is going to say this, and the About page is going to say this.” Or, the product page is going to say this and as they go through the checkout process, it’s going to say this and we’re going to ask for these pieces of information. When they get an email after they’ve made a purchase, it’s going to say this and this is going to be the subject line. It’s like, everybody can have that conversation.

Jared: I assume that discussions of what the voice and the tone of this stuff is comes out at this stage when you’re talking about this.

Steph: That’s right. Which of course then drives design choices as well.

Jared: Right. Because if you have a very happy-go-lucky tone, you don’t want the structure of the site to look like it’s coming from a bank. But if you have a very formal tone, you don’t want it to be cheery, happy, bubbly images.

Steph: That’s right. At the same time, the voice and tone obviously represent the company that you’re making the design for, but it’s speaking to the user, and what is the language that the user uses or the customer uses?

That becomes part of the discussion too, which I think makes for a healthier conversation from a user experience perspective, because it actually introduces the user as part of the original conversation, versus waiting until there’s usability testing once there’s an actual site and it’s focused on functionality and finding stuff.

Jared: You’ve been doing this now for a few years with some of your clients. Is there some resistance that you’ve run into at first or do you have to get over some objections? Or, is this one of these things where you explain it to them and they go, “Of course, that’s exactly how we should do it,” and it smoothly sails through the organization with no conflict at all?

Steph: I’ll tell you a couple stories. I’ll say all of the above. It’s completely environmentally driven. I was working with the Annie E. Casey Foundation and John Hodgins, their communication manager there — a fantastic guy. Really early on, he was open-minded to this idea, but also he comes from a digital background enough to understand that this was atypical.

I don’t really make any bones about it or anything. That wasn’t part of the initial discussion. It was just like, “Hey, this is what we’re going to work on for the next few weeks. We should be on a phone call every single week. I’m going to give you assignments. You’re going to have to write content. I’m going to write some content to help you, to give you a guide, a jumping-off point, to speak.”

He said, “I want to say it was probably our second call.” The first call was a little stiff, because I’m saying, “What is the most important page on your site?” We can look at analytics and see what is the most sought-after content. We can also from an organization perspective get that answer from someone like John, who says, “Our reports. We’re a foundation. We provide grants. We do research to figure out the impact of these grants.

The research is distilled into these reports, people come to the reports pages to learn what we’ve learned. We immediately found out that in their existing reports pages, they didn’t have any real quote-unquote “conversion points” of, can you download the report? Can you provide an email address if you want to learn more about this particular topic, that sort of thing.

We were all on a call together discussing what they could do from a content perspective to give people who landed on these pages in the new site some sort of next step, some way of showing that they didn’t just read this. They weren’t just another number on the analytics, but they actually wanted to do something with it.

That first call was really already digging into the purpose of the site. From a content perspective, what do we want them to do? What are the actions they’re going to take? By the way, these are going to be the labels on buttons, eventually.

After that first call, we went up a higher level. How does somebody get to this report page in the first place? Let’s write the content on a higher-level page that would lead somebody to a report page, that sort of thing. He said to me afterwards, “After the first call, I got where you were going with this, but it was really hard seeing this blank page in front of me.”

Because we’re all working in a Google Doc, the same Google Doc. Because we’re making our comments. All of the content for the website is in a Google doc, a very long one. He says, “But then once I started getting into it, I totally got it and then it became part of my work week.”

But it was, again, shifting your thinking away from, “Can’t we just deal with the content later after we’ve done all the design?” to “The content is the whole reason for the design in the first place. I’ve got to do the hard work now.” He was an example of somebody who, after going through one session, got it and started running with it. Then he had a whole team.

At that point, I was just basically a guide. I was hardly doing anything. They embraced it. They went bananas to put together even a style guide to bring on more style managers to help out. This was something they could all do. While the website, while the design was being done, they were all writing content. It was great.

On the other side, a law firm I was working with, they had a content manager who totally got it but organizationally speaking, there were lots of levels of approvals of people who didn’t really understand this approach and they wanted to see the design first. Which reminds me a lot of the way that it was 10 years ago when I was at George Mason, where there’s nothing wrong with wanting to see design. Design is fun.

Being able to make choices about what you like to look at on your own website is fine. It’s totally fine. But for me and my particular focus, I’m about improving the communication between the customer and the organization, which happens of course with design, but for me it happens through word and word choice and a hierarchy of those words. The content-first design approach strips everything else out and it takes the organization who is very content-focused to understand that and really embrace it.

Jared: Are there certain types of organizations or certain types of projects where this content-first approach really lends itself, and certain types of projects where it’s just not the right approach?

Steph: What I’ve found is it seems to really be culturally driven. If people recognize that content — even organizations like Dell, for example, say content marketing is really important — that the content is the most important piece and are willing to embrace a content-first approach it’ll work for anybody. It doesn’t matter what they’re doing.

I worked on this with start-ups to define exactly what that end-to-end experience is going to be. Somebody comes to you and has to do some sort of transaction, a sign-up or whatever it might be. I’ve used it for product design for those same start-ups beyond their marketing site. What happens when somebody actually uses their application? What’s the way we entice them to give us an input, and what did they get in response? This is getting into microcopy.

Like I said, like within Annie E. Casey, this is a huge, content-heavy website. We’ve used it to guide the experience that 50 percent plus of their monthly visitors are going to have. I don’t think it necessarily depends on what the product or service is as much as it depends on the people being willing to prioritize content and prioritize the work of talking through the conversation that needs to happen between them and their users.

Jared: When we were going over the outline for the workshop, one of the things that came up was you mentioned this thing called a language board. I realized I don’t actually know what that is.

Steph: Have you heard of Style Tiles by Samantha Warren?

Jared: Yeah, of course. Style Tiles are these lovely, single-page abstractions of the colors and the fonts and some of the way the layouts will look in such a way that you can get feedback from a client without them critiquing that paragraph of text doesn’t actually reflect what we’re going to be talking about.

Steph: Exactly. This is what a language board does, and the same idea. It becomes a communication tool, except the language board really focuses on combining the language that customers use with the language that the organization feels comfortable using. We typically see an editorial style guide or a style voice and tongue guide, and it normally comes up at the end of a project.

This is, again, flipping that paradigm. A language board takes the top search terms that bring people to a company’s website because that represents their language, the way they think about the world. It has the terms that are the way that the organization categorizes or talks about those same kinds of terms. I use residence hall and dorm as the example there. People search “dorm” on the university’s website, but the university has everything under “residence hall” on the website.

This is a problem, because they have data to indicate that people don’t think about them as residence halls. We can have the discussion early on about how much the organization wants to “educate/force” the user into their language paradigm versus being able to embrace what their customers’ or users’ natural language is.

The language board, if you think about it, again, as a Google Doc, as an outline of the customer and the customer’s voice mixed with the organization’s content goals and the voice of that content. It serves as a foundation through which we can then comfortable write conversations that speak to both of their languages.

Jared: That sounds very useful.

Steph: I think it is. [laughs] That’s the thing that I really was inspired by with Samantha’s Style Tiles. It’s not so much the product itself, it’s the fact that it can create a conversation around what’s most meaningful. In the case of when I’m working on content all the time, it’s whether or not the words that we’re using are landing.

Do they mean anything to the customer? Are we speaking the same language? The companies and organizations who are willing to evolve to meet their customers in a conversation, in a comfortable conversation, tend to have higher engagement. They also tend to create ongoing content that has higher engagement.

Jared: That makes perfect sense to me. I’ve been thinking a lot lately about the difference between what I would call a deliverable versus an artifact. A deliverable is something you hand to the client. It’s the final copy. It’s the rough draft. It’s something that is going to denote that we’ve hit this milestone at this time and the project is moving forward.

Whereas, an artifact is something that you give that really only has meaning in that moment and down the road won’t be that useful. It’s a sketch or a style tile, though a style tile could be both an artifact or a deliverable because once it’s finalized you can use it for a lot of things. The language board sounds like it also plays this role of an artifact.

An artifact is something that is really about I’m going to give this to you just to get your feedback. If I was cooking a soup, I might give you a taste out of the pot and say, “What do you think?” and you might say, “I think it needs more salt.” That’s an artifact versus the deliverable of the soup, which is, “Here’s your bowl of soup. Enjoy this.”

I think there’s something to that, and it’s not a conversation I hear us talking about very much.

Steph: It also is at a point I want your feedback early on before we’ve started to involve more people in the process. From a design perspective, we start to get deeper into it. Words are the lowest fidelity thing. We’re working in a Google Doc. This is a lowest fidelity thing.

What ends up happening is, for example, I was working with Custom, Inc., which is this awesome T-shirt screen printing company here locally around D.C. Early on they have a light, happy-go-lucky voice and language and tone. I wrote the word ‘awesome’. They said, “We would never use the word ‘awesome’.”

Me, who was a customer of theirs and working with them from a customer standpoint, didn’t completely interpret who they were yet, but they knew who they were. The language board is the way we can have those conversations early on before things are really set.

Jared: This is how you discover that a client’s not awesome.

Steph: [laughs] We don’t use the word awesome. They have really lovely language, but awesome is just not part of their language. It’s part of mine. [laughs] Overly.

Jared: It’s always struck me that awesome is some awe where awful is not full of awe.

Steph: Yeah, no. [laughs] That’s funny. You ever see that Gallagher skit when Gallagher used to talk about these things?

Jared: No.

Steph: All right. I’m going to find it, and I’ll send you the link.

Jared: We’ll have to put it in the show notes. Do I have to wear a tarp?

Steph: [laughs] No.

Jared: I was afraid to fire up Gallagher videos because I’m afraid I’m going to get water rolling all over me.

Steph: George Carlin did stuff like this, too, actually.

Jared: Playing with words, yeah. Absolutely. While we’re playing with words, another thing that we talked about, which I realized I didn’t quite know what we were talking about, was a conversation map.

Steph: The conversation map is what emerges from this content-first UX design approach. What it is is the structure itself. In the example of Annie E. Casey, I said we started with a page. There’s no structure to this, there’s no map, there’s no journey. There’s a single page. Somebody ultimately wants to end here. Let’s start with that. That’s the highest value page, the most sought-after content.

Once we’d done that, we said how does somebody get here? We think about it as a conversation. This is the way the conversation would roll out. We go up a higher level, and we continue doing that until we arrive at the entry point of the conversation, which is usually the home page.

The conversation map is backwards. It’s a little backwards. We’re starting with the highest value content, which is typically not on the home page. It’s typically some, right now, second or third level page. We actually want to have that conversation so we write that content first, and then, we take a step back and we write the content of what would lead into that highly sought-after content page.

We continue to move backward in the process until we’ve mapped a conversation from entry point…”Hi, who are you?” “We’re Annie E. Casey Foundation.” “What do you do?” “We work with juvenile justice.” “What do you know about juvenile justice?” “All of this research here.” We end up architecting, let’s say, at minimum, three, sometimes four or five, different pages of content that forms the structure of one potential path.

Typically, this is the majority of users who come will go in through some sort of path like this. This creates the map. At this point, now, it’s about repeating it. Can we do this again? It’s like choose your adventure books. What are some of the other ways people could navigate — and I use that word lightly here — this conversation?

What are some other topics in this conversation that would lead them to a different point, and what is the content when they arrive there? This conversation map ends up being the product and the structure of writing 5, 10, 15 pages of content that we know should exist and then finding out how it pulls together. We’re mapping that content, which ends up creating the site map.

Jared: This is how we then start to get into the actual design. We have this conversation map which then becomes the site map which then becomes the structure of the site. Between that and some of the pages and the content that we’ve created, we now know what the words have to be on the page, which means, we can then create the design that will create those words, and we’re off.

Steph: That’s exactly right. A couple of questions that I get on a regular basis about this sort of approach are, number one, what if you don’t have a product yet? The process I just gave you using Annie E. Casey as an example was existing content. If you’ve got existing content, how do you go about this process?

If you don’t have anything yet, if you’re a start-up, the concept map would really work as a conversation itself. Somebody says to me, “I’ve got a new idea. It’s like Flickr for YouTube,” whatever that is. I’m like, “What’s that mean?” I continue to document what they’re telling me until they figure out what it is that the actually conversation is going to be that helps me understand what this product is, what I’m supposed to do with it, how I interact with it, that sort of thing.

You can start from the very beginning, from the entry point. Tell me who it is you are, what it is that you offer me, what problem do you solve, that sort of thing. In that case, the content map functions much more like documenting how the conversation should roll-out from start to finish.

That’s really the only difference in the activity is just where do we start. If there’s existing content, we work backwards from the most important content up. If there’s no content already, we just map the conversation how it should exist. Then, after it launches, we look three or four months later and figure out what is the most sought-after content from the conversation we just produced, and if we want to refine at that point we work backwards.

Jared: That’s brilliant. That’s great. I am so excited about this workshop.

Steph: Yeah. [laughs]

Jared: I am going to learn so much. This is such a great way of thinking about designing all sorts of things. This is going to be awesome.

Steph: Thank you. Yeah, I’m excited about it. I will say, too, one of the most rewarding parts of having given this workshop a couple of times already is there’s always this moment of epiphany where product managers, designers, and developers…I always say developers get such a bad rep, because they “don’t know how to write microcopy” or something.

I think that’s such a crock because who is writing it for them? At some point, there’s an error that has to be thrown. It says sorry, you made an error. After the site launches, someone comes back to them and says, “You’re making the user feel like it’s their fault.” This is where the content-first approach really comes into play.

I’ve already thought about what that error should be because I’ve walked through the conversation that I want to have with the user, including what are the labels on the fields. There’s always this epiphany that happens in the workshops when people realize that they have to think about that stuff now. It’s not somebody else’s responsibility down the road. For example, like we will in this workshop, if we walk through a transaction and I say, “Billing or shipping?”

I make them think through the billing and shipping addresses and what they need and how could that be a simpler process? What happens if they don’t put something in? What’s the error message that we should show? How should we show it?

In a conversation map, where we’re starting to document all of this stuff, that’s where using something like a Google Doc makes a lot of sense, because you can just leave a comment there. You say, “We’re going to have address fields.” No, you can’t just say, “We have address fields.” You’ve got to say exactly what fields you want. We’re writing down the labels so the developer doesn’t have to think about it, or the designer doesn’t have to think about it. The developer doesn’t have to think about it.

Jared: Right. Is it a zip code? Is it a postal code?

Steph: That’s right. There’s always this epiphany where it’s like, “Oh, I’m the one doing the work.” [laughs] It’s like that makes the designer’s life…I remember Patrick Marsceill at Happy Cog, I asked him after we went through a project together like this. I said, “Was this really helpful at all for you?” I led that, but he worked with us on all of the calls and everything.

He said, “I don’t ever want to work without this again.” It made his life easier. As a result, it made everyone else’s lives easier by thinking about those detailed messages and words up front.

Jared: Makes perfect sense. Steph, this has been absolutely wonderful. Thank you for taking the time to talk to me today.

Steph: Yeah, you’re welcome. Thank you very much, Jared. I’m really excited for October.

Jared: For those of you listening, you really want to catch Steph’s full-day workshop on content-first design. It’s going to be at the User Interface 19 conference, which is going to be October 27th through 29th. We are so excited to have her there to talk about this for the day. I know I’m going to learn a ton. I know you are, too. You want to come and do that. Thank you, Steph, for talking to us.

Steph: Thank you.

Jared: Thanks to everybody for listening. Of course, thank you for encouraging our behavior. We’ll talk to you next time. Take care…