The Five Competencies of User Experience Design

November 5, 2007

Throughout my career as a user experience designer, I have continually asked myself three questions:

What should my deliverables be?
Will my deliverables provide clarity to me and their audience?
Where do my deliverables and other efforts fit within the spectrum of UX design?

I have found that, if I do not answer these questions prior to creating a deliverable, my churn rate increases and deadlines slip.

When attempting to answer the third question, I use a framework I discovered early in my career: The Five Competencies of User Experience Design.PDF This framework comprises the competencies a UX professional or team requires. The following sections describe these five competencies, outline some questions each competency must answer, and show the groundwork and deliverables for which each competency is responsible.

Champion Advertisement

Information Architecture

Information Architecture When wearing the information architect hat, your job is designing a user interface (UI) structure that satisfies the corporate business strategy, product strategy, and user experience strategy and accommodates all use cases and product requirements. Information architecture addresses questions such as:

What are users’ primary goals, and how can they achieve them using the application?
How do users get from place to place?
What rules exist that users have to work around?
How are product features and components branded?
What is the optimal scope of the application’s feature set?
How do the UI roadmap and product roadmap position the application in its vertical market?
How should I enable users to create and store multiple objects?
What is the application’s search mechanism?

Through laying the groundwork and producing the deliverables shown in the sidebar, information architecture provides the foundation for the other competencies.

Interaction Design

With increasing pressure to create rich user experiences, the interaction designer bears the greatest load and is responsible for conceptual design, which requires exposure to the latest UI patterns and components. In laying the groundwork for and producing the deliverables listed in the sidebar, the interaction designer dives deepest into the minutia of page elements, presentation, and page flow.

Questions the interaction designer must address include:

What layout pattern would work best?
Which features and information are of higher importance, and how do I draw users’ attention to them?
How should I incorporate the user feedback I am getting from user research, user surveys, and formative and summative usability testing?
What behaviors occur on dragging and dropping, on mouse over, and so on?
How can I communicate the strengths of a feature or application?
How can I satisfy users’ primary needs and support the tasks that let them achieve their goals?
How can I draw on users’ intuition to get them to the next step?
How can I ensure users are aware they’re performing a subtask that’s part of a greater task they’ve started?
How can I use the UI components that are available to me—such as grids, tabs, and panels?
How can I maintain consistency throughout the application?

The emergence of rich application experiences has increased the workload for interaction designers. What, in a traditional Web design process, we once specified as page-by-page state changes, we now achieve through a UI-component-by-UI component, multi-state specification often expressed as a matrix. At present, no single methodology that efficiently enables the documenting of rich application designs has emerged as the standard in the UX design community.

On the plus side, the focus of specifications has shifted. Remember when interaction designers had to specify a UI component, then give the specification to the engineers to go build it? Now designers can just pick a pre-built component that the engineers can configure.

Usability Engineering

Usability Engineering At my company, I am the sole user experience designer, and I have observed that, when shifting into usability engineering, it is beneficial to completely remove myself from the other four competencies, for three reasons:

Doing so immediately places me in the mindset of the user.
It favorably affects my ability to maintain neutrality when conducting usability tests.
It gives me perspective on design churn.

Shifting into a user mindset helps me both when laying the groundwork for usability testing and when creating the pre-test and post-test deliverables shown in the sidebar. It is essential when conducting usability test sessions, evaluating the findings of a usability test, and making design recommendations.

I’ve also observed that the moment my usability engineering hat comes off, I dive right into another design iteration, fueled by the abundance of newly gathered knowledge about usage patterns.

Visual Design

Visual design communicates your brand. That’s why everyone has an opinion about it. But it also communicates interactivity, information structures, workflows, and relationships between the elements and components on a screen, making it an essential aspect of UX design for applications—whether for the desktop, the Web, or mobile devices.

What people often overlook is that, for every type of user interface element the interaction designer specifies, the visual designer must design a widget or devise a corresponding style. And the visual designer must consistently apply these styles to every instance of each element throughout the application.

However, in this era of rich application frameworks, if the interaction designer has selected page elements from a reasonably stylish UI component library, the visual designer can concentrate more on branding and navigation.

Prototype Engineering

Prototype Engineering Prior to the advent of rich user experiences, it was unusual for an engineer—a coder—to be part of a UX team. In fact, product development and product management might have resisted an engineer’s working on the UX team, considering engineering and design mutually exclusive. But with new rich UI component libraries emerging weekly, and the separation of the UI, or presentation, layer from the application logic and database layers in the code, both UX and engineering see having a prototyper on the UX team as advantageous to the overall product team.

Ideally, an interaction designer and prototype engineer work closely together to deliver prototypes of concept models for testing by the usability engineer. The findings of usability test sessions determine the designer’s next course of action—either iterate the design of the feature based on test results or move on to the next feature.

Prototyping offers a huge opportunity for increasing process efficiency. When done well, it can alleviate uncertainty about design intentions, clarify functionality, and reduce the need for documentation. It also provides a working, though perhaps limited, representation of the application, so everyone on the product team can evaluate what’s working well in the user interface and where gaps or issues still exist.

Why Are These Five Competencies Important?

For a UX team, these five competencies can provide clarity about the domain of each team member. And if you, like me, are the only UX designer in your organization, they may be even more important. The following sections describe some ways you can put this UX design framework to use.

Framing Your Strengths and Weaknesses

You can use this framework to evaluate your strengths and weaknesses as a UX professional and figure out where you can provide the most value on a UX team.

For example, on a scale of 1-7, I’m pretty good at information architecture and usability engineering, so I’d rate both of these skills a 6. I’m about a 5 at interaction design, but we’re all still learning a tremendous amount about interaction design these days. I’m better than average at visual design, but don’t have formal training in it, so I’m about a 4. And I consider myself an expert at HTML/CSS and was once pretty good at JavaScript, but now I need higher-fidelity prototyping, so I’d put myself at a 4 as a prototype engineer. So, my greatest strengths are information architecture, usability testing, and interaction design.

How about you?

Characterizing and Prioritizing Your Workload

What exactly do others on your product team need from you? A mockup? A wireframe? An image? A spreadsheet? Each of these deliverables requires you to put one of these five UX hats on. When I know ahead of time what creating a deliverable requires, in terms of my analytical and creative effort, I can either devote myself fully to the task or, if necessary, change the task priority.

Scoping the Deliverables for Projects

Scoping is about letting others on your team know how long it might take for you to produce a deliverable. If you’ve defined a task well, you already have a good sense of how much effort and time it will take. For instance, if I am asked to wireframe a new feature, I know I’ll have to do some discovery first, which will require extra time. If my task is skinning a user interface module, as you saw from my strengths and weaknesses, I can do the visual design, but it might take me a bit longer to get it right than it would a visual design expert.

Establishing Dependencies

In completing an interaction design task, my decisions are usually rooted in some information architecture work I’ve already done. Or did I? If I didn’t, I’ll need to go back and do it. Likewise, when you’re going to take the time to prototype something, you want to be pretty sure about the interaction design first.

Hiring Resources

Knowing your team’s strengths and weaknesses as well as your design needs, where would it make sense to bring on a new hire? It wouldn’t hurt to have candidates rate themselves on the five competencies so you can assess how a candidate fits your needs.

Regaining Perspective

If you, like me, are deep into making design decisions day after day, you might at times become disoriented and need to realign your thinking about the appropriateness and purpose of the task at hand. It’s important that we come up for air once in a while, not only in the midst of creating our deliverables, but also when managing our time and our team’s expectations.

Our industry is at a crossroads, scrambling to adjust to the demand for richness in Web applications. Design principles, processes, tools, and resources are changing, too. So, now we need to clarify the value of UX design and the competencies it offers to the greater product development process.

39 Comments

joe

November 5, 2007 6:48 PM

Thank you for this article. Right now, I am getting into the whole UXD thing, and your article was perfect to get a clearer view of how the different aspects are put together.

Maurivan Luiz

November 6, 2007 3:50 PM

Cool article!

Steve Psomas

November 8, 2007 6:18 PM

I’m glad it helped. I want to make it clear that this framework does not work for everyone, and again, it doesn’t suggest that you should model your team this way. It has pulled me through some tough times as a member of a team and as a lone UX designer.

Please comment more.

Mia Northrop

November 9, 2007 8:37 PM

Steve, how do you think content fits into the competencies? Content strategy, metadata, taxonomies, and actual copywriting can be considered part of the user experience responsibilities in some roles and organizations.

