Bringing sanity to swat-team design projects

In a perfect world, interaction design would begin when a product was still just a twinkle in a venture capitalist’s eye. In reality, many software products make it all the way through the development cycle with little thought to the users’ experience, and when executives, sales people, or QA testers finally get their hands on the functioning product and start sounding the alarm bells, interaction designers are brought in to clean up the mess. With increasing demand for design “swat teams” to rescue fully developed but flawed software that is scheduled to ship within months or even weeks, the critical question becomes: how can you avoid getting caught up in the chaos that frequently permeates “crisis-mode” engagements?

Continue reading...

Features Talk, but Behaviors Close

What’s a feature?

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. The experts are no help. Typical is webopedia.com, which goes out on a limb by stating that a feature is, “a notable property of a device or software application.”

In other words, a feature is a feature of something.

What is telling, though, is that the vast majority of definitions refer to featuritis or feature creep, the seemingly endless proliferation of features that glom onto what was once, perhaps, a product with a clear vision. Everyone knows that features pop up during the product cycle like mushrooms after a rain.

Continue reading...

Turning Requirements into Product Definition

In his newsletter article last month, Ryan Olshavsky outlined an overall process for defining new products and services, taking a look at the start of that process. But how do you get from understanding your users to a vision for an innovative product which will appeal to them?

Continue reading...

Bridging the Gap with Requirements Definition

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't click with its audience, though, the costs—development, employee, manufacturing—can be staggering. How do you ensure that your new product doesn't flop? One effective method is to conduct a requirements definition phase before developing a new product.

Requirements definition simply means "figuring out what to make before you make it." This process is not unique to software products. Architects, for instance, go through a requirements definition phase before they start construction on a home. They talk to the future home owner and determine how many floors and rooms will be in the house, where the bedroom should be, if there's a deck, and so on. Similarly, in the product development world, requirements definition enables you to make appropriate decisions about the functionality and design of a product before you invest time and money developing it. By bridging the gap between the needs of the market and those of your organization, requirements definition significantly reduces guesswork in technology product planning, and helps ensure that business and engineering are working on the same product.

Continue reading...

Product Complexity Driving You Crazy? Learn Where to Cut.

All other things being equal, 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' 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?

Well, it's not easy. Marketing wants a feature that one of your competitors has so they can cook up one of those bulleted feature comparison charts. The engineers have an idea for a feature that they think is really interesting, and one of them spent the entire weekend coding it. And then there's the "squeaky wheel" customer in Arizona that wants a particular esoteric feature that no one else seems to care about…

Continue reading...

Three Traps

We talk to a lot of technology companies here at Cooper, and over the years we've seen some clear patterns emerge. On the positive side, more and more companies are realizing the importance of a good user experience and of the overall usability of their products. Unfortunately, we also continue to see companies falling into the same product development traps, to the detriment of their products, their customers, and their business.

These traps can be hard to spot, because they often appear to be standard business practices (especially when the company has never done it any other way), but when you take a step back you see that those practices really don't make much sense. If you have the nagging feeling that there's something not quite right with your product development initiative, it may be because you're falling into one of these traps. To help you recognize bad practices and work to avoid them, here are three common development pitfalls.

Continue reading...