Episode #267 Steve Fisher - Content Modelling for Responsive Projects
It’s no secret that the content on your site needs to adapt to a variety of viewing environments. Responsive and Adaptive Design have been wonderful for ensuring your design flows and displays appropriately for the multitude of devices out there. But what about your content? How can you be sure your content is in the right place, or even makes sense in these different contexts?
Full Transcript[powerpress] [ Transcript Available ] It’s no secret that the content on your site needs to adapt to a variety of viewing environments. Responsive and Adaptive Design have been wonderful for ensuring your design flows and displays appropriately for the multitude of devices out there. But what about your content? How can you be sure your content is in the right place, or even makes sense in these different contexts? Content Modelling is a way to develop frameworks, prioritizing your content from essential to nice-to-have. In his virtual seminar, Content Modelling: Creating Responsive Content Experiences, Steve Fisher shares his process for creating a content model. He takes you from understanding your audiences through goal setting all the way to the finished model. Steve received a bunch of questions during the live seminar and he joins Adam Churchill to answer some of those in this podcast.
- Who do you invite to the content modelling workshop?
- How often should you revisit or review a content model?
- Does documentation and sketching early in the process make the design too prescriptive?
- How do you approach multi-language projects?
- How can someone acting as a “team of one” set content priorities?
- When do you prioritize mobile over desktop or vice versa?
Adam Churchill: Hi, everyone. Welcome to another episode of the SpoolCast. Recently, Steve Fisher presented a UIE virtual seminar, "Content Modeling -- Creating Responsive Content Experiences." The recording of this seminar, along with 220 other UX seminars, is now part of UIE's "All You Can Learn" library.
For 90 percent of the people who start a task on one device and complete it on another, how do you make sure your site's fundamental message remains clear? In a multi-device world where your content can live almost anywhere, content modeling helps content adapt consistently. In his seminar, Steve showed our audience how to move from a static website to a responsive one and gain control of unstructured, disorganized content for good.
Hey, Steve. Thanks for coming back to the program.
Steve Fisher: I'm happy to be here.
Adam: For those who didn't listen to your virtual seminar, can you give us an overview of what you shared that day?
Steve: I sure can. What I shared that day and what we looked at was a two-part thing. One was establishing this framework for success, and within that framework we're talking about how teams work together and how they can agree upon decisions and setting priorities.
That starts with understanding your audiences, who they are as real people, and prioritizing them, getting into your user experience vision or your project vision and agreeing to that as a team, too, based upon who the audiences are, looking at your design principles, the "why" statements, those guideposts that help you make decisions as you go along, and agreeing to those as well as a team.
Finally, goals. These are high-level goals, so they don't get quite as in-depth as we may go with a lot of projects, but right here we're able to say, "This is what these audiences need, what this vision says we are heading towards, and how our design principles are guiding us."
Those four things help us as a team have a framework to make decisions so that we can agree upon things that aren't just based upon our opinions. They're based upon what our audiences actually need from this website or this web app.
After that, we moved into the content modeling itself and setting the priorities. Taking a look at larger content types, or what sometimes people call content templates, and then the smaller chunks within those, the modular blocks that might be a page title, a piece of intro copy, related content, different things like that, and setting the priorities of each one of those inside each content template or type.
We would set those into three priority groups, one through three, being essential, all the way down to nice-to-haves. We have to agree upon those as a team. It's really the agreement that becomes key rather than compromise. Because we're basing that on the framework that we tackled before, we really can jump into that and get outside of ourselves.
At the end, we just sketch those out. We take just really rough documents and sketch out those on a white board or a piece of paper. If someone wants to do it immediately in code, they could, but usually it's just a sketch. That allows us to visualize these priorities across multiple screens.
That's basically what we tackled on the virtual seminar.
Adam: There were a bunch of questions that rolled in. Who does this? You talked about a content modeling workshop. Who do you invite? What are the rules you need to have there? How big does that team need to be?
Steve: It's a great question. The team can really flex in size, and sometimes we can get all these people in their individual roles, and sometimes it's two or three people that are each covering multiple roles.
The key roles I'd like to see represented, whether that's your actual title as a person or that you're just playing that role, is someone that could be a user-experience lead, a content strategist, developer, someone that is the client project sponsor, someone that can make decisions for the client themselves or for your internal team, an IT lead, and then a content specialist on the client side or an internal stakeholder content specialist.
If we could have those six people, that would be a fantastic core team to do this with, but sometimes there's only two or three people and they have to play multiple roles.
Adam: How often do you revisit or review these content models that you come up with?
Steve: That really depends on the project, but I don't like people to map this out once and then just walk away feeling like it's magically never going to change and that everything was gotten right the first time.
My recommendation to most teams is to try to revisit it, at least initially, after your first draft, within a month, and then another month after that and another month after that.
Then, after that, you may spread it out just annually, but this revisiting can be quite lean and agile. You may just come in and say, "We're going to look at it for another morning, as a team, review, test with some external or internal stakeholders to make sure it's working, and then adjust."
If it's a very large project with a large team, or even a small team and still a large project, you're probably going to have to do this multiple times anyways. Coming back as frequently as possible for that in the initial stages is excellent, and then reviewing maybe annually or every few months.
Adam: Steve, in that process, does documenting the model and then sketching a UI this early in the process make your design too prescriptive? What happens to those designers that jump in later in the process?
Steve: I could see that happening, actually. I've talked with designers in the past, where they're given a wire-frame or something, or maybe it's a content model and a wire-frame and they're told, "Just put the lipstick on this," so to speak, and they're not given a lot of room to move.
They're not given any ability to change things. Really, their creativity and what makes them a good designer, the way they think about things, is stripped away.
A way around that is, actually, they should be involved early on. Perhaps they're one of the people playing the role in this team, or they get to come in at the workshop at certain points and give input, so that they're part of the decision-making process early on.
That way it allows that creativity, but also just them to be in there using their designer's mind, so to speak, to really help solve these problems, to really understand and give input. That's why we have this diverse team and it's not just one role that's doing all this content modeling and sketching work.
The other side of it is to be clear that this is just an early draft. This is to help us understand priorities. This is to help us to represent those in a very rough sketch of UI, but it should be repeated over and over that this is not final.
Things will probably move around. We need to test this. We need to see what's actually going to work, so that we can set the expectations that as different roles start getting more and more involved, they have a little bit of freedom as long as we're still representing the priorities and what it is that our audiences need and fits our vision. Everything that's part of that framework.
Adam: Steve, what about projects that have multiple languages, maybe an international user base? Talk about that a bit.
Steve: That can be tricky, especially...I'll give you an example, actually, that will highlight this.
I was working with an airport authority out here in Vancouver, Canada, and they have their website in English and French. It's translated into a few different languages. One of the languages that it gets translated into is Chinese, which is very, very different.
It's read differently. The culture is quite a bit different. Of course, the characters are very different. It's not even just that you can drop in a translated version. It's that the priorities might actually change on what content we're presenting first based on cultural significance, or how people read things, or how it's presented.
For multilingual sites, it's important to take a look at the languages themselves, the countries where this will be accessed and how people think about things. It probably means going back and doing the content modeling workshop and exercise again for those particular languages.
This could be prohibitively expensive for some teams if they're trying to translate to 100 different languages, but if there are some key, priority countries or languages or contexts that you know you need to be represented in, go back, do those again, and then create these revised models and sketches for those particular languages.
Adam: Steven, in the questions pod during the presentation, there were a lot of people that said, "We get it. We completely buy into this. We want to do it," but how do they sell it? How do they sell it to their clients? How do they sell it internally to stakeholders? How do they make that argument, that it's worth the time and money to do content modeling?
Steve: I think they can just tell people it works. No, I'm kidding.
Steve: For me, I do like to look to past examples, past projects, and say, "Well, this is what we did, and this is the outcome of that."
If you haven't done this before or you don't have enough examples, that's not an option, but what I do tell people and what I show them in the process that I lay out for them is that this isn't going to make things longer or more expensive.
In fact, it's going to speed up communication. It's going to help us solve problems earlier on, which will prevent a lot of extra design, content, and development time later on, where we're guessing and we're correcting things or we're changing things as we go along, because our designs, our content, our development wasn't as informed.
When I go in, I usually just talk to the bottom line of the project to say this will actually speed it up if we spend a bit more time earlier on, and, as a result, it will save you money when you get to QA stages or development, so you don't have to redevelop things.
It hits to the bottom line. That's how I typically convince teams. Honestly, on every project that we've gone through this, it has done that. It has saved time and money.
Adam: Steve, don't be afraid to say, "process." Bring the Canadian right back to the podcast.
Steve: [laughs] OK. I do flop back and forth between the two, but we'll bring out the "pro."
Adam: [laughs] We've talked about UIE's audience a lot. There's a good chunk of folks that think of themselves as a UX team of one. How do those folks set content priorities?
Steve: It can be hard to work as a team of one, although it can also be great, but it's important in this process to actually get outside of ourselves.
As a team of one, at least go through everything here, even if you have absolutely no one to bounce this off of that is officially part of your team. Go through and understand the audiences, set your vision, all those pieces of the framework, but I would encourage teams of one to bring in someone that they can share with, whether that's maybe a business partner that works on sales but doesn't have direct insight into these types of roles, but they can still offer great feedback.
In fact, it's really helpful if you have someone that doesn't maybe understand this, for them to come in and get you focused on the things. If they can begin to buy in, then you know you're hitting the right things.
Perhaps you can bring in other colleagues that are other freelancers, other teams of one, so to speak. As long as you're able to share those things and you're not breaking an NDA, that can also be good. You can learn from each other. Try to play the roles out, even on your own.
It's very rare to be a total team of one, unless you're building your own product entirely by yourself. You should always have a client that you could do this with or some other stakeholder within the company. Make sure that you follow the basic process.
Adam: What about those teams that are wrestling with mobile versus desktop? What about the content priorities there?
Steve: That's an interesting one in that, if we're looking at setting content priorities and we're looking across from, let's say, a website and a native web app, there could be some different priorities set there, and so we may have to do the workshop or go through this content modeling and sketching a few times again, to set it in a very specific context.
My experience has been in most cases the priorities don't change. People are looking for the same things across devices for sure, if it's a responsive site. Even across apps and different things, they're really just trying to accomplish similar tasks.
Occasionally, that changes. I did some work with an insurance company, where they were looking at doing geolocating on mobile phones, because people were actually wanting to right then report their accident, so they set a different priority when it was in that context.
In most cases, people are really trying to look to do the same things, so those priorities can be carried across from mobile to desktop, or even better yet, from small screens to larger screens to different screens.
Adam: Talk about the best methods for testing responsive content.
Steve: Wow. That one's a tough question. There are so many ways to do this, but obviously, getting it out in front of people is great. We can set these content models, we can sketch everything out, and we can be as informed as possible, but until we put it in front of people, we don't really know how it's going to perform. We need to have some sort of prototype to show them.
Now, I use an app called Magitest to help me do some screen recording and recording of the individuals -- their voice, their face -- as they're testing this out on mobile devices. Then I also use Silverback, on a desktop or a laptop or something like that, to do the same thing, with the same people, using the same content on this responsive project. Those are two of my favorites -- by the way, that was favorites with a U.
Steve: Although, those are Mac and Apple-based, but if you have any sort of screen recording, get in front of people and it's in the browser with real content. That's where I've seen the real insights come out.
Realistically, within the first three to five people that you talk to, you find about 80 percent of the problems that might exist. If you see something that's broken at that point, that's not working, you can stop. You can correct. You can fix it right then. You don't have to necessarily go through and test with 20 people or something like that. You can learn pretty quickly this way.
Adam: Steven, great stuff. Thanks so much for talking to our audience about content modeling. Jared thinks it's an important topic that we need to talk more about, so we'll look forward to having you back at some point in the near future.
Steve: Great. It was a pleasure to be here.
Adam: To our audience, thanks for listening in. Goodbye for now.