jim.shamlin.com

6 - Design Thinking

In consulting, the author makes a "rule" of never solving the problem the client presents, because the client's attitude tends to be one of "make the user accommodate my product" rather than coaching the client to make a product that is usable. Controlling the user is a hack, which almost never works and often makes this worse rather than better.

In many instances, the client hasn't done sufficient diagnosis to know what the real problem is - they find something convenient, familiar, and relatively easy to address but miss the actual cause, and so the proposed solution is doomed from the onset. It takes quite some effort, and an entirely different perspective, to find an appropriate solution.

Solving the Correct Problem

People enjoy solving problems, and are trained to do so - but they are also trained to regard the world in a specific way: an engineer thinks like an engineer and sees engineering problems; a businessman thinks like a businessman and sees business problems etc. The difficulty is that they will define a problem that matches their perspective, and can distort reality to do so.

Rather than seeking a problem to be solved right away, take a step back to explore the issues. What is really happening? Why is it a problem? What might be causing it? Might there be a chain of causation?

Naturally, this drives managers crazy. They want a quick solution and have the sense that exploring the issues thoroughly is wasting time that should be spend "doing" things to make the problem go away - not realizing that the problem will not be effectively solved until the actual cause is discovered.

If the designer's task is to develop a product that meets the needs of the user, he must take a broader vision and spend the time to work out exactly what is the real cause of the problem - because the user's needs will not be met by token efforts that address symptoms rather than the root cause. And ultimately, a product will not be commercially successful if it is perfectly engineered or economical to build, but because it serves the needs of the user.

The author uses the term "design thinking" for the kind of problem-solving that makes the user its primary goal. Design thinking is not exclusive to designers. The author avers that "all great innovators" practice this kind of thinking when they consider what use will be made of their product.

Or more to the point, all the great failures of industry have resulted from the good intentions of someone who forgot to think of the person who will consume the product. They defined technically wondrous contraptions that could be manufactured efficiently - but were of use to no-one.

He strays a bit into secondary matters: the principle of Human-Centered Design (HCD) relates to beginning the engineering task by thinking about the capabilities and capacities of the user, rather than those of the materials of the device.

The alternate approach, building based on materials, ends up in a process that is both inefficient and ineffective, as the original design of the device is unusable and must be tweaked and compromised to accommodate the user. Beginning with the user in mind means that the original design is usable.

The Double Diamond Model of Design

The author mentions the "double diamond model" of design, as described by the British Design Council. Essentially, the double diamond model has two phases: finding the right problem to solve, then finding the right solution to address it.

It begins with a specific idea, broadens as research is done to identify the surrounding issues, converges on a problem definition, broadens as various solutions are considered, and finally converges again on the final solution to be implemented.

This model, which allows for the scope of effort to be broadened twice, has been effective in helping to reassure project managers, whose expectation is more of a "single triangle" model which begins with a broad problem and arrives at a specific solution by a linear progression, in which focus becomes narrower and never broadens again.

The model also brings to mind that there are two stages in problem solving, the first of which involves identifying the real problem before jumping to conclusions about what the solution might be.

The Human-Centered Design Process

A separate process of human-centered design has four basic stages: observation, ideation, prototyping, and testing. This is not a linear model, but a cyclical one - as the cycle repeats until testing proves the design to be successful.

OBSERVATION

The initial stage is one of research, which may be formal or informal. The design researcher may be observing people casually and notice that they are struggling to do a task - or he may arrange to observe people in the field or a laboratory environment as they perform a task to determine if they have any difficulties. Where anyone appears to be struggling, the designer becomes aware that some kind of problem exists.

Ethnography, or observing people in their natural environment, doing the things they naturally do, has rich potential for innovation. The author elaborates that you have to go into the field and watch people in their homes and offices, paying attention to the things that they do, to recognize these opportunities.

(EN: I don't think the author distinguishes quite enough between different kinds of observation, but likely he's not the best authority on the subject of research: look to experts in the field of sociology and psychology for more reliable advice on how to design research - and more significantly, on how the different approaches to observational studies can skew the results.)

It's suggested that ethnography should also note the details about the audience, to avoid generalizations. If you have a target market in mind, observe people who match their demographics (age, income, education, gender, etc.) - or if you are doing open observation, make note of the qualities of the individuals, because some groups have different behaviors and abilities than others.

