Tag Archives: process

Sketch and Destroy

Designers love their tools and processes. Many verbal battles have been fought about code or images, Photoshop or Sketch, paper or screen. And these discussions are serious. You’d think they were about whether to kill all kittens in the world.

“Why don’t you name your layers?”, asks Designer A, looking in disgust at her coworker’s latest instance of Artboard Copy 05. Designer B shrugs. Designer A visibly shakes, in the throes of obsessive compulsions.

Kittens are dying.

While I understand Designer A—after all, I wrote a book about a particular way of working—I often tend to side with Designer B. Here’s why.

Imagine two Sketch files. Both yield the exact same static image. In our example, stakeholders don’t see the Sketch file. Developers don’t see the Sketch file. They don’t see the layers; they don’t have to deal with the layers. In this case, it doesn’t matter how the layers are named.

Now imagine a relatively small design change. One designer makes a high fidelity mockup in Sketch with full spec. It takes an hour. Another designer opens the page in the browser, open the browser’s developer tools, makes some changes, and screenshots or saves the change and the dev tools CSS. It takes 10 minutes. Both communicate the same thing clearly, one takes less time.

Or a high-fidelity mockup where a super-quick Invision Freehand sketch and a couple of notes will suffice. Or a hand-drawn sketch on a sheet of paper and a 5-minute sit-down with a dev.

As designers, we’re good at asking critical questions. But often, we forget to do the same when it comes to our personal preferences regarding work tools and processes. Some of these questions will help provide direction about things such as naming conventions:

  • How can I communicate this clearly, through the most effective application of my time and effort?
  • Is this an artifact or a deliverable?
  • Will others need to use it in non-exported form?
  • Will this need to be reusable? To what degree?

The end result of a design effort, not including a product itself, is the communication of intent to those realising the production. Developers, for example. And usually non-technical stakeholders. This communication of intent, in whatever form, is your deliverable. All other side-effects leading to that deliverable are, arguably, artifacts. You could, in many cases, destroy them when you’re finished—without consequence.

How many of your Sketch files are really reused by other designers? How many are ever opened again? Do you work in a deeply data-informed environment, where myriads of A/B tests mean you’ll have to rework parts of a previous mockup that are irrelevant to your design changes? Is it quicker to take a screenshot of a current screen, and overlay changes? Are you putting effort into ways of working that make you feel good, but are irrelevant to communicating your intent?

It can be helpful for designers to ask themselves questions about the communication of intent. The following are in order. If you answer no to the first, then you ask yourself the next:

  1. Will a [quick] conversation suffice?
  2. Will a [quick] sketch suffice?
  3. Will a screenshot with annotations suffice?
  4. Will a low-fi mockup suffice?
  5. Will a hi-fi mockup suffice?
  6. Any combination of the above?
  7. I need a prototype. At what level of fidelity?

Of course, ideally you’d come up with questions that fit your own circumstances. These are just examples.

I get it. I do. Emacs vs vim. Gulp vs Grunt. React vs Vue. Sass vs LESS. Spaces vs tabs. (The answer is spaces.) Everybody has preferences, ways of working that are effective for them. But think critically about whether you’re solving the right problem. Those particularities of your own working style might not add much to your actual goal.

Sometimes we present ourselves with the illusion that we’re doing something important. But the biggest waste of time is doing that which need not be done at all.

Never Mind the Process, Here’s the Finished Website

Praise be to Karen McGrane, who dared to defend Lorem Ipsum. Her article couldn’t be more timely, as the festering sore that is the Cult of Content-is-King-and-Design-is-Just-a-Decorative-Sauce-on-the-Content-Entree has started to bleed profusely. And it’s pissing me off. As is the alarming thought trend that all deliverables should mimic the final product.

On content

Content is important. After all, it’s content people who come up with job titles like Content Strategist, which pretty much means One Who Thinks About Content. Which content, for whom, when, where, why, how… It’s absolutely necessary, because clients don’t do it. Not at the level that it should be done.

Paul Rand, one of the most well-respected designers this world has seen, called design “a method of putting form and content together”. If you would agree with this statement (as I do), you can infer the role of the designer as the one who must successfully combine two components: form and content (the designer will first busy herself with the form component). These two are not mutually exclusive. They are separate components which share a common goal and should be developed on a parallel track to one another. This, however, does not mean that they should be reviewed by the client together at every stage.

