Building the UX Dreamteam

Part 1

Part one of a two-part article.

Finding the right person to compliment your User Experience team is part art and part luck. Though good interviewing can limit the risk of a bad hire, you need to carefully analyze your current organizational context, before you can know what you need. Herein lies the art. Since you can’t truly know a candidate from an interview, you gamble that their personality and skills are what they seem. Aimed at managers and those involved in the hiring decision process, this article looks at the facets of UX staff and offers ways to identify the skills and influence that will tune your team to deliver winning results.

The Art

There are many pieces to the User Experience puzzle. The art of fitting the roles together to compliment each other and your particular situation requires a bit of luck and intuition. Try as we might, it is nearly impossible to find someone who is highly skilled in all areas, so you will want to find either a "Jack of all trades" or a specialist. First, lets explore some loose definitions of various skills that make up the User Experience Team.

Skills are measurable. Anybody can learn new skills through education or apprenticeship. They are the capital built over the course of a career, making the applicant more saleable. Categories of research, information architecture, interaction design, graphic design and writing help us communicate and understand the part each skill plays in defining user experience. Not to be confused with roles – which define the activities of any member on the team – staff employ skills to do the work.

Let’s look at skills in a sequential order, as they’re typically utilized when practicing User Centered Design. We’ll begin with research.

Research Skills

Research is interwoven into all user experience roles – the inspiration and validation of ideas and designs greatly enhances the chance of success in meeting your design objectives.

This skill, as it relates to UX, is about asking questions and illuminating a subject area in unobvious ways. Knowledge of psychology, sociology and anthropology are used to tease out intelligence from users, market data and academia. In this regard, Interaction Designers and Information Architects must use research skills to inform the strategic aspects of their job. Even a cursory study of a potential product’s competitive landscape requires an essential research component.

The researcher in us takes a scientific approach to the study of humanity and uses quantitative and qualitative studies to inform the design process. Roles on the UX Dreamteam employ techniques such as:

  • Contextual inquiry – field research that involves interviewing users “in context” i.e. as they perform familiar tasks in their normal environment
  • Surveys – one questionnaire answered by many respondents, statistically analyzed for trends direct us toward a user’s requirements
  • Usability testing – key for highlighting UI and system design flaws as well as opportunities
  • Card sorting – used by IAs to test categorization ideas
  • Emotional response testing – great value to graphic designers seeking direction on the impact of their visuals

Research skills punctuate the UX professionals’ work agenda.

Being good at research is key, but disseminating the results for maximum impact to ensure findings are used is equally important. A lack of attention to this can undermine valuable work. Good communicators reap the benefits of clearly, poignantly presenting facts and theories.

A researcher, whether dedicated to this role or filling it temporarily, needs to be pragmatic. Remaining objective – interpreting findings only from collected data – is often a challenge when we are invested in a particular idea or direction. Researchers should be inquisitive and analytical with an empathetic instinct to dig beneath the surface of things.

Screening tips: Look for some evidence that a candidate understands scientific method with regard to research. They should also be able to separate themselves from an emotional attachment to their own ideas. Not to say they should be dispassionate about finding the right answer, but their personal biases should not taint this effort. Probe their ability to analyze data. Test to see if their nature is exploratory (good) or if they are just as happy to make general assumptions (not so much). See how they have creatively engaged the team with research findings by threading them in to the day’s work.

Information Architecture Skills

Information Architecture entails designing an information system and the users’ pathways through it. The IA’s goal is to create a system that will provide useful information to suit the user’s context. System structure, inputs and outputs of information, semantic analysis and accommodating changes in the user’s context are in the information architect’s domain.

Frequently Information Architecture (IA) and Interaction Design (IxD) skills are confused. Job titles of one or the other do not neatly describe the skills at work and it’s common for an “IA” to use IxD skills and visa versa. Jesse James Garrett in his book The Elements of User Experience differentiates IA and IxD by the type of system being designed. He asserts that Information Architecture fits a model of the web as a hypertext system, rather than a software interface. Johnathan Korman from Cooper delves into the distinction in his article The Web, Information Architecture and Interaction Design – “IA means defining information structures to answer the question "how does a user find the information they want?… IxD means defining system behaviors to answer the question "how does a user take the action they want?”…”

