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.

My Blind Spot

I really enjoy strategy, but I’m not as good at it as I want to be. I’m pretty bad at chess. I’m awful at Monopoly. I’m even pretty bad at tic tac toe sometimes. Recently I’ve been analyzing my own behavior, and I’ve started to see a pattern. I have a blind spot.

I am far more concerned with winning than not-losing.

That is, I spend far more time and energy thinking about how I am going to win than I do thinking about ways my opponent could beat me.

This is probably responsible for most of the arguments I get in with product managers, who are clearly biased toward not-losing. They’re far more concerned with keeping the customers we have than getting new ones.

Ideally, a good strategist is concerned with both making gains and keeping them.

I guess.

Right?

I don’t know. Keeping what you have is way less interesting than getting more.

I mean…I am aware that keeping the customers you have is WAY cheaper than getting new ones. Cost of acquisition is a major issue. But, there’s a balance there, right? You can’t play all-defense. You can’t play all-offense.

At any rate, now that I’ve noticed my own personal bias, I’m going to start trying to modify it. Maybe one day I can achieve balance. (Although it would probably be more fun to be at least a little biased toward winning.)

Support for IE[-3] has ended…

The site I work on at work gets requests like this pretty often:
“When will you support Internet Explorer [version number way lower than 11]?”

And, the answer is, “Never. A very small part of our users use IE[-3], and the cost would be prohibitive.”

And their answer to that is typically something like, “Our IT guys won’t let us install Chrome or Firefox or upgrade windows and get IE[n].”

At first I felt bad for these people, and told my bosses that we could support IE[-3], gave them an estimate for how long it would take to do, and told them how it would affect the design. After all, as a long-time Mac user, I used to get these “you’re a second-class netizen” messages all the time, and I know it’s frustrating. But now…I don’t feel bad at all, and here’s why:

From Microsoft’s website, “Windows Internet Explorer [-3] is also no longer supported, so if you use it (or any other browser) to surf the web, you might be exposing your PC to additional threats…”

This is IT’s job, right? To keep the technical resources running and safe? No one thought it was a huge surprise that XP was discontinued (and along with it IE[-3]), and they gave us plenty of warning. Computers and OSes have a predictable useful life. Upgrades should be planned spend.

If you’re using IE[-3], the web sucks for you. You’re not seeing most of the cool (and useful) new stuff that people are making. Supporting your out of date browser means we can’t make as many cool (and useful) things as we want to, because each one takes twice as long. Selfishly, I like making cool stuff. Not selfishly – The 80% of users who are using modern browsers are better served by the stuff we make using modern techniques.

What you’re asking for, when you ask for support of your out-of-date browser is that we slow the pace of creating cool (and useful) things for everyone, to accommodate the pace of your IT staff not doing their job (or you not wanting to have a conversation with them about it, which I’m sure is often the case).

When viewed through that lens, I no longer feel bad for these people. I will not be their enabler. Talk to your IT staff about getting you the tools that you need.

UX isn’t as important as User Experiences

In the past few years UX has become a big part of the conversation about design and its benefit to business. It had previously been a relatively small corner of the design universe, mostly concerned with how information is organized, how a user gets from Point A to Point B inside your application, and what form fields they’ll have to fill out (and how) once they get there. It is now a growing discipline that seems like it will consume all aspects of product and service design.

UX becoming important to business is not because business suddenly came to understand that what we were doing was important, but because UX slowly drifted into a holistic design discipline at around the same time that businesses finally became aware that products aren’t as important to people as experiences.

Spending vs. Wasting Time

I frequently have arguments with people about wasting time “re-doing” things they spent time on already. They’ll say things like, “I know this isn’t the best solution, but if we change it now, we will have wasted the time we spent making it.”

Here’s the thing. You’ve only wasted that time if you never learn from it and fix it.

If you spent your time making something that isn’t very good, and has little or no value, then you have wasted it. If, however, you spend some more time making a better, high-value, thing, based on what you learned, then it was only a small investment in the resulting high-value product.

Crazy Visionaries and Faster Horses…

I am particularly fond of the misattributed (or completely fabricated) Henry Ford quote,

“If I had asked people what they wanted, they would have said faster horses.”

It’s spirit is something I identify pretty strongly with…that the market is incapable of thinking beyond the horizon. Buyers and users have a really hard time conceiving of anything that isn’t pretty similar to something they’re already familiar with. Steve Jobs also said something similar (and mostly true),

“…people don’t know what they want until you show it to them.”

This creates conflict for me internally, because at my heart, I am a human centered designer. I solve problems for people, and I want them to use and enjoy and find value in the things I create for them. Their input (the user) is critically important to the creation of valuable design. So, how do I reconcile this belief that people/the market are incapable of conceiving of radically high-value solutions to their own problems?

Easy. I don’t.

There’s a world of difference between solving a problem in a way that users can’t have seen coming, and spending your time, money and resources solving a problem that doesn’t exist, or solving it in a way that won’t be accepted. There’s also a world of difference between studying a user and their needs, and simply asking them what they want. It is in that difference that these ideas become not just strange bedfellows, but amplify each others effect.

Effective study of a user’s needs and behavior gives you the background to design exactly what they want, even if they don’t know it yet. Studying the user doesn’t need to raise the probability that you’ll create something mundane. But, not studying the user does raise the probability that you’ll create something that doesn’t solve their problem.

What Henry Ford (allegedly) understood about his users is actually born out in that quote. “Faster Horses,” tells him what problem he’s solving. The value he as an innovator brings to the market is that he solved the root problem in a novel way.

Ignoring your user does not make you a Crazy Visionary, it just makes you crazy. Your value as an innovator does not come from the ability to invent completely previously un-thought-of things from whole cloth, it comes from the ability to solve real problems for real people in meaningful ways.

Who wants crazy visionaries anyway? I would much prefer cannily sane ones. 😉

Opportunity Costs

This, to the best of my recollection, was an actual objection I recently faced when discussing the future of a product with its manager.

“We can’t afford to radically improve [our product]. If we do, the customers we have now might decided that, since they’ll have to transition to the new version, they might as well transition to a competitor’s product.”

At the time I just stared at this person, absolutely dumbfounded. This notion is so foreign to me that, uncharacteristically, I did not argue the point.

After some consideration, I have formulated a response, which I give you now as food for thought.

You should assume that your customers are constantly evaluating alternatives to your product. If you don’t have a new offering, if you’re not setting pace, if you’re not constantly improving, if you’re not always getting a little bit better at solving their problems, you can be damn sure that their short list of solutions to replace your product won’t include your product. Not giving them a radically improved product to transition to is giving them no choice but to transition to a competitor.