Systems

Data in Conceptual Models

| Jorge Arango

When designing interactive systems, it behooves you to define a conceptual model before you start thinking about the user interface. A great resource to learn to do this is Austin Henderson and Jeff Johnson’s Conceptual Models: Core to Good Design. In this book, they describe the system’s conceptual model in terms of “how the user would ideally think about the application and its use in supporting tasks.”

This requires you first understand the tasks (and “task domains”) the system is meant to accommodate. As you analyze the ways users understand tasks, you can define what (conceptual) objects the system must present to help users accomplish those tasks. These objects have certain attributes that are essential to their roles in the system, and they allow users to carry out particular operations that help them accomplish their tasks.

The book includes the following example, which defines a conceptual model for a simple office calendar application:

Objects Attributes Operations
Calendar owner, current focus examine, print, create, add event, delete event
Event name, description, date, time, duration, location, repeat, type (e.g., meeting) examine, print, edit (attributes)
To-Do item name, description, deadline, priority, status view, print, edit (attributes)
Person name, job-description, office, phone send email, view details

It’s obvious why it’s useful to define such a structure before you design a user interface: a conceptual model gives you a high-level picture of the system’s user-facing components. Rather than adding affordances for features piecemeal, here you have the opportunity to think about them as a whole. This allows you to think holistically about the system’s interaction mechanisms and language. Having such a conceptual model​ before working on the UI saves a lot of headaches and leads to a much more coherent experience.

However, there’s another good reason to start by defining a conceptual model: doing so allows you to better understand opportunities for leveraging data that may go unacknowledged when you begin by sketching out screen-level artifacts. Thinking about the conceptual objects in the system, their attributes, and the actions they accommodate helps surface opportunities inherent in the data these objects, attributes, and actions require and generate.

For example, when interacting the model above, the user will generate data points. Adding an event to a calendar is an action that will be captured by the system. We know events include a “type” attribute, so over time, this system will have data about various types of events. We can use this data to spot usage patterns and predict behavior, information we can use for the benefit of users and the business.

While conceptual models focus on user-facing concepts, defining them upfront also sheds light on these “invisible” aspects of the system. Doing so allows you to spot opportunities for improvement that may otherwise become apparent only further down the line (or not at all.)

TAOI: YouTube Subscriber Counts

| Jorge Arango

The architecture of information:

A headline on The Verge: YouTube is changing how subscriber counts are displayed, possibly shifting its culture.

One of the most famous aphorisms in management is Peter Drucker’s observation that “if you can’t measure it, you can’t improve it.” This phrase succinctly captures an important idea: when deciding the way forward, data is your friend. Rather than discussing directions in the abstract, this concept encourages us to break down problems into impartial facets we can trace over time.

However, as useful as it is, there’s a flip side to this concept: with a compelling enough measure, we can lose sight of the ultimate “it” we’re trying to improve. The point of losing weight isn’t to read a lower number on a scale; it’s to get healthier. The number is a proxy for health — and an imperfect one at that. “Health” is a complex subject with lots of nuances. Articulating it as a single number can make it easier to understand, but oversimplifies a complex whole.

We compound the problem when we base incentives on these numbers. Let’s say you’re promised a $500 bonus if you lose a certain amount of weight by a particular date. At that point “health” is twice abstracted: your goal is now neither health nor weight but the money. The numbers start to become more important than the ultimate thing we want to achieve. The map is not the territory, but we’re being incentivized to navigate the map.

We hope to get to the goal on the real ground the map represents. But sometimes we don’t. Sometimes the map is so compelling that it becomes the territory. This has happened with measures in social media such as follower counts on Twitter.

Back to The Verge article. High-level summary: After a recent kerfuffle between two “creators,” YouTube is changing how its system displays subscriber counts. Creators compete for subscribers, and their fortunes wax and wane accordingly. In this system, follower counts are a proxy for popularity. It’s an imperfect measure, but it’s clear and compelling, and so emerges as the locus of attention for an economy of influence. I didn’t realize it until reading about this issue, but there’s a secondary market on these stats: websites like Social Blade exist solely to track how these people are doing relative to each other. It’s a big deal.

