What does the app actually do?
It lets you manage your home Wi-Fi, set up your router, check who's connected, pause internet access, troubleshoot your connection, set up guest networks, and a growing list of features we were actively developing.
A highly complex and technical app.
So it was a very complex product to work on?
Yes... the app runs across multiple markets, with different router models, different legal content, and sometimes completely different flows.
I needed to think about how one design decision would ripple across all of those variations. It required a level of attention to detail that most app projects don't demand.
What was your day to day like?
I worked across the entire product, improving existing flows and taking features through different stages of the design process. I was part of the research process, helping decide what to test and building the prototypes we took into user sessions.
I wrote copy, had hands on the design system, and was very close to the dev team daily. In a product this technical that proximity wasn't optional, it was how the work actually got done. What I remember most are the enormous flow maps and all the decision trees we had to maintain to cover every use case.
What was the hardest part of the work itself?
Making technical things feel human. The product talks to physical devices, routers and extenders, that don't always cooperate.
And some features required explaining concepts most users have never heard of in a way that felt safe and obvious. Getting that balance right between copy and visuals took real effort.
How do you design an app that depends on a physical device behaving reliably?
It's genuinely hard, especially when it comes to testing with real users. You have physical devices like routers and extenders that communicate with the app and vice versa.
There is a lot that could go wrong and I needed to anticipate more use cases than you can imagine and have fallbacks for pretty much everything.
How did you manage all that complexity?
Our workflow was methodic. Figma branches, design system governance, and Transifex for translation strings so we could design in English and trust the platform to distribute the rest.
Every line of text had a string attached that we needed to keep in check. Two refinement sessions per week with developers and product managers kept everyone aligned and were crucial to spot problems early, flag edge cases, and readjust flows before handoff.
Some features involved communicating very technical concepts. How did you handle that?
First you need to understand them yourself, and sometimes that was truly a challenge. Being close to the dev team on a daily basis was crucial for that. And then comes the harder part: taking something complex and making it feel safe and obvious to someone who just wants their Wi-Fi to work.
Concepts like MAC address randomization, for example, require the user to go into their phone settings and turn off a security feature. Explaining what that is and why it's safe to do on a home network in a usable and beautiful way was genuinely hard. You need a very balanced and simple communication between text and visuals and then test with users.
What was it like being part of an in-house product team after years of consultancy?
Different in the best way. The product environment changes how you design. You optimize less for the handoff and more for the product. Everyone is on the same page, working toward the same goals, making informed decisions based on real data.
You grow the product, not just launch it. That felt like my natural environment. A lot of people over the years told me I was built for product.
What did you learn?
Not having direct access to analytics or data scientists made informed decisions harder and sometimes impossible. Being close to engineering is not enough. Designers need to be close to data too. I think this is what’s missing in a lot of teams.
Figma branches work well for complex multi-market products but need tight coordination. We had flows repeated across six different market files that all needed to stay in sync. Merges sometimes went wrong but changing the structure once the system is in place is hard because everything already depends on it. File architecture decisions made early are hard to undo later.
MORE PROJECTS
