Living the Dream

Every interaction designer dreams of having a C-level champion—that person with enough pull to ensure that design is given enough import. I’ve been living that dream for the better part of thirteen years. My champion is now moving on to something new, and that’s a hard reality to come to grips with. I’m going to miss him dearly. On the other hand, I’m not overly concerned. In that amount of time, we have fashioned a culture in which a champion is no longer necessary. Design is just understood to be part of development. Everyone, from sales people to product managers to the developers, understands the benefits that I bring to a project. I don’t need a champion, because everyone has become a champion.

Today, one of the founders of the company touted me as “our Jony Ive”. I know I’m no Jony Ive, but if that is the analogy that readily communicates the value I offer, I’ll take it.

Who Would I Hire?

I’m not hiring. I wish I were, but that’s another post. The discussion I mentioned yesterday got me thinking. If I were hiring, who would I hire, and what would I expect of them?

I’ll break it into two “what if” situations. First, what if I could hire a senior designer?

If I were given the go-ahead by my company to hire a senior designer, I would ideally want someone with a masters degree in Interaction Design or an equivalent discipline, but several years of work experience with quality work products and obvious familiarity with a good design process would be acceptable without the degree.

Ideally, I would want a designer trained in graphic design. It would be difficult to hire a single person without visual design skills, as I wouldn’t necessarily have anyone to collaborate with them on the visual design other than myself, and part of the point of hiring another designer would be to get work done that I don’t have the time for.

Ideally, I would want a designer with basic understanding of HTML and CSS. If they didn’t have this, I would be very clear that their hiring would come with the expectation that they aggressively learn it. I’ve created a tight integration between myself and the developers that I believe is important to extend to any future hires.

What if I could only hire a junior designer?

In that case, I would likely weight my selection heavily towards someone with strong visual design and production skills. Again, willingness to learn both the interaction design process and HTML and CSS production would be necessary. The visual design skills would allow them to immediately take over a lot of my production work, freeing me to design for more projects at once. Over time, I could train them up to become another unicorn like myself.

Okay, since this is all pie in the sky, I’ll throw in a third “what if”. What if I could hire both a senior and junior designer? In that case, I’d want to make sure that the senior designer had strong interaction design skills and process first and foremost. I would again weight the junior designer towards visual design. I would expect both to be willing to learn to code. As the team grows, I would worry less about having all three skill sets in one person, strategizing to balance the skill sets between the team members. What I wouldn’t do is hire a visual designer to just do visual design, an interaction designer to just do interaction design, and a front end developer to just do HTML and CSS.

It all comes back to Jared Spool’s statement:

“Coding and designing are collections of skills. What we’ve learned is teams with a better distribution of skills, not segmented by roles, produce better results.”

Unicorn Quest - Part 3

Josh Seiden’s article, which we worked through yesterday, catalyzed some thoughts for Dave Malouf, currently at Rackspace, who came out guns blazing with a robust, nearly 4,000 word post on his own blog titled Thoughts on code, programming, design, production, development, technology and Oh! Design. There’s a lot of chunky goodness in this stew—much that we agree on and a few opinions that I take issue with. We’re going to savor this one in a few spoonfuls.

Dave kicks things off with this little nugget:

But the question isn’t whether or not designers should know HOW to code, but rather, “Should They Code”. Implicit in this question is that the code they do has a purpose and I think where I disagree most with Josh is the purpose of not the knowledge of technology, but the application of that knowledge to production.

If I read this correctly, Dave is saying that it is important for designers to learn how to code, but they shouldn’t be writing production code. If I were to stop there, well, them’s fightin’ words! But the issue is more complex than that, and Dave does a great job breaking it down.

First, let’s talk about design and designing…
Dave and I are both academics, so one thing we have in common is that we’ve given a lot of thought to “defining the damn thing”, as they say. Dave dances around the definitions here without picking one, and that’s wise, as definition isn’t his point. However, your personal definition(s) of design say quite a lot about your perspective on design issues, such as the relevance of learning to code. So, I will share with you my favorite definition of design to give you some insight to my biases.

