The Space That Symbolizes the Information Age

“The space that symbolizes the Information Age is not the symmetrical and ornamental space of traditional architecture, the rectangular volumes of modernism, nor the broken and blown up volumes of deconstruction. Rather, it is space whose shapes are inherently mutable and whose soft contours act as a metaphor for the key quality of computer-driven representations and systems: variability.”

— Lev Manovich

Four Types of Prototypes

Prototypes are central to the design process; they’re the means by which designers establish the feedback loops that allow artifacts to evolve. But there’s a pitfall when discussing prototypes: there are different types and uses of prototypes, but only one word (“prototype”) to describe them. This unacknowledged variety can cause confusion and false expectations. Talking about prototype resolution and fidelity is as far as many designers go, but often that’s not far enough.

In a paper (PDF) published in the Handbook of Human-Computer Interaction (2nd Ed) (1997), Apple designers Stephanie Houde and Charles Hill resolve this issue by identifying four categories of prototypes, based on the dimension of the design project they’re meant to illuminate:

  • Role prototypes
  • Look and feel prototypes
  • Implementation prototypes
  • Integration prototypes

(Following quotes are from the paper.)

Role prototypes

Role prototypes are those which are built primarily to investigate questions of what an artifact could do for a user. They describe the functionality that a user might benefit from, with little attention to how the artifact would look and feel, or how it could be made to actually work.

In other words, this dimension is meant to cover the “jobs to be done” angle of the product or system. How will people use it? Would it be useful in its intended role? What other purposes could it serve for them?

Look and feel prototypes

Look and feel prototypes are built primarily to explore and demonstrate options for the concrete experience of an artifact. They simulate what it would be like to look at and interact with, without necessarily investigating the role it would play in the user’s life or how it would be made to work.

This dimension doesn’t require much explanation; these are prototypes that are meant to explore UI possibilities and refine possible interaction directions. (I sense that many people focus on this aspect of prototyping above the others; look and feel is perhaps the most natural target for critique.)

Implementation prototypes

Some prototypes are built primarily to answer technical questions about how a future artifact might actually be made to work. They are used to discover methods by which adequate specifications for the final artifact can be achieved — without having to define its look and feel or the role it will play for a user. (Some specifications may be unstated, and may include externally imposed constraints, such as the need to reuse existing components or production machinery.)

These prototypes often seek to answer questions about feasibility: Can we make this? What challenges will we face in producing such a thing? How will a particular technology affect its performance? Etc.

Integration prototypes

Integration prototypes are built to represent the complete user experience of an artifact. Such prototypes bring together the artifact’s intended design in terms of role, look and feel, and implementation.

As its name suggests, this final category includes prototypes that are meant to explore the other three dimensions. Their comprehensive nature makes them more useful in simulating “real” conditions for end users, but it also makes them more difficult and expensive to build.

The authors illustrate all four categories with extensive examples. (Mostly charming 1990s-era software projects, some of them prescient and resonant with today’s world.) A running theme throughout is the importance of being clear on who the audience is for the prototype and what purpose it’s meant to serve. A prototype meant to help the internal design team explore a new code library will have a very different form than one meant to excite the public-at-large about the possibilities afforded by a new technology.

The paper concludes with four suggestions for design teams that acknowledge this empathic angle:

  • Define “prototype” broadly.
  • Build multiple prototypes.
  • Know your audience.
  • Know your prototype; prepare your audience.

Twenty-plus years on, this paper remains a useful articulation of the importance of prototypes, and a call to using them more consciously to inform the design process.

What do Prototypes Prototype? (PDF)

Trusting a Software Ecosystem

Digital products aren’t monolithic. They depend on systems and infrastructure that aren’t controlled by the team responsible for the product. (Thinking about these things as “products” over-simplifies them. But I digress…) Consider a mobile app that relies on knowing its user’s location. That functionality won’t likely be developed internally by the app’s creators. Instead, they’ll use frameworks provided by mobile operating systems such as Android and iOS.

These operating systems in turn also leverage complex systems that their creators — Google and Apple, respectively — didn’t build themselves. For example, these companies didn’t create (or operate) the Global Positioning System on which location services depend; the U.S. government did. OS providers trust the providers of these systems; app developers trust the OS providers; users trust app developers. It’s a chain of trust.

