Enabled an engineering team with Agentic Design Ops to ship end-to-end features
Project Summary
I created a design process and agent skills that let our product engineers own small features from problem statement to release. Engineers now ship simple features using design system components, and I sign them off once they're in code. Throughput on some features rose by up to 300%.
Introduction
Ocula provides a platform for large e-commerce customers to perform data enrichment and AEO (Answer Engine Optimisation) and SEO (Search Engine Optimisation) copy generation for their products at scale.
Problem
AI coding agents let our engineers ship code fast, which made product and design decisions the bottleneck.
Inspired by Linear and PostHog, we created a Product Engineer role that owns features end to end. To do that well, engineers needed guidelines, tools and support.
Goals
- Help the wider team understand why the product design process matters.
- Give engineers tools to deliver small features without learning product design in depth.
- Identify skills agents could use to support the process.
- Build front-end infrastructure that helps engineers create usable UI.
Challenges
-
Mixed experience
Experience ranged from engineers with some front-end work to career backend engineers.
-
A busy team
The team was already busy, and training and onboarding took time.
-
A new bottleneck
As the only designer, I moved from production bottleneck to review bottleneck, because all UI needed my review before release.
-
New to critique
Engineers weren't used to design critique the way designers are.
The Solution
Mapped the agentic product design process
I mapped the process for three reasons:
- To reflect on my own role. Agents had changed how I work, and I wanted to understand how.
- To teach the team. The map became a reference I could walk engineers through, explaining each step and why it matters. It also gave us a shared basis for questions and discussion.
- To find where skills could help. It showed which skills I already used and where new ones could support the team.
Ran design thinking training
The purpose of each design thinking stage is obvious to designers but not to engineers, so I walked the team through each stage and its methods.
Curated design skills
I had already created some of these skills for my own design work. I created others so engineers could do tasks they would otherwise have had to learn.
I added them to the engineering team's shared skills package, so everyone used the same tools and processes.
| Skill | Description |
|---|---|
| Discover | The agent accesses any platforms and tools that it has access to, such as Teams, Notion, Sharepoint, Slack etc. and pull all the available knowledge that it can find about the problem that needs to be solved. It then analyses the findings into a easily digestable and referenaceable document. |
| Journey mapping | Depending on the stage of the process, this can be used for mapping the AS-IS journeys from the existing codebase, or createing new proposed journey maps based on potential solutions to the problem. For this skill I also updated our journey maps to explicitly call out agent steps in their own swimlane. |
| Inspire | The agent can search for inspiration from existing solutions, and use this to inspire the user to come up with new ideas for potential solutions. |
| Ideate | This is where the agent and user can talk back and forth to come up with various ideas for potential solutions. Once ideas are agreed, the agent can then create a detailed proposal for the solution. |
| Prototype | The agent can create a detailed proposal for the solution, and then create a prototype of the solution using the component library. This can be used to test the solution with the user, and get feedback on the solution. |
| Test plan | The agent suggests testing methods that can be used to validate the solution. It also helps to write testing scripts for usabolity testing. |
Agent-readable component library
I wrote design principles for both engineers and their agents. They live in a Notion doc that the design skills reference.
I built the component library in Storybook. Instead of a standalone design.md file telling agents how to use the components, we put context and usage guidelines directly in each Storybook component.
Outcomes and Impact
- Engineers were able to pick up and deliver small features that covered front-end and back-end code.
- Throughput on some features rose by up to 300%.
- Features were delivered that consistently used components from the component library.
- Features passed usability testing.
Feedback and learnings
Features were built where the happy path was clearly thought out and implemented, but often edge and error cases needed more work.
Features that were ‘solved problems’ could be handled end-to-end. More complex problems that needed more research, exploration and testing needed to be picked up by dedicated designers.
Simple features that fit within current journeys could be added easily. Where new journeys or patterns needed to be created, the solutions started to drift from established patterns.