In 1987, Ward and Kent were consulting with Tektronix's SemiconductorTestSystemsGroup that was having troubles finishing a design. wiki 
We decided to try out the pattern stuff we'd been studying. Like Alexander who said the occupiers of a building should design it, We let representatives of the users (a trainer and a field engineer) finish the design. This was our first positive application of patterns. wiki
Ward came up with a five pattern "language" that helped the novice designers take advantage of Smalltalk's strengths and avoid its weaknesses:
WindowPerTask FewPanes StandardPanes NounsAndVerbs ShortMenus
Ward and Kent were amazed at the (admittedly spartan) elegance of the interface their users designed. They reported the results of this experiment at OOPSLA 87 in Orlando.
.
Kent and I had been pair-programming for a couple of months at this time and had found Alexander's Patterns as approach to documenting implicit knowledge. STS had approached our lab director and asked for my part-time participation in their project. I said I wouldn't go unless Kent went with me. Together we could "post-process" anything we were told and that made all the difference.
I had this pet theory that engineers would always put the one thing that they really cared about in the center of any diagram they drew. When we showed up to our first STS group meeting I announced that we didn't want any explanations but instead asked each engineer to draw a diagram on the whiteboard. Thus we learned the names of all the parts and who cared about which ones.
"Debugger" was the think that needed attention. Smalltalk was known to have an excellent debugger but it didn't seem to help testing semiconductors.
We were invited to make a site visit to one of STS's best customers where their process was made clear. We learned that "debugging" wasn't what Smalltalk did. Debugging was how the tester configuration was incrementally improved to more correctly distinguish good parts from bad. This, then, was a data-entry task.
Upon our return we met with the field engineers who admitted that they had worn their "power ties" with every intention of telling what about this data-entry task had to be improved. Better than that, we said, a redesign is necessary and you are going to design it. One sigh to the other, I knew it would come to this.
Then, in fifteen or twenty minutes, we taught them how to draw a picture of what one would do with windows and menus to enter or revise configuration information. We can do this, they said, and did so over the next few days. They had enumerated the tasks and the nouns and verbs present in each and they had pictures that showed how one would use these to navigate between task in a very Smalltalk sort of way.
I remember one plea, please don't make us type in file names. There were no file names in their design. This didn't seem like a problem to me. The smalltalk code could make up good filenames from the names already present.
But, woe, the engineers that ultimately built the software thought they had just forgotten to have a place to enter file names so they added it with wild-card completion that they thought was an important contribution. I accept responsibility for this regression as we hadn't written down our patterns or shared them with the coders. They couldn't see the simplicity that had been designed for them.