Tanzen

View Original

Setting Interface Foundations with IA

The following are my speaker notes (not quite a transcript) of my World IA Day talk in Washington, DC on February 18, 2017. The video includes a 20-minute discussion about domain modeling at the end. Those questions and answers are not included. Please use the comments to share your ideas and questions.


It’s 2017. The world wide web is 28 years old. We’ve gone from having a few hundred Web sites delivered over a network of phone lines at a relatively slow speed, to having content everywhere: your computer, your phone, your watch, your car, your tv, your refrigerator. And it keeps showing up in more and more places we never expected or only dreamed of.

Yet we are still designing in a literal box – a computer screen – based on what has been done in the past.

It’s time to look at a way of creating, structuring, designing content that’s ready for anything the future can hold. And do that outside of any interface – so that we are ready for wherever our content needs to go next – or however it needs to be organized next.

I’ve been working on this stuff for about 17 years. Learning from others and by trial and error. A couple years ago I worked with some amazing IAs (thanks Paul Rissen and Mike Atherton!) when I was the content strategist for the 2015 IA Summit. Before then, my main focus was on implementing content strategy, and it still is really.

During that experience, I learned about domain modeling and semantic relationships. After the Summit, Mike, who had been one of the co-chairs, and I teamed up to share the process we followed for creating the 2015 IA Summit website. By putting his domain and content modeling experience together with my CMS implementation experience, we started what we call “Designing Future-Friendly Content.” It’s a 5-step process and you can read all about it on the web.

Today, I’m going to focus on the first part: domain modeling and what it can do for small and mid-size organizations who are struggling with their websites and digital strategies.

Our journey

In our time together today, we’re going to go on a journey to discover a new way of thinking about content. We’ll take a quick look at where we are now, where we want to go, and how we get there. Then we’ll take a look at a few ways the future could be different, if only we start with IA rather than design. After that, I want to hear from you. We’ll discuss how this new way of thinking about content might change how you do your work.

Where are we now?

We’ve got a few problems as we begin the third decade of the world wide web.

  • There is so much content. There are over 1 billion websites. Over 2 million blog posts are published everyday. But then again, content is the point. How do we make sure we’re creating something of value?
  • There are so many devices – and screen sizes. When we create a website or product, we have no idea where a visitor will be, what they’ll use to view it, what browser they’ll use, or what their connection speed will be. How do we design for this infinite combination of sizes and uses?
  • As we try to figure this out, design trends constantly change. What if we could do real renovations to the design without having to change all the underlying content and structure?
  • Despite lip service, organizations are still designing and creating content for themselves, not their users. How can we change that?
  • Within organizations the silos are strong! People are doing different things with different priorities. That includes the stakeholders you work with and possibly your team too. What if there were a way to get everyone to focus on the same things and have the same priorities?

And these problems are not solved with a tool or technology or a website. The website is too downstream. The fact that we have to keep redesigning them every few years – tear them down and rebuild them – proves that websites are a symptom of a bigger problem. We, collectively, are not asking good questions. We’re not looking at the people and processes that are behind websites. In essence, we’re solving bad problems with websites – and many other systems and tools being put in place.

We’re re-packing garbage. Of course I don’t mean to say that everything we all do is garbage. A lot of good work is happening. But you wouldn’t be here today if everything was perfect at your organization, with your clients, or with the world wide web generally.

Where are we going?

We are starting to get an idea of what the future looks like. It’s the Internet of Things. Not just in the first world to control our houses and make our lights tweet, but solving real problems in African villages and Indian cities.

This network is not going to work if we keep doing things the way we’ve always done them (which really is only for the last 20 years or so; it shouldn’t be so hard to change). Information architecture has an important role in this future, as do content strategists and designers. Without a solid foundation and structure, the future is not as wonderful as it could be.

How do we get there?

We start by asking better questions. We slow down and take a step back. We think differently about how we create, connect, and manage our content. If we keep solving bad problems, it’s not going to happen. We who shape the structures of the interwebs need to lead, not follow.

Information architects and content strategists are perfectly positioned to lead this charge. We are the ones who relish organizing things, making sense of messes, untangling information. And there is a lot of mess out there on the information superhighway! We don’t have to wait around for someone else to do it. We shouldn’t get to the end of our careers and think “why aren’t we living on the moon?”

Domain models

Domain models take us up to the 30,000 foot view and to see what is in our universe. As the name suggests, its the model of the subject domain; how all of the principal concepts are related.

This is where we should start design from, so we’re not limiting it by the technical constraints of the website, or even by the content we have. Instead we are focused only on our best representation of the subject itself.

At this point, we are not worried about the level of complexity this exposes. We’re modeling truth, not websites.

It gets us to specifics of a subject area faster without having to worry about the logistics of making it happen. Domain models are made up of two parts: Concepts and Relationships.

Concepts are things that exist within a subject. If we were talking about space travel, we might start talking about spacecraft, launches, missions, astronauts, planets, and moons. And the concept of "mission" has a different meaning in space travel, than it does in business or in marketing. So we tend to define concepts within the realm of a subject domain so we’re all clear on what we’re talking about.

