1

UX Design: Knowing When to Fold ’Em

 2 years ago
source link: https://uxplanet.org/ux-design-knowing-when-to-fold-em-24d35056d5ac
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

Overview

Every once in a blue moon despite your best efforts, you’re gonna have a project that goes completely sideways and blows up in your face.

This can happen for a variety of reasons, but the result is still the same: you need to pack it up, pack it in, and walk away.

Today, I’m gonna show you how to discern when might be a good time to throw in the towel on a project, and how to let stakeholders know gently.

Why give up?

Now I want to be clear, I am NOT a fan of bailing on projects, and as a rule I will generally fight tooth-and-nail to make sure it gets pushed over the finish line.

That being said, there a few cases that you’ll want to watch out for when determining if it may be a good idea to axe a project:

  • Non-paying clients
  • Ever-changing specifications
  • Completely saturated market
  • Large-scale technical infeasibility

Let’s go over these in more detail.

Non-paying or unreachable clients

This is by far one of the most common things that should make most companies think twice about continuing with a project.

If you have non-paying clients that refuse to pay, won’t work out a payment plan, have no intention of seeking financing, or are unwilling to talk things through with you while just wanting the work done: axe the project.

Trust me, it’s gonna be nothing but headaches down the road.

Ever-changing specifications

Another relatively common one. You agree to the scope of work and the statement of work, all the features, etc. You get to work, and then about 1/3 to 1/2 way through research or design, the client contacts you in a panic saying that they want to completely change everything.

Okay, no big deal, we’re still pretty early on. So you do it.

Again, like clockwork, 1/3 to 1/2 way through the design process, another emergency, need to change the specs.

This will continue for as long as you let it. I’m not talking about necessary alterations in the wake of research either, I’m talking about full-blown complete overhauls of everything that you’re doing, and sometimes this will even be requested in the dev cycle.

Again, this is normally due to specifications that clients didn’t realize they needed, which is of course your job to tease out of them during discovery, but you’re not a mind-reader.

If your clients keep changing specs on you, and it’s causing you and your team massive issues to try and pivot effectively: axe the project. It’s not worth it.

Completely saturated market or non-existent problem

This one is sadly the most common, and you need to let your clients know early on if you discover this in your research.

If the market is already insanely saturated with wide-spread solutions to the design problem, you’re already going to be fighting in a red-ocean of attempted differentiation.

Seriously, just don’t do it, even if you win with this one, 99/100 times you’ll still lose because you’ll design the experience for the product, and then it will get lost in the noise of your competition.

Large-scale technical infeasibility

This one is much more rare, but can happen, and is usually the result of either a massive deprecation/modification of the platform your solution uses, or a change in vendor ramifications that renders your solution infeasible.

It’s not common, but I’ve seen it happen, so I list it here just in case.

How to let it go with dignity

There are four steps to letting a project go with dignity that should be observed and taken in this order:

1. Run it by legal

First off you want to make sure you even can axe a project, so check with legal to see about termination and exit clauses to make sure you’re doing it by the books.

2. Talk with your team

Next, you’ll want to discuss with your team why, who, what, when, where, and how this is going to go down, what it means for them, and what will happen next. This is VERY important as axing a project is never a decision to be taken lightly, and can be very jarring for people who have been working on the project.

Show them that respect, and let them know what’s going on.

3. Talk with your clients and be honest with them

Let your clients know that you’re axing the project, why you’re axing it, and what it will mean for them.

This is the time to do everything you can to leave a good taste in their mouths, because even though they may have caused you a boatload of problems, you should never be in the business of burning bridges.

4. Issue refunds where appropriate & button it up with legal

Finally, make sure you get the cancellation buttoned up with legal, and you issue refunds where appropriate as a gesture of no-harm, no-foul if you’re in a position to do so.

If you can’t issue refunds, explain why, and if you can only issue partial refunds, that’s still better than nothing. Do what you can for your clients to make sure that even if they really dropped the ball, they still walk away with their pride as in-tact as possible.

So what does this all mean for you?

Essentially, if you’re gonna axe a project, make sure you have a really good, well-founded reason for doing it. Most of the time you can work around changes, but every once in a while you’re better off throwing in the towel.

The best, most effective way to make sure you do it right, is to:

  1. Run your decision by legal
  2. Talk with your team
  3. Talk with your clients and be honest with them
  4. Issue refunds where appropriate & button it up with legal

While it’s never fun to have to cancel a project, following these steps can make your life a whole lot easier, and can leave your organization a whole lot better off, by making sure you’re letting that project go with dignity.


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK