1. Not understanding the nature of the Internet.  Too often, design teams think of the Internet as a pushing media such as television or radio. Users’ behavior on the Internet is different than when they are reading books or newspapers, listening to the radio or watching television. For example, when browsing, users have goals and look for information.  If they don’t find what they are looking for, they will leave the page after 8 to 12 seconds.  Users scan web pages.  They don’t read.  If something looks like an ad, they will rapidly look someplace else.
2. Forcing users to guess what is clickable or not.  Design teams expect that users will figure out what will be clickable on their page.   This is not the case.  In most cases browsing is non-mandatory and users do not put their full attention on a website.  In this context, it is very likely that they will not click on a non-visible link even if they understand that a cursor changing from an arrow to a hand means a clickable region. Blue underline hyperlinks are the most effective.  Users perceive such hyperlinks 50 milliseconds faster.   In the world of limited attention resources, loosing 50 milliseconds of user attention means leaving money on the table
3. Not understanding the interactive aspect of the Internet.  Too many design teams see web pages as a static entity.  They have design meetings with color printouts of web pages laid out on a table.  They get clients or management to sign off on a project with static pages.  When people talk about a book, they don’t talk about the front page but rather about the story.  Discussing interaction issues with static pages is like talking only about the front page of a book.  Since interaction is dynamic, this process results in poor design decisions where too much emphasis is put on superficial aspects, such as the look.  Never forget: user interaction with web site cannot be describe, written or verbalized, it can only be observe.
4. Using ads in the same way they are used in traditional media.  Internet is a goal-driven media with very limited user attention.  The bandwidth of user attention is similar the one we have when looking at a billboard on the highway: a few seconds.  Worse, on the Internet, users are not captive but in control of the interaction.  This does not leave much room to be pushing ads.  The only effective way to do that is to position related items at the right time and place.  This requires designers to understand the probable sequence of users’ goals (the path of attention) and to position related items for cross-sale or up-sale in the form of links inside the useful field of view (5-7 cm diameter on a screen).
5. Copying others.  Too often, designers start with the designs of others as the basis for their own design.  The reasoning is that because other companies use a certain approach, it must be good.  This lazy way of solving problems often results in solutions that do not solve the target user problems.  Instead, the focus should always be on solving the target user problems first.  Once the design team has a clear picture of the users and their problems, and only then, can they take a look at how others and the competition address those issues.
6. Cluttering pages with too much information. On home pages and landing pages, user attention is 8 to 12 seconds and reading speed is about 3 words per seconds.  This corresponds to a total of about 25 to 35 words.  The useful field of view is about 5-7 cm, leaving a space of about 4 to 5 groupings on a web page.   When reading a list, users abandon after 5 to 7 items unless the lists are organized in alphabetical or numerical order. 
7. No back button. Users expect to be able to use the browser’s back button.  There are so many websites that do not permit the use of a back button.  Often, IT (Information Technology) people bring security issues as a reason for the lack of a back button, but the fact is that its incorporation requires them to do more work.  Who should do the work, your millions of users or the programmers?
8. No concise writing.  On the web, users are not fully attentive and tend to scan a page.  This means that the comprehension capability of a user with a college degree will be equivalent to that of a user with a fifth grade education.  The writing must be simple, short and right to the point.  To achieve this goal, designers must reduce the quantity of text by 50% in the first review and reduce it again by 50% in the second review.  The text must be tested many times for clarity.
9. Pop-ups. They are annoying, disruptive and do not provide browser navigation capability.  In addition, they cannot easily be printed and are often blocked by pop-up blockers.
10. Small font size. This is the most commonly violated rule.  All sites should provide readable fonts.  With a contrast of 100%, the font size must be equal to 1/200th the distance of reading.  On a computer screen, this means a size of about 3.2 mm.  For a standard font such as Arial or Verdana, it is about 11 points.

