Put the “designers should code” debate to rest

My acting coach in college used to say something to the effect of, “Be. Don’t show.” It was frustrating. He wanted us not to do the things that symbolized what was supposed to be happening in the scene; he wanted us to live the scene. A good example is acting like a drunk person. We see drunk people, and a natural tendency when doing a scene as a drunk person is to act the way you’ve seen drunk people act. But in many cases, that comes across as fake and obvious. Because people who are drunk often try to act sober.

I worked in an art gallery when I was in college, and once a year we would put on an exhibition of children’s art. One thing you notice when hanging hundreds of paintings and drawing by kids, especially the younger ones, is that many tend to draw symbols of what they see. The don’t draw the sun, they draw a circle with lines around it. Or squiggles. Mountains are triangles. Basic forms are used as symbolic depictions of objects.

This often continues into adulthood, unless one learns to draw at least at a basic level. And while perhaps repeated once too often, it is true to an extent that learning to draw realistically is learning to see. Learning to look carefully at what’s really there. What’s really happening. Circles on a wine glass become ellipses. The hard lines of the sun become gradations of color. Are you unable to draw, and don’t think you can? Grab an image, turn it upside-down, and draw what you see exactly. Don’t symbolize the image by thinking about the subject of it. Draw what’s actually there. For those inexperienced with drawing, it will be one of the best drawings you’ve ever made up to that point.

As designers for the web, depending on what type of designer you are, you are researching, structuring, adapting, testing, laying out, wireframing, setting type for, composing, and [fill in the blank]ing something that people will read, interact with, love, hate, tell others about, and perhaps take with them everywhere they go. And the medium is right in front of you, every day, so you as a designer for this medium have the opportunity to use it to prototype what you’re designing.

I’ve gotten my share of criticism for being one of those people to publicly state that it might be a good idea for web designers to learn some code. It took me several years to come to that opinion and it hasn’t changed much, but it wasn’t the coding that was important. It was the movement away from symbolic representations of that which we were designing. It was about not using flat images as a poor proxy for something that’s different for different people on different devices in different browsers. When I wrote Responsive Design Workflow, which describes a content and prototype-based approach to responsive design, people either loved it or hated it. Those who hated it did so because it was outside of their comfort zones, and because it involved learning basic HTML and CSS and getting into the browser as quickly as possible.

You can’t give me a wireframe, detailed as it may be, and tell me that you’ve designed the interaction of a particular product. You’ve just drawn a circle with squiggly lines around it, and you hope that reality will match. Good luck with that. Visual design influences interaction. Typography influences interaction. Content influences interaction. You either work together, as a team, or your bubble will burst at some point. You want to influence interaction? Get the thing into a browser and interact with it. Sculpt it. Shape it. Tweak it. Be, don’t show.

That’s what it’s about. Not about coding for the sake of coding. During the period of time leading up to my book’s publication, a lot of the tools we have available today to get into the browser quickly didn’t exist. I advocated code because I literally could not find tools that would get me to useful and realistic prototypes as quickly as code would. I had to use JavaScript and the command line to automate screenshots. We have tools that do that today. They do the same thing I did in the past, but they do it behind the scenes. There are now tools all over the place that can help get you get your product into the browser quickly. Even two years ago, we didn’t have many of those tools. That’s why many of us advocated learning to code.

Every so often there are articles and tweets about whether designers should learn to code. I think very little of it is constructive anymore; arguments swirl down into sewers of discussions on semantics, like whether coding is a profession or a trade, or whether HTML and CSS can actually be considered coding. It doesn’t matter.

Must designers learn to code? No. Would it benefit them in some ways? Yes. Is the code needed for much of prototyping more difficult than learning something like Photoshop? No. Can it become more difficult than Photoshop if I decide to dive deep? Yes. Are there ways to prototype effectively without learning to code? There are now. Can you still keep using Photoshop (or Sketch, or whatever) even if you learn some code? Absolutely.

It’s not about the code. It’s not even about the tools. Prototyping is about asking reality for feedback.

On diverse speaker lineups at conferences

There’s been a lot of discussion on Twitter about diversity in speaker lineups at web conferences.

Lea Verou wrote about the blindness of blind reviews, and while she was looking at the process of anonymized reviews in general, some tweets in and around this conversation debate whether anonymizing the speaker selection process eliminates bias. Zach Leatherman tweeted:

