starrow
Designed the digital foundation for cross-subsidiary organization management, from organizational structure to usability validation, establishing a scalable framework for collaboration.
Highlight 01
Designing the Architecture for a Cross-Subsidiary Org Chart
Translated complex organizational relationships across multiple subsidiaries and multi-role employees into a clear information architecture and interactive mobile org chart — creating the structural backbone that connects OKRs and collaboration features across the product.
Mapping a Complex Organization
Each subsidiary within the group had its own organizational structure, while day-to-day work still required cross-department collaboration and leadership needed visibility across the broader organization. The org chart therefore wasn’t simply a directory of teams and reporting lines. It served as a structural backbone for the product, connecting OKRs, conversations, and tasks to the organization itself. The complexity increased further because one person could hold multiple roles within the same group — particularly senior leaders, who might have responsibilities across several subsidiaries.
Building the Structure from 0→1
I started by defining the information architecture: mapping the hierarchy from group → company → department, how organizations connect across subsidiaries, and how multiple roles for the same person should be represented. Throughout the process, I worked closely with engineering to validate technical feasibility. The decision was made to use an employee-built organization model rather than automatically importing the structure from an existing system. The intent was for employees to develop a clearer understanding of their own position and relationships within the organization through the process of building and connecting it themselves. This made guidance and usability especially important: users had to build the organizational structure from scratch, so the architecture needed to make that process intuitive as well as structurally sound.
Making the Org Chart Work at Scale
Once the structure was defined, the next challenge was turning a large organizational dataset into an interactive visual org chart that could work efficiently on a mobile app. Loading the entire organization at once would have created significant system performance issues. After aligning with engineering, we adopted a layered loading approach centered on the user’s current organizational role, retrieving only peers and the relevant levels above and below rather than loading the full structure at once. This approach balanced organizational visibility with system performance constraints. We also extended the hierarchy beyond the group’s official org chart to include individual contributors, making the structure more useful for day-to-day cross-department collaboration.
Highlight 02
Leading Usability Testing from Validation to Improvement
Led a usability study with 9 participants, consolidating 48 issues across 7 categories using a User Journey and driving improvements to roughly 60% of them. The findings also became an objective reference for evaluating product quality and informing future development.
Grounding Product Decisions in Evidence
After Phase 1 was completed, the product reached a point where the development team and next steps were being reassessed. I initiated a usability study with two goals: to validate whether the product met the expectations of its core users, and to surface existing product issues through real usage evidence rather than relying solely on internal assumptions. I was responsible for both the planning and execution of the study.
Testing the Core Journey
The study focused on starrow’s core target users — mid- to senior-level managers and secretaries — with 9 participants in total: 7 managers and 2 secretaries. The session was structured into four parts: Registration & free exploration → 5 organizational tasks → 5 OKR tasks → final interview Each task was framed within a realistic scenario, allowing participants to interact with the product in a context closer to how they would actually use it.
Structuring the Findings
I mapped the findings into a User Journey, capturing participant reactions on sticky notes and color-coding them by role. The findings were consolidated into 48 issues across seven categories, covering expectations, comprehension, discoverability, interaction feedback, interface presentation, empty states, and supporting guidance.
From Findings to Improvements
Case 01｜Hard-to-Find Organization Entry Point
Participants found the avatar-based entry point for organization-related features unintuitive, and some could not locate it at all, relying instead on the CTA on the home screen. The organization feature was moved into the Features section of the footer navigation, making it visible when switching tabs. The home CTA was also revised to appear only when users had not yet created an organization, then disappear once one existed, reducing the chance of misleading users. (Improved in v1.0)
Case 02｜Flat List Obscured the Hierarchy
The initial list-based UI did not clearly communicate organizational levels. The team had already raised concerns about the approach, and usability testing confirmed that users were indeed confusing departments with individual employees — some even interpreted the two presentation patterns as system errors. After the development team was reorganized, I revisited the feasibility of a visual approach with engineering. The final solution separated the experience into two views: Department Details for reading information about a single unit, and an Org Chart for understanding the broader hierarchy. (Improved in v1.0)
Case 03｜Unclear Save Behavior in the OKR Flow
Although OKR was not the primary module I owned, I approached the product as a complete experience rather than a set of isolated features. The usability study therefore covered the OKR flow as well as the organizational features I led. During testing, users became uncertain whether their data had been saved when switching tabs while creating an OKR because the system provided no clear feedback. The flow shifted from autosave to a guided Previous / Next step interaction, reducing uncertainty during OKR creation. (Improved in v1.1)
Overall Impact
Of the 48 issues identified, 29 were addressed — roughly 60%. The remaining issues — including lower-priority usability concerns and feature-level opportunities — fed into subsequent iteration planning. I also presented the findings at a department-wide monthly meeting attended by nearly 100 colleagues.
Other Contributions
Tagging Feature
Conceptualized a tagging feature that would help managers quickly understand the overall project landscape and track progress against OKRs. The work reached the concept and wireframe stage before the project was put on hold.
Results
starrow remained pending and did not reach launch, so there were no post-launch quantitative metrics. However, the project produced two meaningful qualitative outcomes:
- Positive Executive Feedback on the Phase Deliverables After the project results were presented to the group CEO, the work received positive feedback on its overall quality, along with a request for the expected restart timeline. starrow was ultimately put on hold due to a strategic shift, rather than concerns about product or design quality.
- Organizational Impact of the Usability Study The study helped introduce a more structured, evidence-based approach to design validation within the team, influencing subsequent design decisions and validation practices.
Retrospective
Thinking in MVPs
The biggest lesson from this project was that the initial scope was too broad and not narrowed down enough toward an MVP. If I were to do it again, I would reduce the scope earlier to the smallest version that could validate the core assumptions — get it running first, then expand from there.
Building an Ownership-Driven Way of Working
The team structure gave each designer ownership of an individual product module — not just the interface, but the full chain from defining the feature itself to structuring the flow, making design decisions, aligning with engineering, and validating the experience through testing. Feature requirements were not simply handed over by PMs. Designers defined them based on product goals and user needs, which trained me to think beyond execution and take responsibility for the product logic behind the experience.