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.
When you are going to be giving a presentation, be it at a conference, to a client, or in class, it would behoove you to be prepared. I’m repeatedly surprised by how unprepared presenters often are. These tips seem obvious to me, but perhaps they are worth repeating.
- If at all possible, test the presentation equipment beforehand. Even if it is only five minutes before you are to start, you should know ahead of time that the projector is set up correctly (in focus, correct aspect ratio, keystone, etc.) and that the computer you are presenting from interfaces with it properly. If you are using audio, make sure that there are speakers connected and working and that the volume is set correctly. Also, if you have video or other types of media as part of your presentation, ensure that they play back correctly. Is an internet connection necessary? Make sure you have one and can hit whatever websites you intend to show.
- If you are presenting off of your own laptop, make sure you have all of the adapters that you may need. An extension cord and display patch cable could even be useful, giving you more flexibility in where you can place your laptop in relation to the projector and power outlets.
- Make sure you have the correct software to run the presentation on the machine. Or, make sure that you have your presentation in several different formats, including paper. When I gave my last presentation, I arrived with Keynote, Powerpoint, PDF, and HTML versions of my slides. Never make your presentation dependent on the internet. Take screenshots that you can use in place of the live site in case you don’t have a connection.
- Consider how you are going to drive the presentation. Will you have some type of remote control? Will you ask somebody else to advance your slides? Or, will the presentation machine be directly in front of you? Personally, I prefer to be able to stand beside the screen so that I can’t point to things and face the audience while I’m speaking to them.
- Make sure you have run through your presentation, start to finish. Proofread the content, and make sure that any transitions and progressive reveals are working as intended.
Ensuring that your presentation runs smoothly from a technical standpoint will keep the focus on the content you are presenting.
As I’ve become more proficient with CSS, and as CSS has become more capable, I have found myself contributing more and more of the final code. Behaviors that once required a developer to write JavaScript, I can now accomplish with dextrous application of styles. Lately, it is common for me to deliver all of the final HTML and CSS to the developer. I much prefer this, as I am able to attend to all of the little details that a developer would overlook. It’s much easier to put in the extra three pixels of padding on the right side of a div myself than to document it in a specification and check to make sure it’s correct several weeks later. The end result looks and behaves exactly as I’ve designed it, and the code is cleaner because I have a better understanding of CSS than the developers I work with.
So, I’ve been changing hats a lot. I try not to think about implementation while I’m sketching and working in Photoshop. I try not to let my knowledge of what is hard and what is easy influence my visual design. Then, when it comes time to build it, I take off my design hat and put on my coding hat. I think about keeping the HTML as clean as possible. I think about how to create my style sheets without repeating a lot of attributes. I think about how to limit the number of things that the developer will have to manipulate with JavaScript. Certainly, my goal is to faithfully reproduce my designs, but sometimes I find aspects of the visual design that just aren’t practical for HTML implementation, and I have to compromise.
Changing hats has given me a deeper appreciation for the issues that the developers deal with on a regular basis. At the same time, it has made me less sympathetic to anyone who complains that a design is too difficult to implement, and less likely to scale back my designs when I meet resistance. Having worn the other hat, I know better the difference between difficulty and laziness.
The details are not the details.
They make the design.
Charles Eames
I was recently asked by a developer that doesn’t know me very well if I thought the little details were all that important. Eames’ quote literally exploded in my head.
The details are the distinguishing factors that make the iPhone something more than the knock-offs. The details are the decision points that lead you to choose an OXO Good Grips potato peeler over that other one. The details lead people to shop at Target rather than Walmart, to eat at Panera instead of Quizno’s, to pick out a pair of Nikes, order from Amazon, and play World of Warcraft.
But the details run deeper than just brand loyalty and rampant consumerism. The details can evoke emotion. They can turn an object into an heirloom, a service into a relationship, or an experience into a lifelong memory. The details are what make Disney World magical. They make a Pixar film ten times better than any other animated feature on the big screen. They make the Harry Potter novels just as riveting to my sixty-year-old mother as they are to a high school kid.
What I’m insinuating, is that the details are the embodiment of quality. The details make something special. If you aren’t thinking about the details, you aren’t designing.
A good designer must have a reason for everything. Every detail is the result of a decision, made consciously or unconsciously. The designer should document decisions for any issues that were deliberated over or contested. He must also recognize the subconscious decisions and understand the reasoning behind them when asked to explain. If a client ever receives an unsatisfactory answer, such as “I don’t know,” or “I just thought it looked better,” they have carte blanche to overturn any decision the designer has made.
When evaluating one’s own work, a designer should continually ask herself why. Why did she use that color? Why did she place a particular element in that exact spot? Why is it that specific size? Perhaps these were intuitive decisions, but there was still a reason behind them. Understanding those reasons will make a designer more confident in communicating the solution to others, leading to more trust from clients and other collaborators.
There is a reason for everything. If you don’t have a reason, you haven’t given enough thought to your design.
It seems to me that many interaction designers just assume that we all create wireframes—that it is a given part of IxD process. I’ve taken surveys that make that assumption. Truth be told, wireframes are not a tool that I find useful.
I don’t do wireframes.
I use thumbnail sketches to work out not only the general arrangement of objects on the screen, but to get a start on the visual design. Working on a wireframe would be a waste of time, as I would only be working on one aspect of the whole. Sketches give me the ability to work on visual hierarchy from an early stage. I find that the visual design informs the interaction design and vice versa. In my process, they can’t be separated.
Creating documentation based on wireframes would be even less useful. My early documentation utilizes the sketches. From there, I move to pixel-perfect mockups in Photoshop, which easily replace the sketches in later versions of the documentation.
I don’t put this forth as a declaration that wireframes are bad and shouldn’t be used. I can appreciate that others find them extremely useful. But for me, wireframes are too low fidelity. Good design is in the details, and you don’t find many details in wireframes.
To be a truly outstanding designer, you must be passionate about your work.
This was the final advice I relayed to my students. It is possible to be talented without passion. You can even be successful without passion. But every designer I’ve considered to be inspiring—and I’m not just referring to design celebrities—has been passionate about their profession.
Certainly, this isn’t unique to design. There are many professions I believe this applies to: teaching, medical and social professions, and political positions, to name a few. That doesn’t make it any less important to design.
It’s a passion for design that drives me to continually strive to increase my knowledge, add to my skill set, improve the quality of my process, and refine my craft. It is passion that finds me spending much of my free time reading other designer’s blogs, industry publications, and the IxDA forum. It is passion that pulls me into volunteering to co-chair the local IxDA chapter, serve on the planning committee for the next conference, or participate in the organization’s initiatives. Passion has landed me in an adjunct faculty position teaching design. Passion often sees me writing for my blog at 1:00 am.
A passionate designer sets his own standard. A passionate designer produces good work, not because she is trying to meet her supervisor’s expectations, nor because she is looking for a bonus or praise, but because it is the way it should be done. When it comes down to soup and nuts, good design is about helping people—improving their experience in some way—and that is a mission worthy of passion.
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.
Very often, upon asking for my input on a function’s UI, a developer will say, “That makes a lot of sense. I never would have thought of doing it that way.” It’s not that I’m smarter, but that my design training has taught me to ask questions and approach the problem from several different angles before settling on a solution.
One of the reasons that UIs designed by developers are typically so poor is that they implement their first idea about a function’s behavior and visual representation. One must realize that the first idea is only the first idea. Sometimes it may end up being the best idea, but more often than not, better solutions exist—they just require some iterative thinking.
Liz Bacon, who is the current vice-president of the IxDA, posted a visual model in response to a heated discussion on the IxDA forum. The model presents all of the various fields that are related to user experience, loosely ordered by product development activities. Color can then be used to indicate where a particular practitioner’s interest and expertise fall.
I really liked the concept, but I left a comment stating that I didn’t feel it solved the problem—that practitioners in many of the fields listed, Interaction Design being one of them, have extremely inconsistent skill sets. Take two people with “Interaction Designer” on their business cards and you may find that one of them creates detailed wireframes as specifications but doesn’t have the skills to do the visual design, while the other creates pixel-perfect screen mockups. Either of them may be able to implement the front-end of the design, or not. So, it seemed to me that it would be more useful to be able to map a designer’s skills to the model at a finer grain.
Liz revised her model and added an additional sundial specifically for Interaction Design. I find this version more compelling, or at least more useful. I think it would be interesting to have a group of interaction designers use the model to map themselves and then compare the results. What would the trends be? Would we find that there are two or three types based on skill coverage? What percentage is necessary to be an effective professional?
An important part of the experience of a studio-based design education is the critique. Students display their work in front of their classmates, and possibly other observers, and must withstand the, hopefully, constructive criticism. It can be devastating to have a project that you spent a lot of time on and thought was decent be ripped to shreds by your professor and peers. It is, however, a necessary experience. One must not only learn to accept it, but embrace it—welcome it, knowing that it will make the end result better. To do this, you have to disown the work, and see it as something other than yours.
Once a designer is out of school and working professionally, criticism will come from many directions: customers, co-workers, users, supervisors, etc. Even with my studio background and all my years of experience in the field, I still occasionally find myself becoming defensive about my designs. It is a completely natural reaction, and as such, I should never let my guard down. When I realize that I am taking criticism personally, I find it quite easy to let go, thanks to my training. The hard part is coming to that realization.
