The main theme of this blog is the relationship that product architectures (the way components relate to each other within a product) have with the way we build organizations, businesses, etc. We have argued in other posts, that this “product architecture” influences the way teams are assembled in the design and fabrication of the final product. Theories that support this claim say that our cognition divides problem-solving into boxes with the purpose of making processing easier. In that way, we create hierarchies of problems, or chunks, and work them out one by one. When we create small organizations, such as startups, we divide our teams initially according to product features or requirements. These requirements will be reflected in the component that each team element designs and will determine the relationships with other components. We make this initial problem division according to our perception of the problem itself, we look for salient features that group parts of what we perceive and try to solve it. New organizations take their initial architectures and discuss them with other stakeholders, prospective partners, collaborators, customers etc. Successful configurations are settled down in agreements that solidify relationships outside the organizations. For a long time, this process has developed industries, however up to this point, the process has been really slow and very difficult to notice. It is fair to assume that this was caused mainly by the speed of information systems. As an example, we can see the timeframe between the introduction of the first car architecture in 1769 and the first mass-produced car in 1913. Today digital technologies have accelerated the introduction of products to mass markets. Collaboration and financing platforms let entrepreneurs introduce products to markets in a couple of months with the help of DATA.
Data available to us these days does not concern only information about the product but everything measurable. With this data at hand, organizations can infer greater amounts of information from their stakeholders, especially their customers and leverage it in the creation of new products and services. This means that data is being used to inform the initial problem-solving classification we mentioned above. As a result, many intangible products, or services, are currently being adapted to our data these days. But what of tangible products? What is their relationship with data? It is obvious that data can be incorporated into the design requirements in product development. Yet, it is clear that the perception of data in problem-solving is a matter of expert interpretation and not accessible to all of us. But, what if we could make data tangible through the products we produce?
Researchers experiment with the physicalization of data to study how can we perceive it with all our senses and make a better sense of it. Compared against data visualization, physicalization uses the perceptual skills of the user. Physicalization invites the user to explore the body of data and learn through different channels that facilitate learning. Physical data facilitates engagement and makes data more accessible to the general public, including those who are differently abled. Data physicalization changes the way we incorporate data into product development, it allows us to embed information into the product rather than only influencing the initial requirements of the design process. From this point of view, data becomes a component of the product architecture. When we design a product to encode data in its form and function we can call it a data object. Since inside data objects, all the functional components have a relation with data, product designers can use existing references in the object itself to manifest data to the users. In this way, designers can embed information in the shape and scale of the product instead of just shaping it through product requirements.
In 2016-2017 I was very lucky to participate with Ricardo Sosa and a team of researchers in a project concerning data objects. Based on workshops implemented at the Auckland University of Technology’s COLAB, we wrote a research paper presented at the International Design conference 2018. In it, we explored the design of data objects and develop a set of four principles that could be used to articulate data with the function of objects. First, use data as a design material. Just as we mentioned above, data is not only a set of requirements but a component itself, that can be shaped in order to design a good and fit architecture. Second, design objects to be re-interpreted in context. Functions of objects work always in context, thus the design of a data-spoon must take advantage of the bowl and the kitchen to make data more understandable. Third, use signifiers to engage with cognition and emotion. Signifiers are features that designers insert in objects to stress an affordable function of the object. Signifiers are pretty common in everyday life, the “play” triangle in music players, the “push” sign on doors, and the USB port sign are all signifiers inserted to highlight some functions instead of others. By using signifiers in data objects we can highlight specific relationships in data. Finally, use criticality to empower users to challenge assumptions in data. Data is just a measurable snapshot of a phenomenon. The problem with data is that sometimes we behave as if it represented the totality of the phenomenon. When we measure something we usually make assumptions about the rest of what we are measuring. For example, when we measure someone’s weight, we assume that the distribution of weight in the body does not matter. Data objects can be used to question these assumptions in data and help people view it more critically. In the rest of the post, I will share my result from the original data object workshops.
Neighbours
The data objects workshop was implemented in may 2016 in a studio paper of the Bachelor of creative technologies at AUT’s COLAB. the objective was to create an object based on data from the office of national statistics on New Zealand website. The chosen dataset was a “time use” survey. A survey that describes how do people in New Zealand use their time for example, how much time they spend in school, their jobs, or with family. From this dataset, I chose to work with a very interesting statistic: spent time with others outside family and friends. This statistic is related to two ideas in creativity and innovation. First, creativity depends on the diversity of the input we give to our minds. This means that having different experiences brings unexpected inputs to our minds and memories that can be used creatively later on. A way of getting this creative input is to collaborate with people from different backgrounds than ours. Second, social groups that are less diverse tend to be less open to new ideas and preserve the status quo in their structures. This inflexibility is very important because much of our wellbeing as a society depends on social mobility. We could join these two ideas and say that social groups who spend less time with people with different backgrounds have the risk of becoming less creative and become less open to new ideas. As a result, this inflexibility can create obstacles for the progress of their well-being. Therefore, the concept of the data object became: “It is important that communities stay flexible to build new solutions for the improvement of their well-being”.
The initial concept, as shown above, brought interesting collaboration metaphors. The first designs of the data object looked for the achievement of a common goal. Proposals ranged from building some kind of volume to directing a ball to a specific objective. In the end, the best metaphor became a version of a social network. The chosen object to build this social network became a doll because it can become a representation of the user in play. A doll can become flexible or inflexible, and a sum of dolls can show how flexible or inflexible a social network of a community is. As a metaphor for cooperation, dolls would join the network by holding hands. The components of the doll gave us the chance to map this flexibility on its extremities. The data from the survey was divided into neighbourhoods. Therefore, we could create a doll that represented the flexibility of each neighbourhood where our user comes from. The doll could be used in educational environments where the council works with social mobility and diversity in communities.
As you may also know, the second most important topic in this blog is 3D printing. Thus, the implementation of the data object also shows an interesting way of using 3D printing for data objects. Making flexible products with regular PLA is possible under certain conditions. PLA plastic is normally delivered in spun up rolls of 1.75mm thick filament. when you receive the filament it is flexible enough to be pulled from the roll and feed the printer extruder while it is moving. This is usually made through a thin tube that changes position and shape continuously. This initial flexibility inspired us to think of making thin thread like geometries that together could give enough toughness and keep the body flexible. We experimented and designed several variations of these thin curves in different thicknesses and orientations. As mentioned here in another post, the orientation and size of the elements had to be adapted to the MakerBot printer we were using. The best prototype came from a 0.5mm thread that presented enough stiffness and flexibility to address our needs. Similarly, we prototyped the “hand” mechanisms that the system would use to connect doll with doll. We looked at tolerances and fittings and selected a slide in mechanism. Finally, the iterations also helped to define the doll language, FDM printers have a minimum resolution (typically 0.2mm) and specific features like detailed faces or textures cannot be printed clearly.
Using parametric design in grasshopper, we designed an algorithm that normalized the time allocation score between the two extremes of the dataset and turned it into a sine wave. Different scores had different wave amplitudes and wavelengths which gave them different flexibilities. After designing the wave, the algorithm placed the wave between the body and hand (or foot) of the doll making an extrusion with it. The body and hands were split in two in order to print all volumes with a horizontal orientation that would let the hands assemble and lock in a perpendicular way to the bending direction of the arms. Both parts can be printed and assembled with a locking system in the middle. The front of the body presents a happy face 🙂 and the back gives the user the flexibility grade with the name of the neighbourhood.
The final Neighbour doll shows the data object principles in use. First, data is used as a design material, like we said above, it is a component (if not the most important) that interacts with the product architecture. Particularly, data interacts with the arms and legs of the doll to create flexible components and with the body to show information. Second, the Neighbour’s meaning is better understood in the context of the community. We can see and play with the doll alone, but only when we introduce a second doll to compare and build a social network we can see the metaphor completely. Third, signifiers are used to highlight the body of the Neighbour and the degree of flexibility. Hands, feet, face, and body were designed to push people to see a person that articulates a social network. Fourth and final, the Neighbour does not qualify flexibility as good or bad. The activity itself must draw the users attention to the pros and cons of flexible and inflexible people. While flexible people can introduce change in the direction of the network, inflexible people are good to make that direction continuous.
This exercise was an example of how data can go beyond the definition of product design requirements and into the product architecture itself. Using data as a product component gives us the opportunity to create interesting interfaces within the rest of the architecture. Additionally, it facilitates data exploration by inviting the user to manipulate the object with every perception channel and make it more understandable.
The Firm & The Product 
Leave a Reply