How We Write Proposals in My Design Studio

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.

Also published on Medium.

Automatic check-ins and the old, personal web

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 all the businesses I 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.

Also published at Medium

Measure Customer Time, Not Organization Time: Gerry McGovern

Gerry McGovern12 LESSONS from An Event Apart San Francisco – № 1: Gerry McGovern was the 12th speaker at An Event Apart San Francisco, which ended yesterday. His session Top Task Management: Making it Easier to Prioritize tackled the firehose of content and interactions web and interaction designers and developers are called upon to support.

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.

 

Also shared on Medium

Ten Years Ago on the Web

2006 DOESN’T seem forever ago until I remember that we were tracking IE7 bugsworrying about the RSS feed validator, and viewing Drupal as an accessibility-and-web-standards-positive platform, at the time. Pundits were claiming bad design was good for the web (just as some still do). Joe Clark was critiquing WCAG 2. “An Inconvenient Truth” was playing in theaters, and many folks were surprised to learn that climate change was a thing.

I was writing the second edition of Designing With Web Standards. My daughter, who is about to turn twelve, was about to turn two. My dad suffered a heart attack. (Relax! Ten years later, he is still around and healthy.) A List Apart had just added a job board. “The revolution will be salaried,” we trumpeted.

Preparing for An Event Apart Atlanta, An Event Apart NYC, and An Event Apart Chicago (sponsored by Jewelboxing! RIP) consumed much of my time and energy. Attendees told us these were good shows, and they were, but you would not recognize them as AEA events today—they were much more homespun. “Hey, kids, let’s put on a show!” we used to joke. “My mom will sew the costumes and my dad will build the sets.” (It’s a quotation from a 1940s Andy Hardy movie, not a reflection of our personal views about gender roles.)

Jim Coudal, Jason Fried and I had just launched The Deck, an experiment in unobtrusive, discreet web advertising. Over the next ten years, the ad industry pointedly ignored our experiment, in favor of user tracking, popups, and other anti-patterns. Not entirely coincidentally, my studio had just redesigned the website of Advertising Age, the leading journal of the advertising profession.

Other sites we designed that year included Dictionary.com and Gnu Foods. We also worked on Ma.gnolia, a social bookmarking tool with well-thought-out features like Saved Copies (so you never lost a web page, even if it moved or went offline), Bookmark Ratings, Bookmark Privacy, and Groups. We designed the product for our client and developed many of its features. Rest in peace.

I was reading Adam Greenfield’s Everyware: The Dawning Age of Ubiquitous Computing, a delightfully written text that anticipated and suggested design rules and thinking for our present Internet of Things. It’s a fine book, and one I helped Adam bring to a good publisher. (Clearly, I was itching to break into publishing myself, which I would do with two partners a year or two afterwards.)

In short, it was a year like any other on this wonderful web of ours—full of sound and fury, true, but also rife with innovation and delight.


As part of An Event Apart’s A Decade Apart celebration—commemorating our first ten years as a design and development conference—we asked people we know and love what they were doing professionally ten years ago, in 2006. If you missed parts onetwothree, or four, have a look back.

 

 

Introducing studio.zeldman

STUDIO.ZELDMAN is open for business. It’s a vision I’ve been cooking up, a new studio supported by some of the most talented people in our industry and everything I’ve learned in two-plus decades of web and interaction design. And now it’s here. studio.zeldman designs digital experiences and provides strategic consulting. We don’t have a portfolio yet, but we landed our first client before we launched. Come on down!

The Design

Heading in this direction meant leaving the studio I founded in 1999 (we’re on the best of terms, and it’s an excellent company in great hands). My rise to an almost purely strategic position there taught me a lot about my business—but it also kept me from designing new projects. And I’ve been itching to get back to my roots. Three factors shaped my design for the new studio’s website:

  1. I wanted to try something different: something that was conceptual and art directional. Jen Simmons’s An Event Apart presentations (like this one from last year) inspired me to break out of the columnar rut of current design and create something that didn’t look like it came pre-baked in a framework.
  2. Because I am contrary, I thought it might be fun to allude to an outdated design approach (like, say, skeuomorphism) in a responsive web layout—if the content supported such a gambit.
  3. Most of all, my design had to come out of content.

Let’s unpack that third point a bit more. Normally, design studio websites discuss the customer’s business problems and posit design (and their particular skills) as the solution. It’s a strategy David Ogilvy pioneered for print advertising in the 1950s (“problem/solution”).

Every mention of an achievement or capability exists to show how it solved a client’s business problem: “our redesign increased conversion by 20%” or “our testing and iterative process reduced shopping cart abandonment by 37%,” and so on. Such sites talk about the company’s expertise, positioning it within a framework of client needs. Almost every design studio says the same two or three things at the top of their home page, leaving the real selling to their site’s case studies section. But studio.zeldman is new. No portfolio yet; no company history.