I’m interested in how you have you addressed this in your career.

Cheers

nemrut

November 12, 2007 5:45 AM

This is a pretty good list, but where are Workflow/Task Analysis, Reguirements Definition, Use Cases…? Almost all the other work products mean little without establishing these baselines.

Steve Psomas

November 12, 2007 5:56 PM

Thanks, Mia.

Great question. Tricky, too. Content is addressed at both the Information Architecture and Interaction Design levels. If you have a copywriter or user assistance writer, there’s an interdisciplinary effort in it. Not only that, but product management should be on board too.

I’m currently in conceptual design mode on a complete UI overhaul of our Web application. And I can’t get around the fact that users will have to adapt to some new concepts, like inline help. Our help files will most likely have to be repurposed. That’s an effort between the UX designer (me) and the user assistance manager.

Another new concept is the way users will navigate the application. What is the nomenclature of the parent and child nodes of that navigation structure? My strategy is to confer with product managers and the user assistance manager to arrive at an educated guess. Then I’ll go test it out in usability testing sessions, rinse, and repeat.

Hope this helps.—Steve

John Beckwith

November 12, 2007 10:01 PM

Steve

Thanks a lot for this! I’m beginning my career in UX design after focusing solely as a visual designer for a number of years and realizing how much the field is evolving. It’s great to have an outline like this to help me figure out my way through projects.

jobrien

November 13, 2007 12:24 PM

This can be and should be used by other groups such as Product Management or executive-level management to better understand what it is we do. As an interaction designer, it is also sometimes difficult to articulate just what it is we do, so this list can help as a cheat sheet. Plus, this helps to clearly delineate between roles and helps everyone understand their boundaries within the design discipline as well.

Steve Psomas

November 14, 2007 12:50 AM

Thanks Nemrut,

You’re right that achieving sound design necessitates a baseline of deliverables such as Workflow, Task Analysis, Requirements Definition, and Use Cases. In my experience, these four describe the business requirements that the product needs to satisfy. So these deliverables are the responsibility of the product manager.

Did you mean Application Workflow and Application Task Analysis? Now these deliverables are the responsibility of the UX designer. Rather than describe the business requirements, they describe the usage patterns within an application. Both fall under Information Architecture, and I had folded them up into “Structure diagram and page types,” which admittedly doesn’t cover the detail required in these deliverables. Did I mention this is a living and breathing document?

I hope this helps.—Steve

Joe Sokohl

November 18, 2007 1:35 PM

Nicely framed, Steve. I know that anytime we try to codify “Just what the heck is UX, anyway??” we open ourselves to all sorts of what about this, what about that threads.

In my role as a Director of User Experience, I have combined visual design, information architecture, Web development—think prototype engineering—and technical writing in one team. So content and metadata should be the province of the technical writers, along with inline, or just-in-time, user assistance.

I’m not happy wiht the term information architecture to encompass what we do—it seems somehow that there’s a UX Architect role that should somehow encompass more. But it’s a work in progress—this structuring of competencies thing. Your article certainly helps get us there.

Nemrut’s comment is, indeed, quite germane. Application workflow requirements documentation and use cases are deliverables that many client stakeholders lean on, think they understand, and expect. Personas, user goals, wireframes, and style guides seem like so much ephemera to them. And the problem does come down to this: they tend to shy away from—read throw away—our field’s documentation in favor of the “oh, it just looks soooo techy, it must be important! artifacts. That’s why I think we need to be key players in creating, if not owning the use cases—at least the use cases that specify people doing stuff, as opposed to system use cases or business use cases. In addition, I’d like to see us create and own a user requirements document that differentiates itself from a business or a functional requirements document.

One can only hope, I suppose….

Steve Psomas

November 20, 2007 7:34 PM

Joe,

I agree—and would go even further—that we, as user experience designers, are creators and owners of application-specific use cases. But the business unit—specifically, the product manager—creates and owns the general business use cases.

I’m not sure I’m with you on the user requirements document though. The two words together suggest a creeping coup that I’m sure wasn’t your intent. I like the idea of a running document not bound to a project. So what are your thoughts on the contents of that document?

