Skip to content
Milijana Smiljanic

Micetro Redesign

Instead of pushing users off the Micetro console, we borrowed its superpowers. This study distilled what keeps admins loyal and mapped it directly to Micetro Web, so adoption is earned, not enforced.

Problem Statement

As Micetro shifted from its Windows console to the new web app, customers found the console faster and more efficient, while the web UI felt limited. What wasn’t clear was how critical these gaps were or their impact on adoption.

Opportunity

This was a chance to learn what customers valued in the console, where the web app fell short, and what changes were needed to drive adoption — uncovering not just usability issues, but potential business risks.

My Role

I led the research end-to-end. I synthesized insights into clear recommendations, and uncovered a deeper risk that led me to create a dedicated case study showing why console parity was essential.

Team structure

  • Lead UX Research
  • UX Designer
  • Product Manager
  • Engineering Manager

Approach & Process

Steps 1 & 2. Discovery, Alignment & Research Plan

At the start, PMs knew there was “resistance” to the web UI, but lacked clarity on which gaps truly mattered and which were minor.

Together, we set three main guiding research questions:

  1. Which console features must carry forward to the web app?
  2. Where are the biggest adoption blockers in the current web UI?
  3. What improvements would make the web app a viable standalone platform?

To answer, I introduced a structured research plan, combining surveys (for breadth) with interviews (for depth) and a CSM validation workshop.

Step 3. Conducting Research & Methodology

Survey

I started with a survey to capture broad sentiment. The goal was to quickly filter between console-preferred and web-preferred users, and then dig deeper into why they preferred one over the other. This gave me a baseline view of adoption blockers and let me see patterns across different accounts before committing to deeper interviews.

User Interviews

I followed with in-depth interviews with users who are preferring console over web UI, to understand context behind survey responses. These were enterprise customers (eBay, SSAB, USDA Wisconsin Gov, Microsoft), each managing complex production environments. I chose interviews because console vs. web workflows are nuanced, and I needed rich, qualitative insights to uncover why operators were resisting the web app and what workflows they considered “non-negotiable.”

“The console just feels more stable. The web UI makes me nervous in production.”

Step 4. Analyzing & Synthesizing

I consolidated findings into adoption blockers and prioritized them by severity, where I placed blockers on a grid Impact vs. Frequency:

Severity: Critical

  • Console-only tasks: Unlocking DNS lists, DHCP scope management, AD permissions.
  • Offline support missing: Critical for secure or air-gapped production environments.

Severity: High

  • No multitasking: Lack of tabs or split views slowed operators.
  • Missing visual cues: Without color-coded indicators, troubleshooting took longer.
  • Weak search & bulk updates: Competitors like Infoblox already offered this.

Severity: Medium

  • Logging gaps: Web UI lacked detailed, real-time logs.

Each was reframed into a design opportunity, e.g.: “How might we give operators instant health feedback without clicks?”

NordicSteel Case Study (Name Changed for Confidentiality)

During research, I discovered that NordicSteel, a major enterprise customer, had flagged their account as high risk. Their teams depended on console-only workflows like DHCP scope management, DNS list unlocks, and color-coded status indicators. The new web app lacked these features, making it slower and less reliable for production use.

“If you shut down the console, we can’t operate.”

This was a turning point: what started as a usability evaluation became a strategic retention issue. To make the risk clear, I created a dedicated case study showing why console parity was critical for adoption and renewal.

✨ Impact of the product is that leadership delayed console deprecation and prioritized parity features (tabs, visual cues, search, bulk updates) on the roadmap to protect retention.

Step 5. Reporting & Knowledge Sharing

I delivered two key outputs:

  1. Micetro Redesign Report → Synthesized survey + interviews into critical gaps and recommendations.
  2. NordicSteel Case Study → A focused narrative for stakeholders, showing why console parity was essential for retention.

I also hosted readouts with PMs, ENG M, and designers. This ensured insights weren’t static but became part of ongoing strategy conversations.

Outcomes & Shipped Changes

Research led to concrete roadmap shifts:

  • Parity features prioritized: Global search, logging, scope management, AD permissions, scheduled scripts.
  • Visual clarity: Color-coded console-style indicators restored.
  • Retention strategy: Console deprecation postponed until parity gaps were closed.

Reflection

This project proved that research isn’t just about improving usability, it can uncover hidden business risks.

  • I discovered a high-risk account (NordicSteel) and turned their story into a case study for leadership.
  • Ensured console parity became a non-negotiable priority before web adoption.

Result was that leadership shifted strategy: the web platform will only replace the console once it reaches parity, protecting adoption, renewals, and long-term trust.

Beyond Micetro

This research wasn’t just about improving the web app. It was later used as a guide for the design and strategy of BlueCat’s new DDI product, ensuring that lessons learned from console vs. web gaps directly shaped the foundation of future development.