When you use a ride-sharing app such as Lyft or Uber, you’re trusting this chain. Most people aren’t aware of it being a chain at all; they experience the app as a singular thing. If something goes wrong, they’ll reach out to the party responsible for the means through which they interact with this complex ecosystem: the developers of the app.

If you’re in such a team, you must understand how your product functions as a system and develop a good sense for its interdependencies. It behooves you to understand the business models that underlie each link in the chain. What drives the providers of these services? What could they do with the information you’re providing them? Are their interests aligned with yours? Are they aligned with those of your app’s users?

Structuring the Problem

Designers are increasingly dealing with more complex problems. The systems we work with often span both digital and physical domains. Requirements and constraints are more abundant and difficult to articulate. More stakeholders are affected. The workings of the system may be opaque to our clients and us.

One of the biggest challenges of working on such projects is that the problem we’re solving for isn’t apparent. This is not out of ill-will or incompetence; some problems are just difficult to pin down. In The Art of Systems Architecting, Mark W. Maier and Eberhardt Rechtin define what they call ill-structured problems:

An “ill-structured” problem is a problem where the statement of the problem depends on the statement of the solution. In other words, knowing what you can do changes your mind about what you want to do. A solution that appears correct based on an initial understanding of the problem may be revealed as wholly inadequate with more experience.

Facing an ill-structured problem is difficult and frustrating. It’s also not uncommon. Complex design projects often start with a vague understanding of what the problem is we’re designing for, or perhaps we’re solving for several problems that appear incompatible. Solutions are often implicit in the way these problems are articulated.

To do a good job, you must clearly understand and articulate the problem(s) you’re seeking to solve. Stating the problem is the starting point for all that follows; it frames the work to be done. Poorly structured problems lead to poorly structured solutions.

Structuring the problem isn’t something you can expect stakeholders to do. It’s up to you, the designer, to ensure the problem is structured correctly. How do you do it? First, you acknowledge that the initial problem statement will be vague and/or poorly structured. You assume your initial understanding of the problem will be flawed. You then move to develop a better understanding as quickly as possible.

This requires iterating through artifacts that allow both designers and stakeholders to grasp new dimensions of the problem so you can set off in the right direction. The forms these artifacts take vary depending on the type of project you’re dealing with. (Concept maps work well for the types of systems I work on.) You want to establish processes that allow these artifacts to evolve towards greater clarity and focus.

This takes courage. Stakeholders and clients want answers, not vague abstractions. The process of clarifying the problem may point away from initial project directions. Because of this, delving in the problem-definition stage of a project can produce tension. But the alternative — getting to a high degree of fidelity/tangibility prematurely — can lead folks to fall in love with solutions to the wrong problems.

Book Notes: “The Evolution of Everything”

The Evolution of Everything: How New Ideas Emerge
By Matt Ridley
HarperCollins, 2015

Designers are called to tackle increasingly complex problems. This requires that we understand how systems function and how they came to have the configurations we experience. I put it this way because complex systems (at least those that stand the test of time) don’t come into the world fully-formed. Instead, they evolve step-by-step from earlier, simpler systems. (See Gall’s Law.) Because of this, it’s essential that we understand the distinction between top-down and bottom-up structuring processes.

That distinction is what drew me to The Evolution of Everything. While not written specifically for designers, the book addresses this subject directly. Per its jacket, the book aims to “definitively [dispel] a dangerous, widespread myth: that we can command and control our world.” It pitches “the forces of evolution” against top-down forces for systems definition. What sorts of systems? Any and all of them: the universe, morality, life, genes, culture, the economy, technology, the mind, personality, education, population, leadership, government, religion, money, the internet.

There’s a chapter devoted to how top-down vs. bottom-up approaches have played out for each of these complex subjects. Mr. Ridley aims to demonstrate that advances in all of them have been the result of evolutionary forces, and the hindrances the result of intentional, planned actions. I don’t think I’m doing the author a disservice by describing it in such binary terms. In the book’s epilogue, Mr. Ridley states his thesis in its “boldest and most surprising form:”

Bad news is man-made, top-down, purposed stuff, imposed on history. Good news is accidental, unplanned, emergent stuff that gradually evolves. The things that go well are largely unintended, the things that go badly are largely intended.

Examples given of the former include the Russian Revolution, the Nazi regime, and the 2008 financial crisis, while examples of the latter include the eradication of infectious diseases, the green revolution, and the internet.

