< back to portfolio

<aside> 💡

Executive Summary

• Context: Individual Development Plans (IDPs) tend to be written once and forgotten. They stay disconnected from daily work, and managers have little visibility or influence after approval.
• Approach: I designed the end-to-end IDP module for employees, leaders and HR, focused on making the plan a living conversation instead of a form. AI was part of my workflow at every stage: Whisper for transcribing stakeholder sessions, and Claude Code for synthesizing business rules, mapping edge cases, writing specs and building interactive prototypes.
• Role: Product Designer & Product Owner (Hybrid — AI-Augmented Product Lead).
• Core Impact: A complete, validated module, from flows and states to user stories with acceptance criteria and a working prototype, with critical edge cases resolved before development. Currently, this feature is in beta. </aside>

1. The Problem & My Role

Most IDPs fail quietly. Employees fill them in at the start of a cycle, leaders approve them, and nobody looks again until the next review. The challenge was to keep the plan alive: easy to update, visible to the leader, and connected to real actions.

In a hybrid role, I owned both sides of the work. As Product Designer, I mapped the journeys of three roles (employee, leader, HR), defined states and interactions, and prototyped them in code to validate behavior. As Product Owner, I turned requirements into user stories with acceptance criteria, framed technical spikes, and prepared the handoff to engineering.

First dashboard wireframe

Final dashboard prototype

2. How I Worked: AI as a Multiplier

I used AI to speed up the parts of product work that usually slow everything down, while keeping the judgment calls with me.

• From conversations to rules. I transcribed stakeholder sessions with Whisper and used Claude Code to turn them into numbered requirements and business rules. I reviewed every synthesis before it went into the discovery document.
• From rules to edge cases. For each requirement, I worked with Claude Code to ask “what breaks this?” and turned the answers into technical spikes, each with a question, a hypothesis, a definition of done and the risk of ignoring it.
• From specs to behavior. I built an interactive prototype in React with Claude Code, not as production code but as a behavioral reference. Developers could click through states, empty screens and error cases instead of guessing from static mockups.

3. Key Design Decisions

Leaders suggest, employees decide. I wanted leaders to support development without taking ownership of the plan away from the employee. So leaders don’t add actions directly. They send suggestions, which arrive as Pending and which the employee can accept or ignore. The trade-off is one extra step for the leader, but the plan stays the employee’s, and that’s what keeps them engaged with it.

Copilot's IDP state machine

AI that never blocks the flow. The leader’s Copilot generates action suggestions through a real AI call, so I designed for failure as carefully as for success. If the call times out or errors, the Copilot falls back to a set of generic suggestions. If the organization runs out of AI quota, the buttons are disabled with a clear message telling the user who to talk to. And “Check deadlines” is a plain calculation, so it never spends quota. Each suggestion is tagged Copilot, so the employee always knows where it came from.

Clear, visible states. IDPs and their actions move through explicit states (Not Started, In Progress, On Hold, Completed) with notifications at each transition, so both employee and leader always know where the plan stands.

IDP state machine

4. Catching Edge Cases Before the Sprint