The UX Architect Interview

answers you’ll want to know, questions you’ll want to ask

Peter Simon
17 min readJan 31, 2017

I wrote this guide of UX architect interview questions a few years ago. I spent a long while in various positions to make hiring decisions and run candidate interviews, for startups and for large corporations. What follows is a list of questions a candidate could very well be asked, and what some great answers are. In addition, as the candidate should also always be interviewing the company as well, I’ve provided questions the candidate should ask, and what the answers likely mean. The caveat here is that I wrote this all a few years ago and times change. I make no guarantees about the usefulness of the info, but I suspect there’s still some good stuff in there.

-PS

For interviewers and candidates — intro

This is a list of interview questions that might be asked in a User Experience Architect ( UXA ) hiring interview.

Of course, I can’t know the level of UXA being sought or interviewed in your specific case, so I’ve included questions for the top of the bell curve; a junior UXA might not ask or be able to answer all of these, while a principal UXA could ask or answer any of them, and more.

It’s totally fine if both the UXA and interviewer have knowledge of this document. Actually, it might be a better situation if they do. The object isn’t for either the UXAs or the interviewer to catch the other off guard. The answers should be authentic regardless of whether they’re spontaneous or considered. The goal here is for everyone to be able to get a feel for each other and gauge competence, mental agility, and personality fit. Of course, both people in the interview should also be able to ask qualifying questions beyond those listed below, especially if an answer seems incomplete or “canned”.

The interviewer doesn’t want to hire someone who sucks, or who is less competent than the position requires. With the spike lately in demand for UX talent, contractor agencies have been known to send people who are only “UX-ish” and brand them as UXAs. It’d be good to be able to sort these people out in the interview.

For the candidate’s part, sometimes the desire to get the job blinds you to obvious questions you should ask about a place you’ll potentially spend more waking time at than with your family.

I can’t help you much with your instincts.

If a candidate seems like they’re stumbling through most of these questions, there’s probably a reason for that. If an interviewer is likewise stumbling or evasive, that’s probably indicative of a situation a UXA should consider avoiding.

Of course this list is by no means exhaustive, but I do feel it’s useful. I’ve interviewed many UXA candidates in a variety of situations in my roles as senior and principal UXA, and I’ve also gone on more than my own share of interviews where I was looking for that great job.

Some assumptions

· I assume someone will ask all the “usual” tech interview questions, such as: “Tell me about a time where you had to deal with stress” or “could you tell me about a favorite project?” …so I haven’t included these in this list. To get these, read a book.

· The interview itself might not be one-on-one. There may be more than one interviewer, but there really shouldn’t be more than one UXA candidate in the interview. If there is, think about how they can get an idea of how you are as a practitioner. Ask them about this.

· There could be a practical part of the interview, a skills exercise on a fake problem, but this doc doesn’t cover that part of the interview.

· The person interviewing is a UX manager, or has some knowledge/experience with how UXAs fit into the org, and how the org works. These questions aren’t really for the HR person interviewing just to see if a candidate is not crazy, and if they can comport themselves professionally.

· It’s okay to ask different people the same question; you never know what answers you’ll get.

· The UXA has a portfolio, you’ve asked for it, and the UXA is able to walk you through it. This is kind of important, but also something I really haven’t dwelt on here. The portfolio review is a pretty important part of the process.

The answers to the questions that follow are guidelines, for the most part. A lot of my experience with interviews has been in high-end, high-volume-of-work retail, insurance, and agency environments, so this colors my perception. Some of the guiding thoughts I’ve given for “answers” or rationales might not fit your company to a “T”.

Part One — Questions interviewers should ask, and UXAs should know the answers to

What part of the job do you like the most? Why?

( design, collaboration, research, presentation, relationship management, marshaling the design through the process, the visibility you have into what’s happening with the brand, etc. ). This is to get a feel for where the candidate might be best placed, and also perhaps an indication of where not to place him or her.

