Book Notes: “Dark Matter and Trojan Horses”

| Jorge Arango

Dark Matter and Trojan Horses: A Strategic Design Vocabulary
By Dan Hill
Strelka Press, 2012

Podcaster Tim Ferriss asks the people he interviews a useful (and revealing) question: What book have you gifted most often? My answer to this question is Dan Hill’s Dark Matter and Trojan Horses, an essay about strategic design. I’ve probably cited, recommended, and gifted this short book more than any other, mostly to other designers.

The main point of the essay is that design is useful for more than just creating great products and services. (Essentially, solutions to pre-defined — and often ill-defined — problems.) Instead, design can help us tackle a wide range of wicked problems at the social and organizational levels:

Continue reading →

Real IAs Ship

| Jorge Arango
mirage
Photo: Michael Gwyther-Jones

Great ideas are worthless without execution. An amazing new product that doesn’t ship isn’t a product at all; it’s a mirage. Mirages can be enticing, but they don’t slake thirst. (They’re enticing precisely because they hold the promise of slaking thirst.) A product can’t start generating value until it’s in customers’ hands. This requires that it move off PowerPoint decks and InVision prototypes and onto users’ computers, phones, chatty cylinders, etc. As Steve Jobs said, “real artists ship.”

Information architecture deals with abstractions: conceptual models, ontologies, taxonomies — distinctions that create contexts within information environments. In their “purest” state these things are far removed (in mindset and often in time) from the code running on customers’ devices. For those of us who define these semantic structures, losing touch with execution is an occupational hazard. We can fall in love with the amazing models we’ve made, forgetting they are but a means to an end: a product or platform that serves specific needs in a market. This product-market fit should be topmost in the mind of anyone involved with the design of such a system — regardless of the level of abstraction at which we’re working. The more rarified the air we breathe, the more important it is that we keep our sights fixed on the real needs that drive the project.

For information architects, this means zooming down the ladder of abstraction to the functional artifacts that make it into users’ hands. It means creating feedback mechanisms to allow our abstract constructs to evolve based on the things we learn from real customers. It means understanding the materials out of which these systems are made: code, databases, APIs, networking protocols. It means understanding business metrics. It means understanding the dynamics of the development process. It means understanding people.

Abstract constructs created for their own sake — or without a clear execution plan — may be interesting intellectual exercises, but are of little value to the people we serve. Information architecture can bring coherence and clarity to products and platforms — but only when they ship.

What I Look for in Collaborators

| Jorge Arango

Recently a student asked me what I look for when hiring people. I sent an abbreviated response but thought it worthwhile to expand on it here since it may be useful to others.

When I’m evaluating somebody as a collaborator, I want to know about four factors:

Is s/he a solid thinker?
This comes across in how they express themselves in interviews and written communications, and what they express. Do they demonstrate a solid grasp of key concepts and relationships between them? Can they explain difficult concepts without resorting to jargon/cliches? Can they explain their decision-making process clearly? Are they confident in what they’re saying?

Is s/he a solid maker?
This comes across in the artifacts in their portfolio. Do artifacts communicate clearly? Do they get to the point? Do they demonstrate mastery of medium? Do they demonstrate mastery of craft? Do they demonstrate clear intent? Do they demonstrate a willingness to experiment/push boundaries?

Is s/he a team player?
This is difficult to evaluate through portfolios and interviews; references come in handy. Still, there are cues that reveal how they relate to others. For example, do they give credit to their teammates or do they claim all the glory for themselves?

The character factor
Most importantly, I want to know about their character. Are they upstanding? Do they behave courteously towards others? Do they demonstrate a clear value framework? This is rather difficult to evaluate over brief interactions. Again, references help.

I place less weight on other things such as formal education or a record of having worked at the “right” places. The four factors above go a long way towards identifying​ the people who will help us be successful.

When the User is not the Customer

| Jorge Arango

Sometimes the people who buy the things you design are not the same people who will use them.

