The Five Competencies of User Experience Design
Published: 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. 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.
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.
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.
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 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.
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.
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.
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.
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.
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.