Process

More Effective Remote Brainstorming

| Jorge Arango

Art Markman writing in the Harvard Business Review blog:

In the age of Covid–19, many of us are no longer working together in the same rooms — but we still need to generate ideas collaboratively. Fortunately, even in a remote environment there are several approaches that can help you solve complex problems effectively.

I’ve tried to facilitate remote brainstorming sessions during the pandemic, and have found them to be less effective than in-person sessions. The article provides suggestions worth checking out. Some, such as getting specific beforehand about the issue to be considered and thinking carefully about who should be in the session, are applicable to non-remote brainstorms as well. I’m most intrigued by the suggestion that initial rounds happen asynchronously, since it matches how I’ve been approaching recent remote brainstorming sessions.

Why are remote brainstorming sessions less effective? For one thing, the interpersonal dynamics of collaborating remotely are different, as is the environment where the collaboration happens. People’s attention is more scattered when meeting over apps like Zoom. And as impressive as they are, visual collaboration tools like Miro and Mural are no replacement for meeting in a room with a large whiteboard; there’s still too much friction in manipulating digital representations of sticky notes. (I’ve had better success with collaborative text-editing tools like Google Docs, but the linear text format doesn’t encourage exploring rich relationships between concepts.)

What to do? I’ve been gravitating to the solution Mr. Markman proposes: having participants do an initial round of thinking on the virtual whiteboard before joining the shared session. This reduces the time it takes to capture their thinking and “primes” the board; the other participants can more easily riff on what is already there.

One possible downside is that this requires that participants read what is on the board, which takes time. A way to resolve this is by assigning pre-meeting work in rounds: you set a deadline for everyone to put their thoughts up on the board and a subsequent deadline for everyone to review the rest of the team’s work, noting any questions they may have. With this approach, you can start the synchronous part of the work by reviewing these open questions.

I’ve not yet facilitated remote brainstorming sessions that are as effective as the in-person variety, but I’m getting better. And as the article points out, there may even be advantages to these new ways of working. The pandemic is forcing us to discover more effective ways of collaborating remotely; these are valuable skills that will pay dividends long after lockdown measures have eased.

How to Brainstorm — Remotely

Internal and External Language

| Jorge Arango

One of the keys to designing an effective information system is defining the concepts people must understand to use the system. What are its key components? How do they relate to each other? How do they differ? What should we call them?

This last question is especially important. The words we use to label system elements affect how people understand them and the system as a whole. Terms people are familiar with can make the system more learnable. However, familiar terms may also raise undesirable expectations.

Proposing “good” language requires that we understand both the system and the people who need to use it. How do these people see the conceptual domain? Do they already have words or phrases to describe comparable features or functionality? Are any of these terms ambiguous or otherwise misleading?

Answering these questions is why we do research. Concept maps are useful artifacts in these early research stages of projects. Although these maps are abstract (and therefore potentially confusing), they can elicit feedback on whether we’re creating useful distinctions and labeling them with understandable terms.
Continue reading →

Slack’s Information Architecture Redesign

| Jorge Arango

The coronavirus pandemic has forced many of us to work remotely. The crisis has made digital collaboration environments more critical than they’ve been before. Many of us are spending significant portions of our days conversing with colleagues in places like Slack and Microsoft Teams. The latter’s usage has more than doubled during the crisis. And in a Twitter thread, Slack’s CEO, Stewart Butterfield, noted a surge in demand due to the pandemic:

When you have that many people working in an information environment, the structure of the place matters. Clunky navigation systems can lead to confusion, wasted time, misunderstandings, increased need for support, and more. The pain is especially acute for new users, who may be unfamiliar with how to find their way around such environments.

Last week, Slack announced a redesign that aims to clarify the environment’s navigation systems:

Continue reading →

Seeing Wide and Deep

| Jorge Arango

A version of this post appeared previously in my newsletter, which comes out every other Sunday.

Teams that manage or design digital products are often narrowly focused on their domains. These teams care about the needs of their stakeholders and users, the features that will accommodate those needs, the rollout of those features over time, their performance (financial and otherwise), the constraints and possibilities of their infrastructure, etc. It’s a lot to track.

These folks must maintain this focus to produce results — especially if they’re working in complex domains. But there’s a risk: by so focusing their efforts, they can become inwardly-oriented, missing opportunities to innovate. For example, I’ve worked with product teams who have trouble seeing outside of their industry. As a result, they understand their offerings primarily in relation to what competitors are doing. These teams would benefit from an external perspective.

