NEXUS

01

The problem with collecting

I wanted to connect what I kept finding.

Some references stay with us because they connect to something else. A book leads to a psychological concept. A song recalls a historical period. A quotation puts an idea into words that we had not quite found ourselves. Curiosity moves between subjects, often in ways that only become apparent after some time.

I wanted a place to collect these references without turning the process into another task of categorizing, tagging, and maintaining notes.

The problem was not the lack of places to store information. It was what happened after something had been saved.

A collection could grow indefinitely without revealing anything new about its contents. A reference might remain useful in isolation while its relationship to another book, person, or idea went unnoticed.

This became the starting point for NEXUS: a personal discovery tool designed around the relationships between the things that spark curiosity.

The central question was not simply how to organize knowledge, but how to make the connections within a personal repertoire easier to discover and explore.

02

Where NEXUS fits

More than a place to keep notes

NEXUS sits close to the world of personal knowledge management, but its emphasis is different.

A Second Brain is an external system for capturing, organizing, revisiting, and using information. It can support research, writing, creative work, and long-term knowledge management. Depending on how it is built, it can also connect ideas through backlinks, tags, or knowledge graphs.

NEXUS begins with a narrower question.

What if the primary interaction with a personal collection was not organizing what had already been captured, but discovering relationships between its contents?

The distinction is in the product's center of gravity.

A Second Brain helps manage and make use of accumulated knowledge. NEXUS explores how that knowledge might lead to something else.

This does not mean the two approaches are mutually exclusive. NEXUS still needs ways to capture, retrieve, and revisit references. Those are the foundations of the experience. What changes is the role of those activities: they support a product whose central proposition is conceptual discovery.

A book, a song, a person, and an abstract idea are not just separate records in a collection. They may be related through a common subject, a historical context, an intellectual influence, or a recurring theme.

NEXUS is an attempt to make those relationships part of the experience itself.

The product hypothesis

If references from different fields can be connected in meaningful ways, a personal repertoire may reveal patterns and paths of exploration that are difficult to notice when its contents are viewed individually.

This became the hypothesis behind the product.

It was a premise to investigate, not an outcome I had already validated. The design process would help turn it into a tangible experience that could be examined, challenged, and refined.

03

Defining who the product serves

One central idea, different reasons to explore

The first challenge was turning an abstract concept into a product that could support specific situations.

I identified three user profiles:

• The explorer collects things out of curiosity and wants to follow connections across different areas of interest.
• The student or researcher gathers references to investigate a subject, develop an argument, or build a deeper understanding of a topic.
• The creative user collects material that may later contribute to a project, an interpretation, or a new idea.

The initial persona and user journey focused on the explorer. This established a concrete starting point for the product, but feedback highlighted a limitation: representing only one of the identified profiles did not account for the different needs of the other two.

I revisited the way the experience was represented and expanded the original storyboard into three scenarios — one for each profile.

The change did not establish three entirely different products or prove that the interface met every profile's needs. It gave me a broader way to examine the same product proposition across different contexts.

This distinction mattered. The central idea could remain consistent while the reasons for using the product varied.

Process artifacts: the original persona, user journey map, initial storyboard, and three expanded storyboards.

04

Structuring the process

Taking an ongoing project further

By the time I worked on the formal requirements and usability evaluation, NEXUS was already a product I was developing for myself.

I used the project as the basis for a university assignment, which gave me an opportunity to examine the work I had been doing more systematically. Instead of treating the product as a series of interface decisions, I began documenting the process behind it: the user scenarios, the expected functionality, the constraints, and the ways the experience could be evaluated.

This changed how I approached the project. I had to make decisions explicit, connect different stages of development, and understand what each method could contribute to the product.

The requirements analysis and heuristic evaluation were part of this effort. They were not an attempt to make the project look more complete than it was, but a way to give the existing concept a clearer structure and examine it more critically.

The process helped me understand product design as more than moving from an idea to an interface. It involves defining what the product is supposed to do, making its assumptions visible, examining the experience systematically, and recognizing what still needs to be investigated.

