What I learned about decisive action and expert systems from electronics class.
I learned my first UX lessons as a teenager. Optimistic science fiction inspired me to work with computers. Authors like Isaac Asimov described a future where computers and software made the world better.
LESSON 1: DECISIVE ACTION CAN SAVE MORE THAN TIME
Design is always about constraints and consequences, but rarely involve a threat to life and limb.
HOW I STARTED DESIGNING SOFTWARE
My design career started from scratch. After a few years on path to becoming a fine artist, I right angled into technology design. At that time, you had to learn programming if you wanted to design software and you had to build a computer to do that. That’s where I started.
This was how I came to build an Apple II clone. It was an arduous and error-prone task to solder hundreds of connections. I enjoyed circuit design and marveled at how Steve Wozniak invented the personal computer, but soldering was just a tedious means to an end.
There are some things you can’t predict. One day, after hours of soldering with safety glasses, I took off my glasses and put my solder iron away. As it snapped into the wall rack, I felt a sharp pain in my eye. I foolishly forgot about it and went home. An hour later, I discovered that my eye was glowing. It took a few moments to clue in that I had melted solder stuck to my eye. My doctor was amused at my discomfort and scraped it off, rather painfully.
When the right action is clear, act now.
LESSON 2: THE DIFFERENCE BETWEEN USELESS & USEFUL SYSTEMS
Now that I’d built a computer, I was confronted with the problem “What is a computer good for?“.
PROBLEM: WHAT IS USEFUL SOFTWARE?
I was finally able to do the good part, design solutions to interesting problems. Fortunately, I was handed a good problem. My class had the job of repairing hundreds of old televisions in use at the school. The TVs had huge electron gun CRTs and vacuum tubes. In a huge school, there were always a few that needed fixing. Diagnosis was what took a long time.
APPROACH: BUILD A TV REPAIR EXPERT SYSTEM
I proposed making software to streamline TV repair. I assumed that I knew enough about repairs myself and created a simple menu-based expert system. For a reported problem, it advised you what to look for and select a choice based on what you observed. Following this pattern of observation, choice and action, it would help someone zero in on the answer in a few steps.
SOLUTION: CROWDSOURCE EXPERT KNOWLEDGE
The problem was that I didn’t know everything about fixing TVs. My classmates dissed it because it was incomplete, so I started again, basing it on the best repairman in my class. It was better, but still incomplete and therefore not helpful. Discouraged, I asked the whole class to list things it missed. It turned out that everybody knew a few unique things, but nobody knew it all. I wrote it all down and started rewrite #3, shadowing these guys. I also refactored it to follow the way the guys actually approached the problem instead of trying to push them to look at it a whole different way. I updated it every day with new improvements.
Suddenly, the guys started using it and liking it because it saved so much time. The striking observation from this was how useless it was when based on one expert and how indispensable it was when it contained everyone’s input.
Collaborative expert systems can add tremendous value.
My instructors were surprised that my rudimentary design could yield such great results, allowing a beginner to fix TVs as quickly as a pro. Today, we’d call it a crowd-sourced expert system.
This simple project taught me how to deliver value from design, something I now call the x-Factor. A valuable design a) improves what users are already doing and b) incorporates research into actual users. Good design is possible any time we pay attention to results and are willing to iterate.