How to Hire a Designer

A few days ago, I read an article with the same title as this post.  Oh, maybe it was How to Hire a User Experience Professional, or Interaction Designer or Information Architect, or whatever. I don’t recall. There isn’t so much difference anyhow.  I do remember it said things like “look at their presentation skills”, “see if their personas are based on research” and something about their wireframes. I tweeted that’s why I wouldn’t hire a designer, which caused some kerfuffle with my followers.  And it’s hard to clarify in 140 characters what teed me off about the original article.

Here’s why I wouldn’t hire someone based on wireframes, Powerpoint and persons:  it’s not because these are necessarily bad (well, except the wireframes, which are so 2001 that they are the mullet of deliverables, and like the mullet I cannot wait until they are finally gone and I’m not asked to stare at them any longer.) I was bummed because these are merely artifacts and not necessarily the  vital critical thinking skills you need to find in a decent designer.

I really don’t care if you never do personas, or if you make them up from a guy you talked to in the grocery story.  I don’t care if you use keynote, Powerpoint or Illustrator. And honestly, I would hire someone if they did wireframes even though I hate the darn things.

So how do I vet designers, if not by their paperwork?

Here’s what I want:

  • Can they communicate with humans?
    I worked with a designer who I called “themute” because when I asked him about any of his thinking, be it color choice or flow logic, he replied with a shrug. Or a shrug and “I can change it.”  He didn’t have a view, and if he did he couldn’t express it.If, in the interview, you feel like you are working too hard to get a conversation going, then imagine if every single day was like working with a sullen teenager.”What did you design today honey?””Nuthin’.”

    Software and web design is as collaborative as theater. That means participants have to communicate with each other.  Lead designers have to do even better; they have to sell the teams’ point of view upwards. Consultants have to do even better still; they have to sell the work the team is going to do and make the clients feel good about the work they’ve done. That may be why the other site mentioned presentation skills. But the heart of collaboration is having a point of view, expressing it, and having a dialog about it. A good designer is able to both defend a design, but also adapt to ideas other than his own. And talk it all through.

  • Can they produce good design?
    Now, you may say, how do I judge that? I’m not a designer. But I say, if you are hiring, you are a fine judge. You will have to live with what gets produced. So get them to walk you through their work. They can have a fancy portfolio, or they can just pull up the website and point out what they did. Doesn’t matter. I personally prefer to see the website. Artifacts mean little if the end result is crap; and it leads to interesting questions that may reveal if the designer has no grasp of technology and business needs.Some things to look for? See if the design is easy to figure out. See if the primary call to action pops off the page (If you dont’ know, the primary call to action– CTA– is the most important thing for the user to do if the company is ever going to make money, e.g. a “buy” button if the website is selling something, a sign-up button for e-commerce, etc).I like to squint a little at the page, making everything fuzzy, to see if that call to action is still flying at me in 3-D. See if the ads (if ads there be) are integrated into the design or tacked on after like a wart on a nose. In other words, look to see if the design is doing the job you need it to do.  If it’s also beautiful your hit the jackpot. But consider if you are hiring a designer to make you a website in this day and age, you are hiring them to help you make an effective website, not a website that wins a place in MOMA’s new digital collection. If you have to pick between gorgeous and effective, don’t let a pretty interface turn your head.  Which leads us to the last point…
  • Do they get what you are trying to do?
    In this age, pretty much every designer belongs to the cult of user-centered design. That is great. If a designer doesn’t understand the end-user, he can’t make a functional design. But some have gone so far in this direction they seem to have forgotten not all websites are nonprofits.  If a designer does not understand that ads/upsells/subscriptions etc are your meat and potatoes, you are dooming yourself to long days of big fights in which you’ll probably end up compromising more than you’d like out of sheer exhaustion.Make sure the designer you hire uses his/her power of understanding the user to make happy profitable customers. So when you interview that designer, yes, research is good, personas are super, contextual inquiry is great; but the tools are less important than discovering if they can they take A (business needs)  plus B (user desire) and C (engineering can do this) to design a viable product? You need to discover if the designer is capable of executing that simple bit of algebra… better yet, gives an example where they did it in a past job… before you let them in the door.

