Jungling inputs and outputs is what design realy is all about — Image courtesy of Gawler History on Flickr

Whenever designers design, they embed their designs within systems: they connect different elements together, forming a whole. User experience is a system; it’s a set of products and services working together to form a solution.

Products and services have always been intertwined with one-another: a bad dealership, repair shop network or warranty cover negatively impacts the sales of a good car, and vice versa. However, what has changed is how much different systems are even more tightly bound together as a result of the digitisation of our economy.

Indeed, it’s almost impossible to separate services and products from each other, they are intertwined: people buy an iPhone (product) to access social media (service) through apps (products) from anywhere thanks to telecommunication providers (services) who harness a network of towers and cables (products) that supports the web (service), while all parts are increasingly facilitated by a seemingly ever growing number of third parties.

This means that as designers we design in an increasingly complex context, fragmented but intertwined. As we design for an increasingly complex system we need to rethink our approach to design.

Today, we tend to design for the problem at hand only, focusing on delivering solutions, not solving problems. To me, this approach leads to a failure in considering the impacts of what we’re designing outside of the scope of work, let alone mitigating them.

There are numerous critics of the design practice calling for different design practices to be employed, such as systemic design, circular design, society centred design, to name but a few. They are all very relevant and I can’t stress enough the importance of them. However, I think the common thread to all of them isn’t in the practice in itself, but in the mindset we approach design with as an activity.

We need to rethink design as a facilitation practice, not as a creation practice, a practice that focuses on enabling, not disrupting. But first, I need to talk about the contexts in which we operate as designers.

Designing is embedding systems within systems

Without realising it, our work is about designing systems and embedding them within other systems. What changes is the scale of the project’s scope and therefore how designers look at it.

A website is a system, it’s a set of different components working together to facilitate interactions, themselves working together to deliver features which all work under one product: the website. When we’re designing a website, let’s say an e-commerce website, we embed it within a direct service: online shopping.

If we zoom out even further, we can see that the service itself is a system. An online shopping service connects different elements together such as the website, the warehouse, the last mile logistics, the payment system, etc. to form a whole.

At an absolute abstract level, there’s the user experience. The user experience is made up of different services, such as online shopping, in store shopping, the repair service, as well as products, like the garment itself, the app, the website, the packaging, etc.

Buchanan’s 4 orders of design applied to online shopping

I see it as a vertical integration of systems within systems, in which user experience will rest on a set of services, which themselves rest on a set of products, which themselves rest on a set of interactions, and so on and so forth. Richard Buchanan identified these as the 4 orders of design. However, I think there also is an horizontal integration: The artefacts we’re designing interact with other systems to operate.

Designing is using systems to power systems

If designing is about embedding systems within systems, it means systems are relying on other systems to operate. For instance, because a delivery service is made out of vehicles, delivery becomes dependent on the different systems delivery vans rely on to operate.

Designing an e-commerce requires back-end solutions that themselves need solutions to operate. When we design an e-commerce, we potentially take decisions that’ll have an effect down the line

Indeed, for a delivery van to operate, it needs to be produced in the first place. Van production is a system in itself made out of supply, assembly and delivery chains and all the resources required to build a van. On a regular basis, vans need to refuel to operate, either electric or combustible. Both forms of fuel rely on systems for a van to be able to use them: they need to be produced and transported to the van, to name only two. Vans will also need roads to ride on, potentially exacerbating congestion, and therefore impacting cities at scale. Vans need people to operate them, or people to design autonomous vans. These people need to be trained, need to be paid to live their lives, etc.

Designing today is designing for tightly bound systems, which rely increasingly on each other, stretching to accommodate the problem at hand. Yet, too often the design industry fails to see the interdependence of front-end decisions with their impact on systems needed to power the back-end. This also applies just as much as when thinking about the impact of back-end decisions on the systems in contact with the front-end. This is causing issues at scale, from pollution due to increased traffic to sustain deliveries to increased energy consumption to power heavier websites that users should be able to access no matter if they are on Wi-fi or 4G.

Short sighted design decisions are coming full circle and threatening our societies directly. Business models relying on attention, such as Facebook’s & Youtube’s, are increasing hatred and anxiety. This isn’t new, and it’s not just the digital revolution creating threats. Our food production model relying on intensive farming creates issues too, increasing health conditions, like gluten intolerance or endometriosis, because of production methods focusing on economies of scale and using cheaper solutions to produce food and crops.

This is where systemic design comes in handy, it allows us to understand the ramifications of the design decisions we take. It helps the team to identify who and what is going to be impacted, and potentially how. Now we’ve covered the context, let’s move into why designers should focus on facilitation.

Facilitation as the key goal of design activity

Tim Brown’s venn diagram representing Human Centred Design (HCD) in a Design Thinking approach depicts how HCD happens at the intersection of business viability, technical feasibility and human desirability. This principle of facilitation, meeting at the intersection of desirability, feasibility, and viability flows through the practice of design at all levels.

