Saturday, July 24, 2010

The Role of a Great Designer (response post)

This post is in response to a post by Hunter Walk, "Get more out of your smartest people by asking them to do less"  Originally written as a comment to the post and cross posted here.

***
Thanks for writing this, it's really interesting and great to see design taking center stage in this discourse. I think it's really important for non-design tech folks to hear from someone such as yourself that there is another work product equally or even more valuable than detailed screen designs and mockups.

Your fundamental hypothesis seems to be two basic positions:

1) A great designer is better, faster, more efficient and more creative than a mediocre one. (This is obvious to everyone, so I won't dwell here, though someday someone should write a post about how damaging a truly bad designer can be.)

2) A great designer can move faster and produce more conceptual mockups and wireframes if the "burden" of creating detailed specs is removed, thus solving larger and more complicated problems at a higher rate. (You'll have to pardon the focus on speed in these first statements, as I feel that most of your post is referring to optimizing great design resources for quantity and speed - if quality is a given, as we assume from point #1.)


First, I'll start with the points that I agree with:

Yes! A great designer can come up with a whiteboard drawing within moments of getting a detailed description of the problem, or in the middle of the night, or during a shower. Once the idea is there, it only takes a few seconds for a truly great designer to draw something reasonable on the whiteboard, outline the flows and use cases to anyone who will listen, and talk through all of the possible technology snafus and edge cases. BAM! Done!

... except it never really works that way. It's nice on paper for people to say that a whiteboard drawing is sufficient, but as a designer who has attempted to send detailed whiteboard drawings to teams and hope that the magic happens, I can tell you that it's not that simple.

The main skill/talent of an (interaction) designer is the relative ease that it takes for them to come up with a drawing on a whiteboard in the abstract and see very clearly how the end product would look on the site. If this work is done for a well-established site with an existing visual styleguide and templating system for page layout, then (in an ideal world) the work should be complete. On paper, any relatively intelligent engineer, product manager, etc with access to a visual styleguide, an existing product or layout templates should be able to pick up a whiteboard drawing or simple wireframe and translate that into a working prototype with little additional design resources. In my experience, this is almost never the case (there was one person I worked with that could do this flawlessly, perhaps I should get him to comment here).

Designers are designers because they can think about interaction patterns, visual style, flow and page layout very abstractly almost as a second nature. If everyone could do that, then you wouldn't need designers! It's easy to forget that the spatial and abstract interaction skills are not easy for others, and it often takes much, much more time from the designer to communicate intent, create more deliverables, and answer questions that (to them looking at the original whiteboard) seem obvious but can become massive roadblocks for an engineer or product person doing the implementation or getting the various necessary approvals.

In short, a great wireframe is almost never enough to get done what needs to get done, not because of the designer, but because of the folks around them.

Some other points from your original post I'd like to respond to:

The flow of ideas is collaborative, not directional
I have to take issue with the implication that the flow of ideas is from product to design. "Product tells design what the task is." But just like any other discipline (eng, product, etc), if someone is truly spectacular, the ideas can come from anywhere and often do come from "the makers." This probably was unintentional in your post, but is often a sore spot for my fellow designers, so I thought I'd bring it up here in the hopes of changing this standard assumption in the future.

Every possible design iteration doesn't need to be explored
In my experience, I often come to a solution that seems reasonable given the various product, legal and technical constraints and it is nearly always the product manager that asks for further and exhaustive iterations of the spec. Nearly every time, we arrive back at the original solution, with sometimes weeks of wasted design time in between. I propose that another way to increase the quantity of output of great designers is to allow them to skip the "comprehensive iteration" phase and go with the good solid solution that comes to them quickly.

Context switching is the enemy of quality
Secondly, if I understand it correctly, your ideal designer would work briefly on all the hardest problems at the highest level, leaving the detail work to more junior designers. This causes a number of problems, not the least of which is the productivity hit from context switching. Just like engineers, designers do their best when they can sit, focus and dedicate hours of brainspace to a single problem and not have to switch contexts dozens of times in a day. Where I work, there are plenty of structures in place to protect engineering staff from these types of context-switches, why shouldn't we protect our most skilled designers in the same way? The more context switching that happens for a designer, the less deeply they can think about any given problem, the sloppier the work becomes. Then you have successfully turned an exceptional designer into a mediocre one by not giving them the time and space they need to actually be exceptional.

The devil's in the details
A trained designer (whether visual or interaction) has spent years in school and countless all-nighters worrying about the perfect kern on a logotype, a torn paper edge, a stray pencil mark and a single unsolved edge case. The foundation of our entire discipline was built on the most minute details that no one even consciously notices. I once watched a design professor rip a student's work off the wall and tear it into pieces in front of everyone because the corner of the paper had a drop of coffee on it. If the high-level conceptual work is the only thing that is completed by a trained designer, then detail suffers and the product could end up looking sloppy and amateurish. A junior designer likely hasn't had enough experience or training to look after all the small details that matter, and this is something you'd lose by redirecting high-level designers to only conceptual work.

Anything that users can see is the responsibility of the designer 
Once the product goes live, if the designer has been shepherding their vision *only* at the conceptual level, then the details become secondary and the product may look or act sloppy. It's all fine and good if the designer internally is given only responsibility over the conceptual work, but once launched, it's entirely the responsibility of the designer. The designer is responsible for the end-to-end protection of the vision, and if they are never working on details, they will get raked as soon as the thing goes live. This pressure is not only from external criticism, but a good designer is her own harshest critic. If something they are responsible for is not of the highest quality, they have no one to blame but themselves.

Strong team relationships accelerate design innovation
Last point: when a designer has been greenlighted to move from team to team working only on the highest level problems and then moving on, they can't form meaningful relationships with the rest of the implementation team (see also "context switching" above). A solid relationship with the product manager and engineers working on the thing being designed is one of the most important components of getting amazing design done (I am, of course, excluding consulting design shops who don't do their own implementation). If a team is all together, working through all the nasty bits, the details and the edge cases, and a designer comes along and throws something over the wall, the team is less trusting and less open to big ideas and innovations from someone not going through all the drudgery with them. This happens time and again. The best and most innovative design I have ever done is on teams where I've also done the most tedious and mind numbing design work you could fathom, just because it needed to get done. Trust is built this way. Big ideas can be acted on more quickly with higher quality by the entire team, with *enthusiasm* if those relationships are strong.


