“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.