Field Notes Inside an Integrated Communications Agency

The creative team was slammed recently, so I spent a day as a graphic designer creating one of the designs for a client presentation. It felt like stepping back into an old, loved pair of shoes that I haven't worn in a while. Those shoes were stiff but still comfy once they loosened up.

A design project typically has several designers assigned to it. Each designer creates a visual idea that is shown to the client, who judges each and chooses one over the others. Having my work next to Shane and Scott Buzik's filled me with a need to really step up and deliver something great.

But I had forgotten things about the hard world of the designer, like the fact that even though you might come up with a great design, it may not be chosen. Harder yet is the reality that hours or days of your time may ultimately be abandoned as the project pursues a different direction. This is hard to imagine for most people whose cumulative effort is rolled into the solution.

But in the five years that I designed Web sites the hardest part was always facing that blank, white canvas that you start with. This situation is made easier by the presence of well-crafted UX and strategy documents. But it is still daunting to open Photoshop and see that white page staring at you.

So the next time you are in a design review, remember that each design represents a lot of hard work. Give each one the attention and chance it deserves. Talk about each one's strengths as well as its weaknesses. When the review is done, consider giving some feedback to the designer. Think about what it must be like in the designer's shoes.

The tool you choose to use should depend solely on the screw you're trying to turn. Same goes for designing Web projects. When beginning the design phase of Web project X, final deliverables should be taken into account when deciding which application to use. Every designer I work with is equally proficient in both Illustrator and Photoshop; while I'm sure every creative has their favorite, both are tools that can be wielded with awe-inspiring deftness. Will the final project hit the Web as XHTML or rich media? Or some amalgamation of both? Making this determination prior to design kick-off can save HOURS of design translation, giving your project a much better chance of coming in on time and under budget.

The formula is absurdly simple:

Flash / rich media = vector = Illustrator
XHTML = bitmap = Photoshop

I submit the responsibility to pose the question is shared. I will try my best to remember to ask - but as long as SOMEONE asks, that's all that matters.

We frequently work with a local company to get interview recordings transcribed. We use transcripts of our stakeholder and user interviews as inputs into our design process. They help us to identify patterns from those we talk to which utlimately inform our stakeholder requirements and user needs and personae. Sometimes transcription works better than others.  Here are some tips:

