What are you, a billboard?

When I was in middle school, I really wanted this Nike T-shirt. It said “Just Do It,” in big black and red letters up the front and down the back, and I thought it was just the coolest. I vaguely remember someone I admired wearing one just like it, and I clearly remember all the cool kids at school having them. In fact, I can clearly recall all the cool kids having Nike shirts, and Umbro shorts, and Adidas shoes (Sambas, if I remember correctly). They all dressed like they were going to/coming from indoor soccer practice all the time.

As I started to work in Brand Design, and learn more about marketing, I remember thinking that the real brilliance of Nike’s brand was not the performance or aesthetic qualities of their products; but that they had convinced the world, through associating their brand with top-performing athletes (and therefore the cool kids who wanted to be just like them), to pay them for the privilege of advertising their brand on our bodies.

In the 1990s Nike’s brand was so pervasive that all you really had to do to mimic it was set some type in Futura Bold Condensed, and you were off to the races. Come to think of it, that probably explains a lot of my font choices in college…but I digress.

I think about this every time I see design recommendations based on, or that heavily leverage, someone else’s Design Language and/or Front-End Framework; which happens a lot. I’ve worked in companies that choose to build on top of Bootstrap, or Material Design (or both, and have a turf war over which is better). I’ve worked with designers and developers who refuse to break a rule set forth by Apple’s or Microsoft’s Human Interface Guidelines. I’ve advised entrepreneurs who have tied their brands so closely to platform conventions that you would never know that their iOS and Android versions are the same product.

This leads me to my point…

There’s great danger in using someone else’s Design Language/Front-End Framework/UI Components in your product interface. It is often overlooked by proponents of such shared frameworks that those things are equal parts User Interface Convention and Brand Expression. When you use them, sure you get the benefits of a tried-and-true UI component (probably saving yourself time and money and risk), but you also extend Google’s, or Twitter’s, or Apple’s, or whomever’s brand expression into your product at the expense of your own.

There are, of course benefits to using these things, not just in the time and money you save not having to build them yourself, but in Usability. Platform conventions are a valuable thing. If you want your product to feel familiar, and align to the choices they already made by choosing that platform, you should follow them. Universal (or nearly universal) patterns reduce the amount of cognitive energy users need to use your interface, and that’s generally good. Your designs should acknowledge Jakob’s Second Law.

Like many things in Design, the goal should be to strike the right balance between competing goals. In this case, between making things familiar enough that they’re easy to use and expressing enough of your own brand that people can tell the difference, and you can build brand equity through the interface.

In this way shoes might actually be a good metaphor. It’s pretty rare that a shoe comes to market that makes you confused about how to use it. They all have pretty straightforward design conventions and that makes them easy to use. But, it’s also pretty rare that you would confuse the products of any of the major brands with one another, because they all have unique brand attributes that help us differentiate them from one another. This is how your experiences should be designed as well.

Predictable behavior

One of the things UX/product designers do is predict the way people will use things. It helps us prevent errors and usability problems. It’s one of the core skills of a good designer, and one of the problems we must solve first; before we decide what it looks like, or how it will make you feel. I mean…unless you’re a bad designer. Then you design things for how they will look in the pages of your favorite design magazine (if those are still even a thing), or to placate your most opinionated stakeholder. I guess it depends on whose validation you crave the most.

Anyway. I digress.

We should be designing things based on how we expect they will be used. It seems simple enough, but it’s this very basic idea at which we fail again and again, especially when we design online systems. We consistently fail to predict, and design for, people using the systems we design inappropriately.

It occurred to me this morning, as I was reading yet another exposé detailing Facebook putting its thumb on the scale in order to avoid receiving criticism from right-wing media pundits while listening to a podcast wax comically about the nudity police on Instagram; that this failure is not a failure of design to predict the behavior, but a failure to accurately calibrate the idea of “appropriate.”

Or, said another way; the problem is not that we can’t predict the behavior and design for it, it’s that we don’t agree that the behavior is inappropriate.

In this example, we seem to all be aligned on the idea that online services that allow children to have accounts and post content should not allow nudity, but we’re not aligned on whether or not we should allow that same platform to be used to spread hate speech, organize domestic terrorism, or manipulate people’s emotional health.

