Go back
Go back
Fastlink Haven — Designing a WiFi Management Dashboard That Actually Works for Everyone in the Room
Fastlink Haven — Designing a WiFi Management Dashboard That Actually Works for Everyone in the Room
Fastlink Haven — Designing a WiFi Management Dashboard That Actually Works for Everyone in the Room
Overview
Overview
Most businesses don't know who's on their WiFi right now. They hand out paper vouchers, manually log users into spreadsheets, and find out about connection problems only when a customer complains. Fastlink built Haven to change that. I was the designer who figured out what "change" actually had to look like
Most businesses don't know who's on their WiFi right now. They hand out paper vouchers, manually log users into spreadsheets, and find out about connection problems only when a customer complains. Fastlink built Haven to change that. I was the designer who figured out what "change" actually had to look like
My role
My role
Product Designer (Founding) — I owned the design end-to-end, from the first stakeholder conversation to the final Figma handoff.
Product Designer (Founding) — I owned the design end-to-end, from the first stakeholder conversation to the final Figma handoff.
Project Timeline — 4 Weeks
Project Timeline — 4 Weeks
Week 1: Discovery + Stakeholder Research
Week 1: Discovery + Stakeholder Research
Week 3 — Wireframes + First Draft + Founder Review
Week 3 — Wireframes + First Draft + Founder Review
Week 2 — User Mapping + Information Architecture
Week 2 — User Mapping + Information Architecture
Week 4 — High-Fidelity UI + Handoff
Week 4 — High-Fidelity UI + Handoff
The Challenge
The Challenge
The brief sounded simple at first, design an admin dashboard for WiFi management. But the moment I started thinking about who would actually sit in front of this thing every day, it got complicated fast.
You've got a front desk staff member who needs to add a user in under 30 seconds while someone is literally standing in front of them waiting. You've got an operations manager who needs to see what's happening across 5 different locations without losing their mind. And you've got an IT admin who needs to trace a failed login from 3 days ago and understand exactly what went wrong.
Three completely different people. Three different definitions of "useful." One dashboard that had to work for all of them — without making any of them feel like they're using someone else's tool.
The brief sounded simple at first, design an admin dashboard for WiFi management. But the moment I started thinking about who would actually sit in front of this thing every day, it got complicated fast.
You've got a front desk staff member who needs to add a user in under 30 seconds while someone is literally standing in front of them waiting. You've got an operations manager who needs to see what's happening across 5 different locations without losing their mind. And you've got an IT admin who needs to trace a failed login from 3 days ago and understand exactly what went wrong.
Three completely different people. Three different definitions of "useful." One dashboard that had to work for all of them — without making any of them feel like they're using someone else's tool.
What I Did
What I Did
I talked to people before I opened Figma
My first move wasn't sketching , it was asking questions. I sat with stakeholders and tried to understand how this product would actually be used in the real world, not just how it was described in the PRD. What came out of those conversations was something important: the biggest frustration wasn't missing features. It was that the tools they'd tried before forced non-technical people to think like IT engineers. That single insight became my compass for every decision that followed.
I talked to people before I opened Figma
My first move wasn't sketching , it was asking questions. I sat with stakeholders and tried to understand how this product would actually be used in the real world, not just how it was described in the PRD. What came out of those conversations was something important: the biggest frustration wasn't missing features. It was that the tools they'd tried before forced non-technical people to think like IT engineers. That single insight became my compass for every decision that followed.
I mapped every user to every feature
I went through the PRD line by line , not asking "how do I design this?" but "who actually needs this, when, and why?" That exercise was revealing. About 60% of the features were admin-only. Another 30% were operations-level. Only about 10% needed to be front and center for everyday staff. Once I could see that clearly, the navigation and information hierarchy basically designed itself.
I mapped every user to every feature
I went through the PRD line by line , not asking "how do I design this?" but "who actually needs this, when, and why?" That exercise was revealing. About 60% of the features were admin-only. Another 30% were operations-level. Only about 10% needed to be front and center for everyday staff. Once I could see that clearly, the navigation and information hierarchy basically designed itself.
I designed for the hardest user first
I made the front desk staff member my north star. My thinking was — if someone with zero technical background can add a user quickly and without confusion, then everyone else will be fine. So I stripped the manual user addition flow down to 3 fields, one confirmation step, and instant feedback. No jargon. No room for error. Just get it done and get back to the person standing in front of you.
I designed for the hardest user first
I made the front desk staff member my north star. My thinking was — if someone with zero technical background can add a user quickly and without confusion, then everyone else will be fine. So I stripped the manual user addition flow down to 3 fields, one confirmation step, and instant feedback. No jargon. No room for error. Just get it done and get back to the person standing in front of you.
Summary first, details on demand
One pattern runs through the entire dashboard — show the summary, let people go deeper only when they need to. The Dashboard Home gives you the full picture at a glance: active users across all hubs, system status, authentication rate. Everything else is one click away. Nothing is buried, but nothing is in your face either.
Summary first, details on demand
One pattern runs through the entire dashboard — show the summary, let people go deeper only when they need to. The Dashboard Home gives you the full picture at a glance: active users across all hubs, system status, authentication rate. Everything else is one click away. Nothing is buried, but nothing is in your face either.
Each user lands in their own world
I didn't want to build one navigation and then hide things based on role. I designed each user's entry point intentionally — so when the IT admin logs in, they see what they need. When the front desk staff logs in, they see something completely different. Nobody has to scroll past tools that aren't for them.
Each user lands in their own world
I didn't want to build one navigation and then hide things based on role. I designed each user's entry point intentionally — so when the IT admin logs in, they see what they need. When the front desk staff logs in, they see something completely different. Nobody has to scroll past tools that aren't for them.
The Sign in / Sign up screen
The Sign in / Sign up screen
What Shipped
What Shipped
After 4 weeks, I handed off a complete dashboard UI, Dashboard Home with live metrics across all hubs, Hub management, WiFi User management with manual add and force disconnect, Authentication logs with filtering and CSV export, and a System Events feed for troubleshooting. Everything was in Figma, fully componentised, and documented for the dev team.
After 4 weeks, I handed off a complete dashboard UI, Dashboard Home with live metrics across all hubs, Hub management, WiFi User management with manual add and force disconnect, Authentication logs with filtering and CSV export, and a System Events feed for troubleshooting. Everything was in Figma, fully componentised, and documented for the dev team.
The result
The result
The core flows went from PRD to dev-ready in 4 weeks with no revision rounds. The client onboarded smoothly. Staff across multiple hubs are now using a product that gives them visibility and control over something they were previously managing completely blind.
The core flows went from PRD to dev-ready in 4 weeks with no revision rounds. The client onboarded smoothly. Staff across multiple hubs are now using a product that gives them visibility and control over something they were previously managing completely blind.
What I Learned
What I Learned
The biggest design decision I made on this project wasn't a visual one. It was deciding what each type of user should never have to see. When you're designing for three completely different people in one product, restraint is the skill. It's easy to show everything. It's hard to figure out what to take away — and then actually take it away.
The biggest design decision I made on this project wasn't a visual one. It was deciding what each type of user should never have to see. When you're designing for three completely different people in one product, restraint is the skill. It's easy to show everything. It's hard to figure out what to take away — and then actually take it away.