Building Software: Thoughts on Reductionism
The whole is greater than the sum of its parts. — Aristotle
Design is often looked at as an act of problem-solving. Designers dare to look out at the world of infinitely complex problems and attempt to pull out a solution from a space of infinite possibilities. I, for one, have found this an effective way to think about design. While other theories exist, rarely do any of them fit the simplicity and ease of understanding that comes with “creative problem solving”. Not only is it an easy way to think of design, but it is also a simple way to communicate what design is to someone unfamiliar with it.
It seems a bit strange to believe in a theory or a way of thinking — not because you believe in it, but because of its effectiveness. In some ways, however, I have always been one for practicality. I have always found effectiveness and practically to be very powerful.
In their widely acclaimed Book ‘Lean UX’, Jeff Gothelf and Josh Seiden talk of shifting software development to “Problem focussed teams”. Problem focussed teams, you see are more accountable towards their designs, and products (compared to feature focussed teams). Powerful theories are often simple like that but have far reaching consequences on organisations and practitioners.
In this article, instead of arguing for one theory of design over another, I want to talk about the “how” — how do designers go about solving problems and what I perceive to 2 issues in the problem-solving initiatives today.
1. Designers put on blinders
So often we designers constrain ourselves. We focus in on one issue or a part of a problem. We break things down and focus on what we “can” solve. It makes sense to do so. Many times this approach works well. We iterate and test and think we have solved that one issue. We do this because constraints work. Much of a team’s success and efficiency is attributed to the removal of distractions. Focused teams are more effective.
The problem with this approach is when those constraints are used as a means of escape — when potential issues are pushed aside simply because they do not fall into these self-imposed limitations. So often, designers push away potential issues simply, not because they don’t matter, but because it’s easier to do so. In doing so, they ignore obvious reasons why their designers would a) fail or b) never get built in the first place.
2. Designers lose sight of the big picture
The second issue with this approach is losing sight of the big picture, the whole product or service being offered.
When reading Siddhartha Mukherjee’s “The Gene” I came across an interesting parallel:
When the poet Wallace Stevens writes, “In the sum of the parts, there are only parts,” he is referring to the deep structural mystery that runs through language: you can only decipher the meaning of a sentence by deciphering every individual word — yet a sentence carries more meaning than any of the individual words. And so it is with genes. An organism is much more than its genes, of course, but to understand an organism, you must first understand its genes.
Similarly, the process of narrowing in on one part of the problem is essential to understand the problem and come up with any meaningful solution. Thats the reductionism. However, the sum of all the different parts would hold little meaning till looked at from the whole — the entire product, the users and the larger context in which they exist.
An example here would be helpful:
Let’s take 10 product designers working on a single product. With a problem/goal identified, each designer is assigned a part of the problem to focus in on. Each designer then comes up with a solution in isolation from each other and presents it at the end of the next sprint. Are all 10 problems now fixed?
I think I speak for anyone with experience in product development, that the answer would be a resounding “no”. Some possible issues that would come up:
1. Half of the solutions presented could not be implemented as is.
2. Every solution, while solving a problem, in one way might create new problems across different parts of the product.
3. Many of the designs presented would conflict with each other. You would only be able to implement one of the two.
But most importantly, would the product as a whole be better if all these solutions were implemented?
The answer would be hard to say, without looking at the product as a whole. Has the user’s experience become better? Is it technically feasible? Is it more efficient? Does it make more money? How modern product teams are organised individual designers are often separated from the big picture.
I don’t claim to have the answer to this problem. Nor do I assume there is one. However, it is something I find worth exploring. With every product, service, app, technology now part of a system bigger than itself, are we simply clinging on the ways of working that no longer make sense?
My name is Anish Nangia. I am a user experience designers and researchers, currently studying Human Computer Interaction at Indiana University.
Over the next few months, I will be looking into ‘systems thinking in design’ as a potential approach to solving some of these issues. This post is the first of a series of reflections.
I want to thank Prof. Marty Siegel, Amoli Mehta and Bhavesh Anand from their input on this article.