Blog

One of the main contaminating ideas in the discipline of user-interface design is the idea of “user experience”. I mention this with some embarrassment, having been Director of User Experience in the past, run (and continue to run) workshops on User Experience, and worked as a User Experience practitioner for many years. But the elephant in the room was always that the concept never really made any sense, and was not the right way to describe what we were really after—something whose importance is not in question.

To put it simply, what matters is purpose, not experience. Who cares about experience if one’s purposes are not accomplished? Achieve the user’s purposes (which include all the desired qualities of great usability, aesthetic appeal, and inter-personal relationship qualities as criteria for satisfying those purposes), and the experience will take care of itself. The triumph of experience over purpose is principally the work of the media and marketing industries, who seized UI design from the grimy hands of the engineers who had been making unusable software for decades. But this solution was almost as bad as the ailment it was meant to cure, because it greased the rails for a takeover of the disciplines of software design and UI design by the marketing industry, aided an abetted by advertising as the chief use of the web in its early commercial years and arguably still today (as a percentage). The marketing industry’s preference (maybe forced on it by the quality of the products they have to market) for stimulating feelings over satisfying user’s genuine purposes has had and continues to have a deeply negative affect on the quality of software, especially online software. Great for marketing, but not necessarily for software product-development.

To put things back the way they should be, user experience should be properly understood as a species of communication quality, founded on Communication Theory and the advanced disciplines that describe who to analyze, assess, and how to design a communication system: General Systems Theory, Cybernetics, Information Theory, and others. Not advertising, media production, or graphics design—although they have their role to play. The foundation of communication quality is clarity about purpose, which is to be found right in the very heart of the mathematical definition of information, as it was formulated from Shannon’s work by Gregory Bateson (to paraphrase):

Information is encoded news of a difference that makes a difference to the sender relative to some purpose, with feedback loop from the recipient to the sender.

To speak and think of Information as a “thing” is part of a “metaphorical family” we normally use everyday. This family of metaphors has been named “communication as conduit” by Lakoff and Johnson, after its most central theme (see Metaphors We Live By). For example, consider these ordinary expressions:

• It’s hard to get that idea across to him.
• I gave you that idea.
• Your reasons came through to us.
• It’s difficult to put my ideas into words.
• When you have a good idea, try to capture it immediately in words.
• Try to pack more thought into fewer words.
• You can’t simply stuff ideas into a sentence any old way.
• The meaning is right there in the words.
• Don’t force your meanings into the wrong words.
• His words carry little meaning.
• The introduction has a great deal of thought content.
• Your words seem hollow.

This family of metaphors is at the heart of the “Bullet Theory of Communication.” This is the theory that words are “containers” for meaning shot back and forth between people like those vacuum-pipe canisters in drive-through banks and old department stores. Although my simile is a bit of a caricature, this is the basic idea behind many theories of language and philosophy of language at large today.

Although we use the idea of Information as a thing, an object, a container, all the time, it is sometimes important to remember that this is just a figure of speech, and that there is actually no information to be found, anywhere.

How can this be?

For example, suppose you’re trying to get my help in firing a mortar over the brow of a hill to hit some target or other. Imagine we’re in the army. I’m your spotter. You fire a shot, and I peer through my binoculars and say, “Bob, you missed! Aim two degrees to the right.”

It would seem as if a piece of Information has come into the world, wouldn’t it?

Let’s say, then, that in this example you don’t do anything in response. You don’t fire, you don’t change your aim. Do I know if I have informed you of anything? I do not. Has any informing gone on? It isn’t possible to tell.

So what? Well, the point of this illustration is to show that all that’s really going on when we talk of information are processes of informing and being informed. The idea of Information is just a reification of those processes.

When we turn the processes of informing into a “thing,” we lose something important: 1) we lose the idea that the criteria for information having been conveyed has nothing to do with noises my mouth makes, or the scratches I make on a piece of paper, but the behavioral outcome resulting from the interpretation by the recipient; 2) that the meaning of a piece of information only exists relative to my purpose in sending the message (pace Roland Barthes); and 3) that I can only be said to have informed you when you provide some feedback to show me that you have understood me correctly. I.e., you turn 2 degrees to the right on your next shot.

