Karen McGrane – Mobile Strategies for Your Content
Podcast: Play in new window | Download (Duration: 34:50 — 18.2MB)
Subscribe: iTunes | Android | RSS
Ensuring that your site is responsive or adaptive is becoming essential to your mobile design strategy. With the plethora of devices available, users want to be able to access your site on whichever one they’re using. The days of the separate mobile site are gone. But as your design is reflowing to display perfectly across devices, what’s happening to your content?
Karen McGrane is the go-to expert for content strategy. She reminds us that responsive design is a technique and not a silver bullet. It’s an important technique that, along with others, can help solve the larger design problem. After all, if the layout of content is confusing or simply lost in the design, the site itself won’t be very useful.
Simply tacking a responsive framework on top of your existing site will often end in disappointment. Image sizes need to be adjusted, headlines get truncated, and you need to go back and take another look at design decisions previously made. Having a solid strategy about how and what your site will display across devices will go a long way to developing an asset and content management system to accompany it.
Check out Karen’s daylong workshop from the UX Immersion Mobile Conference, now in our All You Can Learn Library.
Recorded: December, 2013
[ Subscribe to our podcast via 
←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]
Full Transcript.
Jared Spool: Hello, everyone, and welcome to another episode of The SpoolCast. Today I have with me the wonderful, the amazing, the awesome Karen McGrane, author of “Content Strategy for Mobile” and returning as a speaker to this year’s UX Immersion Conference, which is going to happen on April 7th through 9th.
She’s going to redo her fabulous sellout, “Adapting Your Content for Mobile” workshop, which, if you did not get into last year, you definitely want to get into this year because it was really just quite stunning. We are going to talk to her today about the crazy behind getting content ready in a mobile world.
Welcome, Karen. How are you?
Karen McGrane: Thank you. I am really happy to be here. This is one of my favorite podcasts to do.
Jared: [laughs] Excellent, excellent. We will at some point get the list of the others. You and I were talking, and we got on the subject of the evolution of awareness of content on your mobile site.
My clients, and apparently your clients too, seem to be, they get all excited about mobile and then it all sort of evolves from there. What’s the evolution that you see?
Karen: So, the process that I see a lot of organizations go through, it’s like… Step One: They have the realization like, “Oh, we need a mobile website.” They look at their analytics data or they see what their competitors do and they’re like, “Oh, we’ve got this mobile thing. It seems like it’s getting big. We’ve got to do something.”
Jared: That’s right. Or they just try to look at their own site on their own phones.
Karen: They realize like, “Oh my goodness. Look how often I’m on my phone. This thing is glued to my hand. Maybe our website should work on it.”
And so, Step Two is, Let’s use responsive web design. Responsive web design, that’s the big buzz word, the secret. That’s the trick. That’s what we’re supposed to be doing right now to ensure that our website looks great on whatever device the user wants to use it.
And then, step three is a moment where they just go, “Oh, crap.” And they realize that they have way more problems than responsive design can reasonably solve.
They have problems with their content, with their underlying processes. They have problems with their contact management technology, possibly with their asset management systems and processes and kind of overall they have organizational problems.
They have existing silos. They have incentives that don’t encourage people to work together. They have people who don’t feel comfortable or confident making decisions on mobile and they realize that they have way bigger problems to solve.
Jared: That is exactly what I have seen, this shock of all the skeletons that have been somehow mounting up in the closet without their knowing it, though I guess if you had skeletons, you would sort of know that they got there, wouldn’t you?
But it seems to me that there is all of this stuff that over time they have just been ignoring and they have created this. I don’t know, what do you call it? Content management debt? Asset management debt? It is all this stuff, which now they want to move to responsive, suddenly they have to deal with.
Karen: I think there are a number of organizations that are operating under the mistaken impression that responsive design means that they can build a mobile website, or build a website that works on all of these other platforms, and not have to solve any of these larger problems.
Jared: I have seen that. I have clients who are completely of the belief that there is no technical debt on the mobile product. Right? If we do a mobile app or a mobile site.
You can start from scratch and there is no debt there and that there is nothing that is going to get them until starting asking about, “Well, what about this thing that I always use? How come I can’t get to that?”
Karen: We have all of this existing content, we have all of this existing infrastructure, we have all the same people. None of those things change, so you think you can build a mobile app or create a responsive site.
I get the sense that some people really going in with this hope that they can just wave a responsive magic wand over their existing website and automatically, it’s just going to go work on all these other platforms. That could be not any further from the truth.
The truth is that making good decisions about what you are going to do with your content, what you are going to do with your infrastructure, how your people’s jobs are going to change.
How their incentives are going to change, how their processes are going to change, all of that is probably more important to work through and more complex.
It’s like the responsive design piece of it, the actual front-end design and development techniques are really just the tip of the iceberg. The challenge is that organizations run into is like, “Whoa, this iceberg is huge.”
Jared: Yeah. It’s like, “Oh, wow. It just goes down forever.”
Karen: Yeah. I think there’s a sense in the design and development community of wanting to be very clear that responsive design is a technique. It is just one technique in the arsenal.
It is designed to solve specific layout, and design, and technical problems. The fact that organizations encounter problems that are beyond the scope of responsive design to solve, is not a fault of the technique.
It’s not that responsive design isn’t a good technique because they encounter these other problems. I think that is clearly true. Responsive design is a fantastic technique. It is as I think everyone takes pains to say. It is just one of the tools in our arsenal.
I think the fact that as organizations are trying to implement responsive design. The fact that they immediately bump up against all of these other problems. I do think that all of the people in the community that are advocating for responsive design also need to be articulate about other techniques that we need to put in place to solve these bigger problems.
I don’t think we can ignore the content problem or the content management problem or the design process problem. I think all of those, even though they’re not technically part of the technique of responsive design, it still fall under the umbrella of what happens when you implement a responsive design.
Jared: So let’s talk about that for a moment because I’m intrigued by some of these problems that people run into that they just don’t expect to hit when they first start out in a project. What are some typical ones that they just run flat into and it takes them by surprise?
Karen: I heard one great anecdote. I wish I could tell the full story or even the name of the company but one great anecdote from a very large corporation that basically said, “We just spent an unbelievable amount of money trying to make our existing desktop website responsive.”
They said, “We generally went into this thinking that we would be better off if we took what we already had, like we knew we liked it. We were happy with the website, so why mess with a good thing? So let’s put the effort into taking what we already have and trying to make it responsive?”
Six months later, they have a thrown up their hands and said, “That doesn’t work. We have spent six months and a ridiculous sum of money and we’re basically going to have to throw it out because it just doesn’t work that way.”
There was this real sense of them saying, “We went into this with the best of intentions. We really thought this would be the best way to handle it and it turns out so horribly wrong.”
I think, to me, that seems like the crux of the issue, is you aren’t going to just be able to take what you already have and squish it down. You’re going to have to go through and reevaluate the design decisions, the image sizes, the asset management infrastructure, the content management infrastructure, and your going to have to change some things. I think it’s daunting to people to realize, “Oh, even though we thought we were just implementing responsive design. In fact, what we are doing is a complete redesign, top to bottom.”
Jared: Yeah, I think that there’s definitely something to it. I mean stuff like not even realizing your headlines were written for this wider world that suddenly in a shorter world, the headlines just don’t tell you anything.
Karen: Right, or that you don’t have the right, as you call them, trigger words at the front of the headlines. You’re thinking, “Oh, we’ll just drop some ellipses in there.” It’s like, “No, now it says nothing.”
Jared: Right. “Breaking news…” for 20 different headlines.
Karen: [laughs] Right, exactly.
Jared: Probably not even breaking news, breaking ne–.
[laughter]
Karen: Yeah, people send me all kinds of hilarious examples of bad truncation. I’ve got a whole folder of them now.
Jared: [laughs] A lot of it has to do with just not realizing you built a lot of what you have with all these assumptions of having a lot more pixels to play with and that things would all be in a certain order, in a certain way.
Now, the responsive website wriggles that all away so that you’ve got too much content. People are now having to scroll just to get to the basic call to actions or all sorts of crazy like that. Is that the sort of thing that we’re talking about?
Karen: Yeah. I think part of the root of it is that there’s this ethos that we really all try to evangelize in the mobile space which is you should serve the same stuff to every platform.
You should aim content parody where you aren’t thinking of mobile and desktop is being completely different silos, completely different experiences. Your goal, first and foremost, should be to get all of the same stuff onto every platform.
You could see how a client, a decision maker could reasonably say, “Oh, OK. We’re supposed to serve the same stuff to every platform. Well, we’ll just take what we have and we’ll try to serve it on mobile.”
You need to explain, “Well, yes, you should serve the same stuff but it can’t be exactly what you have on the desktop right now. Your going to have to go through and evaluate whether it’s any good.”
“You are going to need to assess whether, what’s a page? The container of a page is likely to be different on desktop versus mobile or on a larger screen size versus a smaller screen size.”
If your thinking about going responsive, you probably need to strike a balance between those two form factors and do something different than what you might do for either one, if you were thinking of each on in isolation.
You might need to develop alternative forms of some chunks of content. The shorter headline example is one that I use a lot. You might need additional little summaries for pages that can serve for navigation, or other cues that help people to know what’s going to happen when they tap.
You might even need to think about how you present content. What’s the right form factor in which to present content? One example that people always give me is, “Well, what if the whole point of this page is this comparison chart, a big product comparison chart. That’s why the user is coming to the page?”
I’m like, “Well, the point of the page isn’t the table. The point of the page is that the user wants to compare two products or something that might be presented as a sizing chart, in a tabular format, on the desktop.
A tabular format might be the best presentation on a large screen size, but that doesn’t mean that the user’s goal is to look at a table. It means that the user’s goal is to say, “Will these pants fit me?” Or, “Which of these two products meets my needs?”
You might need to come up with a completely different separate presentation or interaction model on a smaller screen size. You have the same content and the sizing chart is not going to change.
The product comparison is not going to change but on a smaller screen size, maybe you need to turn it into some kind of Q & A wizard format, or drop down, or you have to find different visual and physical techniques to communicate the same information.
Jared: It’s interesting, right? The funny thing is that those comparison tables, they never work to begin with. I mean I’ve spent so much time watching people look at these comparison tables and not understand what they’re looking at.
Part of what’s happening here is that when we start to rethink the size issue, the fact that we don’t have all that real estate to play with anymore, we realize, “Well, OK, what’s the most important thing?” “Well, we don’t really know what the most important thing is.”
I remember doing this study of major electronics retailer website. They had this comparison table of cameras, different cameras. They would have line items like burst rate.
For the first camera it would say, “12 FPS.” Then the next one it would say, “14 FPS.” The next one it would say, “Yes.” [laughter] Users would look at this and think, “I have no idea what this is.
I don’t know what a burst rate is. I don’t know if a lower number is more important than a higher number. I don’t even know what they are trying to tell me when they say, “Yes.”
What they really wanted to know, the burst rate on a camera is actually when you’re taking multiple pictures. How quickly can you take pictures?
It’s important when you’re taking pictures of your kid’s soccer game because if you want to get that one shot where his foot is in the right place and the ball is heading straight toward the goal.
The way the real sports photographers shoot, is that they just hold down the take a picture button and just go pu, pu, pu, pu, pu and hopefully one of them is the one they wanted.
The burst rate is the time between each of those pictures. The faster the burst rate the better but that means a faster camera and an a more expensive camera. You have to decide if that is important.
They never say that. They never say any of those things. They just assume that you already know what you’re doing. A lot of the stuff that we have on our website, is written from the view point of people who already know all this stuff.
Then they’re shocked when they realize that no one is figuring this out. Of course part of this is, when you go and ask a question, well, which part of this is the most important thing, well, suddenly you’re now in this situation where you can’t tell.
You’re stuck. You’re like, “Well, wait a second, we have to rethink and reevaluate the information we were giving all along. Maybe our full website information is broken.”
Karen: This is fantastic. This is phenomenal opportunity for organization to go in and fix things that have been broken for a long time. I can understand companies’ hesitation to invest too much in mobile before they really feel confident that they know what they’re doing.
This is obviously a space that is in a lot of flux right now. The interaction models for how people engage with content on the mobile Web really haven’t settled down yet. I think that I can understand why companies want to take a wait and see approach to jumping into mobile.
On the other hand, I just want to grab them and say, “You are never going to get a better chance to fix what is broken with your Web publishing processes.” In fact, you may never get a better chance to fix what is broken with your underlying old structure, with your content management technology.
This is the chance. This is the inflection point where you can look at it and say, “We’re going to make our content better. We’re going to have our teams work more effectively together.”
“We’re going to look at some of the things that just haven’t been working and we’re going to clean them up. We’re going to simplify them. We’re going to make sure that what we’re doing meets our users needs. We’re going to step wasting energy managing and maintaining stuff that isn’t providing value.”
Huge chance to do that. I really believe that the smart organizations are the ones that are looking at this problem and saying, “Yeah, we’re going to use this as our opportunity to make a lot of thing better.”
I think less smart organizations are the ones that are doing the exact opposite. They’re creating mobile as yet another silo, in their organization. They are adding in new technology.
I hear people saying, “Well, we’ll just add on a mobile CMS.” A mobile CMS, what are you talking about? You have one set of content. You have one set of people that manage that content. Don’t add new silos to your organization because I don’t know when it will happen.
If it’s three years from now, or five years from now, you’re going to come back to me and say, “Oh, we can’t manage and maintain this content. It’s a mess.” I’ll be like, “Yeah, if you’d fix that problem three years ago, it would have been a lot easier.”
Jared: Oh, but the idea of another mobile CMS and if we’re going to make it right, we need to give them a completely different log in password. [laughs] It’s just one more thing and different UI for it and everything.
So that when you something in one CMS, you have to put it in the other CMS. Oh my gosh, that sounds like hell. Take me out and shoot me right now.
Karen: You can just see how this is going to happen in some companies. They’re going to wind up with teams that don’t have any incentives to work together. That infect have disincentive to work together, completely separate systems.
For a while I can see, if I were a lawyer in a heavily regulated industry like health care or financial services, I would be all over that just to say, “No, we do not have two completely separate systems,
Where if legal regulations change or we might need to provide emergency information. We’re not updating that in two different places.”
Jared: Or just the compliance checks on two times everything.
Karen: Yes. You do not have the resources to waste on that.
Jared: I mean it’s bad enough that you have to deal with some sort of globalization when you’re trying to figure out how you keep compliant in both, for instance, French and English, if you’re Canadian.
Karen: There’s so many things out there where i want to say, “This is already hard enough. You are already struggling to do a great job with the problems that you already have.”
Now we just added on this exponentially more complex problem. Here’s your chance to look at it and go, “We need to simplify.”
Let’s figure out what we can do really, really well and this is where something like responsive design comes in. Let’s clean up our content. Let’s get rid of the garbage.
Let’s streamline what we present. Let’s makes sure that everything we offer on our website adds value. Let’s make sure that we’re providing the right information in a form that makes sense to users. Then, let’s just serve the same stuff to everybody.
Jared: That makes perfect sense to me. I’m wondering about this. Let’s say I’m game on this. Now, for years, we’ve been telling our clients that you don’t want to just redesign your entire site at once because that’s just opens up too many problems and too many holes. It doesn’t really give you a chance to learn anything.
You want to do it in small pieces so you can design the process of learning into your development process. Of course, things like lean UX now, are saying basically the same thing, which is you make small changes and you do it very fast. You get to learn all the way through.
One of the push backs that I always get on this, is infrastructure changes like the CMS, like the underlying content, like the underlying servers, it’s really inefficient to do that in small pieces, that you really want to do the whole site at once and just get it done.
Let’s say I’ve bought into this idea that I do need to create a single content management system is not going to work much better than the one I have. It’s going to be a better publishing. It’s going to help me when I’m dealing with smaller screens, and larger screens and slower bandwidth, and higher bandwidth.
I’m going to have all that set. Do I have to do it all at once? Or, can I break it into little pieces and learn as I go along?
Karen: Yeah, you’ve really well articulated a problem, I think, most, especially big companies have, where you have this huge website and you can’t schedule an enormous two, three year long project to redo everything because that’s not going to work.
Here’s what I’ve been recommending is something I’m thinking of as using content management system or even a very light weight version of a CMS as a platform as you use to support the content editing, rewrite, restructuring, and migration process to a new site.
Think of it this way, for a lot of companies, touching the desktop mother-ship, it’s difficult, it’s the political third rail of getting stakeholders and competing interests, getting sucked into the organizational quick sand.
Jared: It’s the third rail while you have a foot in the puddle.
Karen: Yeah. One of the things that can be really positive is to say, “Let’s build a new responsive site that, for the time being, is only going to serve smart phone and tablet form factors.
Let’s treat mobile, let’s treat other devices as that’s going to be the focus of the responsive site, with the intent that once we get that responsive site to a place where we’re happy with it, then it will grow up and overtake the desktop site.
That, I think, can get a lot of traction because then you’ll be able to go back to the organization with some actually numbers and demonstrated success on this new site.
If you think about that, what’s the process? How do you get there? Well, I also then, recommend that organizations think about putting in a light weight version of whatever CMS they’re hoping to move to so that they can use that tool to support the content, editing, restructuring, rewriting, evaluation process.
Right now that process, that could easily take a year to go through everything. You have a team of freelancers and your existing team. You need tools to manage that editorial process.
As much as I love an Excel spreadsheet, I like love me some Excel spreadsheet. Excel spreadsheet is not the best tool to help you manage that.
Whether or not you can do this is going to be based on the organization, but I do a lot of work with Drupal. Put in a version of Drupal. A light weight version that is never intended to publish to the Web.
It has some editorial work flow that is built into it to help you track the status of where things are going and pull everything out of your existing site, put it in Drupal, and then use that CMS to manage the rewrite process. Track changes, manage the editorial and approval work flow.
You get two things out of that. One, is that you give your team a chance to actually work with the system. They’re going to be able to go in there and bang on it quite a bit to figure out what works and doesn’t work for them. They’re going to have much more well-informed opinions about how they want things to work in the real production system.
Two, once they get through that process, it’s going to be so much easier to get the content out into the “real CMS” because you’re going to be migrating right out of that system or you can do it directly from an API.
You can set up those content models, set up the editing interfaces, admin interfaces. It’s right there in that system and then, have a much easier time getting that content back out.
To me, this solves several problems. It lets you focus on designing and iterating in the mobile tablet space first. You might even pick a section, I think most people will say, “Let’s pick this section.”
Jared: Like investor relations.
Karen: Yes, let’s pick the investor relation sections. Let’s pick the white papers section.
Jared: Something that is important and needs to be done well but isn’t so massive that you just can’t get your head around it and probably won’t stop business, if you screw it up. Healthcare.gov style.
Karen: [laughs] Then, you can launch just that section in a responsive version for smart phones and tablets and keep adding to that, keep refining it. Then, over how ever long that takes you, when you’re done, you have a completely functioning site that’s been cleaned up, that’s been edited, presumably works a lot better.
You can demonstrate the value of that approach to the organization. Then, presumably go back and say, “Now, we’re going to take what we’ve done here and we’re going to make that desktop site too.”
Jared: That’s great. I like that idea, because you get that ability to learn as you’re going along without taking too much on at once and without dealing with the political issues.
I mean the nice thing about doing something like investor relations is that, sure there’s a group of people for whom the stakeholders are there but not everybody in the organization has an opinion on investor relations.
There’s a handful of people that probably all work in the same floor. You can meet with them and you can say, “OK, we’re going to start with you guys.” You’ve narrowed the scope of the stakeholders that you’re working with.
Once you narrow the number of stakeholders down, everything gets a lot easier.
Karen: It’s gives you a chance to sort through how is the design process going to go. Those stakeholders, what are they going to be looking at? It’s probably going to be different from what they’ve looked at in the past.
You can use that as a test care to say, “Oh, OK, here are the things that people are struggling with. Here’s is something that our stakeholders are still begging for Photo shop comp. How do we make them feel more comfortable with this new process?”
You can go through the legal process. The legal review compliance review. You can go through all of the executive review and approvals that you need to do. You do it in a microcosm with the intent of saying, “OK, let’s try to learn as much about how people respond to this.”
“What they struggle with so that when do the next thing, we’ll feel a little bit more comfortable about where we need to spend our time. What kind of explanations we need to give to people so that they know what they’re looking at.”
Jared: OK, so related to this, there’s a whole bunch of conversation happening now about how the designer’s work flow changes because of responsive. In fact, Ben Callahan is going to be at the same UX Immersion conference talking about how work flows are changing and how to deal with new work flows because of mobile.
Part of that is, when you have the stakeholders, what deliverables do you give them? What do you show them? When you’re iterating in this faster mechanism because you can’t just do a Photo shop comp and send it over the wall and say, “Do you like it?”
“Oh, good, you approve that, yes, that’s exactly what we’re going to build,” because everything is slightly different depending on the size of the screen and the amount of bandwidth and all of these things that are happening.
The work flow process has had to change, so we’re seeing that. The same is true for content. In fact mobile does change how we think of content and deliverables and how we present to stakeholders, not just what the design will end up looking like but also, ongoing, what the content ends up being.
Let’s say you’re a news organization and suddenly you have a story that requires being covered from lots of different aspects. You want to have a special feature where you take six different writers perspectives and you put them all together in a package.
You say, “This is our special bundle feature of covering the shutdown,” or whatever it is, the hurricane. Now, you need to think about, “Well, how do I manage that content in that new bundling mechanism?” You have this problem of because of responsive, you have to rethink your work flows. Yes?
Karen: Yes. You have to rethink, to me, and obviously I’m biased here toward that. It is the same problem that we’ve been struggling with on the Web since day one.
Which is how do you ensure that the content informs the design process and how do you make sure that the design process is then is reflected in your ongoing content, writing, and editorial process?
Jared: Right, because the last thing you want to hear is, “Yeah, we can’t do that because our design won’t let us.”
Karen: I’m sorry, that content won’t fit into the design. We should be past that, but I fear that challenges of responsive, the magnitude of the changes that have to happen in the design and the development work flow and the magnitude of the changes of the content work flow.
Mean that i fear that we will see some projects where it’s like, “Oh, that’s right, these mistakes. We’ve made these mistakes before, how are we making these mistakes again?”
Where to do responsive really well, to me, the foundation of it should be that you are reevaluating your content. What it is? How much of it you have?
What constitutes a page? How much stuff can you fit in the container of a page, when that container changes size and shape? How long should things be?
The challenge there is that those decisions might get made separately or on a different work flow from a lot of the design and development problems. As the designers and the developers are trying to figure out.
How do we move away from wire frames and Photo shop comps to a much more fluid, in the browser, design process at the same time, you have a content team that’s going through and doing a massive rewrite and editing and restructuring process of the content.
You really, I think, need to be very careful with how those teams intersect, how you make sure that some of the right decisions about the content, at least how the content’s going to be structured, are made upfront and early so that that information can inform the design team.
And that, then, as the design team is playing with those pieces, whatever they’re learning about how it works on different pages feeds back into the content team and, potentially, into the underlying structure in the CMS.
Jared: Got it. This has been really just eye-opening for me. Just listening to you talk about this content stuff is always so amazing. It is something that I know a lot of organizations are struggling with.
And I’m really happy that you’re out there fighting the good fight and helping folks get their head around exactly how this works and how to help with this. I know that your full-day workshop at the UX immersion conference is going to really help folks.
Those people who are at that juncture where they really need to start thinking about, “OK, what are our options? What’s going on here? How do we move forward and get our content in a process and in a set of tools that we won’t have to revisit in three years and redo all over again?”
Karen: I hope everyone can tell how much i love talking about this stuff. It’s one of my favorite subjects, and nothing makes me happier than when people show up and let me talk about it for eight hours in a full-day session.
My friends and family are understandably less enthusiastic about me talking about this subject endlessly, so i look forward to seeing some people in Denver and having a chance to discuss it it with them.
Jared: That’ll be awesome. Yeah, you guys can come and show up at the UX Immersion conference. It’ll be April 7 through 9. Karen’s going to do her full-day workshop on the ninth, but you can check out the whole conference.
Because there’s a lot of good stuff going on there. That’ll be in Denver, Colorado, our first time doing an event in Denver in many years, so we’re very excited to go back there. You can find out about it at uxim.co. That’s for the UX immersion conference, dot C-O. We will see you there.
Karen, thanks again for spending such wonderful time making us smarter.
Karen: Thank you for inviting me.
Jared: Excellent. I want to thank our audience for once again listening to the show and, of course, encouraging our behavior. We love you. Stay tuned for more of the podcasts, and we’ll talk to you soon.
Take care.