05

From scenarios to requirements

Making the scope explicit

The storyboards helped represent the proposed experience. The requirements analysis gave me a more structured way to define what that experience would need to support.

Because NEXUS was already in development, this was an opportunity to step back from the interface and formalize decisions that had previously been shaped through the process of building it.

I organized the specification into 14 functional requirements and 9 non-functional requirements. The functional requirements described the capabilities the product was expected to support, from free-form reference capture and automatic identification to contextual information, conceptual connections, search, and different ways of exploring the repertoire.

The non-functional requirements addressed qualities and constraints such as security, data isolation, simplicity, processing feedback, and clarity about the origin of information.

Writing these requirements helped me distinguish between the broader product idea, the behavior needed to support it, and the scope represented by the current prototype.

It also made gaps easier to identify. A feature could be part of the intended product without being fully implemented, and documenting it did not mean treating it as finished.

The value of this step was not simply producing a requirements document. It was learning to translate an abstract product proposition into a more explicit, examinable scope.

Process artifacts: the requirements sheet, selected functional and non-functional requirements, and the relationship between requirements and the main interaction flows.

06

Designing the experience around the repertoire

Five views, one underlying collection

The interface developed around five main areas: Home, Repertory, Explore / Atlas, Panorama, and Search.

Each provides a different way to interact with the same material.

Home — capture comes first

The main interaction begins with a free-form capture field.

Instead of requiring users to select a category before adding something, the proposed experience starts with the reference itself. The system is intended to identify the item and provide context afterward.

This reflects the original problem: capturing something interesting should not require completing an organizational task first.

Home also brings recent entries and recurring patterns into view, providing a way to return to the repertoire without beginning every session from scratch.

Repertory — finding what is already there

Repertory provides a browsable view of the accumulated material.

References can be revisited through their associated information, filtered by type or theme, and retrieved through search. This supports a straightforward need that discovery-oriented products can easily overlook: sometimes a user simply wants to find something again.

The view establishes the collection as a useful resource in its own right, even when the user is not actively following a new connection.

Explore / Atlas — navigating relationships

Atlas gives the idea of connected knowledge a spatial representation.

References appear as nodes within a map of relationships, creating an alternative to the linear structure of a list. The view invites users to examine an item in relation to other parts of their repertoire.

The challenge is not simply to display a network. A visualization can show that items are connected without making the relationship meaningful or understandable.

The usefulness of Atlas therefore depends on more than its appearance. The connections need to provide enough context for a user to understand why a relationship might be worth exploring.

Panorama — seeing recurring themes

Panorama moves away from individual connections and looks across the collection.

Where Atlas emphasizes relationships between references, Panorama is intended to make recurring subjects and patterns visible. It offers a different perspective on the repertoire: not just what is connected, but what repeatedly appears across the material.

The two views reflect separate dimensions of exploration — following a relationship and recognizing a pattern.

Search — retrieval without detours

Search offers a direct way to locate references in the collection.

It complements the exploratory surfaces rather than competing with them. A user should be able to follow an unexpected connection when curious, but should not have to do so just to find an item they remember.

Together, these views create a product structure that supports both deliberate retrieval and open-ended exploration.

Process artifacts: screenshots of the five views, with annotations explaining the role of each and how they complement one another.

07

From interface concept to navigable prototype

Making the interactions concrete

The high-fidelity prototype allowed me to examine the experience as a sequence of interactions rather than a set of static screens.

The available implementation uses a React-based interface, local demonstration data, and simulated processing states. It demonstrates the main flows, including entering a reference, moving through the processing sequence, viewing a result, browsing the repertoire, and navigating the different views.

One of the important interaction decisions was to make processing visible. The sequence communicates the intended stages of identifying a reference, searching for context, and looking for connections.

That matters because an unexplained delay would leave the user uncertain about what the product is doing. The interface instead presents processing as part of the experience.

The current prototype simulates these transitions; they should not be interpreted as evidence of live AI processing.

