Optimizing Responsive Workflows with Structured Content

Jared Spool: Welcome, everyone, we are here, another episode of SpoolCast, International Edition, because I have, from the Netherlands, one of the smartest people I know, Stephen Hay.

Stephen, welcome.

Stephen Hay: Thank you. Good to be here, virtually.

Jared: Virtually, virtually. Across the ocean. The bits are moving.

Stephen: You know I’m not from the Netherlands, right?

Jared: But you are, in that, when you come to the conference, you will be taking a plane from Amsterdam, I believe.

Stephen: That is true.

Jared: As much as anyone is from anywhere, the atoms in your body were all from the Big Bang, so.

Stephen: You got me. Touché.

Jared: [laughs] Carl Sagan once said that if you want to make an apple pie from scratch you have to start with the Big Bang. Everything sort of comes back to that notion.

The other related thing I heard the other day was about that big thing that they have in CERN, what’s it called?

Stephen: The Large Hadron Collider.

Jared: The thing I heard was that physicists have a tradition, every 16 billion years they get together and build a Large Hadron Collider.

[laughter]

Stephen: That’s like really deep nerdy humor right there.

Jared: Yeah, I’m into deep nerdy physics jokes today. I don’t know why. It’s just one of those things.

But that’s not what we came to talk about. What we came to talk about was workflow and dealing with this. I’ve been talking with a lot of teams lately, and they have been telling me that this move to responsive is not just about making things so that when you move your arm to the left and the right while holding the corner of the browser, everything just moves around nicely. It’s changing the way they do everything.

It has this impact, and people are like, “We need to go responsive.” Sure, we can have that done by next week. Then they realize it changes their world completely. Have you seen this?

Stephen: No, not at all. [laughs] I have no idea what you’re talking about. Yes, I see this all the time. It’s getting better very, very slowly. But it seems like everyone has the same problems since we started doing responsive design.

I started doing responsive design before we really had a name for it. We were just making fluid grids. We didn’t have media queries to completely change the layout, if you’re talking about layout. We didn’t use media queries yet, but we were doing a lot of things in the direction of responsive design.

I guess that’s when I noticed that the problems were starting for my work. Now I’m noticing the same stories. I try to sound like I’m hearing these painful stories for the first time.

[laughter]

Stephen: Every time I thought, “Oh, yeah, that sounds pretty painful.” But, really, they’re all variations on the same kind of problem. It’s just the way organizations are set up — especially, the larger the organization, the bigger the problems that they seem to have with responsive.

I’m not sure why a lot of companies don’t understand that the waterfall process is the problem, really. I guess, when we started specializing…In the beginning, when I first started doing websites, I did everything. I designed, I did wireframes, I did pretty much everything, because you could back then. Things were simpler.

We started specializing, and once you start specializing, everyone starts getting their own deliverables. It’s like deliverables are the way to validate your value within a team. When you do that, you have your own little deliverable, and, as long as you do that and everyone’s happy with that, you get signoff on that thing.

Then you pass it over to the next person, they make their deliverable based on yours. They get signoff on that, and pass it to the next person.

The problems that you will eventually have, because everyone does — design problems or development problems — you’ll find them. You always do. But you’re going to find out about them later on down the line. That’s one of the huge problems. It’s that we still push with that whole waterfall effect.

We start pushing a lot of the problem solving toward the end of the project, when it becomes very expensive to do so. It seems like everyone has some kind of version of that problem, the special areas of expertise not talking enough, not working enough together, just worrying about their own little silo.

Some of them were really nice about it to each other, but it’s pretty much the problem of communication and collaboration, really. I tend to think that most problems with responsive design are not even really technical problems, because we have a lot of smart developers.

Whenever I go into a company or into a team, incredibly smart people on almost every team. They’re there for a reason, most of the time. The technical issues are pretty well documented, how to deal with images. You know there are problems with them, but a lot of smart people trying to work around these problems.

But the problems that no one really talks about are the ones within the organization — the fact that you have to fly to Sweden to get signoff on this Photoshop comp before the people in Germany start building this thing. [laughs] That type of problem is not the thing that people first think of when they think of all the problems they have with responsive design, because they don’t trace it back to those types of situations.

The fact that we start with visual design, oftentimes, or interaction design, even, before we even really think enough about the content. People don’t think about these things, because it’s not nice to think about them. It does mean you’ll have to change the way you look at things.

