Summary

In this chapter, we described another simple and inexpensive technique for requirements elicitation . A storyboard is anything you can build quickly and inexpensively that will elicit a "Yes, But" reaction from the user .

We can say with confidence that there has never been a time when we didn't learn a lot from a storyboard, and there has never been a case in which we left the storyboarding exercise with exactly the same understanding with which we entered it. So here's our advice to the development team.

• Storyboard early.

• Storyboard often.

• Storyboard on every project that has new or innovative content.

By so doing, you will get the "Yes, Buts" out early, which in turn will help you build systems that do a better job of meeting the user's real needs. Moreover, you may well do so more quickly and more economically than you have ever done before. Finally, you might want to read the short, true-life storyboarding story below. It might help you really get the point ”it certainly did for us at the time it happened .

A Storyboarding Story

(Some facts have been changed to protect the innocent and the guilty in this very nearly true story.) This story occurred during the development of a complex electromechanical device for a hospital pharmacy. The customer was a Fortune 1,000 manufacturer; the vendor, our company, had been hired to develop this new, complex electromechanical, optical, and fluidics-handling system. The project was in trouble.

One day, the vendor's project manager's boss (we'll just call him "Author") received the following call from the customer's senior management (a senior vice president, "Mr. Big," a powerful individual whom we had never before had the pleasure of meeting).

M R. B IG :	Author, how goes our favorite project?
A UTHOR :	Not particularly well.
M R. B IG :	That's what I hear. Hey, no problem is so big it can't be solved . Just bring your entire team out for a meeting. How's Wednesday?
A UTHOR :	(hastily scrapping every appointment for the entire team for Wednesday) Wednesday is perfect.
M R. B IG :	Great. Come on out and bring your entire team. Hey, don't worry about the travel costs. We'll cover that. Heck, just buy those tickets "one way."
A UTHOR :	(gulp) Thanks, I think. We'll see you Wednesday.

On the appointed day, we entered a large conference room with the customer's project team all seated at the far end. The team had obviously already been at the meeting for some time. ( Question: Why did the customer's team feel the need to meet before the real meeting started?) Author, this not being his first such event, walked to the other end of the room and sat down next to Mr. Big (theory being that it's going to be difficult for Mr. Big to scream at him if he is sitting right next to him; also, if he hits Author, there's the chance to win a lawsuit and recover lost project profits!).

After a short discussion, Author noted that among many significant problems troubling the project, the problem of "lack of requirements convergence" is causing delays and cost overruns. Mr. Big said, "Give me an example." Author gave an excellent example. The customer team members immediately started arguing among themselves , perhaps demonstrating that this was indeed a problem. Subcontractor breathed a small sigh of relief. Mr. Big watched the team for a moment and then said, "Very funny . Give me another example." Author's team pulled out five color renderings , each quite professionally done, of the proposed front panel and made the case that "We presented all these design options weeks ago, and we can't get convergence on a design, and we are well into the necessary tooling lead times." Mr. Big said, "This can't be so difficult. Team, pick one." The customer team members then fell out among themselves again. The day passed in this fashion. There was no convergence. There was little hope.

The next morning, Author was asked to meet for an early breakfast with a project team member ("Team Member"). Team Member, also a seamstress by hobby, pulled out a pile of felt, shearing scissors, and colored markers and said, "I'd like to facilitate the user interface portion of the meeting, using these tools."

A UTHOR :	Don't be silly; no way that would work. It will look silly and unprofessional.
T EAM M EMBER :	I understand, but how effective were you yesterday ?

Author, being politically correct, did not speak the first word that came to mind. The second word was "OK."

The next day, the tone in the room was very different. The customer's team was again there early but this time was silent and morose rather than intemperate and excitable. ( Analysis: They now know they are as helpless as we are. They had been planning to kill us but now they know that we are all doomed.)

To start the meeting, Team Member put a 3-foot-by-5- foot piece of felt on the wall, generating mild amusement but not disinterest on the part of the customer's team.

Team Member then placed large felt cutouts for the power switch and various therapy -mode buttons on the front panel and said, "How would this design work?"

A member of the customer's team (Customer) looked at the wall and said, "It won't, but why don't you move the emergency stop to the back?"

Team Member said, "Here, why don't you do it?" and gave the scissors to Customer.

Customer took the scissors, and Team Member retired to the back of the room. Customer proceeded to do an interactive design session with felt and scissors. One hour later, Customer looked at the wall and said, "Good enough; build it."

And off we went to do just that with our one-way return tickets home.

Let's see if we can discover the moral to this story with a little reader Q&A.

Q UESTION :	Why did the fuzzy felt work when the professional renderings did not?
A NSWERS :	There are two reasons. Interactability : What could the customer do with five drawings, of which the customer's team liked only a portion of each? Usability : How intimidating can it be to cut out a big piece of felt?

The customer, who had the domain expertise but not necessarily the design expertise, designed an adequate solution to its own problem.

We took the felt home with us and stuck it on the wall, where it stayed for many years as a constant reminder of the lesson we had learned. For the project, the fuzzy felt front panel design, although probably less than optimum, never changed again and was quite adequate for the intended purpose.

But no, the project was not a huge success for the vendor, although the product did eventually go to market and achieved some commercial success. As we said before, that was only one of the problems on this particular project. (The device was operated by software, after all.)

LESSON 1 :	Understanding user needs is a soft and fuzzy problem. Use soft and fuzzy tools to address it.
LESSON 2 :	Performing research and development is tricky. Think twice before you start a medical device outsourcing business.