But first, a little something about me

With no portfolio, our strategy—at least for the launch—couldn’t be about our body of work. At least for now, it had to be about me: what I believe, what I’ve done. I came to that realization very reluctantly: I wanted to create a studio that was bigger than any one person. (My original name for the company was simply “studio,” and my plan for the design was that it should be as clean and basic as water.)

But Jason Fried of Basecamp, who is one of my smartest friends, persuaded me that what was unique about this new studio was me, and that I shouldn’t be afraid to say so. Jason convinced me to write simply and directly, in my own voice, about what I believe design is and does—and to support that message by showing some of the things I’ve done that reach beyond my portfolio.

As if I were sitting down to send you a personal note about this new company I’m starting, the best way to express those thoughts on the site was in a letter. That was the strategy. The letter was the idea. And the idea shaped the design.

A new angle on an old design idea

In 2007, if I were designing a site that began with a letter to the reader, I would have used drop shadows and paper textures to suggest that context. Back in 1995, I’d have made an image of a letter on a table or desk top, and the letter would have been at a slight angle, as if the writer had just left it there. Could I allude to these old-fashioned ideas in a way that was subtle and modern?

The 1995 technique of a photorealistic letter was out. But a slightly angled “paper” was feasible; Jen Simmons had shown me and hundreds of other people how this kind of thing could be achieved in modern CSS.

Of course, whether something is possible in modern browsers and whether it actually reads well can be two different things. So while I was comping in pen and paper and in Photoshop, we also ran tests. My collaborator Roland Dubois set up a CSS3 font-smoothing test for angled text in JSFiddle, while my friend Tim Murtaugh of MonkeyDo put together a quick prototype of the top portion of my initial design. Everything checked out.

Once I knew an angled letter could work, I made the angled placement and angular cropping of images a guiding principle and unifying idea for the rest of the design. On the calendar, it took me from January through April of this year to land on a design idea I liked. But once I had it, the site seemed to design itself in just days.

I confess: yes, I designed in Photoshop. (Don’t tell anyone, but I even started with a grid.) And, yes, to your horror, on this project I designed for big screens first, because that’s where these particular design ideas could be most impactful. I knew we could make the design sing on any size screen, but designing for big-screen-first brought this particular project’s biggest coding challenges to the fore and provided the excitement I needed to get to the finish line. Nothing brings a smile to a designer’s lips like seeing your web idea completely fill a 27-inch screen (and do it responsibly, even).

The best part

The best part of the page is the part I didn’t design. Roland did. It’s that magical form. I could play with that thing forever, and I hope potential clients feel the same.

Some folks who checked out the beta asked why we didn’t focus on specific capabilities or budget ranges. Fair question. We certainly could have launched as, say, a redesign shop, or a web-only studio, or a content-focused studio. Any of those would have been credible, coming from me, and differentiating ourselves right out of the gate would not have been a stupid move. We really thought about it.

But we decided it would be more interesting to be less specific and find out what our potential clients are actually looking for. Consider it research that might sometimes lead to a gig.

studio.zeldman thanks you

Mica McPheeters and Jason Fried checked out my copy and kept me honest. Tim Murtaugh coded an early prototype of the site. Roland Dubois coded the final from scratch. Noël Jackson set up the repository and CDN, and ran sophisticated tests that uncovered everything from bugs to performance issues, rebuilding and re-coding with Roland to squeeze every byte of performance we could out of a site with full-screen Retina images. An article by Roland and Noël on the experiments and techniques they used to code this site would be infinitely more interesting than what you’ve just read.

Hoefler & Co. designed the reliable letter font which you will all recognize as Sentinel; DJR created Forma, which I think of as sexy Helvetica, and let us use it even though it is still in beta. Before launch, to save bandwidth, we tried recreating the site design using system fonts. Wasn’t the same. (And with WOFF and CDNs and subsetting, we were able to deliver these wonderful faces without choking your pipes.)

Our thanks to the beta testers: Andrew Kirkpatrick (above and beyond the call of duty on matters of web accessibility), Rachel Andrew, Jen Simmons again, Anna Debenham, Jeremy Seitz, and Nicholas Frota. And to Anil Dash, Jessica Hische, Jessica Helfand, and Khoi Vinh, who gave us design feedback prior to launch.

Most of all, thanks to the “Royal Advisors” who put up with my endless changes of mind, and who always acted as if they were pleased to check out my newest brainstorm, or listen to my latest circular argument: Sarah Parmenter, Jason Fried, Fred Gates, Jen Simmons, and Mike Pick.

A Book Apart Briefs!

Introducing A Book Apart Briefs–even briefer books for people who make websites.

FROM THOSE WONDERFUL people who brought you Responsive Web Design, Design Is A Job, Mobile First, plus thirteen additional instant classics of web design and development, here come A Book Apart Briefs: even briefer books for people who make websites. Starting with the immediately useful and illuminating Get Ready For CSS Grid Layout by Rachel Andrew (foreword by Eric Meyer), and Pricing Design by Dan Mall (foreword by Mike Monteiro).