What part of the job do you care for the least? Why?

Just in case this wasn’t made clear from conversation after the above question. Also, everyone should be able to answer this; it’s not a trap, and everyone honestly has something about the job they do not enjoy. It would be good if the candidate could give clear reasons why they didn’t care for this one thing, and the winning candidate understands there might be an occasional need for the person who’s hired to do this particular task.

What’s a fav well-done website? Why do you think it’s well designed?

“Google” and “Amazon” should be discounted as answers, as these sites might rest at the top of most candidates’ thinking and not demonstrate much effort for the question. By all means call up the website that’s named, and have the candidate show you what they like. Also, the features should be described in much more detail than “They do a really good job of ‘presentation’ on this site…” You’ll know most of the inadequate answers when you hear them.

What’s a website you think is poorly designed? Why?

As above. The candidate who cannot immediately name one site that they feel is poorly designed and speak to the shortcomings is probably not the architect you’re looking for.

Why do you want to change from Viz Design ( or whatever ) to UXA?

This applies if the candidate is making a move from one discipline to another. This is a perfectly legitimate path, and the answer can give valuable insights into the candidate.

You have a client who wants you to design a new site; in general what are the steps you follow to come up with a design?

Here the candidate might speak to a common design strategy, or simply recite the steps they take. It would be good if the candidate didn’t sound like they were making this up as they went along. Things it would be good to hear here include — market and best practice research, consultation with stakeholders, establishing metrics and schedule, design time, collaboration with peers, checkpoints with stakeholders, collaboration with other disciplines, group reviews, and handoffs. Extra points for mentioning iterations and post-mortem reviews.

If a client wants you to modify an existing site, does this method you just spoke to now change?

It would be good here to hear about finding out what the client doesn’t like, examples of sites or solutions they –do- like. It’s hard to fix a problem if you don’t take time to understand what that problem is, and how not to repeat it.

How do you feel about usability testing? Eye tracking? Cognitive walkthroughs?

Good signs are understanding the difference between each of these. Usability testing is taking 4–12 relatively normal people one at a time and running them through a list of relevant tasks on a prototype or the live site, proctoring them and asking questions, observing and recording their answers and actions, gathering all participants’ data and synthesizing some conclusions. Eye-tracking is a specific kind of usability test; it uses one of various methods to mark where a participant’s eye wanders over the page(s) and from this and other participants’ data conclusions can ( maybe ) be drawn. A cognitive walkthrough is less a test with tasks and more a discussion, using comps or wires and walking through a normal person ( not a designer or architect or stakeholder-y person ) through what the page(s) might look like and getting some feedback. Experience with these different assessment methods is good, being able to speak to each of them is a very good sign. Although it’s quite possible that a talented architect has never run their own test or walkthrough, that talented architect should be aware they exist and speak generally about them.

What can you say about prototype fidelity?

Fidelity here refers to how closely the prototype being used, tested, or reviewed looks like an actual done deliverable. A prototype should have a low fidelity early in the design process, where design decisions still need to be made. Low-fidelity prototypes are easy to change and don’t “look” real, so no one mistakes them for real. Stakeholders don’t wind up saying, “Yes, do exactly –that-“ when they see a lowfi prototype. High fidelity is better towards the end, when it’s important to test and give access to the design to people who might not have the skill to look at a wireframe or lowfi prototype and give feedback. A highfi prototype can also be used in a test and the results can be generalized ( if it was a good test ) to the actual thing being built.

If a client absolutely wants something that you know is not in the best interest of the design, the site’s goals, or the user’s experience, what are some strategies you have to reframe?

Almost an infinite amount of answers can turn up, here. Just look for what your org finds acceptable; “They should listen to me because I am an expert” is almost always a poor answer, though. Stay away from someone who claims never to have encountered this situation, or someone who has no idea how to articulate how they’d handle it.

How do you see yourself in the role of a UXA working with Viz Design and Dev? How about with Product Management?

