The Roles and Responsibilities of an Information Architect
This article is based on a presentation I gave at CIDM’s CMS/DITA North America 2013 in Rhode Island. While the presentation title included “Roles and Responsibilities,” I realized afterwards that I focused mostly on the responsibilities. Since I think the roles an Information Architect (IA) plays are important, I framed this article around the roles of an IA, and I discuss the responsibilities contained within each role. For each role and responsibility, I also list questions you want to ask in that role. Because my experience as an IA involves helping organizations transition to structured authoring and DITA-based publishing, the article is written from that perspective.
Since DITA is an emerging technology, and because the position of Information Architect is new within the field of DITA content production, what it means to be an IA can vary widely depending on
- your experience and skills
- the needs of your organization
- the experience and skills of others in the organization
Whenever I hear other IAs speak, I’m always amazed at how different their focus is from my own. I can speak from my experience as an IA, but I’m just one IA in a big world.
Below are the roles I’ve played as an IA. I’ll delve into each deeper throughout the article:
- Requirements Analyst
- Information Model Developer
- Project Manager
Analyzing requirements is a key role and should be an ongoing one. I divide requirements analysis into two categories: audience requirements and writer requirements. There is usually a big push to analyze audience requirements at the start of the project, because the desire to better serve your audience frequently drives a conversion from the current authoring and publication system to one that is DITA based. But analysis of customer requirements doesn’t have to end as a DITA implementation matures. New requirements can emerge as systems evolve, and overlooked requirements must be addressed in later phases of the project. If your organization wants to continuously improve information delivery channels, gathering audience requirements is an ongoing task.
Questions to ask when analyzing audience requirements:
- What are the current pain points for your audience? Maybe your team is limited to delivering information in one format. There might be issues with consistency and accuracy of information. Try to frame these matters in quantifiable terms whenever possible. And by quantifiable, I mean money.
- What don’t you want to change?
- How would you like to innovate? Do you want to automatically incorporate data from external sources into publications? Deliver content to mobile devices? Provide new channels for audience feedback?
In addition to analyzing customer requirements, you also want to analyze writer requirements. I call writers my “other customers.” Increasing writer productivity and efficiency helps them to do a better job supporting the performance of your audience.
- What are your current pain points? Do writers spend too much time tracking down all instances of the same content? Is there inconsistent formatting or application of standards? Does your team spend too much time in production? Are different people using different tools and holding different licenses?
- What do you like about your current system? Sometimes the team won’t know what they will miss until it’s gone. In the systems I’ve implemented, writers do not have control over page formatting in PDF output. Writers have been mostly OK with this, but occasionally miss the ability to adjust the appearance of output. However, a colleague I met at the conference told me how his system allowed writers fine control over page formatting in a DITA-based system.
Wait! Don’t stop reading. I realize that the role of salesperson might seem out of place, but if you are championing a conversion to a DITA-based system, you need to repeatedly sell that system to writers, to stakeholders in other departments, and to management. In many cases, you fulfill the role of salesperson by simply communicating progress and explaining the details of the new system and its benefits. Craft your message for each audience and multiply the message by repeating it frequently and using different communication channels. Use email, social media (if available), meetings, and presentations as opportunities to evangelize what you are doing.
Writers and other publications stakeholders want to know how the output you produce will be improved and how the new system will affect how they do their jobs. SMEs will have the same questions about output changes and also want to know how working with DITA will change their ability to contribute or review content. Management wants to know about all of the above, plus the costs and fiscal impact of the new system. When communicating to management, remember to demonstrate how improvements in documentation help increase operating leverage (simply put, the gap between costs and revenues).
The benefits of the new system will not be self-evident to everyone. People need to be reminded about the changes and the progress your team is making. If you have consistently communicated the benefits of the system and the progress that your team has made, you can refer to prior communications when confronted by people who haven’t read them.
In the role of Salesperson, you might need to perform the following tasks:
- Write a business justification
- Develop metrics to measure progress
- Craft the definition of success
- Send regular communications to writers, management, and external stakeholders
Questions to ask in the role of Salesperson:
- What will the new output look like?
- What day-to-day or release-to-release efficiencies will be gained?
- Who are the budget approvers?
- Do other departments need to be involved?
- How will your project change the way your company produces content?
- How frequently do you need to communicate with various stakeholders?
- Which communication channels are available?
- How will you get feedback?
Information Model Developer
Because the information model sets the standards and rules that govern content development, developing an effective one is a primary IA function. The process of developing the information model is likely to yield many interesting and passionate discussions with writers, who can have strong opinions about how information should be structured and presented.
Story: How I Removed the <xref> Element from the DITA DTDs
Early in the process of implementing DITA at Epicor Software, I attended a DITA user group meeting where Michael Priestly gave a presentation on DITA linking. Priestly explained that inline links make content less readable, and he demonstrated how you can use the DITA map structure and relationship tables to generate links at the bottom of a topic. I was sold! I took this information to my team and suggested that we remove all inline links from our help system and replace them with “DITA style” links. The team responded with immediate and strong resistance. “Inline links are everywhere,” they said. “I wouldn’t recognize online help without embedded links.” Since we were all newcomers to DITA, I did not have the authority to override the team and implement my ideas. We were at an impasse. It was a stroke of luck that caused one of the strongest proponents of inline links to have a reversal on the subject. The following are excerpts from an e-mail thread that described why he changed his mind.
From his first message:
I’m starting to question if having links within the text is effective. Many times when I’m reading through a help topic, I just skip over these links