In the beginning, there was design. No, not fonts and colors. Think bigger. We're a tool-using species, so we've been asking these questions since the beginning: What can I make to solve this problem, what does this thing need to do, and what does it look like? Next, how do I improve the thing I made to be more effective and pleasing? That's design stripped down to its bare essentials, whether we're talking about a potato peeler or a user inteface that simplifies hideously complex processes.
I live in that design space.
Fast forward a couple of hundred thousand years, and we're at the level of sophistication that we deploy fields like ergonomics, usability, and human-computer interaction (HCI) to predict and reality-check the quality of our design decisions.
I live in that space, too.
Of course, we're always known there's an intangible element of enjoyment to all the things we're surrounded by. That's an emotional reaction. Nobody has done more to explore and evangelize that than Don Norman, who we can thank for making “UX” an actual job description when he set up the User Experience Architect's office at Apple back in the nineties. The job was to knit into a coherent whole the efforts of silos and disciplines: Engineering, marketing, and industrial design. White lab-coat usability and graphic design. Usefulness and feel.
Ultimately, I live in that space.
You might say I'm a grizzled veteran of it, since before UX became a fashionable label. Now, this needs to be said, so I say it: Once “UX” got popular, title inflation went full send, and today “UX” means just about anything, to the point that we now have to reach for product and customer experience design to capture what Don Norman originally set up “UX” to do. That's fine; labels are just labels. What matters is what we do.
TL;DR: I'm a UX, product, or customer experience designer. Whatever you want to call it.
Bonus reading: Getting in the weeds
Do I specialize in some particular industry? Do I have a niche?
No. The first principles of good design are applicable to any problem space. That said, you pick up quirks and unique facets to any field and any industry when you spend some time diving into it, and I've been around: Consumer, business, and internal facing sites and applications. B2C and B2B e-commerce, banking, payment systems, consumer electronics, fitness, promotional products, non-profit, manufacturing, GRC (Government, Risk, and Compliance), just to start at the top.
There are also fellow-traveller fields and specialties that tend to glom onto the job: Accessibility, conversion-rate optimization (CRO), privacy compliance, business analysis, and, not least, code. Ah yes, code. “UX” and “UX/UI” tend to get lumped in with Web front end, and I'm no exception — HTML, CSS, JavaScript have been part of my daily life more or less this entire time, along with the various frameworks, libraries, and IDEs (Integrated Development Environments) that go with them.
Let's be honest about this: Yes, it's cool and cost efficient to have your designers also build the front end. However, design and build are two different things. The more you ask someone to switch between the two, the less effective they're going to be at either one, no matter how good they are at both.
Here, let's just list out the pros and cons of having your UX designers also build the front end:
-
Pros:
- Efficiency. I can build out what I design. In fact, my design can be the build when I set up interactive, high-definition prototypes in HTML, CSS, and JavaScript.
- Lower cost. Designers are expensive. Good devs are expensive. Get two for the price of one.
- Minimal signal loss. Nothing is lost in translation in the hand-off between designer and developer. The designer is the builder.
- Domain knowledge. If you know how to write the code you intimately understand the capabilities and constraints of the medium.
-
Cons:
- Productivity. You're not going to be as efficient at either design or build, because you're context switching.
- The bog. I call it the “front-end bog”, because Web front end can be quicksand: Everything you build can suck you into a hole of bug fixes and browser/OS quirks.
- Skill drain. Many of us are very good at both UX design and front-end development, but there are so many hours in the day and you will hit the wall. Front-end code is more complex than it was just 10-15 years ago, which was more complex than 10 years before that. To really pay attention to the details and keep up with new techniques, you really need to specialize.
Do I enjoy unicorn roles, where my team both designs and builds? I certainly do, and that's where I've spent most of my career. It's very rewarding to bring your own designs to life and watch paying customers interact with the code you wrote. Whether that's the most effective solution for any given business depends on an honest assessment of the pros and cons.
