Dancerace

Dancerace Jacko as a greenfield invoice management portal

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.

Dancerace engaged Creative Navy to design Jacko, a greenfield B2B invoice management and accounts receivable portal for small businesses. Jacko was built on top of Dancerace's existing C3 backend system. It was not a redesign of an existing interface, and existing Dancerace customers were used as a source of information during discovery rather than as the basis for preserving prior interface expectations.

Jacko manages the distribution, confirmation, dispute, and settlement of sales invoices across a three-party structure. The financier operates Dancerace's existing C3 financing system and manages collections on behalf of suppliers. The supplier is Dancerace's direct client, typically a small business that issues invoices and wants to be paid. The debtor/customer is the small business that receives invoices and must act on them.

The three-party model was broadly understood at the start of the engagement. Creative Navy's design work did not redefine the roles, but it surfaced detailed questions about how each role could complete specific actions, which states each interaction needed to have, and how one user's experience connected to another user's experience.

Five-month Critical Systems Design engagement across all five phases

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.

The Dancerace engagement lasted five months and included Sandbox Experiments, Concept Convergence, Iterative System Building, Organizational Integration, and Implementation Partnership. Creative Navy applied the full sequence because Jacko needed product definition, interaction design, stakeholder alignment, system-level specification, and implementation support rather than isolated screen design.

The engagement began with strong client domain knowledge and a large premium-feature vision. Dancerace had already identified possible capabilities including DocuSign integration for purchase orders, a supplier marketplace, a payment calendar with RAG grading, mobile SMS notifications, live FX conversion, B2B debt insurance, Companies House credit checking, and other features. The risk was that this scope was not yet anchored to a model of what users would do when they first encountered the system.

Creative Navy's Critical Systems Design method treated this gap as the blanks phenomenon. Dancerace's stakeholders had directionally correct intuitions about the domain, the users, and the commercial opportunity, but they could not yet specify interaction states, role-to-role consequences, or the likely behavioural impact of competing design decisions. Wireframes made those blanks visible enough for stakeholders to react, disagree, and decide.

Stakeholder tension between feature visibility, configuration, and trial conversion

Dancerace's stakeholder group was divided between two positions that both had operational logic. One group wanted advanced features to appear prominently so users would understand the platform's sophistication, value the premium package, and see enough capability before making a purchase decision. Another group wanted users to complete full profile setup and configure rules, settings, and automation logic before doing anything else, because automated operations required configuration data.

A third pressure sat beneath both positions: Jacko needed to convert free trial users to paying customers quickly enough to validate the business model. The trial was self-serve and required no credit card, so conversion depended on users reaching value on their own before the trial ended.

Creative Navy's design work showed that the apparent conflict was not only a stakeholder preference issue. It was a product coherence issue. Premature feature exposure and mandatory upfront configuration both risked placing system demands ahead of the user's immediate need to understand their financial position and required actions.

Sandbox Experiments identified the user's hierarchy of needs

Creative Navy used Sandbox Experiments to explore three challenge areas: onboarding and initial setup, the returning user dashboard, and the recurring invoice action flow. Multiple concepts were explored through rapid prototyping and testing.

User testing, user interviews, and prototype observation produced a consistent hierarchy of user needs. Before users could engage with advanced features, setup work, or upsell prompts, they needed to answer three questions: what do I owe, what is my cost, and what tasks do I absolutely need to do right now.

This ordering was not simply stated by users as a preference. It was observed through prototype interaction, confirmed in interviews, and triangulated across the three research methods described in the case evidence. The design implication was direct: a dashboard that placed configuration work or advanced feature showcasing ahead of those questions would lose users before it delivered value.

The returning user dashboard therefore had to answer immediate financial and task questions first. More detail could exist, but it had to appear after the user had found the information needed to act.

Premature complexity reduced engagement in prototype reasoning

Creative Navy's Sandbox Experiments showed that when advanced features competed visually with immediate user needs on the same screen, users disengaged from the advanced features and from basic system use. The stakeholder desire to showcase capability produced the opposite of its intended effect when the screen lacked a clear information hierarchy.

