Marty Cagan has some really insightful thoughts (as usual) on autonomous teams in Autonomy vs. Mission:

In healthy teams and organizations, the way we normally reconcile these views [where the team might have one perspective and the leadership might very well have another] is that the leadership has control of two major inputs to the decision process. The first is the overall product vision, and the second are the specific business objectives assigned to each team.

Problems arise if the leadership does not provide clarity on these two critical pieces of context. If they don’t, there’s a vacuum and that leads to real ambiguity over what a team can decide and what they can’t.

The section on how to ensure consistency in design across different teams is also really good:

In the name of empowerment and also speed, my personal preference is to invest in the necessary automation (with pattern libraries and style guides) so that the team can get the design (interaction and visual) mostly right pretty easily, and acknowledge that on occasion, you will incur some “design debt” where we realize that the design needs to be corrected, and that’s fixed as soon as the problem is spotted. I like this approach because the manager of design is still responsible for developing a strong set of designers, but doesn’t have to be in the review cycle for everything (which tends to slow things way down, as well as undermine autonomy).

John Willshire wrote a good post on the difference between fidelity and resolution in design. From Want to improve your design process? Question your fidelity:

For us, fidelity is all about the people axis; how close is this to the real world? That’s the future point, when the product is out in front of lots of people, being used often, at scale. If you want to increase fidelity, then you show whatever you have to more people.

Which leaves the vertical axis, things, to be all about resolution. Resolution is a much more technical description of what we have in front of us, used across many different fields to description the detailed specifications of what the thing involves. It’s been much more useful when you’re using that language around the thing you’re working on.

There are some good illustrations in the post to make the point clear. I think this is a pretty important distinction, since it shows how user feedback can be helpful during each phase of a project.

I’m having a hard time with Alex Schleifer’s (Airbnb’s head of design) proclamations in Why Airbnb’s New Head of Design Believes ‘Design-Led’ Companies Don’t Work. There are a lot of sweeping generalizations in the article, but I’ll focus on one specific part — user-centered design. First, this:

The solution Schleifer and CEO Brian Chesky devised actually deemphasizes the designers. The point, Schleifer says, isn’t to create a “design-led culture,” because that tends to tell anyone who isn’t a designer that their insights take a backseat. It puts the entire organization in the position of having to react to one privileged point of view. Instead, Schleifer wants more people to appreciate what typically lies only within the realm of designers—the user viewpoint.

So far, so good. It makes total sense to bake user empathy into the process and not elevate it to some elite role. Let’s continue:

Thus, every project team at Airbnb now has a project manager whose explicit role is to represent the user, not a particular functional group like engineering or design. “Conflict is a huge and important part of innovation,” says Schleifer. “This structure creates points where different points of view meet, and are either aligned or not.”

Ok, this is good too. This is usually the role the product owner or user researcher or UX designer should be fulfilling (if they’re not, something’s wrong). But if we need to call it something else to avoid stepping on toes, that’s fine. Let’s keep going:

Airbnb’s approach does seem fairly novel, simply because it deals with a problem that bedevils any product company to one degree or another: Designers tend to design for themselves, whether they intend to or not.

I agree with this, and have written about the phenomenon before in Designer Myopia: How To Stop Designing For Ourselves. But then the author goes on to say this:

User research, meanwhile, often has limits. It’ll tell you what’s wrong, but it only rarely leads directly to great products. A true user perspective is something more nuanced, specific, intuitive, and independent.

This is where he loses me. User research is not just usability testing that tells you what’s wrong. It’s also ethnography and contextual inquiry and participatory design and in-depth interviews and a slew of other things that result in exactly what they are trying to accomplish: a user perspective that is “nuanced, specific, intuitive, and independent.” As I point out in that designer myopia article:

We do ethnography to learn, not to confirm our beliefs. By using this method to understand the culture and real needs of our users, we’re able to design better user-centered solutions than would be possible if we relied only on existing UI patterns and some usability testing.