IA and IxD roles can work in tandem. The IA defines what data needs to appear and the IxD crafts the UI and user flow. Primarily IxDs in this setup are focused on the nuances of the functionality of the system, and IAs on the data that drives it or is manipulated through it. This is a good strategy for large scale, data-centric projects such as defining a content management system. For smaller projects, one person may perform both roles more efficiently. What type of systems does your team work on? How much of your work is about “content” and searching and how much is about software UI?

IA activities fall into two categories. Big IA includes creating ontology, categorization and metadata design. Little IA is labeling, auditing content, creating sitemaps and wireframes. Do you know which of these you really need?

Richard Saul Wurman – an architect and graphic designer – coined the term “Information Architecture” about 30 years ago. He laid out the domain of what’s now more commonly thought of as broadly “information design” with an emphasis on systemic design. The practice of IA we see today was matured by those in the field of information and library sciences, such as Peter Morville. An IA is an analytical, left-brained beast with a detailed eye for modeling content, metadata and information retrieval systems. They are tireless completers, auditing seemingly endless quantities of information, carefully filtering it and finding the patterns within.

Screening tips: Look for patience, attention to detail and a comfort with language, particularly vocabulary, synonyms and definitions. Pattern analysis and capacity for cataloging and organizing information such as content types, article topics, genres, authors, dates, etc, is essential. Conclusions should not all be derived from their own organizational prowess ­– are they inclined to gain inspiration or test ideas with users? The difference between administrative, intrinsic and descriptive metadata should not be foreign, after all, they revel in semantics!

Interaction Design Skills

The Interaction Designer is a story-weaver – scripting the narrative between man and machine – the dialogue of system response to user action. Goals, behavior and flow are significant strategic concerns, but this skill goes beyond making interfaces relevant and usable. IxD marries personality with each interaction story, creating a system with which users make an emotional connection. Interaction Design and Visual Communication work together to breathe life into software UI. IxD defines the way the user manipulates the interface and Visual Communication determines how that looks in concert with all the other visual elements on screen. Blending analysis and creativity – working between artistry and engineering – Interaction Design concepts muster team consensus around what to build via the user interface layer.

Scenarios, flow diagrams, interaction models, prototypes and wireframes are typical deliverables of interaction design. They capture the desired user experience that is translated into a functional specification.

Because interaction design is primarily about creating intuitive interfaces, a measure of empathy produces the best results. This skill is not a precise science, so humility and resilience in the face of criticism (or sometimes failure) is also good.

Screening tips: Look for an interest in and aptitude for psychology; passion for making things work intuitively; enthusiasm for the difference between good and great interactions. Do they understand how to brand an interaction? Good IxDs make stories; can they hold your interest? The world is full of interaction – they should draw their inspiration widely. They must be comfortable with research and usability concepts too.

Graphic Design Skills

Graphic design (also known as Visual Communication, Information Design or Visual Design) is primarily concerned with clearly communicating the aesthetic, personality and function of a system and to invoke feeling. Strategically, an understanding of branding on a level deeper than visual identity, delving into messaging, semiotics and interaction is important. It is here that they work closely with writers and Interaction Designers on software or with an IA on hypertext systems. Tactically, Visual Communicators ensure that the UI layer is lucid, communicates visual hierarchy and represents the brand in ways that appeal to the end user. Inherently creative, Visual Communicators demonstrate a passion for the marriage of beauty and function.

In collaboration with other disciplines, graphic designers translate concepts visually to persuade stakeholders. They produce ‘comps’ (short for composite or comprehensive) of the UI, advertisements, illustrations and corporate identity treatments. Some companies like to have their graphic designers produce CSS, thereby ensuring that every detail is captured in the finished product. When a graphic designer must compromise their design for technical reasons, an acceptable solution is arrived at more quickly with no friction between development and design. It’s helpful if your graphic desinger can converse in the terms of your technology.

