When I joined Tag People as UX Strategist, the team had a strong foundation: a fully functional internal HRMS tool, heroically built by a lead developer who single handedly crafted the back end, front end, and initial UX.
It worked! But to achieve its vision of becoming a leading local HRMS for SMEs, the platform needed a clear product strategy and user-centred design.
My role was to define that path forward and build the strategic foundation to transition from a solid internal tool to a product ready for its pilot.
This case study focuses on product strategy and process design. Specific product details are protected.
The Core Challenges
The path to market-ready was intercepted by three core challenges:
A Complex Foundation: The platform was powerful but built around technical logic, not user needs. I anticipated this would be a major adoption barrier for a market product.
A Tight Timeline: We had five months to prepare for the pilot. The existing, complex scope made this impossible, forcing a fundamental strategic choice.
A Missing Product Narrative: While there was vision, there was no connecting story or system guiding how the product would actually come to life. Deadlines existed but felt disconnected from a coherent plan to build, learn, and launch
These aren't unique problems. They're the kind of challenges that can stall any product. The central question was universal: How do you create a clear path forward when faced with complexity, time pressure, and strategic ambiguity?
Operational Roadmaps & Systems
My first step was to build a master plan, that connected daily work to the final goal. I mapped the invisible structure, by creating a five phase blueprint (Phase 0 to 4) that defined the journey from pre planning to post launch growth. To align with our key milestones, the blueprint was intentionally split into two stages:
Journey to Pilot (Phases 0–2): Focused on laying the groundwork and building a testable product.
Journey to Launch (Phases 3–5): Focused on refining based on real feedback and scaling for the market.
Which featured:
Phase 0: The Foundation - Groundwork for subsequent phases
Phase 1: Product Development - Developing and testing MVP solution
Phase 2: Pilot - Testing HRMS in a real environment
Phase 3: Review & Refine - Product updates based on feedback, product feature backlog
Phase 4: Launch - Release to the market
Phase 5: Grow & Scale - Expanding the product
The most important was Phase 0. Rather than it being a sequential step, it served as a ongoing system- the baseline of a market ready product launch. Its components ensured we were building on solid ground for example:
Defined goals, KPIs and deliverables for subsequent phases
Why it mattered: This kept leadership's expectations and the team's effort cohesive, ending work in silos and ensuring everyone moved in the same direction
Designed team structure and customer feedback loops, we would be dependent on in later phases.
Why it mattered: The project was extra work on top of the team's core duties. If we had waited until the pilot to figure out support or documentation, we would have drowned. Phase 0 built the structure to scale efficiently.
Planning for branding, marketing and pricing from the very start
Why it mattered: Knowing we'd need product demos and training during the pilot meant we had to create materials and FAQs in advance. Phase 0 forced us to ask "Who owns this?" long before it became an emergency.
The team now had a singular path toward launch. The roadmap did more than track deadlines; it exposed critical dependencies, prevented scope creep, and enabled alignment at every stage.
The core lesson is this: Strategy is an operating system you build, not a document you write. Skipping foundational work creates preventable roadblocks. Being proactive instead of reactive doesn’t mean problems won't find you - it means your team is equipped with the clarity to navigate them calmly. Turning a chaotic project into and executable plan.
Designing the User Experience
With a strategy in place, the focus shifted from planning to development.
The challenge was to translate the complex, technically-driven platform into a simple, user centred product, while designing the operational systems that would allow it to learn and improve after launch.
Given our 5 month timeline, a full feature rebuild was not feasible, or - might I say - completely necessary. Our target users, SMEs HR teams, were largely transitioning from spreadsheets or manual methods. Their core need wasn’t a feature-rich suite, but a simple, reliable system that made their jobs easier. The goal became to identify and deliver immediate value.
To do this, the work unfolded on two parallel tracks: designing the product experience for today, and designing the ecosystem for continuous learning.
1. Simplifying the Core Experience
As a designer, I could see the power within the existing HRMS. But that power was buried beneath unintuitive flows, a steep learning curve for time‑pressed HR teams. For adoption to succeed, the platform needed to feel intuitive, not overwhelming. Making it easy to adopt became the critical point of the entire product effort.
Defining the True MVP: Through stakeholder workshops and user stories, I identified the core modules that would deliver the most impact as their first HR tool: Dashboard, Employee, Leave, Performance & Query Management, and Admin Configuration. Everything else was intentionally deferred.
Prioritised Onboarding Flow: I recognised that the first five minutes of using a product are critical for long‑term adoption. Even though pilot users would receive training, I designed for the end user who wouldn’t; it had to be intuitive from first principles. The platform was essentially unusable without first entering company and employee data, so the onboarding flow turned this setup from a barrier into a guided tutorial. By walking users through entering their first employee, I taught them how to use the system while helping them complete their most important task. This immediate progress transformed setup into motivation- proving value from the very first interaction.
Designing a Two-Sided Ecosystem: The product wasn't one tool, but two interconnected systems: the HRMS for administrators and the Employee Self-Service (ESS) portal. I mapped parallel, simplified journeys for both sides to ensure they felt like parts of one coherent experience. This meant ensuring every employee action in the ESS had a clear corresponding notification or task in the HRMS, and every admin update was reflected back to employees. For example, when an employee submits a leave request, it instantly appears as a pending task for the HR admin to review. By designing these mirrored interactions from the start, the entire ecosystem felt transparent and unified, not like two separate tools sharing a login.
Wireframes to Make Vision Tangible: Without a brand UI, the platform lived only in code, invisible to stakeholders and leaving the front‑end designer waiting. This created pressure and left the team in the dark. I stepped in with detailed wireframes for every core flow, making the product’s structure and functionality clear long before any code was written. These visuals gave everyone (developers, designers, and stakeholders), a concrete reference to align on. Most importantly, it gave the front‑end designer a clear starting point to work from, removing blockers and accelerating the design‑to‑development handoff.
The result was a simpler, clearer product and a team aligned around a shared vision.
Planning for Feedback, Support & Scale
Knowing the pilot’s feedback was crucial in deciding the final product (and how we moved forward) I had to be strategic about what we collected and what we did with it. The pilot wasn’t just about testing the HRMS and ESS; it was also a test of the team’s own capacity to run it.
Without a clear process, I anticipated overwhelm and confusion. To ensure pilot readiness I planned for:
Live Support & Triage
A dedicated customer service role and a simple tracking system so users would get answers quickly while developers could stay focused on building.
Why it mattered: This would prevent team overwhelm and establish clear role accountability from the beginning.
Impact Research Framework:
A system designed to capture where the product’s real value lived within SMEs, revealing how it actually fit into daily workflows, and to surface authentic stories of time saved and efficiency gained.
Why it mattered: To validate product positioning
Team Response Metrics:
KPIs for response time and resolution rates, to create a baseline for support capacity.
Why it mattered: This made support predictable, so we could scale the team as we scaled the product.
This system was about ensuring the team could work and grow alongside the product.
Before transitioning off the project, I handed over the complete strategy to the product owner and the customer team, equipping them with a clear roadmap, defined feedback systems, and role clarity for scaling.
The immediate outcome wasn’t a launched product, but a transformed approach:
Feedback from the team was that I “brought order to their process” and “changed the way they approach development”, addressing things they hadn’t even considered before.
Though external priorities paused development, the work left behind ensures that when the project resumes, they won’t be starting from scratch. They have a coherent product vision, structured systems for learning, and a team prepared to execute with clarity.
Stepping into the product strategy role was a daunting but invaluable experience. It reinforced that a successful launch depends as much on team clarity and operational design as it does on the product itself.
This project highlighted how critical it is to define roles, set clear expectations, and build systems that allow a team to learn and scale together. Even though development was paused, the work established a reusable framework, proving that strong foundations enable momentum, even amid uncertainty.
© UX Asha 2025