Leaving the office and spending time observing users in their own environments is the best way to understand how a product is really being used in the wild. It’s the most efficient way to get out of your own head.

I would love to know how Airbnb proposes that their project managers get these perspectives without qualitative user research, i.e. direct contact with customers.

Articles like this make for great “you’re doing it wrong” headlines, but they are often so light on detail that you’re just left feeling bad about yourself without knowing why (or how to fix it). So I just want to say, don’t let them get to you. Keep doing what you’re doing. Conduct observational user research in context, triangulate your results, and speak up for user needs. There’s no evidence to suggest that those methods have stopped working.

Beth Kowitt’s How Ikea took over the world is a great look inside the Ikea machine. For me, the biggest takeaway is how research and prototyping drive everything Ikea does. On research:

One way Ikea researchers get around this is by taking a firsthand look themselves. The company frequently does home visits and—in a practice that blends research with reality TV—will even send an anthropologist to live in a volunteer’s abode. Ikea recently put up cameras in people’s homes in Stockholm, Milan, New York, and Shenzhen, China, to better understand how people use their sofas. What did they learn? “They do all kinds of things except sitting and watching TV,” Ydholm says. The Ikea sleuths found that in Shenzhen, most of the subjects sat on the floor using the sofas as a backrest. “I can tell you seriously we for sure have not designed our sofas according to people sitting on the floor and using a sofa like that,” says Ydholm.

And on prototyping:

Products under development go through rapid prototyping in the pattern shop to provide a sense of what they will actually look like in the flesh—or at least in plastic. On a recent visit, one of the four 3-D printers was outputting a toilet brush. Apparently this is one of the more normal items. “We have a lot of strange things,” says Henrik Holmberg, who manages the department. “That is very good that we can do it in our own shop rather than spreading the crazy ideas externally.” One of the oddest things he’s ever worked on was a lamp made from the same material as egg cartons. “I thought that was very crazy,” he says, “but we proved the technique was possible.”

Great article on the power of user-centered design.

I’ve been spending way more time with Google’s Material Design guidelines than I ever thought I would, but such is life.

Anyway, as I was going through it, and started to think about the Android side of an app I’m working on, I tweeted this:

Concerned about Material Design’s reliance on label-less icons. Pretty sure most users don’t know what these mean. pic.twitter.com/aH1IZvAyG6

— Rian van der Merwe (@RianVDM) March 11, 2015

That screenshot is from the section on Icons in the guidelines, but it’s not the only example. The whole document is full of screen shots of label-less icons. There’s not a single label in the section on Typography.

There’s lots of research about why this is a bad idea, but I’ll just cite two articles on the topic. First, Aurora Bedford sums it up nicely in Icon Usability:

A user’s understanding of an icon is based on previous experience. Due to the absence of a standard usage for most icons, text labels are necessary to communicate the meaning and reduce ambiguity.

And Josh Porter also makes a good point in Labels always win:

I think labels should be kept around in almost all cases as they turn guesses into clear decisions. Nothing says “manage” like “manage”. In other words, in the battle of clarity between icons and labels, labels always win.

Beyond that, there’s also plenty of evidence from A/B testing that even much-used icons like the hamburger menu is simply not well understood (see Hamburger vs Menu: The Final AB Test). So, be kind. Label your icons.

Update March 16, 2015

I’ve received some interesting and helpful responses from the Android community:

@RianVDM Agree, but they are labeled here which I have used countless times https://t.co/GYVxBoCOH9

— Mike Arney (@mike_arney) March 16, 2015

@RianVDM on Android a long press should show you the label of the icon, it’s required when you develop an app for Android

— Omar Tosca (@otozk) March 16, 2015

My day didn’t start great. The first thing I read was Michael Dubakov’s statement about enterprise software people (i.e., people like me) in Enterprise software vendors have no taste:

