Design should be human centred, but it’s business centred
The business model underlying the design industry frames its practice into a business centred one
Very often we pride ourselves in being human centred designers, implying we’re designing for humans. Truth to be told, we’re business centred designers, human compliant designers at best. This is a major blocker if we want to foster the radical changes needed to mitigate the climate emergency and live in a just society as much as we say we do.
Within the current industry set-up, we can only enable incremental changes, not radical ones. By only designing increments, we’re not solving problems but are displacing them further down the line. For instance, electric vehicles are set to replace fuel powered ones, but we don’t question how electricity is produced, how batteries are made nor how to recycle these, microparticles emissions due to tires & breaking, or the space used by personal vehicles in cities. Similarly with “decentralised finance” even though it doesn’t really solve any problem (human ones at least): it isn’t decentralised nor it removes the hurtful speculative aspect of finance.
The reason for that is, I believe, as designers we are so embedded within businesses, embracing a similar mindset, that we can’t propose alternatives. Worse than that, the whole design industry is geared to solve businesses’ problems, reinforcing the status quo, such as designing frictionless experience for fast fashion companies, unless it starts to impact the bottom line.
[Buying hundreds of dollars of outfits that never get worn at all] is a trend that analysts say is fueled by a social media culture […], as well as an industry that has made impulse buying and returning items far easier.”
Kristoffer Tigue’s Gen Z Has a Fast Fashion Problem. That’s Bad for the Climate and Equity
Recently I published a post saying design is about facilitation, not about creation. Adopting a facilitator mindset is to me the key to unlock meaningful, sustainable, inclusive, progress oriented change through design. To do that, we first need to embrace the intangibility and messiness inherent to the world we design within, by getting out of the tangibility trap.
Caught in a tangibility trap
Let me start with a story. The restaurant I used to work at when studying in Paris got sold one day. One of the first things the new owner did was to fire the director, let’s call her Jeanne, because they found she was paid too much and they wanted to reduce fixed costs. Slowly the restaurant lost some customers, then even more, until only a few passer-by dared to walk in an empty restaurant. Eventually the owner sold the place at a loss soon after.
It turns out that Jeanne was really great at creating an amazing experience for the customers. She was always on the hunt for furniture bargains and antique glassware, she was curating playlists, she was great at customer relationships, and amazing at driving the team, to name a few. All of the above were making the restaurant a vibrant space where people enjoyed spending time, both customers & employees. Her salary was a reflection of the value she brought to the restaurant as an individual, but they only saw the cost.
This is what I mean when I’m talking about the tangibility trap in business. This mindset now infects the design industry and affects the design practice. As design gets more and more institutionalised, becoming a strategic tool for business growth, design agencies and practitioners are adapting their ways of working to fit business requirements, getting caught in the same tangibility trap that ramps through business.
Such a mindset prevents designers from solving problems that matter to foster the change needed to cope with the current ecological and social crisis, as it frames the design practice. It affects the practice in 3 ways: it artificially scopes down projects, it focuses success into measurements, not what matters, and it pushes to scale solutions instead of outcomes.
1-Bringing down project’s scope and team’s capabilities
Most design agencies are using a people/hour model. Meaning the cost of the project is based on the number of people, their seniority and the number of hours each will spend on said project. This is a very simple, manageable model. However, this business model poses a lot of problems:
It reduces the scope to fit the envelope
First, it artificially brings project’s scope down and looks at shortening project length or the number of people resourced on it. The client tries to stay in an envelope and bring the cost down, it results in a shorter project, so the team will either work late in the evening for free, or cut corners by deprioritising things they would have spent more time on instead. Indexing a project’s cost on time basically means “do it as fast as possible” as clients look to get the highest return on investment (ROI).
The issue in this situation is that we know the cost of the project but we can only estimate the value it’ll generate, the ROI. Which brings us to the tangibility bias: to increase ROI, clients will try to reduce upfront costs, even if it means lower potential returns on investments, to reduce risks.
It requires projects to be scoped around outputs, not outcomes
We don’t know how much time we need to enable a ROI of 35% for instance, but we know how much time we need more or less to deliver a new website, a new app, or a new service. As we’re selling people by the time, we want to have a clear vision of how much time people will spend on the project.
As a result we become delivery oriented, scoping to deliver new apps, new websites, loyalty programs, but also just artefacts that are only tools, like blueprints, personas, or even workshops. We start to isolate what we’re producing from the impact we want to generate.
It trims down teams to bare minimum
This business model is a key blocker to cross functional teams. Why would you bill an engineer during the design phase? Worst, during the scoping phase? The project team gets streamlined to the bare minimum depending on the project’s step. It creates two problems: we’re sequencing the project in small chunks, instead of having people to see the big picture, and we end up in an homogenous team.
Let’s take a project scoped around a new website as an example. It’ll start with the front end design team. They’ll conduct research, come up with concepts, test & refine concepts, design the website, test & iterate, and finally deliver it to the tech team to build. The tech team’s brief isn’t the same as the design team’s, their brief is to build the website designed by the design team. Some things aren’t feasible and will need to be changed, hopefully a designer will still be on the project. But most importantly, let’s say the objective of the new website is to have the lowest footprint possible, the design and tech team need to work together, for the design team to understand the backend impact of the front end decisions they’ll take, and vice versa.
Additionally, designers think like designers, engineers like engineers, salespeople like salespeople, and so on and so forth. Teams kept to the bare minimum will prevent cross thinking, having only people with a similar way of thinking to work together.
This is especially true and even more of a threat as the industry requires people to specialise. We end up replicating what we already know, designing like we ride a bike, without applying knowledge we might have gained from other contexts.
We end-up delivering similar products and services, in different boxes
When scoping the project and how much time we believe we need, we’re making assumptions with limited information about the reality of the project. So we’re looking at similar projects and we duplicate the set-up. If an initial project to deliver a new website was 3 months with 2 designers on it, then when answering a new brief it’s very likely that it’s going to be 3 months with 2 designers on it. Additionally, echoing my last point, we’ll staff people who have experience on said topic, who’ll look at the project the same way. They’ll work faster, for sure, but they won’t change the game either. Sometimes looking at something with fresh eyes is what’s needed.
In the end, for the sake of clarity and sellability, we’re productising design methods. Like Google sprints or design thinking tool boxes. However, those are just tools, and we can’t expect change to happen from a tool, it’s about when and how we use methodologies, frameworks and toolsets.
2- It changes the focus from what matters to what can be measured
We’re focusing on things that can be measured, regardless of how representative they are from reality. A good example of that are success measurements such as GDP for countries, or NPS for service relevance, which are indications of some success, but do they measure what matters?
Let’s take the example of GDP: As a result of the Notre Dame Cathedral in Paris burning, it needs to be restored. The restoration makes companies work and generate revenue, so the GDP grows. The question is, is the Cathedral burning something we wish for? Similarly, Amazon has a constant year on year growth, yet the conditions of work are excruciable, without even talking about the impact on the planet. Again, does it seem like a success?
Metrics are biassed, even though we never only use one metric to measure the success of a project. Measurements often tell only one side of the story, without mentioning how choosing metrics can get political. We need to rethink what we’re delivering, to deliver outcomes and not outputs.
As we’re designing for numbers, we’re not designing for humans. We’re currently designing for Sales, ROI, P&L, NPS. This leads to business cases about the market value of designing inclusive and accessible services and products. We’re not talking about values or outcomes, we’re talking about market value. To be inclusive. We need to make a money argument to design for people, and we call our practice human centred?
“If the business is functioning, according to the metrics it set for itself, you can’t change that, because what a lot of organizations are doing is shareholder-centered design. And if the shareholders are happy, that’s the only metric that matters in a business, ultimately.”
Erika Hall in Finding Our Way 27/10/2020
That’s just the tip of the iceberg. Let’s take WCAG for instance. Standing for Web Content Accessibility Guidelines (WCAG), is an international standard validated by ISO, operating as a checklist for companies to show they’ve done their due diligence to deliver an accessible product. It’s a compliance framework, a legal checkbox to not be sued, not an approach to inclusive and accessible design. So it measures colour contrast ratio, checks for accessible images with alt text, etc. In short, it’s a checklist of things to measure. However, being compliant and being accessible are very different, as Sarah Blahovec explains it well in this twitter thread.
Accessibility and inclusivity are not measurements, they are approaches to the way you’ll design. You’ll likely get some stuff wrong; However, you can do research that includes people with different backgrounds, experiences and requirements, you can listen to their experience and integrate these insights to design solutions that’ll be coherent with their behaviours and requirements, additionally you can strive for a more diverse team.
All of these take effort, but inclusive design is in the approach, not in the compliance guidelines. If you want to learn more about how to design accessible products and services, the A11Y project is a good place to start. It focuses on principles, not measurements.
If we want to design for people, we need to think like a person, not like a business. Put it differently, people are either hungry, very hungry, or not hungry, but they’re not 250gr of food hungry. Yes, it includes some grey areas, it’s ambiguous and a harder task, but it’s one that fits reality. So if we want to stop world hunger, it’s not by saying we want people to have 250gr of food, but by saying “we don’t want people to be hungry”. We’re confusing measurements and problem solving just like we’re confusing innovation and progress. Which leads me to my last point, we’re scaling the solution, not the outcome.
3- We’re scaling the wrong things
Caught in a tangibility trap, we’re scaling what’s tangible only. This means we’re scaling the product and service we’re designing, the solutions. Again that’s convenient from a business point of view: it helps them to increase ROI through economies of scales. However, this is a skewed vision of reality. There’s a reasonable case to analyse the world around us as something made of processes, not something made of objects. It echoes my last post about design being about facilitation, not about creation.
Let’s take a very practical example: doing the dishes. To clean a pan you’ll usually use a sponge, hot water and some soap. So cleaning the pan is the addition of 3 forces: mechanical (the sponge scratches), physical (the hot water softens) and chemical (the soap dissolves).
If we only use the sponge, it’ll destabilise the system: the pan will be used quicker and we’ll need more effort to clean it. If we only use hot water, we’ll use the resource extensively, creating hydric stress at scale and using a lot of energy to warm it. If we only use the soap, we’ll have too much soap in the wastewater and it’ll be harder to clean it, plus we’ll use too much of it, and it’s very unlikely that the pan will be soap less if we don’t rinse it.
The issue is that companies are not organised around getting the pan clean, they’re organised around selling water, selling soaps, selling sponges. So when we’re looking at scaling, we often look at scaling a solution, not an outcome.
This is what happens with electric vehicles as an alternative to combustible powered cars, for example. We’re destabilising systems by focusing on scaling a solution such as electric vehicles, not an outcome such as decarbonised mobility. This strains the different systems coming in contact with electric vehicles: minerals digging, battery waste, energy consumption, etc. Ultimately, we’re replicating the fossil fueled mobility geopolitical, economical and social paradigms, only with a new token.
Designers don’t know the solutions to problems, but they know how to solve them
The design industry isn’t geared up to solve problems, it’s geared up to deliver specific solutions. It frames the design practice. Practitioners are not facilitators, they’re creators on an assembly line, delivering outputs solving people’s problems only in the light of business problems. As Erika Hall puts it, the business model is the new grid that design snaps to. With this in mind, no wonder why industrial design, and to the same extent service and experience design, are one of the most harmful professions.
We have to change the way we operate so we can embrace the intangibility & messiness inherent to our role, to become facilitators. I believe the good way to start is by addressing the following:
•Change the business model we operate with
People per hour only fosters a dynamic where clients want designers to spend the least time possible on the project to reduce costs. As if it was going to improve ROI because there’s less investment. It only pushes designers (and agencies who want to make a profit on the project) to replicate similar projects, to try to cut corners to save time. As an alternative we can look at a shared equity model, a flat fee for upfront costs coupled to a percentage of the value generated, or a “retainer scheme” where clients pay a % of their revenue, just like they do for B Corp.
•Scope around outcomes, not outputs, at least scope around a problem
As facilitators, the first question we need to ask ourselves is about “what do we want to enable”. While we can deliver a new app, a new service, or just optimise processes in the backend, we’re doing so to enable something. It makes little to no sense to decide we’re going to deliver a new website without knowing what we want to enable first. Having a clear vision of the outcomes we’re set to deliver is key if we want to build something that has value to everyone.
•Mix practices
Design encapsulates lots of practices. Mix them. From design thinking to speculative design to participatory design, to future design. There are many ways one can approach a project. While in every project a method will dominate because of its relevance to the context, using multiple methods can be beneficial to just look at it from a different angle. The goal is really to just ask “what if” and be critical about what we’re doing, but also to look at it from many angles. Again, a practice isn’t just a set of tools or processes, it’s an approach, a mindset.
•Be inclusive & cross functional
Similarly to mixing methods, mixing teams helps in building a more holistic view of the project and what it entitles, by multiplying the point of views and experiences. Such a practice will help in asking questions early, making sure you consider different ins and outs, challenging briefs, but also to get the whole team on the same page, looking in the same direction, and using their varied skills to build the shared vision.
•Get your work reviewed, organise design crits
Design crits are a good way to get the work internally reviewed, to have people challenge it, to give space to ask “what if”, to give space to have different point of views to look at it. Again, after spending 3, 6,or even 24 months on a project, it’s important to look at something with fresh eyes. Design crits can be the space to do so.
•Get comfortable not knowing and not understanding
It starts with us. We can’t change the industry if we’re caught up in our ego. As designers, we don’t know what will be the solution when taking a brief onboard, but we know how to find ways to solve the problem. If we are caught in delivering a solution or we are incapable of saying “I don’t know yet, but here’s how I think we should start to find that out” then we’re just part of the problem.
•Train leadership in design Recommended by Mauricio Mejía, added 5/6/22
Often, decisions makers are managers not trained in design. Having them to at least understand the principles and the logic behind design would help in supporting design recommendations. Additionally, it’d help in developing a design mindset that’s about creating a holistic understanding of the situation, rather than them thinking only as managers looking for quick ROI.
