Design

Against Wireframes

| Jorge Arango

Yesterday I led a bright and engaged group of folks through my Information Architecture Essentials workshop. Most of them were new to the discipline, and wanting to know more. We talked about many things, but had an especially active discussion about wireframes. I don’t like them and haven’t used them in my work for a long time. I thought it worthwhile to document my reasons here, in case it helps anyone.

Wireframes are a design artifact that has long been associated with information architecture. I’ve heard people ask to be “sent the IA” meaning they expect something that looks either like a sitemap and/or a set of wireframes. I consider these “deliverables” to be tools from a prior — more “waterfall” — era of web design and mostly a waste of time today, if not outright misleading. (I include sitemaps in this statement, even though I’m focusing on wireframes here.)

Although I’m sure it’s been written about at length (and better) elsewhere, here are some reasons why I don’t like them:

  • Wireframes are too abstract and not abstract enough. Wireframes are an attempt to explore the relationships between elements in a screen. Often this includes the relative visual priority of things. However, they attempt to extract aesthetics (the “visual design”) from these visual explorations. As a result,
  • Wireframes confuse stakeholders. I think of design artifacts as tools that allow people — both designers and stakeholders — to make design decisions. Wireframes are mostly clear designers, but not to stakeholders. Asking folks to comment on the relative hierarchy of elements in a visual document while also asking them to ignore the aesthetics of the thing is a tall order.
  • Wireframes are ineffective as decision-making tools. Visual design affects the perception of the relationship of elements on the screen. Font and color choices affect the relative prominence of elements. More abstract wireframes fail to convey these important distinctions. On the flip side, less abstract wireframes are close enough to visual design to derail the conversation towards the lack of aesthetic nuance. As a result, wireframes are seldom effective in helping people make design decisions.
  • “But,” you may protest, “we don’t use wireframes to make decisions. We use them to convey decisions to developers.” Alas, wireframes are also ineffective as design documentation. Wireframes require more effort to produce and maintain than lower fidelity artifacts (like freehand sketches.) Evolution of the design seldom stops when the wireframe deck is complete, leading to either the deck becoming outdated or — worse — design being “fixed” because the wireframe deck is now “signed off.”
  • Wireframes give the impression that things are more polished than they are. I’ve seen designers present early-stage ideas as wireframes. (Perhaps because some folks are uncomfortable drawing freehand?) These artifacts can look very clean and beautiful, leading the viewer to assume that the ideas they present have been thought-through. Often they haven’t.
  • Wireframes are relatively expensive to produce. Given that so many organizations are using design systems these days, building a comp using a tool such as Sketch isn’t that much more work than making a more abstract artifact such as a wireframe.

So what’s a better way of doing it? I prefer freehand drawings, which allow designers to vary the fidelity of artifacts on the fly. Nobody confuses a freehand drawing with a more polished artifact. Freehand drawings are fast, cheap, and disposable; if somebody has a great new idea, you can draw it on the spot. Yes, this requires that designers learn to draw. (I’m still astonished that some people protest this; communicating visually is essential to design work.)

My preferred way of sketching freehand is to use the Concepts app on the iPad Pro. This app treats the lines I draw on the screen as vector-based “ink”; I can select sets of lines and copy them, paste them, delete them, stretch them, mirror them, etc. This allows me to reuse elements (such as window chrome) across drawings, speeding up the process tremendously. Concepts also allows me to share drawings directly to Slack, email, or other channels. The result: very tight feedback loops that enable the design process to move much faster.

What if you’re communicating design intent to developers? In that case, comps or prototypes do a better job than wireframes. It’s not unusual for developers to ask to be sent Sketch files so they can pull out things like colors and element sizes.

Of course, there may be exceptions to all of this. Some teams may have particular circumstances that allow them to move fast using wireframes. Some industries may require them as official documentation. But in my experience, they aren’t very effective. If you’re a stakeholder, don’t waste time and money by asking your designers to create wireframes. And if you’re a designer, learn the basic principles of drawing by hand (such as the use of distinct line weights, how to start and end lines, etc.) You’ll get better results faster.

Design 3.0

| Jorge Arango

My friend Stephen Anderson gave a talk at SXSW 2019 about the future of design. I’ve not seen the presentation itself, but he posted a transcript on Medium. The gist:

Design is in the midst of a shift. A shift that will make much of our present skills obsolete, and demand we learn new skills, or become… irrelevant.