Even if you reply, “Right you are, John,” but you don’t do anything else, I still cannot be said to have informed you. Who knows what you think I said? You might have thought I said “That sodding hissed! Maimed too many trees you blight!” (well, you get the point.) Feedback is necessary for informing to happen.

In short, it useful to remember this definition of Information:

Information is encoded news of a difference that makes a difference to the sender relative to some purpose, with signature, address, and feedback.

In this example: Encoded (English), news (about your shot), of a difference (that it missed), to the sender (me), relative to some purpose (hitting the target), with signature (from me), address (to you, Bob), and feedback (you change your aim 2 degrees to the right on the next shot.)

This definition is founded on Shannon’s Information Theory, but includes insights from Weiner, Bateson, Watzlawick, and Emberling. It is very simple, but very fundamental to all of the work we do in the fields of information and communication.

* Roland Barthes: famous for his theory of the “death of the author.” To the literary theory buffs among you, I should say that I am not trying to contradict all that is good and valid in post-structuralist literary theory, only to point out that whatever literature is, it is something rather different what I am talking about here. If I say “Pass the salt,” and you interpret that as my asking you to perform a god-like extraction of all the salt in the ocean and give it to you, we’re into something else…

So I came across this entry in Wikipedia on the “Information Age,”:

‘Information Age’ is a name given to a period after the industrial age and before the Knowledge Economy. Information Age is a term applied to the period where movement of information became faster than physical movement, more narrowly applying to the 1980s onward. Under conventional economic theory, the Information Age also heralded the era where information was a scarce resource and its capture and distribution generated competitive advantage. Microsoft became one of the largest companies in the world based on its influence in creating the underlying mechanics to facilitate information distribution. It has been estimated that the Information Age lasted from approximately 1971 to 1991.

The superficial problems with this are as follows: an  Economy does not follow an Age, only another Age does.  And a 20-year-long Age? That is more like a Blip. How can information travel faster than physical electrons? If this entry only refers to the transportation of information, then the Information Age was heralded by the steam engine. But that sounds nit-picky.

The most interesting thing about this Wikipedia entry (a resource that I find invaluable, but not for the reasons Wikipedia would like), is that it is a perfect example of how stuck we still are in Industrial-Age thinking about Information. The metaphors come thick and fast: it is resource, that can be moved at a certain speed, it is scarce, and it can be captured and distributed. In other words, Information is Raw Material, only slightly more elusive than coal.

I propose two attributes define the transition from the Industrial to the Information Age.

1. Shifting from power, energy, force, mechanical, self-contained, and “closed system” concepts, metaphors, ways of thinking, to informational, hermeneutic, epistemological, organic, inter-connected, and “open system” concepts, metaphors, and ways of thinking about things

2. Shifting from physical “forms of instantiation” of products and services to informational, digital, virtual, software forms of instantiation

And on there hangs a tail… I guess this is too much to go into right now. But what I think we can say is that we are a very long way from #1, and that most of our attempts at #2 are quite primitive because we are such a long way from #1.

What are the disciplines to pave the way for changing our thinking from Industrial Age ways to Information Age ways? They are General Systems Theory, Cybernetics, Information and Communication Theory, and Developmental Stage Theory.

“Inadequately defined requirements” has been for decades one of the biggest reasons software development projects go way over schedule and budget, are often canceled, or fail to result in a useful product. Many studies have concluded this. Here’s one oldie but goodie. I have participated in many atrocities of this nature myself. But these criticisms miss the point, I think. Requirements Gathering itself, as a method, will always be doomed to produce bad products. In this post I outline some of the reasons why, and it is meant as an intro to a solution to the problem, which I will write about later.

Requirements Gathering is typically the first phase of a software development project, but it has its parallels in non-software design. This is the part where the systems analysts or business-process analysts figure out what potential users want from the product. The satisfaction of these wants will be end-result of a successfully implemented product.

There are three presenting problems with this approach

1. It is often nearly impossible to know who your “users” will be, except in very narrowly defined situations, such as accounting software.
2. Users often don’t know what they want, or what they need
3. What most users say they want is often not very relevant for what they will actually find useful

But perhaps the most fundamental problem has to do with the whole frame of this approach: it bypasses problem-definition and starts with solutions. But solutions to what?

