The shared premise
Tables show what you look for. Canvases show what you were not looking for.
The case for spatial data over tabular data is not about aesthetics. It is about peripheral vision. When you look at a table, you see the rows you filter for. You do not see the rows you did not think to filter for. The account that has been quiet for three months does not surface unless you specifically query for accounts with low activity. The relationship that is warming up does not appear unless you know to sort for increasing engagement.
A spatial canvas changes this. The quiet account drifts to the outer edge of its industry cluster. The warming relationship orbits closer. The at-risk renewal grows smaller as its deal weight decreases. These patterns are visible without filtering because the visual encoding of the data does the work that a query would otherwise require.
This is the core design bet behind both Galaxy builds: that some operational questions are better answered by a view that shows the whole portfolio simultaneously than by a query interface that answers specific questions one at a time. A table is the right tool when you know what you are looking for. A canvas is the right tool when you need to see what you were not looking for.
Two lenses, one engine
The same visual language applied to two different operational questions.
Account Galaxy
Portfolio health across an account book
Account Galaxy is built for the sales director or account manager who needs to see portfolio health without opening 24 individual CRM records. The canvas shows all accounts simultaneously, clustered by industry. Deal size determines planet scale, larger deals are larger planets. Renewal risk surfaces visually as accounts approach the edge of their cluster.
The design decision: make the most important signal (renewal risk) the most spatially prominent. An at-risk renewal is not buried in a field inside a CRM record. It is visible at a glance as an account that has drifted from the centre of its cluster and is no longer in the comfortable orbital range of healthy accounts.
What it reveals: the accounts you were not thinking about. The company that has been in good standing for two years but whose renewal is approaching and whose last touchpoint was six weeks ago. That pattern is invisible in a CRM unless you build a specific report for it. In the canvas it is simply the planet that has drifted.
Contact Galaxy
Relationship urgency across an active contact network
Contact Galaxy applies the same engine to a different question: which of my active relationships needs attention right now? Instead of accounts in industry clusters, it shows contacts in relationship orbits. Proximity to centre signals urgency, the closer a contact orbits, the longer they have been waiting for a response. Size signals thread volume, more active relationships are larger planets.
The interaction design is tighter than Account Galaxy because the action is closer: hover to see the relationship details, click to draft a reply. The diagnostic and the response are in the same view. The visual model tells you who to reply to. The draft mode lets you reply without leaving the view.
What it reveals: the thread that has been waiting nine days that you kept meaning to get to but could not locate because it had dropped below the fold in your inbox. In the canvas it is the closest orbit, the most prominent object in the view.
The shared design bets
What both builds assume and what that means for production.
Both builds bet on two things: that spatial metaphors (distance, size, proximity) are intuitive enough to require minimal explanation, and that periodic review is the right interaction model for relationship data at this scale.
The first bet holds. Users in testing understood the proximity-urgency encoding quickly, it matches how people already think about relationships informally. The second bet is more context-dependent. For a sales director reviewing their portfolio weekly, the periodic review model works. For a client-service team checking relationships daily, a lighter default view would work better.
What is deliberately over-built
The distinction between exploration and daily production.
Both builds show more data simultaneously than a daily production tool would need to surface. The full canvas is the right experience for the first time you run it, the discovery moment when you see your portfolio or contact network as a whole for the first time. It is probably more than you need for Tuesday morning when you just want to know who to reply to.
A production version would likely default to a simpler list view of the highest-priority items, with the canvas available as a deeper navigation mode for periodic portfolio reviews. The canvas is the inspection tool. The list is the daily workflow. Both builds are currently built as inspection tools, which is appropriate for a concept that is exploring the visual model rather than optimising the daily habit.
The design principle behind both
A table gives you access to data. A canvas gives visibility, the answer to "what am I not seeing?"
The canvas is not a better table. It is a different tool for a different question. Tables answer when you already know what you are looking for; canvases answer when you need to discover what deserves attention.
The canvas is one answer to the dashboard nobody opens: show what filtering hides.
Why teams stop trusting dashboards ->If your team needs to see relationship or portfolio health without reading individual records, this model is worth exploring for your context.
The builds demonstrate what is possible with the canvas approach. A practical implementation starts with understanding the specific operational question it needs to answer for your team and what data already exists to drive it.
Bring the page, report, or workflow as it is now.
We reply with the clearest next step, or an honest no.
