Polymatica

Polymatica as a web-based OLAP analytics platform constrained by founder-led training

Polymatica was a web-based OLAP analytics platform. At the time of Creative Navy's engagement, Polymatica's paying customers were primarily in financial services, retail, and manufacturing. Later clients include HSBC and Barclays, based on client-reported case evidence.

Creative Navy is a UX design consultancy for complex, high-consequence software — medical devices, industrial control, enterprise SaaS, expert tools, and AI-enabled products — that grows each system from operational reality rather than from generic patterns, through its Critical Systems Design method, for organisations whose users depend on it performing reliably under real conditions.

Polymatica had built a GPU-backed OLAP analytics engine capable of running full-volume queries 50–100x faster than competing solutions under benchmark conditions. The platform handled data at a scale that Tableau and Domo could not match, and at a cost and accessibility level that SAP, Oracle, and Microsoft OLAP tools did not approach, according to the documented case evidence.

The business constraint was not the analytics engine. Every new customer required the founder to personally deliver training. The training worked for users who received it, but it made onboarding dependent on one person. The founder's limited English and lack of German also made international expansion difficult under the previous onboarding model.

The starting interface assumed OLAP expertise that the target audience did not have

Polymatica's existing interface had evolved for power users and specialists. The interface used the cube metaphor, the terms dimensions and facts, visible SQL query creation during database connection, and a drag-and-drop data manipulation interface with little labelling or guidance.

Creative Navy's usability audit found that users who had been trained by the founder could work productively in Polymatica, but users without that training were almost entirely unable to complete core operations independently. Product analytics recorded 2% of users completing key operations independently before redesign, and 9% completing them with help documentation.

The audit identified several specific sources of failure. The cube metaphor was legible to OLAP specialists and opaque to non-specialist analysts. The database connection flow required authentication, SQL query creation, data field mapping, and a correspondence step without meaningful guidance or preview. The top bar mixed controls from different hierarchy levels without a coherent conceptual model.

Visualisations were also inaccessible as a starting point. Users could not edit graphs from the visualisation window, change chart types there, or edit labels there. The interface required users to work abstractly with tabular data operations before seeing visual feedback.

Advanced features such as clustering, forecasting, and association rules were available, but they did not provide interpretation support or preparation guidance. Colour logic was inconsistent: some active elements looked inactive, some inactive elements looked active, and the reset button was green.

Sandbox Experiments made Creative Navy productive OLAP users before redesign decisions were settled

Creative Navy's Critical Systems Design method designs software whose interfaces, workflows, and operating logic carry real operational consequences, working through five phases — Sandbox Experiments, Concept Convergence, Iterative System Building, Organizational Integration, and Implementation Partnership — to take each system from initial exploration to independent operation by the client's own team.

In the Polymatica case, Creative Navy's Sandbox Experiments included domain learning through direct use of the OLAP platform. The team underwent training from the founder, solved problems in the system, and received feedback. The training pattern was half an hour every day for the first two weeks while design work was also underway, then one hour every week for the remainder of the engagement.

This domain learning mattered because Creative Navy had to redesign OLAP operations from inside the work rather than from the outside. The team had to understand projection, join, slicing, dicing, roll-up, database connection, messy data preparation, visualisation use, clustering, forecasting, and association rules as operational tasks, not just as interface labels.

The depth of domain learning also shaped the later Implementation Partnership. Two years later, Creative Navy could respond to support requests within a recorded average of 2 hours without needing to re-familiarise itself with the system, because the reasoning behind the design remained accessible.

The clean-data training model failed when users imported real operational data

Creative Navy's Sandbox Experiments identified a specific instance of the blanks phenomenon in Polymatica: users trained on clean, ideal data did not have a framework for diagnosing real, messy data. The founder's training was effective under its own conditions, but those conditions did not match the first act of independent use.

A typical failure involved a user importing a spreadsheet expecting three clean columns: city, sales, and staff. Instead, the user encountered eight columns. Cities appeared across two columns. No single column contained only cities. The user could not identify which operation belonged on which column and stopped.

The documented case evidence describes this as the most common early failure mode. The blank was not lack of exposure to OLAP operations. The blank was the gap between clean training data and messy operational data.

