How do you know which SIT tool to use on your product? That is one of the most common questions from my students and workshop participants. One way to decide is to analyze the current products in the category. You look for SIT patterns that tend to dominate how the product emerged and evolved over the years. I look at recent innovations in the category to spot trends. I also try to identify where the industry might have some “fixedness” about the products and how they are used. The type of fixedness (functional, structural, or relational) can lend insight about which SIT tool to start with.
Take light switches, for example. The first light switch was invented in 1884. The dominant design since then continues to be the “up” or “down” toggle switch. In North America, the “up” position switches the appliance to “on,” whereas in other countries such as the UK, the reverse is true. In Japan, switches are positioned sideways to prevent the switch from inadvertently being turned on or off by falling objects during an earthquake.
Many innovations have emerged over the years including dimmer switches, rockers, multi-way, and touch pad. Recent innovations reveal the use of several SIT patterns including Task Unification and Division. Yet the most dominant theme in control switching seems to be “variability.” The dimmer switch and the motion sensor switch are the most obvious examples. If you wanted to create more innovations along this theme, Attribute Dependency is the tool to use.
To use Attribute Dependency, make two lists. The first is a list of internal attributes. The second is a list of external attributes – those factors that are not under your control, but that vary in the context of how the product is used. Then create a matrix with the internal and external attributes on one axis, and the internal attributes only on the other axis. The matrix creates combinations of internal-to-internal and internal-to-external attributes that we will use to innovate. We take these virtual combinations and vidualize them in two ways. If no dependency exists between the attributes, we create one. If a dependency exists, we break it. Using Function Follows Form, we envision what the benefit or potential value might be from the new (or broken) dependency between the two attributes.
For example:
Internal Attributes:
- Type
- Number of switches
- Size
- What is controls
- Color
- Voltage
- State (on/off)
External Attributes:
- User
- Location
- Time
- Price
- Temperature
- Other appliances
- Room factors
Imagine creating a dependency between Internal Attribute 4 (what the switch controls) and External Attribute 3 (Time). The Virtual Product becomes a switch that controls different lights depending on the time of day (or time of year). For example, from midnight to noon, the switch controls a set of lights, but from noon to midnight, the switch changes and controls a different set of lights. Why would that be useful? Perhaps in situations where the person using the switch has no way of knowing what lights will come on, the switch determines it for them based on time of day. This idea breaks the functional fixedness around one switch controlling one appliance.