But what’s the ultimate goal here? What social function is this system enabling? (What’s the equivalent of “health”?) Is it entertainment? Commerce? Both?

Proudshamed

| Jorge Arango

Paul Ford, writing for WIRED:

NERDS, WE DID it. We have graduated, along with oil, real estate, insurance, and finance, to the big T. Trillions of dollars. Trillions! Get to that number any way you like: Sum up the market cap of the major tech companies, or just take Apple’s valuation on a good day. Measure the number of dollars pumped into the economy by digital productivity, whatever that is. Imagine the possible future earnings of Amazon.

THE THINGS WE loved — the Commodore Amigas and AOL chat rooms, the Pac-Man machines and Tamagotchis, the Lisp machines and RFCs, the Ace paperback copies of Neuromancer in the pockets of our dusty jeans—these very specific things have come together into a postindustrial Voltron that keeps eating the world. We accelerated progress itself, at least the capitalist and dystopian parts. Sometimes I’m proud, although just as often I’m ashamed. I am proudshamed.

This piece captures a mood I’ve perceived among my cohort of techie designers: A radical swing from the unbridled optimism many of us felt in the 1990s — the sense that the internet was a transformational force comparable only to Gutenberg — to moroseness and guilt at the effects of these changes on society.

The transition from the Middle Ages to the modern era was anything but smooth. Gutenberg’s innovation wrought tremendous upheaval: Long-standing mental models collapsed; social and political systems were replaced. The technological changes of the last five decades — the wiring up of the planet into a real-time nervous system that democratizes access to the world’s information — are in some ways more radical than those of the 15th-16th Centuries. We’ve not just changed the ways we interact with each other and the world, we’ve changed change itself — scaling and speeding it up in ways that lead to unpredictable outcomes.

The article frames (digital) technology as an industry alongside others such as energy and finance. That’s a common underestimation spurred by the pervasive mental model of our time: that of the market economy. Yes, tech is an industry in that sense. But tech is also a meta-industry: it changes the character of the other industries thoroughly. The call to more responsible design is urgent not because tech requires it, but because we are re-building society atop tech.

Why should we expect such radical changes to be easy or comfortable? People of my vintage (I’m squarely Gen X) and younger in the developed world have thus far led lives of relative peace and stability. Cold War notwithstanding, we came of age inside a certainty bubble. When dealing with (deep) disruption, we fail to account both for the fragility of social institutions and the resilience of individuals under such conditions.

Mr. Ford concludes:

I was exceptionally lucky to be born into this moment. I got to see what happened, to live as a child of acceleration. The mysteries of software caught my eye when I was a boy, and I still see it with the same wonder, even though I’m now an adult. Proudshamed, yes, but I still love it, the mess of it, the code and toolkits, down to the pixels and the processors, and up to the buses and bridges. I love the whole made world. But I can’t deny that the miracle is over, and that there is an unbelievable amount of work left for us to do.

I, too, feel lucky. Yes, there is lots of work to do. But the miracle is far from over; it’s ongoing. Responding skillfully to the changes it bring requires being present; that we see clearly so we can use our (real!) abilities towards increasing agency and compassion.

WHY I (STILL) LOVE TECH: IN DEFENSE OF A DIFFICULT INDUSTRY

“Build More Roads” is Often the Wrong Answer

| Jorge Arango

The Power Broker, Robert Caro’s masterful biography of Robert Moses, tells the story of how modern New York City came to be. Moses and his team were responsible for some of the most important public infrastructure interventions in and around New York City during a span of four decades starting in the mid-1920s. Under Moses’s leadership, the city gained new parks, playgrounds, bridges, and especially roads — sometimes at the expense of beloved neighborhoods and the disruption of countless lives. An unelected official, Moses became incredibly powerful; you can see his influence in New York even today.

The core of Moses’s power lay in the Triborough Bridge Commission, which controlled the flow of traffic between Manhattan, The Bronx, and Queens. Tolls from vehicles driving across the Commission’s bridges generated immense revenues that paid for other projects, which in turn generated more revenues. For Moses, vehicular flow in New York City’s streets translated directly to more power. Thus, when considering means for transporting the city’s inhabitants, Moses’s team would gravitate towards more roads — even when it’d become clear that building more roads only increased congestion. The result was the defacement of major parts of the city with highways and roads that were constantly jammed with traffic.

