The Five-Tool Designer
As someone who has managed and worked with designers for most of my adult life, I get a lot of calls from people looking to check references on someone I’ve worked with or find out from me if there are other designers they should be talking to.
When I think about the range of critique I’ve provided in these situations, the term I always use to describe the very best designers I’ve ever worked with is five-tool designer.
Five-tool player is actually a baseball term used to describe someone who can hit for average, hit for power, run the bases, throw, and field. It’s the highest compliment you can pay to a player and is generally reserved for only the most complete athletes, like Ken Griffey Jr. and Willie Mays. In fact, Major League Baseball estimates there are only 8 five-tool players in the game today.
Everyone looks for slightly different things in the designers they hire, but for me, there are five tools that stand above the rest.
Visual Design & Animation
This is probably the most obvious skill laypeople think of when they think of design. Having this skill doesn’t necessarily mean you are a master iconographer or can reproduce the Take On Me video in an afternoon of After Effects, but it does mean when it’s time to slang pixels, you aren’t throwing your arms in the air and saying “I’m just the wireframe person”. You should be able to produce beautiful final assets yourself, in most cases, and only need the help of specialists in special situations (for example, if you were looking for a particular illustrative style for some marketing materials or tutorials).
Interaction Design
If visual & animation skills are mostly about how a product looks and feels, interaction skills are about how a product works. When I tap the search field, do we put recent searches or trending searches in the dropdown? When a new user comes to the service, what’s the strategy for getting users through the onboarding flow? In the past, this skill has been heavily oriented towards wireframing and sitemapping, but it now includes work that is much closer to the finished product. Prototyping, in particular, is a skill that no interaction designer should be without at this point in time. If you can’t prototype by now, you just aren’t trying. This skill is an absolute must, and it’s not difficult to learn anymore.
Getting Things Done
If you work on a team of mine, the best compliment I could ever pay you is telling you that you are where problems go to die. We don’t have a good icon for Home. “I’ll take care of it.” Our CSS styles are getting out of control. “I’ll take care of it.” JimBob is not getting along with KellyAnn. “I’ll take care of it.” There are so many things in product development that conspire to lengthen, weaken, or outright kill what could be great projects, and people are either net negatives or net positives in that equation. The key to being great in this area, however, is not just being a “net positive” but being a consistently reliable positive. The people you can throw any problem at — technical or interpersonal — are always the most valuable people on the team.
Teamwork
Young designers often begin their careers thinking that if they just learn to design the best stuff, the world will beat a path to their door. It makes sense to think this, given how visual a lot of our work is, combined with our ability to display it easily for all the world to see. Pixels, however, don’t get you jobs. People do. You may get that first nibble from your sickass Dribbble shizzle, but once someone starts asking others what you’re like to work with, that’s going to be the difference between “we’ll keep you on file” and an amazing job that could catapult you into a wildly successful career. This doesn’t mean you should be a suck-up or avoid conflict if and when it is necessary. As one of my favorite ex-teammates loves to say, “you have to break some eggs to make an omelet”, but one of the most important skills you need to learn in your career is not just how to be a great designer but how to be a great teammate. In fact, think of the interactions you have with engineers, PMs, researchers and other designers just as you would any other interaction design problem. What is the desired outcome? How do your teammates need to feel in order to help you produce this outcome? What do you need to do to make them feel that way? Hint: it usually does not involve being an asshole.
Leadership
Leadership is probably the most fungible of the five tools, because it can come in so many forms. You might think to yourself, “wait… the best designer I’ve ever met is amazing, but she isn’t really a leader”. What you probably mean by that is maybe she doesn’t have any direct reports, or she is a little quiet in meetings, or she doesn’t put the term “thought leader” in her bio. But you know what she does do? She runs the meetings when the PM is out sick. She pushes the team to explore other solutions when they’ve tunneled in on only one. She pulls the person who got yelled at in the meeting aside and explains why it happened. She mentors the new hire. She is the “heat-sink” when tensions flare. All of these are leadership activities, and not enough people get credit for them publicly because they may not be an official part of the job description or the Silicon Valley archetype of a leader, but believe me, the people on the ground know who leads and who doesn’t.
So there you have it. The five tools.
Notably absent from this list is at least one thing that I know at least one person might take issue with :)
Code!
There are great arguments to be made for why coding should be on this list, and if you forced me to make it a six-tool list, that’s probably the one I would add, but… the only time I would require a designer I hire to have production-level coding skills would be if we didn’t have other people writing production-level code already. In other words, if your eng/product/design team is so small that everyone needed to do a little of everything, then yes. For most situations outside of that though, I think as long as a designer is technical enough to prototype (covered above already) and maybe write a little HTML/CSS/JQuery, the lack of ability to write production level Android/iOS/PHP/SQL/C++/Cobalt/LISP/Fortran isn’t going to hurt much. It may, in fact, detract from their ability to get better at the other parts of design if they spend too much time going down too many rabbit holes.
The general advice I usually give people on the question of code is: learn as much code as will actually make you a better designer. You will probably know if and when to stop.
Before I close, I’d like to mention what may not already be obvious from this article: you don’t need to be a five-tool designer to be great in this industry. There are plenty of four-tool, three-tool, two-tool, and even one-tool designers out there who are amazing at what they do. And I would hire many of them. In baseball terms, Ty Cobb was one of the top 50 baseball players of all-time, but he was only a four-tool player. Couldn’t hit for power… and was also a total asshole, apparently. One-tool players are more rare, of course, but even they can play pivotal roles as pinch-runners in important games.
No matter where you are in your career and your ambitions, it behooves you to think about how others will describe you after you have gone into battle together. Do you want to be the person who “does great work but is difficult to get along with” or the “person who is popular but can’t actually design much themselves” or do you want to be a five-tool designer?
Luckily, it’s all within your control.
Get to work.
Originally published at mikeindustries.com.
