Object Mapping and UX: A Conversation with Iconstorm
Object Mapping: A Tool, but no Workshop
Tim Heiler says, “By paying attention to objects, you keep the big picture in mind.” Do you see it the same way, Tim Zeidler?
Tim Z.: From a developer’s perspective, you can look at it that way. There are countless programming paradigms and one of them is object-based programming. You look at the real world, analyze what objects exist, and then try to understand how they relate to each other. I personally find this approach easier than other paradigms, such as Flow. It also helps to see the data structures behind it. I think you can really bring programming and design together with object mapping.
Object mapping is about simplifying communication within a team but also with organizations. Tim, as a developer you are caught between two worlds. How do you write down your ideas or exchange ideas with others?
Tim Z.: I am currently working on a project that involves tracking objects from the aeronautical field. I write down what makes up the satellite so that I can translate that into the database in the next step. When it comes to the technical implementation, I use UML diagrams. This variant goes more in the direction of flow. Another tool is entity-relationship diagrams. These are databases in which you can define the individual objects and exactly map the relationships to each other.
What is the key advantage of Object Mapping?
Tim H.: With Object Mapping, I describe a tool that helps us communicate better with each other. In the design process, I have to articulate myself clearly, because I’m discussing with different stakeholders.
Tim Z.: That’s what I like object-oriented development for, because you can create different views and dive as deep as you want into the topic. With flows you always have the same view, but a decision maker doesn’t always want to see all the intermediate steps or clicks.
In the end, it’s always about designing technology for the human context, not the other way around.Tim Heiler
Abstraction and Dimensions: The Limits of Object Mapping
Tim Heiler, where do you think are the limits of Object Mapping?
Tim H.: It’s a great approach where a lot has to happen at the right time. The whole thing is particularly exciting in unknown terrain, where you don’t even know what objects might be involved. Object mapping shrinks the world a bit because everything is already concrete and descriptive and you’re worried about details. That’s why the right use of such a tool is important.
Tim Z.: I agree with that. The tool is relevant in the defining phase. I don’t see it in the ideation phase. You can’t freely make associations with an object based approach. I just experienced this recently in a workshop where the developers involved switched off mentally way too early.
Can you explain with an example what you mean by this?
Tim H.: For example, I describe a butterfly: it has wings, legs and colors. Then a biologist comes along and says that the butterfly was previously a larva. That throws me off track because my model no longer fits. I have no categories to describe what evolution the animal goes through. It’s a contraction and reduction of the categories.
Tim Z.: In IT, we call this mutability. The object changes, but you have no chance to represent that. You describe current states, nothing more. In practice, we had once built state charts to represent temporal processes. But at the moment we mainly design things in two dimensions using the prototyping tools Figma, Sketch or Framer; we don’t have tools for a multi-dimensional perspective.
Tim Z., what else is keeping you busy at the moment?
Tim Z.: I’ve been doing a lot of input-output programming lately. It works like a mathematical function: F(x)=y. Have you ever thought about whether user interactions and flows can also be represented by such functions? Can you apply something like that in design?
Tim H.: Awesome question! With this approach, you begin to understand the world as a description logic. In a world of a constructed and relatively clear IF/THEN, you develop your products accordingly in the abstract. But trying to make a human output out of a computer output is almost a philosophical issue, because in doing so you demote humans to predictable and dependent variables, and you make design for situations that are no longer human. We must always be aware that only one half of the truth is static and controllable. Only in the computer do the world and its objects have a finite set of properties. In the end, it’s always about designing technology for the human context, not the other way around.
Thank you for your time and insights!
Tim Heiler works as design director at Iconstorm. He helps groups make better decisions through structured conversations. With a focus on perception, behavior, and team psychology, he helps organizations unleash their full design potential.
+49 (0) 69 15 32 018 18
Tim Zeidler is a Creative Technologist at Iconstorm. His goal is to facilitate collaboration, make software understandable for everyone, and build excellent products.
+49 (0) 69 15 32 018 16