New Model Army

Content is data.

Sorry to sound so reductive—it is of course art, poetry, music, lively discourse, noble proclamation, informative news, nurturing education, and compelling inspiration. (It’s perhaps ironic that some of the people who give it such a catch-all, brand-X commodity name as “content” are the content strategists sworn to protect it.)

But it is data, even if you take all the technology away. Content provides information about the world around us. It defines, describes, discusses, and debates things and ideas. Concepts. People. Places. Objects. It furnishes us with fact.

Technology helps, though. Tell a computer some tiny stories about the world around you, and it can figure out how that world fits together. Type someone’s name on a web page, and your fellow humans are smart enough to intuit that you’re referencing a person. But apply a little metadata structure under the hood to tell your computer that there’s this thing called a Person and that among their better qualities they have a First Name and a Last Name. Suddenly that person’s name is more than just a dumb string of text. It’s a living attribute of a profile record in a machine-readable database. Go on to tell the computer that this Person has the role of Speaker for a particular Session at something called an Event. Little by little, the computer starts to make sense of the world. Now it understands that this named person is giving a session (at a particular time and place) within your event. So if you were to, say, update their last name, the computer dutifully knows that the change should happen on that person’s profile, their session details and schedule, the list of ­speakers—in fact anywhere they’re referenced at all. A robot army to do your heavy lifting! Content management made easy.

Structure Connects Content

This book covers our process for planning and designing content as structured data and then publishing that content to different user interfaces. That sounds pretty dry and technical, and let’s be frank—later on, we’ll ask you to roll up your sleeves and get into structural diagramming that wouldn’t look out of place on the desk of a database architect. We’re content strategists, but a book on voice and tone this ain’t.

As with all technology, the data wrangling is just a means to an end. Structure provides opens pathways to content from all across the web. Structure opens pathways to content from all across the web, making it easier to locate and to consume. Content wants to be used. It’s there to meet the needs of its audience. You spend all that time and money creating it because you think it will meet a predefined objective. But first, people have to find it. And when they do, they have to make sense of it. This isn’t like the old days, when someone would type your website address into their browser, arrive at your home page, and then descend through your menu trees until, through careful consideration, they arrived at their chosen destination. No, these days people pull out their phone, bash the first thing they can think of into Google, and take advice from one of the top five results. People are arriving straight into the middle of your structure, and they have limited patience to make sense of what they find.

Designing for that behavior means understanding how your audience thinks. We’ll come back to this point throughout this book, so we might as well say it first here: people’s interest in their subject of choice doesn’t begin and end with your content. They’ve come to look at your stuff because they have a particular itch that needs scratching. Maybe they’re looking to buy a house. Or get feeding advice for their new pet iguana. Or relocate to Arizona. Or learn the history of civil rights. Hate to say it, but it’s never really about you.

And you can respect that through the way you structure your content. Whatever field you’re in, whatever topic you publish content about, figure out how your audience thinks about that topic. What’s their mental model? What kinds of things do they consider most useful, and what are those things called? How, in their minds, is one thing related to another?

Design starts from sharing a common language. Information spaces have contextual concepts, relationships, and rules. Structure brings context, and context is how we build understanding. So your most fundamental design is a model of connected concepts within a subject domain. Design your content around their priorities, not yours, and you’ll be better positioned to help them achieve their goals and get a decent return on your publishing investment.

Start Making Sense with Structure

Structure makes sense. Also, structure makes sense. Sensemaking is the term used in the information science and human-computer interaction communities for the process by which people give meaning to an experience. It’s been described as “fitting data into a mental model, and fitting a frame around the data.” That’s a pretty good introduction to the design process you’ll follow:

1. Research and map out a content structure based on the broad subject area you work within (what we call the subject domain—something like personal pensions, medical equipment, or comic book collecting), including how the things in the domain are related.

2. Create content that maps to examples of things in that domain. (In comic book collecting, you might have a thing called Publisher, of which an ­example would be Marvel Comics.)

3. Design your content management system to support publishing based on the structure you’ve mapped out.

4. Design interface templates that will bring your content to every device you want to support.

5. Publish! Measure how well your content is performing, and continue to explore new ways to remix and share it. Make plans for the content you’ll create next.

If you’ve worked on a digital product design before, some of this might seem a little topsy-turvy.