Practically speaking, facilitation is a key aspect of our role as designers: we facilitate workshops, we bring evidence to the table to inform decisions, ensuring that the relevant stakeholders of a company are heard and represented in the solution(s).

Zooming out, we’re designing solutions to facilitate interaction between users and a business, either it’s a checkout page, a signage in a supermarket to help someone find the bread, a full website or a whole service and the relevant business model.

And just like we design systems at different scales, we are facilitating at different scales: business stakeholders together, business and users interactions, but also different systems, relying and supporting each other.

Indeed, while human centred design happens at the intersection of desirability, viability and feasibility, we should not forget that they themselves are only the tip of the iceberg. Just like the marketing and e-commerce stakeholders attending the workshop are the visible part of the marketing & e-commerce departments.

This is why I like that venn diagram, it reminds me that it’s not because design happens at the intersection of feasibility, viability and desirability that each stakeholders only exist at that intersection. We therefore need to understand each stakeholder as a whole, to facilitate any interaction between them. The goal is to design for a common ground, where all stakeholders meet, not one where some stakeholders are stretched to accommodate others as it is the case in reality.

I think there are three kinds of design approaches, in reality today. The first is where users have to stretch, for instance to learn a tool rather than the tool adapting to existing behaviours, like excel spreadsheets. The second, is when the back end stretches, such as delivery services. And the final one is a fully business centred approach, where most of, if not the whole point of designing such a solution is to support business growth, such as autonomous vehicles.

The risk of centering design around the individual

Humans create the tools to solve the problem they’re facing. This is what a designer does when designing a service or a product, they look at solving the problem they have at hand. The question therefore is, what is the problem we’re solving?

The design industry often prides itself on being human centred, to design experiences that serve people, but to what end? Designers are commissioned by companies; these companies are paying the bill, scoping a project with a problem they need solved, but more often with a solution they want implemented. Because of this set-up, we tend to only solve human problems in the light of business issues, making us customer-centred designers.

This context changes the way designers look at things. We’re not asking people “what do you need to feel good/live/be healthy/study /play/etc. & how can we help?” we’re asking “what would make you use this service/website/feature?”. As Thomas Wendt puts it: we’re fitting a business centric product into a human-centric frame. By doing so, we’re biassing the conversation and ultimately designing down rabbit holes, like one leading to increasingly-fast and convenient deliveries.

Focusing only on the interaction between a service provider and an individual, risks introducing bias into the design process. It frames the definition of good, focusing on KPIs around consumption, profit, usage, NPS, time to completion, etc, but will often fail to factor issues external to the relationship between the service provider and the individual, generating “unattended consequences” too. Ultimately, design today has become a paperclip maximiser.

To cope with this, design as an activity needs to focus more on enabling outcomes and less on producing outputs. Design teams need to understand stakeholders in their own system, to understand what impacts the solutions we’re coming up with will have on them; what is the outcome we will enable, not only the output we will produce.

As we move away from the scope of work, we tend to stop looking at the implications of our decisions

This is often something we do with our business stakeholders, this is something we seldom do with the users we’re designing for, and almost never with the technical solutions we will use to power the solution we’re designing. We do understand that we might increase conversion rate, profit, reduce operating costs, etc., but what’s the impact on users and their mindset? What’s the impact on the back-end? We need to design by understanding the impact we’ll have on stakeholders, in terms of both the outputs the thing we design will generate, but also in terms of the inputs required from each stakeholder, to operate and maintain the product or service we’re designing, such as energy consumption, time and effort, number of employees.

Thoroughly understanding the impact is understanding the outputs generated and the inputs required to operate a service or produce a product

Design is about enabling outcomes by facilitating interactions, not creating outputs

Design is about facilitating decisions that’ll have an impact on the business, on the users, on the back-end, and ultimately when scaled, on all the other systems they come in contact with and rely on. As designers, we can’t responsibly facilitate these decisions if we’re unable to assess all the potential repercussions. Designers need to dig further to understand the consequences of the decisions at hand.

As designers, we need to understand each of the stakeholders as a whole, not only at their intersection. We need to understand what positive and negative outcomes will be enabled for each as a result of the inputs required from each and the outputs generated in turn.

This is why we need researchers & business analysts. This is also why cross-functional teams are so useful: it provides the right set-up for collaboration, so the back-end isn’t considered as an afterthought that needs to accommodate front-end decisions.

We need to understand the role every interaction, product, and service of the system plays for each stakeholder, whether directly involved or distantly impacted by a decision. To reuse something most designers are familiar with, we need to understand the job the thing we’re designing has to do, whether we’re designing an interaction, product or service.

To me, the priority is to reframe our approach to the practice of design as one focusing on facilitation and enablement, not on creation. Everything we’re doing is about facilitating decisions or interactions, to enable outcomes. Creating artefacts is only a by-product.