The lines between code and culture

In which I have no original thoughts of my own and just summarize a book I read a while ago.

It’s easy to get sucked into the industry you work in, to go down the rabbit hole of best practices, technical requirements, and boundless opinions. But part of being a designer is recognizing the context in which your problem exists. A designer cannot work in a silo. Neither can your design.

As Finnish architect Eliel Saarinen said:

“Always design a thing by considering it in its next larger context: a chair in a room, a room in a house, a house in an environment, an environment in a city plan.”

So it was refreshing to read Intertwingled by Peter Morville, who basically wrote the book on Information Architecture, and realize it wasn’t really a book on design at all. At least not in the traditional sense. There are no methodologies, no tricks of the trade, and no tutorials. It’s really a book about society, how design is linked to culture, and how the things we make affect, and are affected by, much larger forces around us. And it would behoove us to take notice.

You can be the most talented designer in the world, but if you cannot see how culture shapes the outcome of your output, positive change may be difficult to achieve.

It’s not you, it’s the system

We dove head first into user experience without capturing the hearts and minds of stakeholders. We think we’re making software, websites, and experiences, but we’re not. We are agents of change within complex adaptive systems. Until we accept this mission, we will forever repeat our mistakes. It’s time to go deep and shine a bright light, since we’re all in this together.

Design involves a lot more than just pixel-pushing. We know that, but what does that really mean? Why do we need those pixels to look that way in the first place? This is where research comes into play. We need to understand what we’re dealing with here. We need to understand why we’re doing this. A design never exists in a vacuum. When we understand the situation, then we know what we should be communicating, and to whom. Design requires more than just ideas. It requires buy-in.

C’est non pas un’App

Let’s talk about apps. While I won’t go as far as Magritte when it comes to courting controversy, I will say this: your app is not an app.

A lot of the time, apps are referred to as products. Designers are called product designers. And it’s true. To a certain extent, apps are products, and it’s a convenient shorthand for a category of software that remains largely difficult to define.

But let’s zoom out a little bit.

Morville writes:

Mobile apps aren’t products. They are service avatars that link users into business ecosystems.

Usually, an app is not a stand-alone product. This is why it’s so important to understand the people, the stakeholders, that are connected and plugged into this system. There are always complex relationships at play that will influence how the app fits into the overarching business. Not recognizing these internal politics can seriously derail any project, no matter how robustly designed and developed an app is.

And yes, users are stakeholders too. Having a UX designer on the team is a statement saying that you understand that your users have a stake in the app as well. The design process inevitably involves uncovering the app’s connections to people both inside and outside of the organization that is producing it.

It also involves seeing the app in its context and mapping that context accordingly, both the app’s context within the business ecosystem, and the context of the app within a person’s life. We can’t even begin to get hung up on usability when we haven’t yet figured out the pathways from the app to the service it’s providing. The success of an app rests on much more than a button’s placement or a type treatment. These things definitely do matter, but only after we’re settled on how the app plays into the ecosystem.

Information isn’t enough

Information is not enough. We should map the hidden pathways of our ecosystems, but then we must act. We must embrace divergent ways of changing what we want and what we do. An awareness of the entangled nature of systems is essential, but it’s equally vital to have the right attitude.

Yes, of course, designers must conduct research, examine the world around what they’re designing, and represent this information visually, through site maps or flows or other methods of data visualization. But that’s just one part of the equation. Awareness is crucial, but not enough. Research must be acted upon. Research is merely the spark that should set off a thousand ideas, actions, and creations.

We should use our categories and connections to reveal the hidden assumptions of culture; and sketch links and loops to explore the latent potential of systems; and realize mental models by drawing them outside our heads. By making the invisible visible, we can shift the context of vision and decision, but helping people to see differently is a skill we don’t use enough. We focus on users but ignore stakeholders. We put experience before understanding.

Sketching maps, flows, and systems makes the intangible tangible and assigns physicality to meaning. This serves two purposes: it helps the sketcher understand the problem better, and it also communicates ideas to other people besides the sketcher. One is internal; the other is external. So often, we as designers focus on the first part but not the second part. A designer who deeply understands the system in which she is designing is extremely valuable, but only if she can then communicate that understanding to others. That is where change happens.

“To get better at getting better, we must see there are no limits. We draw edges that don’t exist. This isn’t bad but dangerous, and it makes us uncomfortable. That’s okay. We must learn to sit with our discomfort.”

There’s no point where the design ends and the business begins. It’s all connected. We’re all operating within the same world.

So let’s get uncomfortable.