Working with Developers: 12 and counting

One of the great benefits of having worked at the same company for 12 years is that I have developed an outstanding working relationship with the developers. Literally every developer I work with has an appreciation of my role in a project. They understand how my design tasks relate to their development tasks and how the whole process weaves together. They know what questions should be asked of me and which decisions I should be approving, and they actively seek me out of their own volition. More importantly, they recognize that my work makes the output of the team better, thus making us more competitive in the marketplace. Upon attending my talk, Working with Developers for Fun and Profit, a couple of my coworkers expressed dismay that our methods were not commonly practiced throughout the industry.

In a recent discussion, my manager pointed out that once upon a time, if the developers had been instructed to take our customer’s requirements document, develop a solution, and build it, they would have done so. The result would have been similar to any other programmer-designed UI, but they would have done it. If given that charge today, the same developers would likely throw up their hands and say, “Hold on! We can’t do that without Jack (or someone of my talents).” They know that the result would not be on par with our typical work.

I say this not to brag, though I do take pride in it, but to illustrate the value of putting in the time (years, in fact) and effort to learn to communicate, build the relationships, teach the process, and adapt to your development team.

My talk on working with developers was not accepted to Interaction 13, but there will be other opportunities to learn from my experience. Stay tuned. 

Never Enough

Yes, that crazy IxDA LinkedIn thread, Do Designers need to be able to code?, is still running. It took a short breather a few months back, but then somebody resurrected it. Most recently, Jessie Nunez asked, “Will the deep skill set that we took most of our lifetimes to develop, hone, and enhance ever be enough?”

No. No, it will not. You see, Jessie, Interaction Design is very, very young. I was in the third graduating class of the very first Masters of Interaction Design program, and I’m not yet in my forties. At that time, the World Wide Web was brand-spanking-new. There was no such thing as CSS. The Inmates Are Running The Asylum had yet to be published. Yes, we’ve come a long way in a very short amount of time, but to think that the current state of the industry is the be-all and end-all of Interaction Design is foolish.

If we peg my career as an Interaction Designer starting in 1998, the year I graduated with my masters degree, then I’ve been practicing for 14 years. Assuming I live to a ripe old age and continue to work in the field, which I have every intention of doing, and conservatively retire at 65, that gives me 27 years in which to continue to grow in my profession—almost twice the time I’ve spent so far.

Should I rest on my laurels, satisfied that I have mastered my trade? Of course not. I will continue to learn, pushing myself to become a more valuable contributor to my team/employer/customers. I do have a pretty good handle on Interaction Design at this point, and I have a degree in Graphic Design as well. Where do I go from here? I see three primary directions to branch out: business, research, and programming.

By research, I refer to hard-core usability testing, human factors studies, psychology, and anthropology. That’s the area in which I’m least interested. Programming is going to give me the most immediate bang for my buck. The more I can spread my influence across the development of a product, the better the end result is likely to be, and the more satisfied I will be in my work. I’ve already started down this path. Business is a longer term goal, one that I’m slowly absorbing from working with my superiors, as well as reading. Strategically, that is what is likely going to get me ahead on down the road.

In the mean time, everything is going to continue to change at a rapid pace. So, no, it will never be enough. That’s the way I like it.

Designers don’t retire. We die. - Jeffrey Zeldman

Please Pass the Pepper

I love my job. I’ve had the opportunity to design software for explosive ordnance disposal, oil platform and refinery operations, submarine and aircraft carrier maintenance, automobile service, maritime intercept operations, and industrial power system analysis. One of the greatest benefits of being a designer is that every time I start a project with a new customer, I’m learning a new domain. I’m exploring unique problems in fields that I heretofore had little knowledge of, observing people performing interesting tasks, and puzzling over pain points and potential improvements.

Today, I started learning about crime scene investigation. I have a 300 page field guide that I’m digesting while familiarizing myself with a new vocabulary, new tools, new procedures, and new (to me) problems. It’s fantastically interesting, and I can’t wait to begin discussions with the subject matter experts that I’ll be working with.

But, Sunday, I’m flying back up to Groton to train another sub crew, so posts next week will be few, if there are any. They say variety is the spice of life. Interaction Design, then, must be an herb garden. I love my job.

