DesignAday

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.

Simplified to the point of complexity

Since the beginning of DesignAday, I have made a single post per weekday, minus holidays and days I was traveling. Now, I don’t always get my daily post done on the day it’s for. As of this sentence, I am thirteen minutes late for Tuesday’s post. I have always, however, made sure to date the post for the day to which it was intended. Last night, however, I was surprised to find the time and date field missing from Tumblr’s UI. I looked again, and it still wasn’t there. I stared hard at the sidebar where it was supposed to be, but it stubbornly refused to reveal itself.

So, I sent email to Tumblr support asking what happened to the ability to change the date and time of a post. I received the following response:

Hi Jack—

I’m sorry, but that isn’t supported at this time. Our apologies. We will share your desire for this feature with our team.

Thanks
Doug

I don’t understand why such a basic feature would be so casually removed after it’s been in place for over five years. I can appreciate the desire to keep things simple, but is the ability to change the date of a post so costly?

At any rate, Monday’s post is dated Tuesday, and Tuesday’s post is dated Wednesday. I’m sure there will now be some days with two posts, and some, like Monday, will appear to have none. Maybe nobody else will notice or care, but their simplification has become my complication.

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.

In Comparison: Multiple Selection, part 3

Parts 1 and 2 of this series of posts were the result of my exploration to determine the behavior I would specify for a new, browser-based UI. Now that I’ve explained how it works in Windows XP and Mac OS X Lion, it’s only proper that I wrap up by relating my own design rational.

I sat down with the developer who is to implement the feature and went over my findings. She agreed that including an item that was just deselected in a new ranged selection seemed like a bug. While I like the flexibility of Apple’s implementation, I agreed with her that for our purposes, it was needlessly complex. Together, we settled on a single anchor. We decided to set the anchor on clicks and shift-clicks and to not move the anchor for control-clicks. We also decided that, to keep things simple, we would never deselect items on a shift-click. This goes against the standard desktop behavior, but my thinking is that the average user doesn’t likely realize the intricacies of such interactions. As long as we do something that is sensible and internally consistent, I doubt it will be noticed.

I documented the behavior in a series of Interesting Moments Grids, like the one below, that the developer will reference during implementation, as well as during testing.

Agile 2012 Submission

I’ve been working on the presentation I originally submitted to Interaction 12, and I’ll be able to share the survey results here fairly soon. After posting the survey, I was encouraged to submit the talk to Agile 2012, which I have done. Please give the description a read, and let me know what you think. I have plenty of time yet to make changes to my submission before the final deadline. I’m also planning on submitting a variation of it to Midwest UX, and it’s looking like I’ll be test-driving it for IxDA Pittsburgh next month.

There has been a lot of discussion recently about what is required to be an Interaction Designer. Do you have to be good at visual design? Do you have to know how to code? These are the wrong questions. The question we need to ask is, “What skills and methods will make us better Interaction Designers?” The answers 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 so forth. I strongly believe that a closer working relationship with developers and participation in more of the development process will improve your ability to deliver outstanding products and will increase your satisfaction as a designer. I will explain my reasoning and show you how to tightly integrate with your development team.

Process/Mechanics

This presentation is targeted at designers working within the computer software industry. It is based in survey data, as well as my own professional experience and observation of the design community, especially participants in the IxDA and similar forums for discussion.

I will begin by presenting the results of a survey I conducted for the express purpose of developing this presentation. I’ll use that as a launching point from which to share my own journey from a new hire to a tightly integrated member of the development team. As part of this tale, a number of different developer types will surface, and I’ll explain how a designer can work with each type. Then I’ll demonstrate a collaboration life cycle that interweaves with the typical project schedule, showing examples of design specifications and other artifacts that have proven useful in collaboration with developers. This will lead to a demonstration of how participation by a designer in all phases of a project, as well as usage of the development team’s tools, will result in more influence over the end product. Finally, I’ll address the contentious yet vital debate as to whether or not designers should code. Throughout the presentation, I’ll be inviting the audience to participate by show of hands and personal testimony. A period of time for questions will be left at the end.

This is a new presentation that has been under development for several months. I’m planning to present it at a local IxDA event in the near future. While I have not spoken at a conference since ISWC 2000, I have been teaching classes on a weekly basis for seven years. I presented on the topic of designing for the military at an IxDA Pittsburgh event in 2009, and I have given several talks at my own company’s continuing education lunches. References can be provided upon request.

Learning outcomes

• Understand the benefits of a productively close rapport with developers.
• Identify different developer types and the consequent roles a designer may play.
• Employ collaboration life cycles in relation to project schedules and design process.
• Extend your influence, insuring design integrity and improving final build quality.
• Use the development team’s tools, such as issue tracking and version control, and integrate them into your own processes.
• Address the design of your own documentation to be more effective for collaborating with developers.
• Analyze the benefits and perceived drawbacks of learning to code.