He refers to this as Design 3.0, “a shift from Products to Experiences to Outcomes.” It calls for designers to develop new skills. What sorts of skills? Training machine learning algorithms, monitoring outcomes, modeling possibilities, and reframing the contexts of our work to see the bigger picture. In other words, systems thinking. Design at a higher level of abstraction: designing the thing that designs the thing.

While not a wholly new direction (Gordon Pask was writing about this stuff fifty years ago), technology has finally caught up with the possibilities. So these ideas are very much part of the current zeitgeist. (I’m reading Ann M. Pendleton-Jullian and John Seely Brown’s fabulous Design Unbound, which argues along similar lines. More on that soon.)

Even though the objects of focus for design are changing, the things that make us good designers aren’t. As Stephen rightly points out, designerly approaches such as problem reframing, human-centeredness, and the embracing ambiguity are perennial. They’re also key to doing a good job in this complex new environment.

I’m glad to see design at a higher level of abstraction becoming a thing in the world. I’ve seen few introductions as accessible and compelling as Stephen’s talk; it’s worth your attention.

The Future of Design: Computation & Complexity

Twitter as a Public Square

| Jorge Arango

Managing an information environment like Twitter must be very difficult. The people who run the system have great control — and responsibility — over what the place allows and encourages. In a conversation platform (which is what Twitter is at its core), the primary question is: How do you allow for freedom of expression while also steering people away from harmful speech? This isn’t an easy question to answer. What is “harmful”? For whom? How and where does the environment intervene?

Episode 148 of Sam Harris’s Making Sense podcast features a conversation with Jack Dorsey, Twitter’s CEO, that addresses some of these questions head-on. I was very impressed by how much thought Mr. Dorsey has given to these issues. It’s clear that he understands the systemic nature of the challenge, and the need for systemic responses. He expressed Twitter’s approach with a medical analogy:

Your body has an indicator of health, which is your temperature. And your temperature indicates whether your system more or less is in balance; if it’s above 90.6 then something is wrong… As we develop solutions, we can see what effect they have on it.

So we’ve been thinking about this problem in terms of what we’re calling “conversational health.” And we’re at the phase right now where we’re trying to figure out the right indicators of conversational health. And we have four placeholders:

1. Shared attention: What percentage of the conversation is attentive to the same thing, versus disparate.
2. Shared reality: This is not determining what facts are facts, but what percentage of the conversation are sharing the same facts.
3. Receptivity: Where we measure toxicity and people’s desire to walk away from something .
4. Variety of perspective.

What we want to do is get readings on all of these things, and understand that we’re not going to optimize for one. We want to try to keep everything in balance.

I’d expect the idea to be to incentivize “healthy” conversations over “unhealthy” ones. This would be implemented in the design of the environment itself, rather than at the policy level:

Ultimately our success in solving these problems is not going to be a policy success. We’re not going to solve our issues by changing our policy. We’re going to solve our issues by looking at the product itself, and the incentives that the product ensures. And looking at our role not necessarily as a publisher, as a post of content, but how we’re recommending things, where we’re amplifying, where we’re downranking content.

Twitter has a great responsibility to get this right, because in some ways the system is becoming key public infrastructure. As Mr. Dorsey acknowledged,

Ultimately, I don’t think we can be this neutral, passive platform anymore because of the threats of violence, because of doxxing, because of troll armies intending to silence someone, especially more marginalized members of society. We have to take on an approach of impartiality. Meaning that we need very crisp and clear rules, we need case studies and case law for how we take action on those rules, and any evolutions of that we’re transparent and upfront about. We’re not in a great state right now, but that is our focus. I do believe that a lot of people come to Twitter with the expectation of a public square. And freedom of expression is certainly one of those expectations. But what we’re seeing is people weaponize that to shut others’ right to that down. And that is what we’re trying to protect, ultimately.

As a Twitter user, I was pleased to see the depth of the thinking and care that is going into these issues. I learned a lot from this podcast about the reasons for some of Twitter’s controversial design decisions. (E.g. I now know why Twitter doesn’t have an “edit” button.)

Unfortunately, the conversation didn’t address the elephant in the room: Twitter’s business model. Ultimately, Twitter makes money by showing ads to its users. A good public square shouldn’t attempt to sway our opinions; it should provide the venue for us to form them through engagement with others. How might “conversational health” might be used as a means for persuasion?

Making Sense Podcast #148 – Jack Dorsey

The “Right” Way

| Jorge Arango

Interacting with students is one of the privileges of teaching design at the graduate level. These budding designers are open-minded yet seriously focused on their chosen area of practice, a mindset that offers many opportunities for teaching and learning.