I don’t believe an anonymous conference speaker selection process eliminates bias any more than “not seeing race” eliminates racism.

I think Zach makes a good point. Not only does an anonymous selection not eliminate bias, but the only thing it guarantees is that the curators don’t know who they’ve selected.

This does not guarantee a diverse speaker lineup.

What anonymizing does is put a responsibility-absolving blindfold on biases, so one can inadvertently end up with a totally non-diverse lineup and then can say, “Hey, it was a fair selection because we anonymized.”

That’s a weak position, in my opinion. And yes, I know that some people “de-anonymize” in round 2 of their selection process. Kudos. For now, we (the team I work with) prefer invite-only for events with a small lineup, but that’s a post for another time.

We all have biases. But when it comes to biases regarding people, it’s what we do with them that counts. One approach could be to face those biases and consciously act against them in order to get the type of speaker lineup we want. What lineup that is might be different for everyone. You want an all-female lineup? Great. 50/50 split? Also great. Choose what you want and take responsibility for it. Own the selection process rather than hiding behind it.

One possible approach

I don’t have all the answers, but I’ve been a part of conference organizations for many years and maybe the approach we used for two editions of dsgnday and this year’s CSS Day could be useful to some. Again, I’m not saying “we did it right”. I’m just saying that we owned our process and got the lineups we wanted, and someone out there might benefit from our approach. It might not fit with your idea of the right approach. That’s fine. Anonymized curation is okay; I simply have reasons for not preferring it. Please read that again. Also, note that our team consists of four men. This is purely coincidental, something we’re acutely aware of, and is part of the reason we’re thinking so much about these issues.

We started with the goal of the conference itself, of course, which is a range of topics on web design in a broad sense of the word, since the day is meant to be something of a counterweight to the larger number of developer conferences we have here in the Netherlands. However, that doesn’t mean “no code”, so we have a huge base of speakers to pull from, including non-technical speakers.

Right away, our longlist included people we knew would be a good fit for the conference. Krijn, PPK, Martijn, and I kept a simple text file in a Dropbox that any of us could add to at any time when we thought of someone we thought would fit. (Disclaimer: I’m speaking at the event, and while I hope my talk is well-received, that’s in part a financial move since it’s not the most-attended conference in Europe and paying for speakers and their travel is very expensive.)

Setting the goals

While some conferences have a primary or secondary goal of creating a platform for new or less experienced speakers, we currently do not. It’s perfectly valid to require a certain level of speaking ability or experience for an event. There are plenty of calls for papers and other platforms for willing new speakers at other events.

We had also set a specific gender diversity goal for this conference: at least a 50%/50% male/female split. An uneven split in favor of female would have been fine as well. Note that this is a goal, not a quota.

I have to admit that several years ago, I would have found this approach to be ridiculous. I’ve even openly opposed this type of thing. But years in the industry and hearing more viewpoints and a bunch of other factors led to me completely changing my mind. If I just say to myself, “Write out a list of potential speakers”, mostly men come to mind. That’s not a bad thing, but it’s a true thing. Call it a built-in bias. I might just happen to know more male speakers. But it is a fact, at least right now. And to get the lineup we want, we have to consciously combat that tendency. Setting the goal is the first step.

Battling built-in bias

So while I had a couple of people I really wanted to speak (not only men, BTW), I left them on the longlist and did the following thinking exercise:

What if the entire world only consisted of women? Who would I like to have come and speak at this conference?

Names came easily, because we had consciously removed our natural bias by way of a simple thinking exercise. And no one can say that these are “token” (I hate that term) female speakers designed to fill a quota, because they were the people we honestly thought would do a great job and fit the subjects we wanted handled at the conference. Note that it’s getting easier and easier to think of female speakers without resorting to bias-removal thinking exercises. This is partly due to us knowing more female speakers, and also because when you consciously and consistently work to remove bias, it slowly starts to go away. At least, that’s how I experience it.

Anyway, we had several names, and we curated the final lineup based on the quality of each speaker’s work and presentation abilities, and how their varied expertise would combine into a day-long program.

This process might not be great, and the conference is not a big one, but we are really proud of the three lineups of fantastic, qualified women and men we’ve put together so far (we love you, speakers!). And there is no way we could have guaranteed this result with an anonymized process. Without taking responsibility and making conscious choices.

It’s hard to do. That’s why they call it work. :-)

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.