A lot of people are willing to that, but they see this huge wall, the organizational wall, like, “I have to get my manager to agree to doing it a new way.” He has to get his manager to grant him that. That becomes a huge issue, especially in larger organizations.

Jared: Years ago, when I started doing consulting, a friend of mine handed me a book called “The Secrets of Consulting,” by Gerald Weinberg. He has a couple of laws of consulting. His first law of consulting is, Weinberg’s first law, he calls it, no matter how much your client insists to the contrary, there’s always a problem.

The second law is, no matter how much your client insists to the contrary, it’s almost always a people problem.

This responsive workflow thing, you brought up a point I’d never thought of before, which was that, when we’re that solo Web designer, Webmaster, the only one in the shop doing that work, we don’t work in a waterfall manner. We don’t do the design for eight weeks and write up a document that we then handed off to ourselves. Start to implement.

Stephen: Then get mad at yourself.

[laughter]

Jared: For not thinking it through. Then go back to ourselves for approval.

Stephen: I think you probably do get mad.

Jared: [laughs] Yeah, probably. But that, we work in this very iterative, jumping around, ad hoc, crazy drunken sailor’s path type approach. It’s only when we’ve said, “Well, you’re going to do this, and then you’re going to give it to me and I’m going to do that,” that we suddenly put up this wall and say, “Hey, we can’t have that sort of interactive back and forth. You’ve got to do your thing and I’ll just sit here politely until you hand it to me.”

Stephen: Yes, and we might tell you what we’re doing. But so many organizations don’t. Are you suggesting we call this drunken sailor design?

Jared: Drunken sailor design.

Stephen: [laughs] Just to call up Ethan Marcotte and tell him we’re changing the name.

Jared: Yeah.

Stephen: Drunken sailor design. No, but it is true that, I think it’s a natural way to work. If you go and work alone on something and you have several overlapping disciplines within yourself, as we used to in the beginning of the Web.

Jared: We still do.

Stephen: We still do. You do a lot of different things. I do a lot of different things. I saw a talk Jonathan Snook did recently about. I think he calls it “deep generalists.” Being a generalist, but then having a couple of areas of expertise where you go pretty deep.

Jared:I’m a big fan of that. I think we spend too much time thinking about our roles and not enough time thinking about our skills. That what we should be doing is just constantly assessing our skills.

Maybe I’m not that great at visual design, but that doesn’t mean I can’t get better at visual design. I could hang around people who are awesome at visual design and I could try stuff and I could have them critique it. Suddenly, if I kept doing that, I would get better. Would I ever be as good as them? Probably not.

But I could get better, because visual design, 99 percent of getting better at visual design is just practicing and just doing it. Taking the time and effort to do it.

I think that we all have multiple disciplines of skills within us and we constrain ourselves by saying, “Well, I’m just a programmer, so I’m not a designer. So I’m not going to do that design thing. Then let the person who’s a designer do it, but damn, if they start to code, I’m going to get really pissy about it.”

It’s like, no, that’s crazy. If everybody on the team can handle basic simple coding, then putting a prototype together to get an idea out, that’s like the simplest thing in the world now. Because anyone in the team can handle it.

Yeah, it’s not going to be production level code. It’s not going to be the best code ever written. But it’s going to get the prototype out and someone’s going to go, “Yeah, that’s what I meant,” or, “No, that’s not what I wanted.” That’s just powerful, when everybody can do a little bit of everything.

Then sure, there’s stuff that they just have more experience and practice at. That’s what I think Jonathan’s talking about with that deep generalist stuff.

Stephen: Yes. I think so, and it goes the other way, as well. You know that one of the big debates about this workflow stuff, especially the way I talk about it, is I see code as a potentially powerful tool for designers. Not a lot of designers agree with that and they’re kind of afraid. It’s like, you’re taking me out of the creative zone and you’re putting me into more of a developer zone.

But so, that’s not really what we’re saying at all. Because the other way is just as valid. I don’t want to be able to code myself necessarily, but I do want to understand what’s going on when someone does code and I want to understand more about what’s possible with code.

In the same way that a print designer understands the process of printing, without herself having to go and operate the press. Understanding how the paper will react with the ink, what effect will that have on the colors, visualizing what this thing will end up being like based on the knowledge of all this technical stuff, really, that a printer has to deal with.

But really, I know a lot of designers, at least from, I guess, my age group, who have done that traditional graphic design, even before we started using computers for putting everything together.

Jared: Yeah, back when we still printed things.

