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 (3)
Critiques (12)
Design & engineering (8)
Design disciplines (3)
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 (12)
Methods (6)
Mobile (2)
Personas (10)
Platforms (2)
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 (1)
Typography (1)
Visual design (12)
Web-related (8)
Features
The Drawing Board: Episode One
Here at Cooper, we find that looking at the world from the perspective of users and their goals makes us notice a lot of bad interactions in our daily lives. Being solution-minded designers, we can’t help but pick up a whiteboard marker to scribble out a better idea. (Just ask our partners and friends—we really can’t help ourselves).
This sort of thing makes a fun thought exercise, so we thought we’d share it with you as a series of narrated slide shows we’ve called “The Drawing Board.” These aren’t meant to be slick, highly-produced demos—just some ideas we’ve thrown up on the board to stimulate thought and discussion. So…enjoy. Discuss. Design.
Taking the Call on Vimeo
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.
Beautiful Monsters: With such a late start, we best get moving
From our position at the confluence of human desire, technology, and business, interaction designers can make a tremendously positive—or negative—impact on the biggest issues facing us today: the sustainability of commerce, human societies, and natural systems. Despite these opportunities, software makers are discouraged from thinking outside the aspect ratio of the computer ’s monitor.
This is the first in a series of articles intended to serve as an ongoing conversation about how interaction designers can move the industry toward an Ecosystem Centered Design to improve our fortunes, our relationships, and the health of our planet.
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?
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.
Whiteboardability: How to make process diagrams memorable
Have you ever been in a design review where instead of talking about the proposed solution you spend half the time revisiting what the user is trying to accomplish in the first place? Keeping the human-centered models of the processes that lie behind your solution fresh in the minds of stakeholders (and designers) can prevent this unwanted rehashing. One way to ensure this is to create a diagram and give it qualities that make it simple enough and memorable enough so that, on a dime, you can whip out a dry-erase pen and sketch it out as a reminder.
I like to call that collection of qualities whiteboardability. It won't work with extremely complex business processes, but for simpler processes or most consumer domains, it works well.
Design engineering: the next step
Software construction is slow, costly, and unpredictable.
Slow is a big problem because markets and technologies are always in rapid flux and our ability to maintain pace is critical to our competitiveness.
Costly haunts business people because every precious dollar spent on software design and construction is typically a dollar that is difficult—if not impossible—to directly attribute to a measurable benefit.
Unpredictable is by far the nastiest of these three horsemen of the software apocalypse. Unpredictable means 1) you don't know what you are going to get; and 2) you won't get what you want. In badness, slow and costly pale in comparison to unpredictable. While well-tempered business people are loath to part with either time or money unnecessarily, exchanging time and money for an asset that generates an offsetting future flow of revenue is the essence of business, and "slow" and "costly" are relative terms. If something costs millions and takes years it can still be considered excellent business if the return is tens of millions annually over dozens of years. However, exchanging time and money for something that doesn't generate an appropriate flow of revenue is bad. Very bad.
Intuition, pleasure, and gestures
"Intuitive." We use the word a lot when talking about interactive systems, but it misleads us.
When people say they want a system to be "intuitive," they typically think they mean that users should immediately understand how a system works when they encounter it. But you cannot really do that with many systems … not even with most systems people talk about when you ask them for an example of something "intuitive."
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).
Using research to end visual design debates
Imagine the following scenario: You're involved in a new product design project and are presenting several visual design options to the team. Everyone in the meeting is leaning toward one direction when in the back of the room an executive's hand shoots up. "I don't like orange," he says, and suddenly the meeting spirals out of control, degrading into a discussion about whether or not the square elements of the interface look too blocky, and "Could we use circles instead?"
If you've ever had to present visual design to a group, you probably have your own collection of similar horror stories. But why is it that a group of otherwise level-headed adults can't seem to have a productive meeting about visual design? The short answer is that in the absence of clear context about what they are evaluating, most people don't know how to objectively evaluate visual design, so they rely instead on subjective intuition.
Why is there subjectivity in this process? Visual communication, perhaps even more so than verbal communication, is a nuanced language. Rich gradations of tone and style exist in even the most straightforward of applications. As the old saying goes, a picture is worth a thousand words, and this is just where the trouble begins. A thousand words—especially when they're the wrong words—can do a lot of damage.
About Face 3: Foreword
The industrial age is over. Manufacturing, the primary economic driver of the past 175 years, no longer dominates. While manufacturing is bigger than ever, it has lost its leadership to digital technology, and software now dominates our economy. We have moved from atoms to bits. We are now in the postindustrial age.
More and more products have software in them. My stove has a microchip in it to manage the lights, fan, and oven temperature. When the deliveryman has me sign for a package, it's on a computer, not a pad of paper. When I shop for a car, I am really shopping for a navigation system.
More and more businesses are utterly dependent on software, and not just the obvious ones like Amazon.com and Microsoft. Thousands of companies of all sizes that provide products and services across the spectrum of commerce use software in every facet of their operations, management, planning, and sales. The back-office systems that run big companies are all software systems. Hiring and human resource management, investment and arbitrage, purchasing and supply chain management, point-of-sale, operations, and decision support are all pure software systems these days. And the Web dominates all sales and marketing. Live humans are no longer the front line of businesses. Software plays that role instead. Vendors, customers, colleagues, and employees all communicate with companies via software or software-mediated paths.
Interview tips: The critical first five minutes
Goal-Directed Design necessarily involves first-hand research with real-world users. Whether these interviews last 30 minutes or two hours, the first few minutes of discussion are vital to establishing rapport with your participant.
Outside of celebrities and politicians, few people are practiced at giving interviews. And while participants are almost always willing to help as best as they can, there may be some unspoken questions troubling them before an interview begins. This article offers a list of common topics that proactively address these questions and make participants feel at ease.
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.
Three books to spark your design thinking
For the past several months, I've been working with Alan Cooper and Robert Reimann on the latest version of About Face, Alan's classic book on interface and interaction design. One of the major objectives with this new third edition has been to bring the book up to date with current conversations about the design of interactive products, which has been a great excuse for me to dig into the growing body of literature on the subject.
In particular, the last year saw the publication of three very worthwhile tomes written explicitly on the subject of interaction design. (Those of you who have been in the field for a while probably share my shock to have such a wealth of discourse.) Despite the almost comic similarity in their titles, the three books each cover different ground but are really quite complementary. These three books, along with Mullet and Sano's Designing Visual Interfaces and About Face (naturally) would be a fantastic curriculum for someone interested in interaction design.
Taking Personas Too Far
I don't have to tell you that at Cooper, we love personas—how could we not?—and we're glad to see continued excitement about them. That said, although personas are essential design tools, we think some people may be losing sight of the fact that they're just tools, and tools with a specific purpose, at that. Lately, we've been seeing a lot of gold-plated hammers—unnecessarily elaborate communication about personas—and some fundamental misunderstandings about the relationships among research, personas, and scenarios.
Ignore that designer behind the persona
One piece of advice I have received in my first year here at Cooper is to avoid referring to personas as creations. Of course they are, and everyone knows it, but they work better if we refer to them as if they were real people in the world. For example, the conversation got off track a bit in one client presentation when I said, "We gave Tracy two kids, with one heading off to college…" The discussion went from being about the personas and the design problem to being about why we gave Tracy two kids, and what tweaks might be made to better fit the persona to the client's expectations. Had I instead said something like "Tracy has two children, the older of whom is about to head to college," the conversation likely would have remained on track. Why is that the case?
Communicating Design Concepts Without Getting Skewered
We have a saying around the office: "If you can't explain the design, it must not be right yet." It's a reminder to designers to not get so caught up in idea generation and specifying details that we lose sight of creating a coherent big picture for the design.
We need to exercise the ideas we generate by articulating them coherently; chances are high that if we can't describe our "great idea" with clarity, it's not such a great idea, after all. It's amazing how many design ideas seem just dandy on the whiteboard, then deflate like a punctured balloon when poked at with the sharp pencil of design communication.
Goal-Directed Service Design
Most people think of Goal-Directed Design techniques as focused on product design, but they work equally well for services. A service is comprised of the various "touchpoints" between a customer and a business. Touchpoints include public-facing systems such as web sites and web-enabled software, but can include other channels as well, such as brick-and-mortar stores, points of sale, interactive voice response systems, email and postal mail, too.
A service model best fits offerings that are intangible, distributed in space, or play out over a length of time, especially on a routine basis. Some obvious examples include: electricity, hotels, mobile phone service, or even a government. The touchpoints you design as part of your service are critical to the user's understanding of your brand. Increasingly, many touchpoints are interactive systems rather than human contact, so paying careful attention to the design of these things from the user's goals is vital.
Six Sigma and Goal-Directed Design
If you work for a large company, or have one as a client, you've probably heard about Six Sigma. Many companies report great success using Six Sigma initiatives to improve the quality of their products and services, measured by increased customer satisfaction and millions of dollars saved.
At the core, Six Sigma and Goal-Directed design share some of the same values and provide tools to solve some of the same problems. Six Sigma seeks to understand and quantify the functions that matter most to users and provide improvements in those most leveraged areas. Goal-Directed design seeks to delight users and increase loyalty by creating products that are powerful and pleasurable to use. Six Sigma identifies and tracks faults "critical to quality" (CTQs). Goal-Directed design uses personas and goals to define and communicate interaction design decisions.
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.
Early and Often: How to Avoid the Design Revision Death Spiral
Introduction
One lesson we've learned over the past several years here at Cooper is that on the vast majority of our projects, intimate client collaboration is a critical ingredient for success. This is a lesson that we have sometimes learned the hard way; collaboration can be messy, unpredictable and has often forced us to compromise what we thought was a supremely clear and elegant vision. Despite these growing pains, we have now come to embrace the unpredictability and compromise; through well-managed client collaboration, our designs are stronger and are more likely to serve our clients' needs and satisfy the goals of end users.
It is the aim of this Practice Study to discuss the methods we have adopted to get maximum benefit from our clients' expertise and feedback while maintaining creative momentum and achieving our milestones and deadlines.
The Web, Information Architecture, and Interaction Design
The impact of digital technology—from the Web to mobile phones to the silicon in your toaster—has meant a proliferation of terms for the work people do to define digital products and services. People talk about "customer experience," "user-centered design," and so forth. This talk can confuse even people who do that work for a living, as you often find different people using different terms to mean the same thing—or using the same term to mean very different things!
Many people say that this reflects a breakdown of disciplinary distinctions in designing for the new world of the digital. "It's all just design." I disagree. I see a few major types of problems in the digital world, and I believe that each of these has its own set of tools and methods that work well to solve that type of problem.
Typography and the User Interface
There is a quiet issue that nags at the computer industry. While processing speed and computational flexibility have grown at incredible rates, our displays, the most human-facing elements of our digital lives, lag behind.
Addressing an audience of information designers, Edward Tufte once explained that the fundamental challenge with presenting information is that the world we live in is high-resolution and multi-dimensional, yet all of our displays are most decidedly not. And while Tufte was initially referring to the problems of displaying rich data on paper, he was quick to point out that digital displays suffer the same problem but to an even greater degree. It may be tricky to map multiple axes of information (time, temperature, dollars, color, widgets sold, etc.) onto a two dimensional representation, but your difficulties are only compounded when you add the considerable handicap of reducing the target display resolution to a fraction of that of an equally sized piece of paper1.
Using Personas to Create User Documentation
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.
Using personas to guide your user-documentation creation-process helps you:
- Determine the primary and secondary audiences for your documents
- Prioritize technical writing tasks by giving you a tool for identifying which aspects of the product are most important to your readers
- Write documentation in a way that helps your users achieve their goals, instead of simply cataloguing all of the product's features.
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.
Well-Designed Products
A common affliction plaguing many of us interaction designers is the propensity to complain and kvetch about every piece of software on our computers, cell-phones and cars. And it's true—there is a lot of bad software out there.
To offset this sometimes irritating tendency to critique and redesign everything we see, I'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.
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.
2nd Edition Foreword Excerpt: The Inmates are Running the Asylum
In my recent travels I have noticed a growing malaise in the community of programmers. Sadly, it is the best and most experienced of them who are afflicted the worst. They reflect cynicism and ennui about their efforts because they know that their skills are being wasted. They may not know exactly how they are misapplied, but they cannot overlook the evidence. Many of the best programmers have actually stopped programming because they find the work frustrating. They have retreated into training, evangelism, writing, and consulting because it doesn't feel so wasteful and counterproductive. This is a tragic and entirely avoidable loss. (The open-source movement is arguably a haven for these frustrated programmers—a place where they can write code according to their own standards and be judged solely by their peers, without the advice or intervention of marketers or managers).
Programmers are not given sufficient time, clear enough direction, or adequate designs to enable them to succeed. These three things are the responsibility of business executives, and they fail to deliver them for preventable reasons, not because they are stupid or evil. They are simply not armed with adequate tools for solving the complex and unique problems that confront them in the information age. Now here I am sounding like I'm slamming people again, only this time businesspeople are in my sights instead of programmers. Once again, to solve the problem one must deconstruct it. I'm questing after solutions, not scapegoats.
Designing for Offshore Development
Everyone's talking about outsourcing and offshore development these days. It's been on the cover of major newsweeklies, featured prominently on the West Wing television show, and a topic of conversation around boardrooms and discussion groups. Regardless of your personal position on trade policy, globalization looks like it's going to be a fact of life in the software industry.
As an Interaction Designer, I'm not responsible for actually building the products I design. However, 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.
Common Myths about Web Design
The hype that surrounded the Web and its concomitant New Economy led to many popular myths concerning the design of Web content and Web-based applications. We can forgive this kind of mythology, which is typical of most popular technical innovations. When commercial and industrial use of electricity became a reality at the end of the nineteenth century, it was commonly believed to have miraculous powers not only to transform business and society, but also to cure almost any conceivable ailment by "restoring the life force." Like electricity, the Web has transformed our society to some degree, even in the relatively short time span since its introduction. However, it took 50 years for our use of electricity to mature, and it will doubtless take as many years for us to realize the full benefits and socioeconomic ramifications of the Web.
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.
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.
Going with the Flow: Interaction Design for Healthcare
Healthcare is a target-rich environment for design. Discussing even the smallest design challenge quickly exposes the hacked-together systems and processes that somehow function to help us stay healthy. Designers must understand the context in which they work, yet confronting the complexity of healthcare can be paralyzing. It seems impossible, for example, to discuss the viability of mobile devices at the point of care without discussing the Byzantine network of roles, regulations, and workflows that the device touches: nurse assistants, the lab, the patient, receptionists, regulatory bodies, HIPAA, hospital and lab information systems, IT departments, point-of-care coordinators, ADT systems, and so on.
While it’s important to understand the knotty context of a healthcare design problem, it’s just as important to know when to reach for the sword of methodology to cut through it. To illustrate this point, I’ll discuss some healthcare design challenges I’ve seen during my research and design work and the methods I’ve used to tame the complexity.
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.
The Origin of Personas
The Inmates Are Running the Asylum, 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.
In their book, Fire in the Valley, authors Paul Freiberger and Mike Swaine, credit me with writing the “first serious business software for microcomputers” as far back as 1975. Like so much software of the time, it was terribly hard to use, and its real power was in demonstrating that making software easy to use was harder than everyone thought. Despite my commitment to making software more user-friendly, it wasn’t until 1983 and about 15 major business and personal applications later that I began to develop a more effective approach.
Branding and the User Interface, Part 2: Tips on New Media Branding: Behavior and Color
In the April 2003 newsletter, we introduced a new series devoted to exploring the opportunities and challenges related to branding technology-based products. The first installment presented a handful of basic, high-level brand concepts. In part two of our series, we will take a closer 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. If there are particular topics you are interested in, feel free to submit them, and I will try to address them in upcoming articles.
Why is Software Significant to Branding?
Everyday, more and more customer touch-points traditionally facilitated by human representatives are instead administered by computers. This is the case even in the most common experiences. For instance, when you check out of most grocery stores, whom do you pay? You may think you’re paying Patty, the human checkout clerk, but I bet many of you are actually sliding a card through a computer (you know, the one that asks, “credit or ATM?”).
These days, you can no sooner operate your business without computers and their software than you can without people. Your company may sell auto parts, vacuum cleaners, or fine wine, but if you have a Web site or B2B e-commerce system, you’d better believe you’re in the software business, too. Because of its increasingly significant impact on your company’s brand, the quality of software’s behavior is a crucial factor in your organization’s success.
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?
Critic to Creator: Recognizing Good Design
Someone always asks the question, and I am never ready for it.
"So, what products out there are well-designed?"
As an interaction designer, I learn about users and design a product that helps them meet their goals—one that is tailored to the way they work. Yet this question can still stump me. I am not alone: 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. How can we create good products if we can only articulate what “bad” is?
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.
Not All Web Sites Are Alike
With the Web now completely ubiquitous and familiar, and the frenzy of getting on the Web for novelty’s sake long past, companies routinely turn to the Web to address many types of challenges. A Web site can offer a simple brochure for communicating with customers, a way to disseminate information to people within a large organization, a tool for running complex business processes, and much more. Because different sites try to address different problems, creating them requires different kinds of planning and development.
Although it may sound like a truism, 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.
Branding & the User Interface: Part 1
This article introduces a new series devoted to exploring the opportunities and challenges related to branding technology-based products. The first installment develops a foundation for future, more detailed discussions by introducing several key brand concepts. Forthcoming articles will present a variety of brand-related topics including the differences between traditional media and new media, how to solve common branding challenges, and several case studies that characterize successful technology-focused brand strategies. If there are particular topics you are interested in, feel free to submit them and I will try to address them in upcoming articles.
What is brand?
In tangible terms, brand is a name, a symbol/sign, and typically a system of fundamental visual, verbal, and written characteristics; however, the true essence of a brand extends beyond what we can see and hear. The significance of your company’s brand is also defined by the sum of its interactions with people.
Do U SMS? Text Messaging is Not the Hassle it Once Was
Few modes of communication burden the user with as much interaction hassle as text messaging on mobile phones. Without help from word-prediction assistants, the word "Hello" requires 13 button-presses, not including an additional 5 to get from the start screen to the messaging app. Nevertheless, the clear benefits of short text message services (SMS) have lured untold millions into uncomfortable, not to say unsatisfying, partnerships with their mobile phones.
Design Research: Why You Need it
Ever notice how often a product that makes a huge splash at tradeshows fizzles in the marketplace? The story goes like this: Product is introduced at show to much fanfare. News media gives Product lots of press, and consumers everywhere express interest in Product's features and capabilities. Product hits store shelves…and stays there. Some early adopters purchase Product, but it never penetrates into mass consumer markets.
What went wrong? Market research clearly identified potential dollars in target markets just waiting to spend money on the new product. So why did it fail?
Notable Product: How Nokia´s 8290 Does Something Right
Most people buy mobile phones because they want to be able to make phone calls anywhere, anytime. All the other stuff that's crammed into phones—calculators, game players, text-messaging capability—represents incomplete solutions for problems that are better served by devices dedicated to those needs. If I want to play a game on the go, I won't buy a Nokia 8290.
Still, phones offer a lot of sophisticated functionality to support specific mobile phone needs. Users need a way to quickly change ring-tones, ring volume, and message alert tones—so phone manufacturers allow you to tweak these so that one's phone can behave appropriately as one moves from the construction site to the movie theater.
Making Your Design Real: The Form & Behavior Specification
This article is one in an occassional series on design documentation. The first article in this series, Bridging the gap with requirements definition, by Ryan Olshavsky, discussed how to document the needs of the user and the domain issues relevant to the design of products. The second article, Turning requirements into product definition, by Jonathan Korman, discussed how you get from an understanding of your users to a vision for an innovative product that appeals to them. The present article discusses how a detailed specification of the form and behavior takes the guesswork out of product development.
Getting from Research to Personas: Harnessing the Power of Data
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.
Interface Design as a Life or Death Proposition
In the mid-1980's, a team of physicians, lawyers, and public health experts conducted a lengthy study of the nature and causes of medical errors. They published their findings, entitled "Incidence of adverse events and negligence in hospitalized patients," in the New England Journal of Medicine in 1991.[1] Their research indicated that "there is a substantial amount of injury to patients from medical management, and many injuries are the result of substandard care." While the industry evaluations and renovations sparked by these findings have taken effect, physicians and clinicians have simultaneously adopted more sophisticated technologies to provide more accurate and efficient care. [2]
In Telematics, No Technology is a Panacea
The buzz in the telematics industry lately is centered around why it's not living up to expectations. Ford and Qualcomm recently ended their multi-million dollar telematics joint venture called Wingcast, which was one of the major players in the industry. Two years ago, projections for the telematics market in 2010 were in the $40 billion range; newer studies now put that amount closer to $20 billion. Telematics suppliers are cutting staff, and automotive manufacturers are scaling back telematics initiatives. So what's the problem?
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?
Learning From the Mistakes of Internet Banks
Retail banks are realizing that Internet banking is not living up to the hype that surrounded it a few years ago. At that time, analysts predicted that demand would follow the trends in general Internet usage and grow to hundreds of millions of users by the middle of this decade. Some brave entrepreneurs were even betting that the age of the branch-based deposit institution was over, and that upstart "Internet-only" banks would be able to capitalize on hot new technology to steal all the customers. Yet adoption rates are low, and customer interest is flagging. Why? Online banking is a good example of how bricks-and-mortar institutions can stumble when they try to solve new economy problems with old world approaches.
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.
Managing the Risk in Digital Customer Touch-Points
Are your customers getting a helping hand or the cold shoulder?
The great thing about big American businesses is that they give us many of the stories that become the fabric of our lives. Frankly, we'd rather not endure the circumstances that result in the stories, but like train wrecks and tornados, they are entirely unforgettable and we talk about them for years. I'm talking about customer service horror stories, of course.
We all have many of them. The stories get particularly interesting when they relate to monopolies or near monopolies, otherwise known as oligopolies. Why? Because any interactions we have with such firms are biased from the get-go by the distrust we have for important players in our lives over whom we have little influence and control. We feel victimized before we even pick up the phone to attempt to do business with them. From their business perspectives, this should present them with an interesting challenge: how do we make our customers trust and love us, so that they won't find ways to live without us? Unfortunately, such firms rarely seem to rise to the challenge.
A good example would be a very unpleasant run-in I had recently with my oligopolist ISP (Internet Service Provider). The setup for the story is that I moved about six months ago. I called my ISP during the move to have them disconnect DSL at my old address and transfer it to my new address-simple enough. Six months later, still no DSL; however, my credit card bill continues to be charged. I decided to give them a call, but having already called them three times previously in recent months, it's fair to say I was already not in the best of moods and pessimistic about the quality of service I would receive. Suffice it to say that they lived down to my expectations. The customer service interactions went like this:
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…
Don´t Get Burned by Bad Mapping
Have you ever tried to use a kitchen stove and ended up turning the wrong burner on by mistake? Yeah, us too. Just about everyone who cooks has run into this minor annoyance at some point in their life, if not repeatedly. So what do naughty stoves have to do with software? You may be surprised to learn that your digital products may suffer from the same fundamental problem that makes these stoves annoying and counterintuitive.
The problem with these stoves is poor or unnatural mapping. 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, "what's going to happen when I turn this knob?"
Goal-Directed Content Management
A year ago, most software industry analysts were predicting that Content Management (CM) was going to be the hot sector this year. Unfortunately, sales for most CM software providers are not meeting expectations, and even CM insiders are suggesting that the cause could be a growing disappointment with CM implementation results. 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. Forrester Research recently released a research paper on the subject: "Packaged Apps Fail The Usability Test." In it, they don't name the vendors, but they rate the usability of two popular CM systems. Both rated very poorly. Forrester's conclusion is that much better design is needed to win user adoption and higher rates of corporate satisfaction.
5 Insights for Improving Product Development Cycle Success
In my article last month, Innovate, one step at a time, I discussed how the process of innovation easily derails during difficult economic times, such as today's. 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't see where they're going, they typically just stop. This is tragic with respect to innovation, since it is innovation that propels business and society forward.
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?
Reconciling Market Segments and Personas
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.
The value of market segmentation
The marketing profession has taken much of the guesswork out of determining what motivates people to buy. One of the most powerful tools for doing so is market segmentation, which groups people by their distinct needs to determine what types of consumers will be most receptive to a particular product or marketing message. These groups form a consumer model.
Innovate, One Step at a Time
I believe most things run in cycles: the economy, the stock market, fashion, moral codes, even one's own personal status and influence (your personal "stock price," so to speak)—sometimes you're hot, sometimes you're not. The past couple of years have been particularly harsh in reinforcing a history lesson for us: when the pendulum swings very hard and far in one direction, it will most assuredly swing just as decisively in the other eventually.
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'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.
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.
The High Risk of Low-Risk Behavior
"Necessity is the mother of taking chances."
-Mark Twain
Occasionally I encounter a motorist on the highway who is driving very slowly, some 20 miles per hour slower than the flow of traffic. This driver undoubtedly believes himself to be driving in a reasonable manner, equating his slow speed with safety. Unfortunately, he fails to recognize the greater risk of a much faster car plowing into him from behind. His slow speed has made his car into a barrier rather than part of the traffic flow, and yet he cruises on, oblivious to the squealing tires and honking horns directly behind him.
Is this really a safe practice? Not on the highways in Silicon Valley.