This answer is also given to the taste of your organization, as above maybe stay away from people who have no opinion here, or those who have never worked with any other cross-disciplinary partners.

What percentage of your time spent as a UXA is relationship management?

By relationship management I mean setting expectations, explaining things, gathering requirements, and mostly everything not doing research or the design itself. I like to hear and answer somewhere around 50%; I wouldn’t hire anyone who said less than 20% and seemed serious.

How many projects are typically going at once, for you?

A good answer here will vary along the lines of what you’re looking for. In a modern retail or agency environment a staff-level UXA might have up to 5–7 projects in flight at any moment — 1–2 intensive ones, a few that don’t require quite so much work, and 1–2 that are just tweaks or bigger efforts finishing up. This is a pretty broad guideline, but be wary of the candidate that tells you they’re used to having only 1 project, unless they were specifically contracted for one project.

What’s your idea of a busy day?

This can vary wildly, so here you’re just listening and getting an idea of the person. Stumbling with this question would be good cause to probe a little deeper.

What kind of work-life balance would be ideal for you?

Again, there is really no one correct answer to this question. What does your own company seem to require from its people? Reflect honestly on this, and it’s always a bad idea to bring in someone who’s not a good fit here, regardless of the immediacy of your need for a good new hire. If the answer to this question isn’t a great match-up, there will just be heartache down the road.

Give an example of when one of your design ideas was challenged; what was the idea, how and why was it challenged, how did you counter it?

This is a pretty standard question; look for professionalism here, but also for economy of speech. Does the candidate go into a long recitation here? If so, probe a bit more to get an idea of how the candidate might be under pressure.

Who are your design influences?

While it’s true that some perfectly competent UXAs can’t name anyone in the field who’s influenced their work, it would be odd enough to note. If other answers seem a little shallow or surprising, together these might indicate a lack of depth or experience.

What are some of the latest books/sites you’ve consulted about UX design?

What sources do you follow or use to sharpen your skills? The inability to name books or sites consulted or that are inspirational is a red flag, and speaks to inexperience.

Do you belong to any professional organizations? Why or why not?

This question just gets deeper into the background, motivation, and career-mindedness of the candidate. It’s perfectly fine if a candidate does not belong to any organizations, but if they do ask about what they get out of their participation.

What is a UXA? What are they responsible for?

This might seem like a silly or flyball question, but it’s not. This answer will give you more insight into the attitude the candidate would come into a job with than most other questions. “Someone who does wireframes” or a similar answer without any additional elaboration would be a strong indication of lack of seriousness, or lack of experience.

How do you organize your bookshelves?

Assume you have some, if you don’t in real life. I’ve never met a UXA who couldn’t speak for ten minutes about the art and science of organizing personal books on a shelf. Your mileage may vary, but this might be a good question to learn about how suited to the job a candidate is. It has been my experience that UXAs who seem to be naturals or very competent at the job have animated answers, here.

Part 2 — Questions UXA candidates should ask, that interviewers should know the answers to

How do you see the UXA fitting into the design process?

Is it like this today, or are you working towards it? If different, how so? A solid answer here is imperative, from your point of view as a candidate. You need to know how the company makes use of the skills you bring to the table, and if they’re in a state of transition on this or if the attitude is established.

Specifically, what’s the interplay like between visual designers and UXAs?

Important points to note here are the expectations of collaboration, possible ownership-of-the-design attitudes, and local belief as to the value and use of each skillset. Who has the ball first? Is there a handoff, or is design a joint exercise? This answer can definitely vary group to group within the same organization.

What’s the advancement path for a UXA?

The actual usefulness of this question would seem to depend on your needs as a candidate, but if you’re coming to the interview thinking the job is only a stepping stone and that path doesn’t matter, you should think about how that could change due to factors you can’t even imagine yet. Always assume you’re going to stay with a company long-term at the interview, even though of course you know for a fact you’re not.