Stephen: Yes, exactly, when we actually printed things. You would go in and I remember…I’ll never forget it and people talk about it now, going into like a workshop, Erik Spiekermann workshop on letterpress or something. Using all those old, the lead, the metal letters and typesetting things. It’s interesting to be able to do that.

The fact that designers want to do that kind of thing, even though it’s outdated and technical in a sense, they don’t often share that same enthusiasm for learning code.

There are some beautiful things that are being done with code. A bunch of art is being done with code. It’s just beautiful. Casey Reas and Ben Fry, who came up with processing, if you go to processing.org, you’ll see this coding environment and language based on Java for creative coding. It’s pretty easy to learn for designers to learn the basics, and then to get really good at it, it’s incredibly hard.

But they’ve made beautiful things, interactive things that are in galleries and museums all over the world.

The idea that you can’t be creative with code is, in my opinion, no one can really make that argument. They might be able to, but I’d be interested to hear what the arguments are.

Jared: It’s interesting. The argument I hear is, “Well, you can’t do two things well.” If I start to learn to be good at code, I’m going to become worse at design. It’s such a silly thing, because it’s like, “Yeah, I’ve never met a designer who was also a really good cook.” Or, “A designer who was also a really good musician.”

Because that can’t happen in the world. Or a really good golfer or whatever.

You can’t be good at two things. You can’t. Sure you can. You just put in the time. Most of the way you get good at something is you just give yourself the time to practice it. The fact is there’s a lot of intersection between design and code, because it’s the medium you’re in.

Here you are, you live in the Netherlands. You live in Amsterdam proper, yes?

Stephen: About an hour and a half Northeast.

Jared: If you go an hour and a half Northeast, don’t you end up in another
country?

Stephen: No, that’d be…it’d probably two and a half hours Northeast.

Jared: OK. An hour and a half to the Northeast.

Stephen: Yeah, I get where you’re going. I’d be in Germany if I kept going.

Jared: That’s right.

An hour and a half Northeast, but there you are, you’re an American who is now in the Netherlands. My understanding is that everybody in the Netherlands, or almost everybody in the Netherlands speaks pretty damn good English.

Stephen: That’s what I thought when I moved here. [laughs]

Jared: Yeah. But the thing is, that’s not their natural language.

Stephen: No, it’s not true at all. It was really hard to communicate when I first moved here. I moved here with a lot of linguistic confidence in that sense. I was really excited, because I figured everyone would be able to communicate with me and I with them. It turned out to be completely wrong.

If you’re in Amsterdam proper, as you say, which is a huge tourist attraction, really, everyone’s used to speaking English because it’s all tourists. But up where I live, it’s not like that at all. I’d go and speak English to them and they look at me like I have two heads.

Jared: I remember being in the Amsterdam police station in one of the police stations in Amsterdam once, and went up to the police officer. I said, “Do you speak English?” He said, “Do you speak Dutch?” I said, “No.” He says, “Well, then, I’ll speak English.”

I won’t explain why I was there. But the fact is is that…

Stephen: That’s such a Dutch response.

Jared: [laughs] It is. The fact is that that’s their language. That’s what they speak from their very early age, and that’s their thing. If you really want to communicate well with them, you have to know their language.

Now, for you, it’s a second language. So you’re probably not as fluent in Dutch as people who’ve lived there the whole time. But having lived there for a while, I’m guessing you speak a pretty darn good passable Dutch.

Stephen: Yeah, I suppose so, with a heavy American accent. I write in Dutch, I read Dutch. I don’t think in Dutch, necessarily. But it was like a priority to me, once I realized, and I get where you’re going with this and it’s true.

Once I realized that people don’t communicate as well with me and I can’t communicate as well with them as I thought I would, it was a priority to learn the language as well as I could.

The best way to do it, to be honest with you how I learned it, I took lessons for two years — one night a week to learn Dutch. I did learn the theoretical aspects of the language that way. But I didn’t learn the language really until I just started speaking it, writing it and reading it at work.

Jared: I had friend who lived in Sweden and they tried to learn Swedish. They said that every time they would start to speak to someone in Swedish, the Swedes would pick up their American accent and immediately switch to English.

It was actually really hard to practice their Swedish, because they just thought they were doing her a favor. [laughs]

Stephen: Yeah, that does happen. That did happen to me as well for a certain period of time. But you notice that that’s kind of a good thing, and if we draw that parallel to, like, people working together in organizations, teams building Web stuff, then that period of people trying to accommodate you because they realize that you don’t speak their language yet, that’s a good thing.

