Simplifying the Defintion and Goals of UX
Extending a conversation on simplifying how to describe and frame UX as a practitioner or business agent
The other night, I attended a meetup group of local UX professionals. One of the good things about these groups are the various levels of experience persons have within a field like UX — and so it gets fun when doing introductions and job descriptions go all over the place. Some of the more interesting discussions comes when someone who is trying to break into UX (or has and is quite junior in that experience level) starts to ask how to understand what it is they are jumping into.
I like when conversations get to that point, mainly because we go from talking the “terms” of UX and start talking about the “outcomes” of UX. A recent post on Farnam Street dove into this context when quoting and expanding on something said by Richard Feynman — there’s a difference between knowing the name of something and actually being able to articulate an understanding of it.
Its on this point where some persons in a field come to a realization they are no better than they were when they started the field. They are doing activity, but its under a name of something they are still trying to understand. Its at that point in the conversation where I have some fun — not because I understand UX any better or worse than anyone else — just that I’m a fan of having simpler definitions for my own sanity.
I define UX with the simplicity of four terms:
Now, I can already see the comments somewhat ablaze from those who are in the field whom will say that UX has way more to it than this. And I won’t disagree. However, those dissenters might come towards a rebuttal with specific roles and the behaviors within them. That’s not exactly understanding UX as much as it is understanding terms. That said, there’s probably a neat and tidy way to encapsulate the roles with these four terms.
Not an exhaustive list of roles, but its very clear when looking at those roles based on the UX focus areas that there’s an approach to understanding UX which might clarify roles, expectations, outputs, and even career development.
Now, in that meetup, I went a bit further in this description. I believe that anyone who professes to be in/near UX actually has all four of those terms happening all at the same time. Thing is, they aren’t happening at the same level of competence. For some items, the practitioner might be at a high level, for some they might have let skills atrophy and so the expereince would be high but the level of ability might be medium-low. If one can simply the discussion to these four terms (research, design, code, and content) and then cleanly state their competence in a low/medium/high scale in each of those four areas, it allows for roles and the expectations and outputs of them to be more clearly understood — especially by those who are not clear to the entire value or scope of UX.
Mid-level and senior level UX folks seem to like that simplification. Not so much because it explains everything, but it level-sets most things. They are then able to see not only their work, but the business and technical gaps in understanding their work. For new and junior-level folks, these bucks give some framing to what they are coming to understand; and even how to evaluate the roles they would like to move into.
I’ve honestly got a lot more to this than just this piece here. But, it seemed like an appropriate time to write this up. Those folks at that UX meetup might be looking for a bit of a recap of the conversation; and many others might be going about hiring UX folks but not exactly all that confident about the bucket of persons they are entertaining.
Currently working as a Director of UX for a small company in VA, I’m also available to help your design, hiring, and executive teams better understand UX/SDX, and its opportunities and impacts. Get in touch if that sounds like a next step for you.