You may be accustomed to a practice in which design means interface design and begins with sketching wireframes (you know, with those squiggly lines that denote “content goes here”). Leaving interface design almost to the end may run counter to your user experience (UX) instincts. But for structured content, you really want to design structure first. You’ll use that to connect content resources (for now, think of those as individual articles on specific topics, a bit like Wikipedia). Finally, you’ll design all the ways you want those resources to be represented. Web pages. Mobile apps. Kiosk displays. That’s where the wireframing comes in. (But hey, if you want to impress your stakeholders with a few early conceptual mock-ups, go right ahead! Even Walt Disney used artists’ impressions to convince his backers long before breaking ground on his theme parks.)

You’re probably onboard with the idea of a research and discovery phase. But the research we’re interested in is about the subject domain itself. And the first people we’ll get you to speak to aren’t users, or even stakeholders, but subject-matter experts(SMEs). Hold on, that doesn’t sound like good UX advice either! Don’t panic—we’re both from a UX background and wouldn’t dream of telling you to skimp on researching general user needs. But our focus is on designing a connected content structure, and that means knowing your subject.

Little Things Mean a Lot

We believe you should design your content structure around real-world things. When people read a web page or watch a video or browse a photo gallery, what’s interesting to them isn’t that they’re looking at a document, a photo, or a moving image. They’re far more interested in the content of that media—what it’s about. Inherent to any content you create are one or more specific examples of concepts. Bob Dylan. The Volkswagen Beetle. The three-olive martini. ­People don’t care about the containers; they care about the things they contain.

Things in the real world have readily understood relationships to other things. The content (for example, a scene from the TV show Mad Men) puts these things in a particular context. But they can also act as gateways connecting us to whole other topics. From Dylan to folk music. From the Beetle to automobiles. From martinis to mixology. If you’ve spent time free-associating via Wikipedia links, you know how that goes.

Even within a topic, linking content based on its real-world relationships helps everyone make sense of it. We all understand that the songwriter writes the song. That the scientist performs the experiment. Or that the giant panda eats shoots and leaves. And should it happen that someone doesn’t know, the link between two concepts actually teaches them something new about how the world joins up.

It’s Design All the Way Down

As we write this, debate rages on Twitter (when doesn’t it?) about what it means to “design” something. Opinions are split on whether it’s fair to say that everyone on a product team is a designer or whether that, um, designation should be reserved for those who come to work with sharp haircuts and their top button fastened, ready to push pixels. The concern seems to be that if everyone is a designer, is no one a designer? And does this open the floodgates for the sales manager to weigh in on what color she thinks the app icon should be?

We daresay such fears stem from a limited notion of design. Digital product design isn’t just the layout, styling, and decoration of the things you can see. Of course, interfaces are hugely important and absolutely require expert care and attention to make sure they’re useful and usable (to say nothing of delightful, distinctive, and de-lovely). But design doesn’t stop at the surface. User interfaces connect people to the business and, more immediately, to the business’s content.

Getting the content structure right is design. Designing the content itself is design. After all, the content is the whole damn point. It’s why people are coming to your product in the first place. But if you start design with interface wireframes, a lot of things get lumped together. Decisions about structure, layout, hierarchy, navigation, and even editorial priority can rest on the shoulders of the interface designer.

By focusing first on structure, then on content design, and finally on interfaces, you separate these concerns. Your cross-functional project team members can each bring their superpowers to bear, and everyone gets to do what they do best. When you do get to interface design, you’ll find decisions far easier to make. As a team, you’ll have a clear idea of how the subject domain would best be represented. Designing from the content out, rather than the interface in, helps ensure that the visual presentation shows off the content at its best. A lot of your navigation decisions will be taken care of by the connections defined in your structure. You’ll be using content itself as a design material to craft the best experience for every device. Think of structured content as the design behind the design.

Teamwork Makes the Dream Work

Design is political. Designing a subject domain, doubly so. You’re codifying a point of view on what a subject is. That goes deep, starting tremors that reverberate through an entire product. Keeping a design project on the rails is a contact sport. It takes influence and persuasion. Clarifying the roles and responsibilities. Getting a high-level commitment to safeguard the things we hold dear.

Designing structure first flushes out complexity early. Puts on the table the things most likely to cause disagreement. When you lay down the first draft of your model, you can be sure of some healthy debate. Get the team and stakeholders aligned on the world you want to represent and you’ll set up the rest of the project for success. Unlike wireframes, models let your team evaluate structure alone. They’re conceptual, which helps project sponsors feel comfortable in lending their business expertise. And they’re technical, which helps engineers understand early the kind of system they’ll be expected to create and contribute to.

Considering structure helps everyone on the team find a level of altitude where they all basically agree. It’s a common ground where everyone can offer valid feedback. Disagreements may come further down the line as you get into content and interface design. But at least you know there’s a place where you’re all facing the same way. Agree on the strategy; argue the tactics.