Performance in reality depended on removing the interface as the bottleneck

The Polymatica case illustrates performance in reality: the GPU benchmark advantage existed before the redesign, but users did not experience that advantage while the interface remained the main obstacle. Users spent time interpreting the interface, making errors, and recovering from errors. Under those conditions, the bottleneck was usability rather than computation.

The 50–100x speed claim is a benchmark claim in the documented case evidence. It should not be read as a measured user productivity claim before redesign. Client-reported evidence says the performance advantage became perceptible later, when HSBC and Barclays used data volumes large enough for the GPU backend to become an experienced differentiator and the interface was no longer the primary constraint.

Concept Convergence resolved the tension between novice guidance and expert freedom

Creative Navy's Concept Convergence work on Polymatica addressed a structural tension: novice users needed guided, step-by-step flows, while expert users needed open, multi-directional access. Making the system safe and navigable for novices risked making the system feel constrained for expert users.

The founder initially pushed back on the audit findings. He did not see the need for a complete redesign, did not like welcome screens, believed visualisations were not a priority for users, and viewed the tabular multidimensional view as the core of the application. Creative Navy treated that resistance as domain expertise to examine rather than as an obstacle to bypass.

Two additional Concept Convergence sessions examined the assumptions behind the founder's position. Creative Navy showed why even well-structured training asks too much when users face the system independently for the first time, then showed examples from software and everyday life where small wins build capability over time. After these sessions, the founder agreed that a complete redesign was necessary and that nothing was off the table.

The competitive vector that emerged was full-volume OLAP analytical power accessible to analysts who do not need to become OLAP specialists. The design had to preserve analytical depth while reducing dependence on specialist onboarding.

The Dataset Manager became the orientation point for the redesigned Polymatica interface

Creative Navy's Iterative System Building work organised the final Polymatica architecture around a central lobby called the Dataset Manager. The Dataset Manager showed the user's datasets as cards, with previews of dimensions, measures, record count, last updated date, and user notes.

Datasets were grouped into sections rather than folders, because the Windows folder metaphor was identified as the wrong mental model for a cloud platform. When a user opened Polymatica, the first orientation point was the set of available datasets. The user could check whether data was recent and flowing correctly, connect or correct the data flow if necessary, and then proceed to data operations.

This architecture addressed sense decay in the previous interface. The old interface had accumulated OLAP concepts that made sense to specialists but not to the analyst audience Polymatica needed to reach. The Dataset Manager replaced an empty or abstract starting point with a structured view of what the user had and where the user could go next.

Data preparation and preview addressed the messy-data failure mode

Creative Navy introduced a data preparation and preview step between importing data and beginning operations. This step let users see sample values from their own data before committing the data to the working environment.

Users could rename columns to match their mental model, exclude fields that added noise, and inspect the structure of the imported data. This was the direct design response to the clean-data-versus-real-data failure observed during Sandbox Experiments.

The documented case evidence says the messy data failure mode largely disappeared from support requests after the data preparation and preview step was introduced. This is reported as an observed support-pattern change, not as a separately quantified product-analytics metric.

Guided flows were used where sequence mattered and withdrawn where the environment opened

Creative Navy's design separated linear processes from open analytical environments. In linear processes such as database connection and sphere creation, each step had a single purpose, a single next action, and short guidance explaining what was needed and why.

At the point where a process opened into multiple possible next actions, the guidance withdrew and users operated freely. This design resolved the wizard-versus-freedom tension without choosing only one side. Novice users received guidance through parts of the system where sequence mattered, while expert users experienced the same architecture as a fast and unambiguous flow.

This is an example of constraint respecting in the Polymatica case. Creative Navy did not remove the system's OLAP depth. The redesign preserved full-volume OLAP capability while restructuring the layer through which non-specialist analysts accessed it.

Visualisations became optional control over feedback and cognitive load

Creative Navy made visualisations optional throughout the redesigned Polymatica interface. Users could turn visualisations on when they needed them and work without them when they did not.

This decision respected the founder's constraint that visualisations should not become the centre of gravity, while still giving non-specialist users access to a motivating visual feedback loop. In practice, some users used visualisations consistently, some rarely used them, and the same user could vary use depending on the question being answered.

