We stand with Ukraine and our team members from Ukraine.

The Community Of Over 640,000

Killed at Launch

by Pete Mackie
4 min read
Share this post on


A failure to account for UX results in an e-commerce being pulled offline shortly after launch.

This actually happened. An e-commerce website had been designed and developed. Launch had been initiated, and it was abruptly taken offline in mid-air.

I became involved with this project just as the website was launching and advised the decommissioning. This was not a comfortable position for me to take with my new client: advising them to shut down their site.

Pulling it offline was an even more difficult decision for the owner. After all, this was not my client’s hobby. They were expecting this website to provide them with a living.

This project was a typical e-commerce site with one significance difference: the site hosted multiple stores (under a single domain), with a similar look and feel for each. The stores were managed individually, but offered products for sale through a common shopping cart.

It should go without saying that the complexity of the design, development, and deployment almost surpasses comprehension. Creating a “multi-vendor” website is a savagely nontrivial task.

The original quote my new client had recieved from their vendor was a measly $10,000 (a website of this magnitude typically costs in the range of $75-100K). When all was said and done, the final cost jumped to over $25,000. How could the initial estimate be so far off (two times)? This simple answer is that the scope of the project was never properly defined, and gross mismanagement completely ignored front-end and back-end users.

Management Mayhem

It takes many skillsets to build, deploy, and manage modern websites: project management, graphic design (creative), software engineering, software development, usability testers, website beta test management, marketing, and client management.

As I see it, the cause of most website failures is little or no project management. “No need to define and manage, lets just build something and see what becomes of the website,” seems to go the thinking.

The customer in this case learned after the project failure just how blindly they’d gone into site design and how poorly the project was managed. When I asked what happened, the details came pouring out:

  • “There was never a roadmap for the website’s design, form, fit, and function.”
  • “Page layout design wireframes were never defined and presented to us for review and acceptance.”
  • “There was no formal project acceptance criteria provided.”
  • “We did not know enough about the design an development process to have any doubts regarding the website vendor’s abilities.”
  • “We were an experiment for our website vendor.”
  • “They learned how manage website development from our project.”
  • “During the sixteen months of the project lifecycle, there were many organization changes.”
  • “The deploy environment was basically launch the website and see what happens.”
  • “We did not know any better, as website development deployment was new to us.”

There had been no bridge between the website customer to the vendor’s creative staff. The customer tried to develop “crude” graphics to show them the desired look and feel for website. The customer was the designer.

I find the statements from my beleaguered client chilling. Plenty of them give reason enough for website shutdown decisions prior to launch.

A Ruined Experience

As I mentioned earlier, this website was to provide multi-vendor ecommerce services, where vendors could set up a their own unique shop identities and publish products—including photos—linked to them. This capability required an easy to use content management system. The website was neither alpha or beta tested with users. Instead it was fully launched as a means of testing.

Furthermore, the shopping cart had to hold product orders form multiple vendors. The ordering system had to process orders and notify multiple vendors for product shipment. The website vendor’s answer was to use the free and open source CMS Joomla an add-on module called the IXXO Multivendor Shopping Cart designed for guru-level IT personnel, not the casual user.

Pity the poor vendor, thrown through pages on Joomla component pages with weird names like: Banner, D-Mack Recommend Friends, Jumi, and LyftenBloggi.

The site owner tried to support about six early adaptor vendors though the UX nightmare, but they hadn’t seen the content management and multivendor shopping cart administrative pages prior to launch. After more than two weeks of attempting to support early adaptor vendors, things were going nowhere: pulling the website offline was the only solution I could see.

How The?

How did this happen? The one and only website software developer was young and inexperienced. He selected the Joomla and IXXO software for without discussing it with anyone, including the website customer. The website vendor was a creative-centric enterprise with low experience in software development and a void of UX and usability skills.

The form, fit, and function of the entire website—particularly the content management, multivendor shopping, and the customer interaction—was not shared with the website customer. Sixteen months of design and development more than $25,000 wasted, to say nothing of the lost market opportunity.

How to Never Do This

Bad UX, front-end and back-end, can kill a website. There are finer points (don’t deploy general-purpose software modules for a narrow purpose to save time or money), but more crucially, the client needs to be involved from day one.

Engage a full team of website deployment project members, covering all of the disciplines required. Above all else, have a full-time, experienced UX professional available on the website development team. You can’t start a user experience review two weeks before launch.

If you ever hear anyone asking, “Hey, can you look over this website? We are just about ready to launch,” be very afraid.

Image of rocket launch courtesy Shutterstock.

post authorPete Mackie

Pete Mackie,

Pete Mackie is a software developer and publisher who founded his first company, Seaquest Software, some thirty years ago. It is still going strong.


Related Articles

Visualising 10 types of bias in 10 visuals.

10 Types of Cognitive Bias To Watch Out For In UX Research & Design
  • The article covers how crucial it is to address cognitive biases for navigating daily life as well as UX research and design. Our judgment and thought processes become biased, which might distort reality in accordance with our preconceived notions.
  • The author illustrates 10 examples of real-life cognitive biases and their reflection in UX research.
Share:10 Types of Cognitive Bias To Watch Out For In UX Research & Design
5 min read

More autonomy and less dependency can improve our toxic relationship with digital technologies and benefit all of us, says Alexander Steinhart.

Designers And Developers Pay More Attention To Human Autonomy
  • The majority of tech companies concentrate on attracting active users and increasing consumption. Additionally, their economic incentives conflict with our own values and aspirations as users. 
  • According to the author, we should adhere to the rules of responsible, ethical, and humane design referred to as Design for Human Autonomy.
  • There are 3 conditions to design for human autonomy:
    • The user and their interactions with others should be prioritized over their use of the digital service;
    • In the end, consumers are encouraged to navigate mainly without the software itself;
    • The app’s values are transparent, and it respects the users’ values and objectives.
Share:Designers And Developers Pay More Attention To Human Autonomy
5 min read

What if we designed anything with relationships in mind?

The Rise of Relational Design
  • The author believes that putting relationships first should be a common practice in every part of human activity.
  • The author sees a relational design as something we can anticipate in the nearest future. It can be applied in many cases – from designing cities to building any type of organization or system.
  • Relational design isn’t new in any way – the fact they are old makes them this powerful. With relationships in mind, we can start designing a new future.
Share:The Rise of Relational Design
3 min read

This website uses cookies to ensure you get the best experience on our website. Check our privacy policy and