Designing this way is like designing by committee. It results in an incoherent laundry list of ideas, and there is no way to tell if you’ve captured all of them. There is really no way to know what “all of them” means. What you have is a list of possible features: but the fundamental question still remains: what is the purpose of this product? What is the purpose that will meet what needs? You need to know this first, before you can even ask potential users the right questions. Requirements-gathering leads to products with no focus, no core direction. No way of prioritizing features, except by voting on them, and they are vulnerable to whims, politics, and power.

Another way of looking at it: a product is a solution to a problem. By asking users what they want, you are asking people to come up with solutions to an as-yet unstated problem. You can implement all the solutions, and end up with something that doesn’t actually solve the real problem, because no one figured out what that really was. This may seem obvious, but it happens all of the time. People will keep coming up with more solutions, and they will change their minds during the implementation, because there’s nothing underneath it to guide it to tell if their requirements were the right ones, or whether any are missing. There’s no purpose. This is, after all, a planning problem.

Without a clear purpose and a clear hierarchy of “means” that rigorously “rolls up” to the purpose, you’ll never know when you’re done, or if you really succeeded. The underlying architecture of the product will be horrible, because sound architecture—both internally and in those external interfaces of the product the form the user’s experience—is a mapping of the product’s purposes on to the product’s features for the sake of usability. Without sound purposes, bells and whistles will vie for supremacy, the features will be disorganized, important ones will be missing, incorrectly defined, or irrelevant. Software architects won’t really know what they are doing. Ask any software architect or programmer: they hate requirements documents. They can’t design from them.

I don’t know how this awful method arose. But I would guess it arose from the failure of autocratic design methodologies whose principal focus was technology, rather than users and their problems. That is, arguably, worse. But what we have now is no solution.

What’s needed is a quite different approach, requiring a quite different set of ideas and skills from those that either users or techies can provide: digital product-innovation development.

Use Cases are one of the most commonly used parts of the UML (Unified Modeling Language), for expressing the Requirements of a new piece of software. But here are their flaws, and some suggestions for improvement:

Too low a logical class: this is shown up in the term “Use Case” itself. “Cases” are instances of things. As a software engineer, you don’t want instances of uses, you want the uses themselves. You may have to start with the cases, to get an understanding of the Use they are cases of, but the Business Analyst should end up with Uses, and not cases of Uses.

Conflates Dynamic, Static, and U.I. models (or, in other words, conflates means and ends): Use-Cases were partly intended to be a solution to the common problem of requirements-documents containing too much premature implementation detail mixed in with the description of what the user is meant to be able to do. But they have not gone far enough. Use-Cases mix in information about the U.I. (e.g., information about picking from lists, viewing error messages, confirming actions, etc.), and they don’t differentiate dynamic (about how the software will execute tasks) from static elements (how it will be organized, OO-style, into classes, properties, methods, and events) of the specification. This leads to kind of “impedance mismatch” when the software engineer tries to translate them into software architecture and programming specifications. Plus, the mixing-in of U.I. leads to a lessening of clarity of the core program logic, and a premature design of the user-interface, as well as, perhaps more often and more serious, the overlooking of much of the U.I., which in web applications can be a considerable percentage of the total code. Leading on from that, it encourages the team to think of the Information Architecture and Visual Design as “hanging out loose”, and leads to problems of integration, of how to easily put the whole thing together.

Obscures the holonarchy of vision, objectives, and goals for the software: the Use-Case model is not well integrated with the overall goals of the application. Yet the Use-Cases are meant to be an expression of what Users do to accomplish those goals. They are the means, whereas the goals and objectives are the ends. What this comes down to is a fundamental misunderstanding about what the Requirements phase of the software development process is. What it is typically thought to be is a “gathering” exercise, a compiling exercise, an exercise of interviewing people and finding out what they want. But it isn’t that. It is a PLANNING exercise. Requirements are really the Activity Plan level of the application, by analogy with a traditional plan. And as such, it is part of the Planning Discipline, which has its own sets of criteria for quality that are well-established, and far more sophisticated than anything you’ll find in the Requirements literature of software development.

