Most projects are not one-and-done problems. Sometimes, we are working with flows that are already well understood. The patterns exist, and the structure does not need to be reinvented. But when someone approaches us with a new product, or a new vision for an existing one, the work changes. It requires deeper thinking about why the product exists, what form it should take, and how it should serve the people using it

That is where approach notes come in.

Here’s an operative example to illustrate where approach notes appear within our process, while mapping out, for instance, a personal finance dashboard.

Thinking begins before the interface

When we receive a new project brief that requires planning at a deeper level, the first instinct is to begin digging. But that digging is rarely linear. Research often begins with a single idea and expands into lines of inquiry that may not directly connect to the brief. It requires looking beyond the category, studying how similar problems are solved elsewhere, and challenging assumptions that initially seem obvious.

Research at this stage is exploratory and often scattered, extending beyond user interviews. Before conducting those, you need to have initial hypotheses or problem framings to help anchor what to look for. Without these, user conversations tend to lack direction and rarely yield useful insight. Writing then, becomes a way to frame a point of view before it is

An approach note begins almost like an idea pad. The way we do it is, we write things down as they occur to us. They do not need to follow a strict structure at the beginning, and there is no requirement to start from ground zero and move forward sequentially. You can start anywhere and find your way through.

Writing unlocks a different mode of thinking

Writing, for us, forces clarity. Attempting to explain an idea on paper inevitably reveals its gaps. In the process of articulating why something matters, or how it fits into a larger system, your understanding begins to deepen. Over the years, we’ve noticed that writing is one of the purest ways of thinking. It does not allow superficial engagement. If you are writing about a product concept, you are forced to interrogate it and strip away the veneer to judge its materiality.

And so, approach notes develop gradually, as living documents. They accumulate questions, diagrams, flows, rough UI fragments, and data considerations, and are not simply static presentations. Just as thinking evolves, so do they grow. Sometimes we write them before the build begins. Sometimes we continue building them alongside the product, so that the conceptual thread remains intact as complexity increases. It keeps us grounded and lets us return to the original premise and ask whether we are still aligned with it.

An example: Mapping an activation flow to find hidden friction

One of the strongest examples of this process was the User Activation journey we designed for iMobile Pay. The initial feedback we received was a general “It does not feel good.” Feedback like that is easy to dismiss as it seems vague and not particularly well-reasoned or couched in a directive. But there is always something underneath such vibe-based responses. Clients and users do not always have the vocabulary to diagnose the issue. That does not mean the issue is not real.

We mapped the existing activation experience and compared it with another category-leading payment app. On paper, the difference in time was not dramatic. The competitor app’s activation took roughly 25 to 26 seconds, while at that time, ours, a bank-owned app, took closer to a minute. Yet it felt even slower.

When we mapped out the flows and analysed the transitions, an insight emerged. The problem was not the number of steps. Banking applications require authentication layers, and certain steps are constraints; they cannot simply be removed, and users get this, in fact, they expect it. The real issue, we realised, was the interaction cost of the onboarding journey. It felt more involved to the user as the experience was especially cognitively taxing, unpredictable and frictional.

Instead of stripping down necessary steps, the solution was to rethink how these steps merged into one another. If screens transition in a fluid yet direct way, if elements remain visually stable, if motion feels continuous, the journey feels faster without compromising security. This insight into the problem at hand came from writing the whole case down, mapping it, and interrogating it with acuity.

Approach notes help us explain thinking

Another reason we write approach notes is that we do not pitch in the conventional sense. We do not rely on slide decks that move from one disconnected idea to another. We understand that a certain approach to a product is a narrative. It has an internal logic, and that logic needs to be explained as a line of thinking rather than as isolated screens.

For us, an approach note becomes a midway point between a presentation and a document. It can be walked through in conversation, and it can also be read later in detail. For stakeholders, that dual nature matters. They can see how the thinking unfolded and understand why a certain direction was chosen. The process becomes fully visible.

Conceptualised by one, enriched by many

Writing, especially in the early stages, is not a committee activity. If you want to think deeply about a topic, someone has to own it. When responsibility sits with one person, it creates conviction. There is a coherent thread. The note reflects a point of view that can then be questioned and refined.

In our early approach notes, often one of us would first write a draft capturing the general ideas, then take it to a team mate for a sort of peer review. They would present the note, and hence also their ideas. That conversation would sharpen it further. With more iterations of these reviews, the note would grow as more ideas and insights would be added. Weak ideas would be pruned out, letting the strong ones grow further. So while the outcome of a process like this is collaborative, the beginning usually requires singular focus. Otherwise, the writing fragments into sections and loses coherence.

A guiding North Star

Once we write it, an approach note does not disappear. We will often revisit it. It becomes a reference point, sometimes even an overall guiding North Star. It helps us ask whether the product being built still aligns with what we set out to do. If deviation happens intentionally, that is fine as products evolve. But deviation should not happen unconsciously.

The note remains as a record of intent. It shows where we started, what questions we asked, what constraints we accepted, and what trade-offs were made. For clients, it is also proof of the depth of thinking that preceded execution.

Taking the time to find the right approach

At its core, writing approach notes is about taking time: time to question assumptions, to define what is actually a problem and what is a constraint, to separate perception from reality, and to articulate the product as a coherent idea rather than a collection of features.

We began formalising this practice around 2018 or 2019, and since then, it has become second nature. When you write your way into a product, you tend to build with more clarity. And clarity, in complex systems, is rarely accidental; it is built with intent and arduous reasoning.