The intended technical architecture

The technical direction documented for NEXUS includes the following:

• React, Vite, and Tailwind CSS for the web interface and its development workflow.
• Supabase and Postgres to manage persistent data associated with each user.
• pgvector and embeddings to support similarity-based retrieval beyond simple text matching.
• Claude to help identify references and generate contextual explanations.
• Voyage AI to produce embeddings for semantic retrieval.

The architecture reflects the ambition of the product: if NEXUS is to connect references by meaning rather than by shared keywords alone, its data and retrieval approach need to support that goal.

However, this architecture is documented as the intended technical direction. The available prototype does not establish that these services are all integrated. Its identification and processing behavior relies on local demonstration logic and known examples.

Keeping the distinction clear makes the case more useful: it shows both how the product was conceived technically and what the current prototype actually demonstrates.

08

Evaluating the prototype

Looking beyond visual coherence

After developing the navigable prototype, I conducted a heuristic evaluation to examine the interface more systematically.

The review covered the major interaction flows and considered usability principles such as system-status visibility, consistency, user control, error prevention, recognition, recovery, and minimalist design.

The evaluation was especially relevant to NEXUS because the experience depends on processing information and presenting connections that may not be immediately obvious to the user.

The review identified positive aspects, including visible processing feedback, consistent visual organization, and the language used throughout the interface. It also documented opportunities for improvement involving error states, initial guidance for Atlas and Panorama, recovery after deletion, and the distinction between user-provided content, external sources, and system suggestions.

The evaluation template produced a total of 157 points, corresponding to its own "high" usability classification. This score describes the outcome within that evaluation framework; it is not evidence of user satisfaction or a successful usability test.

What the evaluation changed

The review gave me a structured basis for reconsidering the prototype beyond its visual presentation. Some changes were implemented afterward, while other findings remained open for further development.

The distinction between findings and implementation is important. Identifying a usability issue does not automatically resolve it, and a proposed improvement should not be presented as a completed change.

The next iteration of this case should show specific examples of the process: the issue identified, the decision made in response, and the corresponding change in the interface.

That comparison would make the refinement visible and connect the evaluation to the product itself.

09

Evaluating the prototype

Using heuristics to examine my own decisions

The heuristic evaluation was another part of bringing more structure to a product I was already developing.

I selected this method to examine the prototype systematically across its main interaction flows, including capturing references, processing information, browsing the repertoire, and exploring relationships through Atlas and Panorama.

Rather than relying only on whether the interface looked coherent or the interactions appeared to work, I reviewed the experience against usability principles such as system-status visibility, consistency, user control, error prevention, recognition, and recovery.

The evaluation identified positive aspects of the prototype, as well as areas that needed further attention. These included error states, initial guidance for Atlas and Panorama, recovery after deletion, and clearer distinctions between user-provided material, external sources, and system-generated suggestions.

Working through the evaluation helped me understand how a structured review can expose problems that are easy to overlook while designing and building a product. It also gave me a clearer basis for revisiting design decisions and implementing some changes.

The evaluation did not establish whether people would want to use NEXUS, whether the proposed connections would be meaningful to them, or whether the product would become part of their routines. Those questions require further research and validation with potential users.

What it gave me was a more systematic way to examine the product I had built, distinguish existing strengths from usability concerns, and identify what should be improved or investigated next.

10

Where the project stands

NEXUS is still in development, and it is not the project receiving most of my attention right now. Another project has taken priority, so I am not currently investing as much time in NEXUS as I would need to move it toward a more complete and validated product.

Still, building it has been a valuable experience. I took a personal need and worked through the process of turning it into a product concept, defining requirements, exploring a visual system, building a navigable prototype, and evaluating the interface.

I also ended up with something I continue to use.

For now, NEXUS exists somewhere between a personal tool and an unvalidated product hypothesis. I know it serves a purpose in my own life. What I have yet to establish is how well that purpose translates to other people, and whether the experience is compelling enough to become something they actively want to use.

That is the next question, whenever the project moves into its next phase.