On clients

Two quick facts about clients:

  1. Many don’t know what they want, and when they do, they don’t know how to communicate it
  2. Many lack the imagination to “see through” design sketches

These are the reasons we are hired in the first place. But these two facts have paved a dangerous path across the lawn of the creative process. An alarming number of web professionals today seem to advocate making preliminary deliverables mimic the finished product– the more accurate, the better.

This is, well, stupid.

It’s not stupid if don’t track your hours. It’s not stupid if you don’t care if or how much you are paid for your work. It isn’t stupid if you don’t mind doing twice as much work for nothing. Your clients will love you for it, and you’ll be doomed to continue doing it for the rest of your career.

On designing in the browser

When Andy Clarke first started talking about “designing in the browser”, I thought it was a great idea. Then people started misinterpreting this to mean “executing the creative process in the browser”. If Andy really designed in the browser, his designs would be shit. What he was of course referring to was the execution of a design idea in the browser as opposed to a tool like Photoshop, which doesn’t communicate Web Things the way a browser does. He strives for more realism in his deliverables. He’s simply working based on the two Client Truths listed above. And if you’ve ever done designs in Photoshop, you’ll know that applying client changes to those documents is akin to cutting off your own fingers one knuckle at at time. HTML is much easier.

That said, there is certainly a place for Photoshop sketches. It’s possible to put together a quick visual impression of a website in far less time than it would take to work out in HTML. I’m referring to the basic idea of a website, an impression of the design language, intended to gauge if we are on the write track before spending many more hours mocking things up in HTML, which is, in fact, templating. I am not referring to creating finished static design visuals. These are the bane of the web designer’s existence, and should be avoided at all costs. If you really understand your client’s needs, that means you’ve done your homework, and you’ve actually designed before the browser. Otherwise: baby steps.

On communication

Imagine that your job was to drive your client somewhere. They aren’t quite sure where they want to go, but a lot of sun would be nice. And perhaps water. You could drive them to California, but once they hear about Florida, they might prefer that and demand that you drive them there (at your cost, because you’re the one who chose to go ahead and drive to California).

A better way would be to communicate with the client, asking them if they prefer dry heat or humidity, surfing or Spring Break parties, earthquakes or hurricanes. Based on this information, you could show and tell about both places, help them weigh the pros and cons, and help them in their decision. Then drive. Only then.

Making websites is a process. Creativity is a process. Pacing and leading clients is a process. You’re not going to eliminate frustration by trying to come up with real content, a polished design and working browser functionality on the first go. You will lose money, though, and perhaps your sanity.

There’s a reason for storyboards. But wait, shouldn’t Pixar just go ahead and build and render the complete movie so that the studio execs can see how it will really look?. Then, if they like it, it’s done! Yeah, right. Good luck with that.

There’s a reason that advertising teams consist of an art director and a copywriter: design and content. They’re bed buddies. But these teams pitch ideas, and then work them out. That’s why we have wireframes. That’s why we have Photoshop. That’s why we have Lorem Ipsum. And that’s why we have, most importantly, good old pencil and paper.

On balance

Here’s what I think: some web professionals want to focus more on deliverables than on people. But guess what: it’s all about people. We need to help our clients along and communicate with them. If you want good deliverables the first time around, the answer is not to use “real” content and a design which is in fact finished HTML/CSS/Javascript in a real browser. The answer is to ask focused questions, discover the pressing problems, to introduce your client to your potential solutions to those problems. Give them tidbits: here’s an impression of how the site could look visually. Here are some things you might want to consider concerning your content. Work your way up to real content in a real browser. When done right, that point can come quickly.

It’s too much to show a client all these things at once in the very beginning. There are too many factors, and it’s impossible to tell which factors will influence their opinions at that moment, which makes revision a nightmare at best. Of course content and form should each be developed with the other in mind. But consider presenting separately at first. Yes, that could mean that Lorem Ipsum is an option. That could mean that Photoshop is an option. That could mean that a sketch on a napkin, with a good, old-fashioned explanation of how things work, is an option. When you know enough, put form and content together.

On bed buddies

