One of the biggest challenges I wanted to address was getting designers to the current product before they started changing it.
Finding a Figma file did not guarantee that it matched what was live. Even with the right screen, I still needed to understand the working components and their behaviour.
I built a tool that pulls from the product and component library repositories, so the starting point comes from the implementation. I wrote reusable AI instructions, called skills, to guide the steps.
Start with the shell
I chose to import the product shell, the surrounding layout and navigation, first to keep the setup smaller. Pulling in every application page would add work before the designer had chosen what to change.
When a page has not been imported, the tool shows a prompt the designer can copy to bring it in.
That gives them the surrounding product structure and a way to load the page they need.
Make the steps repeatable
I wanted other designers to use the process without depending on one long prompt or my own knowledge of the setup. I gave each skill a specific job, such as importing a page or explaining what the prototype uses.
I put the requirement and component check before the build. I need to know what the designer wants to change and what the library already supports.
I also use a handover skill to explain what the prototype uses, so the proposal includes more than the visible result.
I judge each skill by an output I can inspect. For an import, that is the working page. For a handover, it is the explanation of the components and behaviour being used.
I still review whether the result fits the requirement and what needs a decision. The instructions carry the repeated steps, while the designer reviews the experience.
I aim to keep the prototype close to the product without treating it as production-ready code. Engineering still needs to review the implementation.
The designer can then explore the change using the existing page and shared components as the starting point.