11 things that go wrong on a UX project

What to look out for when you inherit a Pain Project

UX projects often go wrong because someone was not aware of, or did not plan to mitigate certain risks. I have inherited many such projects over the years, so here are my top reasons why the wheels come off.

Why are some projects screwed up, and some not?

Often the most well-run UX projects are that way precisely because the clients or stakeholders have worked previously on a project that went very wrong and there were Consequences.

But this time, they are willing this time to invest in Doing Things Properly in order to mitigate risk and avoid pain.

In short, they’ve been hit by the bus before, so they now know to be careful when crossing the road.

Most of the projects I inherit where something has gone wrong, it’s because the project has been designed or run by a team who do not understand, or do not perceive the types of risks inherent in UX projects.

Somewhere along the lines someone has said “hey, let’s do it this way!” because they don’t know any better, or they don’t care because as far as they’re concerned, nothing can go wrong.

What’s the worst that can happen?

However if you know the dangers, you will assign the correct time and resource to ensure things don’t go wrong — because you know it’s much more expensive and career-limiting when they do.

What does “gone wrong” look like?

Each project is unique and has the potential to go very wrong in new and interesting ways, and I couldn’t possibly list every single one here.

However there are some situations which are, in my experience, the most predictable signifiers that something has gone or is about to go horribly wrong.

These are the things that will derail any UX project:

1. No methodology or process

If you’re doing UX work, then you’re doing Science. And Science requires a methodology. No matter the size of the project — a day, a month or a year-long, you need to have an approach planned out.

How do you understand the project balance the various sets of needs? How do you define the approach to the solution? What is the design and how will it be tested or validated? The standard UCD method will allow you to do all of this, as will Design Thinking or whatever trendy, newfangled label on the same thing we’ve been doing for years floats your boat. But you need to set it up up-front, and follow it to the end. Not abandon it or skip it entirely because it’s not cool or exciting enough.

You know this is the problem when… No one knows where we are on the project. No one knows what happens next. No one understands why we are doing a task, how one activity relates to the next, or the value of any given exercise or deliverable.

The client and/or senior stakeholder and/or any other person who thinks they know better than the UX people involved can suggest random additional tasks and activities that add no value whatsoever because there is no rationale for why we’re doing anything. The project will drag on, money will be spent, no valuable outcomes will be achieved and everyone (including the user) will go home unsatisfied and possibly, without a job.

2. Inappropriate or insufficient deliverables

Related to the methodology planning above, another problem arises when you have a methodology but have not planned for appropriate deliverables at each stage. There needs to be an upfront plan on how the process is going to be documented, which deliverables are to enable the working team to move the design forward and which are for stakeholder engagement or sign off — and what levels of fidelity are needed for each.

You know this is the problem when… Stakeholders don’t understand the deliverables (i.e. can’t explain to their colleagues what they are, or what they are for), or are asking for different deliverables because they can’t use what you’ve given them. Sometimes it is as simple as mis-matched expectations. However sometimes it’s because there was not enough forward planning for large scale stakeholder engagement.

In this scenario, you will often see actual work stopping while practitioner time is spent re-cutting deliverables in new ways — building presentation versions of prototypes, making shiny promotional videos of the project, or endless Powerpoint decks. If it has been established up front that there are large numbers of senior stakeholders, then a separate strategy needs to exist with a parallel workstream to create politically-driven assets — and this is not part of the core UX team’s work.

3. No documented requirements

Requirements state what the product has to do, or what different stakeholders and the wider business need from it.

They are the output of requirements gathering exercises (stakeholders) and primary research (users).

These are generally (most sensibly) categorised into Business Requirements, User requirements and Technical (and/or) Data requirements. Think of this as a 3 legged stool — if you miss one, you fall on your *ss.

They are your North Star for the rest of the project — for every decision you make you ask yourselves — does it meet the requirements? If not, don’t do it.

It also means that if a stakeholder demands you do something which contravenes the requirements, you can flag a major change that requires the project to pause, and revisit the requirements. Similar to a change request

You know this is the problem when… The project changes constantly, different stakeholders say different things and you’re pivoting all over the place. There are constant curve balls, zero consensus and nothing ever gets signed off — because you didn’t establish a single set of requirements up front which documented and balanced all stakeholders needs.

4. A lack of stakeholder engagement

This one is hard to manage, but during the requirements gathering phase, you need to understand and be in touch with all relevant project stakeholders. This will involve the rigorous rooting out and mapping of client stakeholders, with a clear comms and engagement strategy for all and also a dollop of luck.

To be fair, you probably can’t anticipate or account for the risk of a new senior stakeholder joining the client team half way through the project, but you can reduce risk by just not assuming that the list you’re given is the final list, and making sure that your stakeholder network flags any new stakeholders asap when they arrive. And that your deliverables are on point.

You know this is the problem when… A stakeholder manifests mid-project with a new set of requirements or a general project bomb that blows everything out of the water such as “my team finished a similar project last week.. what are you lot doing?”

5. Tech teams not involved upfront

A specific sub-issue of not having the right stakeholders is not talking to tech and data teams as part of requirements gathering.

You know this is the problem when… You’ve designed something with loads of senior stakeholder buy-in and internal publicity but that cannot be built, will cost a fortune to build, or has made a tech team somewhere very, very upset.

6. An excess of ambition, without pragmatism