If the Requirements phase is not understood as planning, and executed as such, many, many things go wrong: the requirements won’t add up to the goals of the application; the goals of the application will be poorly defined and misunderstood, but people won’t know it, or won’t know to know it; it will be much harder to estimate, plan, and divide up the work than it otherwise would be, resulting in project management problems; the software architecture will be worse, because, just as in an organizational structure of a company, such a structure is a mapping of the purposes of the organization onto its resources, its people. In the case of software architecture, the purposes are the Uses, and the resources are the Classes that accomplish those Uses. The architecture is the mapping of those Uses onto those Classes, using sound criteria for effective classification, organization, and nomenclature.

Too declarative: Use-Cases are intended to be declarative only. But the activity level of any plan is by its nature something closer to a flowchart: it has decisions and branches. In moving away from complex flowcharting of traditional specifications, and via a misapplication of the metaphor of Objects to Actions, Use-Cases make it hard to express the essential conditional dynamic of User Actions.

Unnecessarily Object-Oriented: The purpose of OO is to close the gap between the problem domain and the solution domain, by making the solution domain conceptually closer to the problem domain. The Uses of an application are in the problem domain, and therefore do need any gap-closing done to them. That is, if we use the appropriate conceptual framework, that of Planning. Actions roll up to goals, which roll up to objectives… individual actors work for teams that roll up to supervisors, that roll up to managers, that roll up to the organization as a whole. This is inherently object-oriented already.

To apply the methods of OO to Uses is a weird kind of mind-flip, where we take something that can be inherently expressed in the problem domain, and first suck all of that information out of it by construing Uses as objects, and then, we turn around and wonder how we’re going to put all that information back, and so we try to back-engineer it using OO forms of representation that we use in the solution domain (a domain of program classes, methods, properties, and events). This just makes the requirements unnecessarily complicated and hard to understand. It is a mindless application of the OO metaphor, losing sight of what we’re trying to accomplish.

Gives software-engineers too much of the wrong kind of work to do: Another reason for Use-Cases is to make it easier for the software-engineer to derive classes from the Requirements. The reasoning goes that if the requirements are in OO format, then it’ll be much easier to derive classes from Use objects. But this is not really the case: the domain of Uses is completely orthogonal to the domain of Classes. Uses are part of the dynamic aspect of the system. Classes are part of the static aspect of the system. For example, consider the Use-Case “Activates Credit Card.” The software-engineer is going to see that here we have a Method (”Activate”) of the a Class (”Credit Card”). In normal Use-Case representation, every time there is a case of activating a credit card, you will see a reference to “<includes> Activates Credit Card.” This kind of representation misses the point: the point is to give engineers what they need to write good software, and to do that, the Business Analyst must provide both a dynamic and a static model, because it is too hard to express both in one model. The dynamic model is isomorphic with the domain of human of purposes. The static model is isomorphic with the static OO domain of the implementation. So what this means is that instead of a lot of misguided OO information wasted in the Use-Case model, the BA should provide a static model, a logical representation, of high-level Classes, their methods, properties, and events, and that are needed to accomplish the Uses. The BA then x-references those for the software engineer.

Now the engineer is in the position he wants to be, which is to be able simply understand the requirements and now how they will translate into software. He will be able to see, at a glance, that the task “Activates Credit Card” is invoking the Activate Method of the class Credit Card. This will lead to a much more satisfactory breakdown of labor between BA and engineer, and much clearer, more accurate, more implementable requirements.

It will also, very importantly, provide an easy framework for the specification of the U.I. The U.I. is a mapping between the Uses and this static model. The fields in the U.I. are mapped to classes in the static model. Controller logic can easily be expressed verbally, in terms of transformations and conditions that obtain between receiving Input and writing Output. The resulting Requirements therefore would consist of three models: a Use Model (dynamic), a Class Model (static), and a UI Model (mapping between the two for the sake of user-system collaboration.) This is very close to the MVC framework that the application will actually be implemented in, thus making translation much easier.

Inconvenient to Document & Update: My final criticism of Use Cases is a purely practical one, that, even with CASE tools and their ilk, they are unnecessarily complicated to draw, and unnecessarily cumbersome to update. If they were simply expressed as a textual outline goals and actions, and x-referenced to actors and the appropriate class in the static model, life would be a lot simpler.