There’s another field that has embraced an “outsider” role in the creative process, one which may be worth emulating: the music industry.

Think of a pop song you love, one that brightens your day. You likely know the name of the artist who sings it. However, creating a successful song isn’t only up to the artist; there’s a team behind most hits. One of the key members of this team is the music producer.

The producer isn’t the song’s author or performer. Instead, the producer works with artists to help them reach their potential. Among other things, the producer helps them anticipate trends, break out of ruts, find new uses for innovative technologies, identify and recruit collaborators, manage the recording process, and generally shake things up by helping artists experience their work in a broader context.

To do these things, the producer must know the workings of the studio, the economics and politics of the industry, the past and present of the genre, what other artists are doing, and more. Few musical artists can master these skills while also excelling at writing and performing their music. One way to think about it is that where artists go deep, producers go wide. It makes for a powerful partnership.

I don’t think such a role currently exists in product organizations, but it should. (I suspect it must be played by an outsider, someone not looking to “join the band.” One of the ways producers add value is by cross-pollinating frameworks.) Teams that can see deep and wide can better understand the boundaries of their systems and articulate more clearly the problems they’re addressing. Teams with a broadened perspective can see and connect dots that others miss, revealing new opportunities.

How Designers Can Help Bust Silos

| Jorge Arango

When I talk with folks in large organizations, I often hear a familiar lament: “We’re very siloed here.” By this, they mean the organization is divided into​ groups that don’t play well with others. Each group functions like an isolated “silo” that acts independently from the rest. They each have their own internal goals, incentives, processes, etc. which make it difficult for them to collaborate.

Siloing impedes the organization’s ability to respond effectively (and in a timely manner) to changing contextual conditions. Because it involves organizational cultures and incentives, it can be a tough challenge to overcome. People in silos have an especially hard time seeing things from others’ perspectives — especially their colleagues.

A big part of the problem is that people in these situations​ tend to communicate in abstract terms. Often they’re unaware of using language that reinforces the distinctions between them. With our emphasis on making things tangible, designers can help them bust through these barriers.

Continue reading →

Chuck Jones and the Power of Discipline

| Jorge Arango

Every Frame a Painting has a fantastic analysis of the work of master animator Chuck Jones:

As the video points out, Jones’s work has stood the test of time. Why? The video teases apart the elements that make Jones’s Looney Tunes cartoons work:

  • A two-part gag structure that 1) leads the viewer to make an assumption, and 2) proves that assumption wrong.
  • An emphasis on building character.
  • The discipline to abide by “the challenges and restrictions you set for yourself.”
  • Being open to inspiration from the real world.

The combination of these simple rules led to some most effective — and funniest — short films ever made. (Including my all-time favorite, One Froggy Evening.)

While all the rules are important for storytelling​, I consider discipline paramount since it transcends the medium. When creating a complex work (be it a book, a website, or an animated cartoon), you’re establishing a little universe with its own logic and rules. One of the central concerns of the creator is ensuring that this logic is internally coherent. While can sometimes be tempting to make exceptions for the sake of expediency, such exceptions often point to structural deficiencies, which left unresolved can ruin the work.

Having the discipline to abide by constraints (self-imposed and otherwise) is key to producing good work. Chuck Jones’s cartoons ultimately stand the test of time because of his insistence on abiding by the rules.

Chuck Jones – The Evolution of an Artist

Direction and Action

| Jorge Arango

Invariably, the most popular posts on this site are the ones that deal with tools and practices. Whether I’m railing against wireframes or showing you a way to make language visible, if it features a concrete tool or technique, the post is likely to have traction. This doesn’t surprise me.

My tool-centric writings fall on the craft end of the craft ↔ philosophy continuum. Philosophy is a harder “sell” than craft. Most people would rather know what to do rather than how to think; they want things they can put in practice on the proverbial “next Monday morning.” The more actionable something is, the better.

Except that action can be undirected. And effecting action towards the opposite of “Good” (perhaps unintentionally) makes things worse. Direction without action frustrates; action without direction muddles.

I don’t aspire to give direction in my more “philosophical” writings. Instead, I’d like you to entertain the possibility that direction matters, and that you ought to discover one for yourself. The world provides ample evidence of things that are going well and things that could be better; it’s up to you to determine what those are and what you can do about them.

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 to 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.