UX in web development: How to work with a complex product

Complex projects have little chance of succeeding

It is always riskier to work on complex products rather than on the small ones. But what does it mean that a product is complex? Well, it depends! The more actors, stakeholders, scenarios, touchpoints, modules, and versions, the higher the risk of creating a costly monstrosity. 

The statistics are brutal. According to The Standish Group, research conducted between 2012 and 2016 on thousands of software development projects, if you work on the complex product, you have 14% chance of succeeding. In a small project, this chance rises to 38%. Success here means that project ends on time, on a budget, and with satisfied customers.  Approximately 49% of small and 59% of complex projects end up late, over budget, and with less than satisfied customers. 

Almost one-third of complex projects fail (27%), which means that they were cancelled before they got resolved (or were resolved but never got used). Hence, you can expect that with increasing complexity of the project you leverage the risk of disappointment. 

Why some digital projects fail?

Something will go wrong if you’ll have a lot of dependencies, ideas to implement, and decision makers. Without a clear strategy, the product might have functionalities that support mutually exclusive goals.

A big project is hard to monitor as a whole. The dependencies are sometimes not so obvious. Surprisingly, the influence of the change in one product area could be spotted in another. The smaller scope gives better control. This is why even small changes in big project cost much.

Another tendency is to apply all ideas that come from clients or stakeholders. This is a constant process, so the number of features and gadgets is increasing, what delays the delivery of the final product. As a result, you have many “nice to have” options that make the usage of the “must have” ones less convenient.

Adding new features before you collect the feedback from the test with real users means that you are making the whole thing more complex without even checking how the current solution works. The more functions and dependencies, the more challenging (or even impossible) it is to discover what affects the conversion. To be more sure about that it's better to launch product partially and check after each release the impact of changes on the conversion.

The main problem is that in such projects there is always something to be added, something to be improved. So how to deal with it?

 How to deal with the complex project? 

 First of all, forget about creating the perfect product. Take into the consideration the words of Tom Gilb from  “Competitive engineering” book:

“The Cost of Perfection – Beware Infinite Cost Increases ‘Perfect quality’ does not seem possible in our world and lifetime. The stakeholder would always like to have it (the ‘Ideal’ level), but cannot ever afford it in practice. It seems that the ‘cost of perfection’ is infinite resources. More practically, the costs of performance levels ‘nearing perfection’ have a nasty tendency to accelerate towards infinity. 

So, as we become more ambitious regarding performance, we must become much more exact at specifying the performance levels, if we are to hope to understand and control the cost implications. Further, we must also understand that our systems can be sensitive to very small changes in any attribute or design specification. These seemingly small changes can give unexpectedly large cost increases, incalculable in advance.”

-Tom Gilb

The solution is to create something with a limited scope. Something you can test and collect feedback. In big projects, you can’t wait until the whole product is finished to collect feedback.  

Proof of concept

Proof of concept (POC) is a prototype of the solution, made to verify a concept or check the hypothesis. It is used more when it comes to the technical aspects of the product. Since the lean approach becomes more popular, the term MVP is frequently used in term of POC in the digital area. MVP (Minimum Viable Product) is the simplest version of the product that has as little as possible features so that you could test the main assumptions. It is very useful for User Experience tests. 

If you are working on the very new concept and need to check the hypothesis, then the MVP is a good idea. For example, you need to check if you can build a specific product, work with the particular technology, or test if and how users use your product. But if just after the launch your product will have a competition on the market, then you will need something more than a raw functionality. You will need a Minimal Marketable Product. 

To find what is the MMP, first you have to define your product: the value proposition, the category of the product, users and their needs and gains, competitors (or existing solutions that you will compete with), and competitive advantage (primary differentiation). Next thing to do is establish key performance indicators (KPI) and clear goals. Product definition and KPI should be used as a guideline when working on MMP. 

How to define the scope of the first release?

Think about such complicated solutions as Facebook or Messenger. Because of their complexity, both apps need a lot of space on mobile devices. That is why some users decide not to download them. With that in mind, Facebook launched a “Light versions” of both apps, which have limited functions and minimalistic design. That could be a reference to a complex product. Think about the “light” version of the project you are working on. What functions would you get rid off if there was a limited space?

It's always a good idea to match business value with costs of implementation to investigate low hanging fruits and features that are expensive and don’t bring much profit. 

The very useful User Experience technique is Story Mapping, where the product is divided into scenarios and epics or stories. This approach helps to priorities features and choose the core functionality without the risk of gaps in user flow. In other words, you can cut everything that is not necessary for users to reach their goal. 

In case of the increasing the backlog of new features and ideas for the product, try to find the reason why this feature should be implemented. What primarily needs to be addressed? Maybe it is already covered by other options? Maybe it is not so crucial when it comes to your goal and KPI? Be alarmed when you hear such answers as “I think users might like....”, “Our competitor has this...”, or “I saw this on other websites.” 

This is the hardest part of the product design process. To decide on the priorities is very challenging for Product Owners and authors of the idea. In this stage sometimes even the coolest features that you liked and invented are dismissed. Other may get simplified. Your vision of a new, shiny and perfect product is buried. But the perfect product is a mirage, so if you want to succeed, you must forget about it. Be open to changes. Don’t stick to your ideas. Be prepared for the good and bad scenario after launch. 

To sum up

Here are rules you should follow while working with complex products:

• define your product and its key performance indicators;
• define the scope of the first release (MVP/MMP), light version of your product,
• focus on business and users goals;
• use a more agile approach: test, observe, modify, and make improvements based on the feedback and behaviour of real users;
• stick to the rule:

“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.”

Antoine de Saint-Exupéry

Keep calm and love your imperfect product! If you are looking for help with establishing MVP version of your complex product, don't hesitate to contact us. Merixstudio offers Product Discovery Workshops where we help to find the right features for the first launch.

Good luck!