My current theory is that enterprise software vendors have no taste. CEO, VP of development, Product managers that focus on enterprise market — all of them have no fucking taste. There is no taste in companies [sic] DNA, nobody cares about design and aesthetic. Profits, revenue, sales and new features — yes! Beautiful design — no.

Nobody, you guys. Literally nobody. I guess I don’t blame Michael for this false cause fallacy. It sure seems like a logical conclusion: product bad, therefore product person bad. As with most things, though, it’s more complicated than that.

Let’s start with the most difficult thing about designing in the enterprise space: in most cases, the people who buy the software and the people who use the software are completely different, and therefore have completely different needs. This is not a problem in the consumer market, where the person who gives you money is usually also the person who uses your product.

The people who buy enterprise software — IT managers, HR managers, etc. — care about things like configurability, control, more features than a competitor, and most of all: the ability to customize the thing just so, so that it fits in with whatever systems already exist. End users care about none of those things. They care about getting a job done as quickly and with as much enjoyment as possible.

So, what happens is what happens in most organizations that rely on outside sales. Many Sales teams go out and sell things that don’t exist in the product. And they often sign contracts that have two things in it that make designers wake up in a cold sweat: (1) a list of features (or — ugh, I hate this term so much — “product requirements”), and (2) delivery dates.

Product people then have to fulfill the needs of the contract/promise (as opposed to the needs of end users) in never enough time. Instead of having the time to understand a problem and user needs, building hypotheses and testing them, and taking time to iterate, they make a thing to hit a deadline and then move on to the next thing that has a deadline.

And that’s why enterprise software looks the way it looks. It’s not that product people don’t have taste. It’s that they don’t have agency.

But, I do want to say, there are welcome signs that this is changing. There is a new realization that the needs of buyers and end users can co-exist peacefully, and the result is better products. As an example, our new CEO is a huge advocate for design, and is pushing the organization to create “simple, smart, beautiful products.” This will take time, of course, but if you look at the new suite of apps that we’re working on, you’ll see that these are starting to look more like consumer products.

There are other things I think we can do to help along this shift:

• Train sales teams on the ins and outs of product development. How prioritization works, how long things generally take, what the major user needs are that the product is trying to solve, etc. If they have more knowledge about how their promises affect the teams, it will go a long way to change behavior.
• Spend as much time with end users as possible, record the sessions, and share it widely. Nothing gets an organization riled up about good design like seeing end users struggle with a product.
• Start on a small product that no one cares about (like the mobile site maybe?). Follow a Lean UX process (or whatever methodology you subscribe to). Build it well, and show people the results. Then start moving the process into other areas.

So, anyway. Yeah, enterprise software is still, for the most part, pretty bad. It’s time for us to break out of the constraints of the past that caused that, and do something better. It’s actually a good time to be in enterprise software. There’s so much opportunity, and a newfound agency for designers. I’m optimistic. The day can only get better from here.

I’ve been thinking about product feedback. We do alot of it at Jive, since most of our work happens in the open. It’s one of my favorite things about Jive and I wouldn’t change it for the world. We all want to make the best product possible, and you can only get that if you put everyone’s heads together.

So I’ve been thinking about how we can make sure we give each other good feedback. I went back and reviewed some of the things I’ve learned over the years about what makes product feedback useful. I wanted to share three articles in particular that have been really helpful to me. I’m going to try to use these techniques more, and I invite you to join in.

First, Mike Monteiro wrote a great post called How To Give Better Design Feedback (it’s now mysteriously gone from the internet, but I managed to resurrect a copy from my Pinboard archive and post it on Evernote). This part, in particular, is a great point to remember:

First rule of design feedback: what you’re looking at is not art. It’s not even close. It’s a business tool in the making and should be looked at objectively like any other business tool you work with. The right question is not, “Do I like it?” but “Does this meet our goals?” If it’s blue, don’t ask yourself whether you like blue. Ask yourself if blue is going to help you sell sprockets. Better yet: ask your design team. You just wrote your first feedback question.