Consider this: much of the behavior of "smart phone users" is based on observations of teenage girls in urban centers of Japan, who are the most avid users of the technology. Grave mistakes can and have been made assuming that middle-aged American businessmen will follow the same behavior patterns. It is even a mistake to believe that American teenage girls will act the same way as their Japanese counterparts. Simply stated, there is no substitute for the kind of people who will actually use the product.

DESIGN RESEARCH VERSUS MARKET RESEARCH

A distinction must be drawn between the kind of research done by design and marketing - while the two complement and can inform one another, there are distinctly different focuses.

Cross-pollination can be a bad thing. People do not necessarily want to do something simply because they are able to do it (they may not have a need, or may have an existing way to solve it); and people will not become able to do something simply because they want to do it (a person may wish to life a ton of bricks, but is not physically able to do it). Both must succeed for a product to be a success.

(EN: Marketing also distinguishes between the purchasing process and the usage process, tending to focus overmuch on the former and too little on the latter - that is, they assume people will buy something because it is cheap and convenient, not whether the item serves any purpose once they have purchased it. The notion of developing a product that serves a purpose is often relegated to some other department, or not considered at all.)

The author mentions the digital channels - the way in which web sites make it possible to observe the behavior of people online. This tends to be focused exclusively on the task of shopping and purchasing, and yields no insight as to whether the product is actually valued - though this can be inferred from repeat purchases (or lack thereof). He also briefly mentions testing online - the ability to place two different versions of a web page online to see which performs best.

In a similar mode, "big data" is the recent fad in aggregating data from various information systems to form a picture of the user's buying behavior. It's good observation, but limited in its scope, generally to transactions directly between the user and the firm.

He mentions the contentiousness between design and marketing personnel, and suggests that the debate is not useful or productive. It's not one or the other that is important, but ultimately both - the customer must find using the product satisfactory, and they must consider the buying process satisfactory. One without the other is no good.

IDEATION

Observation gathers information about things such as they are, and this feeds another step in the process: coming up with ideas about the way things could be. This involves a great deal of speculation, because it must be imagined rather than observed.

This is the creative part of design, in which people must envision ways that the problem might be solved. And while creativity is poorly understood as a process, there are a few basic rules:

  1. Begin by generating numerous ideas before criticizing. Fixating on a single idea too early in the process causes tunnel-vision, in which possibilities are ignored.
  2. Be creative without constraints. Assessing whether something is possible or effective or can be accomplished can be done later - and ideas should not be limited by these assumptions.
  3. Ask stupid questions. There are many things that people take for granted that, when they pause to consider and explain, are not true or not important. If they are never questioned, it will always be assumed they are true - so question everything, especially that which is believed to be obvious.

PROTOTYPING

The only way to know whether an idea is reasonable is to test it - a prototype can be built to suggest its design and function. The author mentions various ways in which prototypes are built with varying levels of fidelity to the proposed product, and the puppet-show method of faking functionality.

(EN: The author's description is too vague and abstract to be of use, so I'm dropping notes - though there is some significance in considering prototyping to be a step unto itself rather than a necessary part of testing: often flaws in an idea become evident during the construction of a prototype.)

TESTING

Testing involves gathering a group of people and asking them to perform a task using a prototype. The people should be as similar as possible to the target market for the device; the task should be realistic in its parameters; and even the environment in which the task is performed should be a close match from a real-world situation.

Ideally, the individuals testing the device will be left alone to figure it out rather than coached along - as coaching is not a realistic scenario, and instead tests their ability to follow directions that they would not normally have received in a real situation. Observing whether they succeed or fail, and the difficulties they encounter in using the device, provides a clear indication of the problem.

In some instances, the individual can be asked to talk aloud about what he is doing so that his mental processes can be observed. (EN: This, too, is unnatural and people tend to behave differently when they believe they will be called upon to justify their actions.)

The author advocates the research team observing the tests - either from behind a one-way mirror or watching video of the test so as not to interrupt or distract. There is no better way to convince someone that their design is flawed than to see someone struggle to use it.

Testing is usually done with small groups of people. The author has no opinion to offer, but merely echoes Jacob Nielson, who insists that five is usually enough to find the major problems. Keeping groups small makes testing cheap and fast, and you can do multiple iterations rather than just one test.

ITERATION

The notion that design is a task that can be done once and done perfectly is horribly misguided. It is an iterative process, in which ideas are tested by a trial-and-error process - it is more in the nature of discovery of the unknown than in implementation of the known. The notion of iterative development is to fail frequently and learn fast.