1. Experts cannot assess terminology choice and evaluate task compatibility. Terminology and task compatibility account for the majority of usability problems. To my knowledge, the only effective approach to evaluate terminology and task compatibility is through usability testing and field study.
2. The importance of heuristic (guidelines) depends of the context of use. For example, is the user going their once in a lifetime? Or is he a power user going there all the time on a mandatory basis.

As I always do, I complied telling the client I will do heuristic evaluation with the help of informal usability testing instead of pure heuristic evaluation. That way, I don’t loose time explaining clients why they are wrong. I asked a few colleagues or friends to act as subjects for the informal usability testing who could be representative of the audience.

Following the evaluation, I found the design of the portal was poor but I was not surprised, I have often seen bad design throughout my consulting practice. As usual, most usability problems were associated with confusing wording, task compatibility issues and funky use of interaction techniques. Up to now nothing unusual. I went on presenting my findings. But, while presenting, the client constantly interrupted me saying this or that; we cannot change it because it is a decision from the upper management. In some cases the minister himself got involved in the design choices.

Only later, after the formal usability testing where all users failed on all tasks, I got the client to admit the design was poor. At that point they had no choice but accept my recommendations. This situation is painful because it places the management in a bad position. They were involved in poor design decisions.

More recently, a client in the airline industry told me he does not want to hear about usability because everybody has a different opinion. They often end up asking the CEO to decide. Again, I will have a very challenging consulting project because it might show the CEO made the wrong decision. Of course, I will try to find ways around it but nevertheless, it is not easy.

For many organizations, design (user interface design, user requirement, and functional specifications) is a painstaking process involving fierce battle between stakeholders. When they do not agree, they escalate to upper management for decision.

Escalating design decision that otherwise should be taken by the design team is a sure recipe for politics. If decisions are wrong, it will be uncovered sooner or later. Then, you will be in serious trouble.

How to prevent this?
If you’re an executive, never get yourself involved in detailed design aspect. Keep yourself at the goal level and let your team design solutions. If your team tries to get you involved in design deadlock, it is because they have not done their homework or they lack expertise. Your project manager might say there is a deadlock; he needs your help to move forward. He will try to reassure you by saying he will fix the usability issues later. Don’t believe that, it will never happen and you will get stuck with a poor design for years. Stress it to your team you don’t care if the screens are blue, white or yellow as long as users were able to achieve their goals rapidly, without hesitation and errors. Get an external usability company to evaluate the design of your internal team so you will get an objective assessment of the design. Don’t worry about the susceptibility of your people, there is an easy way to manage that. If you don’t show leadership, you risk to be stuck with poor design for years if not forever.

Never forget, usability equals productivity. The first reason why we use technology is to improve productivity, so good design is extremely important.

If you are member of a project team, base your design decision on facts instead of opinion. How? Learn usability best practices, build a prototype and test your design with users with usability testing. If you do not have this expertise, don’t hesitate, get and external consultant in usability.

The current version at the financial institution is a Windows based GUI (graphical application based). The proposed version was totally web based. After a business review that included a field study and cognitive analysis, I discovered that both the current and the new software didn’t meet the business needs. In fact the current version required lot of manual entries and was highly error prone while the new version would not address those issues and would, in addition, require three times more user action.

I soon made my client aware of this. The project manager, who is from the information technology department, reacted by saying the project scope is to make the transition, respect deadlines and budget. Meaning he does not want to change the plan. Information technology department even contested my findings and required me to demonstrate the facts again. After revisiting my findings they realized that the situation was even worst than they expected it. In the end, the financial institution followed my recommendations because the facts were rock solid and we found a solution that would integrate existing technology already in use at the financial institution.

Sounds familiar? Many IT (Information technology) projects are planned and scoped before analysis or field study is done. In many instances, the justification is a technology replacement or and upgrade. Over the last twenty years I devoted my consulting practice on project turnaround and I encountered hundreds of similar situations.
Last year I attended a three day PMI (Project Management Institute) training camp. What amazed me the most was the widespread acceptance by the PMI community of the irony of planning and estimation for software projects.
Here is the problem:

To estimate a project, you must first know the amount of work required to complete the project. To build two (2) kms of road will require twice as much work than building one (1) km.
In a software project, the amount of work is defined by what (the functions) you will build. You will have a good idea of the functions you will build after the functional specification phase. Since the functional specification is usually done after the planning and estimation, you get the information you need to estimate the project after the project is started. It is a bit like if you have to plan and budget the medical treatment before the diagnostic is done.

I can assure you that in physics, my previous career, you would get fired or put aside fairly fast if you come up with something like this.

What is more, estimation at the planning stage is guesswork. In PMI methodology, they mention arcane techniques such a point of function method or historical data or some other combinations but again, this is, in my view, a sophisticated cover up for guesswork. Yes, there are calculation methods but the input assumptions are based on human judgment (guess). Those judgments vary from one person to another. Often, the estimator does not have any ideas about the business and operations. For example, in the Government of Quebec, software architects estimate after meeting user’s representatives that previously met business analysts who never met end-users.

Typically, once estimations are done, budget, scope and timetables are established. The board approves the budget, people are hired and project execution begins. If you discover in the course of the project that real business needs differ from what you planned, the story above is repeated. The project manager will tell you it is out of scope. Or he might say your new findings could be filed as change at the end of the project. Remember, he is hired to execute the plan even if proven wrong. Isn’t he?

There are solutions:

1. Do you ask yourself if the application you are using (email, office application etc) is in Java, PHP, C Sharp, etc? Most of us will answer “I don’t care”. In fact, 100% of the user experience (UX) is provided by the user interface (UI). So why not start the project by the end. Why not design and test the user interface before the project is established and a budget is set. Then you will know what to build.
2. Look at other industries, such as automotive or aerospace. They all start by verifying their biggest risks first. When Airbus or Boeing want to develop a new airplane, they build a large-scale model, display it at Bourget salon and take orders even if the plane does not exist. If there is not enough order, they will cancel the project. Car manufacturers, design clay models, present those models in a show room to verify if the client will buy it. Then they will plan production. So both automotive and aerospace start by the end.
3. Remove red tape and bureaucracy. Allow direct communication between developers and users
4. Invest in continuous business analysis processes where field study (ethnographic study) is part of the culture. To my knowledge, the best approach to do business analysis is the cognitive approach.
5. Budget business analysis and diagnosis throughout the operation on a continuous basis.
6. When executing verify risk by simulation, experimentation or calculation.
7. Allow information to circulate though project by keeping project size small

Say a lot with less!

2. Avoid having wrong design goals. For example minimizing the number of clicks. To ensure having the proper design goals, know the users, their goals and the context of use. If users are going to your site once in a while on a non-mandatory basis (online banking, news, shopping…), you have to treat them as a novice. They have to understand instantly how to use the site. In this context, it is preferable having a few more clicks and pages with less information. On the other hand, for power user, speed is more important. In this context, less actions, pages and clicks are more important.

3. Do few things and do them well. For example for an e-commerce site, ease of finding the product, having the right information on the product and trust are the key success factors. For a search engine, ease of entering queries, speed and pertinence are the key success factors. Don’t spread your energy on other features unless you master your key success factors better than any others.

4. Design for user limited attention. On the web, many users have little patience and do many things at the same time (they might go on your site while at work). Within 10 seconds, they will abandon if they don’t find what they are looking for. Since the reading speed is about 200 words per minute, you can provide a maximum of 35 words to read before a user abandons. So minimize the quantity of text. Contrary to TV where the full screen is in use, on a computer, only a small portion of the screen is viewed simultaneously (roughly 6 to 7 cm diameter). This is due to the useful field of view, which corresponds to the subtended angle of the fovea vision. Information must be grouped within this diameter. That’s why banners are so ineffective. For most page layout you can afford about 4 to 5 groups. Avoid long lists of items, users read only the first few items at the top of the list. Organize according to the natural eye path. Remember users start from the top left corner, go to the center and if they don’t find what they are looking for, then they try to go to the left expecting a menu. For this reason, avoid menus on the right. The bottom right is the worst real estate of a page.

