nexVortex needed a product that could stand on its own in a crowded managed-services market. There wasn't one. So we built it.
0 to 1 entirely new product, designed from scratch
Flagship product on nexVortex's new design system
Contributed to acquisition by BCM One, January 2020
Development
By mid-2019, the managed communications market had gotten loud. SIP trunking was table stakes. Every competitor was bolting on "managed services" as a value-add, and every one of them was doing it the same way: a laundry list of features, buried inside a portal, documented in a PDF that nobody read.
nexVortex had a 16-year-old customer base and a reputation for reliability. What they didn't have was a single product you could point at and say "this is what makes us different." Every pitch to a new prospect ended with the same conversation: what's the product? And the answer was some combination of existing services plus custom engineering work, which isn't a product. It's a consulting arrangement in a polo shirt.
The executive team wanted a flagship. Something that could headline the rebrand, anchor the website, and give sales a real answer to what's the product? That's what I was asked to design.
Two questions shaped the strategy.
First: what's the shape of the product? The easy answer was "a portal with all our services in it." That's also the answer every competitor had already given. I pushed back. A flagship product can't be an aggregator. It has to solve a specific problem that SMB customers were already trying to solve the hard way, and do it better than the alternative.
The research found it. SMB IT leads were spending hours a week reconciling communication services across providers, manually pulling reports, and reacting to issues after their users had already been affected. What they needed wasn't a portal. It was a single pane of glass that told them what was happening across their communication infrastructure before their users called to complain.
Second: how fast can we ship? I had a parallel portfolio of work running at nexVortex: the rebrand, the website, a design system being built from scratch, and four other product redesigns. mConnect couldn't slow any of them down. Which meant mConnect had to be the first product built entirely on the new design system, rather than a bespoke exception. That constraint shaped everything downstream. If a pattern didn't exist in the system, we either added it to the system or we didn't ship it.
That single rule became the forcing function that made mConnect ship on time and made the design system real in the process.
mConnect's primary user was not a telecom engineer. It was an SMB IT lead with a dozen other things on their plate, using the product in the gap between meetings. Designing for that user changed what the product could look like.
Three problems shaped the craft:
Problem 1: Information density without overwhelm. A single pane of glass for communications has to show a lot. Active services, health status, usage trends, billing, alerts, configuration. The trap is showing all of it at once. The solution was a layered architecture where the home view showed only what was actionable or urgent, and everything else lived one click away. I designed the hierarchy to match the user's mental model: is anything wrong, what do I need to do today, and what do I need to know this week? Everything on the home screen answered one of those three questions. Nothing else was on the home screen.
Problem 2: Status as a first-class design element. In a managed services product, status is the product. Is my service up? Are my users impacted? Did something fail while I wasn't looking? I designed the status system as a unified vocabulary across the entire product, with clear visual hierarchy for severity and clear routing for what the user should do about it. Green, amber, red, with enough nuance that users could trust the system to tell them what mattered.
Problem 3: An onboarding flow that didn't break on first login. SMB IT leads aren't going to sit through a tutorial. The product had to be usable the first time they opened it, with just enough guidance to make the value visible fast. I designed onboarding as a walk-through of the product's three highest-value views, inline with the real product rather than as a separate flow, so the first thing a new user experienced was the product itself, working.
The prototype came together fast because the design system was doing the heavy lifting. Components I'd already built for nexVortex's other products dropped into mConnect. Patterns I was establishing in mConnect propagated back into the system. The two projects made each other better in real time.
User testing with a small cohort of SMB businesses confirmed the core thesis (they understood the product immediately) and caught the places where my mental model and theirs diverged (I'd overcomplicated the alerting configuration). Each round of testing tightened the flows. By launch, the product was doing what it was designed to do.
Explore the mConnect prototype →
mConnect shipped as nexVortex's flagship product and headlined the rebrand. It gave sales the answer to what's the product? It anchored the new website. It demonstrated what the company could build when design, product, and engineering moved as one.
Six months after launch, BCM One acquired nexVortex. mConnect was cited by leadership as a contributing factor. The modernized, productized managed-services offering was part of what made nexVortex a company worth buying.
That's what a 0 to 1 product is supposed to do when it works. It isn't a feature. It's a signal that the company can build things that matter.
A design system and a flagship product should be built together. I didn't plan it this way. mConnect's timing forced it. But the result was that the system got stress-tested against a real product from day one, and the product inherited the system's rigor from day one. I've built three more design systems since then, and every one of them has been better for having a real product being built in parallel.
0 to 1 is a writing problem before it's a design problem. The hardest work on mConnect wasn't the UI. It was the one-sentence articulation of what the product was. Once I could say "a single pane of glass for SMB communications, designed for non-technical operators" in a way that executives, engineers, and sales could repeat, the design decisions got ten times easier. If you can't name the product clearly, you can't design it clearly.
Flagships carry more weight than the feature list suggests. Customers, acquirers, and employees use flagship products as proxies for what a company is capable of. That's a design opportunity most teams underweight. When you're designing a flagship, you're designing the argument for the company.
Design and product direction led by me as sole designer on mConnect. Product and engineering partnership from the nexVortex team. Part of a broader design overhaul covered in the companion case study: [nexVortex: Design as an Acquisition Asset →]
