<?xml version="1.0" encoding="utf-8" ?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
	<title>Articles&gt;Project Management&gt;Usability</title>	<link>http://tc.eserver.org/dir/Articles/Project-Management/Usability</link>
	<description>A listing of the most recently indexed works about Articles and Project Management and Usability 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>Articles&gt;Project Management&gt;Usability</title>
		<link>http://tc.eserver.org/dir/Articles/Project-Management/Usability</link>
	</image>
	<item>
		<title>Agile Development Projects and Usability</title>
		<link>http://tc.eserver.org/33454.html</link>
		<guid>http://tc.eserver.org/33454.html</guid>
		<description>Agile methods aim to overcome usability barriers in traditional development, but pose new threats to user experience quality. By modifying Agile approaches, however, many companies have realized the benefits without the pain.</description>
	</item>
	<item>
		<title>Featuritis (or Creeping Featurism)</title>
		<link>http://tc.eserver.org/30442.html</link>
		<guid>http://tc.eserver.org/30442.html</guid>
		<description>Featuritis or creeping featurism is the tendency for the number of features in a product (usually software product) to rise with each release of the product. What may have been a cohesive and consistent design in the early versions may end up as a patchwork of added features. And with extra features comes extra complexity.</description>
	</item>
	<item>
		<title>High-Cost Usability Sometimes Makes Sense</title>
		<link>http://tc.eserver.org/30195.html</link>
		<guid>http://tc.eserver.org/30195.html</guid>
		<description>Computing the net present value (NPV) lets you estimate the most profitable level of usability investment. For big projects, expensive usability can pay off.</description>
	</item>
	<item>
		<title>Usability Requirements: Making User Satisfaction a Measure of Product Success</title>
		<link>http://tc.eserver.org/29905.html</link>
		<guid>http://tc.eserver.org/29905.html</guid>
		<description>Defining usability requirements at the beginning of the project increases the chances that the end product will meet the users&apos; goals and create a satisfying user experience. Unfortunately, such requirements are often not considered with the same priority as functional or other technical requirements. This presentation defines usability requirements, proposes guidelines for creating measurable requirements, and elaborates the components of a well-constructed usability requirement.</description>
	</item>
	<item>
		<title>Issues in Sizing UCD Projects</title>
		<link>http://tc.eserver.org/28645.html</link>
		<guid>http://tc.eserver.org/28645.html</guid>
		<description>Sizing UCD projects presents special challenges to usability practitioners and consultants. Each project and UCD methodology comes with its own set of variables that makes it difficult to accurately estimate resource requirements and completion times.</description>
	</item>
	<item>
		<title>Usability Team Structures</title>
		<link>http://tc.eserver.org/28644.html</link>
		<guid>http://tc.eserver.org/28644.html</guid>
		<description>There are two basic alternatives for structuring a usability/UCD group within an organization: members of the group can be centralized in a single department, or, members can be distributed among development teams.</description>
	</item>
	<item>
		<title>A Useful Investment</title>
		<link>http://tc.eserver.org/23768.html</link>
		<guid>http://tc.eserver.org/23768.html</guid>
		<description>Proper usability design commonly cuts training costs by 50 percent and increases productivity by 25 percent.</description>
	</item>
	<item>
		<title>If They Don&apos;t Test, Don&apos;t Hire Them</title>
		<link>http://tc.eserver.org/21431.html</link>
		<guid>http://tc.eserver.org/21431.html</guid>
		<description>The single best indicator as to the overall competence of an interaction design team is their plan for user testing. If you are presented with no plan or a sort of vague &apos;and we&apos;ll eventually do some user testing,&apos; you may want to back off and look at other resources. If, on the other hand, you are given a proposal outlining repeated design and test cycles, you are dealing with people who know exactly what they are doing.</description>
	</item>
	<item>
		<title>Crafting a User Research Plan</title>
		<link>http://tc.eserver.org/18918.html</link>
		<guid>http://tc.eserver.org/18918.html</guid>
		<description>Every piece of user research is part of an ongoing research program, even if that program is informal. However, making a program formal provides a number of advantages: It gives you a set of goals, a schedule that stretches limited user-research resources, and results when they&apos;re needed most. It also helps you avoid unnecessary, redundant, or hurried research.</description>
	</item>
	<atom:link href="http://tc.eserver.org/dir/Articles/Project-Management/Usability.xml" rel="self" type="application/rss+xml"/>
</channel>
</rss>