Many of the questions students ask are about the “right” way to do particular things. What’s the right way to diagram a system? What’s the right way to design an interaction? What’s the right way to present this? Is this how a conceptual map is supposed to look? Etc. My reply is often disappointing: There isn’t a “right” way to do it; it depends.

This answer seldom satisfies. But what’s the alternative? There aren’t right/wrong answers in design, only incremental approximations to improved conditions, some of which are preferable to others. Ambiguity comes with the territory, especially at the graduate level. (It certainly does when dealing with clients in “real-world” conditions.)

One of my aims is to help students realize that I’m not there to judge what’s wrong or right; they must develop this sense in themselves. What I can offer is a set of tools and practices that allow them to develop a particular skill: thinking-through-making.

Thinking-through-making is how a diverse group of smart people can come together to solve complex systems problems. These aren’t problems you can solve in your head or by talking with others; you must build models that allow you to externalize your understanding. The act of making the model prompts insights that won’t emerge otherwise. Doing so with others allows the entire group to tap into — and build — their pooled cognitive capacities in an incredibly powerful way.

Thinking-through-making is independent of any particular discipline; it’s evident in architecture, graphic design, interaction design, etc. The feedback loop at the center of the design process is a characteristic shared by all design disciplines. The designer facilitates this feedback loop.

Given the increasingly complex and multi-disciplinary challenges we face, it behooves us to think about design independently of our particular areas of practice. We can leverage our individual expertise in service to bringing diversity to the team; of proposing alternative approaches that may otherwise been missed. But at the core is design, a way of solving problems that doesn’t offer on-the-spot “right” answers but evolves incrementally towards better.

The Client-Designer Relationship

| Jorge Arango

Designers gather input from various sources that affect the direction of a project: There’s bespoke research around the problem space, relevant case studies, regulators (both external and internal), subject matter experts, validation sessions with end users, etc. But there’s one entity that tends to have more influence on the direction of the project than others: the client.

By “client” I mean the entity that has commissioned the design project — i.e., the person or team who is paying the designer to focus his or her attention on the problem at hand. The client has money and reputation at stake; the designer has a contractual obligation to deliver results. The client is tasked with changing the state of whatever is being designed. “We are at point A, and need to get to point Z by X date.” The designer is there to shepherd that transformation through designerly means; that is, by manifesting key decisions in ways that reflect intended changes so they can be tested against reality.

The designer has an important responsibility in creating these feedback loops, but the client ultimately owns the results. This is obvious when the designer is engaged as a consultant – i.e., not an employee of the client’s organization — but is no less true when the designer is an “innie.” Many internal design teams don’t “own” the things they’re designing; they work with counterparts in other parts of the organization who have bottom-line responsibility for the thing being designed.

Charles Eames's sketch of the design process. Image: Eames Office. http://www.eamesoffice.com/the-work/charles-eames-design-process-diagram/
Charles Eames’s sketch of the design process. Image: Eames Office.

The client-designer relationship is central to the design process. Understanding the dynamic of this relationship, and knowing what each party is expected to bring to the process, is key to success. That said, it is up to the designer to ensure that directions are clear. In architectural projects, these directions are often manifest in the form of a brief, or architectural program: a document that lays out the requirements for the project.

The content for this brief must ultimately come from the client, but is formulated in close collaboration with — and often led by — the architect. Architects shepherd what is an initially vague set of requirements towards something more specific and actionable, much like they shepherd design artifacts. The brief is a sort of meta-design artifact that is also designed. Given its importance to the project, the designer and the client must develop it together.


Successful design projects call for relationship-building among all parties involved. Few relationships are as important to the success of the project as that between the client and the designer. At best, these relationships are true partnerships, with both parties having a healthy respect for what the other brings to the project. That said, both parties can’t be expected to have the same degree of understanding of this fact. While this may be the one time in his or her career that the client will be working with a designer, the designer will work with many clients over time. Because of this, it behooves designers to understand the client-designer dynamic and create the conditions necessary for these relationships to be fruitful.

A Data Primer for Designers

| Jorge Arango

My friend Tim Sheiner, writing for the Salesforce UX blog:

demand is high for designers who can create experiences that display data in useful and interesting ways. In my personal experience this became much, much easier to do once I’d learned to speak the crisp, precise and slightly odd language used by technical people for talking about data.

What follows is a phenomenal post that clearly explains much of what you need to know to understand and speak competently about data. A must-read for anybody involved in designing for digital information environments.