It’s great for stakeholders to be ambitious, however a dose of reality and pragmatism is also needed around what is actually possible. As part of the requirements gathering, someone needs to be tracking implications and asking the right questions — if the ambition sounds big and exciting, are the timescales and budgets commensurate with this type of work? Are you going to have access to the right stakeholders? Are tech teams onboard? (see above) Are you doing enough primary research to prove out the business case and mitigate risk?

Again, this is why tech teams and specialist stakeholders are your friends early on, because they will show you where the risks and dependencies are, and you can bring these up early on with your ambitious stakeholders and document them. It’s not about squashing enthusiasm — it’s about preventing disaster.

You know this is the problem when… The project has run out of time and or money and the desired outcome has not been achieved.

7. A lack of stakeholder limits, boundaries and controls

There absolutely needs to be someone on every project who has the ability to say no to stakeholders — or at least to point out risks and dependencies and allow the stakeholder to make informed decisions — without being shouted down.

It can be as simple as someone who has the role of saying “this is not what we agreed in requirements, therefore you need to revisit them with us and provide more resources to make these changes”.

You know this is the problem when… The project has changed and pivoted multiple times because stakeholders have changed their minds. Often this is a flip flop back and forth on an undecided point. Stakeholders do not listen to, or regularly dismiss the advice of the practitioner team.

It can be most disappointing when this comes with a lack of respect for the skills, experience and guidance of the UX team — if the team is simply producing things the stakeholders want produced, it is not a UX project, it is a production studio.

8. A lack of sign off and stage gates

If you have a process, the right deliverables plan, a stakeholder engagement Strategy and someone coordinating your stakeholders’ often competing demands then this shouldn’t be an issue. However. It is essential that someone holds stakeholders accountable for the sign off of each stage gate of the project before the next begins — to whatever extent is most feasible.

Example: requirements should be signed off before IA begins. IA should be signed off before design begins. Now clearly sometimes requirements are a moving feast as the project evolves, in which case you need sign off In Principle with an allowance of budget and resource for pausing the project, revisiting requirements and re-mapping dependencies and changes through subsequent stages of the project.

You know this is the problem when… Nothing has been signed off. Everything is based on assumptions or that no stakeholder has explicitly said “no”. However, you’ve done the same part of the project multiple times and are massively over-burning. And the whole project is a house of cards waiting to come crashing down the minute someone says that something is wrong.

I often hear “we can’t know all the requirements up front”. This is true, certainly on larger projects. But if you don’t start documenting and getting alignment from the beginning, then that’s one very big bus coming your way later on.

9. Skipping the research

Research; everyone’s favourite “expense” and often the first thing to get cut when someone just want some designs churned out. However, research is also the thing that de-risks the design solution.

Do users want this? Will they use this? Will they be able to use this? Generative, formative, evaluative, summative — whatever the approach and purpose — you need to do some in order to remove inevitable assumptions from your project that will come back to bite you when someone asks “where is the evidence to justify this project?”

You know this is the problem when… You start asking questions about fundamental project assumptions and quickly discover there’s no tangible evidence to back up any of the decisions that have been made.

10. Skipping the IA

Another thing teams love to skip over in the race to produce screen designs is information architecture, which regular readers will know I believe to be both vital and rather sexy.

IA work helps you get buy in from stakeholders around how big the thing is, how it hangs together, what content is needed, and how the basic mechanics will work — long before you spend time making prototypes and designs. It doesn’t have to take weeks; a simple site map and some flows for a small site or app can be knocked out in less than an hour if you know what you’re doing — but the result can be a saving of weeks of design time on the wrong solution if you just don’t bother to think it through.

You know this is the problem when… The designers or UX team cannot explain how their prototype works, what the relationship is between content or why things are where they are. Screens keep being added to The Thing with no end in sight. Interaction patterns are inconsistent. The client can add in anything they want wherever they want without any logical, rational push back because there is no logic. You’ve not even gone live yet and it’s already Frankenstein’s monster of UX.

11. Inconsistent team & lack of ownership

Where a team is inconsistent there is no sense of ownership or accountability. And this can happen either with stakeholders or UX teams. If stakeholders change constantly then there is no leadership and no responsibility for things like requirements, sign off etc. If UX teams change constantly then there is no deep craft knowledge, no deeply held understanding of users and no sense of ownership or integrity.

You know this is the problem when… No one knows which stakeholder to go to for sign off or direction. No one knows which UX person did which piece of work or why. The work is inconsistent from requirements narrative through to wireframes. The project needs a librarian to understand how all the deliverables fit together.

I’ve worked on projects with big consultancies (you know which ones..) where someone’s only job was just to write down everything everyone said, collate deliverables and sling everything at new project joiners. It led to a lot of shallow superficial knowledge, widely distributed and it showed in the work.

These are the main ones I’ve come up against over and over — if you see one of these happening on a project, you can either brace yourself, try to fix it or run.

It’s always worth fixin’

For the majority of projects, things have gone wrong due to ignorance rather than stupidity. For this reason, it is always worth attempting to re-position the project, educate stakeholders and realign teams towards the right kinds of processes. Yes there are times where people kind of deserved the outcome due to Massive Arrogance, however I find that most stakeholders who have already been hit by the bus, are generally more open to corrective manoeuvres to avoid getting a face full of tarmac again in future.

In a future post, I will address ways to de-fck a project that has already gone under a moving vehicle. It can actually be very rewarding.

If you found this useful, consider subscribing for free to get email alerts when I post new articles, or you can join Medium for full access to my article archive, plus everything else on Medium.