Many non-designers (including executives and project sponsors) do not understand this aspect of design - and assume that a designer can knock out a perfect solution in a single sketch without any trials. In fairness, designers generally enjoy being regarded as magicians who can knock out perfection in a single try - so they've done little to discourage this notion and to rectify the perception of their work.

A design doesn't "work" until it works for the user - and the only way to get to that point is to start with something that is a good idea in theory, then test it in practice. Designers and their managers should be accept that design is a process of trials, and to admit that they were wrong about what they thought would have worked.

Neither is user research particularly useful in guiding design before the fact. When people are asked what they need, they are imagining and speculating. They are no more accurate, and often quite a bit less accurate, than anyone else in suggesting what might be useful.

Usability testing can also inform those who write functional requirements. In the course of seeing what a user attempts to do to use the device, there may be discovery that some of the functions that were intended are not very useful, as well as uncovering additional functions that would be useful.

How long to iterate depends on the team's flexibility and desire to achieve a quality output. Ideally, the process ends when the major flaws have been identified and solved - and the solutions tested to ensure they are effective. Where time and money push quality aside, there may be a fixed number of iterations, followed by a "best guess" at a solution that will not be re-tested but assumed to work.

ACTIVITY-CENTERED VERSUS HUMAN-CENTERED DESIGN

Most manufacturers do not create a product that is customized to the needs of the user, but instead make a single version of their device and expect people everywhere to learn to use it. For example, a camera sold in one market is identical to one sold in another, rather than customized to the needs of the market in which it is sold.

