Design

Design is a Verb

| Jorge Arango

I avoid using the word design as a noun. This keeps me from lapsing into lazy thinking about the object of my practice. 

Consider this sentence: “I like the design of the new iPhone.” Can you point to what “the design” is? What exactly do you like about it? “The design” is vague. A semantic cop out, fit for the pages of a general business publication — but not for practitioners. 

Designers need precise language that lets us assess our decision-making process. Design is a critical part of this process. It’s how the thing arrives at its form — not a characteristic of the form itself. A verb, not a noun.

Chasing Engagement

| Jorge Arango

When discussing changes to an information environment, I sometimes hear “increasing engagement” stated as one of the project objectives. By this, stakeholders mean creating conditions that encourage people to spend more time in the environment, either through longer visits or more frequent ones, hoping this will increase revenue.

I understand the desire to increase engagement. That said, in many cases, ​I don’t consider useful it as a design objective. For one thing, engagement per se doesn’t signal people are getting value from the environment. (What if they’re spending more time there because they’re lost?) For another, engagement doesn’t always correlate to increased revenue. (A notable exception is environments that monetize their visitor’s attention. It’s not uncommon for these places to employ sophisticated psychological techniques to keep people engaged, even perhaps against their best interest.)

Engagement will result naturally if the environment serves people’s needs. It’s a useful tool for understanding how they respond to our design decisions ​and not something we should pursue for its own sake.

Perpetual Prototyping

| Jorge Arango

Complex systems are not static; they’re always changing in response to changing conditions inside and outside them. They are in a continuous state of becoming; a snapshot of a system at any moment in time will quickly be out of date as the system keeps evolving.

Consider the Wikipedia. During the time it takes for your web browser to download and display a Wikipedia article, many changes have occurred to the site. New articles have been added, existing articles have changed (including, perhaps, even the article you’re downloading!), new links created between existing articles, etc. The article you’re seeing is a small snapshot of an evolving system; if you were to download the entire the Wikipedia to your computer, your copy would be obsolete by the time it finished downloading.

Complex systems ask of designers that we give up notions of control over their final form. Instead, we must adopt an attitude of perpetual prototyping: an understanding that the system we’re designing will soon move on from its initial state to other states that we are ill-equipped to predict from the start.We must develop the ability to understand this evolving system clearly: its structural configuration, the forces acting upon it, the outcomes it produces, and more. Doing so is essential if we are to act skillfully upon its structure and behavior.

Start With a Conceptual Model

| Jorge Arango

The design of an information environment should start with its conceptual model. Doing so gives the team a high-level understanding of the tasks people will do there, the elements and actions required for them to complete those tasks, the sequence they need to happen in, and — ultimately — the purpose of the environment. You can’t gain this understanding from sketching user interfaces; you must begin at a higher level.

I’ve often seen designers jump to UI design too early in the process before they have a clear grasp of the system’s conceptual model. This is understandable: models are abstractions, and abstractions are difficult to talk about. People love seeing and discussing UI; it feels like “real” progress in the project. (This is true both for designers and stakeholders.) However, starting with UI causes the team to miss the big picture, and often leads to incoherence down the line — especially as systems get more complex.

So how do you get designers and stakeholders to discuss the conceptual model without reverting to sketching UI? One approach that works for me is to ask the team to stop thinking about the thing we’re designing as software and start thinking about it as a place. How did people fulfill these tasks before digital? What kind of place should this be? What spaces does it need for people to accomplish their goals? What would people expect to find there? What do they expect to do with those things? Etc. For example, if you were designing a workforce training web application, you could start by imagining it as a physical environment (say, a school) rather than as a website. Needs and spaces could vary by user type (prospective students could have different needs than current students), by the ​degree of sociability​ required (individual study rooms versus classrooms), or by a variety of other factors.

The point is not to design a physical school; team members know the ultimate goal is to design an information environment and that they don’t need to take the analogy literally. The point is to get them to break out of thinking in terms of UI elements so they can:

  1. identify the tasks, objects, groupings, relationships, actions, etc. that will comprise the system,
  2. define the names and attributes of those things, and
  3. think through the choreography required for people to fulfill tasks in the environment.

With a solid understanding of the conceptual model, the team will be able to have discussions about the UI and how serves (or doesn’t serve) user goals. They will be able to test, iterate, and refine the UI and the conceptual model itself. But this is only feasible if they start from the conceptual model and then move to UI — it doesn’t work the other way around.

System Pliability

| Jorge Arango

Systems — including information environments — need to adapt to changing conditions. If they don’t they won’t be around for long. If your aim as a designer is to produce a resilient system (and why wouldn’t it be?), you need to consider how it will address change.

Think of an information environment where users of a family of software products solve technical problems. When you’re designing such a system, you start with a particular set of information that needs to be shown to users, a taxonomy that will affect how people find this information, and navigation structures that allow people to move around the environment.

This particular configuration won’t stay fixed for long. It will need to respond to changing conditions inside and outside the system. An example of an internal change: the company launches a new software product which requires new tech support information. An example of an external change: a new technology appears that allows for instant live screen sharing with website users.

You can design a system to be very pliable (it changes frequently and in multiple ways) or very rigid (it changes infrequently and only in a few key ways.) In the former case, the system is at risk of losing its integrity; it will respond to change by changing what it is, compromising its objectives. In the latter case, the system will preserve its identity, but risk not going far enough to accommodate changing conditions. After a while, it will be rendered obsolete. Different systems call for different balances, but I suspect most of the time you want to be somewhere in the middle.

