Should I be looking for a job with a specific title?
Are there roles I should avoid?
And what do I do when the job description says I have to do everything?
This topic actually comes up quite a lot with people who have booked sessions with me on ADPList, and entering the job market in the first few years of their career in this field.
The point of confusion seems to be around labelling, which is ironic given the work we would do with content, information architecture, and taxonomy.
The case against “UI/UX”
I’ve called myself, at one point through my journey from mid-weight to principal designer, these titles: Experience Designer, UX Designer, Product Designer, Interaction Designer, Service Designer, Information Architect, CX Consultant…
But there is something I would never call myself, and that is: a UX/UI designer.
(And, spoiler: it isn’t because I don’t do UI!)
There are two different arguments here:
1) User interface design is a sub-set of skills that make up user experience design
You won’t call someone a “Menu Developer/Cook Chef” in the same breath, would you? Calling a designer a “UI/UX Designer” is similar to that comparison, as you cannot separate the interface from the experience, nor the experience from how it works when it looks a certain way.
There is an inherent connection between both skills: the design and interactivity of the interface is a key aspect to the general user experience.
Without the visual and interactive elements of the design, it becomes much more difficult to sell the problem-solving perspective of the structure and experience.
There is that old analogy about UX being the blueprint of a house, while the UI is the exterior and interior design of the property. Without the other, one cannot call itself a complete house.
2) Visual design skills are very different in application to interaction design skills
This distinction goes back to the histories of both careers – from library sciences that grew into information architecture and the structuring of content through human-computer interaction, and GUI design that came as an evolution of computers, then the internet.
Not to mention the graphic designers who paved the way across different media!
Both sets of skills are integral to the success of the product that you’re building, and the value you’re bringing across to the cross-functional team you’re in.
(On a side note, and possibly for another article: I have also often seen designers boxing themselves in “the way the brain is wired”, i.e. a visual designer is seen as a more creative individual, while a UX designer is more structured and analytical.
Sometimes, it is very egregious to read definitions in job descriptions, and even in articles laying out the differences in skills and scope of UX and UI – I’ve hypothesized they’re written by UX-leaning folks – that basically boil down to, “a UX designer is a critical thinker and a problem solver”, and a UI designer, uh, “can choose typography and colors”.)
The result? Blurred lines.
The lines blur with each given individual designer, their shape and their stack. One designer can be comfortable hands-on with all the tasks, but they also need to learn how to prioritize: first based on user and business value, then based on what is needed at the point of time. Circling around a content model might not make as big an impact as a working prototype for a set of stakeholders, but might be the motherlode for another.
As a design leader, understanding the scope of what needs to be delivered often starts with identifying the team’s strengths, what they can deliver in a reasonable time, and balancing the deep specialization each designer can bring holistically.
Companies often want that fabled unicorn who can do it all, but I’m reminded of a quote:
You can do anything, but you can’t do everything.
Not at the same time, anyway!
At the end of the day, great experiences are delivered when you have a good mix of both types of skills.
Even if you’re a designer who can straddle across the skills and deliverables (and on a good day, I feel like I can), you still need checks and balances to make sure that the outcomes are balanced.
That means collaborating with your product manager to understand the metrics in which the deliverable will be measured on, or discussing with the engineer who’s feeling a deep sense of despair as you demo the impossible interaction from Figma.
(Just kidding — please don’t do that! We can talk more about desirability, feasibility and viability at another time, though.)
Making an impact
Beyond the actual business metrics, and beyond titles, what we do as practitioners impacts to a great degree what people experience in their lives. It doesn’t start and end with “I made this app look really nice,” or even “translating business requirements from my product owner".
Worse still: “My stakeholder wants to do this so I guess we’ll do this”.
Instead, there’s a lot for us to be intentional about: the language we use, the people we include, and the (hopefully positive) impact we make on their lives.
Then there are questions like, how do we make sure that accessibility is a foundation and not just an afterthought, a checklist of items only for it to get a passing rate, or a plugin on Figma to make sure colors are contrasted enough? How do we make sure that we are not unintentionally excluding people by calling them “edge-cases”?
And even beyond the fabled “user” — what about our own employees? What about the newcomer who’s joining the team, and wants to hit the ground running but still with ample support? Or the hiring partner who needs to understand exactly what skills to screen for when they find someone? (Ah, full circle on this piece.)
Design lives beyond roles and nomenclature. Leading by design and curiosity, and the North Star of creating meaningful impact is the intersection I believe we can make the most of our skills and time on, and honestly? That goes beyond the title I call myself.