Explorations on the identity of an experience designer
You probably don’t need me to tell you that the UX/XD/UI field goes through an identity crisis every now and then. And as much as it frustrates me to watch “discussions” (i.e., very smart craftspeople talk right past each other), those discussions are good. Not because of their outcomes, but because they happen at all. They show that we care deeply about language, how we’re perceived, what’s expected of us, and how we can grow into our desired future professional selves.
I’m going to call this UXistentialism.*
The thing is, these discussions are typically framed at the macro level — “What is User Experience design, anyway?”—while they are answered most effectively at the micro level—”What does user experience design mean to me and others around me at this time in this context, organization, project, and team?” The UXy needs of projects & programs within startups, large enterprises, universities, governments, & agencies are necessarily different and so the role of UX shifts to meet those needs. Additionally, the ways in which those roles are fulfilled & activities performed will vary as well.
While there will and should be similarities, there can’t** be a universal answer. There are traits, skills, approaches, bents, and tools that are shared across the spectrum and beyond the UX borders: it’s a way of thinking & being, a mindset.
Working at a large agency with large clients with a variety of digital project experience, we occasionally find ourselves in such a pickle: “I thought UX was _____” or “No, that’s ________ deliverable” or “________ is specifically a UX contribution.”
And so, after some UXistentialist wondering, I changed my own approach. Just like the beginning of a project, I laid out my own expectations of what I could & should provide to my team(s) as the UX lead so that in turn, I could communicate that outwards to teammates & clients as necessary.
You’ll notice from the words below that they go beyond a typical list of UX deliverables & activities. There are a handful reasons I’ve gone here.
Organizations & projects are different for everyone.
Chart after diagram after blog post after Twitter argument will tell you what UX is, should be, or isn’t. UX isn’t — I’d argue that it can’t effectively be—one toolbox for all.
Lots of non-UX people are good at UXy things.
Some copywriters are great at driving the team towards clarity. Some art directors are hip to what’s cool, some developers have a good perspective on usability, and some account managers understand an audience better than anyone. And so on. We don’t like being pigeonholed, so don’t do it to others, yeah? Invite others to contribute & humbly work through everything towards a common goal together.
Themes are widely helpful
Raise your hand if you’ve ever been told, “Oh, we don’t need UX. Wireframes aren’t that hard.” Or, “We don’t have time for a prototype.” Or, “I don’t know what you do, so I didn’t invite you.”
Now put your hands down, everyone. I think we’d agree that we are all more than the work we do and, with areas like voice & AR/MR/VR on the verge of exploding, the things we do become less important than the ways in which we do them. Wireframes are less important than storyboarding to drive clarity & valuable conversations. Being known for the latter will get us farther.
Because of where we sit in the process and the output & outcomes of our work (alongside product managers/owners, of you have them ), UX designers are often stewards of tension throughout a project. Between widely varying demands & constraints, people & other people, and inputs & outcomes, UX is well-positioned to initiate conversations & emphasize particular characteristics of a project. I made a mission statement to succinctly bring it home.
The goal of UX is to help deliver meaningful experiences by emphasizing form, connection, and practicality.
What is the shape, structure, & substance of this bit of work? Also: what is it not? This is the classic UX work. Wireframes & whatnot. The deliverables & activities. It includes (but is certainly not limited to):
- Information architecture
- Interaction design
- Flow: how will we thoughtfully guide the customer from one point to another with clarity & value?
- Begin the checklist: The structure should help the downstream team begin to understand what’s in store: assets, content, functionality, etc. Of course, this isn’t a designer just telling everyone else the checklist; they’re all making & working through it together.
- What+How: Not just what it does, but how it does it. What emotions do we evoke, quality time do we save, real difference do we make? Again, this can’t be designer’s dictation, but cross-functional collaboration.
With apologies to Donne (and to you, dear reader):
No experience is an island entire of itself; every experience
is a piece of the ecosystem, a part of the system…
No design, feature, app, site, technology, or experience exists on its own. Jorge Arango recently wrote a nice bit on how form sits within & must respond to a context. If we fail to understand and work within the systems in play, frustration will only grow inside & out of the organization. Fortunately, experience designers are uniquely positioned in several ways to be effective connectors, especially between:
- Organization stakeholders & customers
- Organizational objectives & customer goals: even those outside the scope of the project at hand can be helpful in identifying overlap & opportunity
- Internal departments, roles, & disciplines
- Technology & design
- Strategy & outcomes
- Outcomes & updates: if you can get beyond just shipping, look at the results of your work and use them to propose updates, improvements, or opportunities for further exploration.
- Your work and everyone’s expectations: sell it all into obviousness
- Ecosystem & journey mapping: how does this project sit within fits broader context of apps, websites, business process, etc.?
Furthermore, in connecting the aforementioned nodes, we should strive to create:
- Collaborative environments
- Shared clarity of the problem and solution frame
- An understanding of a project within the widest scope e.g. omnichannel, retail, customer support
- The broadest overlap between the needs of customers and the business
Some have suggested that UX shouldn’t compromise. I prefer Mark Boulton’s, “design is an exercise in considered compromise” school of thought. Practical, defined:
of or concerned with the actual doing or use of something rather than with theory and ideas.
I spend enough time in theory & ideas (as you might’ve gathered), but if we don’t get something to market, none of this matters. And it shouldn’t just be anything, it needs to be meaningful across the board. As mentioned before, few others as as well-positioned as UX to understand the balance, the tradeoffs, & the potential impact of various decisions.
- Don’t do what isn’t necessary
- If the unnecessary must be done, get something out of it, learn from it
- Understanding of the problems, context, and assets at hand
- Work towards what we can delivered, learned from, and repurposed
- Do what needs to be done (within reason) to launch
- Use as much of what we have as possible
- Not perfect state, but meaningful & attainable states
- Encourage continuous improvement
- Seek out high leverage, mutually beneficial interactions
- Extract value from the way that we do things
- Apply UX principles to meetings, documentation, & design recommendations
Ontology before activity
I realize these aren’t entirely original thoughts on the matters at hand, but I tried to reorganize, reframe, take a different approach to this whole problem: one of, “what do we provide?” not just, “what do we do?”; I want to communicate the core benefits of UX, not just the features, the why not just the what***, in a way that is:
- Readily understood by those outside the discipline
- Accommodating to designer identities & aspirations, at least in part
- Meaningful in any stage of any project in any organization
- Driven by value, not activity or categorization
Incidentally, the shape of this argument supports its purpose: the form of UX in a given context is to generate connections in the most practical way. Note again that these can be done by almost anyone, and, in a way, it’s part of our opportunity in scaling to make sure we aren’t the only ones doing them.
Hypothetically: thanks to your great work, UX in your organization is coming out of the dark ages. But you can’t possibly handle all the additional work on your own, right? So how to you maintain the momentum? Not just by doing certain things yourself, but by reinforcing certain things with others. This can help get you out of the deliverables business and build UX consideration within a culture.
And so go my latest UXistentialist wonderings. I don’t think it’ll settle any bad blood, but I hope it’s enough to bump a few folks in the right direction.
Honestly, I’ve worked through this in a relatively static (for an agency) season & haven’t had an opportunity to really try it out in new relationships & situations. But as I’ve run it by several designers & non-designers, it’s been helpful to them.
What about you? Helpful? No?
*How’s that for a pretentious label?
**UX designers, of all people, should know this, just like we know two chatbot apps can be the same. But we’re a passionate bunch.
***Describing what we do in our terms to others is the worst. Doing so assumed so much from them! It also suggests that we care more about telling someone about ourselves than we are about them understanding it.