With regard to the Hilliary logo, Bierut disclosed a funny anecdote in which he was asked to weigh in with many other designers on how bad Hillary’s logo was. The requester, however, was unaware of the fact that Bierut had designed the logo. Bierut declined.

But going deeper into the negative, widespread, and sometimes vitriolicbacklash against the Hillary logo, Bierut said, “I kind of would marvel sometimes. I’d say, ‘It’s just some straight lines, some 90 degree angles, some 45 degree angles, and two primary colors.”

I’m certainly in no position to criticize Michael Bierut, one of the most esteemed identity designers in the business—deservedly so. But this felt just a tad off to me, and it struck me because I’ve heard a similar sentiment uttered by other identity designers when defending their work from widespread criticism. Essentially, they say, “It’s just a logo. Chill out.”

This argument is a bit disingenuous when one considers that—99designsaside—designers and their agencies are known for, shall we say, touting the promise of a great identity. They claim the logo tells a story. They promise it will create a deep connection with the masses. That it will build a bridge between the ethereal brand and the actual consumer.

And for their work, they charge tens or hundreds of thousands of dollars, or more (again: Bierut did the Hillary logo pro bono). Logo projects span weeks or months. And no, I’m not just talking about the full identity—I mean just coming up with a single mark. They employ lofty terms to describe their work: transformational, iconic, universal.

All of which would lead one to believe that practitioners like Bierut et al hardly think a logo is just so many geometric shapes and colors. And in fact, they’re usually not. A not-insubstantial portion of my career was spent working for established brandingandmarketing agencies where, among other things, I got to see firsthand the process of creating identities by some of the best in the business. I witnessed the thoughtfulness, rigor, creativity and energy that went into each effort.

I know I’m nitpicking one blurb from an entire conversation, and I know Bierut believes in the transformational power of a great identity. I have the utmost respect for his ethos, insights and talent. And, in fact, I think there’s a great deal of truth in what he’s saying: People, chill out. It’s just a logo!

But it feels wrong to try to have it both ways. I mean, a logo really is just so many shapes and colors, and as someone who designs products and services, not identities, I firmly believe the experience a person has with your product or service is far more important than its logo or identity. (I’d often marvel at companies willing to spend a million dollars on a logo package, then balking at $250K for the digital services underpinning their businesses.) And yet it’s hard to refute that an iconic logo can make its mark on the cultural zeitgeist. Imagine, if you will, Nike killing its swoosh, or Apple losing its…apple.

Are you using them?

I used to joke that 50% of any UX project was anticipating and planning for edge cases — all the stuff that can take people off the happy path. I was wrong. That number should be more like 80%.True. In any project, I’ve found that designing the desired flow is a snap compared to the myriad edge cases. Actually, many edge cases aren’t edge cases at all, they’re just states that are less than ideal or unplanned for.

Often, these cases are revealed through user testing or after a product has launched via user feedback, but it’s critical to try to anticipate as many as possible in advance. A simple framework is simply to ask What if…?

What if the user is a minor?

What if the internet connection dies?

What if the user is colorblind?

What if English isn’t their first language?

What if they have a motor impairment?

What if they haven’t saved anything yet?

What if the confirmation email never arrived?

What if the plugin is blocked in China?

What if JavaScript is disabled?

What if there’s a server error?

What if they can’t remember which email they used?

Asking What if…? should happen throughout the product development cycle. For example, I try to identify as many What if…? scenearios as possible when developing my project brief—some will fall into functional specs, others into product requirements, others into a general bucket of issues to resolve. I ask What if…? while designing my user flows, and then when I’m creating my low- and/or high-fidelity prototypes.

Obviously, I look for them during user testing, and try to gauge them after launch by keeping an eye on analytics. In fact, to bring a little more rigor to my practice, I’ve begun compiling common What if…? questions in a Google Sheet, categorizing them by scenario and context, and adding typical or potential solutions.

Whatever your UX practice, get in the habit of asking What if…? Most people and their contexts are going to throw a wrench in the works, and asking this simple question over and over might be the difference between success and failure.

Many years ago I was the creative lead on one of my agency’s biggest client projects, but I was blocked. Even though he was generally viewed as a fairly useless type, I went to the Executive Creative Director hoping for guidance. I told him I was stuck, blocked, and didn’t know where to start. He gazed at me like a monk, then advised me to sit under a tree in Central Park, let my mind go, and just “imagine what can be.”

What an ass.

His advice wasn’t only facile, it was completely wrong. The worst thing you can do when facing an overwhelming creative challenge is let your thoughts zip around your brain like a Roomba hoping to stumble across a gem amidst the dust bunnies and crumbs. The best thing you can do is find constraints.

A simple experiment you can try right now: take out a sheet of blank paper and draw something interesting.

Does the challenge feel unfair? It is: I didn’t give you any constraints. Now try this: draw a rectangle to frame your drawing. Suddenly you have a frame, a constraint: Everything I do must go in this box right here, right now.

Maybe that helped. How about this? Draw with only diagonal lines. Use no more than 10 lines. And vary the weight of the lines. More constraints, each minimizing the paradox of choice, each creating a wall for the handball of your thoughts to bounce against.