When this occurs, it is the result of activity-centered design. The process begins by asking "how would a generic person take a picture?" rather than asking the question of a specific person in a specific situation (how would a diver take a picture underwater?) and is usually geared to the most common expected use of the product (taking snapshots at a child's birthday party).

This is not necessarily a bad approach. Peoples' activities in certain regards tend to be highly similar. In most industrial economies, people purchase food at a grocery, take it home, and need a place to store a given quantity for a family of a given size - so the refrigerator that works in one nation will work in another without any changes.

However, all of this is based on assumptions, and comes at a given level of risk. In a location where there is no reliable electric supply, in a culture where families are larger, in a market where foodstuffs are sold in different packaging, the "universal" refrigerator design may not be a solution that the market will accept.

The author remarks on the standardization of functionality in the automobile. Aside of the fact that the drivers' seat is on the right in some cultures and the left in others (which itself precipitates some additional differences because the driver will operate things like the radio and air conditioner with his left hand instead of his right) the set of functions and features are the same: start the vehicle, set the direction, manage the speed, signal turns, and so on. People have a universal idea of what a "car" does and can easily switch from one to another.

(EN: Ease of switching is great for usability, but not so great for loyalty to brand. A generic product is a commodity product. If all do the same things, there is no advantage to buying one brand or another. There is also no learning curve to switch from a competitor's brand to yours - and no learning curve to switch from yours to a competitors, either.)

TASKS AND ACTIVITIES

The author pauses to distinguish a task and an activity. An activity is a high-level structure that is designed to fulfill a need, such as "shop for milk" whereas a task is a component of that activity such as "find a shopping basket."

(EN: A third level of behavior is the "action": a component of a task that is done in a single motion, ideally without interruption. This can get granular, such that "put the milk in the shopping cart" can be broken to actions of reaching out, gripping the container, lifting the container, moving it from the shelf to the cart, lowering it into the car, releasing the item, and releasing one's grip. This can be tedious but is sometimes quite necessary.)

An activity is goal-oriented and is not completed until the goal is satisfied. The goal of having dinner begins with deciding what to have, through shopping for the ingredients, through preparing the meal, through setting the table, through consuming the meal. The goal is not satisfied, hence the activity is not completed, until the meal has been consumed (or delivered to others for their consumption).

In this sense, product design is very often myopic: it is designed for one task within the scope of an activity, but not the entire activity. This becomes evident to the consumer when he discovers, for example, that storing an electric drill is quite a pain in the neck - it's an awkward shape and there are all the bits to keep track of. Clearly, the designer of the drill thought only of the task of drilling a hole, not the task of putting the item away afterward.

There's also a bit of a diversion about "be" goals and "do" goals. It is fairly easy to focus on what the person wants to do - as that precipitates a task. The "be" goal is much more difficult to fathom because it gets to the reason a person chooses to perform a task, including non-functional psychological goals. A person does something because he wants to be (or become) something - to achieve or maintain a self-image.

That is, a person consumes food to be satisfied (not hungry), to feel better about themselves for making a dietary choice that conforms to the kind of person he wishes to perceive himself as being, and even to do so in the sight of others whom he wants to impress with the image he is attempting to project. All of these are abstract and difficult to gauge, but they figure into the choice of what to do and the way in which a person goes about doing it.

The author asserts that if you design for individuals, the results may be wonderful for the person for whom it was specifically designed, but may be awkward and a poor match for others. If you design for activities the result will be usable by everyone. (EN: I'm inclined to disagree, and would finish "if you design for everyone" with "it will be awkward and a poor match for everyone" because it is based on assumptions and generalizations that are not necessarily true of any specific person.)

ITERATIVE DESIGN VERSUS LINEAR STAGES

He speaks momentarily of "waterfall," a software development methodology that has a linear process of planning and developing a solution that is designed to provide ample time to define requirements and design a solution - and which refuses to flow backwards if something discovered in testing would require a change in design to correct. (EN: This is not strictly true, as waterfall allows for change requests, but it is often the insistence of project managers to plow forward even when fatal errors have been discovered because change requests are signs of poor planning.)

This approach often allocates too much time to a given task, and then assumes that once a task is completed, it is done perfectly and will not need to be revisited. It allows for large teams to be coordinated and resources to be scheduled according to a development calendar that is fixed in the earliest stages of planning. A milestone or "gate" marks the progress from one step to the next, and there is no backtracking.

An alternate approach is called "agile" in which teams largely wing it - they come up with high-level descriptions, develop a solution, and then iterate to work out the kinks. This approach assumes there will be kinks and provides ample opportunity to rethink and correct.

There is fierce debate over which of these approaches is superior, and each have their virtues and deficits. But insofar as design is concerned, the iterative method is preferable because design is a process of discovery and a designer needs multiple trial-and-error cycles to define the right design. The linear process assumes the perfect design can be imagined in advance - which is almost universally wrong.

(EN: What this overlooks is the decision of when a project is defined. In general, R&D efforts are "agile" affairs in which prototypes are built and tested through an iterative process - but once the design has been refined, it is handed off to production. It could well be that agile R&D and waterfall production development is the best hybrid approach.)

THE NATURE OF PRODUCT DEVELOPMENT

The author suggests a "law" of product development: the day the process starts, it is already behind schedule and above budget.

This problem has arisen as a result of the conflict and dishonest behavior in negotiations between sponsors and project managers. Sponsors want to pay as little as they can and have things done as quickly as possible, while project managers are always "padding" their estimates to provide a schedule that allows for things to go awry. So unrealistic timelines are the norm - and projects that go over budget are also the norm.

For designers, the result is that the design phase is often crushed. Design work has no material evidence - so when a project manger sees a need to compromise, it is easier for those who do hands-on work that produces something tangible to argue for time, whereas a designer simply needs the time to come up with a good idea. You cannot substantiate, on the basis of observable tasks, the amount of time it takes to come up with a good idea or discover a solution. And therefore, design is shortcut - and designers are tasked to provide not a good solution, but the best thing they can think of in three days (or less).

The author muses that having designers in touch with the field is one way around it. The more information they have in advance about the customers' behavior, the better informed their decisions will be for any given solution.

(EN: This turns into a disjointed ramble, or perhaps just more of one, and I'm unable to fathom the author's point, if there is any, in this section.)

Theory and Practice

All disciplines are learned in theory and proven in practice - and what is often found that what works in theory does not work in practice. A theory is entirely speculative, about the way things ought to be rather than the way they are - and even when backed by research, a theory may be applicable in a specific situation, or under specific circumstances, that do not match the present situation. This is the importance of testing ideas before going into mass-production.

He suggests that, in theory, businesses are innovative and attentive to the needs of their customer - while in practice, most tend merely to copy their competitors and are indifferent to the needs of the consumer. Some merely pander to the ego of insiders and company politics.

Both firms and designers who have an earnest interest in serving their customers may consider theory, but will not act until it is backed by research - and research that is conducted with users and situations that are as close as possible to the real customer and their real situation.

Design Challenges

Designers are problem-solvers, and they face an array of very complex and differentiated problems. Moreover, designers work in an array of industries, such that during a given year a designer may be called upon to design a variety of things: a camera, a bus station, a computer printer, a vending machine, and an umbrella. Designers can work across many different areas because they are specialists in the one thing all those have in common: people.

Design is different to engineering. An engineer decides how something can be built, as the designer determines how it ought to work. This is the reason that a designer doesn't need technical knowledge to do his work - he brings the knowledge of people, the engineers bring the knowledge of materials.

Design is different to marketing. Marketers are concerned with convincing people to purchase products, and are indifferent to whether they get any value out of the product afterward. Designers want to ensure that the product does something for the person who uses it.

In a well-run organization, the work between people of different disciplines is collaborative rather than combative, although there is often give-and-take among them.

There's a quick shift to the topic of constraints. There are very few instances in which a designer is able to design the perfect object - ignoring the need for the product to be affordable, ignoring the need for it to be possible given the laws of physics, etc. The needs and desires of the user are one set of concerns, but there are other constraints.

PRODUCTS HAVE MULTIPLE, CONFLICTING REQUIREMENTS

The author mentions situations in which the buyer of a product is not the one who will be using it. For example, few homeowners will buy faucets - most are purchased by construction companies. In these instances, the buyer of a product is often interested in things such as the size or the price of an item, but cares little about whether it is usable. (EN: Though by proxy, the construction firm should want to please the person who will buy the home that contains the faucet, few think that through very far.) A company owner or supply clerk likely orders the office supplies that will be used by their employees, and again is concerned with controlling costs while providing just enough quality to avoid being criticized for making a bad decision.

He complains much about corporate purchasing departments and the misery they inflict on the employees of a firm, who must deal with the frustration of poorly designed and barely functional equipment and supplies. No-one seems to hold them accountable for lost productivity when employees have to constantly spend time clearing jammed printers and copiers because they purchased cheap paper. People have to complain fairly loudly for a supply clerk to consider usability along with price.

But even in designing products that are purchased by their user, price remains a constraint. People can only afford to spend so much for a product and the additional manufacturing cost of a well-designed product must be factored into its price - such that some users will opt for a cheaper, less usable alternative rather than paying a price premium for something that is better suited to its purpose or easier to use.

Aside of the users, the designer must also accommodate the people who build, ship, and install products. They must accommodate the people who will sell it, and those who will provide service after the sale. And they must accommodate the firm's desire to turn a profit. Each of these groups brings their own requirements and interests to the table, demanding to be accommodated by changes to the product's design.

All of this makes design a complex activity that is often impacted by constraints and compromises, in which the designer must negotiate the conflicting needs of multiple parties.

DESIGNING FOR SPECIAL PEOPLE

Designing for the average person is not a particularly good idea - primarily because there is no such thing as an average person. Design must accommodate all people, which means designing for the extremes.

Consider designing a life vest for the average person. Mathematically speaking, 50% are larger than average, which means that half of people would not be able to use it - and likely more than half, because some percentage of those who are smaller than average would find it too large, rather than too small, to wear. As such, a life designed for the "average" person might work for only 25% of the population - leaving the other 75% without any protection in an emergency situation.

Naturally, design does not seek to accommodate the average, but seeks to accommodate most - often the Pareto principle of 80% is used, simply in the manner of a shrug. But even if you design to accommodate 99% of users, when you compare this to the 7 billion people in the world, it means your design leaves out 70 million people.

Some problems are not solved by averages. What is the average of a left-handed and right-handed person?

He mentions that some products can be designed to provide multiple alternatives. Clothing generally comes in multiple sizes to accommodate different bodies, and may products have a left-handed version available. But back to the example of a life vest, when a boat has capsized, who can invest time in sorting through a bin to find a life vest of the right size?

Consider the automobile: there is no one size or shape of vehicle that suits the needs of every person, but a wide range of styles to accommodate functional needs and taste preferences. Even a tool as simple as a pencil comes in a wide range of needs (the standard graphite pencil, a grease pencil, the mechanical pencil, etc.)

And finally, there are concerns designing things for the aged, infirm, and handicapped individuals, which merit a separate section ...

THE STIGMA PROBLEM

Many items designed to aid people with particular difficulties fail - simply because they are rejected by their intended users. Many people do not wish to admit to having infirmities, even to themselves. Consider that contact lenses and laser eye surgery are simply alternatives to eyeglasses, for those whose vanity does not allow them to admit that their vision is less than perfect.

The problem is particularly pronounced in present culture, given the "baby boomer" generation resist the notion that they are getting older, and are loath to admit they need special accommodations. Consider that 100 years ago, a cane was seen as a fashion accessory, and gentlemen of all ages carried them. Nowadays, a cane is a sign of old age, and no-one wants to carry one.

One positive note is that items designed to accommodate people with special needs are often more usable to people who do not have difficulties. Consider Sam Farber, who created the OXO brand of kitchen utensils. His primary intent was to accommodate his arthritic wife - but many people with no disability found kitchen tools difficult to grip and use that they have taken to the brand, in spite of its costing significantly more. (Though the author admits that a vegetable peeler is very cheap, so even one costing three times as much is affordable to most people.)

The author mentions the notion of "inclusive design" or "universal design," which means designing products that can be used by both normal and disabled people. In some instances, this means design for the lowest common denominator - making everyone use handicapped versions even though most do not need the accommodation it provides.

In other cases, items can be made adjustable. A printed book may be available in large-type version for those with poor vision, but an electronic book may have a setting or preference to increase type size, enabling a single device to serve multiple users. A television set may be designed primarily for those who can hear and see, but settings to turn on captions or a secondary audio program can be used to accommodate disabled users.

Complexity Is Good; It Is Confusion That Is Bad

Cooking in the home is an excellent example of the value of complexity and the problem of confusion. Your own kitchen is a place of great complexity - with various appliances, implements, and storage spaces - but the complexity gives you a great deal of ability. You are not confused by your own kitchen, but you would likely be very confused if you have to cook in someone else's, not knowing where things are kept or how to work the controls on the blender.

The problem of confusion is really a problem of knowledge. Once you know how something works, you delight in its complexity and multiplicity of functions and capabilities. But until you know how it works, it seems confusing and intimidating.

Why can't things be made simple? Because life is complex. People want the ability to do many things, and need tools to do them. If you only need to do a few things, and are willing to give up the capabilities to do more, then simple devices will do.

(EN: This is mentioned in terms of the iPod and the iPhone. The iPod is a simple device that just plays music. The iPhone is a complicated device with many applications that must be learned. But people expect their smartphone to do many things, and take the time to learn to use them.)

Standardization and Technology

Laws that govern human behavior set standards that are essential for the welfare of all. Consider what chaos there would be if a country did not standardize which side of the road to drive. Other standards are voluntarily adopted to provide efficiency: the fact that a screw, bolt, or valve is turned to the left to loosen it and the right to tighten it is not a mandate of law, but a useful standard that enables users to act without thinking or having to figure out which way to turn a given item to loosen it.

(EN : Since "law" is mentioned, it's likely important to state that there are many areas in which the law has interfered in the name of efficiency or convenience. In some instances, laws that intrude into non-political affairs have been beneficial, in other cases not so much - but any device manufacturer would do well to engage attorneys to be aware of the legal requirements of designing something.)

ESTABLISHING STANDARDS

Outside of standards that are enforced by law, there are many national and international committees that suggest standards that organizations may voluntarily adopt. Such standards facilitate trade: a manufacturer in need of a part or component need not provide detailed specifications if he can refer to an established standard - and the ability to manufacture standard components rather than tailor each item to the needs of a buyer creates significant efficiencies.

The author goes through a rather elaborate explanation of how a standard is created through a committee, but there is no single method as each organization has its own methods. It is fair to state that when a group of people form a committee, they tend to begin by defining a simple procedure that becomes more and more elaborate over time. Individual members bring their own personal agendas and desire to have clout, and organizations infiltrate committees in order to get standards declared that are in their own advantage. The entire process becomes far more difficult than it ought to be.

The politics of standards goes beyond the organization itself and sometimes becomes an international matter. For example, France sat on the sidelines of the international conflict in Iraq, but was eager to participate in the reconstruction in order to dictate standards: they would rebuild the electric utilities. Behind this ostensible act of generosity was a strongly commercial motive: if Iraq's infrastructure was rebuilt to the French standards, the entire nation would be dependent on French manufacturers for not only electrical system parts, but even household appliances and industrial equipment. Had they been allowed to "contribute" it would have been a significant commercial victory.

(EN: The author doesn't mention standards that are internal to a firm, or which are less formal. Ideally, they can be developed without an act of parliament by simply allowing manufacturers to do what they will, and trust that best practices will be adopted without artificial pressure or manipulation - which is the way most standards arose.)

CASE STUDY: HIGH-DEFINITION TELEVISION

The author mentions the emergence of broadcast standards for high-definition television (HDTV) and the antics that prevented it from spreading more quickly. HDTV was in fact first discovered in the 1970s, by the Japanese. It took almost three decades for the Americans to catch up.

The television industry proposed its own HDTV standard for the US, but when they proposed it to the FCC the computer industry fought back, suggesting that the format was no compatible with the way computers displayed images. Every aspect of the technology was debated, from the resolution (pixels per inch) to the aspect ratio (4:3 and 16:9 were in competition), to the frame refresh rate.

Manufacturers were loath to begin producing equipment to suit an undefined standards, as their products would be rendered useless and their factories would need to be completely retooled if the standard turned out to be something unexpected. They wanted the debate settled.

As a result, it took over ten years for the standard to become accepted and for manufacturers to support it to the extend that broadcasts and televisions sets could be made available to the public.

In all, this meant that the US was around 35 years behind the Japanese in television technology. The author mulls over the question of whether this was really worth it in the end, which could be argued either way.

A STANDARD THAT NEVER CAUGHT ON: DECIMAL TIME

Even in nations where the metric system has taken hold, time is still measured by the old imperial standard. Rather than a convenient base-ten system, it remains awkward: 60 seconds to the minute, 60 minutes to the hour, 24 hours to the day, 7 days to the week, 28-31 days (some odd fraction of weeks) to the month, 12 months to the year. He spends a good bit of time elaborating on the obvious.

No-one but the French proposed a decimal time system, and their idea didn't catch on. While it would be possible to decimalize a day, there would still not be any coherence to the way in which days related to months or months related to years. If the year was taken as the basic unit, then a given time might be mid-afternoon one day and late night the next time.

(EN: Consider the pre-Julian or Muslim calendars. The month of "Ramadan" may be winter in one year and summer a few years later.)

The rotation of the earth, the orbit of the moon, and the orbit of the earth around the sun are each independent phenomena that do not have dependencies or a base-ten relationship to one another. As such, time must be accepted as it is, and will not yield to our desire to fit it to our notion of order.

Deliberately Making Things Difficult

In general, designers seek to make things as easy as possible to do, but there are often instances in which they deliberately seek to make things more difficult - or accept a compromise in ease of use when there is a greater concern.

A common reason for difficulty is security. The simplest way to enter a building is simply to push open the door and stroll in - but there are many instances in which we want to prevent "just anyone" from doing so and ensure that only those who ought to be in an area can open a door. People don't want just anyone strolling into their home, so they install a lock - even though it will slow down people who are supposed to have access (they will have to take out a key, turn it, open the door, and then lock it again behind them) the inconvenience is worthwhile to prevent unauthorized access.

Safety is another issue. One example is given of a door that had two latches - one at the top and the other below, which were difficult to use - a person would need to reach up to open the top latch and press with their foot against the bottom one before the door would open. The reason for this difficulty is the door was to a school for handicapped children, and they didn't want the children to be able to open the door and go out onto the busy street outside without an adult accompanying them.

In these instances, things are designed to be deliberately difficult for some people to use - and while they are inconvenient even to those who are expected or permitted to use them, the difficulty is worth the security, safety, or privacy they provide.

The author provides a list of examples:

The author touches upon the notion that security and safety measures merely make things more difficult. A person who has learned to pick locks can bypass any lock he is trained to pick, a hacker can bypass security of a computer system, and so on. So what these measures do is to ensure that a person who does something is meant to be able to do it, and that they undertake some additional step to do it deliberately rather than unintentionally.

Difficulty can be achieved by simply breaking some of the rules of good design.

He also mentions the degrees to which difficulty is implemented: whether a task is mean to be performed only by a selected number of users, or should be something anyone can do in specific situations. For the latter, consider a fire axe in a glass case - the legend "in case of emergency break glass" tells anyone what they need to do to get the axe, but the pane of glass discourages them from getting it when there is not an emergency. The same goes for emergency exits - which even more clearly illustrate a kind of security that is meant to be circumvented by any person under the right circumstances.

JIM.SHAMLIN.COM
DISCLAIMERS · CONTACT