2013 Main Conference Talk
How do you explain what you do to others? Can you tell when you’re looking at a “good” information architecture versus a “bad” one? Do you know how (or even if) your work adds value to the world?
IAs have great tools and techniques to design information spaces, and various means to convey these designs. However, we have scant frameworks for understanding, explaining, and critiquing our work. Is it good or bad? Do others “get” it? Does it serve user needs? Does it add value?
This session will present a framework for thinking and making value judgments about IA. We’ll also venture briefly onto the minefield of ethics.
About the speaker(s)
Jorge Arango is an information architecture and strategic designer based in the San Francisco Bay Area. He’s the author of Living in Information: Responsible Design for Digital Places (Two Waves Publishing, 2018) and co-author of Information Architecture: For the Web and Beyond (O’Reilly, 2015). In addition to his consulting practice, he also teaches in the interaction design program at the California College of the Arts.
Jorge Arango: Thank you for giving me the opportunity of talking to you this morning about information architecture. I’m Jorge, and you’re here at 9 AM on a Saturday morning, which I’m very thankful for.
I’m going to start with the old trope that everyone uses of asking for a show of hands. I would like you to raise your hands if you’re feeling a little bit apprehensive about being here at 9 AM in the morning for a talk that has the phrase “unified theory” in the subtitle.
Jorge: Show of hands? Yeah?
Yesterday, in the keynote presentation, Mr. Jenson showed a quote from Alan Kay that says that perspective is worth 80 IQ points. I guess I’d like you to think less of the phrase “unified theory” in the titlettes, I would like for you to think of this as a lens through which we can look at information architecture and hopefully try to look at it from other ways.
The reason that I’ve been working on crafting this lens for myself is that I’ve been facing three problems in my career. The first problem is that, as I’ve been moving up into becoming more of a manager of other designers, I’ve been facing challenges in trying to externalize my thinking around how do we talk about information architecture and how do we discuss architectural solutions. Not just the what, do we do, but also the whys and the hows.
We have lots of conferences and websites and books and stuff on how to do wire frames and process maps and all of these things, but we don’t have very many tools to talk about the underlying decision making that goes into this, it seems to me.
The second problem is related to the first, and that is that I’ve been looking for ways of having conversations with my team about what constitutes a good and a bad architectural decision.
The problem is that I think many people, including people that have been brought up within our field, have a fuzzy idea of where information architecture stands, it starts and where it ends. Discussions can quickly devolve into talking about things that are really kind of outside of the purview of what I consider to be architectural. I’d like to focus those conversations on the things that are kind of broader under the structural.
The third problem is that I believe we haven’t yet found a way of clearly communicating the value that IA can deliver to stakeholders and to ourselves. But we’ve been having some conversations this weekend that kind of point in that direction.
I’d like to try to address these points in this presentation. I’ll give the disclaimer right off the bat that a lot of this thinking is very embryonic, it may come across as a little raw and maybe even soft headed. I really welcome your feedback; will help see if it’s a direction worth going in and just making it firmer.
The presentation is structured in three parts. In the first part, I will introduce the concept of links and nodes. This is the reduced set of elements that I will use to discuss architectural solutions. This will be the what, part of the presentation.
In the second part, I will talk about order, which is the way in which we combine these elements to solve problems in information architecture. This will be the how part of the presentation.
In the third part, I will introduce a framework for making value judgments about architectural solutions. This will be the why part of the presentation, why we do what we do and why it’s important.
Let’s jump right to it.
In order to dig into the topic, I must first tell you a little bit about architecture. If you’ve heard me talk before, you know that I’m always talking about the relationship between architecture and information architecture.
This is for two reasons. This first is that I was trained as an architect, so I kind of tend to look at the world through an architect’s eyes. But more importantly, because of knowing architecture, I know that that’s a field that has been solving some pretty complex structural problems around how we experience spaces for a very long time. Many of the problems that they’re facing seem to me to be very similar to the problems that we’re facing here. I think it’s a field that we can learn from.
There’s a big, very important difference between architecture and information architecture, and that’s that architects are concerned with making spaces that we inhabit, whereas, information architects are making spaces for us to understand things. They’re not the same types of spaces, but they’re spaces, nevertheless.
Architects have developed patterns, tools, techniques and vocabularies to help them create structures that elicit particular experiences from the people that inhabit them. Architecture can be ennobling. It can invite you to contemplate your relationship to the outside world or invite you to meditate inwardly on the misery of it all.
It can bring relief and order to a chaotic urban environment, or attempt to disorient us, even in intimate spaces. It can be informal and expressive of human interactions, or it can attempt to introduce order and structure into those interactions.
It can raise our eyes and hearts to the heavens or invite us to play it close to the ground, even in the same building. It can express mass and weight or fool us into thinking that it’s weightless and that it takes no effort.
It can be welcoming and intimate or formal, severe and grandiose. It can tell stories about the ways that we lived in the past and evolve its forms for new uses in the present.
There is incredible variety in the types of experiences that can be created with architecture. However, everything that makes up architectural solutions can be boiled down to the interplay of just two elements, form and space.
Let’s examine them for a second here. Form is everything tangible. It’s the walls, the floors, the ceilings, rocks, rose bushes, all the things that kind of define the world.
A form can be as simple as a point. You’re going to extrude the point, then one dimension to make a line, and two dimensions to make a plane and three dimensions to make volume.
There are a series of forms called primitives that you may recall from your childhood games. They have a very simple geometry and most forms in the world are much more complex than these. Forms can have parts taken from them to create openings and chamfers, or they can have other forms kind of glommed onto them to make more complex aggregates of forms.
I’ve been showing you abstract drawings to present these things, but in the real world, forms are not perfect and homogeneous. They’re built up of combinations of other forms.
For example, a brick wall is made from aggregating these lower forms, the bricks, in a pattern and then glomming them together with mortar to make a wall. There’s also wood and other elements that come into play there.
Bricks, too, are forms. Dan has talked in his presentations about the relationship between bricks. Bricks are forms and they’re, by definition, simpler and more flexible than the walls that they make up. Because once you have a wall, it’s that formed shape. But bricks, by the very nature of their modularity, can make many different types of forms.
The point is that these simple volumes of clay can be stacked together to make walls, which together can create buildings, which together can create building complexes, which can create cities and which add up to the entirety of the built environment.
Let’s talk about space now. The space is the void between forms. It’s where we experience and inhabit architecture. It’s where we move about.
When it comes to architecture, the boundaries of space are defined by forms. Take this building, for example. This is the Pantheon in Rome, and it’s one of the most famous buildings of the Roman Era. When you’re inside the Pantheon, you experience it as the joining of a sphere and a drum. That’s like the space that you experience when you’re inside of it.
But the sphere and the drum aren’t really there, in a sense. They’re revealed to us by the shapes of the walls and the vaulted ceiling above us. Our minds experience some kind of void, the negative void that they created, and the emptiness that they leave behind.
Space can also be experienced outside of buildings. Buildings are forms, too. When you place them in relationship to each other and with things like the plane of the ground, you start giving people a sense of this being a particular space that they can somehow inhabit, and which is different from the other spaces outside of this complex.
When architects design a building or an urban complex, they are as concerned about the spaces they create as they are about the forms that define them. You really can’t have one without the other.
To recap, forms can contain other forms, which can, in turn, contain other forms, adding up to extraordinarily complex and pervasive environments. We experience the differences in form and architecture itself through the spaces that separate them.
Everyone with me thus far? Yeah?
You may be wondering what this has to do with information architecture. I want to suggest to you that we, too, deal with two basic elements that are our equivalents of form and space. They are nodes and links, and we’re going to examine them now.
Nodes are discrete units of meaning. They are to information architecture what forms are to architecture. They’re the basic building block. But they’re also the walls and the buildings themselves.
For example, look at this quote. The words and sentences that make it up are nodes of individual meanings strung together to convey a particular message to your mind. The paragraph is composed of two sentences.
If you take away that second sentence, an important part of the meaning is lost, right? If you take away the first sentence, we’re in real trouble, I mean, you have no way of understanding what we’re talking about. It really makes the most sense as a whole.
What about the attribution? If you take away the attribution, you take away much of the authoritativeness of the statement. It’s an important part of the quote, as well. That’s what I mean by this being a discrete unit of meaning. It really makes the most sense as a whole thing. What about the image right next to the quote? That, too, is a node. It’s a discrete unit of meaning in and of itself. I selected this particular image because I wanted to remind you that Plato lived a long time ago, and he was important enough to have a marble bust of him made and put in a museum.
I could have gone in a completely different direction…
Jorge: … but that would have sent your mind careening off somewhere that I wouldn’t want it to be, except for like humor and comic relief, here.
This library really consists of two nodes joined together to convey a particular meaning with a particular tone. But they’re also one single node, which happens to be a presentation slide, one node in the sequence of nodes that makes up my presentation. The point is that, as we break some walls, nodes can contain, and are made up of, other nodes.
Now let’s talk about links. I’ll be frank with you. I struggled a little bit with this word, because I’m afraid that it triggers associations in the minds of our community, because we have a particular meaning attached to this word. I’d like for you to put that meaning aside for a moment and consider the broader and simpler meaning of the word “link.”
It’s a connection or bond between two things. Links are to information architecture what spaces are to architecture. They define the relationships between nodes, and they are defined by the relationships between nodes. They are where we experience information architecture.
There are many types of links. The most obvious one is the one that you’ve already thought about, the hyperlink. A hyperlink is a relationship in time between two nodes in a hypertext system. When you click or tap on the first node, it’s replaced in your viewport by the node that the link points to.
It’s worth noting that these two nodes are not at the same level of hierarchy with relation to each other. Their link node is contained within a page, but the node that it points to is a page itself. I have some trouble with this when I’m having critiques, and stuff like that, because we tend to draw these relationships as a box and another box. They’re not acknowledging this difference in hierarchy.
Another type of link is the spacial relationship. Let’s revisit Plato here. The relationship between these two nodes is defined in space, rendered right here in the flat surface of the screen. Your eyes and brain perceive a relationship between them because they’re close to each other and because the screen has a very clear boundary, and I’ve chosen to put them there.
I can play around with the sizes, positions, and shapes, conveying different meanings.
Jorge: If you see this painting for the first time without having seen the Mona Lisa first, it might strike you as odd, like a painting of a lady with a moustache. But if you’ve seen the Mona Lisa before, it suddenly means something else. There exists a link between “L.H.O.O.Q.” and the Mona Lisa, but that link isn’t out here in the world. That link is actually in your mind, your experience, and your memory.
I think that we deal with more of this type of link in our work than we’re normally aware of, because we’re concerned with putting stuff down in wireframes and in drawing arrows between. There are other types of links, but we don’t have time to go into them today. The important thing to keep in mind is that links define the relationships between nodes, and that there are many types of such relationships.
As with form and space, nodes and links function as an ensemble. You can’t have one without the other. Also as with form and space, information environments are composed of node/link ensembles that can be mapped out in a hierarchy that ranges from individual words all the way up to the entire collection of human intellectual output.
Is everyone with me thus far? Yeah? We will now move on to the second part of the presentation, where I’m going to talk a little bit about how these things can be organized to solve problems. Nodes and links are just thrown together for the hell of it. For meaning to be effectively conveyed, they must be ordered in very specific ways.
I recognize that order is a word that makes some people a little uncomfortable, because it speaks to authoritarianism, or something like that, but I’m convinced that a particular order is exactly what we’re trying to achieve with our architectural design, so I think we may as well embrace it.
As we did with links and nodes, we’re going to start by looking at order in architecture, and then move on to order as it applies to IA. Let’s look back at the form/space hierarchy diagram here. When we talk about architectural solutions, we’re usually concerned with design problems that are focused in the middle layers of the diagram, so understanding the materials is very important for us, but that’s not usually where we’re arranging forms and spaces.
To give you an example, when I studied architecture, we were taught to use an arc welder, and we were taught to mix concrete, lay bricks, and stuff, but our professors weren’t expecting that we’d go out into the world and become building contractors. They were teaching us these things so that we’d know what we can do with these things, so that we then understand them as a vocabulary to deploy forms and spaces at the wall level.
The ordering principles that I’m going to be covering here have to do with solutions that sit in these middle three layers. We don’t usually talk about the stuff that is at the construction, physical level. Let’s look at some of the ordering principles. An axis is an imaginary line established by two points in space. It’s used by architects to emphasize formality and grandeur.
If you visited the National Mall, in Washington, D.C., you’ve experienced the power of being in a space that is defined by axis. Symmetry is achieved when you have balanced arrangements of forms and spaces on both sides of an axial line, or an axial plane. Humans like balance. Symmetry implies power and formality, and this is why it’s used over and over for public buildings.
Hierarchy is the tool that architects use to convey the reality that some things are more important than others. It’s no coincidence that the Capitol building is set on a little hill in a very prominent part of town. That’s sending a message to people. Datum is a less well known principle, but I think it’s very important. It’s when architectural compositions play off a line, plane, or volume that serves as a reference to the whole.
In Washington, D.C., there is a law that limits the height of buildings in the center of town, and the shape of the downtown area in Washington is highly influenced by that imaginary plane. There are some buildings that exceed it, but they do so for a purpose. I think the Washington Monument is taller than that, and that’s meant to convey something. Rhythm and repetition are patterns of forms and spaces set on regular or irregular intervals. Our eyes and minds interpret them as planes, but as planes that aren’t barriers. They’re porous planes that we can walk through.
They help us transition from the outside to the inside of a building. They also help break up monotony and introduce interest and scale to buildings. Architecture is a field that is in constant dialogue with itself. New compositions of forms and spaces play off those that came in the past. Architects can choose to suggest continuity and comfort or they can make radical statements that break with precedent.
They do this consciously, the reinterpretation of these patterns. Many of these same organizational principles can be perceived in our work. Let’s take a work at Twitter, here. It too, shows a certain balance in the way that nodes are laid out. It also has a certain degree of hierarchy. When you go into Twitter, it’s pretty clear to you that you’re mentally paying attention to the stuff happening on the right column, just because of the slightly bigger size, the fact that it keeps going on, etc.
Twitter also employs datums. There is a header that remains pinned to the top of the viewport throughout your visit. The content area is constrained within a box, for historical reasons, perhaps. But it’s constrained. It doesn’t go up to the edges of the viewport. You see that users sometimes play with this data, to change the meaning of what the space conveys. Twitter also has a very clear rhythm, achieved by a never-ending repetition of these little node clusters, that define a Twitter experience.
You all laughed when I showed the Plato quote reconfigured. Because I think you recognize this pattern. This rhythm is even more noticeable here than in architecture, because the little clusters keep coming. If you scroll down, they’re never ending. What about transformation? I think we experience it even more in our work than architects do in theirs, because first of all, our field is evolving much faster.
Second of all, we’re dealing with this proliferation of different ways of accessing this information, so different devices, screen sizes, etc. We’re constantly being called on to have this dialogue with our own work, where we’re reinterpreting it and trying to adapt it to different contexts. We make cautious decisions about how node link groupings are transformed to suit the requirements of different channels.
At this point, you may be thinking, “He’s talking about page layout, which is visual and therefore easy to map out against these principles and stuff.” However I believe that we can also spot these organizing principles in the broader structures of these experiences. Let’s look at the rest of Twitter. Twitter has information spaces that are public and some that are less so. Andrew has gone into, in some of these presentations.
There are four main spaces in the Twitter experience, which are highlighted in the main navigation bar. These nodes share the same organizing principles as the home page. They’re basically a stream of tweets. The main difference between them is the subset of the entire Twitter-sphere that they show you. For example, the home page shows you the tweets of people you’re following. That’s a subset of the entire Twitter-sphere.
The Discover page shows you a subset of tweets that Twitter may think is particularly interesting to you at the moment. The decision of choosing which subset to show you is an architectural decision, I believe. The fact that they all employ the same structure makes it so that the user experiences rhythms implicit in this structure when they go from one of these pages to the other. This conveys that you’re in a public space, kind of like the columns do in one of those public buildings.
Twitter has other pages that are less public. When you’re editing your profile, that’s like going from the lobby of one of those federal buildings to going to a restroom inside the building. You’d be uncomfortable peeing among the columns.
Jorge: I’d be very anxious editing my account if this had a stream of things that looked like tweets. I’d be worried about what was happening there. These architectural decisions about the configuration of these spaces are emerging, even if they haven’t been verbalized as such. The problem is that Twitter also has another kind of private space, the direct messages that you share with another person.
Andrew has pointed out on many occasions how important it is to make this difference clear to the user. The problem is that the structure of these node clusters is the same exact structure that you have in the public spaces. You see that Twitter is trying to introduce visual differentiation between them, by placing these in a little pop-up box, as opposed to having it as a page. They’re trying to say, “Yes, this has the same structure. But it’s a more intimate space.” That’s the message they seem to be sending there.
The problem is that Twitter on the web is not the only way to access Twitter. Not all these channels are as effective in conveying the difference between these spaces. This is the same stuff, the direct messages, in Twitterific and Tweetbot in iOS and, Twitter’s own Android client. They look exactly like the home, dissever, like the public spaces. Twitterific makes them blue, to try to say, “This is something else.”
But it’s not different enough. I’ve screwed up trying to send a direct message to someone. The problem here is that these spatial differences are implicit in Twitter and they haven’t been consciously structured for spatial differentiation. The designers of each individual app are on their own when trying to convey the fact that you’ve moved to a different space. Before moving on, I want to point out that information architects have been using these principles of nodes and links to communicate meaning through structured collections, well before there was a worldwide web.
This is Mr. Wurman’s map of the Tokyo subway system. With our lens on, you can see that it’s composed of these node clusters, in this case organized in a rhythmic radial pattern. Like Twitter, it has a beat to it. The composition is balanced and symmetrical. The green and red lines serve as datums, so that you know what you’re looking at and their relationship to each other. It also has hierarchies.
The imperial palace here in the middle is an exception to the composition. That gives it prominence, your eye gravitates to it. In this case, that’s to give you a reference as to where these things sit, in relation to the real city. As with architecture, we can and we should apply different ordering principles, depending on the level of the hierarchy that we’re working at. To give you an example of what I mean…
If we’re looking at a design problem that has to do with organizing a sequence of node clusters in a list, we’d be well-served looking at something like Mr. Werman’s latch model. Which is meant to organize node structures at that level [laughs] . Carefully chosen, on the other hand, if your project calls for the high level design of an ecosystem of information node clusters that must interaction with other information systems, you would be better served looking at ordering principles for things that exist at a higher level.
For example, there’s a set of ordering principles behind the World Wide Web itself. These are more appropriate to that level of the hierarchy than Mr. Werman’s latch model, for solving that kind of problem. The point is that different levels in the hierarchy call for different approaches. As information architects, we need to be aware of the differences between them, even if we are not going to be the people who are laying the bricks.
When critiquing a work of information architecture, it is especially important that we know and consciously drive the conversation toward the appropriate level in the hierarchy. So that we’re not critiquing something that is an ecosystem-level decision when we’re talking about very low level decisions about the ordering of things. One of the challenges for us is that, in information architecture, it’s not as easy to tell the difference between a brick and a wall.
Sometimes the two things are conflated. We need to work harder at understanding what level of the hierarchy we’re talking about. Now I’m going to talk about value. I’m going to talk about values. I’m hoping to convince you that the two things are related. You may be wondering, what does value have to do with anything that I’ve been talking about thus far? As I mentioned at the beginning of the presentation, part of the problem I’m struggling with is that I’ve been having a hard time conveying to others what the value is that we bring to our work.
At the moment I feel that we are a feel that has a bit of a PR problem. Part of it has to do with the fact that it’s hard to point to what the IA of something is. To change around the Radiohead song, just because you don’t see it, doesn’t mean it’s not there. This is happening while we’re busy moving many of our day to day interactions from happening in build spaces to happening in these information spaces.
Things like banking and shopping and education and entertainment and all these things are increasingly moving in this direction and we don’t have the IA thing in there. Additionally, as other presenters have been explaining, more and more of this information is moving out beyond our screens, and out to the broader environment. Like I said, I think we’re starting to see evidence that there’s an important piece missing in these complex design problems.
The missing piece is the common structural definition that brings consistency and meaning to projects. This is the stuff that Andrew was covering in his presentation yesterday. You all attended that. Take, for example, iTunes. This is arguably one of the most important software products of the past decade. It started out as a simple music player. But is has been evolving into something a lot more complex as it takes on more responsibilities within Apple’s ecosystem.
The problem is that, instead of trying to tackle the increased complexity, the app has remained fundamentally the same. The way that the node link structures have been grouped, have remained very similar to what it was 10 years ago. It you all have used the latest release, it seems to me that the designers are at a point where they’ve just thrown their arms up in the air and have started crippling it.
At this point, for someone like me, that has a lot of music, it’s really difficult to navigate my library. It’s like trying to make it simpler to understand, but by removing power from the end user. The problem with iTunes, I believe, is that it’s a node link structure that is being pushed to take on responsibilities higher and higher up in the hierarchy, seemingly without going through the process of reanalyzing the change requirements that come with a broader context.
All successful information products or services will sooner or later make such an advance toward becoming an ecosystem, at which point their semantic structures must be reconsidered. This is a space where information architects can add particular value. As I mentioned, at the beginning of the talk, I think it would help for us to look at architecture for hints on how to tackle this, because they’ve been doing this for centuries.
You start with a small group of buildings that ends up being a city. These are complex design challenges. They’re not new to us, as a species. With that in mind, I wanted to share with you one such framework that comes from architecture. This framework was developed in the 1960s, by an architect called Christopher Alexander. If his name rings a bell, it’s probably because you’ve seen this book, A Pattern Language, which has been tremendously influential.
It’s the book that introduced the concept of pattern languages in design. Before writing A Pattern Language, he wrote another book called Notes on the Synthesis of Form, in which he explained the framework that led to the formulation on the pattern language. In this book, he defined the process of design as inventing things which display new order organization form in response to function. He noted that with the accelerating contextual change that characterizes our time, more and more problems are reaching insoluble levels of complexity.
This was in the 1960s. This was pre-the challenges that we’re facing. He wanted to find a way of making these complex design challenges more manageable. The objective of the framework that he came up with is to achieve what he called “good fit” between requirements, what he calls “context,” and design solutions, what he calls “forms.” It does this by breaking down the requirements into subsets that can be formally represented and independently resolved.
A simple design problem may have very few requirements. You can map out the requirements and the relationships between them so that you can understand how some requirements work together to help solve the problem and others are in conflict. Changing the form to solve for one of the requirements may throw other requirements out of whack. It’s an adjustment process. When we understand the requirement set, we can begin to produce a design solution.
The architect’s value in the process is not just being able to propose a solution, but helping define and subdivide this set of requirements. Mr. Alexander claims that we have been going about this in three different modalities. The first modality is employed in simple projects and traditional societies. The people who make the forms are the same ones who will be using and adapting them. Think of a thatched hut.
If it starts raining, the person goes out and patches it up. If they need to add something, they just go out and add to it. This is not so much a design process as just deploying construction patterns that have evolved over time. Their fitness to their context has to do with the fact that they’ve gone through this process of iteration over time, to come up with the form that is most suited for that particular environment.
More complex design challenges require that the designer develop an internal mental picture of the requirement set. It’s not as obvious, I hope. There’s rain coming through the roof. These are more complex requirement sets. The designer, in this case, starts mapping it out. But it happens in their mind. He also adds, by the way, other valuables into the mix. There are all these requirements about narrative and about the designer’s own personal design vocabulary that are fed into the requirement set.
This is how most architecture is done. I think it’s also where we see the issues that we have here with the phrase, “genius design.” Because we’re internalizing all this stuff and trying to make sense of it in our minds. Past a certain level of complexity, even geniuses cannot tackle projects using only internal processes. There comes a point where the requirement set is so complex that, if you inset on keeping it all in your mind, you’re going to drop requirements and perhaps you’re going to drop important requirements.
That’s what he was trying to get at. This is where Mr. Alexander’s modality, the third modality, comes in. It consists of breaking the requirements down into subsets that create a clear picture that can be evaluated for fitness. During the program or requirements analysis phase, the designer must group requirement variables into logical sets that can be resolved independently. This grouping varies from project to project and can be up to the designer’s criteria.
Although some people are even using algorithms to arrive at this subdivision of the requirements, the smaller sets are then resolved independently and capture in diagrams. These individual diagrams are then folded back up into higher level sets. Ultimately leading to an overall, formal design solution. This is done through something called a constructive diagram. A constructive diagram is a representation of the requirement that is so rich that it starts suggesting the form of the solution itself.
To give you an example of this, imagine that a design challenge calls for two streets to be widened at an intersection and among the requirements you’re given data on the traffic patterns at that intersection. So you’re given a spreadsheet that says, “There are so many cars going in this direction. There are so many cars going in that other direction.” The spreadsheet is part of the requirements.
But the spreadsheet itself doesn’t convey the information in any way that starts suggesting the solution itself. It’s just a list of numbers. But if you start drawing that data as a diagram that shows arrows pointing the direction that the cars are going in and start rendering the arrows wider for roads that have more traffic, it immediately starts suggesting the shape that the intersection should take. That’s why this is a constructive diagram.
It’s an expression of the requirements, but it’s an expression that is so rich it starts suggesting the solution. These constructive diagrams can be joined to form solutions to the broader design problem. This allows designers to solve some very complex requirement sets. This is from an example in the book. It’s a case study on a design for the layout of a village in rural India. It’s for the design of a town.
One of the challenges for this methodology for making buildings, towns and stuff like that, is that architects have to translate these things into real buildings that you can walk into. No one can inhabit a drawing. These things are still very abstract. We, on the other hand, tend to deal with diagrams that are much close to the final built thing. For us, in many ways, the map is the territory. Or it ends up being very close to the territory that we’re trying to describe.
These are much closer to node link structures than Alexander’s diagrams are to form space structures. So as a result, I believe this framework is particularly useful for us, in our field. Again, the objective is helping resolve design problems at increasingly higher levels of the node link hierarchy that span multiple channels while maintaining semantic coherence. That’s what we’re trying to arrive at.
I will leave you with one final point. It’s that, for our work to be truly valuable, it should result in end products that are understandable and that enable people to understand each other. We’re heading towards a world in which we are immersed in these pervasive information spaces most of the time. The absence of these structures of meaning in such a world is more than a little scary, at least it is to me. Because, it can lend itself to incredible confusions and privacy issues and non sequiturs and stuff like that.
As far as I know, information architecture is the only field that is particularly focused on the structural integrity of meaning. We should be actively promoting its inclusion and prioritization in requirement sets, when we’re working with clients. I want to encourage you to take a proactive stance to not only try to do this in your work, but also to help raise awareness of the importance of IA itself as a part of a solution to these complex design challenges.
That’s what I have for you. Thank you very much for your time.
Jorge: I’ve been asked to tell you that the first person to ask a question that is relevant will get a book. You get a book.
Audience Member: I was particularly interested in your comment about, in architecture school, how they had you work with mortar and bricks. I would like to know your thoughts on IA’s coding. I find that’s really important, in my work, to understand how the code works and to at least work, at a cursory level, with code and to have that understanding. I’m wondering how you apply that to your current work or if you do?
Jorge: I guess I have a view on this that is not universal and probably not popular. But I tend to agree with you. I think that anyone who is working in any kind of medium needs to understand the medium. The problem in this space is that the medium is very complicated and calls for a very wide variety of inputs. So yes, knowing code is important, but it’s also important to know semiotics. It’s important to know design and all these… People need to understand how databases are structured.
These are hard things to get in one person, which is why they keep talking about unicorns. But that doesn’t mean it’s not necessary. Again, the Radiohead song, it doesn’t mean it’s not necessary. I agree with you.
Audience Member: I think you’re right. There’s few folks who have all of these sort of areas. But that’s also just an important consideration for teams, to make sure that you have people working in very close proximity with these skill sets, and not that they’re passing projects along at various stages. So design doesn’t go to development. Doesn’t go to marketing, whatever. That we all understand how this works, that the taxonomist is working with the folks who are setting up the database itself, that these folks are actually communicating.
Jorge: And let’s meet for your book.
Audience Member Hi, thanks very much. I was wondering where you’re currently getting inspiration for that problem of the complexity that’s coming and where you see the solution is starting to gather for that? That seems to be the next really big phase that’s coming down the road.
Jorge: I think I have a more clear vision of the problem than I do of the solution.
Jorge: That’s why we’re all here. But it’s a good first step to say, “We have a problem here.” What I’m trying to do is to pin down the problem. The problem, at least as I see it, is that we’ve been focusing on the manifestations of these things and the way that we access them, without understanding what the thing is that we’re trying to look at, like we were saying with Twitter. Twitter started its life as a way of sending SMS messages.
All of a sudden, we have the problem that some of it is public, some of it is private. These things were not part of the original requirement set, I don’t think. Or at least it has changed from what it originally was. That’s what we can point to and say, “We have an issue here.” Did that answer your question?
Audience Member: Thank you.
Jorge: Thank you very much.