Looking back on nearly a hundred software projects, here’s my diagnosis of the top sources of problems that cause problems with quality, efficiency, and stakeholder satisfaction:

1. Perspective: wrong perspective on the true role of websites, online products, & communication functions for companies. A limited IT or Marketing perspective, instead of the right understanding of the Internet’s potential, married to a clear business-focus. These projects, after all, should only be done for the sake of worthwhile ROI for the company.
2. Research: not investigating the business reasons & goals for the project, to ensure that the project produces them. Not doing the right kind of research into the right questions, & making sound, well-informed decisions at each step of the project, including whether or not to proceed.
3. Planning: little or no planning at all. Relying on trial & error. Thinking that planning is either not possible or counterproductive (e.g., inhibits creativity). Poorly-chosen or ill-defined project-objectives. Relying on the design work to reveal the purposes of the project. Leaving “strategic” planning to design agencies or company personnel without the skills to do it right. Working from a plan that just isn’t detailed enough to do an adequate job guiding people’s work at each step in the project. Beginning design work, such as UI or visual design, without adequate specifications, or beginning coding without adequate designs.
4. Budgeting: setting budgets before planning, setting objectives, & making sound decisions. Then being stuck with an unrealistic budget for a project that isn’t fully understood.
5. Methodologies: critical steps done in the wrong order. Steps omitted. Conflating user-interface design with visual design.
6. Product development: inability to come up with innovative product-concepts without relying on geniuses or sheer luck, since no research into business objectives or user aims was done to provide the right foundation for innovation. Product development geared toward the wrong user aims, usually identified from demographic market-research. Product development done backwards: concepts/technologies in search of ways to profit from them. Merely copying the competition, as a common way of trying to cope with these challenges, which is no way to capture the dominant market-position.
7. Non-modular services: companies have to buy the whole service or nothing. Thinking they have to get one firm to outsource the whole project to—a myth propagated by design and development firms, which is really the result of poor or unclear methodologies that do not allow for modularization. Leads to the using the wrong people for parts of the project. No pausing for decision points & reevaluating whether to proceed, how, and with whom.
8. People: lacking the requisite perspectives & skills for their part of the project. The people doing this kind of work usually come from IT, marketing, or graphics design backgrounds. They rarely understand how companies really work and what online- solutions to their problems must entail. They rarely have the skills to do effective planning and project-management. They are only really set up to execute assignments given to them—not to research, innovate, make decisions, consider business needs, or define objectives. These critical first steps are therefore left to their client or business analysts, who may not know enough about the latest technology and its potential applications (such as how to virtualize various business functions) to do an adequate job of these things either.
9. Project-management: unskillful, haphazard, and sloppy. Ineffective communication and collaboration among members of the outsourced project-team and between that team and client staff.

The following is a cognitive map to help in the definition of product or service’s Benefits. There is hardly any more important component of the marketing and sales information. There is hardly anything more important in the planning and design of a new product or service. The way Benefits are normally identified is somewhat ad hoc, and it is hard to know if you’ve really nailed it without a lot of trial and error, and even then it can be hard to know. I will present a new (simple) theory and method that I think helps enormously with this process.

Any benefit of a product or service can be thought of as a causal chain, beginning way down into the lowest levels of detail of what the service or product does (its features and how they work), and going way up all the way to, ultimately, human happiness. When you are defining Benefits for a particular audience to understand what they’ll get out of your product or service, you are in effect asking the question: What portion of this chain should be expressed?

