Challenge

I develop software for a measurement device (the “Device”) which is installed on large, complex  semiconductor processing equipment (the “Tool”).  The device requires hardware “tuning” by installers  who turn calibration screws until the Device signals are maximized.  Currently, the installation team uses  a vendor app running on a laptop to view the Device signals.  The laptop must be abandoned at  customer sites, as customers wish to ensure that none of their Intellectual Property can be stolen.  The  install team wants to make similar software available through the Tool software/GUI.  However, the  Device produces a substantial volume of data, at a high data rate, and must be transferred through  three to four servers before it can be plotted on the GUI.  The data is likely to have a time lag or be a  drag on the local network.

Selection

I chose the Learning Launch tool.  In particular, I wanted to apply the Assumption Worksheet, as there  were considerable assumptions on the part of the installers requesting the software and on my part in  being wary of the complexity of the data.

Application

Hypothesis: we need a new utility on the Tool software to replace the Vendor software running on the  discardable laptop.

Key assumption 1:  Data volume for the transferring all of the data from the Device to the Tool’s GUI is  not feasible.

Test: Calculate the data volume and find out who is the network expert for the Tool’s software,  and ask if the data transfer is doable.

Results of test: Data transfer would be acceptable.

Key assumption 2:  The computer can pre-do some of the analysis that the installers do by eyeball, and  present the data to the installers in a superior way to the Vendor software.

Test: I interviewed the installers to determine exactly how they use their eyeballs to evaluate  the continuous stream of data.

Results of test:   I determined that the computer can indeed do that analysis faster and better.   In addition, the computer can display the resulting data as a time series, which enable the  installers to tell if the data are growing, which makes it easier to maximize the Device signals  while turning the calibration screws.

Learning Launch:  I created a mock-up of the data display for the new utility, and demonstrated to the  installers how it would be used.

Disconfirming data: The installers hated the proposed utility.  They want exactly what they had with the  Vendor software, and in fact they added a requirement that the new software must be run from a  remote Tablet computer (which will also have to be left at customer sites for IP reasons!)  Since the data  transfer is possible, I have no excuse not to implement a duplicate of the Vendor app.

Insight

1. Users be crazy!

2. As the software developer for the team, my job is mostly attending to all the details.  None of the  Design Thinking tools seems suitable for determining HOW to achieve what needs to be achieved.  The  tools seem to be for determining WHAT needs to be achieved.  Those things are usually determined well  before the software developers get involved.

Approach

I found that listing my knee-jerk objections to the project as a list of assumptions, with methods for  testing each assumption was very useful for documenting both “what is” and “what if”.  Evaluating the  key assumptions, in a systematic way, was very useful as the tests disproved one of my major objections  to the project.  In hindsight, I should have stopped there, rather than trying to improve on Utility that  the users requested and were used to.  My proposal didn’t “wow”, and I ended up going with “what  works”.

