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.

Free Advice

Hey, all of you newly graduated designers looking to land a job, here are a few suggestions from someone that is looking to hire.

Proofread your résumé. What’s that? You say you already did? Well, do it again! You missed something. Don’t claim to be “detail oriented” and then tell me that you designed landscapes to meet costumers needs.

Include the URL to your online portfolio on your résumé. I do want to read your résumé, but I’m more interested in seeing your work. No online portfolio? Build one. Not only am I going to take a look at your work examples, I’ll be checking out your HTML and CSS.

Don’t just show me finished artifacts. I’m most interested in your process. I want to know how you approach a problem, generate ideas, and document your work. I don’t expect you to be as good at it or as thorough as I am—not even close—but I do want to see that there is something to build on, rather than starting from scratch.

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!

The Real Challenge

My career as a designer has been all about solving other people’s problems. There’s nothing wrong with that. It’s something I quite enjoy, and I seem to be good at it. At the same time, however, I am more than a problem-solver—I am a creative. I have a desire to invent, to innovate, to create something that didn’t exist before. Sir Jonathan Ive’s comment in an interview with Mark Prigg of the London Evening Standard really resonates with me.

There are different approaches - sometimes things can irritate you so you become aware of a problem, which is a very pragmatic approach and the least challenging.

What is more difficult is when you are intrigued by an opportunity. That, I think, really exercises the skills of a designer. It’s not a problem you’re aware of, nobody has articulated a need. But you start asking questions, what if we do this, combine it with that, would that be useful? This creates opportunities that could replace entire categories of device, rather than tactically responding to an individual problem. That’s the real challenge, and that’s what is exciting.

Treasure the positions and clients that enable you to do such work. They are not as common as they should be.