I’m sure there is more stuff I do when I hire, much of it now unconscious. I might look at their shoes or glasses to see if they are jobsian or gatesian, or ask them what the biggest work-related fight was and how they resolved it, or see if they are posting inappropriate  commentary on past jobs on social networks. There are specifics I like to see in specialties, like interaction designers need to have thought through and communicated flow via use cases or diagrams, or graphic designers must have explored a variety of design direction including the font and palette.

Design folks get so caught up in the niceties of their profession, and fighting about one technique over another, they sometimes forget that the person hiring, client or product manager, not only doesn’t necessarily care about contextual inquiry vs site visits… and they may not want to. Even when you get a hiring manager who is enjoying discussing how much research to do before the personas are trustworthy, it’s not an abstract question to them. They care that they understand the user enough to avoid bombing in the marketplace. I think that’s what really annoyed me about the original article. It was, like so many of my peers, so caught up in the mechanics of the work that it forgot the purpose of it.

Great design is like enlightenment. There are as many paths to it as there are people seeking it. Unlike enlightenment, it’s the destination, not the journey that counts.  Design must deliver business results or fuck it.

When hiring all that really matters are the big questions: can you work with them, can they do their job and can they help you succeed? Same questions you ask everyone who you are about to pay vast amounts of money, be it engineer or accountant.  A bunch of jargon and pre-production deliverables can be a distraction, and one you can’t afford when Google (or Facebook, or Microsoft)  is breathing down your neck.

7 Comments

