Designing to solve or dissolve problems?
By: Aletheia Delivre
Tags: Systems Thinking, Public Service, Service Design, Slow Design, UX

Making problems go away through design

In a recent episode of Marc Fonteijn’s Service Design Show with Arash Golnam, the two discuss the nuances between solving problems and ‘dissolving’ them:

Design is often described as problem-solving approach. But what if you didn’t have to solve problems…What if you could let problems disappear by dissolving them?

They go on to give an example with student exams:

“Now that students can’t do regular school exams due to the pandemic, we look for ways to still do exams. That’s solving problems. Dissolving problems is about figuring out how we can achieve the same goals, without exams entirely. It might sound like a small nuance, but the impact is huge.”

Although I personally think the nuance between their definition of solving and dissolving is largely semantic — to me, finding a different way to achieve the same goals is still solving a problem—I get the spirit of the approach.

I think what Golnam is saying is that a ‘problem-solving approach’ implies that a problem exists and we need to fix it, find substitutes, add a new feature, etc.

On the other hand, a ‘problem-dissolving approach’ would be to think about a problem in a completely different frame of mind, such that the ‘problem’ almost becomes an impetus for another kind of thinking, another form of creativity.

Golnam suggests that the approach to dissolving problems starts with thinking holistically (and often backwards) about the entire system:

What skills should individuals be equipped with?

What tasks should they be able to carry out?

What’s the individual fit?

What should this experience be like?

What’s the thread that connects actors and experiences?, etc.

Humans tend to add

Like the ancient Chinese fable about the snake tails, Golnam’s take on dissolving problems reminded me of Gabrielle Adams’ team’s work on design psychology. Their work on behavioural psychology and design was recently published in Nature, appropriately entitled, Less is More.

Adams’ team asked participants to suggest changes to something: a Lego set-up, a geometric design, an essay, or even a travel itinerary.

When asked how they would strengthen the upper platform of this Lego assembly, most people wanted to add new columns instead of simply removing the existing column:

The researchers note:

For most people, their first inclination is to grab some extra Legos and add three more bricks under the platform. About 60% of people pursue that solution under normal conditions. If you don’t jump to that additive conclusion, though, you may recognize that you could instead remove the existing support. The platform drops down and sits flush on the base below, still with enough clearance for Lego Guy. The subtractive solution is more efficient, but you only notice it if you don’t jump to an additive conclusion.

Their work illustrates how when solving problems, humans tend to think about adding something before they think of taking something away — even when subtracting is the better solution.

Feature creep

In the product design world, the human tendency to add ever newer, ever shinier features translates into feature creep.

Feature creep: as the number of features goes into excess, the user’s experience is actually negatively impacted.

In talking about winning formulas for product teams, Linda Zhang from Product Lessons illustrates that feature creep is not only unnecessary from a product standpoint, but also bad for business:

Simple is deceptively hard. Simple requires an opinion of what matters most, and the focus to stay that way. Simple spreads faster because it’s easier to explain. Yet most of us do the complete opposite. The mantra of most product teams is to add more features in the pursuit of growth. But every new feature adds a little more complexity — and enough complexity over time kills two crucial things: 1) customer engagement and 2) pace of execution. It’s death by a thousand silent cuts.

The result of feature creep is an experience that is more feature-led than user-centred. (Like in the above Chinese fable story, a snake with additional legs and tails.)

Greater volume at the cost of connectedness

At scale in management, this ‘add-first’ tendency also has an equivalent, which Gerry McGovern calls the ‘cult of volume’:

Everyone wants to produce. Nobody wants to service and maintain. If you’re a new manager you must do something new. You must initiate new projects. You must produce. You must produce... In 99 out of 100 conversations I have about digital, management only cares about volume. More. More. More. New. New. New. Innovative. Innovative. Innovative.

Adding new things without thoughtful, adequate consideration to the existing parts of the system often results in greater volume, but a loss of sense or connectedness among the things created.

For example:

A well-designed house mustn’t leave dwellers feeling as though they live merely in an endless series of rooms.

A meaningful educational experience shouldn’t leave students equating learning to a set of summative assessments.

A service is not just a series of endless touch points with customer service agents at the kiosk.

Slow down and contextualize

As designers, we can do better. Design is hardly binary, but there’s certainly room to move away from our collective tendency to do additive design by default.

According to Golnam, the antidote seems simple enough (albeit not always easy to execute): start designing things and experiences by first stepping back to consider them in their rightful context.

Of course, designing for context isn’t a new topic: many designers have written about it and continue to consider it both challenging yet important. Saarinen is quoted in almost any article or book that talks about designing for context:

Always design a thing by considering it in its next larger context. A chair in a room, a room in a house, a house in an environment, an environment in a city plan. — Eliel Saarinen

But we don’t often make space for, or recognize, the sacrifice of designing for context: it’s slower (at least, at first).

The mere act of taking the time and resources to properly consider a thing in its context can be an act of mental resistance in a production-driven environment. Much like the principles of slow design, considering things in their context makes us reflect, engage, participate… We slow down.

Oftentimes, this shift in pace is necessary to move our default mindset from feature-first to value-first.

Going from “What can I add?” to “What can I fix?”

The slow approach might sound crazy to the typical startup mentality. But it is especially relevant in high-complexity contexts, like the public service where complex political, environmental and organizational structures abound.

When Dana Chisnell’s team interviewed new people on their transition from the private sector to working for the U.S. federal government, they observed a shift in employees’ attitudes towards valuing ‘slow’ and ‘small’:

Everyone acknowledged that they went into government to improve government services quickly, hoping and expecting to implement change at the speed of Silicon Valley. But the overriding observation from all was that change happens slowly, in small increments. Often for good reasons. When interviewees realized this, they shifted their thinking and their strategy. In some cases, the significant achievements — the things our interviewees were proud of — were either quite small or not visible to the public. Often, the achievements were in the service of setting up a larger program for long term progress. Interviewees had made stepwise improvements, or established infrastructure or frameworks for the next person or a government partner to move the project forward. As others have described, the work is much more like a relay than a sprint or a marathon.

In her “lessons learned” summary, Chisnell writes:

Don’t rush it. Don’t expect to transform an organization in a short tour of duty. Government operates slowly for good reasons. “Fail fast” is irresponsible in this environment. You’re there to move carefully and fix things.

Photo by 胡 卓亨 on Unsplash

For every temptation to add another ‘tail’ or ‘leg’, let’s ask ourselves: is more really more?

We can learn to move from “What should I add to make this design better?” to “Is there some friction I can smooth out? What can I fix in the existing system to make it better?”

By thinking more intentionally about our design approach in this way, we start to have a different view on the scope and nature of the problems we’re tackling. We might even help dissolve them.