While the whole is engaging and erudite, the earlier chapters, which deal with the evolution of natural systems, are stronger than the latter ones, which deal with the evolution of social systems. The book’s political agenda becomes increasingly transparent in these later chapters, often at the expense of the primary top-down vs. bottom-up thesis.

If you already buy into this agenda, you may come away convinced. I wasn’t. Sometimes bottom-up forces enable command-and-control structures and vice-versa. But you’ll find no such nuance here; the book offers its subject as an either-or proposition. This leads to some weak arguments. (E.g., “While we should honour individuals for their contributions, we should not really think that they make something come into existence that would not have otherwise.”)

Understanding the difference between top-down vs. bottom-up structuring is essential for today’s designers. The Evolution of Everything doesn’t entirely dispel the myth that we can command-and-control the world, but it does provide good examples of bottom-up emergence — especially in its earlier chapters. Still, I’d like a more nuanced take on this critical subject.

Buy it on Amazon.com

How to Measure Network Effects

Li Jin and D’Arcy Coolican, writing for Andreessen Horowitz:

Network effects are one of the most important dynamics in software and marketplace businesses. But they’re often spoken of in a binary way: either you have them, or you don’t. In practice, most companies’ network effects are much more complex, falling along a spectrum of different types and strengths. They’re also dynamic and evolve as product, users, and competition changes.

They go on to outline sixteen ways in which network effects can be measured, grouped into five categories:

Acquisition

  • Organic vs. paid users
  • Sources of traffic
  • Time series of paid customer acquisition cost

Competitors

  • Prevalence of multi-tenanting
  • Switching or multi-homing costs

Engagement

  • User retention cohorts
  • Core action retention cohorts
  • Dollar retention & paid user retention cohorts
  • Retention by location/geography
  • Power user curves

Marketplace metrics

  • Match rate (aka utilization rate, success rate, etc.)
  • Market depth
  • Time to find a match (or inventory turnover, or days to turn)
  • Concentration or fragmentation of supply and demand

Economics-related

  • Pricing power
  • Unit economics

I love it when somebody adds granularity and nuance to a concept I previously understood only in binary terms. This post does that for network-centric businesses.

16 Ways to Measure Network Effects

An Economy of Deception

Max Read, writing for New York magazine:

How much of the internet is fake? Studies generally suggest that, year after year, less than 60 percent of web traffic is human; some years, according to some researchers, a healthy majority of it is bot. For a period of time in 2013, the Times reported this year, a full half of YouTube traffic was “bots masquerading as people,” a portion so high that employees feared an inflection point after which YouTube’s systems for detecting fraudulent traffic would begin to regard bot traffic as real and human traffic as fake. They called this hypothetical event “the Inversion.”

And it’s not just traffic. The article highlights other aspects of online life that aren’t what they appear to be, from businesses and content to the people behind them. As participants in digital information environments, we must increasingly grapple with thorny philosophical questions. What is real? Who is a person? What’s trustworthy?

This situation isn’t inherent to digital information environments. It’s the result of bad incentive structures. Trafficking in advertising — the buying and selling of human attention — has had pernicious effects on the internet. It’s created an economy of deception in one of the most beautiful systems our species has created.

How Much of the Internet Is Fake?

Designing a Better System

One of the occupational hazards systems thinkers face is equating the understanding that something is a system with understanding the system itself. Knowing that the outcomes you see result from complex interactions between myriad components doesn’t endow you with the ability to tweak them skillfully.

In complex systems — the weather, the economy — the interactions between the parts often produce counter-intuitive behavior in the whole. You must observe the functioning system for a long time to develop a useful mental model. (Useful in that it helps you make reasonable predictions about what’s coming next.)

Developing good models of complex systems is very difficult. Even after observing the system for a long time — as people have done with the weather and the economy — what makes it tick may elude us. The larger and more complex the system is, the more there is to take in. Such systems are continually changing; often the best you can do is procure a snapshot of its state at any given time. Also, such systems are often the only of their kind. (The sample size for atmospheres precisely like the one that envelops our planet is one.)

The ultimate hazard is hubris. Having understood that something is a system — and perhaps even having developed a good snapshot model of the system — we start to believe we could do as well or better if allowed to start over. You’ll recognize the trap as a violation of Gall’s Law. When dealing with complex systems, no individual — no matter how smart or clairvoyant — can design a better system than one that has evolved to suit a particular purpose over time.