What’s the dress code?

It’s at least kind of likely that you showed up in a tie, and the dress code allows jeans. But regardless of the actual details a dress code is a pretty good indicator o the corporate culture. What are you looking for, in a place where you’re going to spend a lot of your time?

To what extent do the UXAs here work in partnership with the product managers to develop requirements? ( Whatever the extent, ) why?

Are you a team player? Not the answer you might give to an interviewer, but the real no-BS answer. Think long and hard about accepting an offer here if the answer you hear for this question is different than the one you’d hoped to hear. Also be conscious that sometimes interviewers will paint ideal pictures of places while the reality is a little rougher. You are also interviewing them, and you should not settle for vague or flighty answers to your own questions.

How big is your UX/design team? What disciplines are involved? How many UXAs are on the team, in total?

Your interviewer should absolutely have solid ideas of the answers here. Be very wary if they do not, unless you know your interviewer is ( just for example ) an HR person, without specific departmental knowledge. Also, the size of the team with respect to the size of the org can be a fairly serious indication of how important that org views your discipline.

What tools/software do you use here to design?

It’d be good to know this in advance, and if you don’t ask about it you’ll come off as either inexperienced or so experienced it doesn’t matter which tools are used. Is this you? Also, be on the lookout for vague answers that might indicate there’s an expectation you should bring your own tools to the job.

Mac or PC? Why?

Maybe no great insight from the answer here, but you might be able to draw some broad conclusions about an org by whether they use Macs or PCs.

What methods do your teams use to design and research?

( wires, utesting, cog walkthroughs, prototypes, market research, primary research, survey research, hybrid research, individual design, peer design, collaborative design ). Lots of detail in this answer is a good thing. The details might vary wildly from place to place, but if your interviewer is able to carry on a full conversation about design methodologies, it’s possible you’re in a good place.

Do you do user testing here? If so, who does that? How is it arranged?

Which kinds of projects typically get testing? How many researchers/testing peeps do you have? What’s something that was just recently tested? How is the ( testing ) lab set up? How do researchers work with UXAs here? As above, a lot of sophistication here is probably a good sign of a place you can grow and learn a lot in. An answer along the lines of “ummmm, we’d really like to get more into the ‘testing’ end of things” is probably an indicator of a place that’s not so sophisticated in it’s understanding of UX. This might not be a bad thing, if you want to be the one to build that capability out.

How do you see the ( UX ) department evolving over time?

A key question to getting insight into how the interviewer sees things going, and it’ll also reveal a lot about them as a person as well, in the manner in which they describe The Big Plan.

How does UX work with product management here? With Engineering? With Marketing?

Clear, articulate answers here are essential. If the org isn’t big enough to have a separate product management org, substitute “stakeholders”, “clients”, and the like.

Who “owns” the website? The Mobile version? Tablet?

When I say “owns” I mean who decides what is displayed there, or if something should be taken down. This is just good information to have up front, as an insight into how change actually happens in this environment. It also shows you have more than a passing awareness of the fact the company has a process and it’s important for a UXA to have insight into it.

How do you personally feel about people working remotely? What’s the policy?

What’s the general use and attitude? Remember, you’re asking three things here — how the interviewer feels, what’s the policy, and the general attitude towards it. Any answers you get will be instructive as to the nature of the workplace, though keep in mind not all places that disallow work-at-home are stodgy, and not all that allow and encourage it are cutting edge with an awesome culture.

As a manager, how involved do you usually get in the design process?

Know your design style before you ask this question, and have a feeling for how much involvement you like your manager to have. An incompatibility here could be a big deal.

Are there regular touchpoints with upper UX leadership to verify the work we’re doing? How often?

This is pretty key stuff in most orgs. If the touchpoints are rare this can often give rise to the “swoop and poop” phenomenon, where upper management sees something almost done, swoops in and makes a few or many design decisions, mandating changes late in the process that usually are not convenient at all for anyone’s life or sanity. It’s possible insights give in this way will be valuable, but unlikely. It seems that most management structures that allow or embrace this kind of attitude misunderstand UX to begin with, and are hard pressed to contribute meaningful feedback.

