Early customer research revealed a critical insight: we weren't building for one user type, we were building for two fundamentally different audiences with conflicting needs. Developers wanted speed and control, favouring code and APIs. Business analysts, operations managers, and startup founders with limited IT budgets needed GUI-based simplicity for tasks they'd perform themselves.

This created a product strategy dilemma. Building separate interfaces would double development costs and split our go-to-market focus. The insight that shaped our approach: these weren't actually different use cases, they were different skill levels approaching the same problem. I designed for progressive complexity, where the core workflow optimised for the least technical user, with advanced features accessible to power users who knew where to look.

Targeting SMEs and smaller fintechs meant we couldn't assume dedicated IT teams. The platform needed to enable organisations to bring data together from any number of sources so it could be viewed, transformed and shared across departments and between companies, all without requiring specialist expertise. This decision influenced every subsequent design choice and became a competitive differentiator: competitors either built for developers or dumbed down their platforms. We could serve both markets from a single product, making enterprise integration accessible to organisations where this capability had previously been out of reach due to complexity and expense.

The team adopted a lean, iterative process managed through Asana. Rather than lengthy specification documents that became instantly outdated, we used task-based collaboration where requirements, designs, and feedback lived alongside the work itself. This reduced context-switching overhead and created a single source of truth.

This working method was particularly valuable given our distributed team. Asana's structure forced clarity in task definition and made dependencies explicit, preventing the coordination failures common in remote teams. The approach became our operational advantage: we could move faster than competitors with larger, co-located teams because our process created less friction.

The data creation wizard was SPINR's core value proposition and its most complex UX challenge. Users needed to connect disparate data sources, cleanse messy data, and create joined datasets, all without SQL knowledge or developer intervention. This was the heart of our mission to set critical data free from application and departmental silos.

The design challenge was making an inherently complex workflow feel manageable. I broke the process into discrete steps with clear progression, preventing users from feeling overwhelmed by the full scope upfront. Each step provided immediate feedback, showing users exactly what their transformations were doing to the data. This transparency was essential: smaller organisations couldn't afford to debug opaque systems or rely on external consultants to understand what their integration platform was doing.

The critical insight: rather than hiding complexity, make it visible but structured. Instead of a "smart" system that made decisions opaquely, I designed transparent controls where users could see and understand each transformation. This built trust and made debugging possible, directly addressing the "black box" problem that plagued competing platforms and caused adoption resistance among technical users.

For SMEs and startups trying to launch products quickly, the wizard needed to enable efficient creation, management and distribution of APIs. Real-time data services working seamlessly would drive better collaboration within teams and allow new products and services to be launched faster than traditional integration approaches allowed. The interface needed to support this velocity without sacrificing reliability.

I produced extensive wireframes that served dual purposes: communicating design intent to developers and validating feasibility with technical leadership. Design sessions with the CEO and CTO forced me to balance ideal user experiences against technical and timeline constraints, a tension that improved both the designs and our collective understanding of what was actually buildable.

When possible, I validated designs with prospective customers through clickable prototypes. This early exposure served a strategic purpose beyond UX validation: it generated customer interest before launch, converting design artefacts into sales tools. Several early customers committed based on prototype demonstrations, proving demand before we'd written production code.

These prototypes also functioned as specifications for development, reducing the interpretation gaps that typically exist between design and implementation. This accelerated development and reduced rework.