Concepts are intended to be reusable. You might think of them as a category of thing, rather than the thing itself. So if our concept was "planets" then "Jupiter" and "Mars" would be two examples of that concept.

And of course concepts break down further into properties which make up that concept.

Relationships are how the concepts are connected. Remember, we’re thinking about the real-world relationship here – we’re not worrying about website navigation or anything.

We can also describe ‘how’ two things are related, which gives an extra dimension to understanding the subject domain, and if expressed through an interface gives an educational aspect of describing how the world joins up.

Examples of that here. If I had a concept of moon and a concept of planet I could connect them, and describe that connection saying that the moon orbits the planet. An author wrote a book. An ingredient is part of a recipe. A movie can be an adaptation of a book. This is an example of a conference domain model – any conference. We have all these things.

Isn't this a content model?

You might be thinking, isn't this a content model? Well...No. A domain model is everything about the subject matter. It provides context. Once that is set, we can zoom in and create the content model, which is the expression. It adds specific detail about the content which will express and describe the domain.

We are moving from the abstract toward the specific. The content model describes the content we’ll actually show to users. While we typically audit our content based on subjective decisions like how well it’s done, how many visits it gets, or any number of criteria, we can audit our content inventory against the domain model. This helps us create content that is valuable.

A content model is the next step in narrowing the universe we defined in the domain model. We can now make decisions about which concepts and relationships to expose in various interfaces. Where domain models are concerned with meaning and concepts, content models provide the structure and properties for those concepts. Here is the content model for the IA Summit. We determined content types based on the domain model and assigned properties. The content types can have relationships like the domain model.

In the domain model we had 12 concepts. You can see here that we have only 6 content types. These properties in green were concepts in our domain model, so that’s where 3 of them went.

We also eliminated Brand because that is what we are modeling here. IA Summit is the brand. We lost “hotel” because that turned out to be an example of a “venue.” Location turns out to be a property of several content types, not a concept unto itself.

Here’s a zoom in on the Person content type. You can see that we defined properties about a Person. And note that is “Person” and not “Speaker.” That’s because from year to year, an individual could have different roles. One year, they might be a speaker, another year a keynote speaker, and yet another year a co-chair. No matter what role they have, we want to know the same information about them. So instead of different content types for Speakers and Volunteers, we created a “Role” taxonomy to relate people to events.

Before all the usual starting activities, do the domain model. It sets parameters and constraints needed for the life of your website or product.

What does this get us?

The domain model makes decisions more deliberate. More deliberate about what to include – and what to exclude. How often do we hear a version of this request: “Set up a website and blog.” Whether it’s a startup or a new campaign that needs a microsite or a new business line or any number of reasons there are for people thinking another website or blog need to exist.

With your domain model, you’ve already determined what the real world looks like. Now you make a direct connection between the real world and what can support a need or help someone take action. Even as we use technology to get things done, the need to do something starts offline. Domain models help make the connection between the human need and the computer that allows a task to be accomplished. This is a quote from a conversation I had with someone at a large university. I’ve heard one government agency has 900 sites. All because no one took the time to figure out why they all need to exist. With the domain model in hand, you start to see relationships and potential for duplication. I cannot imagine a case in which one organization needs 200 websites, no matter how big it is. If we are to continue to make the web useful, we need fewer websites with fewer pages. Each website, product, or page needs to have purpose and it needs to fit together with other sites, products, and pages much like a puzzle, not pick-up sticks. Contrary to first impressions, a domain model creates expansiveness, not limitations. It sets boundaries and creates connections.

A domain model can be a catalyst for a lot of things, so it needs context. Say you are a historical attraction.

You have land on which sits the original owner’s house and other buildings, a farm, a garden, a museum, a library, and a gift shop. Those are all things that exist. There are also stories about that historical figure and his family. There are also stories about how the grounds were originally used and how they’ve been maintained for the last 200 years. There are products for sale, exhibits for people to visit, documents and photos that are used for research and publications.

We could create a domain model around these things and how they connect. Then we can see where the boundaries are and where there are opportunities to support user journeys. These set the stage for connecting content deliberately rather than haphazardly. Instead of a “you might also like” list of somewhat-related things on the web page about a popular exhibit display item, you could see that this exhibit is related to items in the library or in the gift shop. It might also have been part of a well-known story, which could be told on a blog for students.

It opens a door to a different way of exploring your subject area and things within it.

How can I do this?

You might be thinking, that all sounds nice, but how can I do this? The better question, might be “how much will people allow you into their space?” What follows are possible ways that might happen in your organization or within your client projects. Domain modeling is part of your research. Design starts with a common language. The information we gather from interviews can be used to identify the concepts and relationships and rules of a subject domain. Here’s an example of an interview transcript. We can extract from it the user’s or expert’s view of their world. Reading to find the nouns and ask questions which define each thing, and how it’s different to another thing.