Becoming Future Friendly

Not every benefit of adopting structured content will be felt right away. In the short term, you’ll build an efficient, richly linked ecosystem that helps users find what they’re looking for and helps your content creators focus on what they do best. You’ll be shaping your content into small, sharable, reusable pieces to get the most use out of them. You’ll have a clear strategy for which content is most useful to invest in.

But that’s just for right now. You’re also setting yourself up for future success. When structured around real-world concepts and connections, content scales up without breaking (just look at Wikipedia’s 40 million articles for proof of that). When you separate content and structure from presentation, you’re in great shape to design interface representations for any new device that comes along. And when that content is described with metadata, right down to the last attribute, then every new device—even those without screens—can offer a completely tailored experience based on the same content. Chatbot? Sure. ­VoiceUI skill? Why not. Heck, people don’t even have to come through your digital front door to get at your content. Do a Google search for movie show times in your area. You’ll get the information you need without ever leaving the search results. That’s not the future; that’s today.

Of course success depends on having good content. The most intricate structure in the world isn’t a lot of use if you’re publishing stuff that no one needs. Later in this book, we’ll share some thoughts about what “good” content means. Researching your audience’s mental model of the subject domain is a great way to start. The domain model you’ll construct maps a territory perhaps larger than the content you can supply today. But that model will still be valid tomorrow, when your content budget is bigger. And chances are it’ll remain so in three-ish years when your board decides it’s time for a website makeover.

We call it thinking “future friendly.” Preparing your content for whatever new devices and modes of consumption may come along. Finding new ways to share your content with people, wherever they are. Building new windows on your world.

Chapter by Chapter

Before we get started, let’s run through what each chapter will cover. While the linear nature of books suggests a production-line process, the truth is that you’ll revisit each major step regularly. Your research informs your modeling, but your modeling can uncover unanswered questions that need more research. Your content design stems from a well-defined content model, but digging into examples of content can quickly uncover all those gnarly exceptions you forgot to account for. As with most projects, there are a lot of plates to keep spinning. Jump around these chapters as you need to.

In Chapter 2, we look at the changing digital landscape. The last ten years have seen an explosion of devices—most notably, the rise of mobile as the dominant platform for consuming digital content. In turn, we’ve all changed our habits in how we find that content through search and social media and how we share it with our friends. To address these behavioral shifts, businesses like yours need to improve how they commission and maintain digital projects. To avoid lapsing into triennial cycles of redesign, a business has an opportunity to set itself up for future success by separating its interface designs from the underlying content structure. By investing steadily in ongoing content management and governance, they’ll make sure the right content reaches the right audience. Respect the role of digital content in driving business success. “The website” is no longer a one-off item way down on the meeting agenda and dismissed as an “IT problem.” If you’re in the business of attracting an audience and growing your customer base, then digital publishing and communication is core business.

Chapter 3 dives into what we mean by “structured content.” Spoiler alert: it’s content that gets broken into small parts so that those parts can be recombined one way on a desktop web page, another way in a mobile app, and a third way when, say, heard through a voice interface like Amazon’s Alexa. For that magic to work properly, you feed the computer some rules about how different kinds of content relate. You tell it that if you’re publishing something about an engineering landmark (such as the Golden Gate Bridge), then that piece will include details like its location, year of completion, and claim to fame. And when you later design a page in your website or app for a landmark, you can make room for those descriptive properties, knowing that the computer has the information it needs to fill them out with specific content. Page designs come and go. Devices and platforms may rise and fall. But the structural integrity of your content can stand firm, making every redesign easier. Designing with structure is a gift to your future self.

In Chapter 4 you’ll start to get hands-on with designing connected content. That begins with researching your subject domain with the help of SMEs, audience representatives, and your own Google-fu. You’ll sniff out the most important concepts in the domain and understand how they connect. You’ll learn which stuff is most important to your core audience and where their terminology or mental model differs from the expert view. You’ll come away able to bluff your way through the subject pretty well, able to help your team understand the world you’re all designing for.

Chapter 5 takes this research and funnels it into the construction of a domain model. It’s a diagram that communicates all you’ve learned about how the key concepts within your subject domain hang together. It acts as a shared reference point for your team and quickly flushes out any misunderstandings or disagreements before getting into engineering, where changes are expensive. The domain model becomes your astronomical chart of the content universe. This is the territory you’ll fill out with content, one piece at a time.

In Chapter 6, you’ll add more detail as the high-level domain model turns into a more focused content model. This is where you describe each of those key concepts through their constituent properties and plan out the various types of content that you’ll eventually bring to the screen. By the end of this, you’ll have a detailed plan for your content’s structure.

