This is part of a series of interviews with people who are changing the way they create, connect, and manage content so that they are ready for the next frontier. Every story is unique, but they all mirror the process advocated in Designing Connected Content: Plan and Model Digital Products for Today and Tomorrow by Mike Atherton and Carrie Hane.

Today’s conversation is with Sarah Mendez, Content Strategist at National Instruments.

You are a Content Strategist at National Instruments. Tell me more about your role and how that fits into the company’s organizational structure.
National Instruments creates hardware and software products that scientists and engineers can use to test and measure the things they create. I’m on the content strategy team for the Product Documentation department, which includes about 70 technical writers. There are four of us on the content strategy team. We create front- and back-end strategies to promote consistency and efficiency across all writers.

How did the content strategy team come about?
We have been producing technical documentation for decades. That content was pretty siloed by the products it was for. We have recognized that people don’t use our products in isolation. They use them in combination, and we want our users to have a coherent experience. We also wanted to gain efficiency and standardization in the tool chains* we use.

Earlier this year you found the book Designing Connected Content that Mike Atherton and I wrote to help people lead their organizations toward building content models and structuring content outside of a specific interface. How did you find the book and why did it appeal to you? Our team had been on a content modeling quest since at least last fall. We had a big project that we wanted to create a content model foundation for. We had found good resources but lacked a coherent methodology, so we were on the lookout for new resources that could help us put it together. In January, a co-worker and I independently found information by you and Mike on designing future-friendly content and domain modeling that led us to the book. It put together all the pieces into a coherent process in a way that resonated with us.

And now you’ve used the book as part of your internal team’s book club. What resonated with your team?
Not only had we been looking for an approach to content modeling, but we also weren’t using the same terminology to talk about it. We thought we were talking about the same thing – content types, content models, deliverables – but it became clear that we weren’t talking about the same thing. The book club gave us a common foundation to communicate more effectively.

Now that you have this idea of creating connected content, how are you going about doing that?
We’ve landed on an approach that allows us to span domains and develop our process. Via interviews with subject matter experts (SMEs), we have been getting a broad view of the domains we might be working in. This allows us to embrace the big problem and to understand the context we’ll work in. Once we have a draft of the bigger domain, we will choose a couple of narrow parts of the domain and go through the entire process.

There is a real skill to conducting the domain interviews and figuring out the right level of abstraction to put in the domain model. Our goal is to build our skills in addition to building the domain model. Two of us go to the SME interview – one main researcher and one observer. After several interviews, we have a working meeting for everyone to bring their domain objects and see how they fit together. We’re building the domain model collaboratively. This has been a powerful exercise. Our domain is complex. We had different ideas in our heads of it. Making a visualization helped us get our mental models aligned.

What outcomes do you think your organization will gain from approaching content this way?
One, working on the domain model first helps us avoid one-offing content decisions in the future. We can’t do the whole domain at once. We’ve suffered in the past when we focused on a small part without understanding how that part fit into the bigger picture.

Two, we’re hoping that once we have the whole domain model, we will be able to automate content assembly from the individual attributes. We’ll only be able to do that with these models.

Three, having this process as a tool to come to a common understanding internally is really powerful. We want to get alignment across departments, but a lot of it right now is building our team’s confidence and facilitation skills.

Have you had any experiences so far that have caused you to change course?
Not so much changing course as finding our way. Figuring out the best SMEs to talk to. How to talk at the right level of abstraction. Figuring out if the domain model has the right level of abstraction. Finding the best methodologies for figuring out the domain object attributes. Finding people who can serve as proxies for users.

What advice do you have for someone starting down this path of creating a system of interconnected content and domain modeling?
Be as transparent as possible. We had to have buy-in to spend time researching and learning a methodology. It will be a skill to use across all projects going forward. But it is difficult to explain the process to others. We invite people who might interested in a particular part of the domain to join our team meetings. That way, they get to watch what we do and participate and ask questions. It’s an organic way to give people insight into what we’re doing.

Building a domain model together is a way to sort out inconsistencies we have. There is a level of vulnerability to put your ideas out there to gain alignment. Embrace imperfection.

I really like this quote from Jorge Arango:

Did I get it wrong? It’s likely. If you can spot problems, the map is serving its purpose: to help us have discussions.
Jorge Arango, An Example of a Semantic Environment Map

That is exactly what we’re doing.

* Tool chain = all the tools that have to exist to store and send content through a final delivery mechanism; DITA XML, the CMS, and other things that content out of the CMS and deliver it to the web or store inside software products.

Do you have a story to share about designing connected content? Share in the comments below, on Twitter with #DCCBook, or drop us a note Contact Us.