Earlier, you asserted that “Personas, user goals, wireframes, and style guides” are ephemeral to stakeholders and that “application workflow requirements and use cases” are expected without being fully understood. I’ve experienced some of the same sweep-under-the-rug mentality. But I really get that reaction only from upstream stakeholders who don’t know what to do with the information. I suggest that engineering—downstream stakeholders—are voracious for support documentation of design deliverables. So it depends on the audience, and you should tailor your story to fit each audience, be it upstream or downstream stakeholders.

Thanks for commenting. I look forward to your thoughts.—Steve

Thomas

November 22, 2007 2:11 PM

Good job. Your five competencies are very work- or method-oriented.

The knowledge areas of user experience I think are best defined in the Microsoft Solutions Framework: 352bf148cb7d830c6c5e562be38c2bf1
To me, nothing beats that categorization. It gives a very clear definition of the areas of UX.

boni

November 25, 2007 6:49 AM

This can be and should be used by other groups such as Product Management or executive-level management to better understand what it is we do.

Joe Sokohl

November 26, 2007 5:41 AM

When I think of a user requirements document (URD), I think of the same thing that a functional requirements document is—a trusted repository defining what the requirements of that entity are and how the system needs to fulfill the requirements.
Back in the day, we had a user interface specifications document. For whatever reason, this term has fallen out of favor—maybe, in its place, there’s an interaction design document. At any rate, I see a URD being a compilation of the key deliverables that express what users want and need. So if the URD is an executive summary with references to the other documents, I think that’s fine. But it needs to have a seat at the same table that the other docs are saufin’ & fressin’ at—an inside joke that, among others, Jim Kalbach will get.

As to the reaction by stakeholders—you’re absolutely right—it does become critical that we craft our message to the right audience. In fact, I’ve been working on a presentation / paper / thought process I call “How Open a Kimono?” I think that we UXers should have an internal-to-our-team document that defines what deliverables we expose to which stakeholders. Maybe we show the tech team the deep sausage making, while we show the SVP- and C-level folks the cellophane packaging.

A lot of this, of course, depends on your own work setting.

Steve Psomas

November 26, 2007 6:38 PM

Thomas,

Thanks for that. That’s a good checklist for things to consider when interaction designing. It’s short, so it must be high level. For instance, I would expect knowledge about branding to fall under graphic design.

Some more might be:

Subject-matter knowledge

Scope of UI technology

Cheers, Steve

David Travis

December 3, 2007 9:58 AM

Steve

This is a thought-provoking article, and I think it is spot on as a description of the hands-on design side of user experience. But there’s a whole chunk of requirements that isn’t covered—or at least, not in the depth that it deserves. For example, I’d expect to see an Opportunity Analysis competency—stakeholder analysis, market segmentation, developing the UX vision—and a Context of Use competency—user profiling, environment profiling, and task analysis. I talk more about this model in my book, “E-Commerce Usability.” (You can see a pictorial version of the model .)

This would mean that the UX practitioner needs skills in stuff like contextual inquiry, ethnography, and business analysis.

michelangelo

December 3, 2007 2:30 PM

Others have commented on the article’s content, so here’s a word on its presentation. You are putting large amounts of information inside graphics with null alt attributes. This makes the information inaccessible: screen readers and search engines cannot access it, and graphical text does not resize. This is especially unfortunate since the images’ content is nothing but well-structured text. There is nothing fancy about the presentation to recommend the use of graphics in place of HTML. I think UX professionals should mind accessibility; if this topic is new to you, I recommend this introduction to accessibility.

Danny Hope

December 4, 2007 11:22 AM

Have you thought about redoing this in HTML, with terms being linked to definitions?

It would be great to have this on a wiki somewhere.

Clair Ching

December 4, 2007 1:37 PM

I am but a newbie when it comes to UI design, and I think your essay will help me think about it really well—especially when it comes to interactions and such.

Steve Psomas

December 5, 2007 6:44 PM

David,

Thanks for your thoughts on this. I’m glad to see this article sparking discussion. Your model is enlightening insofar as it speaks to process and the outside influences.

However, be cautious about throwing everything under the User Experience Design umbrella. Sure, Opportunity Analysis and Context of Use are important to a designer’s understanding. But in my experience, which admittedly isn’t everything, the Product Manager (PM) or Business Analyst (BA) feed these into the UX process.