Designer’s Field Guide to Data

Towards Greater Diversity in Design Teams

| Jorge Arango

The websites and apps you interact with are parts of systems. These systems are often commercial organizations with responsibilities to various stakeholders, including the owners of the business, its employees and managers, its customers, and — more broadly — the rest of us who live in the society where the organization operates.

The people who “own” these digital products and services — product owners, business line managers, etc. — are tasked with being good stewards of these systems. They’re called to steer them towards greater value for stakeholders in the short and long term even as conditions around the systems change. Design decisions will change these systems — even if slightly. For example, the team could develop a new feature, fix an existing (and underperforming) feature, or address an entirely new user audience.

These are systemic interventions. Their effects are seldom limited to the task at hand; a seemingly minor alteration could have a large impact downstream. As a result, product owners must look out for second- and third-order effects; they’re looking to intervene skillfully as the system faces perturbations in its context.

To do this, product owners must become aware of the possible options open to them and their potential effects. Their ultimate goal is to achieve dynamic stability: for the system to continue serving its intended purposes as it evolves over time to address changing conditions. This calls for these folks to become systems thinkers.

One of the central tenets of cybernetics — the science of systems — is the Law of Requisite Variety. It’s relevant to people who aim to control systems. In cybernetics, the word variety has a special meaning: It refers to the number of possible states of a system. The Law of Requisite Variety suggests that skillful control of a system requires (at least) an equal number of possible responses to its number of possible states. This is usually articulated as a maxim: only variety can destroy variety.

Translation into humanspeak: a system with few possible states requires a small range of responses, whereas a system with many possible states requires a broad range of responses. This idea has proven to be useful in a variety of fields, including sports, ecology, management, medicine, and more. The more complex the system you’re dealing with, the more states it can be in. Controlling such systems requires at least an equal amount of flexibility in your ability to respond to changes.

Of course, not all digital products and services aim to serve the same purposes. Some are simpler — and less ambitious — than others. Simpler systems will have — and require — less variety. But many digital products and services are very complex and can have many possible states. A digital system that aspires to become the de facto environment where we interact — socially, commercially, civically, etc. — will have a huge range of possible states. The folks who design and manage these systems face a great deal of variety. To intervene skillfully, they need a larger range of possible responses. Among other things, this calls for greater diversity in their teams.

Purposeful Governance

| Jorge Arango

Some systems are best left alone. For example, a rainforest can function perfectly well without human intervention. That’s a natural system that evolved into its current configuration over a long time, and it’s likely to continue adapting to changing conditions. (Barring some major environmental disruption.)

Most human-made systems haven’t had as much time to adapt; they’re aggregates of design decisions that may or may not effectively serve their intended purposes. Some of these interventions may truly be in service to the systems’ goals, but others may be driven by political motivations. (That’s one reason why you should think small when designing a system from scratch.)

As with the rainforest, conditions around the man-made system will change over time. How will the system address these changes? Designing the system itself is not enough; the design team must also design the system that continues the ongoing design of the system. We call this governance. Governance, government, governing; they all have to do with ongoing interventions aimed at keeping systems functioning as intended. These terms are all derivates from the Greek word kubernan (“to steer”), which is also the root for the word cybernetics. Governing is a quintessential systemic activity.

When do you intervene? How do you intervene? With how much force? How frequently? Who intervenes? If the intent is to keep systems functioning for a long time, these questions are essential. They also imply a corollary: you must know what you’re governing towards. What’s the purpose of the system? What are its intended outcomes? You can’t steer effectively if you’re unclear on the destination.

The Limits of the Ethical Designer

| Jorge Arango

Curt Arledge writing in his company’s blog:

As our discourse about design ethics matures, we need better models for understanding this big, squishy subject so that we’re not talking about everything all at once. What does it really mean to be an ethical designer? What is most important, and what should we care about the most? What power do we really have to make a difference, and how should we use it?

Mr. Arledge offers a model that divides the areas of concerns in three layers:

  • Interface
  • Business
  • Infrastructure

The stack goes from specific and concrete at the top to systemic and abstract at the bottom. This seems like a useful way of understanding the domain — and especially the parts where designers have the ​most influence on the problem.

That said, design work is medium-agnostic. There’s no reason why designers should constrain themselves to only the layers that have to do with the ​interface. There are many problems at the business and infrastructure layers that would be well-served by strategic design.

This is one of the central points in Living in Information, where I present a similar model. It’s encouraging to see other designers thinking along these lines.

Design Ethics and the Limits of the Ethical Designer