Wherever you land on this, be certain that your system will need to address change. If you think through how it will respond, you have a much better shot at creating resilience. Here are some questions to help you think through the pliability of your system:

  • How do you know something has changed inside the system?
  • How do you know something has changed outside the system?
  • Which system parameters are open for re-consideration? (Variables vs. constants)
  • How do you ensure the integrity of the system isn’t compromised by change?
  • Who will be responsible for determining what needs to change?
  • Who will be responsible for implementing changes?
  • How frequently must evaluations happen?
  • How will this work be funded?

Conceptual Integrity

| Jorge Arango

Conceptual integrity is central to product quality.
— Fred Brooks

As the designer of an information environment, you will sometimes be called on to help define — and often, defend — its conceptual integrity. This means every element in the environment contributes to the coherence of the whole — towards a gestalt.

Complex design projects involve multiple stakeholders. Many of them will have directions which are at odds with those of other stakeholders. The marketing executive may want to feature more products on the homepage, while the executive in charge of the overall experience wants to limit how many products appear there. How do you resolve these conflicts as a designer?

To begin with, you must understand the project’s strategic objectives. This requires that you grok the objectives and context for:

  • Your customers/users
  •  Your team
  • The broader organization (e.g., your company)
  • Society as a whole

Stakeholders will be more willing to engage in generative dialog with designers who can articulate a competent understanding of the drivers behind the project. These stakeholders will then be more willing explore and test possibilities. How would the homepage function if it had more products in it? How would our users respond? Etc.

The designerly way of approaching these issues is through making and testing possibilities. But you shouldn’t waste time by iterating arbitrarily. A clear understanding of strategic intent can help give you a sense direction and help define the boundaries for these explorations.

Platforms and Environments

| Jorge Arango

Last week I had an interesting conversation with a product management researcher. I told him why I think “product” is the wrong framing for many digital things and we discussed the concept of information environments. He asked a good question: Why call them environments instead of platforms? After all, “platform” is a well-understood concept in the context of UX design.

While the two terms share a similar intent (getting designers and stakeholders to think more systemically about the work to be done), there is an important difference between them: “platform” implies a technology-centric view of the system while “environment” implies a people-centric view. A platform is something you build upon. An environment is where you have experiences. This is a key distinction as we move to make user-centered design more systemically aware.

I realize the word “environment” brings with it connotations that may court controversy. This is not unintentional. We exist within environments. They host our activities. Our long-term survival hinges on the viability of our environments. It behooves us to develop an attitude of responsible stewardship towards them — whether they are made of stuff or of information.

Buckminster Fuller’s Mission Statement

| Jorge Arango

If you’re of a certain vintage, you’ll remember how cheerful the early 1990s felt. The Berlin Wall was gone and we thought history was over. The new World Wide Web heralded a future where we’d all learn from each other, freed from eccentricities accrued through millennia of having to compete for material resources. Good times.

Now hydrogen bombs are back! And Nazis! And the climate is going nuts! And as for the Web… although most of it is quite good, it’s fallen short of our early optimistic outlook in some areas. As it’s become clear history was not over but merely taking a short nap, we should now ask ourselves: What can I do to make things better?

As a designer, I turn to one of my heroes — Buckminster Fuller — for inspiration. Bucky described the role of the designer (which he considered himself to be) as “an emerging synthesis of artist, inventor, mechanic, objective economist and evolutionary strategist.” While I love this description as a way of understanding how designers can change things systemically, for guidance on what to change towards I turn to his mission statement:

To make the world work for 100% of humanity in the shortest time possible through spontaneous cooperation without ecological damage or disadvantage to anyone.

Crazy idealistic — and spot-on. I’ve adopted this mission, replacing “without ecological damage” (which is somewhat removed from my direct purview as a designer of information environments) to “without damaging semantic environments.”

Making the world work for 100% of humanity.

In the shortest time possible.

Through spontaneous cooperation.

Without damaging semantic environments or disadvantaging anyone.

In troubled times, it’s important to have a clear sense of purpose. Bucky’s statement is something to aspire to and work towards.

Aligning Incentives

| Jorge Arango

Incentive structures work. So you have to be very careful of what you incent people to do, because various incentive structures create all sorts of consequences that you can’t anticipate.

— Steve Jobs

What incentives drive your actions?

I don’t mean this in an aspirational, high-level, mission-statement sense. I mean: How is the value you add to the ​world remunerated? How do you put bread on the table? If you’re rewarded for a particular set of behaviors, you will most likely engage in those behaviors.

Some consultants charge by the hour. They get paid more the longer they focus on a problem. But the client doesn’t want the project to take longer (or cost more) than it needs to. In fact, the client wants a good job done as fast as possible. He or she is driven by different incentives than the consultant; time is usually a key factor. This is a case in which incentives are misaligned.

If you look around, you’ll find many such misaligned incentives. For example, as a citizen, ​you want to be well-informed so you can make better decisions. However, many mass news media are driven by engagement — how long they can keep you around so you can watch more advertisements. Engagement is a very different metric than elucidation; people will write and say outlandish things if they think it’ll make you pay more attention. (And if they get paid more when you do.)

We’ve never before been able to learn so much about what drives people, and instantaneously re-define their contexts based on what we learn about them. Incentive structures become reified in information environments. So when designing an information environment, we should work towards aligning the incentives that drive the environment with the incentives and goals of the people who will use it.