Category Archives: Creativity

My name is Stephen, and I’m a generalist

This week I had something akin to an existential crisis. The whole thing was solely in my head, and alarming in intensity. If you ask me what triggered it, I couldn’t tell you. Though it might have been that potential client that needs to learn about how to deal with potential contractors, but that’s another post entirely.

Part of this mental hurricane was me questioning what it is that I actually do. What is my job, exactly? I’ll spare you the worries about how this question might tie in to age discrimination and how I must remain my own boss in order to continue working. No. I can hear you thinking about it. Stop it.

In the 20 years I’ve been designing and developing for the web, I’ve considered myself a designer. A designer who can code, but still a designer. And indeed, when I started, I designed a lot. I came from print design. Design, especially typography, was what I loved to do. In the work realm, at least.

I wrote my first BASIC program when I was 12 years old. On a Commodore PET. Yes, I see you oldies nodding. We had an Apple II in a special room at school. One Apple II. Programming was like magic. Someone wrote code and made these computers do amazing things!

I was fairly good at math(s), roughly two years ahead of my fellow students, but I’m also easily bored. So after advanced trig, I kind of lost interest in both math(s) and programming. I liked it well enough, but I encountered a dull patch. Other things, like art and theatre, grabbed my interest.

Programming never did let me go. I came to realize that some things are simply more effectively done in code, and that there was space in my brain for both the technical and the creative. But people seem to fight against that particular brand of collaboration between the different parts of the mind. We’re told to specialize. You can’t just specialize in JavaScript; you must specialize in a particular aspect of JavaScript, such as performance. Or a particular library (good luck with that). You also can’t be a “designer”, because what exactly does that entail? Do you do interaction design? Visual design? Or as ambiguous as they come, user experience design?

If I put 10 people in a room and asked them to describe user experience design, I’d get 10 different answers. 11 if it’s a really creative group. While speaking recently at UXLx, I encountered UX designers who don’t draw. “I only do research”. Others design the user experience of websites without venturing into the browser. Graphing software is enough; after all, they’re UX designers, not UI designers. (Oops there’s another one for you.) Some UX designers did more visual design. Confusion ensued.

Not that these disciplines are bad or unnecessary. On the contrary. Nor is the fact that we might soon need a complex table to map out the various types of design we’ve created and their relationships to one another. But where we can complicate things, we tend to complicate things. And when specialization means money, we’re quick to specialize.

And now we’re entering a period in which the spectrum of specialists is just a bit too large for some projects. Like a feature film, all the disciplines need a lot of overhead to work together smoothly. And we look to the generalists. We might call them “product designers” or “full-stack [insert title here]”. Proficient in many areas, expert in one or two. For me, I’m an art director at heart with a lot of experience in graphic(visual) design, interaction, design processes and dealing with large-org project politics. And I can code.

When people ask me for a portfolio of recent design work, I’m shocked to discover that I really don’t have a clear one. The work I’ve done since going freelance five years ago is mostly front-end development combined with design and interaction work. Which all, believe it or not, is part the user experience. Thus, I’ve done front-end design and development consulting work. Accessibility work. Speaking. Writing a book. Co-organizing conferences.

Holy hypertext, Batman, I’m a generalist.

The thing that’s both scary and exciting at the same time is that no generalist is the same. This week I came to realize that I have no clue how to market myself effectively. (No that is not an invitation.) I’m an expert in a few things, and proficient in several more. But for every project, emphasis shifts within those areas.

This week, a friend told me that he doesn’t know what to call himself. Then he said, in his typical manner of a man who believes that every workday is just a holiday that starts with a “W”:

“Embrace the chaos.”

I like code. I like design. I like the place where design and technology meet. Where art and technology meet. It’s a special place. It exists and we should embrace it.

Some thoughts on “designing in the browser”

Ever since Andrew Clarke’s presentation The Walls Come Tumbling Down—which is the first time I heard of the term—the idea of “designing in the browser” has increasingly become a point of discussion and debate.

As one of those crazies who doesn’t use an image editor (like Photoshop) to create design comps, I’m often lumped into the design-in-the-browser category. So let’s clear things up a bit with my take on this approach.

You don’t actually design in the browser

Okay, you can design in the browser, meaning you open up a blank HTML file in both a text editor and a browser and have at it. But why would you? Some people really mean this when they speak of designing in the browser. But in my experience, that’s often not what we’re really talking about.

