Article summary
More than ever, digital experiences impact the way we work, learn, and play. As these experiences become more connected, and therefore complex, it’s never been more important to design for clarity and intentionality in how we build our information.
In part one of this series, we’ll start by examining the term “information” and how it plays a crucial role in project success or failure. To do this, I’ll use the definition taken from Abby Covert’s book How to Make Sense of Any Mess. I’ll also explain why it’s important to understand this interpretation when working on software.
What is information?
We can’t talk about complexity and simplicity without first defining what we mean when we talk about “information.” Covert defines information as “whatever is conveyed or represented by a particular arrangement or sequence of things.” I like this definition when talking about software work. What is software, if not an arrangement or sequence of things?
The other important nuance in this definition is the snippet “conveyed or represented” because this is more or less the “human” part of human-centered design (HCD).
It is, in fact, the human using our software who gets to decide what it means, and what we intended to convey might not be what gets interpreted.
This is the crux of information architecture. Working toward clarity is the best way to ensure a successful piece of software. We intentionally architect information to serve different needs. And, when we work within the information layer of a project, we inform decisions about how the technical solution could/should work and how the user experience can be useful for end users.
What isn’t information?
This definition is just as important for communicating what isn’t information. Specifically, that information is not data or content, which often gets lumped into the same category. Instead, information is the message we intend to communicate with that data or content. As I’ve already mentioned, we have more data and content available to us than ever before. It’s important to understand that these things don’t actually make up the information conveyed in our software. The absence of content or data can be just as informing as the presence.
Up Next
Next, I’ll examine why we need to be clear with our definition of “simplicity” and why it’s not the same as reducing the complexity of a system.
In this Series:
- Part 1: We start by defining “information” and how it plays a crucial role in the success or failure of a project.
- Part 2: We take a look at why making something simple isn’t the same as making something less complex.
- Part 3: We explore why you can’t design away complexity, and why you might not want to.