DesignAday

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.

D.I.My

Last evening I participated as a subject in a study for a Ph.D. student’s thesis. From what I gather, she is going to try to develop a software tool with the purpose of helping a designer communicate the subtleties of expressive user interfaces to a developer.

For example, if I were designing the iPhone OS, and I needed to communicate to the developer exactly how a list should bounce when it reached the end, how could I do that? Though completely natural, it is not a simple behavior when you start thinking about it. At what rate does it decelerate before bouncing back? How far does it extend beyond the edge before returning? How fast is it moving on the rebound, and how long does it take to stop? I can picture it in my mind, but it could give me a headache trying to spec it in text, which of course I wouldn’t try to do.

I would do exactly what the designers at Apple did when they were designing Mac OS X. I would create an animation in Director that exactly represented the behavior I wanted. Then, once the developer had something implemented, I would sit down with him or her and tweak it until it was perfect.

I wish the student I met this evening the best of luck in her thesis work, but I think she’s working on the wrong problem—or at least not mine. The majority of developers won’t have the visual design skills to fully understand the nuances of the animation—I’d never expect them to. That’s not their focus. So, I’m wasting time if I have to try to communicate nuances to them.

I don’t need another tool that helps me communicate. I need a tool that helps me get what is in my head into code that can be employed in whatever environment implementation is occurring in, be it HTML/CSS/JavaScript, C#, or Eclipse RCP. I don’t want to rely on a developer to get the nuances right.

I want to do it myself.

Postpone No

I’ve asked the developers I work with to postpone no. There is one developer I work with that, upon seeing a sketch for a design I’m working on, will immediately rip off five reasons why it can’t be done that way. The database this, and performance that, etcetera, etcetera. Then, five minutes later, he would be back at my desk with a great idea for how it could be implemented. I ask them to postpone saying ”no” for long enough to mull over the possibilities. Then, if a good solution hasn’t turned up, we’ll work on Plan B.