• A transcript filled with "[inaudible]" notations is not helpful! Test your recorder and make sure you position it in the room appropriately to pick up all voices. (Consider background noise like loud A/C units since they may impact what gets picked up)
• Ask people to speak up if you think the tape may be missing their voice because of low volume.
• Consider giving the transcriber some assistance when you have frequently used jargon or internal terms. (We had a series of interviews on intranets and internets and the transcriber didn't know to pick up on the differences.)
• Voice the interviewer and interviewee names into the recorder before the session. This will help the transcriber track who's saying what. It also can be helpful if you have more than one interviewer and interviewee. (The typical male and female indicators in transcriptions can be very confusing when multiple people are involved.)
• If you are doing lots of interviews, identify the transcript and audio files by interviewee name instead of interview date. Sessions get cancelled and all those numbers make it difficult when trying to sort back through all of the results. 

If you've got tips, we'd love to hear them.

Many years ago I was traveling in the UK, and found myself in a little pub in Wales making friends with some locals. Wales is an awesome place to visit, but if you don’t know any Welsh, the place-names can be tough to work out. They look like unpronounceable jumbles of consonants - some of them might as well be in Chinese. After a few drinks, I built up the courage to ask my new Welsh friends, “so what’s up with the way y’all spell stuff?”

The answer, they told me, was that centuries ago it made it a lot harder on English invaders when they couldn’t actually say the names of the places they intended to invade and occupy. Basically, they were telling me, they spelled stuff that way to intentionally screw with English-speakers. And it’s a plan that clearly works on modern-day invaders as well.

I’m not sure whether that’s actually true or just what they tell tourists in the pubs. But I’m reminded of this because I’ve been reminded so often recently of how difficult it can be sometimes to communicate with clients and colleagues about technology.

I belong to the technologist tribe. I spend at least a little time out of every day doing technical stuff, writing computer programming code, and discussing technology with fellow tribespeople. At the risk of dating myself, I’ll just say I’ve been at this for quite a while. So if you’ll take my word for it, I’ll let you in on a little tribal secret. All this technology stuff isn’t even a tenth as complicated as you think it is. No really, it’s not that hard. What’s hard is talking about it.

Everything hard about technology is in the language: learning about technology from manuals and experts, describing it to people who are unfamiliar with it, asking for what you want, understanding what you’re being asked for - all of it really, really hard.

As someone who’s been in the tribe for a while, I can tell you that becoming a productive technologist is a lot less about the ones and zeroes than it is about simply learning how to communicate with fellow technologists, especially when it comes to teaching it to those who know less than you and learning about it from those who know more than you.

Communicating with people who don’t know any of the ones and zeroes stuff is an even bigger challenge. They need technologists to build technology for them, but they don’t have the language to ask for what they want in a concise way. Sometimes they have a hard time describing what they want in a vague way. How big a problem is that? Try this experiment: think of a popular song. Now find someone who knows how to play guitar or piano. Describe the melody, but don’t tell them anything else about the song you’re thinking of. Do it without reciting lyrics, humming or using any musical jargon. Unless you can get creative about how you communicate with your friend, then it’s not a question of whether you’ll succeed, but who’ll be first to get too frustrated to continue.

With that same kind of barrier between technologists and non-technologists, it’s not surprising that folks who are decidedly not in the technologist tribe can often get frightened, confused, frustrated and even a little pissed off when confronted with Klingon-sounding technical jargon. There might even be the slightest suspicion it’s not Klingon, but Welsh: that technologists’ language is intentionally obfuscated and dense, crafted to keep the magic within the tribe.

For the most part, that’s not true. But what is true is that both technologists and non-technologists are complicit in perpetuating a communication barrier that extends beyond just acronyms and technical terms. You have to be patient (and creative) if you’re going to get your ideas across that barrier. Understanding how and why the miscommunications happen, and how we’re each complicit in making them happen is key to getting there.

So why do technologists use so much jargon? Wasn’t the word “blog” jargon just a short while back? How and when do we get ourselves into these language-barrier predicaments, and how do we get ourselves out of them? In the next couple of articles, I’ll discuss some of the specific challenges we technologists face in discussing technology with our colleagues, our clients and each other, and how to overcome the urge to reject anything and everything that sounds like Klingon (or Welsh).

Ideally, this is first in a series of tips for UXD practitioners. Today's topic: interviewing.

We recently had a lot of stakeholder interviews to complete for a client in a short period of time. Think 65 interviews in a little over 3 weeks. Our interviews were more about buyin and garnering political support than stakeholder requirements, but nonetheless they had to be completed. We took a divide-and-conquer approach. This meant we had first time interviewers conducting interviews. Below are a few tips we created for the team:

• Avoid asking leading questions
• Ask people about recent behavior instead of predicting their actions: people are bad predictors.
• Avoid an inquisition: rather, aim for an organic and natural conversation
• Avoid jumping to solutions or feature ideas
• Listen! Listen! Listen!
• Restate answers to make sure you have understanding
• Ask for clarification of terms or items that you are not familiar with
• If you are not getting clear responses, PROBE!
• Avoid making judgments and assumptions
• Ask questions you think you already know the answer to: answers will surprise you.
• Do domain research before interviews to avoid getting up to speed on the subject matter during an interview.
• Listen for the words they use.
• Avoid getting a list of likes and dislikes. Ask why individuals have their preferences?
• Solicit stories thru "tell me about..." prompts.

Stay tuned for UXD Tip #2 - Transcription Advice