Cemre Güngör’s How to give better product feedback is also a great article to go through, and this is some good advice:

Describe objectively what you expected and what the product delivered (or fail to deliver). Speak about your particular experience “I got confused when I used this…” instead of generalizing “This is confusing…” or speaking of hypothetical user-beings “Users will get confused…”. This should help disarm the team and empathize.

The worst kind of generalizations speak on behalf of the whole wide world: “Nobody will like/use this”. Being dramatic is unlikely to make the product team start thinking about their work in a new context and change their ways.

But my favorite article on this, because it provides such a great framework for feedback, is Jared Spool’s Moving from Critical Review to Critique. The whole thing is fantastic, and it goes over how to structure a good review. Here’s the gist:

What makes a critique different from a critical design review is we are not there to find flaws. We’re there to learn from the design and to explore where it works well and where it could be improved.

In a well-run critique, we explicitly separate out the discussion of “What are we trying to do with this design?” from the discussion of “Does this rendition accomplish it?” By separating out these two pieces, we avoid digging into the designer’s work just because they unaware of a critical requirement or need.

This part is particularly effective:

The audience also now can explore the design. Often this is done, not with critical commentary, but with exploratory questions. “Have you thought about how users will share the photos with their friends?” “Have you considered how the application works when there’s no network connectivity?”

By posing their thoughts as questions, the designer can say whether they’d thought about that issue or not. If they have, it gives them a nice chance to talk about their thinking. If they haven’t, well, they just say, “No, hadn’t thought about that yet.”

If you have any other tips on giving good feedback, please let me know!

Lukas Mathis’ False Dichotomies is a great post about how quickly design feedback can turn into an argument about the wrong things:

In creative endeavors, tribal, black and white thinking can be problematic, because it prevents you from noticing all possible options. Whenever the discussion veers from «how can we solve this problem» to «should we pick option A or option B», you need to take a step back, and ask yourself — and your team — if these are really the only two options.

Is there any kind of middle ground?

Are there entirely different approaches we didn’t consider?

Are there valid concerns the other group is raising, and can we take these concerns into account without completely dismissing our own concerns?

The Paradox of Empathy is such a great post by Scott Jenson that I pretty much want to quote the whole thing. But I’ll stick with just this one gem, and encourage you to read it in full. It is a fantastic exploration of empathy in design, and includes a framework for making empathy part of our everyday work in a very practical way:

Designers will be the first to admit that not every empathic observation leads to a miraculous insight. However, it’s called “Design Thinking” for a reason: it’s how we process and explore, taking a complex problem and breaking it down before we build it back up. Product managers seem to expect a designer to walk up to a product, say something brilliant, and drop the mic. Experienced designers deeply understand a simple fact: design isn’t a deliverable, it’s a process. A process paved with dozens of small empathic observations that lead you, slowly, iteratively to a better product.

The problem for us designers is that our fellow teammates don’t always think this way and unfortunately, we as a community don’t reflect on this difference. It’s ironic that designers are passionate about how a product interacts with people but not how they themselves interact with their team.

I’ve been spending a lot of time thinking about how product design decisions aren’t neutral. The way we design a product has a direct effect on how people use it. This is obvious, but I think we often forget the real implication: Design wants something from its users. And we are the architects of those wants. We have a direct impact on user behavior, and we need to recognize the weight of that responsibility.

Let’s look at some recent product changes on Twitter as an example.

In October 2013, Twitter introduced more visual tweets, with photo previews within the timeline. It’s almost hard to imagine now, but before they introduced this you had to click on a link before you could see a photo.

This change had an immediate effect on how people used the product. I’m sure some of it was intentional — people began to tweet a lot more photos. Some of it was probably not intentional but still made sense: social media marketers caught on to the fact that if they attach a photo to an article tweet, they’ll get more attention since the tweet will take up more screen real estate. A little annoying, but ok, so far so good.