That portion of the chain that should be expressed (from X to Y in the diagram above) in the Benefits should be defined as follows: Y is defined as the left-most end that the audience will regard as clearly desirable (they won’t say, “So what?”). X is defined as the right-most means that the client will regard as something the product or service is likely to be able to accomplish, and can see will plausibly lead to Y (maybe by including X`,X“,…) (In other words, the audience won’t be left thinking, “But how?”) This would be expressed as “Y, by doing X.” In some cases, X can equal Y.

For example, I have been developing a service recently whose Y is “Improves the sales-conversion rate of online retailers by 15% to 25%”. If I go any further left we’ll start at get into the technical details of how I accomplish this, and risk the client saying “So What?” If the client is savvy in this technical area, this might be fine, but it is best not to assume so. Let’s say he or she is the eCommerce manager for the website. Increasing sales is the thing they really care about. But I can’t leave it at that, or they’ll be left wondering, “But how?” I have to express this Benefit in a way that doesn’t leave the client suspicious or incredulous of the claim. This is the function of X. Now, in my service I reframe online sales as “customer decision-making”, and part of my method is to create a decision-analysis model for the product or service category. Will this do as an X? “Increase sales by 15% to 25% by designing a decision-analysis model for the purchasing of Televisions.” The answer is no, this is too far left. There are still means to the right of this that the client will regard as something that the service is likely to accomplish, and will be less of a stretch for them understand how they generate the Benefit. For example, “Helping indecisive and uninformed visitors, who might otherwise give up or buy the wrong thing, get clear about what they want, and guide them through an evaluation of the best solutions the site has to offer to meet their need.” This is better; the client is likely to find this a plausible explanation for the increase in sales. The full expression of the Benefit therefore might be, “Increase sales by 15% to 25% by helping indecisive and uninformed visitors, who otherwise might not buy anything, get clear about what they need and find the best match on the site.” It’s still a bit wordy, but you get the point…

This map also provides a method for evaluating the quality of any Benefits statement. Try it on marketing and sales material you come across and see how well it works. It can also be used to evaluate the fundamental marketability of a new product or service, because if you cannot find a way to meet the criteria for X and Y defined above, maybe your new product or service is unmarketable. And the longer the portion of the chain you have to use, the harder it will be to market. A product that “sells itself” is a product whose features are enough to communicate its benefits.

Feedback is a key (perhaps the key) notion of a branch of mathematics called cybernetics. Norbert Wiener invented cybernetics and introduced it to the world in 1948. He coined the term from the Greek word meaning “steersman.” Wiener defined “cybernetics” as the science of communication and control in the animal and the machine. The field has been broadly developed and applied to such diverse areas as engineering (control systems), communication, information theory, general systems theory, cryptography, epistemology, and management, among others. It offers insight and utility in understanding and improving the performance of all systems. It is often very misunderstood. Isn’t it just the comments you get back from people?

Here are the conditions that define feedback. First, someone who can use the information as feedback must have a goal. Without a goal, there’s no way to figure out whether this person’s subsequent behavior treats the information as feedback or not.

Second, the information received by this person must allow him/her to relate the effect of his/her actions to the goal. Otherwise, the information is useless as feedback.

Third, the person receiving the information must choose to construe this information as feedback—to interpret it as a report of how well the action succeeds in approaching the goal. If the person doesn’t want to construe the information as feedback, it remains merely information. Finally, this interpretation must influence the person’s subsequent actions in attempting to reach the goal. Unless the construed information helps the person move toward achieving the goal, the information is not being used as feedback at all.

Herein lies the common misunderstanding of “positive” and “negative” feedback. Negative feedback isn’t necessary bad; it just means information that is construed in such a way that it results in a change in direction in the pursuit of some goal. Inversely, positive feedback isn’t necessarily good; it just means information that is construed in such a way that it results in a continuance of the same course. In nature, positive feedback loops are often responsible for a state called “runaway,” unchecked behavior that can cause a disaster. In general, negative feedback leads to stabilization or homeostasis, while positive feedback can (but needn’t always) lead to runaway.

In sum, the four conditions are these: (1) a goal, (2) a way of relating the effect of actions to the goal, (3) choosing to construe the information as feedback, and (4) influential on behavior.

So what is customer feedback?

Customer feedback is one of the key ways a business learns how well it is satisfying its customers, and how to alter course to do this better. Satisfying the inadequately satisfied desires of your customers in exchange for money is what a business is all about. Without it, a business is flying blind. Of course, there are implicit measures of customer satisfaction: volume of sales, size of customer base, market share, profits, etc. But these kinds of end-result variables are almost useless at helping you pin-point what’s wrong with your products and services, or what’s wrong with how they are being marketed or sold, or even which departments in the chain from Marketing to Sales to Production or Service Delivery are causing the problem. Nowhere is this truer than in a web business. You stay up nights, searching in vain for some pattern in the logs that will give you a clue as to why visitors are not staying or buying. If only you could ask them…

And therein lies the art of eliciting customer feedback. How do you know you’re asking the right question? How do you know that what you get back from your customers can be reliably used as feedback, in the sense explained above? The statistical questions concerning unbiased sampling, sample size, significance, and so forth, can be handled by a competent statistician. You can hire those people or get up on the field relatively easily. What is much harder to come by is a usable and compact criteria for the quality of a feedback loop. That’s what you need to set up an effective customer feedback function. Reproduced below is one of the very best, derived directly from Information Theory and Cybernetics. It was developed by Dennis Emberling. Use it to assess your current feedback loops, and as a guide to improving them.

Quality Criteria for Feedback Loops

1.         Recipient

            a.         Right recipients: gets to the people who need it.

            b.         Willing recipients: recipients have to want to construe the information as feedback. They won’t if they feel offended by the information. Therefore, the information must be inoffensive.

2.         Quality of Information

            a.         Stance: appropriate assumptions, point of view, attitudes. Includes using first-person (“I”) for self-expression and second-person (“you”) for understanding others. Also active voice (not passive).

            b.         Sufficiency: enough information for recipients to be able to figure out whether and how to modify their efforts.

            c.         Relevance: all information recipients need to work toward their goal.

            d.         Organization: information presented in the right order and making clear the relationships among pieces of information. It must be easy for recipients to use as feedback, without their having to do a lot of work. This often means it must be expressed, presented, displayed, or encoded in a form that obviously relates the recipients’ actions to their goal.

            e.         Coherence: the pieces of information are well integrated—they “hang together,” are accurate, reasonable, logical, consistent, do not contradict each other or other information known to be accurate, and in a single, appropriate time period (past, present, or future).

            f.         Logical Class: not uselessly vague, abstract, or general, or so specific as to prevent seeing the forest for the trees. Avoiding logical class errors.

            g.         Language: uses appropriate terminology, metaphors, analogies, etc. that are unlikely to distort the information, mislead the recipient, or be difficult to understand.

            h.         Degree: makes explicit the correct degrees of probability, confidence, emotion, importance, determination, etc. as appropriate for the information. Avoids absolute, rigid, doctrinaire pronouncements.

3.         Delivery

            a.         Timely: the value of the information diminishes with elapsed time, because the recipients have moved farther down what may be the wrong road. The sooner they receive the information, the sooner they can correct their course. Untimely feedback loops are called “sloppy.” Fixing them is called “tightening” the feedback loop.

            b.         Fail-safe: a common problem is to permit feedback loops to rely solely on someone’s memory. When they forget (as often happens), the loop is broken. It is better to set up some precautions, reminders, or automation to ensure that feedback occurs.

Some simple distinctions to show how truly mixed-up we are about Marketing, especially on the web. Marketing seems to have nearly obliterated the distinction between itself and Sales—as though if you hung a cash register on a billboard, you could call that a store.

The consequence is that most websites reduce the sales function to the cash-register function (checkout), and fail to offer the visitor much in the way of sales help at all. The consequence of that is that only visitors who know what they already want to buy, or are close to knowing, have a satisfactory shopping experience. The rest have a lot of work to do, get frustrated, hesitate, give up, or buy the wrong thing, especially in “complex” product areas, such as consumer electronics.

• Marketing is usually of many products (or even the whole company, whole product line, etc.). Sales is usually of a single item (the one being sold).
• Marketing is to many customers at once. Sales is to one customer at a time (whether an individual, team, or company) .
• Marketing is therefore usually many-to-many. Sales is usually one-to-one.
• Marketing is essentially broadcasting. Sales is essentially transactional.
• Marketing is self-expression, broadcasting, one-way. Sales is communication, dialog, two-way.
• Marketing is an offer of unsolicited help to meet some need. Sales is solicited help—responding to a request for help to meet some need.

One thing this scheme clears up is the question: what is “transactional advertising“? Why, it is sales. and not really advertising at all.

A fair question for potential employers to ask any digital product expert would be, “What are the advantages to us of your particular methodologies, models, approaches, skills, tools, and modular services? That’s what we really care about.” This short article answers that question in terms of clients’ contracts with providers of design and development services, and the actual design and development projects themselves.