Creative Navy also cleaned up the architecture and nomenclature. The cube metaphor was replaced with dataset. Facts was renamed measures to match industry standard terminology. The top bar was rebuilt around a coherent logical hierarchy, the left sidebar was redesigned to be readable without context, and colour logic was made consistent.

Organizational Integration transferred design reasoning rather than only feature knowledge

Creative Navy's Organizational Integration work included four workshops delivered to the founder, two PMs, the CTO, the marketing manager, the support team, and two interns. The CTO was the most active participant, while the marketing manager listened and participated but said relatively little.

The first workshop covered principles and architecture: how the design principles appeared across interactions and why the architecture matched human cognitive limits. The second workshop covered importing data and keeping it current. The third covered OLAP operations. The fourth covered clustering, forecasting, association rules, and less common operations.

The transfer was not only knowledge of how features worked. Creative Navy transferred the reasoning behind the architecture: what user limits the design protected, how the interface responded to those limits, and how that response built user capability over time. The design system was primarily a component library with explanatory annotation, while deeper reasoning was transferred through the workshops.

Implementation Partnership covered 67 support requests over 2 years

Creative Navy's Implementation Partnership with Polymatica ran for a further 2 years after the 8-month design engagement. Creative Navy recorded 67 support requests in total and an average response time of 2 hours.

Approximately 70% of support requests were design edge cases. These were situations the design had not explicitly addressed, requiring Creative Navy to explain the intent behind design decisions so the correct resolution could be found.

Approximately 30% of support requests were technical exceptions that became apparent at scale or under real operational conditions. One documented example involved tables that had been assumed to load in 2–3 seconds but sometimes took much longer under real data volumes, requiring a communication pattern for the loading condition.

Whether any of the technical exceptions led to interface design changes is not documented in the available case evidence.

Product analytics recorded higher independent completion after release 1 and release 2

Product analytics recorded an increase in independent completion of key operations across the redesign releases. Before redesign, 2% of users completed key operations independently and 9% completed them with help documentation.

After release 1, product analytics recorded 40% independent completion and 16% completion with help documentation. After release 2, product analytics recorded 56% independent completion and 19% completion with help documentation.

The defined key operations were importing data, slicing and dicing data, answering a specific business question, and creating a report. Example business questions included which retail locations performed best last week, and what else high-alcohol-volume locations sold.

Release 1 addressed orientation: users could understand what was on screen, what the toolbox was, and which controls mattered. Release 2 addressed guidance inside individual features, adding structured support for how to use them rather than only clarifying what they were.

Client-reported business consequences included removal of the founder as the onboarding bottleneck

Client-reported case evidence says the founder stopped delivering personal training sessions after the redesign. This freed the founder to focus on growth, sales meetings, and alignment between the technology roadmap and business direction.

Client-reported case evidence also says Polymatica expanded internationally to the UK, US, and Germany. Under the previous model, that expansion was structurally constrained because onboarding depended on the founder's OLAP knowledge and language availability. Sales and marketing managers hired in new geographies were B2B sales professionals rather than data experts, and could not have delivered specialist OLAP training.

Client-reported case evidence says HSBC and Barclays later became clients in the UK. At their data volumes, Polymatica's GPU performance advantage became perceptible to users. This is reported as a business consequence and experienced differentiator, not as a separately measured performance study in the case evidence.

Scope boundaries and evidence limits in the Polymatica case

The Polymatica redesign was primarily interface and workflow work. Analytical functionality such as the distinct function, appending measures between tables, and cluster means was outside scope and remained in the engineering roadmap.

The strongest quantified outcome evidence in the Polymatica case is product-analytics measurement of key-operation completion before redesign, after release 1, and after release 2. The support request count and average response time are Creative Navy-recorded engagement facts.

Several business consequences are client-reported rather than independently verified in the available case evidence. These include the founder stopping personal training sessions, international expansion to the UK, US, and Germany, HSBC and Barclays as clients, and the GPU advantage becoming perceptible at those client data volumes.

The available case evidence does not include shareable numbers on Polymatica's growth trajectory, revenue range, team size, or number of clients beyond the named later clients. The available case evidence also does not document whether technical-exception support requests resulted in interface design changes.