The verbs tell us how the nouns or concepts relate to each other. How they are connected. You do this with experts – who map the world – and with users – who mark the points of interest. Use domain modeling as a pre-card-sort activity. As a way of figuring out what goes on the cards to sort.

Based on these interviews, we can extract and define concepts that will form our domain model. These are the concepts we defined for the IA Summit. From here we can figure out what things we want to include in the card sort. You can create a domain model as a pre-kick off-meeting activity. Before even starting to build a new website, app, product, or database, determine that it needs to exist or set parameters. This idea goes back to “we need a website and blog” without thinking about what problems those things solve or what needs to be included in them.

Most of all, lead, do not dictate. Instead of marching into a meeting or colleagues’ offices telling them about the great domain model you’re going to create (or already created), share that you want to map communications efforts. This can show duplication of efforts across your silos and builds connections with peers. You’re not encroaching on their areas of speciality, you’re helping them do their jobs more effectively and efficiently.

How does a domain model help?

Content duplication is a plague running through our digital world. We need to think more about resources and canonical references and fewer single-purpose pages. Let me show you an example of what I mean.

People. We often think of just the information in a specific context and what that needs to look like. This is an inside-out perspective. But if we start from the real-world version of a Person, we start to think about how the things we are describing connect to other things we are describing. Over the last 18 years, there have been thousands of people involved in the IA Summit, whether as attendees, volunteers, or speakers. For any given year, those people get involved in a certain way (or choose to not participate). Each year they might have different roles, such as volunteer. Therefore, year over year they need to be represented differently depending on whether they are a speaker, a co-chair, or a peer reviewer.

But the data about that person doesn’t change. They have the same attributes, even outside of the IA Summit. Our domain model works from the outside-in, which allows us to do “resource driven design” as Michael Smethurst suggests in a recent blog post. This was the model we used for creating the 2015 IA Summit website. Instead of a separate website for each event, we’d build one based on resources that could be reused, restyled, and remixed year after year. The current year’s event would be the context for the interface, but whether we linked from the 2015 list of speakers, the 2016 list of volunteers, or the 2017 session speakers, we’d link back to the same resource. Not a different, completely distinct web page for the same person.

We talk a lot about curation. Curate means to pull together, sift through, and select for presentation. We do this all the time on the web. But we did this before there was a web. Museums curate. Libraries curate. Art galleries curate. Interior designers curate. Why should digital curation be different than physical curation?

If we were to curate an exhibit of Monet’s paintings this year and then next year one of French impressionists, we would use a subset of the same Monet paintings. We might even borrow from another museum to make the exhibit special. Be we certainly wouldn’t recreate the paintings because it was a different context.

Yet this happens on the web over and over. We recreate things over and over for different interfaces – heck we re-architect, redesign, and rewrite entire, massive websites every few years! We’re getting better at reuse, and retailers and media companies are leading that because they have to. But smaller organizations aren’t doing it so much. When you take that outside-in point of view and think about what concepts are in your world and how you want to represent them and connect them on the web, you get more sustainable and rich interfaces. Because you are designing from the outside in, you also gain flexibility within a given interface, across many interfaces – which may or may not be your own – and across devices and screen sizes.

The domain model is just the start of a foundation for a system based on resources, not pages. It leads to content models and design frameworks that allow us to be platform neutral. And we have to remember that it’s not just websites anymore, either. The domain model also helps your organization beyond better content. It helps with the politics within the organization itself.

Because you are elevating the conversation to be about what your stakeholders care most about – their area of expertise – you are more likely to avoid the arguments about what goes on the home page. Getting everyone together to talk about how real-world concepts relate to one another means you’ll get people to align faster than if you try to get them to agree on a site map based on a content audit they don’t agree with in the first place because if only their bit of content were on the home page they would have more page views.

With that alignment, you can start to prioritize. Within every discipline or company, there are some basic facts or principles that need to be followed. If you are a professional society focused on furthering your profession, it is harder for people to disagree about what things about being a practitioner in that field are most important than it is about what goes at the top of the home page. If you can base your website’s prioritization (whether in the actual interface or to sort user stories) on real-world priorities, you’ll be much better off.

Remember those 200 websites for one organization? Guess what? Having a domain model helps to corral those into a cohesive set rather than one-off microsites because there are already microsites for all the other department’s campaigns, so why can’t we have another? A domain model allows you to create a plan for aligning and connecting your different “domains” (which are actually URLs), making them easier to manage and govern.

This idea may not be brand new to some of you, but maybe it’s given new context or provided some ideas for thinking of your offering as being part of a wider conversation. As users ourselves, we use the whole web as our resource, cherry-picking information from all over the place. Our audience is the same way. So when you’re publishing ask not just ‘what is this doing for my customers?’ but ‘what is this adding to the web as a whole?’.

The only thing we can predict with any certainty is that things will change. As more and more information is produced, it is essential to be findable and usable and to provide value. Thinking content-first will pay off when the next disruption happens.

How might change how you work?