Web design is about multi-disciplinary mastery and laser focus, so we created A Book Apart to cover the emerging and essential topics in web design and development with style, clarity, and, above all, brevity. Every title in our catalog sheds clear light on a tricky subject, and fast, so you can get back to work.

With sixteen classics under our belt, and buoyed by your support over the years, today we take that mission one step further with our new, ebook-only guides to essential fundamentals, of-the-moment techniques, and deep nerdery.

As A Book Apart co-founder and publisher, it actually thrills me to bring you the pricing guide our business has needed since forever, by Superfriends founder Dan Mall; and the easily understandable guide to the next generation of CSS layout, by the super-talented and incredibly brilliant Perch co-founder Rachel Andrew.

There are no better writer/designers to present these topics. And there are no needless words to waste your time, because these are A Book Apart Briefs: same great writing, even more brief.

Dig in!

Front-end devs, An Event Apart is hiring.

An Event ApartAN EVENT APART, the design conference for people who make websites, seeks a freelance, part-time, front-end developer to work with our web designer, creative director, and project manager on ongoing design and UX improvements to our site at aneventapart.com.

You have a mastery of HTML, CSS (including Flexbox), and JavaScript. You’re a thinker who cares about good user experience and knows that the smallest design details matter. Progressive enhancement is your bread; mobile-first responsive design is your butter. Sweating web performance details is your idea of Saturday night; arguing the semantics of blockquote, your idea of Heaven.

For details, and to apply, see our listing on weworkremotely.com.

Job Hunting For Web Designers

Stagnation is fine for some jobs—when I was a dishwasher at The Earth Kitchen vegetarian restaurant, I enjoyed shutting off my brain and focusing on the rhythmic scrubbing of burnt pans, the slosh and swirl of peas and carrots in a soapy drain—but professionals, particularly web professionals, are either learning and growing or, like the love between Annie Hall and Alvy Singer, becoming a dead shark. If you’ve stopped learning on the job, it’s past time to look around.

Source: If Ever I Should Leave You: Job Hunting For Web Designers and Developers · An A List Apart Column

A List Apart № 421 Gets Personal

A List Apart Issue No. 421

THERE’S GREAT reading for people who make websites in Issue No. 421 of A List Apart:

Resetting Agency Culture

by Justin Dauer

Forget Air Hockey, Zen Gardens, and sleep pods: a true “dream” company invests in its people—fostering a workplace that supports dialogue, collaboration, and professional development. From onboarding new hires to ongoing engagement, Justin Dauer shares starting points for a healthy office dynamic and confident, happy employees.


Crafting a Design Persona

by Meg Dickey-Kurdziolek

Every product has a personality—is yours by design? Meg Dickey-Kurdziolek shows you how Weather Underground solved its personality problems by creating a design persona, and teaches you collaborative methods for starting a personality adjustment in your company.


Design Is A Relationship

Mike Monteiro

MIKE MONTEIRO is a man on a mission. He wants to improve design by fixing the core of it, which is the relationship between designer and client. Too many of us fear our clients—the people whose money keeps our lights on, and who hire us to solve business problems they can’t solve for themselves. And too many clients are even more frustrated and puzzled by their designers than the designers are by the clients.

It’s the designer’s job to fix this, which is why Mike first wrote Design Is A Job, and spent two years taking the message into conference halls and meeting rooms from New Zealand to New York.

I wish every designer could read this book. I can’t tell you how many friends of mine—many of whom I consider far better designers than I am—struggle every day with terrible anxieties over how a client will react to their work. And the problem isn’t limited to web and interaction designers. Anybody who designs anything burns cycles in fear and acrimony. I too waste hours worrying about the client’s reaction—but a dip into Mike’s first book relaxes me like a warm milk bath, and reminds me that collaboration and persuasion are the essence of my craft and well within my power to execute.

If the designer’s side of things were the only part of the problem Mike had addressed, it would be enough. But there is more:

  • Next Mike will help clients understand what they should expect from a designer and learn how to hire one they can work with. How he will do that is still a secret—although folks attending An Event Apart San Francisco this week will get a clue.
  • Design education is the third leg of the chair, and once he has spread his message to clients, Mike intends to fix that or die trying. As Mike sees it (and I agree) too many design programs turn out students who can defend their work in an academic critique session among their peers, but have no idea how to talk to clients and no comprehension of their problems. We are creating a generation of skilled and talented but only semi-employable designers—designers who, unless they have the luck to learn what their expensive education didn’t teach them, will have miserably frustrating careers and turn out sub-par work that doesn’t solve their clients’ problems.

We web and interaction designers are always seeking to understand our user, and to solve the user’s problems with empathy and compassion. Perhaps we should start with the user who hires us.