Integrations Hub,
a codeless platform,
made coherent.

Integrations Hub connects OpenWater to the systems its customers already run on: Salesforce, iMIS, Microsoft Dynamics, HubSpot, QuickBooks, and about a dozen more. Before it, wiring OpenWater to any of those meant custom code for each one. The Hub replaced that with configuration.

The concept and the engineering were BitBang's, and both were solid. What was missing was the layer people actually touch. Every page felt like it came from a different product, controls sat where they were built rather than where users would look for them, and the whole thing did not read as part of OpenWater.

The problem was coherence, in two directions at once: making the Hub feel like one product internally, and like OpenWater externally.

This is a sub-product of OpenWater, the application and review platform I redesigned in full. Integrations Hub is where an admin connects OpenWater to their organization's other systems. Single sign-on, data pushbacks, record lookups, credentials.

It matters because integration is often the deciding factor in whether a platform gets adopted at all. An association already running iMIS or Salesforce will not move to a tool that cannot talk to them. The Hub is what makes OpenWater viable for those buyers, so it needed to feel as trustworthy and finished as the platform it extends.

• Mine. The entire interface and interaction design. Every screen, rebuilt from scratch. Applying the OpenWater design system to a product that had never used it, and building the new components the Hub needed that the system did not already have. The design of the new features: the workflow builder, the dashboard, custom fields, and webhooks.
• Shared. Feature requirements, defined with the OpenWater and BitBang development teams. I designed what they needed built.
• Set by others. The product concept and its functionality. Integrations Hub was BitBang's, the idea held at the founder level and built out by their engineering team before I arrived, and it was implemented well. I did not invent what the Hub does. I kept every function intact and redesigned how it is experienced.

Nothing felt connected. The functionality was there and mostly correct, but each page had been built on its own. No shared layout logic, no consistent placement, no visual through line. Some controls did not behave the way a user would reach for them, and some sat in the wrong place entirely. The system worked, but using it meant relearning the interface on every screen.

And it did not belong to OpenWater. Sitting next to the platform it extends, the Hub looked like a different product from a different company. For a tool whose whole job is trust and connection, that gap undercut it.

How I framed it. Not "restyle the pages." The question was: how do you take a working system built page by page and make it read as one coherent product, and as a native part of OpenWater, without losing any of the functionality that already worked.

I started from scratch on the surface and kept the engine. Every function BitBang had built stayed. What changed was the experience around it: I rebuilt each screen against how users would actually expect it to behave, applying standard product patterns where the original had improvised. Where a control did not react the way people reached for it, or sat somewhere it should not, I moved it. The point was not novelty. It was making a capable system predictable.

Success was coherence, judged by eye rather than by metric. Does it read as one product. Does it look and feel like OpenWater. Does each screen behave the way the last one taught you to expect. The bar was whether the Hub finally felt like it belonged to the platform it extends, and it did.

Adopting the OpenWater system into a product that never had one. The fastest path to coherence was also the correct one: put the Hub on the design system I had already built for OpenWater. That solved the belonging problem at the root, not with a color pass but with shared foundations. Where the Hub needed things the system did not cover, integration-specific patterns with no equivalent on the main platform, I built new components rather than bending existing ones out of shape. The system extended to fit the Hub instead of the Hub pretending to be something it was not.

The workflow builder. A new feature the dev teams needed: a node-based canvas where users assemble integration workflows by connecting steps. This is a different interaction model to the rest of the Hub, closer to a diagramming tool than a form, and it still had to be built from the same design language so it did not become another disconnected island. The whole reason the Hub needed a redesign was pages that each felt like their own product. A powerful new feature that ignored that lesson would have reintroduced the exact problem I was there to fix.

A dashboard where there was none. The Hub had no landing view, so I designed one: active connectors, total logged-in users, total pushbacks, and the other signals an admin needs to see the health of their integrations at a glance. It gave the product a front door and a reason to open it, instead of dropping users straight into configuration.

Custom fields and webhooks. Two more capabilities designed into the system: custom fields per connector type, so each integration can carry the data specific to it, and the ability to add new webhooks. Both had to feel native to the patterns already established, not like features stapled on afterward, which is the trap the original build had already fallen into once.

• Full UI redesign. Every screen rebuilt for consistency in layout, placement, and behavior.
• OpenWater design system, applied. The Hub rebuilt on the same foundations as the core platform, so it reads as one family.
• New Hub-specific components. Built for integration patterns the core system did not cover, without breaking from its language.
• Workflow builder. A node-based canvas for assembling integration workflows.
• Dashboard. A new landing view surfacing active connectors, logged-in users, total pushbacks, and other integration health signals.
• Custom fields. Per-connector custom fields, so each integration carries its own data model.
• Webhooks. Added the ability to create and manage new webhooks.

Connectors span roughly eighteen platforms, including Salesforce, iMIS, Microsoft Dynamics, HubSpot, and QuickBooks, across OAuth, SAML, and web service methods. The shared design system is what lets all of them, and every new feature, read as one product.

Everything shipped. A full redesign, the Hub rebuilt on the OpenWater design system, plus four new capabilities designed into it: workflow builder, dashboard, custom fields, and webhooks.

What the work set out to do and did: the Hub stopped looking like a separate product and started reading as part of OpenWater, and a system that had felt different on every page became one coherent experience. OpenWater's leadership endorsed the result.