When I speak of designing in the browser, I mean creating browser-based design mockups/comps (I use the terms interchangeably), as opposed to static comps (like the PSDs we’re all used to). So it’s not the design. It’s the visualization of the design—the one you present to stakeholders. It’s not the only deliverable, but it’s the one that’s most important to show in the browser. Before that, I sketch. On paper. Other people I know who “design in the browser” actually use Photoshop. For sketching. But when we say “designing in the browser”, we mean the comp is in the browser.

We sure do like our comfort zones

Creating comps like this puts many designers out of their comfort zones. Many feel they have to learn to code, or “think in HTML and CSS”. Those who know that isn’t true can still feel awkward pairing up with a developer to visualize designs. That said, I think that learning CSS can be a useful addition to a designer’s toolbox. Note that in all my talks and in my book, I’ve only ever stated my opinion that browser-based comps are preferable to Photoshop-based comps. I have never stated that code should replace Photoshop.

That said, I’m increasingly frustrated by the articles, talks and discussions defending Photoshop comps, almost all of them citing Dan Mall’s idea of “deciding in the browser” rather than “designing in the browser”. I do agree with Dan; in fact, designers should already have been “deciding in the browser”, for years, especially when doing static image comps. If you design for the browser, you decide in the browser.

So much effort is being put into stating the case for static image comps, almost as if to justify the current (which is also the past) way of working. “Let me tell you why I want to stay in my comfort zone.” “Let me tell you what you other disciplines need to do for me so that I can continue to stay in my comfort zone and do things the way I’ve always done.”

It would all be fine, if it weren’t complete bullshit. And that is partly due to the flimsy premises of the arguments given.

Flimsy arguments

I don’t mean to pick on any specific article, but I’m compelled to provide an example and this particular article really got to me. Probably because I’m sure the author is skilled and talented, and thus many folks who read the article might swallow the premises whole. But looking at the points made, I’m inclined to disclose a couple of fallacies.

  1. The author states that the desire to increase the speed of design and development is the driving force behind designing in the browser. While speed may be a factor, it’s arguably not the main factor, and certainly not the only one. More important, for example, is bridging the traditional gap between what the client sees in a comp versus the end result.
  2. The implication of the sentence that follows is that web-based comps help speed but reduce the quality of the design work being produced. Tell that to The Guardian.
  3. The author then proceeds to make the case for Photoshop instead of code (albeit with an 80/20 split). Nothing wrong with that, but the author’s personal experience with code yielding “dull” designs does not mean that code yields dull designs. It most likely means that the author tried getting into code too soon, or skipped sketching altogether, or is simply not as comfortable in code. I would agree that might not work out well. But in that case it’s the design process at fault, not the fact that code is used at all.

Code can support the creative process

Fabulous, creative things are being done with code. Just because some of us are more comfortable with graphical tools doesn’t negate that fact. It simply means that we’re less comfortable with code because we don’t know it as well as the tools we’ve been using for years and years. Which is logical, if you haven’t learned to code yet use Photoshop daily. And if you’re in my age range, you’ll remember that we didn’t always use Photoshop to create design comps. We had to get out of our comfort zone and learn it. And learn it we did, eventually.

For every person who tries opening a text editor and typing code from scratch before claiming “FAIL”, there are scores of us who actually sketch before even touching code. And I know designers who don’t code, but team up with developers to create design comps in the browser.

If you prefer using graphical tools, that’s fine. Nothing wrong with it. No one’s attacking you. But don’t say web-based comps are about speed when they’re not, that the process is less creative when your own approach to it is the problem. Photoshop is neutral. Code is neutral. It’s what you choose do with them and how.

I think code is a valuable tool, and I think web-based comps offer a plethora of benefits to the design process, clients, and teams. But again, I said web-based comps offer benefits as compared to Photoshop comps. Not “code is better than Photoshop”. That’s a huge difference. Designers know Photoshop; not all of them know the benefits of code as a design tool. I feel it’s important to talk about that.

Nobody is going to take your copy of Photoshop away from you. So since no one’s attacking, perhaps there’s no real need to defend. With false statements at that. In fact, for every defensive article or talk or tweet against code, I think about how time could have been spent learning some.

Creativity is tool-independent.

Responsive Design Sameness

Sometimes, when discussions are really interesting, I find it hard not to chime in.

Mark Boulton tweeted:

I wonder if #RWD looks the way it does because so many projects aren’t being run by designers, but by front-end dev teams.