I will rarely start any professional project before I create at least a simple written project brief. I outline some basic project tenets: Who am I designing for? What are they trying to accomplish? What are the technical limitations? What features do I know I need to include? What are best practices? Etc. Each paragraph a constraint. Each sentence narrowing the scope, each word helping to funnel my efforts into something meaningful.

Maybe a brief’s not your thing, but whatever you do, don’t fall into the trap of thinking you’re supposed to start from scratch and make miracles happen. Find meaningful constraints, or create your own.

Here’s how Apple could fix it

A Norman Door is designed in such a way that you’re never sure whether you’re supposed to push or pull. Generally this is because there are pull-type handles on each side of a door that only opens one way; this results in people pulling when they need to push. It’s maddening, especially since it’s so easy to design doors that don’t have this problem: a push plate on one side, a pull handle on the other.

iOS 10 doesn’t have actual Norman Doors, obviously, but it does have a Norman Door problem. Apple apparently thought the previous Control Center pane was overloaded, so they split it into two panels: Home and Now Playing. You swipe up to reveal the Control Center, then swipe sideways between the two panels. This has created a couple usability problems:

The only indication that there’s another hidden panel is the carousel-style dots at the bottom of the screen; these are tiny and easy to miss, so users may not even know there’s more than one panel.

Once you swipe to a given panel, you have to swipe in the opposite direction to go back, and this is where the Norman Door problem arises.

Here’s how this plays out: you swipe up to reveal the Control Center’s Home panel, the default. You need the Now Playing panel, but you’re not sure where it’s hiding, so you swipe right. Wrong! That’s a dead end, but you had a 50% chance so better luck next time!

iOS's version of a Norman Door

Later, you want to go back to the Home panel, but you’ve forgotten whether it’s off screen to the left or right, so you swipe left again. Wrong! Another dead end. You swipe right and you’re in the right place.

Current state: toggle between panels, but hit a dead-end after one swipe.

If you’re like me, you’re now annoyed: why must I remember where the hidden panel is? Perhaps with time I’ll memorize the pattern—Home panel on the left, Now Playing panel on the right—but that’s as borked a user experience as are Norman Doors. It puts all the burden on the user, none on the system.

Infinte carousels to the rescue!

My solution is to treat the two panels as an infinite alternating carousel: no matter which panel you’re on, the other panel is off-screen on either side.

Solution state: just keep swiping between alternating panels. No dead-end in sight!

No matter which way you swipe, you end up on the panel you want. Since there are only two panels in Control Center, you can’t go wrong:

Swipe on, swipe off.

My solution doesn’t solve for the first problem, i.e., that the other panel is hidden off screen, but it does solve the Norman Door problem pretty well. And it’s not a complex fix to implement—so get going, Apple! (Next, they can fix the challenge of accessing the Control Center itself in any app with scrolling content, but that’s another post.)

Update

Some kind people have pointed out that Control Center can have up to three panels if HomeKit is enabled (I haven’t activated it yet). I think the infinite carousel is still an improvement, but would want to test that hypothesis.

Source: iLounge

However, the fact that there are now up to three panels (and maybe more in the future?) in Control Center, two of which would be hidden by default, tells me Control Center needs some more UX love from Apple.

What do you think?

Update

June 29, 2017: the iOS 11 beta reveals that instead of multiple panes, the new Control Center will have multiple units in one screen. It could get cluttered, but at least the issue of off-screen items should be resolved.

From a designer who used to code

Okay, truth time: I was never much of a coder, but back when websites were less complex, I could build a (simple) one myself. I also knew my way around the Flash ActionScript editor, if that means anything (and I know it doesn’t). It was great fun. I learned a lot.

But this topic of designers needing to code is a tired one. I’ve written about it myself at least once or twice. But articles like this still get my goat. So let me say it one more time: designers don’t need to code, and here are two compelling reasons why:

1. You’ll never be a great coder

Sorry, it’s true. If you think you’re going to be a top-notch UX’er, with all that entails, and also be top of your game at coding, you’re delusional. I work with great frontend engineers. Yes, engineers. The stuff they’re able to pull off is scary complex (and cool). They’re at the top of their game, and staying at the top of their game is their full-time job. And staying at the top of your game as a designer is—or should be—your full-time job.

2. You’ll end up limiting yourself as a designer

You want to build what you design? Great! It’s a solid instinct. But when you sit down to design, you’re going to start thinking about what you can reasonably build yourself. And, inevitably, you’re going to think of some fantastic feature—the one your users really want and need—that’s too technically sophisticated for you to code yourself. And so you’re going to limit your design. Trust me, I know: I realized my days coding websites were coming to an end when I started to change my designs based on what I felt comfortable building.

Look, I’m not saying you shouldn’t learn to code; I’m taking a Processing class myself in a few weeks. Nor am I saying that keeping up on the latest technical advances is unnecessary: you most certainly should. I’m not even saying a talented designer can’t be a decent coder; I know some who are.

I’m saying that the imperative—designers must code!—is bogus. Know your trade; learn your tools; understand the technology; communicate with your engineers early and often; and dedicate all your energy to your craft. Trust me, it works.