Working with Developers: Designer Wannabe

A few weeks ago, I proffered advice on working with the “old dogs”. Today, I’d like to describe another type of developer I’ve had the pleasure to work with: the Designer Wannabe. Many designers would be annoyed with, or threatened by, a developer that wants to do our job, but I recommend embracing them. Let’s take a look.

Reece Groene
Software Engineer III

  • Loves to do UI work. Where many of his colleagues prefer the back-end stuff, Reece prefers spending his time on the part of the software that people will actually see.
  • Always happy to take a first crack at the UI. He won’t wait for you to deliver sketches.
  • Excited when the designer comes up with improvements.
  • Will work his butt off to implement a difficult UI because he believes in it.

While you may initially feel like Reece is invading your turf, this guy can be your best friend. He understands enough about the user interface to recognize that your designs are better than what he comes up with, and he’s dedicated to getting it working correctly. Here’s my advice for developing a good working relationship with him and using these traits to your advantage.

  • Don’t rain on his parade. Don’t immediately shoot his ideas down every time he does something on his own. Sit down and do a constructive critique. Explain why his decisions are bad ones, and pick out anything that’s worth keeping, or at least considering, for the final design.
  • You may even take him under your wing—start teaching him how you go about designing. There are many good designers that started as coders and few designers that have coding as a strength. You might end up training a new design team member with a very helpful skill set.
  • When you are looking for feedback on your UI designs, run them by Reece. This will help build mutual respect, showing him that you do care about his opinion and recognize his interest and expertise in the user interface. He may even give you some good ideas.
  • Whenever you are unsure about the feasibility of one of your own designs or the capabilities of a particular technology, consult with Reece first. He’ll have a good sense of what your concerns are, what you are trying to accomplish, and for what reasons. He’ll understand the technical problem from your perspective and may be able to offer alternatives that wouldn’t occur to another developer.

In time, Reece may come to see you as a mentor. He will at least respect you as an equal. And with his drive to make the UI the best it can be, he will be a great asset for you.

Free Advice

Hey, all of you newly graduated designers looking to land a job, here are a few suggestions from someone that is looking to hire.

Proofread your résumé. What’s that? You say you already did? Well, do it again! You missed something. Don’t claim to be “detail oriented” and then tell me that you designed landscapes to meet costumers needs.

Include the URL to your online portfolio on your résumé. I do want to read your résumé, but I’m more interested in seeing your work. No online portfolio? Build one. Not only am I going to take a look at your work examples, I’ll be checking out your HTML and CSS.

Don’t just show me finished artifacts. I’m most interested in your process. I want to know how you approach a problem, generate ideas, and document your work. I don’t expect you to be as good at it or as thorough as I am—not even close—but I do want to see that there is something to build on, rather than starting from scratch.

Learn to Create!

I’ve been enjoying Discovery’s new show, Unchained Reaction, quite a bit. It’s a fantastic showcase of creativity, ingenuity, and prototyping. I just watched the most recent episode, which pitted a team of construction contractors against a team of “designers”. They didn’t say what types of designers they were, but the show’s editors made a point of communicating that the team members specified designs for other people to implement; they didn’t know how to build anything themselves. Much of this exposition came from the designers’ own mouths. Meanwhile, the manly men of the opposing team bragged about how efficient they are at building things. They would build big, playing on their strengths.

Of course, this was a dramatic setup, but being a designer, it really struck home for me. I was immediately on the defensive, routing for my team “against all odds”. The cameras portrayed the designers standing around a whiteboard, planning out an elaborate narrative, while the contractors got to work building stuff. During the first test of their opening mechanism, one of the designers loudly proclaimed their success at failing, clearly branding himself as a member of our tribe. In the end, both teams did outstanding jobs, demonstrating admirable creativity and inventiveness. I’m happy to say that the designers were quite capable of building what they designed, and they won, but that’s beside the point.

