Sign up to get our featured articles delivered straight to your inbox every month or two.
RSS feed of all articles
Architecture (3)
Books (3)
Branding (2)
Business (21)
Communicating design (7)
Cooper (4)
Critiques (13)
Design & engineering (8)
Design disciplines (4)
Design in organizations (19)
Design principles (13)
Development (6)
Ecosystem-centered design (5)
Events (1)
Experience (1)
Features (77)
Ideas (1)
Industrial design (4)
Industry-specific (11)
Information design (4)
Innovation (16)
Interaction design (14)
Methods (6)
Mobile (3)
Personas (10)
Platforms (3)
Product definition (7)
Requirements (2)
Research (10)
Service design (2)
Service design (1)
Strategy (4)
Techniques (27)
The Drawing Board (1)
Travel (3)
Trends (4)
TV (2)
Typography (1)
Visual design (13)
Web-related (8)
Design in organizations
Alan's keynote at Agile 2008
I was asked by the leadership of the Agile 2008 Conference to give the closing keynote address at their annual conference in Toronto. The audience at Agile08 consisted of about 1500 programmers, engineers, product managers, and others involved in the creation and deployment of software primarily using Agile methods.
My belief in the value of detailed written design has often led enthusiasts of Agile to assume that I am an adherent of the obsolete, and justly maligned, waterfall method of software construction. I was pleased to have this opportunity to state my position with clarity and precision, not to mention making the case for effective collaboration between interaction designers and Agile programmers.
Here are the slides and accompanying speaker's notes for my talk. Some in the audience noticed that I was reading from my notes during the presentation. If you're interested in why I chose to do this, read this Journal entry.
If you would like to discuss this presentation with me, either post a comment to the Cooper Journal blog or email me directly at alan@cooper.com.
Whither interaction design consulting firms?
Is interaction design done by consultants or employees?
When Cooper was launched as an interaction design consulting firm in 1992, the answer to this question wasn't at all clear. However, as the 90s drew to a close, I confidently predicted that the bulk of the interaction design done in the world would be done by consultants. I based this conclusion on the proliferation and success of interaction design consulting firms. I assumed that the industry would follow the model of building architecture, where major design projects are typically performed by outside consultants. Architects on corporate staff would act primarily as liaison and project management. And for the first few years of the 21st century my prediction appeared correct. Today, I wonder if I called it wrong.
More and more I see corporations both large and small with their own in-house interaction design staffers. In fact, in a broad sense, my company competes with our own clients for qualified designers. There are still many successful interaction design consulting firms, but I see an ever increasing number of design projects handled completely by internal design talent, and successfully at that.
This, of course, brings up the thoughtful question of "Whither interaction design consulting firms?" What will their role be in the next decade? Will the pendulum swing the other way, and clients find that it is less expensive to hire designers on a project-only basis instead of keeping them on staff full time? Or will the consultants find themselves working only on fringe projects that are too large, too small, too complex, or too unique?
I don't yet know the answer to these questions, but I'm leaning towards the idea of an ever-more specialized role for interaction design consultancies. What do you think?
Where does design belong in your organization?
These days, more and more companies are recognizing that design and innovation are essential to their strategy and bottom line: effective design sells products and services, improves your position in the marketplace, and turns customers into loyal advocates for your brand. If you've gotten your organization to this point, take a moment to enjoy your success! Creating demand for design is no small achievement. Unfortunately, to reap the full benefits of design, you probably still have a lot of work to do on your organization's structure, processes, and culture.
One of the first things you need to do is determine where in your organization design belongs. There are a variety of models, from outsourced design to an in-house consultancy to designers permanently embedded in individual product teams. No single structure is the right answer for every situation; you have to assess what's the best fit for the number and type of design needs you have, as well as for your organization's culture.
Collaboration with development is a handshake, not a handoff
We recently spent 14 months designing an investment platform for traders and portfolio managers. As you might imagine, this was a large and complex application that required a tremendous amount of collaboration with the client. Our team consisted of a design communicator, an interaction designer, two visual designers and an engagement lead. We spent many hours with subject matter experts (SMEs), business analysts (BAs) and developers, crafting a solution that satisfied the needs and goals of seven user personas (and because their real-world counterparts were also employees of our client, actual users reviewed our work every step of the way). This article describes some of the key techniques we employed to ensure that the interaction design was something our client's development team could implement (I'll focus on our collaboration about interaction design; visual design was a key component of this highly visual interface, and deserves its own article).
By any medium necessary: How interaction designers can save the world
An email from on high hits your inbox: the company is kicking off an initiative to "radically improve" the effectiveness and efficiency of its nationwide sales force.
Nothing new here, you think. This sort of thing sweeps over the land every few years, like locusts.
But as you drag the message into your Deleted folder, something new catches the eye. Your design team is being asked to carry out the first step of the initiative: conducting a research project to "gather requirements" for how to make the organization more effective.
Undo! Undo!
Aside from the fact that requirements are defined and not "gathered" (one pictures wine bottles hanging from grapevines), it's surprisingly level-headed to turn to interaction designers to examine organizational needs and propose solutions. Most of the time, it's business analysts and technology specialists who are tapped for these assignments. Analysts collect information about what makes the business tick; technologists, meanwhile, build and/or choose tools that work within a given infrastructure. But while the work of analysts and technologists is necessary, it is not sufficient. That's because they are rarely trained (much less asked) to describe usage contexts, identify goals, or design tools that satisfy people while also meeting the objectives of organizations. The result? Too often it's a new flavor of the same old thing, just more expensive this time around.
Myths and Measurements: Evaluating the ROI of Design
There's a dirty little secret that nobody in the design community wants you to know: it's actually possible to build and ship a software product…without designing it first! There. I said it. Now my time is short; even as I type, assassins with square-toed shoes and goatees are stalking my whereabouts.
But just because you can construct software products without designing them first, why on earth would anybody want to?
The analogies are endless: you wouldn't point a construction crew to an open lot and tell them to build a structure without giving them blueprints, would you? You wouldn't ask a doctor to re-set a broken bone without looking at an x-ray; you wouldn't storm the beaches of Normandy without a battle strategy and a good map; you wouldn't even don your shoes before putting on your socks.
Executives chuckle warmly at these analogies, and agree wholeheartedly that yes, it's always best to design products—the things that their companies sell for money—before building them and putting them in the hands of customers. Yet even though business decision-makers of all stripes acknowledge the merits of design, it's the designers and usability professionals who are the first to get jettisoned from a project plan when the going gets rough.
Ten Ways to Kill Good Design
It's a given that we at Cooper—and most of you reading this article—believe design is the right tool for translating market needs into tangible product specifications. The people who hire us to design their products or who attend our Cooper U courses think the same thing. Unfortunately, the best designs and the best intentions won'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.
When design pilot projects fail, it endangers everyone's willingness to adopt design methods. Over the course of doing hundreds of design projects and teaching our methods to more than a thousand people, we've seen that several reasons for failure keep showing up. A discussion of these reasons follows, along with some solutions to consider. Let's start with the easiest ones and work our way up.
Where Do Product Managers Fit?
People often ask how interaction designers should fit into their companies. If the company cannot take good advantage of it, the most brilliant interaction design in the world won't help as much as simple, workmanlike interaction design will benefit a company that uses that design well.
Technical Writing and Interaction Design
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.
Technical writers and interaction design
When I started my career as a technical writer in 1992, interaction design did not exist as a stand-alone discipline in a product development organization. My role in the development process went something like this: early in the development process, I made a documentation-effort time estimate based on some vague, high-level requirements provided by a product manager. Months later, development would finally distribute an early internal release, which only faintly resembled the initial requirements definition. The technical publications team would revise our time estimates and scramble to start documenting the software. Once a week, the development team would release another internal version of the software—which might or might not resemble last week's release—and so on.
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.
Can Programmers Do Interaction Design?
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’s ineffective, inefficient, and risky.
RUP & Goal-Directed Design: Toward a New Development Process
Abstract
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 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.
Although different, the two approaches are both successful ways to manage software product development. Do development organizations need to choose one methodology over the other? Or are the two development strategies complementary?
5 Ways to Get the Most from In-House Designers
Over the last two years, we've heard from increasing numbers of executives who want to bring interaction design in-house because they'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've been found.
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.
A Breath of Fresh Air
When all you have is a hammer, everything looks like a nail. If you have never seen a wrench or a screwdriver you will have a hard time seeing what you need, even once you discover that your hammer does not work very well on bolts or screws. This makes it hard to break away from tools that do not serve you. Under pressure, companies tend to fall back upon what they know, so they often end up trying to solve problems with the same tools that got them into trouble in the first place. When this tactic threatens to choke an organization, we call it "breathing your own exhaust."
Right now, many companies see an opportunity to approach product creation from a fresh perspective. With the frenzied dot-com "business model" no longer a distraction, and the recession apparently easing, these companies are looking for ways to benefit from their painful experiences and create a better crop of products and services. They want to nurture customer loyalty by building products that please their customers, rather than following fads or stacking up long lists of features that no one really wants. Everyone knows pleasing customers is the right thing to do, but how do you really do it?
Bridging the Gap Between Design and Engineering Cultures
A few years ago I conducted a workshop on ethnographic mapping methods with a Pueblo community in the Southwest. While I wasn't familiar with Pueblo cultures, I had heard they were rigorously private. For example, I was asked not to discuss the specific details of the Pueblo's history or personal stories—normally a key topic in the workshop.
Despite these precautions, I was surprised when the group seemed unimpressed by the exercises in the workshop. They were often hesitant to participate, especially in the exercises that focused on developing skills for mapping personal stories, historical accounts, and cultural data. I was told, instead, that they were not prepared to talk about these things in the presence of outsiders—meaning myself and some other attendees from a nearby Pueblo. Instead, they asked for handouts.
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.
Putting People Together to Create New Products
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 "what can you make?" Marketing addresses the question "what can you sell?"
You could engineer a combined toaster and cell phone, but you could never sell it. Marketing would tell you that you have a product no customer would buy. Likewise, you might successfully market a car that runs on tapwater, but the impossibility of building one makes it a meaningless product idea. Smart organizations know that they need to combine the insights from both marketing and engineering to find products that they can both make and sell.
Today More Than Ever: The Lost Chapter of The Inmates Are Running the Asylum
Computers and their software participate in every aspect of the precious and delicate relationship between the company and the customer. The typical customer first learns about your product from an email advertisement or a computerized mailing. He visits your website to find out more about it. He buys it from your online store, and you ship it to him by FedEx, where he uses software to track it on his PC. Once delivered, even if your product isn't 100% software, it very likely has some silicon intelligence inside it. When your customer can't figure out how to work it, he calls your company on the telephone (which is itself a computer). The first thing he hears is the stilted and artificial voice of your automated call distribution system, instructing him "for technical assistance, press one now." Finally, the software puts him in contact with a real human, only for him to find that this person-trained by software-is merely echoing instructions from a problem report database software program running on his computer!
Email it to us and we may answer it in an upcoming article.