This sketch show the typical eye pattern on a web page.

5. Avoid relying on branding. Users do not remember seeing your ads, brochure and other corporate information. Keep your brand simple and name your entire product line in relation to a user goal. If you already have a brand for a product, provide a prompt matching the user goal. This also help SEO (Search Engine Optimization). For the same reason, you don’t need to be that consistent between corporate brochure and web site.

6. Users don’t read, they scan. Users will scan text and when they find something that is likely to meet their goals, they click on it. You better to expect that users won’t read your text. A good approach is to provide just a list of hyperlinks with a large font. You can also provide a small description with a maximum of 15 words with smaller lighter font under the hyperlink. This technique is ideal for a newsletter. Users will scan the list, if they are interested, they will click on it and read the description under it.

7. Ensure users understand your text and graphics. At least 50 % of the usability problems are related to the wrong choice terminology. Users get easily confused between concepts such as events and news, schedule and time table…. Minimize the number of concepts. Don’t worry, users mix apples and oranges. Test and test again your site with real users to find the right terminology.

8. Don’t reinvent the wheel. Use basic web controls. You don’t need to create complex navigation structure. A simple menu and the browser’s back and forward button are Ok for most of the cases. Once users have a successful behavior, they continue to us it for other goals. For example, if they find something through the menu, they will try this method again for another goal. Limit your design to familiar controls. Use straight hyperlinks to select a page. You will make more money with blue underlined hyperlinks because the users’ reaction time is about 30 ms less.

9. Use readable font. If users find the information and can’t read it, it’s zero. Why using small fonts? If your fonts are too small, only younger users will be able to read it. With the right size, everybody will be able to read it. Fonts must have a size equal to 1/200th the distance of reading for proper readability. On a computer screen, fonts must be at least 3 mm. For example MS Sans Serif or Verdana at a minimum of 11 points are Ok. Font adjustment controls don’t work because most users that would need them never use them. Those having serious reading problems already have special adjustments on their browser.

10. Be permissive to errors. Users make errors. The best way to manage errors is to allow them. For example, be permissive to various date formats. On the other hand, if users make errors, ensure proper detection, recovery and simple messages. Messages must have two items: the status and the corrective action.

For more information , you should check the Top 10 Web Design Mistakes of 2003 from Jacob Nielsen

The levels at which impacts of change are major are not understood while the levels at which impacts are minor are easily understood.

Why?

Most managers believe people resist change because humans have a natural desire to keep the status quo. They believe that resistance to change is a defense mechanism caused by frustration and anxiety. With this diagnostic, executives belief that good change leadership comes with a strong message from the top, effective communication plan, mandatory training and sometimes, removing undesirable parties that are labeled as strong change resistant.
In fact, Individuals aren’t really resisting the change, but rather resist the loss of status, loss of pay, or fear they will not be able to achieve the same level of performance. While causes of losses of pay or statuses are visible, causes impacting performance involve factors at the unconscious level that are difficult to communicate.
We observe that in many business transformation initiatives those fears were justified. New processes would not permit anymore efficient tactics evolved over years of trial and errors.
How can we distinguish between fear and facts?
First, let’s look at the nature of change in human work, the impact of business transformation initiatives and to finish, what to do about it.

Why change is difficult in work setting?

Change happens on an individual and organizational basis. Change is everywhere: mergers, new policies, new technology, new management . . .
Employees resist change because they have to learn something new. They fear the unknown future and their ability to perform.
The unknown comes from subtle and nonverbal aspects of human work that are difficult to communicate.
The nature of work
Jens Rasmussen observed that human work is either at: the skill level, rule-based level or knowledge level. Don Norman also came to the same conclusion.
When driving a car, turning the wheels is at the skill level while letting the other car passes at the intersection is at the rule-based level. Deciding to choose a route over another one is the knowledge level.
In addition, we observe that there is a fourth level, usually called “meta-cognition” but I prefer to use “wisdom”, which involves self-awareness about our own limitation. For example, if tired or drunk, hopefully, we might decide not to drive.
Any human activity: tasks, sport, arts or leisure lies within those levels.

