User Experience (UX) may come by many names, but the importance of it is indisputable. It is a good idea to focus on the person who will be using whatever it is you are making. UX should be an insurance to minimise the fail rate of your product by telling you what will fail before you finish building it.
If you still don't have a UX designer on your team, stop reading and get one! For the rest of us, your project's risk might not be on the UX insurance coverage just yet if it's displaying one of these four symptoms.
#4 Slow or no reaction to new information
New, relevant information is a fact of life. Your competitor could be releasing a new product that thoroughly obsolesces yours tomorrow. That external information will definitely affect what you will do next week. A good UX team will produce internal streams of relevant insights, which is great. However, your project team needs to quickly react to this new information. Heaven forbid, it doesn’t act at all - we normally called this the "Titanic Mode".
For example, consider your team has to do a "discovery phase" for a divination group and comes up with the entire product's life-cycle of user flow, wireframes, and storyboards for a “flying broom”. Four weeks into the project and the actual users are telling you’ll that they want a “flying carpet”. If your team responds with "Well, we should try to find an entry point. Maybe on the next iteration or planning meeting? That's in two weeks? Gonna need to move a few people... Will need to get these figures approved again. Buck it, let's just make the darn flying broom." Then the carpet will be pulled from under you.
Case of The Boiling Frog
#3 PSDs, emails, noise artifacts replacing Real Conversations
Some people still have misconceptions about how design works. Designers are often locked up in a room so they can lay their magical golden eggs... with some design-oriented UXers helping to collect them. They will produce a slew of noise artifacts designed to replace real conversations so that they can keep doing their thing in their cave - to the frustration of all parties involved. Some artifacts are designed just to "appease" certain people like Marketing or QAs.
"Hi Harry, Did you get a chance to email Ron so that he can e-signoff on the wireframe I emailed you last week? I need it so I can update the Hi-Fi PSDs for Marketing? To be frank, I'm not sure why the Marketing said 'no red' but whatever - I have updated it to Salmon Pink. I hope they e-signoff it this time, it's been the 5th round! #OhNoItsMarketing"
Why salmon pink products might not be a good idea
It's easy to demonize anyone you haven't had a real conversation with. For the Marketing team, red might have been disastrous on the last project when it actually boosted the competitor's sale. Salmon pink discussion would have come up had both of them talked for five minutes. Truly one of your project's huge time-sink.
#2 UX doesn't touch Dev/Code
UX is not UI, we know that. Some non-technical UX however use this as an excuse to not have any interaction with the technical part of the team, ever.
For example, this is real advice I’ve heard:
"UX is not supposed to have any development skills. If Dev comes back saying that they can't implement the UI, then you should ask the UI Lead for help. If that still doesn't work, you're going to have to live with it."
What that means is that your project will be compromising on either the design or the implementation, weakening your product even before it comes out of the gate. This also frustrates both parties to no end ("You can't even implement a button right!" "Do a few pixels really matter? Here's where you can shove it a few pixels up")
#1 Accepting mediocrity
The burnout. Close enough is good enough. At the end of the day, everybody is getting his or her paycheck. And if the functions are important enough the user will suck it up and use it. What more do you want?
Here's a common quote I hear. "You involve us (UX) a bit too late. All we can do is put lipstick on this pig and call it a day."
Paradoxically, this should be where UX shines. UX should be able to research/test what would happen when we walk down this path, creating a clearer vision for the team. Perhaps even suggest alternatives within the constraints.
If we are releasing something "unpolished" because of the restraints on time, budget, people, or objectives... that's OK. Every project goes through this awkward phrase, like the teenage years. But it shouldn’t be happenstances. The team should be making that decision with backed-up information and understand the consequence of said choice. They should own it.
In conclusion, if your project exhibits any of these symptoms then UX lethargy is on the way. One way you can address this is to create a shared vision of what the team wants to do. Get people to feel the consequence of their actions on the user. Encourage the fact that their contributions are not only welcome, but also compulsory.
Or a jetpack. That works too.