Loving questions in design

Maria Rilke wrote “Do not try to find the answers to questions that you can’t answer yet. Love the questions themselves“. Rilke didn’t write about anything even close to digital product and yet it seems to neatly sum up designer’s mindset. It surely is a wonderful motto of life that can spare us of anxiety to know all the answers straight at a given point and focus on what is important.

And it is the question and enthusiasm to explore it that is important in design and life. In practical design, loving the question is about focusing on why’s and why they matter before rushing to solutions. This mindset is hard-wired into frameworks such as Design Thinking and Lean, where design is perceived as a method of critical thinking and doing. In Speculative everything (2013, MIT) describing design as critique Anthony Dunne and Fiona Raby wrote,

While this passage is about speculative design which operates in another spectrum of objectives compared to applied design, design and designers play a role of a thought catalyst in any environment. We should let the questions guide the process.

Role of design

To understand question-first mindset we shall define the role and domain of design first.

Design is a holistic practice that guides both problem-framing and problem-solving.

Yves Behar described design using in seven points, the step on his list “Start my asking questions to put a problem in its context”. Interaction Design foundation writers describe user experience design as a practice where “designers try to work with a better grasp of all the human [we can also add societal – S.P.] dimensions that are involved between users and a particular design.” Since the matter in question is entire complexity of human and societal dimensions only a holistic practice can address their needs.

In product development, loving the question matters the most in discovery (problem) and testing (solution). A lot has been said about importance to spot the right problem. In a nutshell, the main idea behind it is that even the most brilliant solution is irrelevant if it solves an irrelevant. A product and platform exist in a paradigm of Useful – Usable – Used: take one of these out and the platform will vanish. And it is a role of designer (together with product owner and their technical peers) to define both problem and solution.

Apart from problem-framing and problem-solving, today’s designers also design pathways to validate their assumptions and prototypes, where validation is essential on both stages.

This is why we thrive on question-first approach and should let questions guide the process. Before moving on, we should also address a common misconception about design. A misconception that sets design apart from the rest of the team and limits it to aesthetics while UX design is a very technical and a fact based discipline.

Design is not about making things beautiful, it is about the beauty of thought, logic and informed decisions behind the product, service or experience.

Questions in problem-framing

Whether your peers can stand up by this statement depends on the level of UX maturity in the organisation. There are many UX maturity models such as NN Group model. I find it useful to describe it in terms of assumptions a team makes about a challenge and how these assumptions are articulated. The moment design explores questions that surround the context our reasoning about the problem changes to fact-based: “Researched showed that we can project 25% adoption of this feature among our target users”.

In the beginning of discovery process I like to assume a very Socratic position. In discovery and beyond, I admit that I know nothing. That often makes a designer the most annoying person in the room. As Dan Brown writes (Practical design discovery, 2011),

Discovery is hard, because the first step in any process is hard. Embracing the discovery mindset means putting yourself in a vulnerable position. You’re actively admitting that you don’t know enough to solve the problem—that’s challenging for anyone.

In order not to end up on trial for educating everyone for no good reason and being a (not)know-it-al like Socrates, it is important to communicate this mindset to the peers in the way that it’s clear where we come from. Otherwise the intention of making informed decisions will be misinterpreted for disregarding ideas and not respecting team’s opinion. Socrates allegedly failed his trial because he choose to protect the integrity of his school of thought, something he devotedly believed in, rather than defend himself against allegations. The most was sentenced to death by drinking poison. No designer who loves the question should be hurt in the process.

To define a problem we need to shower ourselves and our audience with questions, give ourselves an opportunity to think of alternatives and test them.

“Whenever a theory appears to you as the only possible one, take this as a sign that you have neither understood the theory nor the problem which it was intended to solve.”

– Karl Popper

Questions in problem-solving

After the problem was formulated and agreed on, designers move to prototyping solutions. As it was mentioned before, we do not only design a solution but a pathway to validate it. In practical terms it means designing a survey, test, mind map, interview script, group workshop and such.

Two analogies from communication and philosophy can help to illustrate the importance of testing in problem-solving.

In communication theory*, Interactional model (Schramm’s model) describes communication as a constant exchange of an encoded message that needs to be coded by the sender and decoded by a receiver.

Schramm model on Interactive communication is used in internet and social media communication that enables reaction, or messages, from both parties.

*One of the first theories of communication is a Linear model by Shannon and Weaver is typically criticised for the lack on exchange between the parties: even if it accounts for feedback.

Whichever communication theory one prefers what is interesting for us here, in terms of solution finding, is encoding and decoding of messages or symbols. Essentially, when we test our prototypes we are making sure that our encoded system can be accurately decoded by the user. Instead of oral language as a common ground we rely on mental models and a shared understanding of symbols and flows. Designer’s genius is to make sure that the code is properly understood and based on a shared understanding.

A very common and a rather corrupt assumption is that we understand decoding principles of our receivers, users, because we can reason on their behalf through meticulous analysis of our own design. Whenever this assumption comes from – the fact that designer is close to users in age, field, interests, experience or anything else – most interfaces and flows need to be tested because a rare user is our soulmate that can finish our sentences. A designer always designs from their point of view where user lives very nominally. From my personal experience, anytime we test something comes up: sometimes these are minor flaws that make experience less delightful and sometimes these shortcomings are catastrophic for adoption. I have known teams that even follow a radical rule that if testing returns all-positive results something is off.

It is the gap between Real world, or in more modern terms – Mental models, and Computer (The platform in case of a service), that we need to close through testing and improvements.

Some parallels from philosophy and art come to mind. The first one is Roland Barthes’s work on author, text and the reader and his famous essays “Death of the Author” and “From work to text”. If we apply it to design and take it as a direction rather than an observation of the phenomena we can reformulate it as – design process should destroy every point of origin to become a “text” that is open to interaction that every product implies. Death of the designer, if you will.

Marcel Duchamp famously noted that “art is completed by the viewer”. Rephrasing it in design terms we can say that design is completed by the user. In fact, we can take it as far as saying that design doesn’t exist without a user.

Our prototypes only become alive when they meet the users and not when they sit in Figma files or in functional specs. Anything that was created before this encounter is a speculation.