<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>Boxes and Arrows: Comments by Ray Whitney</title>
    <link>http://www.boxesandarrows.com/person/3823</link>
    <pubDate>Mon, 20 Aug 2007 15:19:21 GMT</pubDate>
    <description>Comments by Ray Whitney</description>
    <item>
      <description>&lt;p&gt;Thank you for a well-considered summary of content strategy.&lt;/p&gt;

	&lt;p&gt;I have held the job title &amp;#8220;Content Strategist&amp;#8221; for longer than I care to admit, and (as I am sure you have experienced) the role has changed over the years. Different clients and different projects require different processes and artifacts, and as we move into a more interactive (&amp;#8220;rich&amp;#8221;) content model, our ability to analyze, strategize, and manage content becomes more critical to the architecture.&lt;/p&gt;

	&lt;p&gt;I was humored by some of the early reponses that questioned the value of content strategist roles. How quickly people forget that IAs faced the identical value question a few as five years ago (and depending on where you are working, they are still facing the value proposition challenge).&lt;/p&gt;

	&lt;p&gt;One thing that is worth reminding folks is that IAs come from a variety of backgrounds. Some come to IA from design, others through &lt;span class="caps"&gt;HFE&lt;/span&gt; studies. And let&amp;#8217;s not forget the library sciences folks and the former programmers among us (I am certain that I am leaving out others.). As a result, different IAs approach their tasks from different perspectives. I have found that the best IAs have a broad background and a hunger to learn from others; and that the best teams have personnel whose experiences span a breadth of disciplines.&lt;/p&gt;

	&lt;p&gt;As this applies to content strategy, I have always promoted a &amp;#8220;hand in glove&amp;#8221; approach. At times during a project IA is the hand (and content strategy is the glove), and at other points content strategy is the hand (and the IA is the glove). At all points, content strategy and IA are intimately intertwined; they are symbiotic.&lt;/p&gt;

	&lt;p&gt;I happen to come to IA from a technical writing background. I have trained as a copy writer and an IA, and I market myself as an IA/Content Strategist. The result? I currently hold the title of content strategist.&lt;/p&gt;

	&lt;p&gt;I suspect that as complex content interactions increase within enterprise systems, there will be an increasing need for content strategists within the core architecture and design teams.&lt;/p&gt;

	&lt;p&gt;And it&amp;#8217;s not a bad gig, if you can get it.&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/content-strategy-the#content_5840</link>
      <guid>http://www.boxesandarrows.com/view/content-strategy-the#content_5840</guid>
      <pubDate>Mon, 20 Aug 2007 15:19:21 GMT</pubDate>
      <author>Ray Whitney</author>
    </item>
    <item>
      <description>&lt;p&gt;Special T:&lt;/p&gt;

	&lt;p&gt;I followed a similar path, moving from technical communication to content strategy and IA. Yes, it is logical, and yes, it is possible, but there are a lot of folks who don&amp;#8217;t see the connections.&lt;/p&gt;

	&lt;p&gt;I have noted to some colleagues that there is a little bit of IA within all technical writers. Technical communicators make the complex simple, using structure, language, and design. In essence, this is precisely what IAs do.&lt;/p&gt;

	&lt;p&gt;Another group of professionals who could make the transition are those involved with technical training. As a technical writer I used trainers as a primary source when I needed to understand the audience needs. Trainers possess invaluable first-hand knowledge of the product and the user base. Most have excellent people skills (that translate well into user interviews). Most easily adopt the user perspective (they *are* users, after all), and most have the technical savvy to communicate with designers.&lt;/p&gt;

	&lt;p&gt;Thanks again for the article.&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/using-technical#content_5963</link>
      <guid>http://www.boxesandarrows.com/view/using-technical#content_5963</guid>
      <pubDate>Mon, 16 Apr 2007 04:35:41 GMT</pubDate>
      <author>Ray Whitney</author>
    </item>
    <item>
      <description>&lt;p&gt;James:&lt;/p&gt;

	&lt;p&gt;I always appreciate your articles, since enterprise-scale projects have been my bread-and-butter.&lt;/p&gt;

	&lt;p&gt;I generally agree with this article, but I think that you are creating terms (or not using terms) for things that already exist (and have perfectly adequate labels). As a result, the water gets a bit muddy.&lt;/p&gt;

	&lt;p&gt;This muddiness concerns me, because working within the enterprise places a premium on communication across disciplines and organizational levels. As a result, using terms that are well-understood is critical to accelerating and achieving success.&lt;/p&gt;

	&lt;p&gt;Please bear with me here as I quote you and provide alternatives.&lt;/p&gt;

	&lt;p&gt;You wrote:&lt;/p&gt;

	&lt;p&gt;&amp;#8220;The needs analysis then informs the creation of an overall strategy, scope and direction. From this clear framework for the IA work, a comprehensive overall roadmap of the activities required can emerge. &amp;#8220;&lt;/p&gt;

	&lt;p&gt;You also refer to this process as a &amp;#8220;holistic needs analysis.&amp;#8221;&lt;/p&gt;

	&lt;p&gt;I would call these activities &amp;#8220;Requirements Gathering&amp;#8221; and &amp;#8220;Business Analysis&amp;#8221;. These are traditional terms that are understood throughout the enterprise. Personnel with these skill sets are found in many levels of the organization, so it is easy to get a group to grok the activities you (so rightly) identified.&lt;/p&gt;

	&lt;p&gt;While I understand that there are nuances (you appear to be emphasizing the ethnographic elements of the needs analysis), I do not nees the value of applying a new label to an old task.&lt;/p&gt;

	&lt;p&gt;You also wrote:&lt;/p&gt;

	&lt;p&gt;&amp;#8220;The strategy also identifies the most critical issues to be solved, along with the activities with the potential to deliver the greatest business benefits. In this way, the IA work can be targeted for the greatest impact.&amp;#8221;&lt;/p&gt;

	&lt;p&gt;and&lt;/p&gt;

	&lt;p&gt;&amp;#8220;Together, the strategy and scope define the &#8220;problem&#8221; and provide a concrete context for the user-centered design process. Along with the illumination of the practical aspects of the work to come, the strategy also builds the business case for change and creates a sense of urgency.&amp;#8221;&lt;/p&gt;

	&lt;p&gt;I would call strategy and scope development &amp;#8220;Product Management&amp;#8221;. Again, this is a term well-defined within the enterprise. In this case, you did not apply a new label. I would, however, call it what it is.&lt;/p&gt;

	&lt;p&gt;While I fully recognize that there are nuances, I find that I have far greater success using generally-accepted terms for processes and roles that already exist within the enterprise.&lt;/p&gt;

&lt;steps soapbox&gt;&lt;br /&gt;One of my criticisms of the IA community is that we tend to make it all about us. In this sense we are pre-copernican: the universe exists around the IA. &lt;br /&gt;
The reality is far different: IA is a component of the greater enterprise. We need to better understand how we fit into that particular picture.&lt;br /&gt;&lt;steps soapbox off&gt;</description>
      <link>http://www.boxesandarrows.com/view/enterprise-ia#content_6347</link>
      <guid>http://www.boxesandarrows.com/view/enterprise-ia#content_6347</guid>
      <pubDate>Sat, 09 Aug 2008 02:30:10 GMT</pubDate>
      <author>Ray Whitney</author>
    </item>
  </channel>
</rss>