You gotta watch incentives.

This comes to mind because of something that Jessica Ivins said on her interview for The Informed Life podcast:

So not everybody has the detail-oriented mind that I do, or not everybody works the same way I do. And because we’re small and I’ve been working here for almost 5 years, I have a sense of what works well for my co-workers. So for example, my coworker Thomas, I will assign him a to-do in Basecamp and he’ll get an email notification, but I’ll also send him a notice on Slack. And I’ll say, “Hey Thomas, I signed you this to-do on Basecamp, please review it by this date and see the to-do for details.” And that Slack message really helps him because he… I guess some people are really good at wrangling their inbox, other people really struggle with it. And I think that’s really typical.

It is typical. I’ve faced similar situations in other projects: Someone new joins the team, and you don’t yet know their communications preferences. Are they an email person? Do they prefer Slack? Or maybe iMessage? It’s not unusual to get a message in Slack followed by an email asking, “Did you see the message I put in Slack?” And of course, people’s preferences vary depending on other factors. For example, perhaps they only use Slack on their computers and find it easier to respond via SMS when they’re on the road.

Proprietary communications systems like Slack and Basecamp set out to solve the problems with older systems like email (and there are many!), but like Moses’s roads they can end up creating other problems. Now instead of one or two places to check your communications, you have five. You get reminders on one system (e.g., email) to check messages sent to you on another (e.g., Basecamp.) I’ve gotten messages on Slack to check something that was posted in Basecamp; later that evening I’ll also get an email reminder from Basecamp of all the things that were posted there during the day. The signal-to-noise ratio goes through the floor. And of course, now you have to keep track of where you saw the message or file if you ever need to get back to it. (“Did you send that document over email, or was it in Slack?”) As far as I know, it isn’t possible to search across all of these systems; it’s up to you to keep track of where things are. This is difficult, given the challenge I mentioned above. (I.e., different people have different communications preferences.)

The added complexity would be worthwhile if these systems enabled amazing new ways of working, but these proprietary communications systems bring little new to the table; most of the functionality they enable has been around for a while. Check out Jon Udell’s book Practical Internet Groupware for the state of the art twenty years ago; you’ll find lots that is familiar. It’s worth noting that that book advocated for building these communications systems atop existing open standard technologies. In this sense at least, the current state represents a regression from where things were in the late 90s.

I’m cranky about this stuff because in the past month I’ve joined three new Slacks and one Basecamp project. This is part of the job when you’re an independent consultant who works on several projects with different teams throughout the year. But I don’t enter these spaces casually. As someone who thinks about the longevity and resilience of information ecosystems, I’m concerned about my ability to find and keep track of stuff — especially in the long term. I dislike the proliferation of disconnected, single-purpose silos of information. While the discussions that happen in these places can be rich, vibrant, and productive (that is, when they’re not generating more noise in other channels), they’re locked away, inaccessible for future (even near-future) reference.

In the long term, building more roads isn’t the solution to the challenge of moving lots of people from one point to another. Past a certain volume, individual vehicles are inherently inefficient; one needs to re-think the structure of the transportation system from the ground up. This is more challenging if the people charged with the stewardship of these systems are incentivized to get more cars on the road. I sense similar problems with the communications challenges we face in organizations. When what you’re selling is access to Slack, your incentive​ is to get more people using Slack. That’s a different goal than getting people to communicate effectively. Yes, there is some overlap there — up to a point. How does the system scale?​

Design as an Antidote to VUCA

| Jorge Arango

A short presentation I shared as a videoconference with Rosenfeld Media’s Enterprise Experience Community.

In the early 1990s, the U.S. Army War College created an acronym to describe the geopolitical situation following the Cold War: VUCA. It stands for volatility, uncertainty, complexity, and ambiguity, four characteristics they saw as defining the multilateral post-Cold War world. The rise of information technologies — and the internet in particular — has radically transformed our political, economic, and social reality. We are all now living in a generalized state of VUCA. We see signs of it everywhere — including the enterprise.