Now, you could say, “Everybody, step away from the customer; he’s all mine.” But it’s the job of a PM or BA to know what features and components the product strategy requires you to satisfy. That doesn’t mean the UX designer can’t inject himself into any of those processes and deliverables; in fact, if you’ve got the time, I’d recommend it. But be true to your primary goal of delivering design.

Also, even if you have the deepest knowledge of your Opportunity and Context of Use—specifically, the three aspects that you’ve outlined above—does that directly aid in your decision of whether to go with a certain form element in favor of another, for instance? Become knowledgeable about the specifics of the user activity the PM or BA has handed to you. If that’s not enough direction, ask the PM or BA for more.

Steve

Steve Psomas

December 5, 2007 7:00 PM

Michaelangelo,

It’s a great point you bring up about the images. One thing I knew before writing this article, you can’t please everybody. That’s the story behind UX design. You have to rise above that fact and, once again, gain perspective.

I’ll pass the information along. Thanks.

Steve

Mike Ni

December 21, 2007 12:01 AM

Thank you for helping lay out a framework. After having moved back and forth between the product and the UX roles, having a clear sense of the deliverables becomes critical to help disparate groups work to deliver a compelling solution to the market. Given how easy it is to copy technology these days—that is, features—we are quickly getting to the point where UX makes all the difference.

Steve Psomas

January 3, 2008 3:00 PM

Mike, that’s a good point. At the company I work for, I was brought in as the lone UX designer. Product Management and Development were in place and well established. I soon realized that just having a warm body to think about the user experience and bridge the gap between product requirements and engineering was a huge improvement. Not surprisingly, attention to user experience has lifted this company from stagnant to number one in its space. Thanks.

marsha harner

April 17, 2008 4:50 AM

Thanks for this. I really like the way you broke out the groundwork from the deliverables. On many projects that I have been on, it is hard to explain why you need to do things like contextual analysis, and I think this really helps to explain why UX people are so darn busy all of the time!

Mahesh Kumar

June 17, 2008 1:45 PM

I am somewhat in agreement on this aspect of competencies in design, but when identifying competencies in a manufacturing process or service industry, what should be the questions and answers? The questionnaire requirements vary from business to business and based on a business’s objectives and positions. Can you guide me further in this regard.

Mahesh

Steve Psomas

June 19, 2008 6:10 PM

Marsha—Thanks. I hope you use it to prove your worth and then some.

Mahesh—Thanks. I have no idea about the processes of manufacturing or typical service industries. But I’d like to. I think I get your point, however. You mean, how can a designer truly represent a process—like manufacturing or that in a service industry—if he doesn’t know what’s going on?

Here’s my answer: He needs to find out what’s going on. Get time with a subject-matter expert and ask him or her to tell you:

What’s the big process? and

What are the roles involved at each point in the process? (And think only in terms of roles, not employees.)

Once you know the roles, find people who fill a role and ask them what steps they take to fulfill their obligations in the process. Then go to people in the next role. Lay out the bigger process as you find out more in one grand diagram. And prepare for an Aha! moment.
That process will be very effective in informing your design if you take the time to do it. I hope that helps.

July 2, 2008 7:06 PM

Thanks for the article. I’m wondering where you would fit scenarios into this? I would think under interaction design. Is that what you meant by component requirements?

Steve Psomas

July 8, 2008 6:37 PM

DJ,

That’s a good question. Sorry we’re getting into semantics. What I had meant by Component Requirements was strictly mechanical; that is, must be sortable, must incorporate pagination, must provide a visual cue on drop, and so on.

Again it’s a semantics discussion. But my understanding of a scenario is all of these:

the page-level design variations when a user interacts with it—You might see that in a storyboard.

a use case variation—That belongs in the requirements documentation—usually a product manager’s responsibility.

a flow document that expresses page-level design variations to meet the needs of a user in particular situations—Now that belongs in Interaction Design under key states and/or wireframes and/or storyboards.

If that’s too vague, I can try again. Just let me know. Anyone know of a good glossary of user experience design terms? That would help this discussion.

Thanks DJ.

—Steve

Jason Sack

August 4, 2008 5:11 PM

I would place BA and IA deliverables—including wireframes—in the first group, with design patterns and visual design in the Interaction Design bucket. Seems to flow well if you have a good collaboration between the IA/Design team.

Stu Collett

August 11, 2008 1:27 PM

Great article and overview, Steve.

Thanks!

Kumud Bihani

