<?xml version="1.0" encoding="utf-8" ?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
	<title>Cooper Interaction Design</title>	<link>http://tc.eserver.org/publisher/Cooper_Interaction_Design</link>
	<description>A listing of works published by Cooper Interaction Design 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>Cooper Interaction Design</title>
		<link>http://tc.eserver.org/dir/Cooper_Interaction_Design</link>
	</image>
	<item>
		<title>Common Myths about Web Design</title>
		<link>http://tc.eserver.org/26080.html</link>
		<guid>http://tc.eserver.org/26080.html</guid>
		<description>Some of the most common myths about Web design follow. These myths have found their way into business and technical organizations, and are--to some degree or other--taken at face value by management, marketing, engineering, and sometimes even Web designers themselves. The sooner you can disabuse your organization of these myths, the better.</description>
	</item>
	<item>
		<title>Designing Products for Offshore Development</title>
		<link>http://tc.eserver.org/26077.html</link>
		<guid>http://tc.eserver.org/26077.html</guid>
		<description>Although as an Interaction Designer I&apos;m not involved in the actual development of the products I design, I find it increasingly clear that outsourcing creates a significant impact on the entire software design and construction process. Offshore development is in its infancy, but will continue to evolve to become an increasingly effective way to go about certain kinds of software construction. Based on recent project work, this article describes a number of observations worth considering as you ponder how outsourcing and offshore development may fit into your plans.</description>
	</item>
	<item>
		<title>The Inmates are Running the Asylum</title>
		<link>http://tc.eserver.org/26078.html</link>
		<guid>http://tc.eserver.org/26078.html</guid>
		<description>The classic rules of business management are rooted in the manufacturing traditions of the industrial age. Unfortunately, they have yet to address the new realities of the information age, in which products are no longer made from atoms but are mostly software, made only from the arrangements of bits.</description>
	</item>
	<item>
		<title>Technical Writers and Interaction Design</title>
		<link>http://tc.eserver.org/26079.html</link>
		<guid>http://tc.eserver.org/26079.html</guid>
		<description>Technical writers are oft-forgotten constituents in the product development cycle. Although they are rarely tasked with participating in product requirements definition and product design, technical writers are in a unique position to affect product design. However, they will find that subtlety and subterfuge are sometimes necessary to make a politically correct impact in an organization that has not embraced interaction design as a formal part of the development process.</description>
	</item>
	<item>
		<title>Ten Ways to Kill Design</title>
		<link>http://tc.eserver.org/26073.html</link>
		<guid>http://tc.eserver.org/26073.html</guid>
		<description>The best designs and the best intentions won&apos;t always lead you to success, because the problem goes beyond your product and beyond your design or development process. Building better, more innovative, and more profitable products requires organizational change on a deep and difficult level.</description>
	</item>
	<item>
		<title>Using Personas to Create User Documentation</title>
		<link>http://tc.eserver.org/26074.html</link>
		<guid>http://tc.eserver.org/26074.html</guid>
		<description>Personas and other user-modeling techniques are often solely discussed as tools for product definition and design, but they are useful tools in other arenas, as well. Technical writers responsible for creating user documentation can benefit greatly from a well-defined persona set, too.</description>
	</item>
	<item>
		<title>Well-Designed Products</title>
		<link>http://tc.eserver.org/26076.html</link>
		<guid>http://tc.eserver.org/26076.html</guid>
		<description>To offset this sometimes irritating tendency to critique and redesign everything we see, I&apos;d like to offer a selection of software that I consider to be truly well-designed. To avoid creating a list that is simply an expression of my personal taste (which of course it is, to some extent), I devised some criteria as necessary aspects of a well-designed software product.</description>
	</item>
	<item>
		<title>Always Have a Backup Plan</title>
		<link>http://tc.eserver.org/23993.html</link>
		<guid>http://tc.eserver.org/23993.html</guid>
		<description>By anticipating failures, and designing backup plans, you can minimize the impact of unexpected problems on the user.</description>
	</item>
	<item>
		<title>Beating the Checkout Blues</title>
		<link>http://tc.eserver.org/23997.html</link>
		<guid>http://tc.eserver.org/23997.html</guid>
		<description>Depending on which research report you read, roughly 25% to 75% of online shoppers abandon their shopping carts before consummating the deal. Despite the disparity in numbers, all the research firms agree on one thing: that&apos;s way too many.</description>
	</item>
	<item>
		<title>Branding and the User Interface, Part 1: Brand Basics</title>
		<link>http://tc.eserver.org/23972.html</link>
		<guid>http://tc.eserver.org/23972.html</guid>
		<description>Develops a foundation for future, more detailed discussions by introducing several key brand concepts.</description>
	</item>
	<item>
		<title>Branding and the User Interface, Part 2: Tips on New Media Branding: Behavior and Color</title>
		<link>http://tc.eserver.org/23969.html</link>
		<guid>http://tc.eserver.org/23969.html</guid>
		<description>A look at how branding differs between traditional applications, like printed corporate collateral, and emerging new media applications, such as software user interfaces, with a focus on behavior and color. </description>
	</item>
	<item>
		<title>A Breath of Fresh Air</title>
		<link>http://tc.eserver.org/23986.html</link>
		<guid>http://tc.eserver.org/23986.html</guid>
		<description>It takes research, humility, and skill to truly understand your customers well enough to serve them better than your competitors.</description>
	</item>
	<item>
		<title>Bridging the Gap Between Design and Engineering Cultures</title>
		<link>http://tc.eserver.org/23990.html</link>
		<guid>http://tc.eserver.org/23990.html</guid>
		<description>Developers want details. They want information they can take back and talk about on their own. They want the space to decide, based on their own criteria, what is valuable and what is not. They make use of the divide between designers and developers to help maintain their boundaries.</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>Can Programmers Do Interaction Design?</title>
		<link>http://tc.eserver.org/23967.html</link>
		<guid>http://tc.eserver.org/23967.html</guid>
		<description>In most of the organizations we encounter during our consulting work, programmers tend to think they’re the best-qualified people to design the form and behavior of a product. In the absence of trained interaction designers, they may be right. They know from experience that no one else is going to think through all the implications of serving up that snippet of data in just the right way, and no one else questions the idea of programmers doing the interaction design because they assume it’s a technology problem. As a result, executives who lead technology initiatives believe that they already get interaction design for free from their programmers. In their opinion, having interaction designers is unnecessary; if the product happens to be hard to use, they assume the programmers just need some sensitivity training. Having programmers design the product is anything but free, though; it&apos;s ineffective, inefficient, and risky.</description>
	</item>
	<item>
		<title>Content Management Systems: Don&apos;t Automate the Misery</title>
		<link>http://tc.eserver.org/23992.html</link>
		<guid>http://tc.eserver.org/23992.html</guid>
		<description>Few organizations have seen much good come of content-management BPR initiatives so far. Of the many reasons for these failures, one stands out: these BPR initiatives—and the systems they spawn—are focused on realizing organizational objectives without sufficient regard for the context, habits, and goals of the people who will actually use the system. </description>
	</item>
	<item>
		<title>Critic to Creator: Recognizing Good  Design</title>
		<link>http://tc.eserver.org/23971.html</link>
		<guid>http://tc.eserver.org/23971.html</guid>
		<description>All too often, people in our field focus so much on pointing out the egregious interaction design mistakes that make it to market, we forget to pay attention to the good design that exists. Not only does it make our profession look bad if we are always complaining, but it also makes us less effective.</description>
	</item>
	<item>
		<title>Design Research: Why You Need It</title>
		<link>http://tc.eserver.org/23974.html</link>
		<guid>http://tc.eserver.org/23974.html</guid>
		<description>Just as important as market research, design research is a necessary ingredient for creating, developing, and delivering a successful product. Marketers need solid market research to guide their decisions about product positioning, revenue potential, and target markets. Likewise, designers need solid design research to guide their decisions about the product&apos;s interaction framework, feature set, and overall appropriateness for its users.</description>
	</item>
	<item>
		<title>Don&apos;t Get Burned by Bad Mapping</title>
		<link>http://tc.eserver.org/23985.html</link>
		<guid>http://tc.eserver.org/23985.html</guid>
		<description>The term mapping describes the relationship between a control, the thing it affects, and the intended result. Poor mapping is evident when a control does not relate visually or symbolically with the object it affects, requiring the user to stop and think, &apos;what&apos;s going to happen when I turn this knob?&apos;</description>
	</item>
	<item>
		<title>Features Talk, but Behaviors Close</title>
		<link>http://tc.eserver.org/23966.html</link>
		<guid>http://tc.eserver.org/23966.html</guid>
		<description>Features are often the currency of software development and marketing, yet few people can agree on what exactly defines a feature. The term can be used to describe a particular piece of functionality, an entire set of functionality, a capability, or sometimes even a possibility.</description>
	</item>
	<item>
		<title>Five Insights for Improving Product Development Cycle Success</title>
		<link>http://tc.eserver.org/23987.html</link>
		<guid>http://tc.eserver.org/23987.html</guid>
		<description>When creating software and digital products, innovation typically spans many months, and it can become disrupted by unobservable or frequently changing business conditions that make it extremely difficult to form and evaluate viable options. When people can&apos;t see where they&apos;re going, they typically just stop. This is tragic with respect to innovation, since it is innovation that propels business and society forward.</description>
	</item>
	<item>
		<title>Five Ways to Get the Most from In-House Designers</title>
		<link>http://tc.eserver.org/23970.html</link>
		<guid>http://tc.eserver.org/23970.html</guid>
		<description>Over the last two years, we&apos;ve heard from increasing numbers of executives who want to bring interaction design in-house because they&apos;ve realized how critical it is to product success. There are plenty of challenges involved in doing this, including hiring and training the right people. One of the challenges companies may not expect, though, is in deciding how to use those resources once they&apos;ve been found.</description>
	</item>
	<item>
		<title>Getting from Research to Personas: Harnessing the Power of Data</title>
		<link>http://tc.eserver.org/23977.html</link>
		<guid>http://tc.eserver.org/23977.html</guid>
		<description>The usefulness of personas in defining and designing interactive products has become more widely accepted in the last few years, but a lack of published information has, unfortunately, left room for a lot of misconceptions about how personas are created, and about what information actually comprises a persona. Although space does not permit a full treatment of persona creation in this article, I hope to highlight a few essential points.</description>
	</item>
	<item>
		<title>Goal-Directed Content Management</title>
		<link>http://tc.eserver.org/23980.html</link>
		<guid>http://tc.eserver.org/23980.html</guid>
		<description>Anecdotal evidence from within the CM industry indicates that CM implementations fail to meet corporate expectations about half of the time. Part of the reason for missed expectations could be poor usability.</description>
	</item>
	<item>
		<title>Innovate, One Step at a Time</title>
		<link>http://tc.eserver.org/23988.html</link>
		<guid>http://tc.eserver.org/23988.html</guid>
		<description>During recessions, uncertainty prevails, and like a driver trying to weave his way along a mountain road in heavy fog, many businesspeople eventually tire and just pull their businesses over to what seems like a safe embankment, turn off their engines of innovation and progress, and wait for the fog to lift. But how long can one afford to sit on the roadside? At what point does it become riskier to do nothing than to proceed with caution? One has to wonder if there&apos;s a better way, a way to keep moving forward in measured, confident increments, rather than eventually creating an additional element of uncertainty by deferring innovation altogether.</description>
	</item>
	<item>
		<title>Innovating For Humans</title>
		<link>http://tc.eserver.org/23999.html</link>
		<guid>http://tc.eserver.org/23999.html</guid>
		<description>Before starting to innovate, it is important to reflect on how different flavors of innovation are perceived by the people who will eventually use a product and what risks and opportunities are associated with each. Then comes the hard part: figuring out what the right innovations are and how to implement them.</description>
	</item>
	<item>
		<title>Interface Design as a Life or Death Proposition</title>
		<link>http://tc.eserver.org/23976.html</link>
		<guid>http://tc.eserver.org/23976.html</guid>
		<description>While the FDA has always required thorough documentation of product development, recent initiatives have instituted a more prescriptive, design-focused procedure encouraging extensive user research at the beginning of the development process.</description>
	</item>
	<item>
		<title>The Iteration Trap</title>
		<link>http://tc.eserver.org/24003.html</link>
		<guid>http://tc.eserver.org/24003.html</guid>
		<description>Iteration without a good design foundation is a very risky method.</description>
	</item>
	<item>
		<title>Making Use of User Research</title>
		<link>http://tc.eserver.org/23995.html</link>
		<guid>http://tc.eserver.org/23995.html</guid>
		<description>By focusing on how a product performs in the lab without broader knowledge of the user&apos;s environment and goals, measurement alone may be misleading. To get the most value and meaning out of user feedback it is important to choose the appropriate method for conducting and analyzing user research.</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>Not All Web Sites Are Alike</title>
		<link>http://tc.eserver.org/23973.html</link>
		<guid>http://tc.eserver.org/23973.html</guid>
		<description>Many people have a hard time talking about the distinctions between different kinds of Web development, which makes it difficult to decide how to proceed. This article offers a quick survey of various Web projects and of the techniques that address them.</description>
	</item>
	<item>
		<title>The Origin of Personas</title>
		<link>http://tc.eserver.org/23965.html</link>
		<guid>http://tc.eserver.org/23965.html</guid>
		<description>&lt;i&gt;The Inmates Are Running the Asylum&lt;/i&gt;, published in 1998, introduced the use of personas as a practical interaction design tool. Based on the single-chapter discussion in that book, personas rapidly gained popularity in the software industry due to their unusual power and effectiveness. Had personas been developed in the laboratory, the full story of how they came to be would have been published long ago, but since their use developed over many years in both my practice as a software inventor and architectural consultant and the consulting work of Cooper designers, that is not the case. Since Inmates was published, many people have asked for the history of Cooper personas, and here it is.</description>
	</item>
	<item>
		<title>Perfecting Your Personas</title>
		<link>http://tc.eserver.org/23996.html</link>
		<guid>http://tc.eserver.org/23996.html</guid>
		<description>It&apos;s easy to assemble a set of user characteristics and call it a persona, but it&apos;s not so easy to create personas that are truly effective design and communication tools. If you have begun to create your own personas, here are some tips to help you perfect them.</description>
	</item>
	<item>
		<title>Product Complexity Driving You Crazy? Learn Where to Cut</title>
		<link>http://tc.eserver.org/23979.html</link>
		<guid>http://tc.eserver.org/23979.html</guid>
		<description>The more complex your product is, the harder it will be to use. And the harder your product is to use, the more your customers will rely on your technical support department, which tends to increase your costs and decrease your customers&apos; overall satisfaction with the product. The good news is that one of the most simple and effective ways to reduce complexity is to cut unnecessary features from your product. But how do you know which features to cut?</description>
	</item>
	<item>
		<title>Putting People Together to Create New Products</title>
		<link>http://tc.eserver.org/23994.html</link>
		<guid>http://tc.eserver.org/23994.html</guid>
		<description>When companies plan out a new product (or service, or business process) they often think of the effort as the coordination of two teams solving different problems. Engineering addresses the question &apos;what can you make?&apos; Marketing addresses the question &apos;what can you sell?&apos;</description>
	</item>
	<item>
		<title>Reconciling Market Segments and Personas</title>
		<link>http://tc.eserver.org/23989.html</link>
		<guid>http://tc.eserver.org/23989.html</guid>
		<description>Market segmentation and personas are two different techniques that are often perceived as conflicting methods, but they are actually complementary tools that organizations can use to design and sell successful products.</description>
	</item>
	<item>
		<title>RUP and Goal-Directed Design: Toward a New Development Process</title>
		<link>http://tc.eserver.org/23968.html</link>
		<guid>http://tc.eserver.org/23968.html</guid>
		<description>Interaction design methodologies, such as Goal-Directed Design, tackle the software development process from the top down by defining specific product requirements and interface behavior based on research and user needs. The Rational Unified Process (RUP) and other agile programming methodologies attack software development from the bottom up. RUP creates fluid efficiencies for iterating product development during the construction phase in order to react to changing product requirements while still producing shipping code.</description>
	</item>
	<item>
		<title>So You Want to be an Interaction Designer</title>
		<link>http://tc.eserver.org/23998.html</link>
		<guid>http://tc.eserver.org/23998.html</guid>
		<description>We get a lot of email from students and usability professionals asking how one goes about becoming an interaction designer, and what background one needs to get into the field. What are good interaction design programs? What real-world skills and experience are required? What, exactly, do interaction designers do on a day-to-day basis?</description>
	</item>
	<item>
		<title>Three Traps</title>
		<link>http://tc.eserver.org/23991.html</link>
		<guid>http://tc.eserver.org/23991.html</guid>
		<description>We continue to see companies falling into the same product development traps, to the detriment of their products, their customers, and their business.</description>
	</item>
	<item>
		<title>Time Travel Design</title>
		<link>http://tc.eserver.org/24002.html</link>
		<guid>http://tc.eserver.org/24002.html</guid>
		<description>New technologies will introduce as many problems as they solve unless they are focused with good design.</description>
	</item>
	<item>
		<title>Today, More Than Ever</title>
		<link>http://tc.eserver.org/24000.html</link>
		<guid>http://tc.eserver.org/24000.html</guid>
		<description>The great promise of the information age is that computers help us to do everything. The great tragedy of the information age is that computers obstruct everything we do.</description>
	</item>
	<item>
		<title>Turning Requirements into Product Definition</title>
		<link>http://tc.eserver.org/23978.html</link>
		<guid>http://tc.eserver.org/23978.html</guid>
		<description>How do you get from understanding your users to a vision for an innovative product which will appeal to them?</description>
	</item>
	<item>
		<title>Waking Up to Good Design</title>
		<link>http://tc.eserver.org/24001.html</link>
		<guid>http://tc.eserver.org/24001.html</guid>
		<description>Why an awareness of good design has increased at such a dramatic rate in recent months.</description>
	</item>
	<item>
		<title>Navigating Isn&apos;t Fun</title>
		<link>http://tc.eserver.org/18661.html</link>
		<guid>http://tc.eserver.org/18661.html</guid>
		<description>The artless Websites created during the Web&apos;s infancy were of necessity built only with simple HTML tags, and were forced to divide up their functionality and content into a maze (a web?) of separate pages. This made a navigation scheme an unavoidable component of any Website design, and of course, a clear, visually arresting navigation scheme was better than an obscure or hidden one. But many Web designers have incorrectly deduced from this that users want navigation schemes. Actually, they&apos;d be happy if there were no navigation at all.</description>
	</item>
	<atom:link href="http://tc.eserver.org/publisher/Cooper_Interaction_Design.xml" rel="self" type="application/rss+xml"/>
</channel>
</rss>