In the end, my advice is this: If you've identified someone exceptional, just have a conversation *with* them outlining your perspective all of the projects and ideas that would benefit from their expertise, explain why you think they are important to the company or to users, and then let them decide where and how to focus their time and what fidelity their deliverables should be.

**Disclaimer: I'm currently a Senior User Experience Designer working at YouTube**

4 comments:

Hunter said...

thanks for taking the time to respond at such length. One thing i wanted to emphasize - i didn't mean for my post to suggest a rigid workflow (product specs --> UX mocks --> eng codes) since i'm not a believer in linear silo'ed roles.

If i could summarize my intent in a single sentence it would be: smart people have massively good intuition/learned knowledge and many teams should seek to maximize the ability for those folks to input into as many parts of the project as possible.

Your question of whether context switching ends up in loss of productivity or negates the intellectual leverage of a smart person, is a really good one. I bet this differs individual by individual. Also there are probably some best practices you'd want to employ in the way information is presented to the individual, the way they sequence their time or the problems (group similar issues togethers?), etc.

Kevin said...

Thanks so much to you and Hunter for this wonderful dialogue! I've reflected upon what you've both said in my own post at: http://kflores.com/a-conversation-about-great-designers

Arno said...

What it comes down do is that people should do what they do best. Coders code designers design and if they can accept each others strengths and weaknesses they will be able to work together as an experts strike team and make development fast and high quality.

"I can do all" mentality and ego's can be dramatic for the overall result and work pleasure and fun.

Orlando JunkCar said...

Thanks for this post, I have been having some issues with my junk car removal website and I have a few more to work on after. Pay cash for junk cars in Orlando.