We Spent So Much Money On This And It’s Bad… Should We Just Release It Anyway?

Posted By Debbie on March 6, 2018

I came up with this post idea when I read in late 2017 that Disney was sure that their spin-off Han Solo movie was going to bomb… but they’ll release it anyway in 2018. The rumors are that the script is terrible, the actors aren’t good, and it’s a money pit.

What should Disney do? Release the movie knowing it may make customers unhappy, especially about something that has so many wild fans? Re-shoot or re-edit the movie? Shelve it and go direct to video at some point? Disney has options.

What should a software company do?

You’ve probably heard this story before. Software company spends lots of money building something. When it’s getting ready for release, someone realizes it’s not great or even good. Let’s imagine it’s bug-free but the UX is summoning The Four Horsemen of Bad UX.

Everybody starts whispering about how much it would cost to have to scrap all this work and start over. Should we just release it?

I’ve heard this one in real life. “Nobody had redesigned our portal in years. We hired this company to redesign it and it wasn’t that good. It some ways, it was a downgrade. But management wanted to see us using what they built (solely) because we paid all that money for it. So we installed it.”

If you bought expensive ingredients and spent hours cooking dinner only for it to turn out disgusting, would you still serve it to your in-laws, assuming you like them?

If you spent a lot of time picking out a very expensive dress but by the time you went to wear it, it was a few sizes too small, should you still wear it out?

The only question: How did that happen?

Any company taking UX seriously and incorporating a full UX process into product design and software development shouldn’t end up at this crossroads. Nobody should be surprised that late in the game that the product is a known or potential failure.

Solve this problem before it happens by hiring UX specialists who will incorporate all of the appropriate User-Centered Design tasks into the process. If we truly know the customer, if we have identified our personas, if we have reviewed the competition, if we have had UX specialists come up with multiple solutions and refined the best one, if we have taken this to user testing and then iterated after user testing… this scenario shouldn’t happen.

The times I have seen this happen have been when non-UX roles have designed the product and/or when user testing was eliminated from the process. That normally happens when:

  • Someone decides we don’t have the time or budget for testing before dev builds it. Consider the possible outcomes. Can you afford the time and money to rebuild it if it turns out to be an embarrassment or failure?
  • Someone announces that we’ll just test it live. We’ll release it to some or all of the public and we’ll see how they react. Again, can you run the risk that the public experiences something that is an embarrassment or failure?
  • Someone is sure we don’t need user testing. Marketing told us people want this, we built it. You know what question I’m going to ask here.

The cost to change your mind or redo something increases as the project moves into later stages.

It’s easy for us to completely redo a product design idea when everything is still an Axure prototype. I’ll just change the prototype, we’ll test again, and see if that’s a better solution.

It costs a lot more to have one or more teams of developers re-build something. Teams of QA people re-test for bugs. Possibly having to merge the code in again.

The moral of the story is: don’t release something that could be embarrassing or a failure. Nothing good comes of that. Customers are unhappy. You lose trust. Wall Street or bloggers tear you to pieces.

Know what’s embarrassing or a failure before you release it by using a proper UX process. Go through all the UCD steps but certainly spend more time testing and iterating if testing shows there is room for improvement.