<?xml version="1.0" encoding="utf-8" ?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
	<title>Olshavsky, Ryan</title>	<link>http://tc.eserver.org/authors/Olshavsky,_Ryan</link>
	<description>A bibliography of works by Olshavsky, Ryan in the field of technical communication.</description>
	<language>en-us</language>
	<copyright>Copyright (c) 2005-08 by the EServer. All rights reserved.</copyright>
	<managingEditor>tclib-editorial@eserver.org (TC Library Editorial Board)</managingEditor>
	<webMaster>webmaster@eserver.org (Geoffrey Sauer)</webMaster>
	<image>
		<url>http://tc.eserver.org/images/newlogo.gif</url>
		<title>Olshavsky, Ryan</title>
		<link>http://tc.eserver.org/dir/Olshavsky,_Ryan</link>
	</image>
	<item>
		<title>Six Tips for Improving Your Design Documentation</title>
		<link>http://tc.eserver.org/28316.html</link>
		<guid>http://tc.eserver.org/28316.html</guid>
		<description>Documentation is a crucial component of successful product planning and implementation, so it&apos;s important that it communicates as effectively as possible. Good organization, complete information, and clear writing are, of course, key to the success of any design document, but there are some other, less-obvious techniques you can use to make your documents more readable and understandable. Here are a few of them.</description>
	</item>
	<item>
		<title>Six Tips for Improving Your Design Documentation</title>
		<link>http://tc.eserver.org/25619.html</link>
		<guid>http://tc.eserver.org/25619.html</guid>
		<description>Good organization, complete information, and clear writing are, of course, key to the success of any design document, but there are some other, less-obvious techniques you can use to make your documents more readable and understandable. Here are a few of them.</description>
	</item>
	<item>
		<title>Bridging the Gap with Requirements Definition</title>
		<link>http://tc.eserver.org/23984.html</link>
		<guid>http://tc.eserver.org/23984.html</guid>
		<description>Developing a new product or service is tricky. When everything goes well, the product can redefine a market or even create an entirely new one, to the benefit of its manufacturer and its consumers. When the product doesn&apos;t click with its audience, though, the costs—development, employee, manufacturing—can be staggering. How do you ensure that your new product doesn&apos;t flop? One effective method is to conduct a requirements definition phase before developing a new product.</description>
	</item>
	<item>
		<title>Making Your Design Real: The Form and Behavior Specification</title>
		<link>http://tc.eserver.org/23975.html</link>
		<guid>http://tc.eserver.org/23975.html</guid>
		<description>Let&apos;s say your development organization has embraced design as a key to creating successful products. You&apos;ve devoted time and energy to creating the perfect, goal-directed design for your product. Your programmers are ready and eager to start putting that design into code. So…now what? How do you communicate your design to your development team, accurately and in sufficient detail? One approach is to produce a Form &amp; Behavior Specification.</description>
	</item>
	<item>
		<title>Information Architecture: Blueprints for the Web</title>
		<link>http://tc.eserver.org/21353.html</link>
		<guid>http://tc.eserver.org/21353.html</guid>
		<description>While there are many fine books that go into great depth on various aspects of the information architecture and design process, &apos;Information Architecture: Blueprints for the Web&apos; is, essentially, a primer on successful website design.</description>
	</item>
	<atom:link href="http://tc.eserver.org/authors/Olshavsky,_Ryan.xml" rel="self" type="application/rss+xml"/>
</channel>
</rss>