How do you keep in touch with one another around the office?

While working remotely? The answer here just provides more insight, along the lines of the Mac/PC question. It’s better to have a solid answer here than something like “Well, different people use different methods, whatever works”. This kind of answer might imply shoddiness in management.

What’s your onboarding process like? Formal or informal? Materials?

A formal onboarding process is almost always a good thing, and doesn’t have to indicate stodginess; Valve has a remarkable onboarding program. The lack of an onboarding program ( and by “program” I mean a set process, docs to hand you, some kind of reference guide mentioning online and physical assets you can use, a directory of people and services, even some info about the local town and where people go to eat ) is unfortunately more typical, and never an indicator of awesome.

What presentation technologies do your Devs use?

( JSON, HTML 5, etc ) The question signals that you are in fact aware that there different technologies, might also imply that you know the limitations of each of them, and have insights into which experiences you could freely suggest with whatever technologies the devs use.

Is your back-end team, the people who implement the code the front-end devs come up with, located locally, or somewhere else?

Knowing this is crazy-important. Co-location is almost always awesome and leads to less stress. A removed development capability ( that is, the devs are located somewhere else ) can be workable, but is never awesome. It can also be a nightmare, depending on the design process you’re accountable to follow. If you’re responsible for tight delivery, quick turnarounds and few if any iterations, this almost never goes well with offshore dev resources.

How important to your work is technical usability ( adhering to governmental specifications guiding accessibility for people with alternative browsers, etc )?

This is good to know up front; lots of very competent UXAs don’t have a lot of experience in designing for this kind of precision usability situation. If the job is heavy on this, make sure you can play ball or learn –really- fast. If an org has this as a priority they very likely are not going to be very patient while you learn all the ins and outs of the legal and technical specifications.

How does Product Management communicate requirements for projects? Are they written down? Agreed to? Updated in a process? How common is feature or scope creep?

Answers can be all over the map, here. While it is possible that an openly and seriously collaborative place can do great work with little documentation, this almost always requires everyone to be proximate and running like a well-oiled Keebler Tree. If you don’t get that impression, then less documentation is almost always a bad thing. Most org require documentation to facilitate handoff, measure success, and build consensus and buy-in. An org that does not feel like a well-running machine but that also does not have strict documentation standards is likely way-stressful.

Who handles copy? What’s the process for that?

It might be that you will be expected to write copy, if there are no copywriters on staff. Can you write copy? If you say you can because you think it will help you get the gig and you really don’t have skills here, better read up, quick. It’s a whole skillset unto itself, and writing well for the web is different than writing for mobile/tablet. Know what you’re getting into, here.

Can you show me an example of a UXA deliverable or design?

I’m looking to see what level of granularity you specify in the doc, how much annotation/documentation there is. Unless they’ve been up front with you in that you’ll be their first UXA, there’s no reason in the world why you shouldn’t be shown an example of what they feel is a quality deliverable. If they won’t, seriously consider the “why” and if you get a good vibe from the place or the people.

What is a UXA? What are they responsible for?

As with the interviewer question, this might seem a silly thing to ask at first, but the answer can provide a lot of insight into the manager’s or the org’s point of view as to what is really expected from a UXA.

What’s a UXA’s biggest source of stress in the job you’re interviewing me for?

This is sort of a pivot on the classic interview question “what would you say your biggest fault is?” Every work environment has stress. You should slip past easy answers like “deadlines” and “high expectations”; of course the workplace has those as potential sources of stress. You’re looking for insight into the culture, here.

If you find some value in what I do, consider supporting my work by buying me a coffee.

--

--

Peter Simon

Principal UX guy & onebag digital nomad who loves dense problems, dogs, fine scotch, and algebraic semiotics.