I’ve consistently bridged the gap between design, development, and product management to streamline workflows and clarify expectations. On this page, you’ll see examples of how I improved efficiency by introducing scalable documentation practices, untangling fragmented backlogs, and running retrospectives that drove meaningful iteration. These efforts helped multiple teams stay aligned, deliver faster, and reduce ambiguity.
Clear, consistent requirements documentation is essential for implementing designs with the intended visuals and interactions. As our Product team grew, we faced challenges: each PM used a different story format; engineers reported missing use cases; some didn’t realize there was an Adobe XD file to reference; others found the requirements buried in dense paragraphs or split between design stories and engineering tickets.
In collaboration with other team leads, I refined our documentation for greater clarity and consistency. Over time, we established a standard format, shown in the sample story below.
Tip: Click screenshots to enlarge. For best results, download the full image, as it’s large and may not preview well in the browser.
To avoid confusion from stories arriving without background, always include context: what pain points this feature addresses, what the goal is, and any relevant background. Optionally, include a story-style statement such as:
As a [persona], I want [feature], so that [goal]
Given [conditions], when [trigger], then [outcome]
A high-level user flow helps PMs, designers, and QA testers understand how users move through the feature. Outline each major step or screen interaction.
Include only the prerequisites needed for your audience—skip obvious steps, but ensure someone could reasonably follow along from the starting point you're describing.
For each screen, describe the expected UI and behaviors. If your feature involves different user types (e.g., Buyer, Seller, Admin), be clear about which persona is performing each action.
Many B2B features vary based on certain dimensions. Make it clear which apply:
Is this for free or premium subscribers?
Which roles can access it—admins, power users, auditors?
If there are internal-only features or feature flags, who sees what?
Clarifying these ensures features don’t appear for unintended users.
Even if dependencies are linked in Jira or your ticketing system, briefly note key ones in writing. This section serves as a reminder to discuss timing and relationships between tickets during review—even if you don’t revisit it later.
This is the core of the requirements. Break it down in a way that matches the UI—commonly by page, then by section. If the UI changes by user role or state, describe each version.
Link to the Figma or prototype’s table of contents at the top of this section for easy reference.
Even if you’ve included a prototype link, also embed screenshots and write out key details—this avoids confusion from flipping between tools.
In the written portion, describe (a) content, (b) styling, and (c) behavior, adjusting the level of detail as necessary.
If you’re using established components, skip basic specs like padding or colors. But if modifying something, document the changes clearly—even duplicating styling from Figma when necessary depending on your layer structure and the engineer you're working with.
Use bold text to flag what’s new vs. updated.
Use an ℹ️ icon before background info to help engineers and testers skip non-essential details while preserving context for PMs and designers.
One of our major projects in 2023 faced significant challenges—loose requirements, unclear priorities, and frequent PM turnover. The project’s epics reflected this turbulence, and after release, related bugs and follow-up stories were scattered across multiple projects and epics.
As the only consistent Product team member (designer, PM, engineer, or tester) involved throughout the project, I took the lead in cleaning up the backlog. I used four different queries to locate all related tickets and consolidated them into a single list. This helped the incoming product manager define and prioritize future releases with greater clarity.
Retrospectives were a semi-regular Agile ceremony at Inxeption, typically led by Project Management. I introduced the format we used for several years, outlined in the first yellow sticky note below. While design didn't usually run these sessions, I was trusted to step in when needed due to my seniority and cross-functional experience.
For this retrospective, I facilitated the session by summarizing release accomplishments as a reference (yellow), reading each card for clarity, keeping time, and guiding the discussion on top-voted topics to define future goals (blue). This example highlights my commitment to continuous improvement and my ability to engage across the entire Product organization.