My name is
Jack Moffett. I am an Interaction Designer with over ten years of experience. According to
Herb Simon, that makes me an expert, so I must have something worth sharing. I have started this venture as an exercise to spur critical thinking about my chosen profession. I hope that others may find it thought provoking as well.
DesignAday will present a brief thought about Design every weekday.
Adobe has decided to discontinue the production of Flash Catalyst in order to streamline the product line.
Translation: Adobe has decided to discontinue Flash Catalyst, because we finally acknowledge that Flash isn’t long for this world. Catalyst took too long in development, and when it finally released, it wasn’t relevant to the Interaction Designers that were its primary audience—they were already prototyping with HTML5. We don’t want to have to support it any longer than we have to, so we’re cutting our losses.
I’m sure somebody, somewhere is upset about this. The only thing that I find sad is that I was really excited about it in 2008. It had so much potential! As its development stretched well passed the release of CS4, I became less and less interested in it. It became apparent that it wouldn’t ship with some of the features that attracted me to it in the first place. Apple dug the grave by keeping flash off of iOS while Adobe wrote its own death sentence, unable to get Flash to perform well on Android devices. Adobe’s announcement that it would stop supporting Flash on mobile platforms was the first nail in the coffin—Catalyst is just collateral damage.
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.
The Iconfactory has released version 3 of one of my favorite little utilities: xScope. This is a significant update the makes the already awesome suite of tools, well, more awesome. Take the Loupe tool, for example. It now has two modes: the original mode that showed an enlarged view of the area around the cursor and one in which the window itself is a magnifying glass, allowing you to set it over the area you want to enlarge while doing other things with your mouse. The window is resizable, so you can decide how big or small an area you want to enlarge. A menu allows selection of the format in which you wish to see the color of the center point, and another menu allows you to view the area with different types of color blindness. You can even drag out areas on the grid to measure their pixel dimensions.
I already found this tool to be indispensable. Now it goes all the way to eleven, and that’s just one of seven imminently useful tools. It’s available on the App Store for $29.99, or you can buy a $19.99 upgrade directly from The Iconfactory. It’s a must-have for anyone doing design on a Mac.
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.
In the Highlander series of films and TV shows, a Quickening occurs when one immortal beheads another, receiving all of the knowledge and power of their defeated opponent. A similar phenomena occurs in the software industry when a company ignores their customers. Those customers end up drifting away to competitors. It’s a slow burn, rather than an explosion, but the metaphor works.
I just received email as a “Mac Customer” from Aaron Forth, Quicken’s new General Manager of the Personal Finance Group.
I recognize, however, that we have not always delivered on this promise to Quicken Mac customers.
Darn right, you haven’t. The message goes on to explain that they are working on a solution that will make Quicken 2007 “Lion-compatible” (his quotes, not mine) by early Spring. Yes, that’s right: they are working on making a 5-year-old version of their software run (limp?) in the latest OS. Well, guess what. I don’t want Quicken 2007. Lion finally forced me to kick that fossil to the curb and find something better. I’ve been happily using iBank since July (I wrote about switching at the time). It’s not perfect, and I really do miss the ability to pay my bills directly through the application, rather than having to do it separately on my bank’s website, but there is no way I’m going to go back to Quicken 2007.
Rather than spending time to jury rig obsolete software, why not figure out why so many Mac users were still using it (as if that isn’t fairly obvious), and work on a new version that we actually want to use?
I remember when Photoshop only had one level of undo. You had to take great care with every action, or you would be starting over. Today, nearly infinite levels of undo and redo are standard fare. Why would anyone complain about having an undo feature.
There’s a particularly poorly designed piece of software used for media presentation in worship services called MediaShout. The UI defies all logic, and I could cite any number of perfect examples of how not to design an application. My wife ran into one today. After importing and formatting over sixty slides, she hit the wrong undo button. What’s that, you say? There are multiple undo buttons? Indeed. She meant to hit the one that undid the last edit she made on the current slide. Instead, she hit one that is for actions taken at a higher level of the application’s cognitive model. In this case, it undid the action in which she had added the container into which she had imported the slides. When she pressed the redo button, it recreated the container, but all of the imported slides and the formatting she had done to them were lost. She had to start over.
The application’s cognitive model doesn’t match the user’s. The user doesn’t perceive two distinct levels of activity with separate sequences of events that should be controlled by separate, yet identical buttons. Ironically, the undo button creates the exact situation it is intended to avoid.
One of the capabilities of an application I’ve been working on for two years now is the generation of graphs as PDFs. The UI allows the user to choose a type of graph, select several parameters, specify which axes they go on, and set a number of options. We are using JFreeChart and JasperReports to generate the graphs. I was designing a new type of graph for the next version of the application based on the standard open-high-low-close (OHLC) chart used for financial reporting. I have no need to show an open or close value, but I need to show the high, low, and average values. I was hoping to create something more like a box plot, and while JFreeChart doesn’t do box plots, it will create candlestick charts. So, I worked with a developer to explore the various options provided for styling the candlestick chart. To make a long story short, the best we could come up with was to use the high and low “wicks” as intended, but set both the open and close variables to the average. That gives us a vertical line from high to low intersected with a horizontal line for the average. I can style the length of the horizontal line, but that’s the extent to which I can customize the display in any useful fashion.
Time and time again, I end up working with these tools that make it really easy to implement what would be relatively difficult and time consuming, but they are hobbled by a seemingly mindless inflexibility. How difficult would it have been to allow the thickness of the vertical stroke to be styled separately form the horizontal stroke? Why not allow a horizontal stroke to be placed at any data point on the vertical line? With just a couple extra options, the tool would be able to support many variations on the basic chart types. It’s as if the creators never imagined that someone might want to do something differently than the way Microsoft Excel does.
There’s a rather amusing, and quite clever, YouTube channel titled the Museum of Obsolete Objects. Short videos demonstrate the use of objects that, as the name implies, have become obsolete. The dial telephone, instant camera, and abacus are examples. The videos are well-produced, and many of them point out unintentional quirks, such as how a pencil was used to wind up a cassette tape that had been eaten by the player, how a record could be played backwards, and how to cut a second notch in a 5 1/4” floppy to make it double-sided.
They are all obviously created for comical amusement, but it has me thinking about a minor concern that has bothered me for some time. Our technology is advancing at a very fast rate, which means things are also obsolescing at a very fast rate—fast enough that we lose things before we care enough about them to save them. The film industry has done a fair job of keeping movies available for viewing. I can sit down and watch old black and white films on DVD or even digitally. The same goes for music. But what about computer games. The vast majority of the games I own are not playable on any device I have access to, yet they are as sentimental to me as any movie. A few games have been rereleased for newer platforms, and there are emulators for several more, but what of some of the fantastic explorations from the early days of “multimedia”? All that’s available for Laurie Anderson’s Puppet Motel is a short demo reel on blip.tv. The music from The Residents Freak Show is available on YouTube, but there doesn’t appear to be any video of the actual gameplay. I’m even having difficulty updating the student work I created in Macromedia Director. Then there is software—just plain old user interfaces. Where can an Interaction Designer go today to experience the original Palm OS or a Silicon Graphics machine running IRIX? Aren’t user interfaces historical artifacts that we should be maintaining for future study?
Recently, Photoshop CS4 has been hiding many of my menu items, including an option to “Show All Menu Items”. It’s been really annoying. First, I think I must be looking in the wrong place for an option that I know should be there. Then, I finally notice the “Show All…” option. Clicking it reveals the option I’m looking for, which requires an additional click to activate. I didn’t know why the menu started behaving this way, as it didn’t used to do this. A search of the preferences turned up nothing. Finally, I Googled it and found a blog post by John Nack that explains, and solves, my problem.
As John suggests, the dialog is poorly written. It doesn’t communicate what is actually going to happen. So, you end up unwittingly setting an invisible preference. You don’t know what you did to set it, and you can’t find anywhere to turn it off. That’s really poor design. I haven’t had the opportunity to use CS5—hopefully this has been fixed.
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.
- As an Interaction Designer (or similar), how integrated are you with your software development team?
- Do you utilize some of the same tools that the developers use?
- Are you tasked through issue tracking software like JIRA?
- Do you record bugs and issues against your product?
- Do you check your work into Subversion, GitHub, or some other repository?
- Do developers consult with you on every UI decision that must be made, from behaviors to buttons and error messages?
- Are there management-sanctioned processes in place that require design involvement?
- How much implementation are you responsible for?
- Do you work directly in the code base?
- Do you participate in code reviews?
- Are you involved in functional testing?
- What kind of relationship do you have with the developers you work with?
- Are you co-located with developers?
Please answer any or all of these questions in the comments.