The wider field of graphic design has its share of passionate folk. However, most that have moved to the technology sector have since matured of “artist’s ego”. A lot of compromise typically comes with crafting the surface layer of technology so only those who are flexible survive. Evoking emotional response, passion, flair and patience for refining details are hallmarks of the graphic designer.

Screening tips: Test for an understanding of branding beyond the visual, moving into interaction and messaging. Be sure they embrace usability concepts and processes and are as concerned with user comprehension as beauty. Gather evidence of “willingness to compromise”. Do they value what other UX disciplines bring to the team? Ensure they understand CSS or the constraints of your particular interface technology. How concerned are they with engaging the emotions of the user?

Writing Skills

Good writers can effortlessly guide users through an interface with concise instructional copy. They have the ability to create memorable taglines, deduce complex concepts into layman’s terms and author well-researched and thoughtful articles. Great writers have honed their skills well beyond what we learned in high-school English.

Steve Calde from Cooper says in his article Technical Writing and Interaction Design, writers have a pivotal role to play in the interaction design process: “As the first people actually trying to explain how the product works in users’ terms, technical writers are in a unique position to spot problems.” He is speaking from the technical writing perspective.

When we talk about writing to express a brand, there is a synergy between all disciplines committed to creating a strong voice. A writer’s ability to express the brand through phraseology is key not only for creating associative messages for the customer, but also for driving home a subtle Interaction or Visual Design personality.

Other than manuals or help files, instructions, labels, advertising headlines and copy, a deliverable missing from many UX teams is a style guide that details how concepts are to be expressed. Do you currently have a clearly articulated and documented voice and style?

Writing requires patience. Language allows us to express ourselves in many different ways and it can be a contentious area for stakeholders concerned with the message sent to readers. Therefore, subjective rework can happen, especially with highly visible projects. Empathetic people make good technical writers since they can quickly learn to speak the language of an audience who needs them to be clear. Equally, those exhibiting flair and wit often craft great marketing material.

Screening Tips: Are they comfortable with language? Can they demonstrate a command of the language to explain or sell ideas. Can they demonstrate how you create a ‘Brand Voice’ and keep it consistent?

While skills are important, less tangible qualities are arguably more so. With time skills are developed, but people who are creative or analytical, strategic or tactical, directive or hands-on are like this by nature. It behooves the hiring manager to identify which of these qualities are needed. In the next part of this article, we will look at some of the less tangible qualities of UX Dreamteam members and organizational contexts that determine which skills you really need.

Posted in Methods, Professionalism, Workplace and Career | 34 Comments »