Design is the human power to conceive, plan, and realize products that serve human beings in the accomplishment of any individual or collective purpose. - Richard Buchanan

The reason I particularly like this definition is that it includes conception, planning, and realization as equal siblings. The definition doesn’t say that the same person has to do all three to be considered a designer (It’s not the definition of a designer, but the definition of the activity.), nor do I believe that you have to be able to do all three to be a good designer. However, I strongly identify with this tripartite and believe that truly great designers will be capable of doing all three. I strive to be a truly great designer, thus I feel compelled to excel in all three areas. You can agree or disagree with my personal conviction, but now you know where I’m coming from and, rather than taking umbrage at my commentary, can compensate by applying your own lens to my thoughts.

Dave describes five changes that have brought us to the current conditions in which designers are often expected to know how to create production code:

  1. Greater accessibility through tools
  2. Startup culture
  3. Agile/Lean (which is in large part a response to #2)
  4. Maker/DIY culture
  5. Open source

This is very insightful, but I don’t believe it paints the whole picture. I see historical influences at play as well. If you ask an Interaction/UX Designer the history of our field, you will get a different story depending on the background of the person you ask. Dave alludes to this in his earlier listing of focus pairs:

  1. HCI - people & technology
  2. New Media - graphics/interfaces & technology
  3. Information Design/Architecture - graphics/navigation & people

The fact is, Interaction Design grew out of several disciplines at the same time. One of the significant contributors was Graphic/Communication Design, which also happens to be my background. Graphic Design, along with Industrial Design, has a tradition of craft. Graphic Designers don’t just conceive and plan things—they make things. There was no such thing as a Graphic Designer that couldn’t produce their design. Some of the greats were able to produce both 2-D graphic design and 3-D industrial design. To this day, I get dumbfounded reactions from my students when I explain that a large percentage (likely a majority) of Interaction Designers and UX professionals are not visually trained and have to rely on a Graphic Designer to realize their wireframes. I believe that this tradition of craft still has a huge impact on the field, which we see surfacing in “design studio methods”, sketching workshops, discussions of materials and foundations, and yes, the pressure/attraction of learning to code. There is a drive for designers that resonate with this tradition to realize—to produce—what they have conceived and planned.

That is enough for tonight’s post. I’ll continue dissecting Dave’s article tomorrow.

Unicorn Quest - Part 2

Wayne Greenwood’s article, which I picked apart yesterday, prompted a response from his friend and acquaintance of mine, Josh Seiden. In “Designers shouldn’t code” is the wrong answer to the right question, Josh points out that Wayne’s core insight is correct:

If you are paying attention to how a software system will be built, you will be influenced by that need; if you don’t do something to counter that influence, you will end up with software designed around what Alan Cooper calls the “implementation model.” Cooper argues that designers who are doing a good job are making software that is designed around a user’s “mental model.”

Josh believes, however, that the conclusion is wrong, and I’m in full agreement with him. As I stated yesterday, we are smart enough to compensate. We understand the problems that result from focusing on the technology instead of the user, and we’re smart enough to not let that happen.

He also refutes the idea that the design profession could be denigrated by an increase in designer/coders, but what I like most about Josh’s piece is his realization that “having designers in control of the presentation layer results in a presentation that more closely conforms to the designer’s intent.” He says that you get better products when designers produce front end code. This is the primary benefit for designers that learn to code.

All the World’s a Stage

Last week, I had my students reading articles about defining “design”. Some of them were specifically dealing with the struggle of finding a definition (or multiple definitions) for what we do, while others were about what it means to be a designer. We had a good discussion in class last night, but I wish I would have learned of Cameron Norman’s post on his blog Censemaking a few days sooner. It would have been perfect for inclusion.

It’s been suggested that anyone who shapes the world intentionally is a designer, however those who train and practice as professional designers question whether such definition obscures the skill, craft, and ethics that come from formal disciplinary affiliation. Further complicating things is the notion that design thinking can be taught and that the practice of design can be applied far beyond its original traditional bounds. Who is right and what does it mean to define the new designer?

Titled Defining the New Designer, Cameron’s article examines definitions and descriptions of designers and what they do. He ties in discussion of Design Thinking and cites several people that were contributors to the articles I used in class, such as Sir George Cox, John Thackara, and Bruce Nussbaum. I don’t find any conclusive answers, but it raises a lot of interesting questions that are worth thinking about and discussing.

If I could pin down a result from the discussion that occurred in my class, it would be this: The field of Design continues to grow and diversify, and thus settling on any singular definition of Design is fruitless. We must prepare today’s students to think about Design not as a WHAT, but as a HOW. We must position them with the skills necessary to act as facilitators and bridge makers in interdisciplinary teams. We don’t know where they will be applying design thinking/process/methods in the future. As Dan Roam stated in NextD Journal’s special issue Beautiful Diversion, “A whole new breed of designer is waiting in the wings, and we can’t even imagine the tools, the voice, and the stage she will have.”

Adobe Kenobi

I recently upgraded to Adobe Creative Suite 6. I was filling out the registration and encountered the typical Job Type menu. Seeing as how Adobe’s products are intended for creatives, one would expect to find better defined titles than you would in registration forms from other companies. While there are five different designer roles listed, I was disappointed in the selection. How long has it been since Adobe has reviewed this list? It’s outdated. Where is Interaction Designer, Service Designer, Information Designer/Architect, or User Experience Designer? I wouldn’t expect them to include all of those, but one or two would suffice. I was relegated to Web Designer, which leaves me with a bad taste in my mouth.

These aren’t the jobs you’re looking for.

Working with Developers: 12 and counting

One of the great benefits of having worked at the same company for 12 years is that I have developed an outstanding working relationship with the developers. Literally every developer I work with has an appreciation of my role in a project. They understand how my design tasks relate to their development tasks and how the whole process weaves together. They know what questions should be asked of me and which decisions I should be approving, and they actively seek me out of their own volition. More importantly, they recognize that my work makes the output of the team better, thus making us more competitive in the marketplace. Upon attending my talk, Working with Developers for Fun and Profit, a couple of my coworkers expressed dismay that our methods were not commonly practiced throughout the industry.

In a recent discussion, my manager pointed out that once upon a time, if the developers had been instructed to take our customer’s requirements document, develop a solution, and build it, they would have done so. The result would have been similar to any other programmer-designed UI, but they would have done it. If given that charge today, the same developers would likely throw up their hands and say, “Hold on! We can’t do that without Jack (or someone of my talents).” They know that the result would not be on par with our typical work.

I say this not to brag, though I do take pride in it, but to illustrate the value of putting in the time (years, in fact) and effort to learn to communicate, build the relationships, teach the process, and adapt to your development team.

My talk on working with developers was not accepted to Interaction 13, but there will be other opportunities to learn from my experience. Stay tuned. 

Never Enough

Yes, that crazy IxDA LinkedIn thread, Do Designers need to be able to code?, is still running. It took a short breather a few months back, but then somebody resurrected it. Most recently, Jessie Nunez asked, “Will the deep skill set that we took most of our lifetimes to develop, hone, and enhance ever be enough?”

No. No, it will not. You see, Jessie, Interaction Design is very, very young. I was in the third graduating class of the very first Masters of Interaction Design program, and I’m not yet in my forties. At that time, the World Wide Web was brand-spanking-new. There was no such thing as CSS. The Inmates Are Running The Asylum had yet to be published. Yes, we’ve come a long way in a very short amount of time, but to think that the current state of the industry is the be-all and end-all of Interaction Design is foolish.

If we peg my career as an Interaction Designer starting in 1998, the year I graduated with my masters degree, then I’ve been practicing for 14 years. Assuming I live to a ripe old age and continue to work in the field, which I have every intention of doing, and conservatively retire at 65, that gives me 27 years in which to continue to grow in my profession—almost twice the time I’ve spent so far.

Should I rest on my laurels, satisfied that I have mastered my trade? Of course not. I will continue to learn, pushing myself to become a more valuable contributor to my team/employer/customers. I do have a pretty good handle on Interaction Design at this point, and I have a degree in Graphic Design as well. Where do I go from here? I see three primary directions to branch out: business, research, and programming.

By research, I refer to hard-core usability testing, human factors studies, psychology, and anthropology. That’s the area in which I’m least interested. Programming is going to give me the most immediate bang for my buck. The more I can spread my influence across the development of a product, the better the end result is likely to be, and the more satisfied I will be in my work. I’ve already started down this path. Business is a longer term goal, one that I’m slowly absorbing from working with my superiors, as well as reading. Strategically, that is what is likely going to get me ahead on down the road.

In the mean time, everything is going to continue to change at a rapid pace. So, no, it will never be enough. That’s the way I like it.

Designers don’t retire. We die. - Jeffrey Zeldman

Please Pass the Pepper

I love my job. I’ve had the opportunity to design software for explosive ordnance disposal, oil platform and refinery operations, submarine and aircraft carrier maintenance, automobile service, maritime intercept operations, and industrial power system analysis. One of the greatest benefits of being a designer is that every time I start a project with a new customer, I’m learning a new domain. I’m exploring unique problems in fields that I heretofore had little knowledge of, observing people performing interesting tasks, and puzzling over pain points and potential improvements.

Today, I started learning about crime scene investigation. I have a 300 page field guide that I’m digesting while familiarizing myself with a new vocabulary, new tools, new procedures, and new (to me) problems. It’s fantastically interesting, and I can’t wait to begin discussions with the subject matter experts that I’ll be working with.

But, Sunday, I’m flying back up to Groton to train another sub crew, so posts next week will be few, if there are any. They say variety is the spice of life. Interaction Design, then, must be an herb garden. I love my job.

Working with Developers: Designer Wannabe

A few weeks ago, I proffered advice on working with the “old dogs”. Today, I’d like to describe another type of developer I’ve had the pleasure to work with: the Designer Wannabe. Many designers would be annoyed with, or threatened by, a developer that wants to do our job, but I recommend embracing them. Let’s take a look.

Reece Groene
Software Engineer III

  • Loves to do UI work. Where many of his colleagues prefer the back-end stuff, Reece prefers spending his time on the part of the software that people will actually see.
  • Always happy to take a first crack at the UI. He won’t wait for you to deliver sketches.
  • Excited when the designer comes up with improvements.
  • Will work his butt off to implement a difficult UI because he believes in it.

While you may initially feel like Reece is invading your turf, this guy can be your best friend. He understands enough about the user interface to recognize that your designs are better than what he comes up with, and he’s dedicated to getting it working correctly. Here’s my advice for developing a good working relationship with him and using these traits to your advantage.

  • Don’t rain on his parade. Don’t immediately shoot his ideas down every time he does something on his own. Sit down and do a constructive critique. Explain why his decisions are bad ones, and pick out anything that’s worth keeping, or at least considering, for the final design.
  • You may even take him under your wing—start teaching him how you go about designing. There are many good designers that started as coders and few designers that have coding as a strength. You might end up training a new design team member with a very helpful skill set.
  • When you are looking for feedback on your UI designs, run them by Reece. This will help build mutual respect, showing him that you do care about his opinion and recognize his interest and expertise in the user interface. He may even give you some good ideas.
  • Whenever you are unsure about the feasibility of one of your own designs or the capabilities of a particular technology, consult with Reece first. He’ll have a good sense of what your concerns are, what you are trying to accomplish, and for what reasons. He’ll understand the technical problem from your perspective and may be able to offer alternatives that wouldn’t occur to another developer.

In time, Reece may come to see you as a mentor. He will at least respect you as an equal. And with his drive to make the UI the best it can be, he will be a great asset for you.