Signifi
Get reliable Wi-Fi at home.
Problem
When COVID-19 closed offices and schools in March 2020, home Wi-Fi quietly became business infrastructure. Professionals, students and teachers were suddenly working, studying and teaching over connections nobody had provisioned for the job. A frozen screen mid-lesson or a dropped client call stopped being an annoyance and started being the work not happening. The people paid to fix networks could see none of it: network administrators had deep visibility inside the building and none at all past an employee's front door, so every ticket arrived on a network they could not reach, measure or change. What was missing was an affordable way to see a home network from the outside and act on what it showed.
Solution
Signifi is one system with two faces. Signifi Agent is a lightweight desktop app the remote worker runs: it scans the home network from inside the house and posts the result up for analysis. Signifi Cloud is the dashboard IT support works from, where those scans arrive as a fleet they can triage. Both read the same scan record. What changes between them is how much of it surfaces, so a teacher gets a verdict and a network administrator gets the evidence underneath it. One payload with two readings of it is what kept both halves simple, and it is the reason a pass in the Agent and a pass in the Cloud cannot drift apart.
Design Thinking
Empathize
We started by watching rather than specifying. Before writing a single requirement we spent time with the people who would use this: remote workers living with the problem daily, and the IT staff fielding their tickets. The goal at this stage was not to validate an idea we already liked. It was to understand a working day well enough to know which parts of it were genuinely broken.
User Interviews
We interviewed 30 people, split between high-school teachers and work-from-home professionals, digging for behaviors rather than opinions. Each person walked us through a bad Wi-Fi day: what they noticed first, what they tried, who they called, and what happened next. A short questionnaire kept the sessions comparable, and recording them meant we could go back for the details we missed live. Two answers came up again and again, and they shaped everything after: almost nobody could tell whether the fault was their Wi-Fi or their internet service, and almost nobody knew who to ask.
User Personas
Two personas came out of the interviews, and we were building for both. Sanjay keeps a high school's staff online. Jennifer teaches there. They described the same problem from opposite ends of the same ticket, and the fix had to work for both of them at once: one needs reach, the other needs reassurance.
Sanjay
IT Manager, high school
I can see every access point in the building, and nothing in the homes my teachers work from.
Sanjay diagnoses Wi-Fi for a living. He knows what channel overlap looks like, he owns the spectrum analyzers, and inside the school he can find a bad access point in minutes. None of that expertise reaches past the building's front door. He is still measured on how fast tickets close, and every ticket now lands on a network he has no access to, no authority over, and no way to see.
Goals
- See every teacher's home network without visiting it
- Separate a Wi-Fi problem from an ISP problem on sight
- Resolve it without dictating router settings over the phone
- Point at evidence when the fix isn't his to make
Frustrations
- Tickets that say only "the internet is slow"
- Diagnosing a network he cannot reach or measure
- Relying on the teacher to describe what they see
- Owning an outcome he has no control over
Jennifer
High-school teacher
I just want to know it'll hold up before class starts.
Jennifer teaches back-to-back classes over video, where a frozen screen costs her the lesson rather than a minute. She shares one router with a house full of family devices and has never opened its settings page. She has no interest in learning Wi-Fi and shouldn't have to. What she needs is to know, before first period, that the next hour will hold.
Goals
- Get through a lesson without freezing or dropping out
- Know which room in the house to teach from
- Check the day will hold up before first period
- Hand IT something useful without diagnosing it herself
Frustrations
- No idea whether to blame the Wi-Fi or the ISP
- Advice online assumes knowledge she doesn't have
- Competing with the whole house for bandwidth
- Being asked to describe a problem she can't see
Define
Two personas are a story. Thirty interviews are evidence, and only if you go back through them looking for patterns rather than the anecdotes you happen to remember. The figures below are how often a theme surfaced across all 30 participants. The observations under them are what those figures turned out to mean in practice, and they are what the product had to answer for.
Reported network disruptions while working from home
Reported uncertainty about whether the Wi-Fi or ISP is causing issues
Reported difficulty getting Wi-Fi support
- Anyone who presented over video worried about stability, not speed. For a teacher mid-lesson, freezing or dropping out costs the class, so a connection that is fast on average but unreliable for ten seconds is the worse outcome.
- Teachers had no framework for diagnosing Wi-Fi and no reason to acquire one. Faced with a problem they could not name, most restarted things until something worked, which let the same issue recur without ever being understood.
- Households competed for bandwidth in ways their occupants could not see. Participants without children at home generally reported stable connections. The ones describing dropouts were sharing a router with kids, usually at predictable times of day.
- Even the technical participants found this slow. They owned the right tools and could read them, but answering one question meant opening several programs and correlating the output by hand, which nobody does in the middle of a workday.
Ideate
None of those insights are features. Each one is a question somebody kept asking out loud, so we worked outward from the questions rather than inward from a feature list. Each one below had to survive the same test: name the capability that answers it, or drop the question.
Problems
- Where in the house is it actually good enough to work?
- Will my connection hold up for the presentation I have in an hour?
- How do I know today will go smoothly before it starts?
- This is beyond me. How do I get help without having to explain it?
Solutions
- Rank rooms by measured signal and throughput, so the answer is a place rather than a number.
- Measure available bandwidth against what video conferencing actually needs, and answer pass or fail.
- Make a scan something you run once before work, with a result you can read at a glance.
- Send the whole network picture to IT support in one action, so the person who can fix it starts with the evidence.
Signifi Agent & Signifi Cloud
Ideation exposed a conflict we could not design our way around. IT support needed the full detail to troubleshoot properly, and that same detail in front of a teacher would be noise at best and alarming at worst. One interface could not serve both without failing one of them.
So the product split along the line the audiences already split on. Signifi Agent is what the remote worker sees: one scan, a plain result, and guided steps when something needs fixing. It assumes no knowledge of Wi-Fi and asks for none. It also has to run on the employee's own machine, on whatever they own, which is the constraint that later decided the Agent's stack.
Signifi Cloud is what IT support sees: the same scans with the full underlying data, across every employee, with enough history to spot a pattern. The split was an architecture decision as much as a design one. Scanning happens where the network is, history and comparison live where the fleet is, and the two meet over a single payload. Neither audience had to tolerate an interface built for the other, and both halves got simpler for it.
Design Considerations
The technical gap between the two audiences drove most of the decisions. Anything a remote worker touched had to be readable by someone with no interest in networking, which in practice meant one obvious action per screen and a verdict before any figures.
We leaned deliberately on the aesthetic-usability effect: people judge an interface that looks considered as easier to use, and extend it more patience when something goes wrong. Our users were already frustrated before they opened the app, so that goodwill was worth designing for, and type, spacing and alignment got the same attention as the flows.
Where the two products overlapped we treated the shared language as a contract rather than a style guide. A pass in the Agent means exactly what a pass in the Cloud means, because both surface the same field from the same scan instead of each deciding locally what counts as good enough. A teacher and their IT manager can argue about one scan without either of them translating, and no amount of divergent front-end work can pull the two definitions apart.
User Journey
Mapping the end-to-end journey let us see exactly where a remote worker hands off to IT support, and which moments in the flow needed the most guidance.
Picking the journey back up on Sanjay's side showed where Signifi Cloud had to earn its keep: triaging Wi-Fi against the ISP in a single view, then pushing fix steps back into the employee's Agent rather than talking someone through a CLI over the phone.
Prototype
Moqups
Layout and hierarchy, deliberately grey.
Figma
Real type, color and scan data.
Figma prototypes
Clickable end-to-end tasks.
Lo-fi wireframes
Both products got wireframed in Moqups first, and the fidelity was the point. Working in grey kept every argument on structure: what belongs on the first screen, how much a remote worker should ever see at once, where IT needs depth. Screens this cheap are easy to abandon, so we abandoned plenty, which is far less expensive than discovering the same thing in built software.
Hi-fi mockups
Once the structure held, we rebuilt the screens in Figma with real type, color and data. This is where the Agent picked up its single primary action and the Cloud dashboard picked up its pass and fail language.
Interactive prototypes
We wired the Figma screens into clickable prototypes so participants could run a whole task, from launching the Agent to reading a scan report in the Cloud, instead of reacting to a static picture. Watching people move between screens is what surfaced the problems below.
Usability Test
The prototypes went back in front of the same mix of teachers and work-from-home professionals we had interviewed, plus IT staff for the Cloud side. Each participant ran a scan and then tried to explain what the result meant. That second half is the part that mattered: a person can complete a task correctly and still have no idea what the screen just told them. Every hesitation became a change, and all eight are below.
What changed
Added a trial path
People who had not bought anything yet hit a dead end on the first screen. Starting a trial now sits alongside register and log in.
Put benchmarks next to every result
A bare number told nobody whether it was good. Each card now carries the requirement it was measured against.
Showed signal in both % and dBm
Teachers read the percentage and ignored the dBm. IT wanted the opposite. Showing only one alienated the other group.
Led with pass and fail, not the reading
Participants scanned for a verdict before they read any figures, so the status became the largest element on each card.
Said what the connection can actually do
Numbers were still abstract, so we translated them into whether video calls, streaming and gaming would hold up.
One primary action per screen
Competing buttons made people hesitate. The Agent now has a single obvious Scan, and everything else steps back.
Implement
By the time the stack came up, most of it had already been decided by what we had and by what we could not afford to get wrong. Signifi Cloud went on Laravel and Vue because we had shipped on both and knew their failure modes, which is a duller reason than novelty and a better one. The Agent went the other way for a harder reason. The Wi-Fi scanning already existed as .NET libraries that read the adapter properly, and that was the riskiest code in the product: the part that, if it were subtly wrong, would make every verdict above it a lie. .NET MAUI let us wrap working code in a desktop app on Windows and macOS instead of reimplementing it twice against two operating systems' wireless APIs. The constraint picked the stack. The job was making sure the constraint never showed up in the interface.
Laravel
Accounts, the API, and storing scan results.
Vue
The dashboard IT support lives in.
.NET MAUI
One desktop app on Windows and macOS, wrapping the scanning DLLs.
MVP first
In front of real teams before polish.
Why this stack
The expertise was already there
Nobody had to learn a framework on the clock. The team could argue about the product instead of about tooling, which is where the argument was actually worth having.
We had shipped on it before
Laravel and Vue were behind products we had already put in front of customers, so we knew the failure modes and roughly what things would cost to build.
The backend did not need to be clever
The Agent scans and posts the result straight to the cloud, so the backend only needed accounts, an API and somewhere to keep the data. Laravel gives you that on day one.
The scanning DLLs picked the Agent's stack
The hard part already existed as .NET libraries that read the Wi-Fi adapter properly. MAUI let us wrap code that worked instead of rewriting the riskiest part of the product.
Speed to market beat novelty
Remote work was the moment, and it was not going to wait. A product that arrived a year later on a more fashionable stack would have missed the problem it was built for.
Design stayed close to the build
Working in a stack the team already knew meant a change out of testing could be tried in days rather than scheduled for a later release. Every one of the eight findings above shipped, which is the only thing that made running the tests worth the time.
Success Story
Signifi shipped. It went on sale as Signifi Business in July 2021, priced so a small IT team could try it on a handful of remote staff rather than sign a contract. Nine months later, on 11 April 2022, MetaGeek was acquired by Auvik Networks, the Ontario-based network monitoring company, and the Wi-Fi work Signifi came out of became part of a much larger platform.
- Mar 2020
The problem shows up
Schools and offices close. Home Wi-Fi becomes everyone's Wi-Fi, and nobody's to support.
- Jul 2021
Signifi Business ships
$150 a year for five seats, with the 14-day trial that usability testing asked for.
- Apr 2022
Auvik acquires MetaGeek
Terms undisclosed. The Boise office stays, the team joins Auvik, and the products keep shipping.
- After
Wi-Fi expertise inside a platform
MetaGeek's 100,000+ customers and 15 years of wireless work fold into Auvik's network management suite.
Acquired by Auvik
Together with MetaGeek, we will build an even better Auvik platform by adding their strong wireless expertise to our team.
Signifi was not incidental to the deal. The bet behind it was that the corporate network now ends at an employee's kitchen table rather than at the building's edge, and Auvik was making that same bet. MetaGeek's founder later wrote that Auvik had reached that conclusion about the expanding corporate network independently, which is what made the two companies fit. The home network Signifi was built to make visible had become a category worth assembling a platform around.