The impacts of change

Changing something at the knowledge level is relatively easy. If someone shows you a better route to go somewhere, you only need to understand the advantage and good indications and voila, you can execute the change.
At the rule-based level, it is a bit more difficult but manageable. For example, if the state decides to change the law and permit right turn on red light, an action previously forbidden, at first you need to pay a little bit more attention to apply the new rule. You may even forget to apply it but with little time and patience, turning on the red light will become natural.
The real challenge is at the skill level. Let’s say the car manufacturer decides to invert the position of the break pedal and gas pedal. It will take you months of practice and you might make many errors that might event kill you. Change will be very difficult to accept and you might express a high degree of frustration. You will certainly not use this car if you have the choice.
Those examples show that: efforts to execute a change at the skill level are much higher than at the rule-based or knowledge based level. The level of energy required is dependent of the level of work affected by change: being at the skill, rule-based or knowledge based level.
Convincing a golfer to change his swing is a much more difficult challenge than convincing him to change club number to reach the green. It requires much more energy to acquire the new swing.
The proposed law of change:

“The effort to execute change will be equal to the amount of energy required to execute the same level of performance.”
“The amount of energy required to change is the highest at the lowest level of wok affected”. Skill based being the lowest level while knowledge based being the highest level.

Business Transformation

In business transformation initiatives, people only understand impact of change at the knowledge and rule-based level but not the ones at the skill level. Skill level is mostly non-verbal and unconscious.
For example, during a word processing task, users might select backspace to delete few letters or they might select the mouse to delete a paragraph. The choice is usually unconscious. This is a good example of a natural way humans optimize energy. According to the keystroke model, it takes 1.2 seconds to delete 6 letters with backspace and it takes 2.6 seconds with the mouse.
Now, let’s say a vendor convinces management to adopt a new word processor. While nicer and with more features, it doesn’t permit using backspace anymore. It is likely that this subtle change would be unnoticed even during a demonstration. Only after implementation employees will complain and express their frustration. As good performers, employees will be frustrated because they cannot achieve the same level of performance. They might even express anger.
This is only the tip of the iceberg. In fact, in a real work setting there is a myriad of such optimizations tactics: being a particular noise, a visual clue, a physical arrangement, a specific sequence…

What to do about it

There is a science, Cognitive ergonomics (called Human Factors in USA), which permits the understanding of human work at all levels including the skill level. Cognitive task analysis permits gathering both verbal and subtle non-verbal operations such as eye movement, cognitive processes and unconscious manual movements. Understating work at all levels permits the understanding of the impact of change at all level of work.

Managers can stop managing change with brute force.

First: stop doing endless meetings and politics and go in the field. Wake-up and forget the meeting rooms, the real world is in four dimensions.
Second: do a field study and cognitive task analysis to fully understand the current situation. Field is rich and wild; people develop very sophisticated tactics.
Third: select a solution or design a new system that will permit skill transfer, keep efficient tactics and strategies and remove problems.
Fourth: before any implementation and at the earliest stage possible, design mock-ups, simulate and test them in the most realistic manner as possible. This is even truer with physical devices because there are so many subtle interactions with the environment.

Easier said than done but at least try to change the change management practice if you want to bring change in your organizations.

Sounds familiar, you’re not alone. Almost all users of the classical stove design, as showed in figure 1, activate the wrong burner at one time or another.

Why? It is in the human nature to associate objects that are side by side. As showed in the figure 1, the controls of the back burners are closer to the front burners. We cannot tell witch control activates what. This layout is highly error prone. To ensure we activate the right burners, we need to pay attention and look at the instructions. See also Don Norman’s Design of Everyday Things.

Fig.1 Classical Stove Design

