Designers and developers have something incredibly important in common—but people forget it all the time

In 1999, I overheard something that changed my career. I was the sole Designer at what later became Razorfish, where I sat in a space with a bunch of developers. Standing in the hallway one day, I picked up on something I hadn’t heard since art school: the judgmental, authoritative, biased tones of a Critique in progress.

Critique: A traditional art school activity consisting of ritualized verbal assault disguised as an enlightening series of observations regarding one’s artistic skills, and which is intended to ‘toughen one up’ for the real world

Like Goodall with the apes, I couldn’t be sure that what I was seeing was normal behavior or not. The developers were taking turns tearing into a sad block of code that had been hung on the wall with voracity and a certain glee. “Sloppy”, “bad formatting”, “I could have written this in five lines!”, “What’s with this semicolon use?” These were just the warm ups, and all I can convey without profanity.

After a few minutes,I approached the semi-circle of developers,as I felt like this was my kind of thing. When they saw that they were being witnessed (like something from the DaVinci Code) they quickly put their heads down, went back to their desks and put on headphones.

And so it hit me: Developers are artists too.

Developer as Artist

Over the following decade, I used that perspective to rise in the ranks, eventually becoming Group Creative Director and running a full UX team of Designers, Information Architects, Researchers and Integrators (Blend specialists). All of whom I view and treat as artists.

When I was asked to write a blog post for Mix Online, I wondered what a GCD could possibly say that would interest developers. After some deliberation, my team and developers instructed me to talk about what we do AFTER we sketch—where does a User Interface COME from?

That’s an important question that requires a serious answer, because when I thought about it, I was led to more questions. Such as, “Why don’t they already know this? They’ve been working along side designers for years and we have no inexperienced staff—hasn’t anything rubbed off?”

The Sketch, The Silver Bullet

As an industry, we have spent the last few years beating down the rigid role boundaries of the late 90’s and early 00’s. We’ve largely done this with the sketch, the best battering ram we could find and the great leveler of the field. Now you don’t need a design background to play a critical part in creating the project vision; you just needed a pen and ideas. Suddenly everyone can play.

Books were written, presentations given, software built to embrace it. Clients got hip to it, methodologies adjusted to accommodate it. And once clients started respecting our loose and sketchy ideas as ‘final deliverables’, developers quickly got involved at the beginning of projects too. The impact to product and software design has been profound.

Largely as a result of the sketch, the developer is now a welcomed participant in all conversations with a client. A side effect of this fraternization is what I call skill-bleed: Our roles are more integrated and friendly, and more and more people are dabbling in tasks that have long been the well-defended territory of another group. We suddenly have jacks-of-all-trades popping up all over, and I’m all for it.

The one barrier that I haven’t seen break down, though, is the separation between developers and UI designers. As far as cultural memes go, this one is really, really deeply rooted. There’s a perception that a ‘professional’ developer is precise, analytical, has terrible fashion sense and under no circumstances has the ability to design—the same way that ‘professional’ designers are supposed to be wild, unpredictable, overly hip and elitist. (I’ll also point out that both frequently wear tight clothes, but for different reasons.) These are damaging and dangerous stereotypes that don’t do anyone any good.

From where I sit, I think this all goes back to the question of why a developer would ask me what happens after sketching. After a sketch, UX is usually in control and the developer is once again segregated to specialist tasks. They might conduct a technical audit or produce architectural diagrams, but that’s as visual as they feel they are allowed to get. This way of working supports the professional developer persona I mentioned above, and keeps developers from dabbling in design.

If a developer takes initiative, he or she may start creating prototypes, which involves making design decisions—something they are ‘never’ supposed to do, or do only by taking a personal risk. I don’t ever want to hear the caveat “I’m not a designer, so this UI I sketched sucks” from a developer again.

I’d really like to see a world where this prejudice stops. Developers are artists in their code, and with the right coaching and exercises that mindset can translate to UI design. Naturally, this kind of skill growth will take time, but I hope you’ll join me in believing that the old rules need to go.

