Evolving the Complex Customer Experience

In the beginning websites had one thing to do and they needed to do it well. Whether it be selling the latest pair of shoes to a fashion conscious 20 something, or letting someone book a European flight from Bristol to Barcelona. With these single-minded user journeys the processes that grew up in the digital world work well. Design, test, build and deploy. Then optimise with more testing.

In the landscape of possible solutions this approach is pretty much guaranteed to get you to the top of the mountain in shortest amount of time. Efficient optimisation.

The game has changed.

It started innocently enough. The on-line fashion retailer wants to become a destination. Mixing editorial fashion news in with the product offerings. The airline wants to tackle those who just want a deal, not knowing exactly where or when they want to go.

To start with the solution is simple. Create distinct areas of the site for each specific user journey. When a customer needs to shop, send them directly to the shop. When they want to browse the news then they go to the news section. When a customer wants a flight from A to B then use the search tool. If they want to browse around go to the interactive map experience. Great our methods of optimisation continue to work as the two user journeys are independent. When you examine each user journey in isolation your old methods for optimising the experience do still appear to work.

However when you look at the bigger picture you can see something isn’t right. Customers are people after all and people don’t like being put in boxes. Someone reading an article on Rihanna wearing fuchsia will want to go buy something in fushsia. The customers who hits the site with a definite idea of where to go, change their mind and want to be inspired. The new customer journeys are interdependent. Changing one will have an effect on the other and visa versa. Chances are you won’t even have just two journeys to consider.

Science has a word for systems that have a high degree of interdependence. Complexity. Solving problems when things get complex is not straight forward. Just look at the weather. That’s an interdependent system with each weather system both effecting others and being effected by others. Even with massive super computers we can only make short-term predictions about the weather. The same goes for these complex customer experiences.

There is one strategy that works well with this kind of complexity. Evolution. Life has been dealing with the problem of complexity by letting solutions emerge. How do we apply evolution to a highly interdependent customer experience?

As with evolution the answer lies in building blocks. Small components that can be rapidly combined. Allowing the high-level customer experience to be tested in the wild. Winning combinations of components get to fight another day. The winners get combined and mutated slightly before being tested again. While each component will need designing and building. The cost of combining the components on the page needs to be low. Only then will the next generation of complex customer experiences emerge.

A Tale of Two Architects

Ever got caught up in a debate about up front architecture versus evolutionary architecture? I know I have, but which is right? I believe it all depends on the business context and the information you have available.

I my mind both approaches are valid, just generally not on the same set of problems. Deciding which architectural approach to take should be considered seriously, and if you’re not having a long hard think about which approach to take, you probably should be.

This post hopes to equip you with some basic ideas to have a meaningful conversation about how you should approach your project from an architectural point of view: whether it’s the design it before you code it approach, or quickly start on the implementation and use learning to feedback on the direction you should be heading.

I’m going to split the approaches to architecture into the following two broad types:

Architecture Approach A

The first approach to architecture involves a lot of planning and discussion and a general effort to deeply understand the problem and map out the system up front. Typically there will be a person or delegation of people responsible for the architecture as a primary role. A separate team responsible for software implementation will build against the architectural vision. It will generally involve lot of meetings and documentation.

Architecture Approach B

The second approach is to transfer the responsibility of architecture to the implementation team and allow them to grow the architecture organically based on the continued learning and insight gained during the build and feedback from stakeholders as they see the software evolve.

The Winning Architectural Approach

I believe both approaches will get there in the end with a determined team (so by simply delivering a project using an approach, you don’t necessarily have proof about whether the choice was right, only that you have a good team), however, I think there are clear cases when one approach is better than the other.

The Architect Who Faces Certainty

An architect that faces certainty usually works in a business whose landscape is unlikely to change and with users and customers that have clear expectations and have requirements that are highly predictable. This is a clear choice for Architectural Approach A – the Certain Approach.

The Architect Who Faces Uncertainty

An architect that faces uncertainty will work in a business environment with a volatile market and whimsical users/customers whose needs are unpredictable. This is a clear choice for Architectural Approach B – the Uncertain Approach.

The Future of Architecture

Choosing the right architectural approach really depends on how much information you have about the future. If you have certainty, making all your decisions up front will get your project where it needs to be efficiently as everything can be mapped out. If you do not have certainty, you need an evolutionary approach to architecture based on gathering the information you need for the next set of decisions. Typically information is gathered by implementing part of your architecture and extracting insight from real results.

If the time taken to plan is spiralling out of control and conversations involve a lot of “what if this happened in the future” and you are hedging your design against uncertainty you are probably trying to up front plan against uncertainty – a sure sign you need to rethink your approach.

Another way of looking at the two approaches is from a scientific point of view. When trying to model something we understand it’s easy to come up with sound model. When modelling something we don’t understand, we must experiment in order to piece the model together.

As computing power continues to increase, and software tools become more powerful, it’s becoming harder and harder to model the systems that our tools are capable of building and predict how users/customers will use them. Companies should be comfortable with both architectural approaches to ensure the best chance of success developing software.

Designing software at the start of a project in a certain world is well understood, and I don’t think there is much more to teach anyone about how to do it well. Evolutionary architecture is a seldom discussed topic in software literature and their are similar sounding labels for other ideas. To feel your way through a project implementing the right parts at the right time to get the right feedback is tough and ultimately an art form with much scope for new thought but already used with great success. I believe it is vital to invest time in exploring the benefits that evolutionary architecture can bring to delivering large scale customer facing web platforms that inherently have many unknowns without being paralysed by the fear of implementation without certainty.

Whatever you decide, uncertainty will be your guide 🙂