Function Analysis of a water bottle
Map the systems
Diagrams used to visualise systems are typically divided into two broad categories: static diagrams, which represent the state of the system at a moment in time, and dynamic or behavioural diagrams, which illustrate how the system changes over time. Function diagramming is static, so it’s critical to keep in mind. Most products do different things at different times. The function diagram is going to change depending on the product output or primary function. To identify opportunities for improvement, it’s critical to see the full picture and analyse different states of the product, looking for opportunities to make the product better. Let’s look at a simple example.
A water bottle is a tangible system with at least two components, a bottle and a cap. I think we’d all agree that its function is to hold water. The test of this assumption is a thought experiment. What would happen if the bottle vanished? In that case, we’d expect to see a puddle, so yes, the bottle is actually doing something to the water. The water would change if the bottle were removed from the system.
Simple enough, what happens when we drink out of a water bottle? Well, now its function has changed. The bottle shouldn’t be holding the water. The bottle should be channeling the water into the drinker’s mouth. Again, we can test if it’s performing that function sufficiently by measuring the flow of liquid into the mouth. If you think this is too simple of a function to focus on, think about all the effort beer companies invested in anti-glug cans. They determined that a standard can was insufficiently performing it’s a liquid channeling function.
So products are almost always multi-tools, performing different functions at different times. This is critical, and this is often the reason for innovative design features that we find in products. This is why we have twist caps on water bottles. They adapt the product between the state of holding water and the state of channeling water. This is a critical source of innovation.
Systematic product design is a method for effectively tackling the problem of creating new products. It’s based on identifying problems with existing solutions and finding ways to solve them by breaking down those problems into manageable parts. For example: if your goal is to create a new smartphone case, you’d need to identify potential problems with existing cases — such as poor battery life or an inconvenient charging port location — and come up with solutions for each one.
If a drinking container is always upright, it will look like a cup. It’s not until you have the alternative, the bottle upside down, that you have to add a cap, and then it becomes a more complex product.
The need to toggle between holding liquid and channeling liquid becomes more complex when the product is intended for a less coordinated or more curious user. Most parents have seen the huge variety of sippy cups. That variety illustrates that no one, no product developer, has conclusively solved the problem of adapting to these different functional states and performing all these functions sufficiently for a baby.
When performing function analysis, it’s critical to remember that a single diagram represents a particular state of the product in a moment in time, Don’t try to compress multiple states, it becomes too confusing. On the other hand, products have multiple states, so multiple function diagrams are required to represent all of their functions. Representing products with multiple function diagrams reveals opportunities for improvement and reveals opportunities for innovation, even for simple products, as we can see in the design of sippy cups.
The best diagrams work as models or surrogates for a real world product or system, which may or may not exist yet. Creating a diagram that will work as a surrogate requires careful and accurate representation and mapping. Different types of diagrams use the nodes and the relationships between the nodes to represent different things, which can lead to confusion about how to interpret the diagram, undermining its usefulness as a surrogate. Function analysis typically uses the nodes in a diagram to represent components or parts within the system. And the connections between those nodes represent functional relationships
In a functional diagram, the nodes are things, physical objects, or at least nouns. In a physical product, you should actually be able to touch the nodes. They should be things you can hold in your hands. You should include a node in the diagram if it’s necessary for the primary system function. So, once you’ve determined that primary system function you track back through the branching functional relationships, adding nodes as needed to the diagram. There are certainly instances where there are components in a product that in a particular circumstance or scenario have no functional contribution to the primary system output.
Looking at this simple example of a water bottle, what is the primary function? Well, we agree that the primary function of the bottle is to hold water, what are the components? We see a cap, a bottle and water. Typically we would not include water within the system, because we don’t have control over it. We can’t change the water. The actual function of the system is to hold the water. So the water would be considered outside of the system boundary. The relationships in a functional diagram are verbs actions. They’re the things that different components within the system do to other components. A functional relationship is usually a physical interaction between touching components. Relationship is functional if the target component would be in a different state if the acting component is removed. And this is a thought experiment you can use to test whether there is actually a functional relationship between two components. So if we look again at the water bottle, we have a water bottle and a cap within the system.
And we have a hand holding the water bottle. The overall water bottle system is holding water. So we’re representing that as a blue arrow. Most of the time, we have two functional relationships. We have a hand holding the water bottle and the water bottle holding the water, and we can use our thought experiment to test these functions. If we remove the hand, the bottle falls, if we remove the bottle, the water falls. So these functional relationships are actively participating in the primary function of the system. And in this scenario, the cap really isn’t doing anything. The water bottle is functioning just like a cup or a mug. It’s not until we turn the water bottle over that we activate the cap as a component in the system. Now the hand holds the water bottle, the water bottle holds the cap and the cap holds the water.
So let’s expand on this a little bit and look at how we can track these functional relationships in a broader functional system. So what if the purpose of our system is to hydrate, not merely to hold water. The system needs to get water into a human being. What are the components? So we can look at the image. We see that we have the bottle, the hand holding the bottle, the arm holding the hand. We have a digestive track, which actually needs to ingest or distribute the water throughout the body. We have a mouth channeling the water from the bottle into the body, and a neck, and a torso.
So these are all the things we see in the system that likely have functional relationships in order to get that water throughout the drinkers body. So if we look at how we would diagram this out, we start with the primary output or function. So we have the water and we know that the water needs to be distributed into the body itself. So, the mouth is channeling the water into the body and the bottle is holding the water. And we can see immediately something must be holding the bottle, or it would fall to the ground. Something must be supporting the mouth, or it would fall to the ground. And something has to be distributing the water throughout the body from the mouth. So we have more components we need to add to our system. So let’s think first about the bottle. So the hand is holding the bottle and the arm is supporting the hand. The neck is channeling the water along with the mouth into the body, and the neck is holding or supporting the mouth. The digestive tract is actually absorbing and distributing the water. And we could go into more detail.
The digestive tract is a complex system in and of itself, but for the purposes of this analysis, we’re treating the digestive tract as a single component within our system. And that’s not unusual. It’s often that single components within a system analysis actually represent smaller subsystems. And this is the hierarchy that we see in the real world where systems are nested within other systems. The torso of the drinker, right? Is supporting all of the other body part components. So the torso supports the arms, supports the neck and holds the digestive tract.
And this is important if we’re thinking about this from the perspective of a sports nutritionist. There might be something constricting the torso making it insufficiently holding the digestive tract or insufficiently supporting one of the arms. And finally, we’re going to support the torso with the legs. And this is a component outside of the system. Wrapping up the system by showing the input, supporting all of the components within the system boundary. So to reiterate the nodes or components in the system are things. In a physical product, these should be things you can hold and touch. You include the nodes if it’s necessary for the primary system function. The relationships on the other hand are verbs. They’re the actions, they’re connections between the components. A functional relationship is a physical interaction in a physical product. And a relationship is only functional if the target component would be in a different state, if the acting component is removed. So if you have a relationship where the target component would not be different, if the acting component were removed from the system, then you don’t really have a functional relationship. For simple products, like a water bottle. It’s easy to identify the components and functional relationships. But as systems become more complex, it gets more challenging. Consistency is the key. If you use a simple set of rules to identify the components and the functional relationships between the components, you’ll produce useful diagrams that actually reveal new insights into the function of the product.
