UNDERSTANDING UX ROLES IN 15 MINUTES OR LESS
How to staff a UX team when you know nothing about UX.
“We need a UX Person…we think.”
My inbox gets requests from agencies and recruiters almost daily, and I have gotten pretty good at filtering through these requests. If a request looks un-spammy, I’ll courteously respond — even if the request for “UX work” that isn’t really UX work.
Just as often though. I also get requests for UX work that is “UX work” in a broad sense, but does not fit into my realm of UX Strategy, a discipline that exists alongside, and at times within, UX Design and UX Research.
My goal with this article is twofold: 1) To explain what UX Strategy is, and where it fits with its sibling disciplines, within a project-type. And 2) To help you understand identify what is the best UX role fit for your project.
So what is UX Strategy and how does it fit into the current UX milieu?
First, Keep in mind that it’s an evolving job role that encompasses a multidisciplinary skill-set.
These include:
- UX project planning and onboarding design
- Discovery of project goals, identification of stakeholders and key resources
- Facilitating and/or co-facilitating interviews and workshops
- Interpretation of data in conjunction with UX Researchers
- Minimum Viable Product (MVP) and/or key interaction validation
- Strategy and task design and documentation
- Artifact and prototype creation with or without creative counterparts
- System architecting with or without Info Architects and/or Data Architects
- Knowledge sharing with other disciplines
- Wireframing and/or User Flows and Task Flows
If you think that I just made the waters muddier, hang tight. In fact, quite the opposite is true.
Why? Because the above skills have existed as part of the UX project lifecycle within various disciplines for decades. What has happened in recent years as awareness of UX’s value has increased, is a consolidation of these skills into a single discipline.
So why isn’t educating non-UX people—particularly those staffing UX roles—a priority? I really don’t have a good answer, except to say that we are in a period of rapid change. However I can provide some definition and differentiation for you.
My hope with this article is that whether you work in UX, or need to find UX talent, I will help you understand your UX role needs.
One FYI: If you aren’t curious or don’t care about UX theory, feel free to skip the next section. The rest of us UX nerds are going to hang back a second…
First a bit of System Design theory
Ok nerds. Let’s review…
In chapter two of Rex Hartson and Pardha Pyla’s essential (and criminally underutilized) tome “The UX Book: Process and Guidelines for Ensuring a Quality User Experience ” (Kauffman, 2012), the authors introduce the idea of “System Influence on Process Choice” within system design. Besides being a term that sensually rolls off of the tongue, it is also a much simpler concept than the name would indicate: UX system design tasks can be viewed in terms of ranges of complexity called “Work Domains”. Intersecting these work domains are interactions associated with the project goals. Work domains and interactions can be rated as either “complex” or “simple”. When you combine the two, you get a Process Choice. So for example, I can combine a simple interaction with a complex work domain, and the result is simply ”Simple Interaction/Complex Work Domain”.
Since there are only four Interaction/Work Domain combination choices, the visual representation is four quadrants that reflect the system types being developed…in theory.
In reality, what you have are three quadrants to describe a variety of projects that overlap at times, followed by a fourth option, which for most projects is a false fit. More on that shortly.
Below is the diagram mapping out the basic concept:
So how do I use this?
Okay, everybody back? Lets get started…
While reading about Process Choice, it occurred to me that if the quadrants in the exercise can help UX specialists, then it might also be useful to non-UX people to understand their UX role needs.
In order to help the non-UX people, I repurposed the quadrants to reflect real-world project types, and the corresponding roles that might be needed. Below is a breakdown of the combos.
- Complex Interaction/Complex Work Domain (CI/CWD) — Sometimes this literally involves rocket science: CI/CWD is the domain of things like aeronautical systems and power plants; as well as software like Adobe Illustrator or AutoCAD. CI/CWD is for process-dependent systems with lots of moving parts, legacy layers, and little tolerance for failure.
This domain typically will place heavy importance on a UX Designer with a corresponding engineering degree or engineering experience, who is able to work through lots of design iterations. In the early stages, research may be headed by an outside research team, or the UX design team itself. Additionally, in cases dealing with legacy systems, an experienced Information Architect (IA) will also be useful.
Because the scale and scope of these projects can be expensive, multi-year commitments, requests for staffing them are relatively rare compared with projects under in the other quadrants. - Simple Interaction/Complex Work Domain (SI/CWD) — These are projects that require pretty simple input from the user, but involve a series of complex tasks within the system. Examples include HealthCare.gov, Facebook, or DocuSign. There can also be a social/organizational component — especially when designing things like a company intranet.
In the initial stage, these sorts of projects require a UX Strategist and a UX Researcher in order to generate assumptions from existing data. Once the time to conduct interviews comes around, the two conduct Contextual Inquiry, Business Analysis and Task Analysis. The UX Researcher organizes and classifies the data, then one or both then organize and interpret the data in order to come up with a set of recommendations, and/or validate existing assumptions.
Then the validation and design phases call for a UX Designer and/an IA, who will likely be present for to review findings, requirements, goals etc; as well as design the system in question.
Many times, UX will generally be executed in the initial and middle stages of a SI/CWD project, unless it is as standalone research for use down the road. I’ve personally worked on a number of these projects. - Simple Interaction/Simple Work Domain (SI/SWD) — This is the domain where many consumer-facing apps and websites live. It also tends to be the process that is most heavily recruited for as UX becomes gains recognition within the creative realm. Unfortunately, many times UX is inserted some time after assumptions and goals have been established; so the UX specialist finds his or herself effectively having to mitigate poor planning. However, that can be averted to an extent, since SI/SWD is a highly collaborative domain, relying heavily on creative thinking.
In this domain, UX/UI Designers and UX Strategists are best utilized. Activities may include design thinking, creative workshops, business research, user testing, wireframing, and prototyping.
Additionally, a small multidisciplinary workgroup using Lean UX methodology can help ramp up quickly, getting a lot done in a short amount of time. Particularly in the validation and prototyping phase [UI[
In this domain, iteration is generally in conjunction with the client and/or a small research sample. Each iteration will also work closely with the engineering and creative teams. - Complex Interaction/Simple Work Domain (CI/SWD) —
As I mentioned earlier, this domain is a bit of a false friend and generally should not be used in the staffing UX roles. Here is why:
Imagine you are building a series of interfaces for a smartwatch. The essential purpose of a watch is to tell time (Simple Work Domain). However the various screens used to program the date, give you a pedometer reading, or show the weather forecast are complex interactions. Therefore a digital watch is CI/SWD. Right?
Wrong.
Here’s why: The problem is that the work domain itself (the time of day) is so essential that it is really the purpose of the device. Why? Because the fundamental reason for using a watch is to know what time it is.
At the same time, within the Complex Interaction part of the equation: Things like setting the alarm, programming your step-goal, etc, are really unique applications with varying degrees of difficulty, which are actually work domains.
Therefore, the applications are really what determine the Interaction/Work Domain combination, not the watch itself.
Still don’t believe me? Then take a look at your smartphone…
If I ask you “What does it do?”, you’ll probably show me all the apps you use, tell me about the camera, or give me the stats on the processor speed and screen resolution.
However none of these things directly answer the question “What does it do?”, which really means “What is the purpose of a phone?” The correct answer to which is: “To make phone calls”.
But is it really? I can’t remember the last time I bought a phone solely based on its ability to make a phone call. What I use a smartphone for are things like taking pictures, navigating with GPS, listening to music, and (most likely) using third party apps. But these third-party apps have nothing to do with the native smartphone experience. Furthermore, they all have wildly varying degrees of complexity.
So on top of the smartphone’s interaction/work domain, there is an added layer of whether an interface is part of the native user experience, like the camera app, or a third-party non-native user experience, like Facebook, which actually exists in it’s own completely unique ecosystem. In other words: Facebook is Facebook, but the Facebook user experience just happens to be compatible with my phone. All of this means that on a single smartphone, you can have everything from native SI/SWD (like dialing a number or launching your email), to non-native CI/CWD (like managing SalesForce CRM within a mobile interface).
So really, CI/SWD projects are more like a collection of other quadrants, not a definable quadrant itself; and discovering UX role needs is going to require understanding the task you need to perform, and not the project itself. To misuse an old Russian proverb, when it comes to CI/SWD: “Trust, but verify.”
Visualizing It
Below I have added some visualizations of the concepts discussed in the previous section to help get you up to speed. If you have gotten this far, know that everything above is a lot to absorb in one sitting.
The first one below is the interaction and work-domain graph from earlier, but with project example types and the CI/SWD process combo crossed out.
Bringing It All Together
The second graphic is a vertical chart summarizing the combinations reviewed, along with UX role needs, task types, and example projects.
I do need to emphasize that timing, role and job overlaps can occur in any of these domains, but this graphic will help give a general idea of who is needed for what, and when.
Wrap Up
The awareness of UX as an important tool in the project lifecycle is increasing within organizations, but understanding the types of UX roles, and where to insert them, is still something that recruiters are in the process of refining.
For my part as a UX Strategist, writing this article was partially out of a selfish motivation to promote my discipline, but I also wrote it because I think that it is important for those of us in UX to share our knowledge in order to help them help us by advancing awareness of our profession’s value.
Whether the search is for a UX Strategist, an IA, a UX Designer, or UX Researcher, recruiters are actually the first to implement UX strategy simply by trying to fill UX roles for clients. Hopefully this article and the tools it contains will help to push things forward a bit.
Thoughts on this article? I welcome any comments, criticisms or angry volleys. Reach out to me at jacob@bornhuman.com or Twitter: @jharrisuxpdx
Be well.
Downloads For Reference:
Modified Work Domain/Interaction Graph
Modified Work Domain/Interaction Summary
Sources:
Hartson, H. Rex, and Pardha S. Pyla. “Chapter 2, Section 2.3: “Choosing a Process Instance for Your Project”” The UX Book: Process and Guidelines for Ensuring a Quality User Experience. Amsterdam: Kauffman, 2012. Print.
“Modified Work Domain/Interaction Graph”, “Modified Work Domain/Interaction Graphic, Marked”, “Work Domain/Interaction Summary” Graphics by author. 2014. By Jacob Harris. From source The UX Book: Process and Guidelines for Ensuring a Quality User Experience. Hartson, H. Rex, and Pardha, S. Pyla. Kauffman, 2012.
Dissemination and alteration of all original graphics is encouraged under the Creative Commons Attribution 4.0 License: https://creativecommons.org/licenses/by/4.0/
