Redesigning how evidence moves from research to writing
A research and writing platform that helps users capture evidence from source material, organise it and reuse it while writing.
What started as an onboarding brief to address a steep learning curve evolved into a deeper system-level design problem. Moderated usability testing showed that participants could get through parts of the core workflow, but struggled to understand what happened to captured evidence and how to carry it forward.
Rather than patching individual interfaces, I traced how evidence moved through the product, which reframed the problem and redirected the design strategy.
Project Snapshot
Key area
Detail
Users
Students, academic staff, researchers and others producing evidence-based written work
Initial brief
Improve learnability and onboarding
Scope
Two phases, a commissioned product engagement followed by independent deeper investigation
Constraint
The underlying Snippet model and fundamental Page relationships could not be substantially changed
Duration
5 months
My Role
Contributed to user research synthesis and qualitative analysis.
Owned wireframe and interaction design for Phase 1 onboarding deliverables.
Mapped the platform’s core object model across the full Snippet lifecycle.
Diagnosed architectural communication gaps across capture, organisation, and writing workflows.
Developed design responses grounded in heuristic evaluation and system testing.
About the platform
The platform was designed to bring a fragmented research and writing workflow into one connected workspace. Instead of moving between source material, notes, citation tools and writing software, users could read, capture useful evidence, organise it and bring that evidence back into their writing.
📖 Read ──► 📥 Capture ──► 📂 Organise ──► 📝 Reuse
Its value came from keeping those activities connected. Evidence captured while reading could remain linked to its source, be organised for later use and eventually be reused when developing written work.
The Business Reality
Short sessions created an activation and retention risk
For a platform designed around a connected research-to-writing workflow, the engagement data showed that users might engage with only parts of the platform and never experience the broader value of connecting reading, captured evidence, organisation and writing.
Average session duration
<15 mins
Average active time per session
4 mins
The numbers showed that something was not working, but they could not explain where the difficulty occurred or what was causing people to disengage. The question was therefore whether the platform was making its wider workflow and value clear enough to encourage continued use.
The team believed the steep learning curve was a major barrier, so the initial brief focused on improving onboarding and helping new users understand how the platform worked.
What happened when we tested the core workflow
To test the onboarding hypothesis, we ran moderated usability sessions with 11 participants (postgrads and staff). We asked them to complete the platform’s core loop which is to capture a piece of evidence while reading, and successfully import it into a draft. Tracking their progress revealed a massive break in the workflow.
9 / 11
Managed to complete Capture
2 / 11
Progressed to importing evidence into writing
Existing Capture flow showing where uncertainty begins after the Snippet is created.
Most participants eventually got through Capture, but the interaction itself was unclear. Once the popover appeared, many were unsure whether the Snippet had already been saved, what “Add New or Link item” meant, and where their captured evidence or notes would live.
It seems like my comments are not actually being saved or edited somewhere. Where do they live?
— Participant 06
I captured this but can't pull it into writing.
— Participant 11
These were not isolated interface questions. Together, they showed that participants were struggling to carry an understanding of their evidence forward through the workflow. The platform could help them create a Snippet, but users lacked a clear mental model of how that evidence would carry forward into their broader workspace.
There was also an important limit to what the study could tell us. Because most participants became blocked before progressing through the later workflow, the deeper Import and Page relationship mechanics were not meaningfully validated in the original usability study. The research showed us where understanding was breaking, but not yet why the system behaved the way it did.
Investigating the system before changing the behaviour
To understand why the system behaved this way, I needed to look beyond the interface. I mapped what happened to a Snippet from the exact moment it was captured, all the way to the point where it could be reused in writing.
Two objects were central to that workflow. A Snippet was a reusable piece of evidence captured from a source and kept linked to where it came from. A Page could be used to organise that evidence or as a place to write. The same Snippet could be associated with more than one Page, allowing evidence captured in one context to be reused elsewhere.
The map clarified an important distinction. Capture worked at the level of an individual Snippet, while reuse could happen at the level of a Page containing multiple Snippets. A Snippet was saved first, could optionally be associated with another Page, and later become available for writing when evidence from that Page was imported.
Three distinct moments of friction
While the platform was designed around a seamless research-to-writing loop, tracing the evidence showed that friction was breaking the journey across three key moments:
01
Capture
Save evidence without interrupting the reading flow.
02
Route
Find the right destination for a snippet as the workspace grows.
03
Organise
Understand how snippets and pages are connected.
These were not three isolated interface problems. They were connected by the same underlying Snippet and Page model, so changing one part of the workflow could affect what happened later.
01/03
Capture without interruption
When a user selected evidence and pressed Capture, the Snippet was already created and associated with the current Page. The popover that followed was therefore not required to complete Capture. It gave the user additional options to edit the Snippet or associate it with another Page.
The interface, however, did not communicate that state clearly. The routing field received immediate attention, while there was little visible confirmation that the original task had already succeeded. As a result, saving evidence and deciding where else it should belong could feel like one continuous requirement.
It prompts me to add a new page or link an item, but I am not sure why I would need to do that at this point.
— Participant 04
I captured this but can't pull it into writing.
— Participant 11
For someone reading and collecting evidence, the immediate task was much simpler: I found something useful. Don’t let me lose it. The interface was introducing an organisational decision before making that first task feel complete.
Why not just remove routing?
That was the obvious direction at first. If Page assignment was interrupting Capture, removing it would make the interaction considerably simpler.
But the system map showed why that decision was not so straightforward. Associating a Snippet with another Page was one of the ways evidence could be organised for later reuse. It also happened at a useful moment, while the source and meaning of that evidence were still fresh in the user’s mind.
So there were two legitimate needs competing for the same moment.
During reading
Capture should be quick enough that users can preserve evidence and continue.
Vs
For later reuse
The platform still benefits from giving users an opportunity to organise that evidence while its context is fresh.
The problem was therefore no longer whether routing should exist. It was how much attention routing should demand during Capture.
DESIGN TENSION
Capture needs to feel complete and lightweight, while routing needs to remain available without feeling mandatory.
This became the principle I used to evaluate the interaction rather than starting with a preferred UI.
What a good solution needed to achieve
Before exploring alternatives, I set four criteria for the Capture experience:
Make completion unmistakable
Users should know that the Snippet has already been captured before deciding what to do next.
Protect the reading flow
Someone who only wants to save evidence should be able to continue without making another decision.
Keep organisation available
Users who already know where the evidence belongs should still be able to associate it with another Page while the context is fresh.
Keep optional actions proportionate
Adding a note or routing evidence should remain available without either action appearing necessary to complete Capture.
Exploring the interaction model
With those criteria in place, I explored how much the Capture surface should ask users to do after the Snippet had already been saved.
Exploration 01
Separate completion from what happens next
Exploration 02
Give routing comparable presence
Why I tried it
At this stage, I was still treating annotation and Page association as persistent follow-up controls within the Capture surface. Because the note field occupied most of the available width while Add to page remained visually secondary, I tested whether giving both actions comparable presence would create a more balanced hierarchy.
Exploration 03
Keep optional actions available on demand
Why I tried it
Exploration 02 made both follow-up actions easy to recognise, but at the cost of keeping two large optional controls visible after Capture was already complete. I tested whether their entry points could remain discoverable while revealing the full interaction only when needed.
A different interaction model
The first three explorations changed what the popover contained, but they all retained the same assumption: that Capture should open one. I tested a different model that separated confirmation from optional
follow-up actions.
Confirm Capture, then get out of the way
Why I tried it
Capture is repeated while users are reading, so even a lighter popover could become disruptive over time. I wanted to see whether success could be confirmed without interrupting the reading flow, while keeping organisation available when needed.
I carried this model forward because it gave Capture a clear completion point while preserving immediate access to routing and reducing the repeated interaction cost.
02/03
Route to the right destination
Separating routing from Capture made 'Add to page' a deliberate action rather than part of completing Capture. I then examined the destination picker itself to understand what happened when someone actually chose to organise a Snippet.
How I first approached retrieval
I started by asking how the way someone finds a destination might change as their memory of it becomes less precise. From that, I formed a simple working model.
Exact recall
"I know what I’m looking for.”
If the user remembered a Page name, source title or another clear identifier, Search offered the quickest route back to it.
→ SEARCH
Partial recall
"I remember something about it."
The exact destination might be unclear, but topic, source or surrounding context could still help the user recognise the right Page when likely options were surfaced.
→ SUGGESTED
No usable recall
“I don’t know what to search for.”
Browse through Pages, use surrounding context and progressively locate the destination.
→ BROWSE / ALL LOCATION
WORKING HYPOTHESIS
As recall became weaker, the picker should progressively shift from direct
search → recognition → navigation.
I used this as a working model to guide the first explorations.
What could someone actually remember?
If the first model depended on recall, I needed to understand what someone might actually remember when trying to relocate a Page. I mapped every cue the platform could potentially use, from Page names and source details to citation metadata and content inside files.
Not every useful cue belonged in Search
Mapping the cues showed how much information the platform could potentially use for retrieval. But the destination picker had a much narrower job, i.e. help someone choose a Page to route the Snippet to.
This kept Search focused. A Page could still be found from an incomplete title or remembered source information, without turning a small routing interaction into a search across every heading, paragraph, Snippet and uploaded document.
Exploring citation-led search
Citation metadata was the less straightforward case. A user might remember a source through an author, year or journal rather than its title. If those details identified a selectable source Page, they could still be useful for destination Search.
I initially explored whether citation should therefore become a separate search mode.
What this exposed
Looking at the interaction more closely, I realised the problem went deeper than whether 'Chen 2023' counted as partial recall.
I had assumed that citation information could help identify the Page the user wanted to route to. That assumption did not always hold.
Here, the citation describes the Page itself. Searching 'Chen 2023' can reasonably return that source Page as the destination. But consider a thematic Page such as 'Digital Sustainability' that contains evidence captured from Chen 2023.
Here, Chen 2023 does not identify the destination Page. It identifies the source.
To return those thematic Pages, Search would have to move beyond matching the destination itself and follow:
source → evidence → Pages using that evidence
Because evidence from the same source could appear across several Pages, one citation cue could legitimately relate to multiple destinations. I could no longer assume that citation metadata uniquely identified the Page.
Course correction
I had started designing citation search before defining what a citation query should actually return. The exploration also challenged my first recall model. A user might remember only part of a Page title, an author, or a year, but any of those can still be enough to Search.
So I stopped treating Search, Suggested and All Location as fixed levels of memory.
Suggested destinations
Search worked when someone had something useful to type. But the existing picker also surfaced Recently Used Pages, giving users another way to recognise a destination without searching for it.
The problem was that recent did not necessarily mean relevant. A recently used Page could be unrelated to the evidence being captured, while a more relevant destination might have been used much earlier.The problem was that recent did not necessarily mean relevant. A Page opened five minutes ago could be unrelated to the evidence being captured, while a more relevant destination might have been used much earlier.
I explored using signals such as the current source and existing Page relationships to surface more relevant destinations first, with recency used when stronger contextual signals were unavailable.
All Location
Suggested could surface likely destinations, but users still needed a way to reach any Page in the workspace.
Earlier in the case study, I had already identified that the existing hierarchy became harder to navigate as nesting increased. At this point, I brought that problem back into focus before exploring alternatives.
How could I make a deep hierarchy easier to navigate without removing the flexibility users already had?
The Structural Constraint
The tool can contain deeply nested pages, but the sidebar does not provide persistent visibility of sub-pages created within documents. The destination picker therefore had to carry the structural complexity of the workspace within a small, temporary surface.
Stress-testing the hierarchy
I explored several ways to make deep Page structures easier to navigate, then pushed each approach with increasingly nested examples to see where it began to break.
01–02 · Making the hierarchy clearer
I first focused on making parent and child relationships easier to read while keeping more of the structure visible. However, showing more of the hierarchy improved context, but deeper structures still increased scanning and visual density.
03–04 · Containing the hierarchy
Next, I explored containing the structure through scrolling and more controlled navigation rather than allowing the list to keep expanding. Containing the hierarchy reduced its physical footprint, but shifted the effort into scrolling and keeping track of where the user was.
05–06 · Giving the hierarchy more room
I then tested whether additional width (5) and clearer separation between levels (6) would make deeper structures easier to traverse. More space improved legibility, but it did not remove the underlying problem. As depth increased, too much of the hierarchy still had to remain visible at once.
The Breakthrough: Navigate the Hierarchy on Demand
The explorations showed that the problem could not be solved by giving the hierarchy more space. Whether it scrolled vertically, expanded horizontally, or occupied a separate tab, deeper nesting still required users to navigate through structure they did not need to see.
The solution was to change how the hierarchy is revealed. Instead of expanding the entire tree inside the picker, I introduced contextual re-routing. Selecting a page or branch moves the user into that local context, temporarily replacing the broader hierarchy with only the destinations relevant to that branch.
A persistent breadcrumb keeps the user's position visible and provides a clear path back to the parent level.
A small detail with an important role:
Showing where a snippet is already linked gives researchers confidence before adding another destination, reducing accidental duplicate routing without interrupting the capture flow.
Final direction
Rather than simplifying the Page structure itself, I reduced how much of that complexity users had to deal with at each moment. The same picker could now support direct retrieval, recognition and deep structural navigation without forcing users into one method.
03/03 Organise and reuse
The explorations showed that the problem could not be solved by giving the hierarchy more space. Whether it scrolled vertically, expanded horizontally, or occupied a separate tab, deeper nesting still required users to navigate through structure they did not need to see.
The solution was to change how the hierarchy is revealed. Instead of expanding the entire tree inside the picker, I introduced contextual re-routing. Selecting a page or branch moves the user into that local context, temporarily replacing the broader hierarchy with only the destinations relevant to that branch.
A persistent breadcrumb keeps the user's position visible and provides a clear path back to the parent level.
A small detail with an important role:
Showing where a snippet is already linked gives researchers confidence before adding another destination, reducing accidental duplicate routing without interrupting the capture flow.
Final direction
Rather than simplifying the Page structure itself, I reduced how much of that complexity users had to deal with at each moment. The same picker could now support direct retrieval, recognition and deep structural navigation without forcing users into one method.