Research can have a much longer life than the phase dedicated to it for a project.
Usually, though, it just sits in a folder until somebody remembers that it might help with a question they have, and at other times, it is forgotten entirely.
I know this from my own files. I have dozens of old research documents and mind maps lying around, and I am unlikely to reopen most of them, if only because I no longer remember what I called them.
My files are one personal version of a broader problem. Across a studio, research accumulates in different projects and people’s notes, and somebody has to remember that it exists before it can be mined.
The research system we are building at Canvs keeps new research connected to its sources and project context, so it can return when a related question appears.
How the non-linear research system contributed to a pitch from past learnings
Here is an example of how the system works in practice, storing and surfacing information at critically opportune moments.
In late January, an internal conversation about a payments project brought up a competitor that had changed its onboarding.
The system recognized this as something worth investigating, researched the change in the background and stored what it found.
A couple of months later, the same competitor came up with a different client on another payments project.
That conversation produced a second synthesis note.
In June, while working on a health insurance pitch, we began with a direct ask: what should onboarding for this product do?
The system researched the category and brought the 2 earlier notes into the new inquiry.
Together, the research pointed to a problem shared by payments and health insurance:
Financial products hold a great deal of information that can sit unused between visits.
Payments apps accumulate transaction data throughout the day. Health insurance products hold policy and claims information that may sit untouched until renewal, or until somebody needs it.
This insight became the thesis for the health insurance pitch and set the direction for an entirely agentic health experience.
This very movement → from an observation made in one project to a decision taking shape in another → is what we are building the system to support.
How this research branches and returns
Here, it is important to clarify that when we say ‘nonlinear’, we mean the relationship between inquiries. The research itself happens in separate runs. Some begin with a direct request, while others run on a schedule.
[IMAGE — From Signal to Decision]
On MARS AMC, a coverage gap flagged on 29 July persisted through weekly reviews, gained context in an August meeting, and returned as researched material that changed strategy for the next client meeting.
A design decision or review can raise a new question at any point. When that happens, the system looks in 2 directions at once: outward through current sources and back through the research it already holds.
It searches for meaning as well as matching words, allowing a question to reach related work even when it began on another project or used different language.
New evidence is then read against what is already known:
Supporting evidence can strengthen an earlier finding.
A contradiction is recorded along with the context in which it appeared.
An adjacent subject can become another line of inquiry.
The revised synthesis returns to the same knowledge base with its sources attached. Each research run has a beginning and an end, while what it adds becomes available to the questions that follow. This is where the system begins to compound.
[IMAGE — Research Compounds]
On MARS AMC, a first-pass note from 31 July is refined three weeks later by folio math and sponsor data, with unknowns like AUM per folio still marked.
Sometimes we make the first design decision before the research note exists. On one live banking project, a new NPCI directive changed how Virtual Payment Addresses (the IDs used for UPI payments) needed to be masked on screen.
During a meeting, we worked through how phone-number and name-based VPAs should be obscured. Several weeks later, the pipeline documented the directive and connected it back to that meeting, an earlier fraud-rules briefing and related research.
By then, the masking decision was already in the screens, so the pipeline attached the dated source the next person would need to understand or revise it.
[IMAGE — Provenance Enters the Work]
On Orion, a 30 July decision to mask the VPA is later paired with the 25 August NPCI directive that justifies it, so anyone asking why can retrieve the reasoning.
In a live project, the process can begin earlier: the next branch can begin with something as ordinary as a designer asking me on Slack to choose between a couple of directions. Once that exchange enters the system, it checks the research we already hold and notes what is missing.
I can respond with what we know at the time. If the conversation continues the next day, the system may already have researched the likely follow-up questions. The inquiry grows with the decision that raised it.
From a question to evidence we can use
The system once inherited a research question built around an apparent RBI prohibition on concurrent sessions. An earlier note had repeated the premise while discussing authentication for an ICICI product, which meant it could have influenced how we justified the interface.
When the research agent checked the rule, it found no RBI circular containing it. The same wording appeared in LinkedIn posts about regulations in India, the UAE, Cameroon and Nigeria.
The agent traced the one-device restriction to ICICI’s own policy, then flagged the earlier note and asked whether RBI’s requirement on device binding had been misread as a ban on concurrent sessions. The premise sounded credible until each part was traced back to its source.
[IMAGE — A Claim Rejected]
The ‘RBI prohibits concurrent sessions’ claim fails three checks (no primary source, identical wording in four countries, restriction traced to Orion’s internal policy), and the earlier note is flagged for review.
Something similar happened when 2 notes were connected because both contained the words “claims” and “insurance.” One concerned health insurance and the other travel insurance. The connection looked reasonable at a glance, but fell apart in context.
This is why a research task passes through more than one threshold. First, the system has to decide whether a question deserves pursuing at all. That can happen in a few ways:
A person can ask directly, usually in response to something raised by a client, designer or design manager.
A subject that appears repeatedly across conversations and notes can be promoted into a research task. Three separate mentions within 24 hours make it a high-priority signal; weaker signals stay in the background until they recur.
Scheduled scans compare new material with what the system already holds, looking for gaps or adjacent questions that could use further research.
Whichever route it takes, the task carries its project context and original source into the research. The first pass is then examined by models other than the one that produced it, since a model is rarely the best critic of its own assumptions.
This adversarial review looks for missing citations, stale evidence, contradictions and broad claims that sound convincing without saying who or what supports them. A statistic without a source, or a generalised phrase such as “customers tend to …” or “most people …” is likely to be flagged.
The final review is human. The original material remains unchanged, and every synthesis keeps a route back to where it came from. I can trace a finding through the source, prompt and tool call that produced it. If I cannot work out why something exists in the system, it does not enter a brief, screen or client conversation.
The system works especially well for secondary research: competitive intelligence, category trends, regulatory tracking and technology deep dives. It can search and compare more material than any of us could reasonably read during a project.
Primary research asks something different of us. We still need to speak with users, observe behavior, read important sources closely and write our own notes.
I remain skeptical of synthetic users assembled from personas. They tend to return abstractions precisely where we need lived experience.
Formal research remains part of our projects for the same reason. It gives us time to understand a category properly, while the system keeps that work available for questions that appear as the product develops.
When research enters the work
For a recent banking pitch, we were looking for an idea that would feel distinctive inside the this product – a hook , if you will. In this case, differentiation meant moving the bank beyond what it already offered.
A while earlier, we had designed a security feature for a different banking product. It had gone live, and the system’s weekly scans continued following it through release notes, customer commentary and press coverage.
While we were testing ideas for the new pitch, I asked the system whether we had missed any useful angles. It brought that security feature back into the conversation.
Two things made it worth considering. The feature remained uncommon among Indian banks, and we already understood how it worked because we had designed it once before.
We adapted the underlying idea for the new bank and included it in the pitch. The client told us they had considered something similar, but had not worked out how to turn it into a product feature.
The earlier screen had returned with its later history attached: why we built it, how it had been received and enough recent evidence to check whether the idea still held.
[IMAGE — Old Knowledge Returns]
Old knowledge returns across two spans, a 2019 project detail resurfacing in a 2026 Mars pitch as a proof point, and a month-old Mars research match refreshing a five-crore-folios record.
Keeping that history current is part of the same system. Older claims are checked against newer sources, and the system records what has changed:
Material that is clearly out of date is archived.
A claim whose language or context may have shifted is held for further research.
New evidence can update an earlier note or revive an idea that had stopped being relevant.
Research becoming cheaper does make it tempting to investigate everything. I say this as someone perfectly capable of ending a night with 700 tabs open.
The useful test is whether that research connects with an open question, fills a genuine gap or gives the work something it can act on. Otherwise, we end up with a very smart content farm: agents researching everything and integrating nothing.
Once the system finds a connection, a designer or design manager still has to decide whether it belongs in the product. As more research becomes available, that judgment takes up a larger part of the work.
More research makes judgment more important
On the morning of this conversation, the system picked up a discussion about technical clarifications for a pitch and offered to prepare the questions. I told it to go wild because I had tokens to burn.
It returned 7 pages of 12-point type for a task that needed 7 questions. I still had to work out which questions the client could answer and which answers would actually help the project.
As research becomes cheaper, gathering information takes up less of the work. Designers need to frame sharper questions, while design managers spend more time finding gaps and deciding what deserves further investigation.
A system can assemble common onboarding patterns for a bank, insurer or payments app within minutes. Choosing which pattern belongs in a particular product depends on information it may never see.
The largest business inside a bank may receive more attention than another division. An idea may run into internal resistance, depend on a team that cannot support it or ask the client to make a change they cannot carry through.
That knowledge comes from working with the organization and the people inside it. Evidence, experience and judgment have to be read together.
Different angles already enter the research through the people doing it. Debprotim tends to follow the business case, Arjun looks for the visual opportunity and I am usually trying to find the novel or unexpectedly useful angle.
Those divisions are still informal, but they reflect our individual interests and give the work several ways into the same question.
The compound loop described here currently runs end to end in my setup. Research from others enters through shared notes, links and agent handoffs. We are building a common studio knowledge base that will make those exchanges more direct.
As that layer reaches more people, it will need clear accountability. We should be able to see which agent began a search, what prompted it, which sources it used and who approved the resulting connection.
That also helps us avoid several agents repeating the same research while preserving the differences in how people approach it. If the system ever decides ‘fashion’ and ‘payments’ belong in the same inquiry, we should at least be able to find out why.
The worst lesson to take from a system like this would be that the knowledge base can do the thinking for us. It extends how much we can search, retain and compare; the people working on the project still decide what belongs in it.
That morning, the useful work was cutting a 7-page response down to the 7 questions we needed to send.
What nonlinear research changes for the studio
Research is usually judged by the answer it produces for the project in front of it. A persistent system adds another measure: what that inquiry makes possible later.
An inquiry becomes more useful when another team can see how its answer was reached and decide whether the same reasoning still holds. A different category or newer evidence may lead them somewhere else, which is useful too.
As more of this work enters a shared knowledge base, the studio accumulates a record of how its understanding has changed across projects. The reasoning stays available alongside the conclusions it produced.
The next inquiry begins from there, asking better questions because of the work that came before it.
