DesignAday

Working with Developers for Fun and Profit: Tonight!

I’ve spent all weekend preparing for tonight’s IxDA Pittsburgh event. Here are the details.

February 27, 2012 - 6:30pm - 8:30pm

Hosted by AlphaLab
2325 East Carson Street
Pittsburgh, PA 15203

IxDA Pittsburgh invites designers and software developers to an evening about how we work together, hosted by AlphaLab. Enjoy two great presentations, chat amid the AlphaLab offices, and enjoy snacks and refreshments provided by Daedalus Product Development.

TALKS:

Working with Developers for Fun and Profit
Jack Moffett | Senior Interaction Designer, Inmedius

A lot of recent discussion, in IxDA and elsewhere, asks 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 should be asking is, “What skills and methods will make us better Interaction Designers?” The answers vary greatly, depending on the type of company you work for, team makeup, types of projects, and so forth. 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. In this talk, Jack explains his reasoning and shows how to tightly integrate with your development team.

MockupTiger: a design/dev tool demo
Nilesh Jethwa | Founder & Developer, Rudrasoft

Nilesh will present MockupTiger (http://www.mockuptiger.com), a php application for Dashboard and website prototyping. You’ll see how to use this tool to build mockups, mixing textual widgets with charts to represent design ideas quickly. Nilesh seeks valuable feedback from the design and development communities.

My Sister from Another Mister

I don’t know Jenna Bilotta, but we must have an awful lot in common. My research for Working with Developers for Fun and Profit turned up her December 2011 article, How designers and engineers can play nice (and still run with scissors). Her advice is like a page taken out of my own playbook and covers many of the same points I’ll be making, such as “Use the tools they use” and “Participate in the entire engineering cycle.” Her suggestions for developers even kick off with one of my own mantras, to not let your first answer be “no,” or as I stated in my UI Design First Aid talk, “Postpone no.”

There is one very significant difference, however.

When a designer asks an engineer to move an icon three pixels to the left, or align two blocks of text on the same baseline, that one change might not seem important—but a collection of these things can really make a difference.

I have no problem with the point of that statement; she’s exactly right. I just don’t believe that designers should have to ask developers to make those kinds of changes. It’s terribly inefficient. Once a designer has mastered design, it’s imperative that they begin expanding their skills. If you are an Interaction Designer without visual training, it’s time to learn. If you have visual skills, but don’t yet know how to code HTML and CSS, get to it, and once you have that down, dig into jQuery. When I want a change made in the UI, I do it myself. I don’t need permission, I don’t need to get on anybody’s schedule, and I don’t have to waste time documenting what has to change. Make the change; check it in. BAM! UI perfection in minutes.

Working with Developers Survey: Languages

One of the questions in my survey asked what languages respondents were proficient in. I categorized the languages by type and turned the responses into a treemap with the help of Many Eyes.

As you can see, client side languages are the most popular, with HTML and CSS leading the way. That is no surprise. JQuery is the most used JavaScript library. I think it significant that JS libraries are getting more attention than JavaScript itself. I thought that Objective-C might turn up a little larger due to designers wanting to build their own iApps. I was surprised that ActionScript wasn’t more prominent, but it had the same number of respondents as Java.

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.

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.

National Design Awards

The Cooper-Hewitt recently announced the winners of the 2011 National Design Awards. I was pleased to see that Ben Fry is the winner in the Interaction Design category. Ben has created some fantastic information visualizations and authored the O’Reilly book, Visualizing Data. He has a Ph.D. from the Aesthetics + Computation Group at the MIT Media Lab and was the Nierenberg Chair in CMU’s School of Design during the 2006-2007 school year. He is also one of the creators of Processing and has published books on using the language. He is an outstanding representative of our field, deserving the recognition.

Also of particular note are Steven Heller, author and editor of over 130 books and winner of this year’s Design Mind category; Rick Valicenti, winner in Communication Design; and the recipient of the Lifetime Achievement award, Matthew Carter, designer of many popular typefaces, including some of the most used, such as Verdana and Georgia.

You can check out the winners and finalists in all categories on the Cooper-Hewitt website.

Once Upon a Time…

There’s a great discussion happening right now on the IxDA forums about the technical skills of interaction designers. Should we learn how to code? To what extent? What are the possible benefits and risks of doing so? I’d like to tell you a little story.

Once upon a time, I didn’t know much code. I had learned Lingo, the scripting language for what was then Macromedia Director (now Adobe’s), so that I could create interactive pieces in college. It was very useful for prototyping, but had no connection to actual implementation. I used GoLive Cyberstudio, then later Dreamweaver, to create web pages with WYSIWYG layout. That was fine for websites, but when it came to web applications, the HTML wasn’t clean enough. My role within a project was completely up-front, and once implementation started, I moved to other work and was occasionally consulted by the developers on issues that weren’t covered in my design documentation.

Over time, I became familiar with HTML and was able to edit it directly, then write it from scratch. As CSS popularized, I learned how to use it. By this time, I knew how to use HTML and CSS better than any of the developers at my company. Rather than developers taking my static HTML, cutting it up, and pasting it into JSPs, I was integrated with the project team, editing the JSPs directly. I was able to ensure that my designs were implemented exactly as envisioned. I learned to use the tools the developers were using for checking out and checking in code. I learned to use the bug tracking and tasking software they employed. In so doing, I was better able to influence implementation. I became an integral part of implementation, and thus was involved in the functional testing where I could enter bugs against anything that didn’t live up to my expectations—either from a functional or usability perspective. Eventually, I became familiar enough with the JavaScript that I was able to make minor edits to the dynamic parts of the application. Now that I’m able to use jQuery, there is a lot more behavior that I can implement myself in a way that the developers can use.

So for me, the ability to code is less about earning “cred” and communication, although I’m sure it has helped with both, and more about dependency and scope of influence. I am less dependent on the abilities and attention to detail of the developers, and I now have greater influence over the entire course of a project. As a result, the final product is better.

Does the ability to code, to a certain extent, make me a better designer? I would argue only to a small degree. Understanding constraints and capabilities of a technology is important, and learning to code gives you a better appreciation for that, but isn’t necessary. Better communication and more credibility with developers is a good thing, but learning to code isn’t the only way to get there either. What learning to code has done is made me a more effective designer, as my design abilities better affect the final product. It has made me a more valuable designer, as I can now be utilized more effectively across the entire project schedule.

If you want to be a better designer, learn more about design. If you want a greater hand in implementation and the benefits that go with it, learn to code.

Blame the Browser

He was sure it was a JavaScript problem. We had two tables (that we knew of) that were displaying a disabled scroll bar when it wasn’t needed. The rest of them we had checked were fine. Actually, I should say that a div was displaying the scrollbar. You see, we have tables in which the body must scroll separately from the header. So, I implemented it such that the header and body are actually two separate tables. The body table is in a div that gets a max-height set by JS, based on the height of the window, and has overflow set to auto. The developer that was assigned to fix the bug was looking for a problem in the div sizing logic. He couldn’t find anything. Then I took a crack at it, searching for differences in the CSS. The scroll bar was only showing up in IE, of course, so Firebug couldn’t help me. I was stuck using IE’s built-in developer tools. I compared the broken table with one that was working and compared both of those to my original prototype. The styles being applied were identical. We had spent hours trying to figure it out, and were no closer to finding a solution than when we started.

Finally, I started comparing the tables themselves. It occurred to me that the buggy one incorporated row spans, while my prototype and the working table did not. I removed the row spans and voilà! The scroll bar disappeared. We spent all that time assuming that something was wrong with our code. I should have known it would be a quirky IE bug.