Building a Monthly AI-Assisted Prototyping Workflow
Together with product and engineering partners, we established a monthly PS App rhythm for aligning on features, prototyping with AI coding tools, reviewing MVP readiness, and learning from opt-in beta feedback. The repeatable process gave the team a practical way to release smaller experiments and build on what we learned.
Sony Interactive Entertainment / PlayStation
UX Manager; cadence and cross-functional coordination
Designers, an engineer, and a product manager
PS App on iOS and Android
Codex and Claude Code for design prototypes; React and React Native in the engineering workflow
Using the mobile release rhythm to learn
The PS App released monthly, while console work followed longer cycles. Mobile therefore offered a different opportunity to explore ideas with players and use what we learned in subsequent decisions.
The challenge was to connect that opportunity to the way the team worked. Design exploration, engineering development, and player feedback needed to fit into the same rhythm. A prototype could help the team examine an interaction, but it only became part of a useful learning process when there was a shared decision about readiness and a way to review the response.
I set the cadence with my engineering and product partners. The designers developed prototypes and the engineer worked on the build. My role was to organize the relationship between those activities and the points where we needed to make decisions together.
Starting with planning and alignment
The cycle began with about a week of planning and alignment. This gave the group time to establish what it was taking forward before moving into prototyping and development.
Putting alignment inside the cycle mattered because a monthly release did not leave room for every question to remain open indefinitely. The team needed a shared understanding of the work before assessing whether the resulting experience was sufficient for an initial release.
The cadence also established an expectation that reviewing the response was part of the work. The cycle did not end when an idea became a prototype or when engineering finished a build. It included time after rollout to look at the impact and feedback.
Prototyping alongside engineering
Designers used AI coding tools, including Codex and Claude Code, to prototype while engineering built in React and React Native. This allowed design exploration and engineering work to proceed in parallel within the monthly cycle.
The value of the prototype was the experience the team could examine. Instead of relying entirely on static files to communicate an interaction, designers could explore it in code and bring that work into the discussion with product and engineering.
The designers’ contribution remained design-led: expressing an experience, evaluating it, and developing the direction with engineering partners. Engineering retained responsibility for its implementation. AI supported prototype creation within that process; it was not a new AI feature offered to players. My contribution was to support the collaboration and make it part of a consistent workflow.
Reviewing readiness as a shared decision
Before rollout, design and engineering jointly checked whether the experience met the bar for a minimum viable product. The review connected the prototype to the intended initial experience and the build moving toward release.
This was an important point of coordination. A prototype alone did not establish readiness, and the fact that a feature could be built did not settle its UX. The group needed to examine the experience together before taking it to players.
The cycle reached rollout after about three weeks, followed by roughly a week to review impact. Those timings describe the working rhythm we established. They are not a measured reduction from a previous cycle or a guarantee that every feature required the same amount of effort.
Bringing player feedback into the cycle
Players could opt into small beta releases in the mobile app and share feedback. This gave the team a way to examine an experience beyond internal design and engineering reviews.
The structure connected that feedback to a recurring review period. We had a defined opportunity to look at the response before planning the next cycle, rather than treating feedback collection as separate from delivery.
The work established a repeatable monthly pattern: planning, parallel prototyping and development, a shared readiness check, rollout, and review. I do not attribute an engagement lift, a reduction in development time, or less rework to the workflow; measured results from the cycles were still pending at the end of my involvement.
My contribution was to make AI-assisted prototyping part of a coordinated product workflow, with engineering participation and a route to player feedback. The tools supported the work, while the cadence gave the team a consistent way to use them.