But that shouldn’t be motivation to stop trying to speak their language as well.

Once you get to the point where you speak their language, they’ve done some work to speak your language, you could speak each other’s language. It just depends on the situation.

When I go speak at a Dutch event and Dutch people come up to me, I can speak to them in Dutch and the conversation will be in Dutch. But if there’s an American speaker who comes along, we know that that’s the only person who won’t understand what we’re talking about and everyone just starts speaking English. That makes for a really flexible situation.

That’s really the same type of thing that we need to get going in organizations as well in teams.

Jared: Yeah, if designers can speak pidgin developer, they can talk about it in a way that the developers understand what they’re trying to say, but it’s not the clearest most perfect version of the language. Similarly, developers can talk about design and they understand design in its concept. But they’re not going to go out and create the world’s greatest designs.

They’re going to be able to understand what the designer’s trying to do.

When you have that situation, where everybody can communicate cross lingually in that way, suddenly it changes the way the team works together.

Stephen: Absolutely. You could even take it to more of an extreme and say that the designers who really are interested in learning code can go as far with that as they want, without having to worry that they’re going to lose their designer identity, because code doesn’t suck the creativity out of you. That creativity, you have it, it’s there. It’s not leaving unless you let it lie dormant.

You know Val Head, right?

Jared: Yeah. I love Val Head. She’s so smart.

Stephen: She is. I’ve spoken with her at a couple of conferences. She’s done a fantastic talk about animation in Web user interfaces. The subtle things you can do with animation to completely enhance your experience, the experience for the people using the thing you’re building.

It’s so powerful. She gets up there, and she starts typing stuff. If you don’t know code, you’re like, “What? What is she doing?” Then things just start happening on the screen. It’s a beautiful thing to see.

She’s also very talented. Everyone was like, “I would like to be able to do what she’s doing.” Besides from that, if you’re a designer or if you’re an interaction designer, your whole job is to focus on interaction. Wouldn’t it be cool if you would be able to play with that kind of thing to get the type of interaction that you envisioned?

Jared: I saw exactly the same thing a few months ago. I was at a conference and Chris Coyier got up. He completely deconstructed how SVG works. In the middle of this presentation, he showed a completely responsive icon built out of SVG. I guess you can build media queries into the SVG code.

Here he was with this SVG house and as you made the view port bigger for that SVG item, the house went from this little monopoly-shaped house that was just a triangle and a square that made a house to this thing with windows, and a door, and trees depending on how much space it had.

The power of that and understanding that as a designer, I can change the actual geometry of an icon based on how big the view port was. But being able to then talk about how do I set the break points in that view port? How do I decide at what point should it shift?

The UIE logo has several components. It’s got this asterisk. The new one that Dan Rubin created. It has this asterisk. It has the big letters U-I-E. It has the phrase, “User Interface Engineering,” that’s underneath or sometimes it’s to the side. Depending on whether we have more horizontal space than vertical space, we’ll put the “User Interface Engineering” on the side, or we’ll put it at the bottom.

If we don’t have space at all, we’ll get rid of “User Interface Engineering” and just have UIE. If it’s in its smallest form, it just has an asterisk.

I saw that presentation from Chris Coyier. I came back. We have a design intern here. I said to her, “You got to watch this presentation, and then I want you to create a responsive version of our logo.” Within 24 hours, she had this really cool responsive version of the logo. It was because she knew how to code.

It’s not hard code. It’s really simple stuff as far as I could tell. She mastered it. I’m sure a production developer would look at it and go, “Oh, my God, that is so big. We’ve got to reduce the size of that by 70 percent.” But it showed what we were trying to do.

Stephen: At the same time, it’s valid to say, “Well, it’s too much of a jump for me.” Let’s say I’m a designer who doesn’t code at all and everyone’s talking about using code as a design tool. People get scared by it understandably.

One of the important things to talk about is how you can gradually get to that point, where you can use code as a design tool in addition to your other tools. I kind of make fun of Photoshop just because it’s fun to make fun of. Also, the whole idea of working in Photoshop has a whole plethora of problems when it comes to responsive design.

Jared: Because you deal with fixed pixel and stuff, right?

Stephen: Absolutely. Yeah. The amount of work that has to be done to make changes, for example. I tend to make fun of Photoshop at times, but I never say don’t use Photoshop and only use code. There are a lot of misconceptions about what you mean when you say use code as a design tool. People think you just go into the browser, open a text editor, and start typing.