Step 1: Permission To Be ‘Emotional’ Has Been Granted.

I think developers would benefit if we busted the myth that there is a ‘right’ answer when dealing with users. Humans tend to believe that the frontal lobe is what makes us different from animals, since it‘s where our rational thought is supposed to come from. Therefore, most (if not all) all the decisions we make must be ‘rational’—right?

Well… maybe. What behavioral science has been uncovering is that the mid-brain, the emotional center, may have a lot more to do with our decision-making process than we would like to think. I’m paraphrasing a lot here, but the gist is that it’s really the emotional center that generates feelings like want, hate, love, etc. The ‘rational’ part of our minds merely rationalizes those feelings, giving us permission to perform the acts that achieve whatever ‘emotional’ outcomes are desired. What? Yes.

What’s my point? As a developer, the first step to post-sketch success is letting yourself off the hook and dropping the idea that right = rational. It doesn’t, and it never will as long as humans are involved. We can hedge our bets with research and studies, but trying to design as people were driven by reason and logic alone will lead you to disastrously lame User Experiences.

Look at it this way: If you can give yourself permission to make strategic emotional design decisions (make it cool, elegant or magical—whatever), you’ll actually come closer to being scientifically RIGHT in satisfying your users. Trippy, yeah?

Step 2: Up Your UI IQ

You can’t create a passable UI overnight, and doing so involves much more than good technique. There are hundreds of unsuccessful designers out there who don’t seem to understand this. To begin with, your UI is an extension of your client’s brand, one of the most critical resources you have in creating a successful design.

A lot of strategy goes into creating a good brand or a logo. Frequently, the more simple a brand, the more complex the strategy that went into it. Your client will likely have some key documents from their branding exercises. See if you can get a hold of them. If you can, great. If not, you can still move ahead.

Pay special attention to the logo; it’s the first clue to the language a client’s brand communicates in. The logo is how the brand says ‘Hello’.

From ‘Hello’, you can often make a number of safe guesses about your UI direction, like colors or button styles that could work or even what container styles may fit. Clients love it when even the initial prototypes are on-brand, so don’t discount this process.

Once you have an idea of what language you’re speaking, you need to know what to say. See if you can let the ‘emotional’ part of your brain drive for a bit and try to capture your visceral impressions. Look at logos, collateral (brochures), business cards, websites, posters or even the physical location (if applicable) for clues.

Deciphering a brand is a lot like wine tasting—at first the vocabulary is strange and fairly aggravating and you have to guess and fail a lot at the start, but it starts to make sense eventually. Once you’re fluent, a lot of doors may suddenly open for you.

The point of step 2 is really to underscore that brand is the cornerstone of a User Interface, but it should also impact your interaction models as well. For example, a client whose logo consists solely of a metallic gray calligraphic font is pretty much 100% not going to be happy with fast, snappy UI where things quickly appear and disappear—but a music site may love that model. The difference is the brand.

Step 3: Get Lots of Exercise

When I took on managing the Integration team (a front-end development team, more or less), my goal was to grow them as designers. So, I gave them a series of assignments to help them learn what to do post-sketch and teach them what design really consists of. I’ll detail these exercises below.

Task 1: Find a User Experience that you think is very effective and be prepared to say why you think it works.

This was a loaded one, because I didn’t say what kind of an experience you should get. A website? An application? A toaster? When we did this at IdentityMine, I got a good variety of User Experiences back (no toasters, though ?), and was pleased to find that the team could articulate what they liked in a user experience: clear navigation, simple presentation, dynamic content, etc. Things that, coincidentally, most users are into as well.

The important thing is that we talked about what a “good” experience was, so that we had the grounds for a meaningful conversation. The UX team also participated in the meeting, letting us know what they look for in a good design and essentially bird-dogging what’s involved in successful UI without it becoming personal (as in, not about their work or the developers’).

Task 2: The Attributes & Associations

