Sign up to get our featured articles delivered straight to your inbox every month or two.
RSS feed of all articles
Follow us on Twitter
Architecture (3)
Automotive (2)
Books (13)
Branding (3)
Business (28)
Communicating design (10)
Cooper (13)
Critiques (20)
Design & engineering (20)
Design disciplines (1)
Design in organizations (23)
Design principles (16)
Events (13)
Experience Design (11)
Features (82)
Financial (1)
Industrial design (7)
Information design (7)
Innovation (24)
Interaction design (41)
Interaction Patterns (5)
Medical (4)
Methods (5)
Mobile (10)
Personas (13)
Platforms & technology (2)
Presentations (4)
Product definition (6)
Prototyping (1)
Requirements (4)
Research (17)
Service design (8)
Strategy (9)
Sustainability (10)
Techniques (32)
Travel (3)
Trends (12)
TV (5)
Typography (4)
Visual design (19)
Web (14)
Features
The Drawing Board: Commuter Buddy
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.
In this edition, we thought a bit about public transit. It's great for the environment and pocketbook, but it isn’t without its own headaches. Managing departure delays and worrying about getting off at the right stop make commuting less carefree than it could be. So how can we make the experience better? Meet Commuter Buddy, a concept application that lets commuters sit back and enjoy the ride. So…enjoy.
The Drawing Board: Commuter Buddy on Vimeo.
What do you think? Join the conversation in Comments
Economizer: A Cooper service concept
People are looking for ways to economize in these uncertain times. We can all see the evidence of environmental crisis brewing alongside the economic downturn, and it's easy to feel powerless in the face of such global forces. With politicians and businesses seeking avenues to a sustainable future, Cooper wondered how design might help individuals cut costs while also encouraging behavior that was environmentally responsible.
This all started when Environmental Defense approached Cooper, asking us to imagine new ways to make it easier for people to save resources. We performed research throughout the Bay Area, then collaborated with Environmental Defense to model our findings and identify design opportunities. From this point of inspiration, we continued on our own, crafting a quick eco-friendly concept: Economizer, a service that helps consumers save money while making sustainable choices. The service consists of a core set of internet-aware services with optional components such as hardware data collectors, social networking applications, and dedicated smart phone interfaces.
Economizer: Scenario 1 on Vimeo
(Watch this video in fullscreen mode by clicking the icon in the lower right of the player.)
A unified approach to visual and interaction design
During my seven years as a visual designer at Cooper, I’ve learned that designing for complex digital products and services requires input from a number of unique perspectives to be truly effective. Furthermore, each of those perspectives must be effectively integrated throughout the lifecycle of the design process to achieve results that are consistently and predictably usable, useful and desirable.
In the course of managing, consulting and teaching, I have not only had the opportunity to define and discuss design process with my colleagues here at Cooper, but with countless practicing designers from organizations all over the world as well. Unfortunately, my observation has been that even when all of the right people are involved, more often than not, the various design disciplines opt to compartmentalize the problem. In other words, they divide the project into an interaction design problem, a visual design problem, and an industrial design problem. Each of these problems is then tackled separately, and the resulting individual design solutions get bolted together at the end. It’s a Tower of Babel situation, where huge opportunities are lost because the team fails to work together to come up with an innovative product solution and to employ a single, unified design language.
A fractured process makes for a fractured user experience
In practice, people view their experience with a product in a unified way. For example, when a user interacts with a cell phone, she doesn’t experience the phone’s behavior separately from the visual and tactile presentation of that behavior on screen and through the physical form factor. Why, then, don’t product teams consider these aspects of the experience in a unified way when designing solutions?
Of course, we know that many digital products and services represent extraordinarily complex, large-scale design challenges. A significant degree of rigor and a rational approach to methodology is required to bring together the diverse perspectives of the different design disciplines in a way that results in optimal creative abrasion, rather than destructive friction that threatens to bring the entire process to a grinding halt(1).To this end, let me share with you a few of the insights that we’ve gleaned from practicing a truly convergent approach to design.
(I should note that in an attempt to keep the length under control, I've focused this article on the convergence of interaction and visual design for products with defined hardware, like PC's or handsets. We're looking forward to sharing our experiences with integrating these two disciplines with industrial design in a future article.)
The Drawing Board: Our Building's Elevator
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.
The Drawing Board: Our Building's Elevator on Vimeo.
What do you think? Join the conversation in Comments
A command I could really use
Ctl+Z works when you've done something inadvertently bad, but what about those rare occasions when you do something inadvertently good?
What do you think? Join the conversation in Comments
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
What do you think? Join the conversation in Comments
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
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.
Content Management Systems: Don´t automate the Misery
Organizations of every size are attempting to get a handle on their content generation, management, and publishing systems. This trend toward business process re-engineering (BPR) of content management is largely the result of an outsized proliferation of Web pages, intranet sites, and electronic communications strategies adopted by organizations, their partners, and customers.
Sadly, few organizations have seen much good come of content-management BPR initiatives so far. Of the many reasons for these failures, one stands out: these BPR initiatives—and the systems they spawn—are focused on realizing organizational objectives without sufficient regard for the context, habits, and goals of the people who will actually use the system. These new technology solutions are intended to create efficiencies, but they actually prevent people from achieving their objectives, which generally have to do with reducing hassle and ensuring their own personal effectiveness.
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.
Always Have a Backup Plan
I've been thinking about how things can go wrong lately.
At Cooper, we have a design principle that suggests that designers should "hide the ejector seat levers," meaning: make sure users can't inadvertently cause their software to fail. By the same token, we also encourage designers to "make errors impossible" by designing software that anticipates the actions of its users.
Nevertheless, things will go wrong. By anticipating failures, and designing backup plans like those described below, you can minimize the impact of unexpected problems on the user.
Navigating isn't fun
The artless Websites created during the Web's infancy were of necessity built only with simple HTML tags, and were forced to divide up their functionality and content into a maze (a web?) of separate pages. This made a navigation scheme an unavoidable component of any Website design, and of course, a clear, visually arresting navigation scheme was better than an obscure or hidden one. But many Web designers have incorrectly deduced from this that users want navigation schemes. Actually, they'd be happy if there were no navigation at all.
Making Use of User Research
Designing or redesigning a product often feels like a risky proposition, especially in today's business climate. Those responsible for defining the product offering and marketing want reliable, measurable data to define success both incrementally and overall.
Hard data helps us make choices about where to spend resources, but placing a product under the microscope every step of the way can also introduce as many opportunities for error as it avoids. By focusing on how a product performs in the lab without broader knowledge of the user's environment and goals, measurement alone may be misleading. To get the most value and meaning out of user feedback it is important to choose the appropriate method for conducting and analyzing user research.
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.
Perfecting Your Personas
A persona is a user archetype you can use to help guide decisions about product features, navigation, interactions, and even visual design. By designing for the archetype—whose goals and behavior patterns are well understood—you can satisfy the broader group of people represented by that archetype. In most cases, personas are synthesized from a series of ethnographic interviews with real people, then captured in 1-2 page descriptions that include behavior patterns, goals, skills, attitudes, and environment, with a few fictional personal details to bring the persona to life. For each product, or sometimes for each set of tools within a product, there is a small set of personas, one of whom is the primary focus for the design.
What We Can Learn From the Fender Stratocaster
I must admit I'm not terribly impressed by the quality of today's software—my benchmark for good product design isn't defined by the output of Microsoft, Apple, Adobe, or other respected software companies. Those companies produce some good work, of course, but the software industry, though no longer in its infancy, still seems to be working through its gawky adolescent stage. So, when I think about high quality products, I think of BMW automobiles, Eames furniture, and the Fender Stratocaster guitar.
So You Want To Be An Interaction Designer
We get a lot of email from students and usability professionals asking how one goes about becoming an interaction designer, and what background one needs to get into the field. What are good interaction design programs? What real-world skills and experience are required? What, exactly, do interaction designers do on a day-to-day basis?
Beating the Checkout Blues
Your online store is a good example of the breed. You've got good products at good prices, the site navigation is straightforward, the product information is rich, appropriate, and easy to find, and everyone likes the clean, uncluttered visual design of the site. So why do more than half of your customers abandon their full shopping carts?
Depending on which research report you read, roughly 25% to 75% of online shoppers abandon their shopping carts before consummating the deal. Despite the disparity in numbers, all the research firms agree on one thing: that's way too many.
Innovating for Humans
Innovation is an obsession and a watchword throughout the software industry, and it's been widely adopted as a core business goal. But from the consumer's perspective, innovation is only valuable if it solves a problem or provides a new benefit. It can be a bitter pill to swallow, but any product that innovates without adding human value will eventually be displaced by one that gives power and pleasure to those who use it.
Before starting to innovate, it is important to reflect on how different flavors of innovation are perceived by the people who will eventually use a product and what risks and opportunities are associated with each. Then comes the hard part: figuring out what the right innovations are and how to implement them.
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!
The Second-Order Effects of Wireless
Even though "wireless" is the hot buzzword on the lips of every high-technologist, the effects of the technology hold far more interest than does the technology itself.
Wireless freedom is intriguing: It isn't hard to imagine a world of perpetually perambulating people with cell phones clamped to their ears and styli firmly gripped in their fingers doing at the cinema or the next table over at Il Fornaio what they could formerly do only at their desks.
But this flexibility to work where you want is just the first order of change wrought by these new tools. Far more interesting are the second-order effects - those unintended consequences of a new technology which often have a more powerful impact on society than the more obvious first-order changes.
Time Travel Design
In this month's newsletter, Tony refers to a Washington Post story titled The End-User View of Techo-Nirvana: Blink, Blink, Blink. The Washington Post writer had this to say about Video Cassette Recorders:
That flashing "12:00" has become a symbol of technology as tyranny, taunt, impotence, ignorance, intimidation, humiliation, stone in the shoe and pain in the butt. It stands for innovation created without humans in mind. Yet humans have grown to live with it. To expect it. To adjust themselves to the selfishness of these machines. Like sheep.
The Iteration Trap
High-tech companies are in a hurry—as well they should be—but many hurt themselves by trying to move products out the door too quickly. I often hear executives repeat homilies like "Ship early, ship often," and "Launch and learn." They assume that there is no penalty for simply slapping something together, shipping it, and then upgrading their product or site in a rapid iteration cycle. Unfortunately, there is a big, hidden cost associated with this tactic.
Rapid development environments like the World Wide Web have promoted the idea of simply iterating many versions of a product or service until something works. Arguably, the Web is in its nascent stage and companies are still experimenting to see what works and what doesn't, yet this should not be an excuse for iteration without planning, nor should "speed to market."
The Perils of Prototyping
Which is harder to change: a program with 1000 lines of code or a 1000 square foot slab of concrete? The concrete is ten inches thick and has steel reinforcing rods criss-crossing within it. Every cubic foot of it weighs almost 100 pounds. The software has almost no physical existence at all. It weighs nothing. It consumes no space. A few microamps and those bits flip from zero to one without a second glance. The answer to my question seems a simple one, doesn't it?
Which is the best medium for designing software: Visual Basic or a sharp pencil and a couple of sheets of paper? Visual Basic is a powerful, flexible integrated development environment. It is on its way to becoming the most widely used language ever. It has won every industry award there is. Paper is not interactive. Paper offers no palette of pre-made controls. It just lays there and you have to do all of the work. The answer to my question seems a simple one, doesn't it?