Designers have accrued a formidable stigma. We’re armchair generals in fancy clothes. There may have always been a little of this perception, but I think it is on the rise. Graphic designers created things with their own hands. Sure, it had to go to a printer for mass production, but there was a craft, materials, and specialized tools. Industrial designers still have the physical component of materials, but most graphic designers are working entirely digitally now. Interaction designers are in an even worse position, because most of us don’t have the skills necessary to realize our designs.

There has been a push lately for designers to learn to code. That’s certainly one approach, and I’m all for it, assuming you have mastered design, but I propose a less-specific movement:

Learn to create!

The Real Challenge

My career as a designer has been all about solving other people’s problems. There’s nothing wrong with that. It’s something I quite enjoy, and I seem to be good at it. At the same time, however, I am more than a problem-solver—I am a creative. I have a desire to invent, to innovate, to create something that didn’t exist before. Sir Jonathan Ive’s comment in an interview with Mark Prigg of the London Evening Standard really resonates with me.

There are different approaches - sometimes things can irritate you so you become aware of a problem, which is a very pragmatic approach and the least challenging.

What is more difficult is when you are intrigued by an opportunity. That, I think, really exercises the skills of a designer. It’s not a problem you’re aware of, nobody has articulated a need. But you start asking questions, what if we do this, combine it with that, would that be useful? This creates opportunities that could replace entire categories of device, rather than tactically responding to an individual problem. That’s the real challenge, and that’s what is exciting.

Treasure the positions and clients that enable you to do such work. They are not as common as they should be.

Working with Developers Survey: Job Situation

As a point of comparison, I asked survey participants some questions about their work context.

What is your current work situation?

If you are employed by a company, are you:

How would you classify your company?

Are you:

I was actually surprised by the high percentage of designers working in software development firms, and the comparatively low percentage working in UX/design firms. I’m still analyzing the data, but I’m expecting this to lead to some interesting comparisons in the answers to the questions that are the meat of the survey.

The Wrong Questions

I’ve been seeing a lot of questions recently along the lines of “Should Interaction Designers know how to do visual design?” and “Should Interaction Designers know how to code?” My opinion on both questions is that they are the wrong questions.

There are very talented, successful, and influential IxDers that can do neither, so it is already proven that a good IxDer doesn’t have to. The question we should be asking is, “What skills will make me a better Interaction Designer?” The answer will vary greatly depending on the context of your work. The type of company you work for, the makeup of your team, the types of projects you work on, and even what you want to be doing in the future all have a bearing on the skill set that will make you most effective.

I have a hard time imagining being an Interaction Designer without being a visual designer, because that is my background. I have a degree in Graphic Design. CMU, where I got my masters degree in IxD, teaches it with an emphasis on visual design. I consider the majority of IxD to be visual communication, and I draw the most from my visual design skill set. But that’s me, and I’m not about to say that it is the only way, or even the best way, to do it. I have too much respect for others in the industry that are not visual designers. In fact, I make a point of impressing on my design students the importance of the multidisciplinary makeup of the design disciplines.

So, I will strongly disagree with anyone that makes broad claims like “Interaction Designers should not be developers,” or “Interaction Designers without visual design chops are inferior.” IxDers don’t have to be visual designers or developers, but both skill sets have much potential to make us better Interaction Designers.

If you really press me, I will probably argue that a designer with skills in both areas has the most potential, but realization of that potential is dependent upon the context in which one practices.

Working with Developers Survey: Titles

My survey was open from December 13, 2011 to January 14th. I advertised it through many channels, including the IxDA forums, Twitter, Facebook, LinkedIn, and DesignAday. I had 308 people view my survey, but only 90 actually responded. 82 completed it, giving me a 91% completion rate. On average, people spent 11 minutes answering the questions.

I created a Wordle rendering of the job titles. It’s not a particularly attractive one, due to the dominance of a very few words contrasted with single use of a lot of words. You’ll have to view it at full size to see any of the smaller words. I did convert abbreviations, such as UX, UI, and Sr. to full words to get an accurate word count. One respondent in particular did not like his/her title: Web Experience Specialist. You can see their unique contribution within the counter of the “g” in Designer.

I was a little surprised by the relatively even distribution of years of experience. I guess I was expecting a higher percentage of designers with 1 to 5 years of experience and a lower percentage of respondents in the 16 to 20 year range.