The next exercise was to take the user experience in question and start divining the strategy and thought that went designing it. Yes, this is a fairly abstract exercise, but it’s really, really relevant. In analyzing the experience, a person who has his emotional receptors turned on should start to get ‘feelings’ from the visuals, the copy, the images and the flow of the experience.

Note: This may require a drink or two the first few times you try it.

What my team was looking for were the brand attributes, the critical foundational components of the user experience. Here’s an exercise to help you recognize brand attributes:

While relaxing, focus on the brand experience and listen to your subconscious for words that describe what you are looking at. Is it fast? Responsive? Secure? Modern? Capture these emotional descriptors that the experience is conveying, and be ok with being off-the-mark. You can always come back and refine.

Collecting 5-7 of those brand attributes will get you ready for the next task.

Task 3: Get Personal

To teach my team to ‘get personal’, I instructed them to spend time trying to envision the intended target user (or persona) of the experience. See if you can do this:

Think of a couple potential target users of the experience and describe them in any way you find useful. Then, link features and functionality to the story of each user, and see if you can determine cause and effect. There should be a clear relationship between features and aspects of the persona.

There are a lot of ways to do a persona. Some are narrative style (day-in-the-life), some are focused on vital statistics, and some are focused on ‘needs statements’. All are valid, so you should try different versions to see what feels natural.

At first I was amazed by how detailed the team got with their personas, and then I realized I shouldn’t have been surprised—after all, this was all about analytics and detail, something they already excelled at—they had just never been asked to do this.

Task 4: Be Moody

Up until now, the team hadn’t really been asked to do anything that felt like ‘design’ to them. We were slowly demystifying the process and exploring how the different thought-based tasks worked to support the final design direction. We were starting to understand that visual design isn’t ALL visual. This next task, however, does require some design:

Using whatever tool you feel comfortable with (the usual Adobe products, PowerPoint, Keynote on your iPad), make a moodboard/stylepage. The goal is to assemble a collage of photos, colors, typography and UI elements into a single view that the sample experience could blend into. By creating an environment that the experience could ‘live in’, you are beginning to extend the brand associated with the experience. This is a very valuable skill to have.

My team’s moodboards varied in technical sophistication, but each had been able to capture parts of the essence of the experience, the critical lesson.

To keep this from being a totally subjective exercise, I asked the team to turn to the attributes and personas from the earlier tasks to validate their design choices. All of a sudden, it was much easier to pick photography that was right for the experience, because we had built a ‘case’ for making certain choices and could start to logically and rationally ‘prove’ that they had the right images, since they fit the persona, attributes, or style of the experience.

The UX team was on the whole pretty impressed. The Integration team had rapidly gone through a number of the key UX tasks and come out the other side proving that some myths need to be busted. They weren’t tightly coached or and there was nothing to copy (they had no help and did this on downtime)—they pulled this off because they were willing to break their mold, leave their comfort zone and be ‘artists’. They had opened themselves up to being emotionally empathetic at the right time, which caused them to be more rational and strategic than before.

Everyone’s An Artist

These tasks are far from new to UX teams, but they may be new to you or your team. If you haven’t seen them before, the reason may be that your designers don’t show their work. Meaning that often, designers get to a point where we don’t bother to capture all these steps as we go. We end up doing all of these things, but just in our heads and in a few seconds.

So don’t be fooled—designers/creatives/UX’ers (or whatever you call them) don’t wield any powers that are beyond your ability to command. While you were learning to program, we were being forced to cry in front of our classmates in critiques that burned the paint from the walls (maybe that’s why some of us come off as total jerks). Designers just have a head start designing. So don’t sweat it.

At this point you should have a light bulb going off about these exercises and how they can help you expand your skill set. If it isn’t a full-fledged light bulb, I’m hoping it’s at least a candle. What I’ve seen and what I believe is that everyone, including developers, are artists inside. How art expresses itself is different for everyone—some people sculpt, some act, others play music and some people (you know who you are) are coders.

By finding that part of yourself, and giving yourself permission to step out of the stereotype, you can grab a hold of your artistic passion for code and focus it on UI design.

… and that’s what you do after you sketch.