Consider infant nutrition. For many other lines of business in the food industry, the terms consumer and customer are interchangeable. But not with baby foods. In this space, the person who consumes the product (the baby) is not the same person who buys it (the baby’s caregiver, most usually his or her mother.) The two groups have different needs and expectations: the nutritional aspects of the product must address the infant, while its packaging and marketing must address the caregiver. A successful product must address both.

Another example is corporate IT. The computers and other tech equipment used in large organizations are not sold to the people who use them; instead, they’re sold to IT departments. The needs and incentives of the people who make these purchasing decisions are different from those of the people who’ll use the equipment. While the latter care about good product experiences, the former are more concerned with reliability, serviceability, manageability, and cost.

These different sets of needs may conflict with one another. In some cases, such as with newborn infants, the conflict is unacknowledged because users may be unaware or unable to articulate their needs properly. But in many other cases, end users may be quite aware of what they like or don’t like in a product. For example, making a laptop more serviceable may also make it heavier and clunkier. This is often a challenge in enterprise contexts where people often make decisions on behalf of their collaborators.

When designing a product or system, it’s important to be clear on who its users are, who its customers are, and whether or not the two groups are the same. When they’re not, we must set out to map the needs and concerns of both groups so we are clear on what tradeoffs — if any — are required. As much as designers aspire to be user-centered, we must acknowledge that being customer-centered is also important. While this is easier to do when our users are also our customers, this is not always the case.

The Power of Co-creation

| Jorge Arango

Co-creation is a design approach that allows teams to achieve excellent results very fast. That said, it’s better suited to some cases than others. Having worked in several large-scale co-creation projects over the past few years, I have some insights on where it produces the best results.

What is co-creation? The best way to understand it is by examining how other design approaches work. Many follow a process similar to the one represented in the double diamond model:

Continue reading →

An Example of a Semantic Environment Map

| Jorge Arango

I’ve had folks ask me for examples of a semantic environment map. Here’s one for the confessional, a semantic environment within the broader environment of the Catholic Church:

Did I get it wrong? It’s likely. If you can spot problems, the map is serving its purpose: to help us have discussions about contextual issues that often go unnoticed or unexpressed.

If you want to create a map of your own, you can download a PDF of the Semantic Environment Canvas.

What a Medium Is

Quote | | Jorge Arango

“A medium is a technology within which a culture grows; that is to say, it gives form to a culture’s politics, social organization, and habitual ways of thinking.”

— Neil Postman

It’s Not Just About Users

| Jorge Arango

Designers have long known that good work comes from a thorough understanding of the people who use our systems and products. We interview users or observe them “in the mist” to grok their desires, needs, and motivations. We analyze their behavior and generate insights. We produce prototypes to validate and test those insights with them. In short, much design today is a collaboration between designers and the users of the systems we create.

Many designers within organizations have adopted this laudable perspective. “I’m an advocate for the user,” they’ll tell you. The geekier ones cite Tron: “I fight for the users!” Who are these designers pleading or fighting with? Often it’s people from other parts of their organization. You’ll hear designers talk about resisting pressures from marketing, or working around constraints placed by compliance. It’s as though the requirements established by these groups are obstacles arbitrarily placed in the way of a “great user experience.”

Many do get in the way. But why is the experience being designed in the first place? Ultimately, it’s to meet business objectives. In establishing requirements and constraints, those other “corporate silos” are serving their organizational functions, just as design is serving its​ own. Thinking of colleagues from these groups as an “other” to be resisted shows a lack of systemic understanding and leads to sub-par work. The objective of user-centered design is not merely to provide the best experience to users; it’s to provide the best experience to users that serves their needs while also serving the organization’s needs.

Designers should strive to have as much openness and empathy towards our counterparts in the organization as we do towards users. Yes, a deep understanding of our product and its users is essential. But it must be framed by a systemic understanding of the organization’s goals, our role within it, the roles of people in other parts of the organization, and how those parts work together to help it achieve its purposes.