Design Loneliness

On a recent project a client confessed some small degree of envy of Cooper’s team structure. He was the sole designer at a medium sized software company doing good work, but unsatisfied doing it alone. In our short project he was able to see the value of paired design and wasn’t looking forward to heading back to business as usual. I’ve got four ideas on what someone can do in this circumstance, but first let me extol the virtues of Paired Design.

Continue reading...

A “to do” list for integrating design into your organization

The good news: whether it’s thanks to the economy or to the iPhone, more senior executives understand that they need to get some design love. The bad news: Most expect that it will be easy. Most execs who want to integrate design into their organizations (or expand the role of an existing team) ask us for help with training, establishing some best practices, or perhaps developing some design tools. Sooner or later, though, real success with such efforts requires attention to five different areas.

1. Process
   Figure out how design is going to work in your organization. This can’t be treated as purely a design process problem; you have to consider the product development process overall. How will designers work with product managers, subject matter experts, engineers, and others from early problem definition and concept through shipping product? How will you figure out what users and customers need, and what can differentiate your product or service from others? How will you arrive at one or more good solutions, and how will you ensure that they actually are good? How will you communicate, build consensus, and ensure accountability along the way? And how will this approach differ depending on the scale and type of problem you’re trying to address? While of course I’m a fan of Cooper's own Goal-Directed Design process and think it’s widely applicable, any process has to be adapted to its environment, whether because you need to comply with FDA regulations or because you’re tweaking the product for every customer. Of course, if you’re in a healthy, learning organization, your process will always be something of a work in progress.


2. Structure
   Determine not just how design teams are structured, but what comprises an entire project team. Look beyond the project level, too; where does design live in the org chart? How will you ensure that designers have close working relationships with their product teams, but still have an opportunity for design mentoring as well as sharing ideas and skills across multiple projects? What reporting line gives design the necessary authority to champion desirability alongside technical feasibility and market viability? What work will you do in-house, and what will you outsource? How many designers do you need, and do you need generalists, specialists, or both? Do you need to pair designers with business analysts or subject matter experts?


3. Skills
   Having process and structure without the necessary skills is a bit like sitting down at a table full of dishes without any food. What skills do you need, and how will you obtain them? It’s difficult to start or grow a design team without hiring some talent (especially design leadership) from outside. That said, there are only so many trained designers in the world, so some organizations build part of the team by training product managers or engineers who have the right attitude and aptitude. Even if you hire a group of experienced designers from outside, existing product management and engineering teams will need to learn some new skills to work effectively with them. How will you hire? What training will people need to begin with, and how will you ensure that new hires get the skills they need?


4. Tools
   Although experienced designers can get away with standardized tools, they’re more efficient if they’re not reinventing the wheel for every project. Less experienced staff often benefit from templates that help ensure they’re thinking through the right aspects of a problem, whether that’s a user interview, a description of design behavior, or a usability test plan. Engineers typically appreciate standardized styleguides and document templates so they get predictable output, too. It’s essential, however, that everyone understands the why of their tools; otherwise, documents and forms become part of a rote checklist and cease to be helpful.


5. Culture
   If you’ve ever bought a house, you’ve probably heard this little mantra: “Location, location, location!” When it comes to organizations that really put design in the driver’s seat, the chant should be “Culture, culture, culture!” I’ve seen clients with lousy process and average (or no) designers beat the heck out of the competition because they’re focused on delivering quality customer experience from top to bottom. Cultural change is the to-do item that nearly everyone neglects, and it’s the one that will make or break your success with design. What does your organization value? Consider what your hiring, evaluation, and compensation practices say about that. What do executives and managers talk about not just in big company gatherings, but also in day to day interactions? Where does the company invest its resources, and where does it take shortcuts? Developing process, skills, and tools without changing the culture is going to result in incremental improvements at best.
   
   
   If you try to change an organization without addressing its culture, you may never get where you’re going.

   
   Of course, you also need a plan for tackling all five of these areas in a coherent fashion. John Kotter’s Leading Change is a good place to start learning about what it takes to move an organization. Changing an organization is much harder than the toughest product design problem you’ve ever tackled; pixels, unlike people, generally do as they’re told.

    

   What do you think? Join the conversation in Comments

Is incremental design the wave of the future?

An old friend and former client — let's call him "Paul L." — sent me an email question the other day, asking “Is incremental design the wave of the future, or just a flash in the pan?”

When I finished my response, I thought that it might be of interest to a wider audience. Here is the exchange.

Alan,

My wife teaches computer science at Menlo College. She has been teaching software engineering based upon the traditional cycle of specification, design, development, testing.

I have seen some Research Channel TV shows that talk about Incremental design. Google and Inuit are two companies that seem to be having some success with ID.

My wife and I have been talking about ID as compared to the traditional methods. During the discussion I thought about my friend, the Design Guru. I am wondering if you have any thoughts on ID. Is it the wave of the future or just another flash in the pan?

Thanks,
Paul

Paul,

As agile methods take over the programming world (and they will), EVERYONE else will adjust accordingly. The old paradigm of everyone hunkering down and protecting their turf from everyone else is what gave rise to the "traditional cycle" (which is, by the way, uniquely ill-suited to software construction and design).

The new (agile) paradigm isn't at all defined yet, but it characteristically includes a) Generation Y programmers; b) a refreshing belief in the potential for change; c) the understanding that satisfying human users requires special efforts and probably special skills; d) a belief that software should be built in continuous increments; e) a corresponding belief that everything else in the world relating to software would benefit from such continuous increments; f) that building software is a team endeavor; and g) that nobody has solved these problems before.

Continue reading...

A good design critique

How do you thoroughly critique a design without crucifying the designer? What are ways of critiquing that result in better designs, rather than defensive justifications?

Scott Berkun explores a model for design critique in a detailed post, but I'm interested in the little stuff that works for your design team in day-to-day practice.

At Cooper, our teams often work together for a year or more. It is important for us to create a dynamic of cooperation, but great design often happens when we push on assumptions and challenge the first iteration. We want to encourage this critique, but make sure that it doesn't derail the meeting.

Why is that good?

It's pretty common to hear a skeptical Cooper designer begin a critique with some variant of the question, "Why is that good?" Many ways to express disagreement have negative effects on the meeting or relationship. "That won’t work because," or "But what about." These tend to bring momentum to a halt. Designers must stop, defend their ideas, or chase objections.

As anyone who has faced a blank whiteboard knows, once the ink gets flowing it is important to run with it and see where the idea goes. Communication strategies of design partners can enhance or detract from this process. By asking to see the goodness, we focus on enlightenment, encouraging our partner to help us see what they see. Also, asking an open-ended question is an acceptably naïve way of pushing your design partner to step up and show you what is going on in their mind.

At the core, we want our teams to feel comfortable in expressing healthy disagreement, and to focus on clarifying rather than justifying.

What are ways that your team has developed to critique design while maintaining harmony on the team?

What do you think? Join the conversation in Comments

Playing well with others: How to create effective design teams

Continue reading...

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.

What do you think? Join the conversation in Comments

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?

What do you think? Join the conversation in Comments

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.

Continue reading...

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).

Continue reading...

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.

Continue reading...

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.

Continue reading...

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.

Continue reading...

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.

Continue reading...

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.

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...

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.

Continue reading...

RUP & Goal-Directed Design: Toward a New Development Process

Interaction design methodologies, like 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?

Continue reading...

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.

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...

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?

Continue reading...

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.

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...

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.

Continue reading...

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!

Continue reading...