September 18, 2008 6:22 AM

Thanks a lot. I am currently looking for a job as a user experience designer, and although I have all these skills, I did not know how to potray them together! This really helped!

Fritz Desir

September 27, 2008 8:12 AM

Steve

Concurring with everyone else in this thread. Great post! Very much needed. Our consultancy has recently been grappling with these buckets, primarily making the where this starts and this ends and this starts type of decisions. One thing we have decided on though is that Content Design—as I call it—is a separate bucket that definitely contributes to the overall UX—especially when thinking about the standard organization/primary destination Web site, as opposed to a promotional microsite or Web application. Word count, tone, grammar, photo/video choices all play a part in the experience. This was traditionally referred to as copywriting/editing or video production, but this shifts considerably when working in an interactive digital space that can encompass words, photos, videos, and animation. The central output of Content Design speaks to how do I make content more attractive and legible, as well as helpful—think documentation. Take all of this and add what’s possible within a social media environment and you will get something else entirely. I think, though, when looking at the central role content plays in how we experience 90% of the Web sites we encounter, its importance is really staggering.

Anyway, apologies for the long comment, as I’m certainly not a content designer/strategist myself. Just wanted to share how important that skill set is as it’s often overlooked.

Steve any thoughts about putting this together in a book?

Johnson Fabienne

June 22, 2011 5:00 AM

This article is exactly what I needed to really understand what UX is all about. I am a graphic designer and have been thinking about getting into UX. This article really helped me understand what’s involved.

Philip Hastings

March 11, 2013 8:52 AM

Great stuff. It’s especially important to understand our roles and to constantly recalibrate our insertion into the process of UX design.

Philip Hastings, UX Design Colorado

Rebecca

March 27, 2013 12:34 PM

This article is a great resource. I’ve referred to it numerous times. Thanks!

Ian Scheller

November 12, 2013 4:23 PM

100% awesome article. Can’t believe it took me so long to find it.

Gwen Robson

November 19, 2013 1:18 AM

Well, well, this has restored my faith a little. After hearing horrendous stories and seen rip-off artists posing as Human Factors, this sounds like it may work well!! Not that I’m skeptical or anything! Thanks for the well-written article.

Anirudh B. Balotiaa

November 6, 2014 3:10 AM

Thanks for the post.

A follow-up question, specifically, what kinds of Key Result Areas (KRAs) or Key Performance Indicators (KPIs) can be set for UX Designers?

Stephanie Klausen

February 16, 2016 12:35 AM

Steve, as a new graduate working in a large global IT company, I found this article inspiring and extremely helpful. I have graduated with a Masters in Digital Design and Communication, specializing in Service Design. But this term is confused by all and everyone I work for in this company, and I’m the only designer-type person employed there. So expectations that I can do UI and UX as well are high. Yet I have done only school projects to date, with some experience in coding HTML, CSS, and Java, as well as interaction Design. The many designer titles are misunderstood by management, and it is my constant job to explain my area of expertise, while, at the same time, I continue to develop. So your article about the five competencies was for me brilllant. Now I just have to figure out which area I need to focus on and develop first. One really is an all-around expert as a UX’er. Thanks again.

Join the Discussion

Full name

Email address

Remember me (Optional)

Comment

Steve Psomas

UX Design Manager at Workday

San Francisco Bay Area, California, USA

Specializing in Web application design and UI product management, Steve has eight years of experience in UX design and four years in UI component engineering at Workday, Responsys, Neoforma, Intuit, Clear Ink, and Maus Haus. He is currently responsible for managing UI requirements and interaction design at Workday. Steve has developed and presented an audio conference on Rich Interaction Design. In his work as a designer, he draws inspiration from his prior experience as a technical writer and teacher. Steve graduated from the University of San Diego with a B.A. in English. He is a member of UPA and SIGCHI. Read More

The Five Competencies of User Experience Design

Information Architecture

Interaction Design

Usability Engineering

Visual Design

Prototype Engineering

Why Are These Five Competencies Important?

Framing Your Strengths and Weaknesses

Characterizing and Prioritizing Your Workload

Scoping the Deliverables for Projects

Establishing Dependencies

Hiring Resources

Regaining Perspective

39 Comments

Join the Discussion

Steve Psomas

Other Articles on UX Roles

New on UXmatters