Design can be a powerful organ for organizations dealing with VUCA. In this presentation, I give some reasons why. I also cover some reading materials that have led me to this line of thinking. I was gratified to see participants in the videoconference suggest other resources worth investigating if you’d like to delve into design’s more strategic value; I’ve added those recommendations into my reading list.

Books I referenced in my presentation:

I also called out these recent Medium posts:

Other folks in the call suggested the following additional resources. (I’ve listed them here in the order in which they were suggested.)

I have a lot of reading to do! I was familiar with some of these resources, but not all of them. That’s one of the upsides of sharing incipient ideas with a smart group of folks like the Enterprise Experience community: you get to hear from other folks who know more about other parts of the domain. I’ll be digging into these books, posts, and videos for sure!

The Cynefin Framework

| Jorge Arango

I’m keen on frameworks that help us deal with change in complex systems. The Cynefin framework is particularly illuminating. Here’s an excellent, succinct introduction by its originator, Dave Snowden:

The framework posits that causal differences in systems categorize them into four domains or “spaces”:

  • Simple: Cause and effect relationships between elements in the system can be determined in advance.
  • Complicated: Cause and effect relationships exist, but aren’t self-evident.
  • Complex: No causality; agents are able to modify the system.
  • Chaotic: Cause and effect relationships can’t be determined.

“Dependent on which space you’re in,” Mr. Snowden says, “you should think differently, you should analyze differently.” In other words, each of the domains calls for a different response. Therefore, knowing which domain you’re acting within is key to making effective decisions. That said, in some cases, you may not know which domain you’re acting within. The framework defines this fifth domain as “disorder,” a situation that lends itself to idiosyncratic responses that can be ineffective or worse.

You can learn more about the Cynefin framework in the Harvard Business Review or in Cognitive Edge, Mr. Snowden’s consulting company.

Cynefin Framework Introduction

A Brush With Resilience

| Jorge Arango

The iPhone in my pocket is a miracle: an encyclopedia, a communicator, a calculator, a notebook, a library, a compass, a tape measure, a camera, a flashlight, a watch, etc. Yet for all of its capabilities, it’s also not very durable. In another year, my iPhone will start to feel sluggish, and its battery won’t last a full day. In another ten years, it’ll practically be useless. This is partly by design and partly because its technologies evolve so rapidly.

Not all things are designed to be ephemeral like the iPhone. Yesterday my family and I visited the SS Red Oak Victory, a World War II ship that is part of the Rosie the Riveter WWII Home Front national park in Richmond, CA. The Red Oak was built in 1944 and is a marvel of 1940s-era engineering. What amazed me most is how many of the ship’s communication technologies are still operational.

For example, the ship’s internal telephone system, which is powered by small hand-cranked electrical generators, still works, as does its late-1940s radio. When compared to my iPhone, these things are incredibly crude, of course. But the fact that they’re still in good working order after 70 years was illuminating.

This is by design. The conditions under which the Red Oak operated demanded resilience. Its operators could find themselves in remote ports of call, with little or no access to expertise. They would need to fend for themselves, and the ship was designed to make this possible, if not easy. It was built to be easily repaired and maintained by the people who operated it; people who wouldn’t necessarily have advanced engineering knowledge.

Also, the Red Oak wasn’t mean to be consumed. That is, it’s not an artifact designed to generate ongoing want, to be discarded and replaced. There are redundancies — inefficiencies — everywhere. The ship’s components are large and sturdy. They weren’t designed for portability, efficiency, or economy — they were built to last.

I don’t expect the same degree of resiliency in my iPhone. But touring the Red Oak made me think about how we can make the things we experience on the iPhone — our information environments — more like that ship; better able to stand the test of time.

Two Approaches to Preserving Cultural Monuments

| Jorge Arango

Yesterday I followed along in horror as the roof of Notre Dame Cathedral burned down. The building — one of the great monuments of Western Civilization — was terribly damaged in the conflagration. Fortunately,​ no lives were lost. However, I still felt very sad. Buildings such as Notre Dame are more than mere shelter; they’re also vessels of culture. This fire was a great loss not just for the city of Paris, but for the world.