Add Yours
  1. 1
    Brett Lutchman

    Christina, another excellent article like usual.
    I am on board for the points that you stated here in this post. I know exactly what article you are speaking about with the same title.
    If I can be a mediator here, I believe that your first point “Can they communicate with humans” is the foundational platform that unlocks much, much more beneficial character traits that can be leveraged by the hiring manager.
    My success is primarily due to communicating with people through empathy, sympathy and reflective listening skills. Communication is the zenith of human qualities which enables people to open up to each other and express more information to others because of this trust.
    In defence of the original author, I still do believe that presentation skills is a huge must, but like you said, this skill is an indirect fruit of communication.

  2. 2
    Sean Duhame

    “Wireframes are so 2001.” Since when is design process a function of fashion? If applied correctly to the design process – wireframes can be amazingly effective. They’re broad strokes that allow a lot of quick, continuum exploration and can spark very healthy design discussions. Because they’re broad strokes they often make finding the right constraints in good layout organization much easier. Lot’s of other good reasons for wireframes but I’ll end there.

    Personality differences happen all over the place – sales, dev, design, management. Thoughtless, “sullen teenager(s)” don’t only apply to designers. Also, “if you are hiring, you are a fine judge (of good design)” is silly. Being an employee in the position to hire doesn’t automatically make you a good judge of design and how well it performs.

    BTW – the reason someone suggested you look at a designers wireframes is because it offers you a glimpse into how these people THINK. If where you end up has everything to do with where you start then wouldn’t you be interested in where the designer starts? What you want to see is all this thinking culminate into finished product that solves the design problem effectively. From this you can see that the work builds off of fundamental purpose, is thorough, complete, and original.

    Great designers explore, push boundaries, collaborate, believe there is no shelf to ‘pull’ from and produce lots of ideas so they can qualify the one that solves the problem the best. You need to be interested in that.

  3. 3
    Aynne

    great post, Christina.
    Personally I like to see what projects interests candidates show that is outside of their daily work.

    Do they also make films? Are they interested in photography? So they have some curiosity or knowledge about a specific industry?

    Client work or work in-house doesn’t always show ones true oeuvre , their individual style or point of view, so it really helps to see work that someone is especially excited and motivated about.

    How they see the world will reflect in the work.

  4. 4
    Dave

    Excellent post.

    I read the tweet and thought: “Well, how DOES she hire? It’s a little flip to just blow off advice meant for a manager looking for guideposts in a discipline she may not understand…”

    Nicely explained – I’ve been waiting, and hoping I’d see.

  5. 5
    admin

    Until I write up my wireeframes screed (which sadly, i see I have never done) enjoy some links of problems and solutions
    ” I knew that designing with wireframes is fraught with problems, from the lack of a standardized notation understood not just by stakeholders but, most critically, by developers, who have to build the darn thing based on them, to the confusing overlap between wireframes and design comps, to the abundance of information not inherently communicated in a wireframe that therefore needs to be explicitly explained in droves of labor-intensive annotations, that inevitably become out of date. And on and on.”
    http://www.andersramsay.com/2008/10/31/new-article-at-boxes-arrows-on-prototyping-with-xhtml
    http://natek.typepad.com/blog/2004/07/web_visions_pre.html

    “How many times have you been asked, “So, is the new website going to be black and white too?” after presenting your wireframes to a client or a usability test subject?”
    http://www.boxesandarrows.com/view/real_wireframes

    “Like many interaction designers, I’m increasingly dissastisfied with the static, page-based tools that are used to create and share wireframes (OmniGraffle or Visio, anyone?) There is simply no way that these applications can communicate the fluidity and richness of interactions that are now possible.”
    http://www.adaptivepath.com/blog/2008/06/02/alexa-conquers-interactive-wireframes-on-boxes-arrows/
    “I’ve realized that it may be impossible to not see the semblance of a design in a wireframe with a lot of detail. A gray bar down the left side may show information grouping to the designer, but is immediately recognized as left navigation to the business owner. Levels of detail intended for audiences of every type are polluting my wireframes, forcing my audience to project their prior knowledge and experience upon them. This, I’ve found, leaves little room for innovation.”
    http://www.boxesandarrows.com/view/the_devils_in_the_wireframes

    “The problem here is that traditional computer wireframing tools, like Visio, OmniGraffle or InDesign, lay out drawings as hard-lined boxes, lines and fonts. As a result, wireframes look the same regardless of which stage of completion the wireframe is representing. Early-stage, conceptual wireframes look identical to late-stage, functional specifications. This differentiation becomes especially murky in the middle of the project, where conceptual and final elements are comingled on the same page.”
    http://www.boxesandarrows.com/view/sketchy-wireframes

  6. 7
    Andy Budd

    While I agree with a lot of what you’ve said, there’s a bit of a passive-aggressive undertone in your post that worries me a little.

    Wireframes are a tool like any other, and therefore have their place. I agree that they’re an overused deliverable in the IA community, and that there are often better ways of communicating behaviour and intent. However under certain circumstances and with certain teams they’re still the best way of sharing this information.

    Furthermore, sketched wireframes are an excellent tool with which to think through problems. So I think to dismiss them out of hand, while obviously the fashionable thing to do at the moment, isn’t particularly helpful.

    As somebody who hires user experience designers, I find it incredible useful to look at their scamps, sketches, wireframes and prototypes as it gives me an insight into the intent of their designs before they have been impacted by external factors. It’s entirely possible that features got dropped, mangled or implemented badly once the project was out of said designers hands. So asking a potential candidate to walk you through the thought process in their wireframes seems like a perfectly valid suggestion to me.

    Looking at the followup comments you’ve posted, it seems that your problem doesn’t lay with the artefact itself. Instead it’s with the tools you use to create them, the point in the process you use them, the level of detail you go into and the way you present them to your clients. Just as a bad workman blames their tools, I’d suggest that the problem isn’t with the wireframes themselves but with the way you use them.

Comments are closed.