DesignAday

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!

Working with Developers: Version Control

The results of the survey I conducted as research for my upcoming Midwest UX talk indicated that about 70% of the respondents do not use a version control tool, such as Subversion. I can’t say that I’m too surprised by this. Version control is traditionally part of the developer’s domain, and the tools are specifically geared towards code.

Of course it is necessary to use version control if you are a designer that works directly in the production code base. However, I’ve also been using Subversion to track all of my artifacts, from scanned sketches, to Photoshop and InDesign files, to HTML. It gives me great peace of mind to know that every version of every comp is easily retrievable. I don’t have to remember to save a new version of a file every time I modify it. I just check it in. This is especially valuable when you are collaborating with other designers. Your Subversion client ensures that you have the most recent version of every file and presents a history of changes made by all collaborators. And on top of that, your development team now has access to the most recent version of your specs within the very environment they are living in.

If you aren’t already a part of the 30% of designers that take advantage of version control, I encourage you to start utilizing it. I guarantee it will improve your process and lead to tighter integration with your development team.               

Working with Developers: Testing

Only 36% of the designers I surveyed participate in functional testing. In fact, the only activities with less participation are bug fixing, implementation, and the writing of user guides. That’s a shame, because designers make great testers! Good designers are detail oriented, a trait that is also important to testing. Designers use the system more like the users will than like the developers use it, so we will often discover issues that the developers won’t. On top of that, we know better than anybody how the system is supposed to work—we designed it, after all. Participation in functional testing also gives us the opportunity to find and document usability issues prior to usability testing.

Your participation in more of the development process is going to result in a better product and higher job satisfaction. Participation in functional testing is a relatively easy way to extend your influence and grow your technical knowledge.

Working with Developers: Force the Discussion

“Ideally, the developers and I are to work closely together during the design phase… but it typically works out that they gloss over the document or attend a few meetings and get a basic understanding of what we are planning on doing, but never pay attention to the full details. Then they tend to come to me with questions or ‘Are you crazy? I can’t do that!’ when it’s time for them to put together a timeline for their development assessment.”

I don’t know the full context in which this designer works, so I don’t want to be too accusatory, but it seems to me that s/he isn’t taking enough initiative in establishing solid communications with the development team. We can’t afford to just expect developers to show up at our meetings or assume that they will thoroughly digest an entire specification. Sure, some may, but there are competing time-sinks. We need to schedule time to huddle with developers, individually if need be, to walk them through the design. Force the discussions about feasibility, technical challenges, complexity, thoroughness of the spec, and so forth. We can’t blame developers for a lack of attention if we don’t actively engage them during the initial design phase.

Working with Developers: The Results

“I get most frustrated when, after providing a pixel-perfect mockup, I see the finished implementation during the testing phase, and it’s drastically different than what I spec’d (fonts, colors, sizes, spacing, alignment, positioning, etc).”

This comment was left by one of the respondents to the Working with Developers survey I circulated in December and January. It is a perfect illustration of why my topic is so important. There are too many designers working disparately from their development teams. We cannot expect developers to have the same visual sensibilities or attention to behavioral details that we have worked so hard to perfect. It is unfair to berate them for misunderstanding our design specifications when we do not participate in development activities.

The talk I gave last night at IxDA Pittsburgh’s event, Working with Developers for Fun and Profit, is intended to help designers solve this very problem through deep integration with their development teams. The survey was conducted as background research to make sure I had a reasonable understanding of practices outside my own experience. It resulted in a few insights, which I will continue to analyze and share here on DesignAday. For those interested in reviewing the full results, I have made them publicly available at https://www.survs.com/results/TMEFGAPC/13RJJY2M2T. If you have any revelations or questions about the data, please share them with me.

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.

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.

Pick a Card

Another of last semester’s projects found my students designing tools in support of design methods. Kofi Opoku created a set of cards intended to be used when a team hits a wall during a brainstorming session. Whenever there is a pause in the action, draw a card from the shuffled deck and apply it to the problem that is being solved. You might find yourself thinking about how you would solve the problem as a medieval king, or as a member of the opposite gender. You might even draw a coffee break. The deck has some really creative ideas in it, and the cards are beautifully rendered.

Priorities

Designers typically find themselves acting as mediators between the stakeholders of any given project. There are the requirements and desires of the customer, which must be balanced with the time and expertise of the developers, as well as the technical constraints they work under. Then there are the business needs that concern the project manager, among others, such as the schedule, assigned resources, and budget. Oh, and of course we can’t forget our users. Yes, their needs are not always represented by the customer, at least not fully, and may even be in opposition. The designer must take all of the concerns, constraints, and desires, and weave them into the design of the solution.

The designer must remember, however, that of all the stakeholders, the users are her primary concern. All of the other stakeholders already have somebody watching out for them—making sure that their needs are considered. The designer is the advocate for the users. They are our first priority.

How Integrated are You?

While my proposals weren’t accepted for Interaction 12, I’ve decided to go ahead and develop the talks so that they are ready to present elsewhere. After all, one of them is short and practically complete in my head, and the other is a subject that I’m particularly interested in at the moment. To that end, I’d like to gather some information. I’m interested to know how well designers are generally integrated in the software development process.

1. As an Interaction Designer (or similar), how integrated are you with your software development team?
2. Do you utilize some of the same tools that the developers use?
3. Are you tasked through issue tracking software like JIRA?
4. Do you record bugs and issues against your product?
5. Do you check your work into Subversion, GitHub, or some other repository?
6. Do developers consult with you on every UI decision that must be made, from behaviors to buttons and error messages?
7. Are there management-sanctioned processes in place that require design involvement?
8. How much implementation are you responsible for?
9. Do you work directly in the code base?
10. Do you participate in code reviews?
11. Are you involved in functional testing?
12. What kind of relationship do you have with the developers you work with?
13. Are you co-located with developers?

Please answer any or all of these questions in the comments.