Working with Incomplete Information
It’s what designers do best
Lately, I’ve been thinking a lot about what makes design truly different from other disciplines. As the tech industry continues to evolve and the various roles in digital product development continue to blur, design has become more of a shared practice.
So what do we designers do that’s so special?
If you’re a designer, you probably already know what you do (or at least have a decent understanding of what you do).
We listen, reflect, hypothesize, experiment, sketch, iterate, prototype, refine, build, scrutinize, test, disassemble, reassemble, and present the best version of whatever we’re creating.
But what do all of these activities have in common? What makes design such a specialty?
In many of these stages, we’re working with incomplete information. Designers aren’t the only practitioners working with fragments of data. However, I would argue that we’re one of the few professions that build artifacts in response. It’s a skill we’ve built by taking on ambiguous projects as students and the technique we continually hone as professionals by developing specific product features.
Working with what could be, what might be, and what we don’t know is what designers do best.
A (Very) Brief Overview of the Design Process
At a high-level, I believe that most all design activities try to do at least one of the following three things:
- Respond to a problem
- Answer a prompt
- Express an idea
In the case of designing product experiences for technology, I believe design is about responding to a problem or a set of problems. The design process gets complicated very quickly because of the systemic nature of any experience (more on that here).
With that said, I believe that there is no one way of approaching a design problem. In general, designers in the tech industry typically employ a standard outline that looks something like this:
Definition > Investigation > Ideation > Execution > Delivery > QA
However, we typically need to adjust our approach for each project. Why is that? Let’s look a little deeper.
Missing Pieces in the Design Process
Fully understanding a problem in a product space includes identifying constraints, understanding audiences, and adhering to budgets and timelines. And of course, designers need to partner with cross-functional peers to execute on a vision. The design process becomes difficult when any of these areas fail to (or are unable to at the time) provide adequate information.
Let’s look at a few examples of failure and how they affect the process:
- Unclear technical constraints
The design work could assume new features without having the engineering resources or necessary systems to implement it. Not a good situation for any team. - Lack of audience research
People make decisions based on their values, and we need to pay attention to what they’re saying at a deeper level. Otherwise, our product risks failing in the market. - Short timelines and/or small budgets
Needing to move quickly and efficiently is important, but it can also cause people to step on toes and miscommunicate. This can cause friction amongst various partners and stakeholders.
Each scenario presents challenges to how designers work. And yet, each of these scenarios have happened to me or I’ve witnessed them happening to other designers. In fact, they’re fairly commonplace.
So how can designers be successful if they don’t have all of the elements of a project that they need? We need to learn to work with incomplete information.
Incomplete Information
One of my favorite philosophies of the mind is Gestalt psychology. This area of study deals with how the human brain organizes information to form whole systems out of separate parts. The principles relate to how we perceive visual elements, but I believe some of the ideas relate to working with problems as well.
Gestalt psychologist Kurt Koffka is known for this famous quote:
“The whole is other than the sum of the parts.”
It’s important to note the word ‘other’ used in that quote. It’s not ‘greater than’ but specifically ‘other.’
In the context of the design process, the whole (problem) is actually made up of varying parts (smaller problems) that can act independently on their own. This idea doesn’t fall perfectly under systems theory, but it does explain how we have to see things as smaller, autonomous parts instead of one large item.
Similarly, designers can view constraints, audiences, budgets, timelines, etc. as pieces that are individual on their own, but together form a broader problem context.
How Designers Deconstruct Problems
When we see a problem, our first instinct is to address it with our initial idea. However, the smarter idea is to deconstruct the problem into smaller pieces so we can understand it better.
One critical note: designers don’t typically go about this deconstruction process by ourselves. We rely on other practitioners—Researchers, Product Managers, Data Scientists, Engineers, and others—to bring specific insights and help each other see different parts of the problem.
For instance, Engineers might address the technical constraints or predict integration issues. Researchers can conduct qualitative studies to understand the values in play (generative) or carry out usability testing to assess product fit (evaluative). Data Scientists can provide meaningful insights from a variety of inputs and outputs. Product Managers can organize and synthesize these data points to formulate business cases for each aspect of the feature.
Designers should be in communication with each partner, collaborating to develop problem statements, goals, and timelines. It’s also a beneficial exercise for designers to organize brainstorming and strategy sessions with these partners to include their opinions and bring varying viewpoints to the table.
No matter how big or how small, the problem needs to be deconstructed, divided, and organized into pieces so each function of the team can relate to the larger problem and goal.
How Designers Piece it Together
So when we see the problem as smaller, individual pieces, that’s when Gestalt principles come into play.
If we’re missing research for a specific audience segment, we might try to piece it together by using a heuristic or even running a quick hallway study (i.e. Law of Closure, Law of Similarity). Or, if we’re lacking the resources to build out a new component, we might borrow from other system patterns to form a similar interaction (i.e. Law of Proximity). These techniques won’t create a perfect whole, but they will help us see the picture more clearly.
Designers can use these methods at all levels. They work at a high-level when we provide strategy for a feature launches into a new market segment (i.e. audience narratives or vision videos), or even in the details of how a toggle might play out as a new pattern in the interface (i.e. rough sketches, mockups, or prototypes). They’re quick and easy ways of visualizing those missing links and engaging the team with the problem.
The Picture is Never Complete
By putting something in front of stakeholders, designers have created an artifact that others can react to. The artifact may not be the right response, but it is a response nonetheless.
From this point, we gather feedback, we test, we iterate, and we refine. And ideally, designers will go through all of it right alongside our cross-functional peers. It’s a team effort.
And when we finally ship our product update or new feature, we know it’s not truly done. Design may seem linear, but more often than not, design is a cyclical practice that continues on with the life of the product. Once we get feedback from a greater number of people in various contexts, we’ll once again need to figure out where we can improve the experience.
The product we’ve designed won’t be perfect. It will have gaps and missing pieces. But we’re okay with this reality… working with incomplete information is what we do best.