That’s not how design works either.

Those are misconceptions, but also we have to understand that there are some designers who find it very scary and so we start small. Just learn tiny bits of CSS and realize that all this CSS that you’re learning is something like color. It’s really easy.

You type color, a colon, and then the name of the color. Then the thing that you attach that to gets that color. That kind of CSS is not very hard. You have to start there.

There are some tools to get people playing around with it. You could consider them like browser-based sketch tools for CSS, if you will. Things like JS pen and CodePen which is Chris Coyier’s project.

Jared: Such a cool tool. I love CodePen.

Stephen: It is a cool tool. I love those kinds of tools. They allow you to play around with little ideas that you have for the more experienced people.

Jared: He was showing how Illustrator will save something as an SVG. He was showing how you can take it from Illustrator, plunk it to CodePen, see the code behind it, start tweaking that SVG that Illustrator created, and seeing how that affects the design. That seems to be a way great way to learn.

Stephen: Yes. Every browser has some kind of developer tools. They’re called developer tools, but they are really design tools as well. You can open up a website and start changing things on the fly in the developer tools of your browser.

I know in Chrome you have a little color picker, so you can just select an element and then pull up the color picker and change the color of the element. It’s easy to change margins, and padding, and things like that.

If you don’t even know CSS, you can play around with these things. It doesn’t ruin your website. You just open up any website. You can see how it’s built. You can also see what affects little changes you make would have on the design at the same time.

It’s also a great way to learn. It’s like a super-enhanced version of the way we learn how to make websites way back when which was looking at view source. This is like an interactive view source that you can do anything with. That’s another great way to learn.

You don’t have to go from designing and Photoshop to suddenly making production-ready code. I don’t think anyone reasonable expects that. But to consider code to be an extra tool, in addition to Photoshop and things that you already use, it’s a good healthy way of looking at things which gives you a lot of options for the future.

Jared: In your workshop, you’re also talking about adaptive content which is something I haven’t really thought too much about until you and I were talking about how we were putting this workshop together. In addition to understanding code, you have to understand how the content works, right?

Stephen: Right. How structured content works, every time you make something there’s a reason for that thing coming into existence. There’s a reason why you want to build a particular website, or application, or whatever.

When you focus on what is this thing we’re building, why are we making it in the first place, it becomes a little bit easier to start thinking about content. The most important thing about content…There are two important things. One is that it should come first. Two is that it should be well-structured.

When I say well-structured, the HTML is a language that’s used to add structure to content to tell machines what a particular piece of content is. For example, this is a heading, this is a paragraph, this is a quote, this is a table, or a form, or what-have-you.

It’s very important to have that, because that basis is going to be the basis of how your thing shows up in any device that you can imagine. Any device that can go on to the Internet and read Web pages, and can read plain HTML. That’s why structure is so important in that content.

It’s also because we know what these pieces are. We also have to know how these pieces fit together. What’s the most important? What’s not as important? But in the context of a linear format, let’s say you were just writing a book. You have chapters and within the chapters you might have sub-chapters, and things like that.

It’s good to think about this kind of thing. Everything has content. Every single interface has some kind of content even if it’s just icons which I hate. I dislike leg for example, the iOS interface. I can’t get myself to like those icon-based interfaces. That’s a personal preference.

But even if you have icons, there’s still content. It might be implied content unless it’s done excessively. It always got content. What is that content? It should hopefully be completely relevant to the reason that you’re making this thing in the first place. It should be the starting point of every project.

I did a project about a year and a half ago. I went into a large company. I walked in and within the first two minutes I was there, the project manager came up to me with the content manager. They have this content department. It has a hundred content managers, if you will.

Jared: Are they on the same floor with the developers or are they like…?

Stephen: No. They’re in a different building.

Jared: In a different building? Yeah. OK.

Stephen: Yes. They have a building especially for the content people.

Jared: Does it have special loading docks to load the content in and out? I got meta on you. Sorry.

Stephen: Yeah, you did. You did.

Jared: [laughs]

Stephen: Maybe think of a newsroom in a way for some reason.

Stephen: They’re kind of all in rows. They’re all working for different content for different projects that they’re working on different websites and different products. There’s one person who’s in charge over this particular project as far as content goes.

She was there and the project manager was there. He had this huge spreadsheet. It was like A3 pieces of paper all taped onto each other. I guess four A3 sheets landscaped, taped together. It was huge, took up a huge table.

