Macrointeractions
“Always design a thing by considering it in its next larger context — a chair in a room, a room in a house, a house in an environment, an environment in a city plan.” — Eliel Saarinen
Roughly four and a half years ago, a few months before Windows Phone 7 was shown at 3GSM, Albert Shum and I were discussing some ongoing projects and the challenges ahead. At some point he casually said “We’re going to need apps”.
Yes, we were definitely going to need apps. Before he mentioned it though, I hadn’t really thought about it much — we had been focused completely on the design of the product.
“We should do something about that.”
I wasn’t really sure what he meant. What were we supposed to do? We were the product design team. We design the phone, and then developers build the apps.
It’s painful to recall this conversation now, and to know that I thought about the problem in this way. But I also think of this conversation fondly as the beginning of an ongoing shift in the way I think about what my role as a designer is and can be. Up until that time, everything I had studied and worked at in design was focused on the skills and processes for designing and building tangible products. The intended outcome of my work was the making of a singular thing, the best thing that could be made for the design problem at hand. Once designed, other teams were responsible for marketing it and making it available to the people we designed it for. And then people buy it or use it. Somehow.
As I’ll assume everyone knows well today, a good phone isn’t just the quality of the device in your hand, it’s the sum of the apps and services and accessories and cases and connected devices around it. If we wanted Windows Phone to be a great product, we would need to think of the product ecosystem as being a design problem as important as the product software.
This kind of ecosystem problem isn’t unique to phones. For me personally, the way my conversation with Albert (and the work that followed) shifted my thinking has become generalized this way: if I want the products I work on to be great, I need to think of the spaces adjacent to the product as being a design problem as important as the product itself. Though a lot of the Design canon is focused on the quality of craft — the details make the product after all — a lack of attention to the problems around the product may mean very few people ever experience all your attention to detail.
I’ve started to find it helpful to think of the problem space around the product as a Macrointeraction — an interaction design space at the other end of the spectrum from a Microinteraction. Any friction that might prevent your product (with all its wonderful details) from being made or connecting with your customers is a design problem worth spending time on.
In the years since my conversation with Albert, I’ve learned to look for three categories of problems around the products I’m designing that may prevent the product from being built or from reaching the people we’re designing for. Once you begin to look for and recognize these problems, you can start to approach them the same way you would any other design challenge.
1. Network Defects
The most successful products today have some kind of ecosystem that supports them. This might be a network of users, a developer community, or accessories made by third party manufacturers. A supporting ecosystem not only makes the products it supports better for customers, it creates an environment that is extremely difficult for competing products to enter. A challenger can’t catch up just by working harder or faster to build a better product — they need a comparable ecosystem to grow around them. Building a competitive ecosystem makes the competitor dependant on resources they don’t have direct control over.
Once we decided that apps were a problem that we wanted our design team to spend time helping out on, we approached it like a design problem. We needed to understand who would and wouldn’t be interested in developing apps, why developers would or wouldn’t want to build apps, what information was and wasn’t helpful for developers to design apps, and what kinds of tools developers were going to need to get started. It was tempting to just start designing apps ourselves — designing apps was a very familiar kind of work — but the best solutions to the problem came from thinking about the developer scenarios above. To connect with developers, we wrote publicly about our design thinking, we presented at design and developer conferences, we held online workshops, and we hosted designer and developer events. To help developers get started we published guides, we published templates, we published tutorials, and we held hands-on workshops where we worked side by side with third party developers. All of these efforts took a lot of time and energy from our product designers. Some of these approaches may seem obvious (if they do, great!), but at the time, as a design team we were not in the habit of creating these kinds of events and materials.
Here are a few other examples where teams have focused on growing a network from scratch:
Reddit: All of Reddit’s content comes from and is curated by its massive community of Redditors. Of course, that community didn’t exist when Reddit got started, so the founders simulated it. For the first few weeks after the site launched, most of the content came from the founders submitting posts and comments themselves, using a collection of usernames that they managed. The activity on the site that the founders simulated made the site feel like it already had a thriving community, which attracted others to join in. I suspect that in most designers minds Reddit is a bit of a hot mess, but it’s one of the most active and popular products on the web.
Pinterest: When Pinterest launched, its growth got off to a slow start. Three months after launch they only had 3,000 registered accounts, and it wasn’t attracting much attention from the tech press. Rather than pivoting the product, the founders focused on getting to know the users who already loved the product. They organized meetups with their users to gather feedback and make the product better for them. They built tools and designed programs for their most well connected users to spread the word about Pinterest. They built a community by working directly with their first users.
Medium: When Medium launched, its content was publicly available for anyone to read, but writing on the platform was exclusive. For the first year, Medium was able to groom its content and brand voice by inviting the people that they hoped would write the kind of articles they wanted on their product. In some cases, they paid writers as well. It wasn’t long before you knew very well what you could expect from a Medium post. Even though writing on Medium is open to anyone now, the content and quality remains relatively the same. By seeding their ecosystem with a specific type of author and content from the beginning, they set themselves up to attract and grow the community they wanted.
2. Barriers to Entry
Before someone uses your well designed product, they need to hear about it, they need to know about it, they need to find it, they need to try it, and then they need to choose it over any alternatives. While most of a product designers focus will tend to be on how the product works in regular use, there are many barriers that will get in the way of people trying any new product in the first place, let alone using it regularly. Similar to challenges involved in building a product ecosystem, the barriers that prevent you from connecting with your potential customers will likely show up outside the normal bounds of what you think of as your team’s immediate responsibility. Good product teams will spend a lot of time thinking about the first use or “out of box” experience. Marketing teams will work on getting the word out. But that might not be enough.
While working on mobile phones at both Microsoft and Nokia, I became familiar with some scenarios where it was especially tough to directly connect with people the way we would have wanted to. When you walk into a mobile operator store, the agent that greets you is going to lead you to one of the phones that store (or the agent helping you) prefers that you buy. Even if you know exactly the phone you want to buy, they might try to talk you out of it if they have a strong preference. That preference may be based on the phone model or models that the agent personally uses or is familiar with, because they know the product well and will be better able to answer questions about it. They may have financial incentives from some phone manufacturers that will determine which model they will try to get you to buy. Similarly, the mobile operator might have a partnership or competitive strategy in place that will strongly encourage the store agents to sell a particular model.
Generally, the phones near the front of the store are phones they want you to buy, and phones at the back are not. All of the above scenarios create significant entry barriers for any company trying to bring a new phone to the market. As a designer, if you’re focused completely on the experience quality of the phone you’re working on and are not involved in figuring out how you will get the product into people’s hands — or at least aware of how that problem is going to be solved — then there’s a good chance the people you’re designing for won’t even have the opportunity to try your product.
For products on the web, the problem is different. Your storefront is likely your own url, but it’s even easier to bounce out of a webfront than a physical store. Once people have stopped by your site, how do you simultaneously help them understand why they should care about your product without adding a lot of friction to the entryway? This is a problem that we spend a lot of time working on at Twitter.
One way to get to know the kinds of barriers that sit in front of your product is to regularly start fresh with the product you’re working on. Not just from the unboxing or signing up with a new account, but from the earliest possible touchpoint. Consider how someone would first learn about your product and try to start there. Walk into a store that’s selling it and try to buy it. Follow your marketing links and see where they take you. Even better, follow a friend or family member along their journey. Even even better, work with a professional researcher to observe people you don’t know. Pay attention to all the ways you’re failing to connect with people before they even have a chance to get to the “core” product experience. The main point being, don’t just test whether people understand how your product works, test whether they can can even get to the product.
3. People and Process
You need a strong team to design, build, and ship great products. Collaboration is hard, and there are many ways that teams can be pulled apart, or for friction to destroy to progress. For example: unclear roles and responsibilities, ineffective processes for design and development, overly complex processes, personal conflicts or power struggles, poor decision making, a lack of strategy or vision, an inability to execute, or poor quality control. Compared to Network and Entry problems, these types of internal problems are the closest to you, so you can address them directly. On the other hand, these problems are often political, cultural, personal, and emotional, so they aren’t necessarily easy to solve. Sometimes they are the hardest of all.
“We start from the presumption that our people are talented and want to contribute. We accept that, without meaning to, our company is stifling that talent in myriad unseen ways. Finally, we try to identify those impediments and fix them.”— Ed Catmull, in Creativity, Inc.
A couple of years ago we went through a rough period in the Twitter design studio. Every team and every company has its ups and downs over time. Fast growing teams and companies are especially vulnerable to some emotional volatility as people adjust to change. We were in a low point, our productivity was dropping, and we were starting to lose some of our designers because of it. It was tempting to keep our heads down and just try our best to keep pushing work forward. Instead, we let some work slide and focused our energy on the team. We spent a lot of time listening, rebuilding trust, and repairing relationships across the team. We changed the way we worked based on feedback from the team. We started having “Design Open Houses” to celebrate and share the work that the team was doing. We still lost some designers in the slump. But instead of letting that be a downer we began to throw “Leaving the Nest” parties for them on the way out, to share stories about them and send them off with good memories of the team. It wasn’t long before the mood changed and we were able to refocus on the work. Ever since then, we are always looking out for relationships on the team that may be becoming stressed, and evaluating how our tools and processes are working for our designers (or holding them back).
You cannot mandate productivity, you must provide the tools to let people become their best. — Steve Jobs.
People and process problems can extend beyond your own team, to how your team interfaces with partner teams like Product Management, Engineering, Marketing, or Executive Leadership. As you begin a project, consider everything that you’ll need to be successful: Which relationships you’ll need to build, what people you’ll need on your team, which processes will need to be in place, and what skills or tools you’ll need. Building the team, skills, tools, and relationships will take dedication and energy in the same way as doing great design work.
Out of the details
So why “Macrointeraction”? There are more traditional labels (and distinct disciplines) that apply to these problems: Evangelism, Marketing, Public Relations, Product Management, Strategy, Operations, Human Resources, and Business Development to name a few. Thinking of these problems under traditional labels makes it easy to think of these problems as being someone else’s job. Since these problems affect the product you’re working on, they are worth getting to know, and considering how you might help. If you’re light on design resources, it may make more sense to stick to your usual product work. But if you can give yourself or your team the time, start looking out for these larger interaction problems. There are many days where I find myself debating a design detail with a few other members of the Twitter design team and realize that the time I spend adding my opinion to the mix might be more effectively spent looking out for other blind spots around us.
As designers, we hold work with carefully polished details in high regard. But there are many ugly products that succeed for their users by getting their marketing or distribution right. And there are beautifully detailed products that fail for lack of consideration of its price, who it’s for, or how people will find it. An intense focus on design details can be blinding. Throughout your process, continue stepping back from your work to consider the bigger picture interactions around you and the product — they may have a lot more impact on your product’s ability to succeed.