But then there was what must have been a fairly unexpected behavior change. People started to use screen shots of text to bypass Twitter’s 140 character limit. At first, only a few people did it. But then publishers and marketers started to notice, and it took off:

Yes, it’s crazy to share text as images on Twitter. But, look at the engagement increase: https://t.co/VRVglh6Bei https://t.co/ePo3pGtep0

— Chris Dixon (@cdixon) November 20, 2014

Some have even come up with guidelines for the best way to stand out in these “textshots”:

Following an exchange with MG Siegler a while back, I settled on a specific textshot style: sans-serif text with a sepia background pulled from Pocket. The idea of using the app’s sepia theme for these came from MG, who noticed that yellow screenshots had more contrast in Twitter’s native apps.

I’ll admit, the temptation to do this is strong. Earlier this week I used a textshot and it became my most retweeted tweet ever:

This post by @scottjenson on empathy in design is so good: “The Paradox of Empathy” - http://t.co/9mYXqWEVP0 pic.twitter.com/J3lekmt5DW

— Rian van der Merwe (@RianVDM) February 24, 2015

Nice, right? Win!

But wait… Let’s step back for a moment and have a look at the metrics on that tweet of mine:

Almost 25,000 impressions, with a 0.9% click-through rate. That’s worse than a crappy banner ad, and it’s the sum-total of the amount of traffic I sent to Scott’s excellent post. As Derek Thompson points out in The Unbearable Lightness of Tweeting:

Is the social web just a matrix of empty shares, of hollow generosity? As Chartbeat CEO Tony Haile once said, there is “effectively no correlation between social shares and people actually reading.” People read without sharing, but just as often, perhaps, they share without reading. […]

There used to be a vague sense that Twitter drives traffic, and traffic drives renown (or fame, or pride, or whatever word defines the psychic benefit of public recognition). Instead, the truth is that Twitter can drive one sort of renown (there are some people who are Twitter-famous), and traffic affords a different psychic currency. But they are nearly independent variables.

All of this culminated in Medium’s Text Shots announcement yesterday:

So there you have it. There is now a very real chance that most of our Twitter timelines will become nothing but screenshots of Medium articles that no one reads. That doesn’t help Medium, it doesn’t help authors, and it frankly doesn’t help us to experience and learn, which is kind of the point of reading. This trend does help Twitter, though. Quoting from The Unbearable Lightness of Tweeting again:

In the last month, I’ve created nearly 2 million impressions for Twitter. Whether that is good for my Twitter persona and my pride is a qualitative question whose answer resides outside the bounds of an analytics dashboard. But it is quantitatively not a good deal for The Atlantic. Something I already suspected has now been made crystal clear: 99 percent of my work on Twitter belongs to Twitter.

Twitter is a business, and impressions are how they make money, so this isn’t inherently evil or wrong. But Twitter is, if nothing else, not what we think it is. Not to get too curmudgeonly about “early Twitter”, but there was something amazing about the 140 character limit. Something about the constraint that brought out people’s creativity. And because it was all text, timelines were easy to scan. Now, all of that is different.

Putting all my personal feelings about this trend (and its implications on traffic and reading) aside, it’s time I get to the point. This fundamental change in the way Twitter is used can all be traced back to a single, fairly simple design decision back in 2013: expanding photos natively in the timeline. Without that change, none of this would have happened.

As designers we can’t possibly know how all the ways our decisions will affect behavior in a product. But we have to, at the very least, recognize that design has an opinion, and that it wants people to behave a certain way. I like the way Jared Spool phrases this:

Over the last year, we’ve started explaining design as “the rendering of intent.” The designer imagines an outcome and puts forth activities to make that outcome real.

We have a responsibility to do our best to ensure design wants things that are good for users as well as the business. We have to think ahead as much as possible, because what design wants is up to us. And once it wants the wrong things, it might be too late to change.