He’s like, “This is our whole plan. What do you think of it?” I had the advantage of being someone external that they hired to come and help them with this project. Even things that people have been saying for a year in that organization and no one hears them, I could say the exact same thing and they would listen to me. That’s the advantage of being external.

He said, “Tell me what you think of this spreadsheet. We’re starting here with interaction design and then we’ve got visual design. We’ve got this. We’ve got that. We’ve got development. We’ve got content.”

Content was literally the end like it is on most projects. He said, “You could say anything you want and we’ll do it.” I was like, “OK. Take that column of content and move it all the way to the very beginning.” And that was it. That one thing made a huge difference.

It was completely different than any other project that they had worked on just because they did the content first. What that ended up being is the content people had less work to do, because they only had to worry about the content that they really needed to worry about.

They didn’t have to fill in the blanks of some kind of design where the designers came up with things that might need content. That might not necessarily even be important. The designers could design something based on the content. It fit the content really well.

There was a little bit of back and forth there as well. The developers who were involved from the very beginning which meant that they knew exactly what was going to be done. They could start playing around from the start even though they didn’t know from the very beginning exactly what things would look like.

They knew what the idea was. They kept having these meetings all the time. It’s almost like an agile type of process. By the time the comps were done, really there wasn’t a whole lot more to be done to get the thing live. It was a fantastic process.

They saved about like 700 or 800 hours compared to what the developers had estimated they would need. That’s a lot of money for them. It’s just a huge amount of money. They had between 20 and 25 percent conversion on this. It was mobile-specific, this project.

But they had like 20 to 25 percent conversion in one week. It was a little over a week. That was just an incredible success story for the owner of that project. He was like the king in that organization for a while. But it’s just an example of what happens when you simply move content to the very beginning of your process. That was the thing.

Jared: In your workshop, you’re going to show people how to do just that, to move it to the beginning. How to then build a workflow around that, and even show them that they don’t need to be scared of just a little bit of code just to pull this off. Right?

Stephen: No, and developers don’t need to be scared of a little bit of sketching. We’re going to do some of that as well.

Jared: When they come to the workshop, they should bring their developer with them.

Stephen: That would be the way to do it, yeah. That would be fantastic. It would be great to have a developer, a content strategist or content manager, the visual designer and an interaction designer, and you know what? Bring the client, because that’s part of the thing too, is having your client involved throughout the process.

Which avoids the problems that you have when you go away for three weeks and do what Mark Bolton calls the big reveal where you come back and you show these beautiful Photoshop comps, and the client’s like, “Well, it’s not totally what I expected.” Then you have to go back and do all those changes.

Jared: Can you make the logo bigger?

Stephen: Yeah, and then make that bigger in the desktop Photoshop comp and do that in the mobile smartphone Photoshop comp and, again, in the tablet Photoshop comp. Then that for every single comp that you’ve made. Want to avoid that kind of thing.

Jared: Bob from accounting wants this language changed.

Stephen: Yes, exactly. It actually happens that way.

I literally had to change the font size of headings in a design where we had, like, upwards of 20 comps. In Photoshop, you go in, you select the headings. I tell this story all the time. You select the heading, you make it bigger.

But a designer doesn’t just go in and select a heading and make it bigger and then call it a day. That affects all the space around the heading, so they have to move other things around as well. Eventually, you have to make the document larger, just because things have pushed down so much.

Then you get to go and do that for 20 other comps. That’s one change. Then the next day they have another change, because John from marketing was on vacation and just got back today. [laughs]

Jared: Yes, that’s right. He’s looking at this for the first time and wondering why we’re doing it that way.

Stephen: Exactly.

Jared: Hey, Stephen, this was awesome. I’m really excited about your workshop and we’re going to learn so much. It’s going to be fabulous.

Stephen: Looking forward to it.

Jared: If you are interested in coming to the workshop and bringing your developer and your content person and your interaction designer, in fact, we will give away an award for the person who brings the biggest team with them. You can do that, you can go to uxim.co and look for Stephen’s full day workshop, which is called Optimizing Responsive Workflows with Structured Content, and you will not be disappointed.

It’s going to be a fabulous day and you’re going to come out of there knowing exactly what you need to do to get your workflow producing really great designs and the content working with the designs so effectively. It’s going to be so much fun.

Stephen, thanks for taking the time to talk to us today.

Stephen: Thank you.

Jared: I want to thank our audience for listening and, as always, thank you for encouraging our behavior. We’ll talk to you again next time. Take care.