And forget the content versus design war. They need each other. In the words of Paul Rand, “when form predominates, meaning is blunted. but when content predominates, interest lags.”

Designing this site, part 2: Values, goals and requirements

A week of hard client work behind me and it’s time to be my own client. And just as my clients would tell you when I badger them with the questions I’ll be asking myself, the first part of good design is not necessarily the fun part. It’s about asking questions, sometimes difficult, but always meant to encourage focus. Focus on what the website needs to be, and for whom.

As I mentioned last week, I’m redesigning this website, which for non-colorblind visitors is the pukey–green monstrosity before you. The color combination has been a joy to me, watching people dry–heave and reach for their feed readers while they still had the chance. But those days are numbered. I consider it quite unacceptable to be creative director of a reputable web design firm and not have a personal site which shows the same amount of thought and effort that goes into client work.

I’ll be putting my money where my mouth is, and using the same process I’ve evangelized for years and use for clients all the time. The Design Funnel is nothing new; many designers follow similar processes. I claim no patented process. It’s simply a (traditional?) process which I’d like to see more designers utilize, especially in this age of jumping–right–into–Photoshop, but also for those who don’t sketch before designing in the browser. It’s about thinking through before doing. It’s about design instead of decoration, which is so prevalent on today’s Web. This site is an example of decoration, and that shows. And that’s a pity.

Step one is defining values and goals. Defining the problem isn’t enough (and defining possible solutions at this point borders on evil—if you’re a designer, you know that a lot of clients tend to do this). My problem is pretty much stated in the second paragraph. But what’s important to me? Let’s not worry about formulating at this stage. This stage is about aggregation. To do this, I’ll answer some of the questions I ask my own clients.

What do I want (the site) to communicate, show, tell or do?

I work hard, with a talented team, for some awesome clients, many of whom are very happy with our work. Client work is nevertheless sprinkled with compromise and factors such as existing brain–dead branding by brain–dead design firms. This is actually the hallmark of good designers: working within constraints. But that doesn’t mean it’s easy. It also doesn’t mean the end result will fit your personal taste.

The Haystack should fit my personal taste. It should be what I feel is appropriate design, and I want to design it myself. It should demonstrate my ability as a designer and art director, and should adapt to the content I choose to publish. It should not overpower the content, nor should it be mere decoration for the content. It should be pleasurable to visit and read (okay, calmly, slowly, place the feed reader on the ground and kick it over to me).

It should be an online repository for all thoughts, ideas, discoveries, code, images, sketches and anything else I’d like to share publicly. It should be technically adaptable to my usual flurries of endless ideas, re-evaluation and mind–changing. It’s a bird, it’s a plane, it’s…

For whom?

I’ll be writing and posting about things for which I have a passion, and that means mostly design and web development, art, technology and any combination thereof. Therefore the audience will be (and is) industry creatives, developers and perhaps a few societal misfits and some very nice people. Oh yeah—some family and friends who will get here by clicking on the little blue E.

Any branding guidelines or creative considerations?

No brand. But the site should make a mark by being recognizable. Creatively, I’d like to be able to tailor the design of posts and pages to the content. Being able to art direct my own posts will be one of the biggest advantages to the redesign. Jason Santa Maria does this fantastically; he’s chosen not to let his CMS determine his design possibilities. The new site should allow me to art direct the full design of a post: type, color, layout and imagery.

It should be standards–compliant. It should be accessible. It should uphold basic usability principles, but I’m giving myself some space on that one. Usability purists, simply turn off CSS completely, thank you.

Technical considerations?

  • Write it in HTML5, just for the challenge of getting the design I want using a moving target. I will, however, think twice about using vague so-called “semantic” elements like
  • Use as much CSS3 as possible. Not necessarily the decorative stuff like border-radius et. al., but really cool stuff like media queries and the tastier selectors.
  • Use Drupal, because I’ve got 2+ years experience with it, and it will allow me the flexibility I want in implementing a design. Plus, it is quite awesome.

Next steps

Reading through this, I realize that if a client had sent this to me as their wish list, I would’ve had a conniption fit at the office. It’s a good thing I know what I mean by all of the above. Now that I’ve got it typed out, though, it’s enough to get the ideas flowing. We’ll cover it and let it simmer for a while.

And then it will be time to start sketching.