WordPress.com is holding its first virtual conference, I’m speaking there, and you’re invited. The WordPress.com Growth Summit is a two-day live event where you can learn to build and grow your site, “from start to scale.” To make it as inclusive as possible, the event will take place twice, with live sessions accessible to all Earth’s time zones:
In the Americas, Europe, Middle East, and Africa, the conference is August 11-12 from 11:00am–4:00pm EDT (15:00–20:00 UTC).
For attendees in the Asia Pacific region, the event is August 12-13 from 11:00am–4:00pm JST (02:00–07:00 UTC).
Can’t attend all of the sessions you’re interested in? No problem. The WordPress.com events team will record them all and make them available to you after the event.
A diverse group of speakers will share tips on creating your site, aligning it to your business goals, finding an audience, building and nurturing an organic fan community, and more.
As for me, I’ll co-host “Blogging and Podcasting: Defining Success” with the amazing Jason Snell. Here’s how we describe our panel:
There are almost as many ways to succeed at blogging and podcasting as there are bloggers and podcasters. In a lively discussion full of plentiful tips and takeaways, industry veterans Jason Snell (The Incomparable, Six Colors) and Jeffrey Zeldman (A List Apart, WordPress.com) will teach you how to:
Define your mission;
Craft and govern content;
Understand and cultivate your audience;
React to change.
You’ll also learn when and how to diversify, and how to make money with paywalls, stores, advertising, and more.
DESIGN WAS so much easier before I had clients. I assigned myself projects with no requirements, no schedule, no budget, no constraints. By most definitions, what I did wasn’t even design—except that it ended up creating new things, some of which still exist on the web. Soon I had requirements, schedules, and constraints, but most of those were self-imposed: for instance, I designed the first A List Apart, published a fresh issue every week, and created title illustrations for every article. This was design, but self-directed. I found it easy and natural and it never felt like work at all.
But then a curious thing happened: I began to get clients. And the more clients I got, and the more complex and sophisticated the projects became, the harder design became for me. I wish I could say I approach design with fearless joy, but the truth is, the longer I do it, the harder and more unnatural it becomes. Starting new projects is easy when you have almost no clue what you’re doing—as easy as playing is for a child. With experience comes knowledge of all the depth and skill you lack. You know how great some design can sometimes be, and how unlikely you are to attain anything resembling greatness on any given project. The very idea of beginning terrifies you.
You work past that, because you’re a professional, but the ease is gone. Maybe it’s just me.
And it isn’t just design. Writing comes naturally to me when I’m expressing myself on my own site, with no outside assignment and no deadline except my own sense of urgency about an idea. It’s easy when I’m crafting a brief text message or tweet. Or a letter to a friend.
But give me a writing assignment and a deadline, and I’m stuck. Paralysis, avoidance, a dissatisfaction with myself and the assignment—all the usual hobgoblins spring immediately to life. I fulfill my assignments, because I’m a professional. Sometimes, once I’m far enough past the initial internal pleading, denial, and bargaining, and have put in the first dull miserable hours of setting one word in front of another like a soldier on a long march through waist-high, rain-drenched mud—sometimes at that dreary midpoint, everything unblocks, and I feel pleasure and clarity as flow returns. That’s what writers on assignment fight for—to reach clarity and naturalness after slogging through the hateful murk.
I also play music, and I’m good at it as long as I’m sitting in a corner at an instrument or console, making stuff up for my own pleasure. But create a commercial music product? Not so much. I once had a small recording studio. I got rid of it. Too much pressure.
You get it.
In my heart I remain an amateur. The spirit of play is where my gifts lie. After 30 years in business I can do the other thing—I can fight through the loneliness to make good product on demand. That is, after all, how I feed my family, and there are many far worse ways to earn a dollar. But it’s never easy. It’s never The Joy.
I’M LEARNING new tech and it’s hard. Maybe you’re in the same boat.
Through the rosy lens of memory, learning HTML and Photoshop back in the day was a breeze.
It wasn’t, really. And CSS, when it came along in 1996, was even tougher to grasp—in part because it was mostly theoretical, due to poor support in some browsers and no support at all in others; in part because the design model in early CSS wasn’t conceived by designers.
But my memory of learning these tools in 1995 and 1996 is pain-free because it’s an old pain, forgotten because of time passing and even more because the pleasure of achievements gained by acquired knowledge masks the pain of acquisition. (See also: learning to read, learning to ride a bicycle.)
Beyond all that, my old learning’s pain-free in hindsight because I view it through the filter of nostalgia for a younger, simpler me in a simpler time. I was faster, sexier, ached less. Maybe you feel that way sometimes.
Most of all, I falsely remember it being easy to learn HTML, CSS, and Photoshop because I wanted to learn those things. I was doing it for me, not for a job, and certainly not to keep up.
I was a pioneer—we all were, back then. I was passionate about the possibilities of the web and eager to contribute.
Do you dream in color?
That first year of learning web design, I often, quite literally, dreamed in four-color GIFs. I got near-physical pleasure from reducing file sizes. I subscribed to every web design mailing list out there, and even started one of my own.
Remember mailing lists? I don’t mean sponsored, monetized newsletters with images and tortuous HTML. I mean stuff you read in Lynx.
When I shared what I was learning, by writing about it—when I learned what I was learning by teaching it—I felt euphoric. We were at the dawn of a new kind of information age: one that came from the people, and to which anyone could contribute merely by learning a few simple HTML elements. It was going to be great. And democratic. And empowering. Our tech would uplift the whole suffering world.
With every new discovery I made and shared, I felt a sense of mastery and control, and a tingling certainty that I was physically contributing to a better world of the near-future. A world forged in the best tech ever: simple, human-readable HTML.
Design is supposed to fix the world, not break it. Yet some of us, possibly even most of us, work on products and at companies we feel conflicted about.
Design is supposed to value simplicity. And yet here many of us are, struggling to learn new tech, and not feeling it.
But enough about the universe; let’s talk about me.
I’m learning new tech and it’s hard.
I work at a company that makes it easy to use a popular open-source publishing platform. Making things easy for customers is what design’s about. It’s also, always, hard work. And it’s supposed to be. The harder designers work behind the scenes, the easier the experience is supposed to get for the customer.
I have a confession to make: I love hard, mental, strategic design work. I love going cross-eyed envisioning customer journey options small and large. I love it like I love good typography and icons and layout, and I’m way better at it than I ever was at those things. I love it like I love color schemes, and, again—I’m better at it than I was at those.
And, stop me if you’ve heard this one, the more strategic I gets, the further from the code I feels.
Learning new code and tools
I’m not on a product team—I do client-facing design on a special projects team inside our product company—but every designer at the company should understand our products on a deep level, and every designer at the company, whether officially working on product or not, should be able to help make the products better for the customer.
For team-building and other reasons, every designer at our company who can do so is flying to a desert resort next month for a meet-up. And at that meet-up, each of us will fix at least one thing that’s wrong with one of our products. And when I say fix it, I don’t mean file a bug report as a GitHub issue. I mean fix it.
To be ready for that, I’m learning code and tools I probably should have learned a few years ago, but, as a rich man says of his servants, I always had people for that.
New to my work day, before and after internal and client meetings, I slog away trying to master command line interfaces, GitHub workflow, WordPress Calypso, Gutenberg, and React. I’ll need facility in these areas to do a live product fix at next month’s meetup.
Getting the hang of this tech will empower me to fix broken designs and create good ones. That excites me. But learning new things is hard—and GitHub, Terminal, Calypso, Gutenberg and React do not come nearly as naturally to me as HTML, CSS, and Photoshop did 25 years ago (or so I remember).
Age. It’s not just a number.
We’ve all heard that the body replaces itself every seven years. Which means I’m not just a different person mentally, emotionally, and spiritually since I first learned web design 25 years ago; I’m also physically an entirely different person, inhabiting a body that’s been rebuilt, cell by cell, more than three times. (The actual science is more granular than the seven-year meme, but go with me, here.)
At my age, change comes harder than it used to. Guess what? That means I need to change, not just to do my job; I need to change to stay young. (No, that’s not science, but yes, it works.) When it’s hard to move, you need to start exercising, even if starting is hard. When you’re trapped in a dead-end relationship, it’s time to say goodbye, even though breaking up is sad and scary and hard as hell. And if you work in tech and find yourself thinking your past learning gets you off the hook from having to learn new things, you need to think again.
Change. Try it, you’ll like it.
I’m lucky. I work in a supportive place. When I get stuck, a dozen people offer to help. (If where you work isn’t like this, consider working with us.)
Learning new things is hard, and it gets harder if you’re rusty at it, but it gets easier if you keep at it. Or so I tell myself, and my friends tell me.
Maybe you’re in the same position. Maybe you’ve even wasted time and energy on mental ju-jitsu like this: “I believe in semantic, accessible HTML. Therefore I don’t need to learn React.” If that’s you, and it was me, review your thinking. There is no therefore. You can have both things.
You can do this, because I can, and I’m more stubborn and more full of myself than you ever were.
So to my old-school sisters and brothers in HTML. If you’re struggling to learn new things today so you can do your job better tomorrow, I’m going to tell you what a friend told me this morning:
TEACHING is a great way to find out what you know, and to connect with other human beings around a shared passion. It’s an energy exchange as well as an information one, and the energy and information flow both ways.
I’ve been a faculty member in the MFA in Interaction Design program at New York’s School of Visual Arts since my colleague Liz Danzico cofounded the program with Steven Heller in 2009. As with all programs and departments at School of Visual Arts, the MFA IXDprogram is run by a faculty of busy, working professionals who teach one three-hour class per week, one semester per year.It’s the kind of gig that doesn’t interfere with your full-time job, and even makes you better at it.
(Fun facts: In 1988, I moved back to New York, the city of my birth, specifically so my then-girlfriend could study computer graphics at SVA; the highlight of my advertising career, which preceded my ascension into web and UX design, was spent working for top SVA advertising instructor Sal DeVito; and I subsequently enjoyed a long romantic relationship with an artist who’d moved to New York to study painting at SVA. So you could say that my eventuallyteaching at the place was overdetermined. When Liz told me of her new program and invited me to teach in it, it was as if half the prior events in my life had been whispers from the future. But I digress.)
Helping students have better careers
Since the program began, I’ve taught a class called “Selling Design,” which helps students completing their Masters thesisdecide what kind of work they’d like to do when they leave with their MFA, a few months after the class begins. There are so many opportunities now for people who design experiences, digital or otherwise. What should they do? Where will they be happiest? Inside a big company or a small one? A product company or an agency/studio? Should they start their own business?
And there are so many kinds of workplaces. In some, it’s your work that matters most. In others, it’s politics. How can you tell the difference before taking a job? We illuminate the right questions to ask and the clues in a student’s own personality that can lead to a great career or a blocked one.
The main teaching method is discursive: I invite designers who’ve had interesting and varied careers to come into the studio and have a conversation in front of the class. Mainly I ask questions and the guest speaker answers; then the class asks questions. Over time the speakers’ experiences and the takeaways I synthesize from them for the class create a picture of everything from how to tell if someone’s lying to you in a job interview to the signs that you’ve come to the right place.
A blaze of glory
This Thursday, May 2nd, at 10:00 AM, I teach my last class of the year, and I’m thrilled that my guest speaker will be Alexis Lloyd, Head of Design Innovation at Automattic, and previously Chief Design Officer at Axios, and Creative Director of The New York Times R&D Lab. In my initial months at Automattic, I’ve reached out to Alexis many times for help and insight, and she’s always generous, patient, and illuminating. It will be an honor and a pleasure to end my teaching year in what will surely be a great conversation with this experienced design leader.
For more about the MFA IXD program at School of Visual Arts, follow @svaixd on Twitter and visit https://interactiondesign.sva.edu/ . And for those who don’t yet know Alexis, here are some points of reference:
Every once in a while, life gifts you with a genuine moment. “>Here’s my friend designer/author Justin Dauer and his newborn, exchanging important information during, of all things, a business conference call. (By the way, Justin is now hard at work on the second edition of his book, Cultivating a Creative Culture, which I recommend for anyone leading a team: www.the-culturebook.com/.)
For your viewing pleasure…
We’re standing at the threshold of an entirely new era in digital design—one in which, rather than hacking layouts together, we can actually describe layouts directly. The benefits will touch everything from prototyping to custom art direction to responsive design. In this visionary talk, rooted in years of practical experience, Jen Simmons shows you how to understand what’s different, learn to think through multiple stages of flexibility, and let go of pixel constraints forever.
Recently, Josh Clark, Gerry McGovern and I have been questioning our industry’s pursuit of “engagement.” Engagement is what all our clients want all the time. It’s the ? 1 goal cited in kickoff meetings, the data point that determines if a project succeeded or sucked wind. When our clients muse over their Analytics, they’re almost always eyeing engagement, charting its tiny variances with the jittery, obsessive focus of overanxious parents taking a sick child’s temperature.
Engagement is our cri de coeur. Our products, websites, and applications live and die by it. But should they?
For many of our products, websites, and applications, duration of page visit, number of our pages clicked through, and similar signs of engagement as it is traditionally understood may actually be marks of failure. If a customer spends 30 minutes on her insurance company’s site, was she engaged … or frustrated by bad information architecture?
For these products, websites, and applications, we need a new metric, anew and different ? 1 goal. Think of it as speed of usefulness; and call it content performance quotient—or CPQ if acronyms make you feel all business-y and tingly inside.
The content performance quotient is an index of how quickly you get the right answer to the individual customer, allowing her to act on it or depart and get on with her day. It is a measurement of your value to the customer. For many apps, sites, and products, the content performance quotient offers a new goal to iterate against, a new way to deliver value, and a new way to evaluate success.
For many sites, engagement is still a valid goal
To be fair as well as explicit, spending extra seconds on a web page, and browsing from one page to another and another, remains a desirable thing on deep content sites like A List Apart and The Washington Post?—?sites that encourage slow, thoughtful reading.
A List Apart isn’t a place to grab code and get back to your web development project; it’s a place to ponder new and better ways of designing, developing, and strategizing web content. And pondering means slowly digesting what you have read. The Washington Post isn’t a purveyor of ten-second talking points and memorable but shallow headlines—it’s a place for detailed news and news analysis. That kind of reading takes time, so it makes sense if the owners and managers of those publications peruse their Analytics seeking signs of engagement. For everyone else, there’s the CPQ. Or will be, once someone reading this figures out how to measure it.
There’s also a new design paradigm that goes hand-in-hand with this new goal: shrinking your architecture and relentlessly slashing your content. It’s an approach we’ve begun practicing in my design studio.
But first things first. What exactly is the CPQ?
The content performance quotient (CPQ) is the time it takes your customer to get the information she sought, and here, less is more—or better. From the organization’s point of view, CPQ can be the time it takes to for a specific customer to find, receive, and absorb your most important content.
Come to where the messaging is
Consider the Marlboro Man (kids, check the Wikipedia entry), a silent visual spokesman for Marlboro cigarettes, created by the Leo Burnett agency for an era when Americans expressed their optimism by driving two-ton be-finned convertibles along the new highways that bypassed the old cities and the old urban way of life.
It was a time when Americans looked back on their historical westward expansion un-ironically and without shame. Cowboys were heroes on TV. Cowboys were freedom, the car and the highway were freedom, smoking the right cigarette was freedom.
On TV back then, when commercials had a full 60 seconds to convey their messaging, and nearly all were heavy on dialog and narration, Marlboro TV commercials were practically wordless. They showed a cowboy riding a horse. You saw him in closeup. You saw him in long shot. There were slow dissolves. There was music. There were no words at all, until the very end, when a suitably gravel-voiced announcer advised you to “Come to where the flavor is. Come to Marlboro Country.”
But it was in billboards along the highway and at urban entrance points where the campaign really lived. There was a beautiful shot of the cowboy doing cowboy stuff in the distance. There were four words: “Come to Marlboro Country.” One of them barely counts as a word, and you didn’t have to read any of them to get the message.
The billboards had one or two seconds to tell you everything, and they worked. At a glance, and from repeated glances over time, you knew that Marlboro was the filtered tobacco cigarette of the independent man who loved liberty. It was not the smoke of the neurotic urban dwelling subway rider (even if, in reality, that was the customer). Marlboro was for the libertarian in chaps. For the macho individualist with no crushing mortgage to pay off, no wife and kids to infringe on his horse-loving freedom. You got it all, without even knowing you got it. That’s performance.
Targeting convertibles on the information superhighway
In hindsight, it sounds ridiculous, but the super-fast storytelling worked: when I was growing up, Marlboro was what every child in my middle school smoked.
Remove the cancer and the other ethical problems from this story and hold fast to the idea of conveying information as close to instantaneously as possible. The geniuses behind the Marlboro Man achieved it by reducing their messaging to only what was needed—only what could be conveyed to a person passing a billboard at 60 MPH.
Your customer is not speeding past your messaging in a 1954 convertible, but she is speeding past it, and if you don’t optimize, she will miss it. For her to get your message, you have to work as hard as those evil ad wizards did. You must focus relentlessly on messaging (as well as design and site performance—but we’ll get into all that soon enough). Just as Leo Burnett cut their TV messaging to ten words, and their billboard to four, you must be willing to think twice about every word, every page. Mobile First taught us to focus above all else on the content the customer actually seeks. A better CPQ is what you get when you do that—particularly when you combine it with good design and optimal technical performance.
Most business websites contain dozens of pages that were made to satisfy some long-ago stakeholder. They are pages that nobody visits. Pages that do nothing to help the customer or advance the business’s agenda. Putting all that junk online may have made for smooth meetings ten years ago, but it isn’t helping your business or your customer. Our sites, apps, and products must do both.
Content performance quotient: the secret sauce
Lately in my design practice I’ve been persuading clients to create sites that might superficially appear less effective if you’re going by engagement metrics alone, but which are actually far more successful because they are more instantly persuasive. At my urging, our clients have allowed us to relentlessly cut copy and chop sections nobody looks at, replacing them with a few pages that are there to do a job. We are lucky to have smart clients who are willing to jettison hundreds of hours worth of old work in favor of a streamlined experience that delivers value. Not every client has the courage to do so. But more will as this idea catches on.
(By the way, don’t look for these projects on our studio’s website just yet; they are still in development.)
Serving only the content the customers actually need; streamlining and testing and fine-tuning the interaction to get the right customer to the right content precisely when they want it; wrapping the experience in an engagingly readable but also quickly scannable user interface; and doing everything in our power to ensure that the underlying web experience is as performant as possible—this, I believe, is the secret to increasing CPQ.
CPQ: the story so far
The idea of delivering much less (but much better) first occurred to me while I was looking over a fellow designer’s shoulder. My friend Fred Gates of Fred Gates Design is working on a project for a client in the nonprofit education space. The client’s initial budget was not large, so, to be fair, they suggested Fred only update their homepage. But Fred being Fred, if he was only going to design a single page, he was determined to deliver tremendous value on it.
By focusing relentlessly on the objectives of the entire site, he was able to bring all the principal interactions and messages into a single performant homepage, essentially reducing a big site to a lean, fast, and more effective one.
Far from getting less, his client (and their customers) got much more than they expected.
Inspired by what my friend had achieved, I then proposed exactly the same approach to a client of ours. Not because their budget was a problem, but because streamlining was clearly the right approach … and a redesign is the perfect opportunity to rethink. When you repaint your living room, it gives you a chance to rethink your couch and divan. You’re most likely to consider changing your diet when you’ve begun a new exercise program. Clients are people, and people are most receptive to one form of change when they are already engaged in another.
Positioning CPQ as an aspect of technical performance is another way to overcome stakeholder skepticism. Lara Hogan has more on persuading peers and stakeholders to care about technical performance optimization.
We are a few weeks away from launching what we and the client are calling Phase I, a lean, performant, relentlessly message-focused web experience. But if we’ve done this right, we won’t have much to do in Phase II—because the “mini-site” we’re delivering in Phase I will do more for the company and its customers than a big site ever did.
I’ll be back with updates when we launch, and (more importantly) when we have data to share. Follow @DesignCPQ to stay on top of CPQ thinking.
A beginning consultant brings skills, an experienced consultant brings value.
Early in a good career, you establish that you write the best code on your team, have the deftest touch in UI design, produce more good work more quickly than others.
You’re the person who resolves disputes about which typeface was used on an old poster. Or who knows more frameworks, has used more tools. Or who can fix the server when everyone else around you is panicking. Or all the above.
God is in the details. You sweat them.
You are incredibly skilled and you work to stay that way. You read design books and blog posts when your friends are out drinking or home watching TV. You keep a list of things to fix on your company’s website, and you make the changes whether anyone instructs you to or not.
Often, you make a site more accessible, or more performant, or easier to understand not only without being asked, but without being thanked or acknowledged. You do good in secret. You quietly make things better. You inspire good colleagues to learn more and work harder. Lazy or less talented colleagues secretly hate you. You’re the tops. You got mad skillz.
But the organization doesn’t treat you like the incredibly motivated, supremely talented, highly intelligent, deeply passionate professional you are.
The organization rewards something different. The organization looks for leadership, not among the most skilled, but among the most strategic.
The tragedy of great designers and developers
The tragedy of great designers and developers is when they get promoted to positions of leadership where they can no longer design or develop. And the other tragedy is when they don’t.
You can stay an ace coder, a design whiz, a brilliant copywriter well into your 40s and remain a valuable, employable team member. You will not go hungry. You will not be without work.
(By your 50s, finding jobs becomes tougher no matter how brilliant and experienced you may be, due to capitalism’s preference for hiring younger people and paying them less, but the multidimensional, interlocking problems of agism and economic injustice exceed the scope of this little commentary. Typically the solution to prematurely aging out of the market, even though you have much to contribute, is to go off on your own—hence the plethora of consultants in their late 40s. But here again, merely having skills will not be enough.)
To survive as an independent consultant at any age, and to remain meaningfully employable in digital design, you must bring something different to the table. You must bring value.
You must be able to demonstrate, in every interaction with management, how your thinking will help the organization recruit new members, appeal to a new demographic, better assist its customers, increase its earnings.
Consulting in a nutshell
As a professional with skills, you are a rock star to other designers and coders.
As a professional who brings value, you are a star to decision makers.
Both paths are valid—and, truthfully, a great designer, writer, or coder adds incredible value to everything she touches. But the value she adds may not be one management deeply understands. Just as developers understand development, managers understand management.
If you can speak that language—if you can translate the precocious gifts of your early, skills-based career into a seasoned argot of commerce—you can keep working, keep feeding yourself and your family, keep contributing meaningfully to society and your profession.
Living in New York and working in media, I talk to nonprofit organizations a lot. Big or small, they all say the same. No matter how much work they put into their apps and websites, they just don’t get enough new members. No matter how many expensive redesigns they undertake, they still don’t convert. Why is this?
Generally, it’s the same reason any site with a great product doesn’t convert: the organization spends too much time and effort on the pages and sections that matter to the organization, and too little on the interactions that matter to the member. (“Member” is NGOese for customer.)
Of course there are sites that don’t convert because they have a crappy product. Or an inappropriately priced product. Or because their content attracts people who are never going to be their customers, and gets missed by people who might want what they’re selling. Or because their content attracts nobody. Failure has a thousand fathers, and most businesses fail, so the fact that a website doesn’t convert could mean almost anything. (To know what it actually means, you need data, and you need to watch users interact with it.)
But with nonprofit sites, the product is almost always great, and the person visiting is almost always interested. So what goes wrong?
Never mind the user, here’s the About page
What goes wrong is that nonprofit stakeholders are so passionate about their mission—a passion that only deepens, the longer they work there—that they design an experience which reflects their passion for the mission, instead of one which maps to a member’s mental model.
NGOs lavish attention on their About page and mission statement and forget to work on their members’ immediate, transactional needs. And this is true even for those members who are as passionate about the cause, in their own way, as the stakeholders are in theirs. In the wake of a hurricane, a passionate member thinks of your site in hopes of donating food or giving blood. But nothing on the site calls out to that member and addresses her needs. All she sees are menus, headlines, and buttons trying to lead her to what matters to the organization—namely, the things it says about itself.
How to satisfy the user and convert at the same time
First, decide what one single action you, as the organization, want the user to perform. Should they sign up for your mailing list? Make a donation? Keep it singular, and make it simple. One form field to fill out is better than two; two is better than four.
Next, put yourself in the member’s shoes. What does that member wish to achieve on your website? Have you created transactions and content that allow her to do what she came to do? Have you designed and written menus, links, and headlines that help her find the content that matters to her? Forget the organization, for now. Pretend the only thing that matters is what the user wants. (Because, ultimately, it is.)
Do these things, and weave your singular, simple conversion opportunity into each screen sequence with which your user interacts. To optimize your chance of success, place the conversion opportunity at the very point where the user successfully finishes transacting the business that mattered to her. Not before (where it is only a distraction). Not in another part of the site (which she has no interest in visiting). She’s a lot likelier to sign up for your mailing list after you’ve helped her donate food to her neighbors than she is to sign up in an unsolicited popup window.
Thank you, Captain Obvious
All the above suggestions are obvious common sense, and have been known since transactional web design was in its infancy in the 1990s. And yet, because of organizational dynamics, internal politics, and our getting so close to our own material that our eyes go out of focus, we forget these simple ideas more often than we use them—and fail when success is so easy, and so close to hand.
I HADN’T heard from her in years. Suddenly, there she was in my in-box. Tentatively proposing coffee. Maybe lunch. A dam broke inside me, releasing a flood of warm memories. Our first, tentative contact ten years or more ago. Getting to know each other. Endless, happy discussions about where this thing was going. Coming together on goals and brand; on voice and tone. Finally, the joy of designing and launching her website. And then, abruptly, the last invoice and the hurried departure.
My former client. She had a new job now. She wanted to catch up. And, sheepishly, she admitted, she might want something more. Advice about a design problem.
Over an unassuming wooden table laden with summer lunch—mine was Ramen, hers was salad—we shared personal updates. Kids, relationships, projects. And then we got down to the real agenda: an issue at work that was stumping her. Desire for an outside perspective.
Former clients often feel slightly embarrassed about reaching out for a little free advice. They shouldn’t. As a designer, one of my greatest joys is to reconnect with good people whose projects I loved working on. Design is a job, but it’s also a relationship. When design is going well, the exchange of ideas is almost addictively exciting. And then, all too soon, the project ends, and, if you’re a consulting designer, and you’re lucky enough to have a steady stream of business, you move on to the next gig.
We designers have built-in forgetters: super powers that enable us to care passionately about the problem we’re solving and the people we’re solving it for, and then, absurdly, to discard those feelings as we move on to the next client and design problem.
Clients have a built-in forgetter too. They forget that our relationship, although partly monetary, was also very real. Many clients are self-conscious about reconnecting personally and asking for a small favor in the same breath. But I couldn’t welcome that more. If I can help people, it’s a joy to me. Collaborating on the discovery and solution to a problem isn’t just a stimulating mental exercise and a profession: it’s also a codependent rush.
Between the cracks of my studio’s bigger projects, I’m always looking for ways to help people. So, in the spirit of Ask Dr Web, I’m taking this opportunity to issue an invitation to folks located in or visiting New York. If you’re someone in my network—a former client or old friend or both—with a design problem to mull over, you don’t have to do the mulling alone. Ping me. And let’s do lunch.
NICK Disabato (@nickd) and I discuss heat maps, conversion rates, design specialization, writing for the web, Jakob Nielsen, and the early days of blogging in Episode ? 159 of The Big Web Show – “everything web that matters.” Listen and enjoy.
We’ve got some exciting news to share. Web and interaction design studio.zeldman is moving, from our digs at 148 Madison Avenue to a new location on Fifth Avenue. As of June 1, we’ll be designing, creating, and consulting out of our beautiful new studio space at The Yard: Flatiron North.
But we’re tired of playing landlord. Instead of debugging the internet router, tending to the recycling, hiring HVAC repair people, and seeking suitable replacement studio mates when a company moves out, we’d rather spend our time solving our clients’ design problems and making cool stuff like A List Apart, A Book Apart, The Big Web Show, and An Event Apart. And The Yard’s the perfect place for us to ply our trade and make our goods. (Plus we still get to rub shoulders with other creative business folk.)
We can’t take it with us: furnish your office with our stuff!
Running a co-working studio space meant buying a lot of furniture and equipment. Beautiful stuff, still in great condition. Elegant stuff, because we’re designers. Stuff we won’t need any more, now that we’re moving to new digs where somebody else does landlord duty. So we’re selling it, for a lot less than we paid. And that’s where (maybe) you come in.
Most everything must go, including our famous Eero Aarnio (style) ball chair (if its red cushions could talk!), custom Bo Concept shelving, Eames Desk Units from Design Within Reach, Herman Miller Aeron chairs (ditto), midcentury tulip table and side chairs, black glass desks, Nespresso espresso maker, file cabinets, icemaker, microwave oven, see-through glass mini-fridge, and more. These are beautiful things that inspire good design, and they deserve good homes.
IN Big Web Show ? 158: internet veterans Jim @Coudal & Jeffrey @Zeldman on the death of blogging, the birth of Field Notes, the virtues of a subscription model, and much more. Begins in tears, ends in triumph. One of the most fun (and inspiring) episodes ever. Sponsored by Hotjar & Blue Apron.
AS THE HEAD of a newish design studio, I spend a fair amount of time writing proposals. And here’s how I like to do it.
I do it like a conversation, and that’s how we start: with phone calls and emails to one or two key decision makers, followed by a research period of about two to three weeks. And when I say research, what I’m really talking about—besides the usual competitive analysis, analytics, and testing—is even more conversations, but this time with a wider net of stakeholders and customers.
Some studios do this for free, and other studios only do it if the client has signed off on a huge project and paid the first big deposit. But we do this research for a fee. A small, reasonable, consulting fee. If the client then hires us to do the job, we deduct the research fee from the project cost. If they don’t, they’ve gained a lot of great information at a fair cost. (So far, they’ve never not hired us to go on and do the project.)
From intake to ideas
About two and half weeks into the research project, we have a strong idea of what matters most to the business and its customers, and we begin to have visions of solutions and innovations, large and small. We can’t help it. We’re interaction designers and it’s how our minds work.
After soaking in a potential client’s world for two-plus weeks, we can’t help beginning to invent designs that solve some of their big and small problems, and that enhance what’s already great about the client and their product. This happens in our heads whether we want it to or not.
At first, we are merely neutral listeners, forcing ourselves not to solve, not to imagine, but only to truly hear and understand. But within about fifteen days, we can’t help but begin imagining little modules and big sections, huge themes and tiny, innovative enhancements, which might please and help our client, their customers, or their staff. And so long as those ideas come from the product, come from what the client and their customers have told us, we feel free to begin sharing them.
The first design is written
We do that by writing a report where we share with the client what we’ve begun learning and thinking about their business. Although this report is structured like a business document, we think of it as the first part of design—the first written rough draft of articulating what the client’s business needs to do, and how design might help.
Because it’s a business document, and because we’re workers, not magical pixies, we share facts and data and things stakeholders and customers have said that ring true and that harmonize with other things other stakeholders and customers have said. But all that mustering of facts and data is in the service of a shared creative awakening to the design’s possibilities.
Start ugly to stay honest
Now let me tell you how we present our findings: we present them in a Google Doc that the client can access, share, and comment on. We know that many design studios spend much energy visually tarting up even their most basic client communications. Thus, even a humble invoice comes dressed for the prom.
But we don’t do that. We save aesthetics and beauty for the site design. We keep communications open and plain, like an Amish shirt. And we keep communications editable, because this is collaboration, this is conversation, this is not a dead artifact, a take-it-or-leave-it. And Google Docs is the perfect vehicle for it. Just as the traditionally formatted typewritten screenplay is the perfect, neutral vehicle for a writer to share with a director.
This initial research report, this poem of business, this first, rough, written design, presented to the client via the homey simplicity of Google Docs, elicits more client/designer conversation, more emails, more Basecamp posts, more internal discussions in the studio.
And then, after about a week, we present the client with our proposal. Which is clearly the product of all our conversations, and particularly of all the important agreements we reached during that research period. By the time our clients receive the proposal, they are already nodding, as if they always knew what it contained. Because, in a way, they did. Because, if we did our research right, we’ve merely externalized and articulated what they already felt but had not expressed.
And even now, when we’re asking for serious money to do a serious job, we submit our proposal via Google Docs—because prettified, overly branded proposals are about the studio that produces them, whereas our work is about the client and their product. Because even the most painstakingly researched and written proposal, if it is too pretty and too studio-branded, feels like boilerplate, whereas an ugly Google Doc is clearly just work, to be modified or agreed to or argued about.
This is just what we do at our studio. You can try it or not. Personally, I like this approach and I’ve never had a client complain. I’ve always felt a little dirty when presenting a pitch that was too visually polished, and I’ve never won a single gig with boilerplate. Every job has to be earned by studying and understanding and knowing how to share what you’ve understood. At least, that’s how we do it.
ABOUT A YEAR ago, around the time I launched my new design studio, I moved nearly all business-related communications to Basecamp 3, the latest evolution of the web-based project and communications management tool from my Chicago designer friends who used to be called 37signals.
One of Basecamp 3’s nicest features is the ability to set up automatic check-ins, such as asking all team members “What did you work on today?” at 5:00 pm daily.
On the surface, it’s intended as a way of letting everyone know what their teammates are working on, thereby deleting needless meetings from everyone’s schedules. But the feature can go much deeper, as I’ve discovered to my great pleasure. A day at a time, it can build community and help you design your career and your life. It even brings back some of the joy we once derived from the days of the personal web.
What did you work on today?
Over the years, I’ve started or cofounded several web-related businesses. Rather than limit my new studio.zeldman Basecamp exclusively to the designers, developers, and UX specialists who make up my studio, I decided to include everyone from allthebusinessesI touch.
Naturally, I’m mindful of people’s bandwidth, so anyone who doesn’t wish to participate can opt out or selectively block threads or projects that don’t interest them. I also refrained from inviting two staffers from one of my businesses who, for whatever reason, have just never hit it off with Basecamp. (Evangelizing any tool, however much one personally loves it, is like trying to convince a carnivore to go vegan. It accomplishes nothing, and leaves everyone feeling hurt.)
Save those two folks, with whom I collaborate through other methods, everyone else I work with on a daily or weekly basis, across all my little businesses, has access to a shared Basecamp. And every day at 5:00 pm Eastern Time, Basecamp asks all of us, “What did you work on today?”
The evolution of open sharing
At first, those who chose to participate took the question literally, sharing the work-related tasks we’d accomplished that day. But, over time, we began something sharing else. We began sharing our lives.
As if in a Unitarian church group, or an AA meeting, we share daily joys and sorrows, hopes and aspirations. One of us has a child leaving the nest; another’s child may have had a tough day at school. One of us is writing a book, another has begun physical therapy. Some of us comment on each other’s shares; others use Basecamp’s “applause” feature to indicate that we read and appreciated what was shared. Some folks write essays; others share via bulleted lists.
Hearkening back to the old, personal web
Sharing and reading other people’s posts has become a highlight of my day. Of course it helps me get my work done, but more importantly, it also lets me focus on my life and professional goals—and those of my friends. I love getting to know people this way, and I deeply appreciate how respectful and safe our sharing space feels—partly because Basecamp designed the space well, and partly because I work with people who are not only talented and bright, but also kind and empathetic.
If we all sat together in the same office space, I doubt we would let down our guard as much as we do when responding to Basecamp’s automatic check-in. Indeed, far less personal sharing goes on with the non-remote colleagues in my NYC studio space—probably because we are all there to work.
It reminds me of what life was once like on the old web, where people shared honestly on their personal sites without fear of being harassed. I’m not the only old-timer who misses that old web; in recent years, several of my internet friends who once blogged blithely have switched to opt-in newsletters, sharing only with subscribers. Although I mourn the personal, open-hearted web we once shared, I understand this impulse all too well. Sharing with my colleague/friends on Basecamp restores some of the joy I used to take from sharing and listening on the old open web. You might try it.
Gerry shared example after example of cases where most of this stuff didn’t matter at all to the person using the site or service, and drew the commonsense—but too rare in the corporate world—conclusion that if we spend our time making stuff that matters to our organization instead of stuff that matters to our customer, we will lose our customer. (“Nobody reads your annual report.”)
One of my favorite takeaways from Gerry’s session was about performance, but not in the way you probably think. Gerry pointed out that, in organizations, we are always measuring our own performance: how quickly did we turn that project around? Did we launch on time? Instead of dressing up our navel gazing with analytics that are about our tasks, we should measure our customers’ speed. How quickly do our sites and products help our customers achieve their goals? How can we identify and remove additional obstacles to completion, so our customers achieve their goals faster and faster?
We need to manage speed on the page, not just the speed of the page load. Manage the customer’s time on task. We won’t become customer-centric until we change our metrics—focusing on customers’ time to complete tasks, not on internal speed, and not just on the mechanical speed of page load—although page load speed (and perceived page load speed) are also terribly important, of course, and are part of improving the customer’s time to complete their task.
“If you solve the customer’s problem, they’ll solve your problem.” When you understand your customer’s top task, and focus relentlessly on helping them achieve it, you build a relationship that works for organization and customer alike.
Tomorrow I’ll be back with another top takeaway from another AEA San Francisco 2016 speaker. The next AEA event, An Event Apart St. Louis, takes place January 30-February 1, 2017.