34 Comments

  • Holger Maassen

    November 28, 2007 at 8:56 am

    Excellent article and a interesting approach – Anthony.
    I am working on a related story – UXdesign + planning is not a one-man-show – http://www.boxesandarrows.com/idea/view/13449

    I’m curious about your next part / step.

  • Todd Walker

    November 28, 2007 at 4:01 pm

    Something that seems glaringly missing is any sort of coding or programming skills, for prototyping (barely mentioned under interaction design). I think it’s more and more important that ID folks be able to actually build and tinker to quickly iterate through ideas and see if they are workable. I’d say that’s a more important skill than Graphic Design, though I’d always want that too.

  • Christian Bogner

    November 28, 2007 at 4:28 pm

    I think, you mentioned some important skills which are indeed necessary to build interactive systems. Hiwever, in my opinion, social and communicative skills might even be more crucial than any of these rather “hard” skills when creating systems to fit human needs. Let me explain: what I learned about user centered design was not only that this might be one of the most complex industrial development processes I can imagine but this is also a process that is rich in trade-offs and conflicts, too. Without having members on the team which are capable of dealing with that many different stakeholders, ideas and needs I’m strongly convinced that interaction design will fail.

  • Patrick Lauke

    November 28, 2007 at 4:54 pm

    “Finding the right person to compliment your User Experience team”

    that would be somebody whose job it is to come in each morning to say “hey guys…you’re doing a great job.”

    I’m sure you meant “complement”…

  • Anthony Colfelt

    November 29, 2007 at 2:01 am

    Todd > I don’t know how common it is to expect interaction designers to code. As a general rule, I think they don’t at the moment. Perhaps the industry will trend that way, but I don’t know. I’m trying to write for the now, however.
    Christian > Stay tuned for part II. That’s when we talk about personality traits…
    Patrick > Thanks for catching that… oops!
    Alexander > This isn’t supposed to suggest you find one person that can do all these things, but rather that these are the skills that are out there. When hiring, you need to analyse what you need before choosing a candidate with some or one of these. The next part will clarify this point.

  • David Royer

    November 29, 2007 at 4:24 am

    Interesting post, I am looking forward to the second part.

    I think one of those less tangible qualities that is very important is a designers ability to reflect. Reflective designers are always improving and learning from previous projects and experiences. I think this is as valuable as any skill listed in this article.

  • Aynne Valencia

    November 29, 2007 at 6:56 pm

    Great post!
    I think this also provides a good overview of our job description.
    I would also say that business acumen and strategic thinking is also critical.

  • Anthony Colfelt

    November 30, 2007 at 1:48 am

    Thanks for the feedback and thoughts. The second part is still not fully baked yet, so I’ll encorporate these notions.

  • Terry Bleizeffer

    November 30, 2007 at 11:48 am

    Thanks for the article, Anthony. As I am in the process of bringing in several new folks to my team, it is a very timely topic.

    A couple comments about roles where I seem to draw boundaries in different places than you have. First, I think it’s useful to separate out “usability testing” from “user research”. If we step back far enough and squint, we can say, “They both involve collecting data from users,” but in practice the differences are more interesting than the similarities. User research tends to be done in advance of the release process, or as input into the release process, while testing is done after design (hopefully in an iterative fashion, of course). In other words, user research produces collateral to enable good design decisions, testing validates whether good design decisions were made. In many projects, user research on the next release is being done at the same that testing is being done on the current release, so having one person responsible for both is problematic. Second, user researchers tend to be more experienced in the domain, because it takes quite a bit of experience to understand where the gaps exist, while testing is done with the assumption that the gaps have already been identified. In other words, it’s always harder to find something that’s missing completely than it is to find something that exists but is broken. And third, in my experience the deliverables coming out of user research activities (personas, task analyses, conceptual design) are both different and more difficult to do well than the deliverables coming out of testing activities (reports, defects). Bluntly, I consider a good user researcher far too valuable to spend their time performing testing.

    I also think there’s a useful distinction between graphic designers and visual designers. Graphic designer create the building blocks, visual designers put them together. I’ve worked with brilliant graphic designers that seemed to have a preternatural gift for turning a vaguely-defined object into an icon that was both attractive and informative… but had absolutely no skills whatsoever in, say, properly laying out a panel. The opposite is true as well – folks with a deep understanding of white space and grid layouts and visual primacy, but no particular skills in “pure” graphic design (which I loosely define as the art of creating an image). If I need a visual designer and I hire a graphic designer, I may end up disappointed.

  • Terry Bleizeffer

    November 30, 2007 at 12:00 pm

    @ Todd: Are you talking about coding skills that allow a designer to code a prototype, or coding skills that allow a designer to code in the same technology as the product, so that the code can actually be shipped as part of the product?

    If you mean the former, I agree with you that this is something else to look for when evaluating candidates. So under Anthony’s “Screening tips” section, I’d want to look for prototyping skills in Visual Basic, HTML/CSS/JavaScript, Flex, Flash, Powerpoint, etc. Heck, I’d want to see real example of prototypes that they’ve created.

    If you mean the latter, I agree with Anthony that that’s the exception to the rule and probably wouldn’t be useful in making a hiring decision, because it’s so rare and in many shops it might even be inappropriate. However, I will add that I think this IS a skill that designers should learn. True GUI development is really difficult and I would expect designers to be able to code all the externals from soup to nuts… but a designer that can produce solid, ship-quality code for the final on-the-glass pieces is valuable indeed, and in many cases that technology is not that difficult to learn… no more difficult than it is to become a Powerpoint guru.

  • Terry Bleizeffer

    November 30, 2007 at 12:28 pm

    At the risk of over-commenting, there’s another area where I’m struggling, and that’s the distinction between “architecture” and “design”. You touch on this in the section about “Information Architecture” and “Interaction Design” but I’m still not comfortable with it. Maybe I’m just dissatisfied with the term “Information Architect” (I can hear the cries of “blasphemer!” already), but I think there’s a “UX Architect” role that’s also important that doesn’t exist in your list. Maybe Information Architecture is a subset of UX Architecture or maybe it’s something different – I haven’t gotten my head around it yet.

    Anecdote: I was talking to an Agile Development evangelist recently who was saying that design is done during Agile milestones in an iterative fashion. I asked, “Okay, but what about architecture? Are you distinguishing between architecture and design, and if so, when is architecture done?” He replied, “Oh, the architecture should all be done before the first milestone even begins.” I said, “Great. Can you tell me how you know when you’ve stopped doing architecture and you’ve started doing design?” And he replied, “Um… no.”

    So I’m not alone in my confusion, which is comforting. Maybe an example would help clarify. I would expect a UX architect to be involved in a decision regarding what technology should be used to implement a user interface. Thick or thin client? HTML/CSS or AJAX? Flex or WebForms? Obviously this decision can have a profound impact on the user experience, but I would neither call it design nor information architecture. And skills and experience in these types of decisions can be critical to a hiring decision… whatever the role is called.

  • Jamie Owen

    November 30, 2007 at 4:05 pm

    What happens when someone in Terry’s position (as team leader) has members of different cultures on his team? How does one mediate the cultural influence on an individual’s contribution to the team? Do the differing values held by a multicultural team mean that there will by more internal conflicts to sort out? For example, does a team member of one culture dismiss the contributions of another (for whatever reason)? Or given the results of user research on a population whose culture is different from that of the design and development team, how does the design impact a business goal aimed at this audience?

    Rhetorical questions, yeah–and I don’t have the answers. But I think they bring up realistic issues as technology shrinks the globe.

  • Richard Dalton

    November 30, 2007 at 9:39 pm

    I think “personality traits” or more general “competencies” are actually more interesting and important in hiring full-time staff, I would have led with that for part one!

  • Christina Wodtke

    December 7, 2007 at 7:02 pm

    A story: when I was hired at Yahoo, I was hired to be the first member of would be a team of probably 5ish UE’s. I was asked who the next hire should be, considering the third hire wouldn’t happen for at least a couple months. Despite my lack of visual design chops (much less html) I decided to try to use my weak skill set and my strong ability to cajole help out of others to ask that the next hire be a user researcher. I have never regretted that decision, even when I was up at 2 a.m. desperately trying to figure out how to make an icon in photoshop. The research brought insights into the user behavior that made all design choices easy and often obvious.

    Next, we hired a visual designer, a web developer and an ID, and grow out from there. The Yahoo UE teams at that time were made up of Design manger, user researcher, IxD, Visual Designer and Web Developer. You might grow to having two VizD’s, two Web devs, etc, but the core team had the makeup of what was believed at the time to be the ultimate shape of a team. I say at the time, because I understand now the researcher is part of a larger organization that includes market research, and the Web Developer has been absorbed into engineering. I personally think the original configuration was the best for getting great designs. But I wouldn’t be surprised to hear the change had some good results too.

    I think the mental model of a team, if you take out the titles, should be:
    * Conductor/leader
    * Finder-outer of user needs and behavior
    * Structural designer (IA, IxD)
    * Interface and visual designer
    * Realizer in the native web format (web dev.)

    That means if you were in a small company, you could hire one person with two or three of these skills, and your next hire could fill in the next skills, without getting caught up in titles. Sadly, in big companies there is a urge to standardization that often makes this approach impossible.

  • Livia Labate

    December 18, 2007 at 1:12 am

    Relevant to the topic at hand: http://www.uie.com/articles/assessing_ux_teams/

  • lara s

    December 20, 2007 at 1:35 pm

    This has been very interesting and helpful, especially for someone who’s very new to the area ( i.e. ME!)

    :-)

  • David Shen

    January 3, 2008 at 5:52 am

    One thing I’ve found at Yahoo! and in the startups I’ve worked for is a lack of understanding that all the disciplines described above are all individual career paths with great depth. It is near impossible to find and hire people with great talent and experience in two, let alone three of those disciplines. Companies and teams looking for UX support need to realize that they really need at least 3 people to round out a UX team: Interaction Designer, Visual Designer, and User Researcher. The unfortunate fact is that most people don’t understand that when they ask for a “designer” they think they can easily satisfy that with one person. Educating the hiring companies of this fact is crucial so that their expectations are set correctly on who they are looking for. They can go looking for that one person, but they need to realize that it could take a really long time to find someone who can perform the duties of two or more of those disciplines.

  • Adam Polansky

    January 3, 2008 at 7:27 pm

    This serves as a nice overview. Much my last year was devoted to building out our team (as you know ;)).

    We looked back at some of our past hiring successes and failures and we realized two things: 1.) Like the circumstances Christina described, we were in a position where being a jack-of-all-trades was not necessary. We didn’t need everyone to be a “does-it-all-heavy-lifter”. 2.) What we did need was for everyone to have what we called the combination of proficiency and presence. Proficiency, I think, breaks down into the distinctions you provide here while presence is probably what you’ll cover in Part II.

    Having difficulty finding the tried and experienced IAs (at least those we could afford), we also mined sources for people who were, as Sonya Smith-Wong used to say; “newly self-aware” IAs. These are people who have the intrinsics of presence but not necessarly all of the hard skills – you can learn Visio but do you “think” like an IA?

    Looking forward to the next installment.

  • Jason Norberg

    January 14, 2008 at 10:15 pm

    This information is also a great help in explaining the roles and skills of UX members to business partners within a corporation and to show that there is often some overlap. In the past my company has had some issues in trying to define the roles and responsibilities. Looking forward to part 2.

  • Afshan Kirmani

    January 16, 2008 at 5:03 am

    As this industry of user experience is yet evolving, job responsibilities overlap as the demand for a specific need from clients is not yet optimized. The hiring trend really depends on the demand for user experience internally within the company.

    I’m quite sure that somewhere down the line, people will begin to specialize in certain areas of user experience as described in your article.

    But right now, as practiced, you surely have proposed a dream team, Anthony. :)

  • laurie kalmanson

    January 17, 2008 at 11:12 pm

    good comments and wise perspectives. my short answer: it depends

    i’ve been lucky to work with designers and developers who get ia/ux deeply and we can whiteboard and sketch and brainstorm together as a team during the initial requirements phase, and it’s a great pleasure when it happens that way. i remember one agile evangelist in particular who loved his agile stories and loved his agile iterations, but also got that wireframes are more tools for telling stories and help everyone agree on what it is they are agilely pursuing

    i’ve also had projects where i’ve been called on to help the team find its way out of the inevitable blind alleys that get built when executive sponsors hand off some requirements to dev, declare that “it’s all been thought through,” and dev just starts developing.

    and i’ve seen a lot in between, in terms of org structure and the space it allows for ux/ixd/ia upfront and thruout the process

    additional short answer: not every role needs its own person, but a team needs to have people taking care of each role, so everyone can make things make sense and find the sweet spot where business goals come together with what works for users

    and, yes, i am also in favor of apple pie, motherhood, rainbows, cute furry puppies, adorable kittehs, etc

  • Anthony Colfelt

    January 20, 2008 at 11:53 am

    I didn’t mean to make an impression that you need someone dedicated to each skill, but rather that you should aim to have the skills you need covered by the various staff you hire. These definitions are a means to divide the things we do into buckets, not to state the sole domain of any one person. My personal opinion is that you need at least some level of skill in each of these areas to do good design. I like Christina’s role definitions: ” * Conductor/leader * Finder-outer of user needs and behavior * Structural designer (IA, IxD) * Interface and visual designer * Realizer in the native web format (web dev.)”. This presents a nice abstraction from established role and job titles. It encourages us break our thinking out of them and I think that’s healthy. What skills you need has everything to do with your context… and that’s part II. :-)

  • Ariel Jatib

    February 2, 2008 at 3:03 am

    great article .. thank you very much for sharing. I really enjoyed the screening tips at the end of each skill area.

  • Gabe Morris

    March 1, 2008 at 2:25 am

    Anthony,
    I believe there’s a typo in your web address provided on this page: http://www.boxesandarrows.com/person/8678-colfelt

    should be colfelt.com, not cofelt…

  • Anthony Colfelt

    March 2, 2008 at 11:31 pm

    Thanks Gabe, fixed it. :-)

  • Melissa Robison

    March 21, 2008 at 3:37 am

    Anthony,
    Great article and excellent follow-up comments.
    I agree with Jason that the information in this article can help explain the roles and skills of the UX group to internal teams and also to clients.

    I liked Alexender’s comment about a UX candidate needing tons of patience and also a quick mind. I am an account manager at an interactive agency. Patience, agility, and speed are necessary when working in an agency environment or under deadlines. A star candidate would bring relevant skills to the table while being able to build consensus, negotiate deadlines, and also adhere to budget. A tall order!

  • charlene mcbride

    March 29, 2008 at 8:02 am

    Was there ever a part 2 to this article?

  • Chris Baum

    March 29, 2008 at 4:54 pm

    Hi Charlene,

    > Was there ever a part 2 to this article?

    It’s in progress, but not ready for publication yet. Rest assured
    that we’re working on it. Anthony knows that y’all are eager to
    see part 2.

  • Theresa Kraemer

    April 23, 2008 at 6:26 pm

    This information will be very helpful when I decide to move on to my next UI design opportunity. It really helped explain the similarities/differences between the various skill sets needed for a well-rounded UI Engineer, and will assist me in determining what areas I want to explore at my next possible opportunity. I feel I have a more confident answer when someone asks me “What does Interaction Design mean to you?”

  • Jon Kranz

    August 11, 2008 at 6:14 pm

    Very interesting article. I’m glad that I found it (and part 2) today. Can you tell me about how a typical IA/IxD group would be set-up organizationally? To whom does each position report to? I’m in the midst of re-thinking how my team is structured to focus on their strengths more and identify areas that need bolstering with additional staff.

  • Anthony Colfelt

    August 16, 2008 at 1:27 am

    It really depends on the organization and size of team, Jon. I’ve seen the design team as part of the marketing group, a production group, an engineering group and free standing. So where design fits into the organization needs to be negotiated, but you want a boss sympathetic to the cause of user experience design. I have found that marketing or production groups make good bedfellows with design. Free standing also works providing the manager is able to play nicely with the other group managers at his/her level.

    Within a large team, members can report to a head of their discipline, e.g. heads of IA, visual design, research, etc. Smaller teams are often split into IA and visual design, with a team leader of each or all reporting to a head of experience design. If you have dedicated researchers/usability analysts, they can fit comfortably with IA functions managerially.

    Matrix structures involve a manager of each discipline and managers of clustered related projects. So most people then have two managers, one of whom remains constant (discipline manager) and another who may change according to what project they’re working on. The discipline manager then looks after all things career and skills wise, the other manager looks after work being done on the project.

  • Mike Clarke

    March 28, 2011 at 8:24 am

    Really glad to see Emotional Response Testing being mentioned as part of the Research Skills section, it is something that is often overlooked.

    It’s because of this that I created mojoleaf.com which is a free online remote design feedback service that uses the Microsoft Reaction Card to help gauge the emotional response to a design – hopefully some of your readers will find it useful.

  • Alexey Pankov

    July 7, 2011 at 7:36 am

    Very helpful article.
    Anthony, would you mind if I post translation of your article on some Russian IT-community site?

  • Anthony Colfelt

    November 13, 2012 at 6:56 am

    Hi Alexey, as long a you credit the original article here at Boxes and Arrows and link me as the author, I would be pleased for you to translate the article.

Sorry, comments are closed.