Then the fine Mr. Tim Kadlec wrote a great post, followed by observations from Susan Jean Robertson. There were also a few thought-provoking responses to Mark’s tweet.

Tim and Susan (and others on Twitter) seem to agree that workflow/process—specifically lack of communication between designers and developers—tends to lead to the type of design sameness we’re observing today. I agree that this is a problem for many aspects of the design process; in fact, I wrote a book about it. And with the utmost respect for Mark, Tim and others, I tend to be skeptical that getting designers and developers to work together will solve the design sameness problem. That’s not to say it doesn’t need to happen; it certainly does.

In my experience, most projects are not run by front-end developers, as Mark suggests might be the case. Of course, that’s just my experience. In fact, I observe that front-end devs often get the short end of the stick, basically forced to implement whatever gets thrown on their plate by designers and requirements. In the same way, the visual designers before them in the waterfall process must implement that which has been handed to them by interaction designers, UX designers, or whoever might be in front of them. A slightly longer stick, but still pretty short. This is a workflow problem, and one of the main things I’ve spoken and written about for the past few years.

But this doesn’t necessarily explain why responsive sites share similar visual characteristics.

At the moment I can think of three things that I theorize might be at least as important as workflow, in regards to RWD design sameness:

  • Lack of a solid graphic design foundation
  • Excessive reliance on tools
  • Lack of critical design thinking when copying the work of other designers

Lack of a solid graphic design foundation

Now that design education has fragmented somewhat between “traditional” graphic design and web/digital/whatever design (even though students are often required to take both), I get the feeling that many designers live with the assumption that these are two separate worlds. It’s probably our fault (I know I’m guilty of it): we keep hammering on the differences between design for web and design for print.

But web and print are simply media. Design is problem-solving. Design is—and for the umpteenth time I quote Paul Rand—”the method of putting form and content together”. Contrary to popular web-belief, good web design is not only typography. Web designers need to know how to design. They need a solid foundation in the principles of design. And when they choose their preferred medium, of course there are always specifics that are only relevant to that medium.

A problem arises when designers lack a basic design foundation, yet have a working knowledge of medium-specific design concerns. Lacking the foundation, their creative potential has a fence around it. And, if what Mark says is true and devs are designing, that foundation might be lacking as well. And, no, I don’t mean go read The Elements of Typographic Style and you’re off to the races. Graphic design is a formal, legitimate field of study.

Judging by what I’ve observed while guest-lecturing to web design students, I suspect that tool-based education and reliance on tools and frameworks is partly to blame.

Excessive reliance on tools, frameworks and pattern libraries

Similar to Mark, I’ve often quipped that 50% of the web looks like Twitter Bootstrap. And it shouldn’t be surprising when a good portion of web design education is tool-focused. Photoshop. Illustrator. Web-based answers to Dreamweaver (“but they generate better code!”) that use frameworks as a Foundation for the generated code. (See what I did there?)

No matter how you look at it, tools are just tools. In my book, I present the Tool Rule: it’s not about the tools. Frameworks are prefab. These tools are about execution, not design. Design involves first thinking, then execution. And when one designs for a particular medium, they need not be shielded from the inner workings of that medium. Designers who want to know how to change Bootstrap need to know the inner workings of Bootstrap; have fun switching frameworks down the road. But why hide the web from them behind an abstraction layer? Would designers come up with more appropriate visual patterns if they knew more about what was possible outside the confines of a framework?

Yes, designers must learn tools. Which tools would make them more effective at being able to effectively design for the web: those that teach them about the web, or those that teach them a particular framework? I don’t know the answer; I just have my opinion.

Lack of critical design thinking when copying the work of other designers

Designers copy/steal trends all the time. Sometimes this is mandated by bad clients (“my competitor does this so it must be good”—oh, the logic), and often designers emulate the bits they like from others’ work into their own projects. It’s not only graphic designers doing this, but interaction/UX designers and developers as well. We copy patterns we like. We have pattern libraries. Prefab building blocks to help us work faster. Faster perhaps, but not always better.

Emulation is a part of the evolution of design. And the web, for that matter. But design sameness tends to fade when one forgets all of the existing patterns, all of the Bootstraps, all of the preconceived design solutions. Design sameness fades when designers stop focusing on which solutions for their problem are out there and start focusing on the problem at hand.

Solve that problem, and maybe the solution is exactly what your peer implemented, in the exact same way. But maybe not.

(Thanks to Mark Boulton for reviewing this post.)