For 7+ years, I've been part of the entire process β planning Produtct, working with engineering, design, and operations, and taking features from a rough idea all the way to launch. I know how software gets built, where things go wrong, and why users get stuck.
I've worked across hardware, software, and B2B SaaS β from Wi-Fi routers and mobile apps to complex admin platforms. And because I started in UI/UX, I don't just know what a product does β I know how people actually use it, where they struggle, and how to fix it.
My approach to product work is iterative, honest, and structure-loving.
βοΈ Email: chiangyichieh@gmail.com
It's a platform monitor data center clusters. Over the years, the platform was expanded without a clear structure. Features were added one after another, which led to confusing user flows and inconsistent visuals across modules. This made it harder for new users to understand the system, and also slowed down internal collaboration.
I joined the team as both a designer and interim Product Manager to define a coherent experience and resolve gaps in developer collaboration.
My role involved translating ambiguous requirements into scoped wireframes, design UI layout, driving cross-functional alignment, and codifying interaction logic into a reusable system across modules.
This project focused on redesigning an platform used by our support team to monitor data center clusters and troubleshoot system issues. Over time, as more third-party services were added, the platform started to feel messy. Also, the inefficiencies in daily workflows like check status or identify errors need refinement.
The project has these primary goals:
While not a commercial product, internal adoption and productivity were the key success markers.
Our primary users were support engineers and platform ops teams responsible for managing hundreds of active clusters. They needed fast, reliable visibility into system logs, health checks, and configuration states to triage incidents and minimize downtime.
| Work stream | My Actions | Direct Impact |
|---|---|---|
| Project framing οΌProposed Solution | - Defined project goals based on stakeholder inputs and product gaps. - Designed modular solutions (Modules see below) | Created a structured and scalable solution focused on user and business value. |
| Design-spec clarity | β’ Created mockups and UI-logic breakdowns in Figma. | Developers had clear references and could start immediately; Reduced follow-up questions and rework. |
| Team collaboration | β’ Produced end-to-end scenarios and UI copy for engineers. | Reduced ambiguity across designβdev handoff and improved implementation speed. |
| DevβQA schedule realignment | Detected a two-week development slip; rapidly re-sequenced engineering and QA tasks, locking critical paths. | Recovered a 2-week delay and still met the planned release date. |
| Issue-board visualization | Reworked the GitHub Project boardβadded explicit status columns and auto-labels so QA could pull tickets directly. | QA tracked progress without extra sync meetings. |
| Next-milestone prep | During the QA window, groomed the Milestone 2 backlog and pre-split tickets with dependencies noted. | Helped the team distinguish priorities for upcoming work. |
This initiative aimed to transform the platform into a branded and user-friendly product.
| Goals | MVP prioritized |
|---|---|
| Unified brand identity | - Create new UI library, storybook for reuse - Masking other open-source projects fragments - Restructuring dashboard layout for visibility and clarity |
| Improved usability | β’ Improve Troubleshooting flow (file upload/download) β’ Redesign Health check display dashboard and logic β’ Advancing Notification flexibility β’ Check detailed node status |
| New features | β’ Tunings modules β’ License management |
Modules
π₯ Youtube demo (27 min) in Mandarin
I presented our latest product updates, including a comparison of new vs. legacy features. (Note: the feature order differs from the list below.)
The platform originally linked several third-party tools on sidebar, each with its own styling and logic. This created a fragmented user experience that felt more like a collection of disconnected tools than a cohesive product.
I replaced iframe-based views with unified layoutsβstandardizing headers, sidebars, and page structure to reduce fragmentation and context switching. I also partnered with the designer to rebuild our UI library from scratch, documented in Storybook for consistent reuse. I also replaced iframe-based views with unified layoutsβstandardizing headers, sidebars, and page structure to reduce fragmentation and context switching.
The redesigned UI delivered a cohesive, branded interface that felt internally owned. It established a structured design foundation for future modules and enabled teams to build with greater consistency.
Information was spread across tabs with no visual hierarchy, making it hard for users to find critical data.
I conducted UI audits and mapped user flows to identify overlapping data and redundancies. I then proposed hi-fi mockups to initiate discussion and move the team from vague ideas to tangible feedback.
We implemented a new dashboard with collapsible sections and clear visual prioritization.
Users could only download logs one at a time, and inconsistent file names complicated support and escalation.
I collaborated with ops engineers to analyze usage patterns and pinpoint common naming issues.
We added batch download support.
The original health check interface displayed real time status but not stored history, leading to delays in identifying system issues.
I created health status and it history bar to monitor the logs
More detailed and history status could trace back.
Tuning configurations were CLI-only, inaccessible to non-technical teams..
This UI module reduced reliance on CLI and empowered support teams to make adjustments independently.
This UI module reduced reliance on CLI and empowered support teams to make adjustments independently.
| Stage | Timeframe | Feature / Deliverable | Rationale | Success Metric |
|---|---|---|---|---|
| Now | Public release by end of May | Platform Rebrand (brand & UI unification) | Cohesive brand experience required before going public | β₯ 80% of interviewed partner teams report that the new modules improved visibility. |
| Existing-feature improvementsβ Support file batch actionβ‘ Health status & history viewβ’ Event-ID dashboard | Addresses current pain points and boosts efficiency | Reduce operation time at least 20%(TBD) | ||
| Tunings module (new feature) | Satisfies power-user tuning needs | -Reduce tuning editing time 10% -Adoption Rate to 50% (TBD) | ||
| Notifications β Triggers Phase 1 β user-configurable notification methods | Increases alert flexibility | Reduce emergency fixing time at least 20%(TBD) | ||
| Next | 0β3 months after release | Notifications β Triggers Phase 2 β personalized conditions & automated responses | Moves from reactive alerts to proactive automation | -Adoption Rate to 50% (TBD) |
| Integrations β user-addable third-party services | High-demand request; scheduled after Rebrand stabilizes | -Adoption Rate to 50% (TBD) | ||
| Later | 3β6 months after release | Node Advanced Controls β deeper hardware-level operations | Requires backend refactor & new permission model; follows Integrations | -Adoption Rate to 50% (TBD) |
π All content has been anonymized. It's an open source project.
This spreadsheet documents the planning process for a product rebuild initiative.
It covers:
This document provides module-level UI copy text and annotation such as:
The document was written to assist engineering and QA during implementation.
This project deepened my role β from a designer primarily executing tasks, to someone who actively scopes work, makes decisions, and delegates responsibilities.
Instead of waiting for clarity, I started shaping it together with the team β asking questions, identifying gaps, and helping turn vague goals into concrete tasks. Aligning with engineers, understanding each person's workload, and breaking down unclear requirements into structured, testable tasks.
When working with unclear requirements, I've found that putting forward a proposal β rather than waiting for clarity β helps the team move forward faster. In this project, I initiated product discussions by presenting hi-fi wireframes based on my own interpretation of needs, using them as starting points to frame decisions.
This approach speeded up our conversations. Instead of debating abstract possibilities, we could evaluate actual workflows, uncover missing logic, and focus on what needed to change. Even when a proposal wasn't feasible, it anchored the discussion and reduced time spent circling around the same questions.
By breaking down features visually and resolving one topic at a time, we created shared understanding more efficiently. Before this, we often spent hours debating small assumptions; now, by breaking down features one by one through visuals and structured sessions, we were able to reach consensus more efficiently β and turn uncertainty into actionable steps.
I also started taking more responsibility for how work moved through the team. I helped coordinate QA schedules, triaged issues, and kept our GitHub board organized so that QA could track progress directly β even though we didn't have an SOP for that, and it was my first time using GitHub for issue management.
These were small things β updating statuses, checking who's blocked, labeling tickets β but they made a noticeable difference. We spent less time syncing. I began to see that a good implementation isn't just about product decisions β it's also built through everyday maintenance.