Twenty Years in the Valley
“If you can’t make it good, make it BIG. If you can’t make it big, make it RED!”
That’s a Paul Rand quote that’s become a bit of folklore in design circles.
I always forget the details of the story behind it, but I think it goes along the lines that Rand was teaching his Graphic Design course at Yale and offered up this little nugget to an eager student who was struggling with how to fix the logo she was working on for class.
It’s a pithy quote, and entirely memorable.
It also has little to do with what I’m about to tell you other than the fact the color red features prominently in this story. And that I love the quote.
One of the consequences I suffered in abdicating my duties as a designer and not building some level of coded prototypes during my tenure at Adobe was that I spent an inordinate amount of time in meetings exhaustively explaining in excrutiating detail how every proposed tool, command, and feature would work across Photoshop, Illustrator, and InDesign. I would often find myself discussing the same thing for each team in different meetings. Over and over. Weeks upon weeks. Months into Years.
“Andrei, what happens when I press Command+Option+Shift, then click on the canvas, but I miss the anchor point? Should we deselect the entire path or treat the selection as ‘active’ and copy it if I start dragging the mouse?”
Insert: Me in a discussion lasting two hours with a few engineers about selection logic and mouseDown and mouseUp events, going through the example four times to quadruple check the decision on what to do with a single freaking click.
“Andrei, in this screenshot, you have the layer effect icon on the background layer. Surely you’re not suggesting we change the behavior of backgrounds to allow for this? That would take at least 4 weeks of unplanned coding, and we’re already behind on getting to alpha.”
Insert: Me having to explain that was a copy and paste error on my part. Please ignore the icon. It’s not supposed to be there. And no, I’m not going to go fix it right now, reprint the screenshot, and bring in a fresh copy for this meeting. Just fucking ignore it. Please.
“Andrei, we understand how the Photoshop and Illustrator team are doing this, but one is a pixel editor and the other a vector editor. Our product does something entirely different.”
More on this in a second.
One of the key lessons I learned in those meetings — and a lesson my wife, Donna, is quick to remind me about — is that often times how you frame something will dictate the success of what you are trying to do. I mean this literally. While it’s not 100% true, it’s pretty high on the scale.
What do I mean by success? In a design review, you could show the best work you’ve ever done. It could be the most amazing solution to one of the hardest problems your team is facing. It could even have test result scores shooting through the roof. But if you fail at effectively communicating the work in the meeting, it’ll get shot down and never see the light of day.
It’s a tragic irony that many designers are often ill equipped when it comes to communicating their own work.
Why is this? I wish I knew.
Design as a craft has deep roots in communication. It’s a problem solving activity that largely results in solutions that people interact and converse with. One would think that a profession so largely based on this would lead to the designer of the work being able to speak in coherent sentences about the very thing they created.
For all the talk of unicorns amongst designers in tech, the real unicorns aren’t the ones who can draw, sketch, code, research, strategize, organize, animate, and create art in their cappuccinos. The real unicorns are the ones who can do all of that and explain clearly what the hell their work is about.
Case in point, Thoughts on Design by Paul Rand.
Lest you think I’m excluding myself from this affliction, let me be clear: I’m as guilty as anyone. I fumble my words, lose track of my thoughts, and stick my foot in my mouth all of the time. I do it often, usually in public. I just did it this morning. I’m probably doing it right now.
Back to the point.
It was 1997, and I was in a meeting with the Illustrator team in San Jose. We had shipped Photoshop 4.0 and Illustrator 7.0 by then. InDesign 1.0 was deep into development as well. Both Photoshop and Illustrator were getting some heat from long time customers because we had begun the process of converging the interfaces. Although those customers were in the minority, they often yelled quite loudly from the mountain tops about the changes they disliked. Inside, we were getting good feedback and sales numbers that showed the strategy was working. People were starting to use Photoshop and Illustrator together and more often, especially new customers. FreeHand was getting hit hard from this strategy as more people began to adopt Illustrator to work in conjunction with Photoshop. Later on, when InDesign shipped and followed suit, Quark XPress would suffer the same fate.
In this meeting, I was a bit exhausted. I had been at the company for two years, and the constant discussions, debates, and arguments about the entire design strategy were starting to take a toll on me. Even though we were seeing success, I was still finding myself arguing the merits of the strategy in some meetings over big features, and defending the idea that the experience of our products should reflect the new usage pattern of people using Adobe’s products in collaboration with each other, not as silos.
Now, I was raised in the ‘80s, a decade that started with the IBM PC and ended with the Macintosh. I started with DOS and graduated to the GUI. I remember walking into a Babbages in 1984, and seeing a shiny new Mac 128K for sale. It had a demo of MacPaint and MacWrite running on it and I immediatelty fell in love with the interface. I remember the brochures sitting next to it that sold the benefits of consistent keyboard shortcuts, menus, and conventions for the user experience. The Macintosh was the computer for the rest of us! It was easier to use. And it got a lot of that ease of use from a consistency of interface controls and keyboard shortcuts through all the applications made for it.
Undo:
Cmd+Z
Cut, Copy, and Paste:
Cmd+X, Cmd+C, and Cmd+V
Why “X?” Because the cross symbolizes deleting something. Why “C?” Because its mnemonic! Why “V?” Because it’s next to “C” on your keyboard. Why those keys? Because as a sequence, you can use them with one hand, often without having to look down. Brilliant!
I had used much of the logic from early Macintosh interface design principles in so much of my work on the Creative Suite, but it wasn’t enough to get everyone on board in some meetings. I often used the point that Microsoft had successfully made their tools into a suite, and that Word, Excel, and PowerPoint were three entirely different products that used Cut, Copy, and Paste in a consistent manner. Still not enough. I would do everything possible to ask for as little as possible per release to sneak as much as I could in. That was still not enough.
I found myself constantly getting into debates about the merits of how Photoshop, Illustrator, and InDesign needed to work cohesively, and I still heard arguments that because one dealt with pixels, the other with vectors, and the last with page layout, things needed to work a unique way within each product.
So it was in that meeting in 1997 that I said something that framed the entire Creative Suite, and finally made it click. Not just for me, but for the people I was working with as well.
The discussion we were having was over adding the Photoshop Color Picker to Illustrator. It was really more of a heated debate. Now that I think about it, I guess it might have included a bit of shouting, mostly by yours truly.
The conversation went something like this:
“Andrei, I hear you. But look, Photoshop is a pixel editing program. It doesn’t have spot color plates or support PANTONE colors in the way Illustrator does. We can’t just duplicate the Color Picker from Photoshop without taking those things into account. It makes no sense.”
“Agreed. But still, we should make the color pickers reasonably close up to the point where the color engines differ.”
[Author’s Note: There’s a better than good chance I’m partaking in a little bit of revisionist history here with regard to my tone or speaking voice. Ask anyone who knows me for clarification on this point. Better yet, don’t.]
“Andrei, if we use the Photoshop Color Picker, we would be implying the color engines are the same. They’re not.”
“Yeah, I get that. But we still need to do it. As a product suite, we need to make parts of the interface the same when it comes to shared features. The Color Picker is one of those!”
“Andrei, it doesn’t make any logical sense. You’re asking us to put in a lot of time and coding effort to add something that make no sense in the context of the application it’s in. Color works differently in Illustrator. What are we supposed to do if the user expects Lab to be there?”
“What? Or course it makes sense! How could you possibly think that?”
“Andrei, you’re not listening.”
Exasperated, I finally said, “Look, at the end of the day, all someone wants to do is pick RED in Photoshop, then pick the same RED in Illustrator. They do that with Color Picker and they don’t care how the color engine works. They just want to pick the same RED.”
The room got silent. People were processing what I had just said. Even I was processing it, because I hadn’t thought to say it that way until just that moment.
Then the best three words I think I’ve ever heard were spoken by the engineering lead:
“I get it.”
Followed up by music to my ears:
“Ok then. Let me see what it would take to make it happen. No promises, but we’ll see what we can do.”
That was it. The Color Picker went in.
I suddenly understood. I understood that most of the problem, if not the entire problem, was that I was communicating the solution entirely wrong. I was making it about the specifics of the design, or the strategy for the company, and probably tossing a bit of ego into the mix to make it really difficult for the team to accept.
But once I reframed the design — making it about what our customers wanted from our tools— it became a different discussion, and one that made it possible for the team to envision. Nothing about the design changed in the conversation. Nothing was added or removed from the proposed Color Picker for Illustrator, although the final result exlcuded a few Photoshop specific features like Lab color. All that changed was the discussion became about the person who was using our product, and every single person on the team cared deeply about those people.
All I did was reframe the discussion to match, and everything suddenly became possible. That time back in 1997 I did it accidentally. As time has passed, I try to find ways to practice this skill, and to frame any design discussion in a way so the other person can say those magical words to me:
I get it.
Communication and framing is a skill that’s incredibly hard to learn. I’ve met only a few designers who’ve ever mastered it. Like all skills you’ll have to acquire in your design career over the long haul, it’s one you’ll have to practice and practice and practice some more in order to get better with it; no different than learning how to code. Or how to draw with ink and paper. Or how to strategize how your product ideas fit your company’s business model. Or how to conduct ethnographic field research with your customers.
In fact, I’m trying to practice it right now, with this entire exercise of writing down my recollections of what’s happened over the past twenty years as a designer working on the front lines in the high-tech industry. Whether it’s working isn’t the point.
What I care about it is practicing it.
Besides, if it didn’t work, there’s always this:
Damn, that Paul Rand was a genius!