We look at content itself in Chapter 7. This isn’t a book about how to write copy or shoot video, but we offer some principles for well-designed content that meets user needs. You’ll use the work you’ve done in content modeling to chop up content into small pieces that the computer connects together based on the relationships you defined. This is where we talk about blobs and chunks—­neither sounds pleasant, but they’ll help you understand the difference between unstructured “dumb” content and super-intelligent structured content.

Chapter 8 covers the back end of content management. You’ll take all your research, modeling, and content design and make it all work for your content management system (CMS). We’ll talk about CMSs in general, why you shouldn’t feel bad for hating yours, and things to consider when shopping for one. Many businesses working with structured content actually develop their own CMS, or at least heavily customize an existing one. But it’s perfectly possible to have a great structured solution with an off-the-shelf product, provided you make the right choices. Planning for CMS implementation adds yet more detail to your content model, spelling out field by field the interface an author will use to enter content according to your designed structure.

In Chapter 9, we help you bring all that content glamour to the big screen.
Or the small screen. Maybe even the chatbot. We’ll look at how interfaces are designed for structured content. Each interface is like a window on the world. Peering through that glass, you experience the vista of content that stretches out on the other side. We’ll look at how each interface can remix different chunks of content. We’ll explore navigation options and how they can come from your original domain model. And we’ll discuss (for what by then will probably be the millionth time) how separating interface design from content design makes redesign projects so much less painful.

Finally, in Chapter 10 we look to the future, because that’s how people normally end a book like this. For some businesses, the internet is still space age. Even today they drag themselves into cyberspace with an enthusiasm reserved for a root canal. But “new media” isn’t new anymore, and the tectonic plates of the digital landscape are forever restless. So this is where we’ll help you convince your boss that by investing in structure they’ll get better digital products that improve return on investment, make the most of content already paid for, and better prepare for a future where the means of finding, consuming, and sharing content look nothing like they do today.

Climbing the Summit

As we progress, we’ll keep coming back to a real project we worked on a few years ago: a conference on the topic of information architecture (IA). The Association for Information Science & Technology (ASIS&T) has hosted the IA Summit event every year since its inception in 2000. Over the years, minds immeasurably superior to ours have shared their IA expertise through talks, slides, workshops, and more. It was some of these folks who taught us about content management. Yet sadly, the IA Summit’s own website struggled to practice what the event preached. Year after year, a site would be built for the upcoming conference. The site detailed all the speakers and their sessions, along with information about the venue and local area. The designers even went to the trouble of making a schedule timetable page, which worked pretty great until we all started using our phones to browse the web. And when the conference was done for the year, the whole thing was torn down, never to be used again.

We thought there was a better way. Our goal was to build something not just for the next conference, but for every IA Summit thereafter. Not only would this break the cycle of redesign, but it could become an increasingly valuable asset. The event aims to be the home of conversation about the craft of information architecture. It has a community of ardent fans who come first as attendees but often return as speakers or workshop hosts. Some go on to help out with the programming and production of the conferences themselves.

With a multi-event structure, we could track each participant’s contributions and roles over time. We could cross-reference topics discussed at the latest event with related thinking from five years back. We could use the pages created to advertise each session and to host the slides and recordings for the session after the fact. We could use the structure to house a growing knowledge repository for the benefit of the wider community. When you’re doing the information architecture for a conference about information architecture, you really want to get it right.

That ambition led us to design our structure based on things common to every event—to the overall subject domain of the IA Summit (maybe even to conferences in general). Things like sessions, people, venues, sponsors, topics, and tracks. We would go on to find content for every example of these things and use the relationships between them to connect that content. As we learned more about the domain, we discovered that some things didn’t join up exactly as we assumed they did. And we found that other things become a bit complicated when you’re thinking about more than one event.

It’s a pretty good example with which to chart the progression from research to structural design to content planning and publishing. We’ll take you down the path we followed, including a few wrong turns.

Designing connected content goes from the bottom up. You first aim for stability by considering a subject domain. From there you look at the structure of content and the makeup of that content itself. Finally you consider how to represent the content resources, since interface design is perhaps the most rapidly changing part of all. Yet all these elements must be kept in balance for a truly successful product. Design each part with its surroundings in mind.

In the end, it’s all about making connections. Along the way you’ll connect with the people in your organization so that your product may benefit from their expertise. You’ll connect to your audience to learn about the things that matter to them. And you’ll forge new bonds between the elements of your content itself, expressing relationships to build understanding. It’s connection that makes the elements more valuable than the sum of their parts.