Creative Navy demonstrated this to Dancerace through analytical reasoning tied to wireframes. The discussion was not framed as an abstract principle about simplicity. It showed what a particular user type would see on a specific screen, what that user would likely do next, and what the consequence would be for engagement, trust, and conversion.

Dancerace had also produced an internal wireframe before the engagement. That wireframe was dense and feature-complete, placing sparklines for multiple invoice categories, a payments chart, a calendar, tasks, recent documents, and other elements on a single dashboard. Creative Navy did not build or test that wireframe. It functioned as a prior iteration that showed what Jacko could contain and also showed a direction to avoid: a flat inventory of features without priority ordering or a model of what users needed first.

Domain learning modelled debtor behaviour rather than formal business norms

Creative Navy's domain learning identified that debtors in invoice relationships do not always behave according to formal business norms. The case evidence describes debtors delaying, acknowledging without committing, using informal relationship signals, and going quiet when they know they will pay late rather than opening a formal dispute.

Creative Navy's design work modelled this behaviour instead of designing against it. The system allowed a debtor to change an invoice status to "accepted." This status did not trigger payment, but it allowed the debtor to signal good faith without creating a formal conflict. The supplier could then see whether the debtor had seen the invoice, accepted it, ignored it, or disputed it.

This design decision made informal financial behaviour operationally visible to the supplier. It also avoided a workflow failure in which the system fights the user's real task by forcing formal behaviours that do not match how debtor relationships operate under time pressure and limited attention.

Concept Convergence resolved the false opposition through chasing routines

Creative Navy's Concept Convergence phase resolved the stakeholder tension through a specific design concept: pre-built chasing routine templates. Instead of requiring users to configure complex rule-based automation from scratch before experiencing value, Jacko offered selectable patterns for invoice follow-up. A user could pick a template and immediately have functioning automation without understanding the underlying rule structure.

The detail remained available for users who wanted to go deeper. It was not required for first use. This distinction showed stakeholders that simplicity and feature richness were not opposites. Simplicity could be an entry path into complexity when the system introduced depth after trust had been established.

This was an instance of tension-driven reasoning in Creative Navy's Critical Systems Design method. The stakeholder conflict was not resolved by compromise between feature visibility and configuration depth. It was resolved by identifying the false assumption driving the conflict and designing a sequence in which users reached advanced capability at the moment they were ready for it.

The competitive vector that emerged was sequential value delivery. Jacko's interface introduced each layer of capability when the user had enough context and trust to use it, rather than placing all capability in front of the user at the first encounter.

One interface served two user types through progressive access to detail

Dancerace's user base contained two meaningfully different user types. The case evidence describes John Smith, a small business owner representing approximately 25% of users, who wants to complete a small number of tasks quickly and act on the most urgent dashboard item. The case evidence also describes Janet, an accountant or finance director representing approximately 75% of users, who needs more systematic access to detailed invoice data.

Dancerace did not have the development capacity to build two separate interfaces. Creative Navy treated that as a constraint respecting design parameter rather than as an obstacle. The dashboard surfaced highlights that answered the user's immediate questions, and each highlight was clickable, leading to either a detailed page or a modal with full data.

The same interface could therefore support different depths of use. John Smith could read the highlights and stop. Janet could click into the detail. Neither user type was forced to encounter the other's level of detail before reaching value.

Iterative System Building produced a design system with implementation rationale

Creative Navy's Iterative System Building phase produced full interactive wireframe prototypes across the Jacko flows. The documented product specification covered account management, sales and purchase ledger, payments, messaging, notifications, customer and supplier management, templates, and a configurable dashboard.

The design system was documented with component coverage, consistent page logic, and written rationale explaining the design decisions. According to Dancerace, developers rarely needed to contact Creative Navy during implementation. This is client-reported evidence of implementation clarity rather than an independently measured support metric.

The design system functioned as a navigation map for the implementation team. The case evidence states that teams could extend the system intelligently because they understood what the design logic was protecting.

Wireframes made organisational trade-offs visible enough to decide