Seeing the disaster play out on​ Twitter, I couldn’t help but think about the way that we (in the West) go about preserving our cultural heritage. We incur great expenses to maintain structures like Notre Dame “as they were” — kept “authentic,” with as little alteration as possible. Buildings such as Notre Dame are symbols of our past; reminders of where we come from. We strive to keep them the way they were.

In this view, the emphasis is on the artifact itself; what matters is that the structure be preserved unscathed. Occasionally, something terrible may happen, such as yesterday’s fire in Paris. In that case, we put great effort in reconstructing the artifact as accurately as possible. (Architectural historian Andrew Tallon laser-scanned every inch of Notre Dame in 2010.) Fires, wars, and natural disasters have destroyed great monuments in the past. They’re often rebuilt exactly as before. (An example that comes to mind is the campanile in Venice’s Piazza San Marco, which collapsed in 1902.)

This is one way of going about preserving our cultural identity. Another way is best illustrated by another historically important religious structure, the Ise Jingu Shrine in Japan. This building is much older than Notre Dame; it’s been around in its current form since the late 7th Century CE. One of the interesting things about the Ise Shrine is how the people go about preserving it: Instead of waiting for time to take its toll, inhabitants of Mie Prefecture tear it down every twenty years and rebuild it as before.

When you visit the Shrine, you’re experiencing a building that is simultaneously over a thousand years old and also not older than twenty years. What matters isn’t the artifact per se – that exact building — it’s the process that brings it about. The ritual of rebuilding the Shrine preserves not just the structure, but also the methods that brought it about. Its continuous re-creation keeps it more immediately relevant than an artifact that is preserved “as is” for all time. Every generation gets to make it its own. (Literally.)

This is a completely different way of preserving the past. The focus is on systems, processes, and craft over the finished product. It’s a way of bringing cultural identity to life in a way that is more engaging than the more common approach to preservation. It’s also more resilient: a devastating incident like yesterday’s fire wouldn’t be such a major disruption if the structure was meant to be rebuilt anew every generation or so.

I don’t expect we’d actually do this with our great monuments; the expense of re-building an artifact as big and elaborate as Notre Dame ever twenty years would be too great. I want to see the great cathedral reemerge from the ashes, and would love to see it rebuilt as it was. I expect the people of France will bring it back to life. That said, I can’t help but wonder what it would mean for us to adopt a more systems-minded approach — not just to the preservation of our buildings, but to culture more broadly.

Systemic Design Beyond the Screen

| Jorge Arango

Last evening I introduced students in my systems studio class to their final project for the semester. The project has them designing an intervention to help individuals with their financial health. I must call it an “intervention” because I’ve been trying to steer the students away from thinking about the things they’re making as manifesting exclusively through screens.

It’s a challenge. Designing at a systemic level calls for thinking abstractly, and looking at the entire ecosystem one is designing for. However, systemic change happens as a result of concrete interventions: Something must serve as the catalyst for change, and that something must be made tangible somehow. Given how much time we spend interacting with and through screens, it’s natural to immediately gravitate towards solutions that involve software experienced through (especially) mobile app screens.

While software can be incredibly powerful, to think exclusively about the objects of interaction design as screen-based experiences is to limit ourselves unnecessarily. Our bodies and the world they inhabit are incredibly rich; screen-based experiences collapse that richness into relatively small windows that concentrate everything into what you can experience through a small glass rectangle.

We have so many more possibilities to choose from! What if the object of design were a new ritual? Or how about language? (“Create a new way of talking about the domain that opens up new possibilities.”) And of course, service design offers a broad range of possible interventions well beyond what can happen through screens.

Of course, I’m not opposed to screen-based interventions. The problem is that we’re so used to them that students run the risk of 1) immediately gravitating towards cliched solutions, and/or 2) not thinking about the problem as a systemic design challenge, thinking instead that they’re working on an “app” (something they’re more familiar — and therefore, more comfortable with.) I’m hoping that nudging them to think beyond the screens can help them think more systemically and propose more interesting (and fresh) solutions.