Summary
I led research to clarify what an AI integration should support beyond read access. Customer workflows helped separate requests for write access into distinct capabilities for the team to consider.
The challenge
The initial integration used the Model Context Protocol (MCP) to let AI tools read existing wireframes. People could use that connection to generate code, specifications, or prototypes in their preferred AI environment. But reading wireframes covered only part of what some product builders wanted to do.
Earlier discovery interviews described work moving between tools: screenshotting outputs, transferring requirements, and rebuilding visual artifacts by hand. Some people wanted AI to create or change wireframes without leaving the environment where they had developed their ideas. The team needed to understand these workflows before deciding what to support next.
My approach
The research examined what people were trying to accomplish across tools and where the integration fell short. Engineering could track tool calls, but could not see users’ AI conversations or the artifacts they generated.
The survey gathered accounts of usage and needs. Interviews explored the why and how: what people were doing across tools, the context they wanted to preserve, and where they became blocked. These early adopters revealed emerging needs; the study did not measure how common those needs were across the wider customer base.
Respondents described generating code, specifications, and user stories. One participant had built an application that passed wireframe content and team coding standards to Azure OpenAI. Another used Claude to generate prompts, then manually pasted them into the product’s built-in AI. Someone else had connected MCP but had not used it because it could not create wireframes.
To assess what the evidence supported, I distinguished working solutions, manual workarounds, and requests for future capabilities. I then separated write access into three needs: creating new wireframes, updating existing ones, and reusing project components. This helped the team consider a smaller initial scope without losing sight of the other workflows.
The research also clarified why a shared wireframing tool still mattered. Participants wanted an editable visual artifact that colleagues could review before implementation. Their AI environment held the context for generating a first pass; the wireframing product offered a place to develop it with others.
Results
The team’s proposal for write capabilities cited my report and mapped its four user scenarios to specific capabilities. It proposed creating new wireframes first, with component reuse and updates as possible later additions. A separate Viewer App proposal also referenced the research.
The team launched MCP write and viewer capabilities in June 2026. July was the first full month after launch.
Research informed the proposals; product and engineering made the investment and implementation decisions. The adoption figures do not isolate research’s contribution or the effect of either capability.