Creative Navy's Organizational Integration work addressed the stakeholder alignment problem by making trade-offs observable. Dancerace's stakeholder disagreements had been expressed as competing principles: show advanced features, require configuration, or reduce trial friction. Wireframes converted those principles into visible consequences for users.

The alignment mechanism was not persuasion toward a predetermined Creative Navy position. Creative Navy's design work gave stakeholders a medium for deciding what the product was, who it was for, and how its mechanic generated value before asking for payment. When a stakeholder decision affected the user experience, the wireframe made the consequence specific enough to discuss.

The chasing routines concept was the decisive artefact because it dissolved the assumed opposition between an approachable first experience and a feature-rich product. Dancerace's stakeholders aligned around a product structure in which baseline value came first and premium depth followed through progressive exposure.

Implementation Partnership supported client-run A/B testing

Creative Navy's Implementation Partnership included test scripts that Dancerace later used to run A/B tests without Creative Navy's direct involvement. The tests addressed small but consequential interaction questions: default column configurations, whether detail boxes should be collapsed or expanded by default, and whether a search field needed to be visible or could be represented as an icon.

The A/B test results were directional and informed final implementation decisions. Specific quantitative findings are client-held and are not available for publication. The case evidence should therefore not be read as a published quantitative A/B testing dataset.

Client-reported 36% demo-to-paying conversion after release

Dancerace reported a 36% demo-to-paying conversion rate measured six months after release across self-serve free trial users who signed up without providing a credit card. The case evidence states that industry benchmarks for self-serve SaaS conversion at the time of release were 15–20%, and that Dancerace's own expectation before launch was also in that range.

The 36% figure is client-reported and was measured by Dancerace against Dancerace's own trial-to-paid conversion tracking. Creative Navy did not independently verify the number. The figure is meaningful in this case because it is reported against both the industry expectation and Dancerace's own expected range, rather than as an isolated percentage.

The case evidence connects the conversion outcome to an operational mechanism: users reached value during the trial because the dashboard answered immediate financial and task questions, did not require mandatory upfront configuration, and introduced complexity progressively through templates. This causal connection is described in the case evidence, while the metric itself remains client-reported.

Operational and organisational outcomes recorded in the case evidence

The Dancerace case records several operational outcomes. Users could understand their financial position and urgent tasks immediately on login without training or configuration. The system accommodated debtor behaviours such as acknowledgement without commitment and symbolic good-faith signalling. The same interface served both a time-pressured small business owner and a detail-oriented finance director through progressive access to detail.

The Dancerace case also records organisational outcomes. A divided stakeholder group reached alignment on what the product was, who it was for, and how value would be delivered and monetised. Dancerace also transferred capability to run user testing after the engagement by using Creative Navy-authored test scripts independently.

The product launched with a clearer distinction between baseline features and premium features. The case evidence states that this structure was absent and contested at the start of the engagement.

Evidence boundaries for the Dancerace case

The Dancerace case contains a client-reported conversion metric, Creative Navy-recorded design process evidence, user research observations, and client-reported implementation feedback. The strongest numeric outcome is the 36% demo-to-paying conversion rate, but that number was not independently verified by Creative Navy.

The A/B testing evidence is limited. Dancerace ran the tests independently using Creative Navy-provided scripts, and the available case evidence describes the results as directional. Specific quantitative findings from those tests are not available for publication.

The Dancerace internal wireframe should not be attributed to Creative Navy. It was produced by Dancerace before the engagement and was used by Creative Navy as a prior iteration that helped identify a direction to eliminate.

Related documentation

This case is related to enterprise software because Jacko is a greenfield B2B invoice management and accounts receivable portal built on an existing backend system. It is related to multi-stakeholder operational environments because the financier, supplier, and debtor/customer each interact with the invoice lifecycle from a different operational position.

The case is also related to fintech and financial services because the product concerns invoice distribution, acknowledgement, dispute, remittance intent, settlement, payment, debtor behaviour, and supplier visibility.

For outcome evidence, the Dancerace case is relevant to verifiable performance claims because the 36% conversion figure is a client-reported performance result with a stated benchmark context. It is also relevant to lower training burden because the trial design aimed to let users reach value without a credit card, without mandatory configuration, and without training.