Process, data, and intuition
UX designers are in a role that is meant to use data and process to eliminate intuition and craftsmanship. The assumption is that if a well-defined process is used and every step is carefully backed up by data, everything will just work. Part of the reason behind this is that often times the people doing the hiring don't understand the role they are hiring for. If you're not a designer, it's hard to judge the ability of the person you're hiring.
Good design works. I think we all agree on that. But what is good? That's where process and data are meant to help.
There are a lots of different processes, this is one that is common:
The above process glosses over it, but in here is likely user-testing, persona development, user stories, and hopefully (because it never ceases to amuse me), moodboards. It's not the process itself that I disagree with, it's the idea that one process works for everything and ensures results—very tidy, just not realistic.
"Can you walk us through your design process?"
If I'm designing something that will take me six months, I have a much different process than if I'm doing something that I'll start and finish in an afternoon. Likewise, my process also depends on my team. But there is a common core.
A lot of articles on process stress the need for empathy and ways to get there. Empathy isn't a series of steps achieved through tools like user stories though, it's just part of design. If you need certain tools like user stories to get there, good for you. I generally don't. I'd argue that most designers generally don't, moodboards and user stories are often pageantry for the stakeholders. For me, empathy is internal and has no deliverables.
Design is also not a concrete process. If I can't see something clearly in my head, I'll sketch it. If I can't see it clearly when I sketch it, then I'll use Figma or something to design it until it's clear. If it's perfectly clear in my head, I'd just as soon go to HTML/CSS/JS and re-factor later. In a perfect world (unfortunately, not in big corp) my team would see the design as a mostly-functional project. We'd discuss, iterate, and then get it in front of users.
Lastly, nothing is perfect. The biggest proponents I've found of process are people in corporate environments. I'd argue that implementation and evaluation are the most important part of process—and yet they're usually overlooked in large organizations. Iteration is crucial.
Similar to process is the desire for designers to focus on data.
This is not my strong suit, but I believe in it and respect it. However, I have some caveats. Data, especially big data, is complicated. I'm friends with two data scientists—both really smart people. Data analysis is hard. It's not something I'd trust just anyone to do. Not only is the analysis hard, but you have to fight the human tendency to favor your own prejudices.
Twice in the past week alone I've heard a very loosely organized user testing session referred to in a way that implies it's hard data. User testing is rarely (if ever) the absolute best source of data. How things are tested in my industry is not awesome. We put half-baked Invision prototypes in front of people who are being paid to be there and ask them very pointed questions about it or perform very specific tasks. This isn't data, it's a way to make designers feel better and back up their assumptions in front of people who might disagree.
I'm not saying user testing isn't helpful as a gut check, but I'd rather put things live and watch what happens—via interpreted analytics and customer feedback. Analytics in 2020 are super powerful. If you want to see how useful it is, build it. Build the real thing, not some sad prototype, and then watch real customers use it. You will not be 100% right the first time (or you may be, good on you). That's fine. Design is iterative; it is a learning process.
Usage patterns change. Products change. Your site should change and evolve. Keep watching, keep learning, don't pretend to know all the answers, that's the best we can do.
The best use of data I've seen is this: as a team, we'd set goals of what we wanted a new project to achieve. We'd use tools that were simple to implement and could be easily understood. At the end of the week, we would all get together to look at the results. Was our project achieving our goal? Everyone in the room could understand the basic parts of the analysis, some would understand the nuances and be able to clarify to others. Small team, common goal, no drama. As a team, we would agree on potential areas for improvement and define a plan based on a mix of a/b testing, reworking, and redefining.
However, this is key: this method relies on trust and mutual professional respect.
Lastly, intuition has gotten a bad rap lately. I'm not sure when our industry decided to veer completely away from the ephemeral, but UX (and all design) is not just a science, it's also an art.
I don't put a lot of stock in the Meyer's Briggs test, but like most everything else in life, learn what you can from it and move on. I'm INFJ. What I learned from this is that I generally make decisions based upon a gut feeling and that this is something I can either accept or fight against. As I've done well with this my entire life, I think I'm going to roll with it.
This means that while I have unspoken reasons for almost everything I do in my design work, there are times when it just feels right. But while data might not be my strong suit and I'd rather go on a gut-feeling, I'm also willing to rethink my stance when I'm wrong (also INFJ).
I don't believe in a one-size-fits-all approach. This is just my opinion. If your process works for you, that's great. I only wrote this as a counterpoint to the assumption that the current model of process and data evaluation works for everyone.