When you think about it, especially considering the problems that a platform chooses to fix, versus the ones it chooses to fix (or fix poorly); what they are really telling you is which uses of their platform are appropriate or inappropriate. Or, at least they’re telling you which behaviors they’ve decided aren’t deal-breakers because they’re important to their most opinionated stakeholders.

If you want to go quickly…

There is an almost certainly apocryphal proverb that goes something like, “If you want to go quickly, go alone. If you want to go far, go together,” and I think of it often when trying to take on large/complex projects, because I see this thinking get a lot of teams in trouble.

One of the things we have to do when we, as designers, take on large projects is integrate complex sets of requirements; but that’s really hard to do with the “two-pizza teams” favored by adherents of this particular folk wisdom. Those teams are designed for speed, because (let’s face it) speed is almost always a requirement. That isn’t a bad thing. The longer a project goes on, the more likely it is to fail or get cancelled. Speed is a determining factor for most projects. The fault lies not in prioritizing speed, but perceiving it as a binary, and as a constant.

So, what do you do when you need to go quickly and go far?

I propose you oscillate between going together, and going it alone. Or, to keep things in the realm of apocryphal proverbs, you oscillate between Two-Pizza Teams and It Takes a Village. Recognize that there are times to go fast, skimming the surface and plowing through (or skipping off) surface-level disruptions; and times to slow down, sink in, and roll with the waves a bit. I know. My metaphors are all over the place.

This requires that you spend your time building a coalition of people who trust you and understand that there will be times that you will need their attention, and times when you don’t. There will be times when it seems like you’re ignoring them, and times where you will be joined at the hip. There will be times when you are asking them to weigh-in, and times when you are asking them to butt-out.

It takes an enormous amount of trust to get that last part to be okay; but that’s what it takes to do the big stuff quickly and well.

This, for what it’s worth, is why I end up being a proponent of facilitated collaboration methodologies like Design Thinking. At the points where you need to get input from that coalition, a well-designed workshop (or series) is a great way to get what you need from those people, while setting the ground-rules for asking them to get out of the boat so you can start going fast again.

No, it’s not all “User Experience.”

Update: Upon re-reading this post, I decided that I was being a dick. So, I'm editing it, to be clearer, and less of a dick.

Last night, I had a simultaneously exhilarating and frustrating conversation with a group of designers that I know through AIGA. It was the night before the national conference started in earnest, and the hotel bars were chockablock with excited designers from all over the country; gathered to get inspired, network, and engage in group catharsis.

Clients/Developers/Stakeholders (people who are not Designers), as it turns out, really do be like that sometimes.

The conversation was a free-wheeling exploration of the relationships between all the various design disciplines and what makes them “the same” and different. What was frustrating about it was the obvious lack of context of one of the participants, who kept insisting that “everything is UX” and then talked about something specific to graphic design. More specifically, graphic design within the context of advertising.

At some points in the conversation, another participant and I would be having a side-bar about design history, engineering, computer science, design thinking, Design Thinking™, or whatever, and find ourselves saying exactly the same thing as the main conversation, only to hear it punctuated with “That’s what I’m saying, it’s ALL UX!”

Except here’s the thing: It’s not.

What we were discussing is Design. All design has (and should be produced for) users, and all users will experience that design, but that doesn’t make all design User Experience (UX) Design. UX design is its own discipline, which is made up of sub-disciplines, with skills that specifically support the intended outcomes of UX Design.

Each of the various disciplines has facets of their execution that place emphasis/value on domain-specific concerns that would be useless in the other disciplines. For example, the selection of paper stock is mostly irrelevant to UX. The understanding of Human Factors/Usability is mostly irrelevant to print designers. There are even sub-disciplines that cross over, but the nuance of their application distinguishes a UX Designer from another type of Designer with the same core skills. A motion designer who is fantastic at designing for advertising might be completely lost when creating animations to aid usability.

There are, of course, overlaps in our understanding; because these are adjacent disciplines. Being able to select type combinations and judge their legibility is relevant to both. Even within that similarity, there are distinctions because of the technology being used to produce the end results. Understanding those limitations is key to the success of the execution.

As I’m writing this, I recall various points in my transition from mostly doing print and brand work to doing 99% UX work, and the ridiculous number of times my print-based judgments of the overlapping parts of the two disciplines failed me. The more I think about it, the more I can see how my early judgment that these things were “the same” led me astray.

No, it’s not all UX. It may all be Design, but even in the similarities, there is nuance. It’s not the same at all.