Fig 2. New Stove Layout

With the layout presented in figure 2, there is no confusion. Association of control with the burner is now easy because the layout of control is compatible with the layout of the burner.

This example demonstrates design can play an important role in preventing human errors. A design that respects human’s nature and limitations will reduce the likelihood of errors.

Human error in managing human error

After having done hundreds of interviews with managers, we observed when discussing employee’s errors, most managers:

1. Blame employees for lack of attention or for lack of training (practice).
2. Overlook the possibility of preventing errors by a redesign of workstation or processes.

In our highly advanced technological society, we are still at the Stone Ages in term of human errors management

The stove example is the tip of the iceberg. Human errors are everywhere; from day to day errors such as trying to pull a door that should have been pushed to high impact errors such as: being attentive on the wrong signals and crashing a plane killing hundreds of people, having the wrong information and making bad investments, forecasting the wrong economics figures, misjudging intelligence report and brining a nation to war, making the wrong medical diagnosis, underestimating a budget for a project and being insouciant of consequences of our action on the environment.

Most of those errors, boils down to a combination of human errors that are at the cognitive level. They are errors of detection, attention, planning, estimation calculation, judgment, decision, comprehension, discrimination and execution.

Although aircrafts are still crashing, the safety record of the aviation industry is impressive when compared to other industries. At the end of World’s War 2, the aviation industry realized, following the pioneer work of Alphonse Chapanis and Paul M. Fitts, that human errors were caused by subtle inherent human cognitive limitations. The Aviation industry stopped blaming pilots or maintenance personnel for human errors decades ago. They tried to understand the inner cause of human errors.

This demonstrates it is possible to move away from the stone ages in a few decades. Managers need to stop limiting explanation of human errors to the lack of attention, lack of training or poor personnel selection and expand their analysis of to the real nature of human errors.

Newton observed the apple falling and devised the law of gravity; the telescope permitted Galileo to observe planetary motions and devise new conception of the solar system; Einstein following observations from Michelson-Morley devised the theory of relativity. Today, experimentations became more costly and take longer time. Scientific evolution has slowed down by longer time to gain results from experimentation. Nowadays, complex experimental apparatuses take years to build and require large investments.

Technological innovation follows a similar path.

“The Wright brothers built and tested a series of kite and glider designs from 1900 to 1902 before attempting to build a powered design. The gliders worked, but not as well as the Wrights had expected based on the experiments and writings of their 19th century predecessors. Their first glider, launched in 1900, had only about half the lift they anticipated. Their second glider, built the following year, performed even more poorly. Rather than giving up, the Wrights constructed their own wind tunnel and created a number of sophisticated devices to measure lift and drag on the 200 wing designs they tested. As a result, the Wrights corrected earlier mistakes in calculations regarding drag and lift, though they missed the effect of Reynolds number (known since 1883), which would have given them an even bigger advantage. Their testing and calculating produced a third glider design, which they flew in 1902. It performed far better than the previous models.”

Their wind tunnel permitted a series of rapid trial and errors that would have taken them years to achieve. The Silicon Valley is a land of rapid trial and errors. There are hundreds of new start-ups with young entrepreneurs willing to try new ideas. Time between new ideas and commercial products is short. High concentration of VC, University and high-tech companies render the whole region as the equivalent of the wind tunnel for the Wright Brothers.

The essence of innovations is observation. The essence of observation is experimentation. So to increase innovation capacity, it is essential to devise new ways to shorten the time of experimentation. That being a wind tunnel or new way to finance start-up.

For more on innovation in information technology, see sketching user interface for a way to shorten time in experimentation.

The Economist retains 4 lessons from apple:

1. Innovation can come from outside. In the case of Apple, the GUI (graphical user interface) was invented at the Xerox Park by a group that included Larry Tesler who later went to Apple to work on the Apple Lisa and the Mac. The Ipod OS (operating system) was designed by Pixo, an external firm. To do so, making a network of innovators, university and start-up is important.
2. Design around the user’s needs and simplicity, not the demand. You sell with demand but design by focusing on the user’s needs. When Ipod was launched there was no demand but Steve Jobs stuck to his instinct. In fact Apple as always integrated technology and simplicity with users in mind. Macintosh, Ipod and now the Iphone are all great innovations, but they were not the first. The characteristics of those innovations are not the novelty in functionality but the simplicity and user experience. It gives access of these novelties to a wider audience.
3. Ignore what the market says today and target new customers. The Ipod is an example. The simplicity makes the Ipod accessible to a wider audience. This innovation created the demand and consequently the market. Steve Job stuck to his instincts
4. Fail wisely. Most of the Apple success came from previous failures. The Mac emerged from the Apple Lisa failure, The Iphone is a response to the original music phone project with Motorola. When failure arises, learn form it.

In my view, the most important aspect is the Apple culture. It is not an engineering driven company but a design driven company. Decisions are not based on technical constraint. Of course, designers listen to engineers but they will sometimes ask them to go back to the drawing board and think again and be creative to achieve the design goal. For example Bill Atckison wanted the screen of the original Apple Lisa to be white instead of the traditional black in order to imitate the paper. Engineers at the time were strongly opposed saying it would consume more memory etc…but Bill stuck to his point and the engineers found innovative ways to achieve Bill’s design goal.

By being firmly centered on design and the user, more often than not, engineers will find a way to make the impossible possible. That culture is what in my view makes Apple stand out.

“WOW, I should have used this or that sketching technique and I would have saved huge amounts of time and money instead of building those expensive prototypes”.

It broadens the concept of sketching to the user interaction or in other words user experience.

In Wikipedia, a sketch is defined as a rapidly executed freehand drawing that is not intended as a finished work.

The objective of a sketch is to verify an idea rapidly and cheaply. Bill extends the concept to user experience. He describes a multitude of sketching techniques such as Wizard of Oz, Video, and paper mockup as a way to test user experience rapidly and cheaply.

The current level of maturity of user experience design (interaction design) is at its infancy just as was industrial design of the beginning of the previous century.

Most industrial designers and system designers make the same mistake. They jump too fast in the detail, hardware or technology. So they spend too much and learn about the user experience.

My view is that the concept is so important it could be extended to all kinds of system design disciplines.

This idea of verifying idea rapidly and cheaply is a necessity in some industries so it exists for years. For example in aerospace, the equivalent of a sketch is to place a model in a wind tunnel to verify the aerodynamic cheaply. In microelectronics, sketching is equivalent of a software simulation. As Bill Buxton describes in his book, the biggest risk when designing a new car model is the market. So car designers will build clay models and test the reaction of the market.

As for sketching user experience, sketching a project risk is absent in most initiatives. Such as business process renovation, information technology, R& D initiative and even in a business investment.

I believe that with creativity it is possible to sketch anything.

For example, I recently designed a market place for Jet charter brokers. These guys are like Wall Street brokers, their time is precious.

They had to phone vendors, check opportunities on web sites and constantly monitor emails to check if there is a new opportunity. Those emails are real time. At any time, there could be a new incoming opportunity. So they felt compelled to go back and forth to check those emails. There was also a great risk of omission

I studied those emails and sensed it would be possible to automate the reading of them. I went back to the IT department. But they told me it would be very expensive to build an algorithm to understand free unstructured text.

So in one night, I sketched the algorithm. I took about 100 of those email and devised 100 basic rules, I ran them with an excel spread sheet. After the simulation (sketch of the algorithm), I was convinced that it would work

I went back to the IT guy, gave him the rule and told him to implement the algorithm

The system is currently in operation. Brokers save time and each day they make a lot of money with this system.

So, I propose we could extend the concept of sketching the user experience to sketching the project risk. It could be making calculations, building a model, simulating the behavior, or in some instance setting a theatrical role play, etc..

There is always a way with creativity to figure out how to cheaply and rapidly verify a project risk.