Before I hand over a UI ticket

Over time, I have settled into a simple quality loop before I push code and hand a ticket over: understand the ticket first, use Figma MCP to check the intended UI, use Playwright for repeatable checks, then do a final manual pass. None of these steps is enough on its own. Together, they help me spend less time repeating the same checks and more time on the parts that need judgement.

Start with the ticket, then the intended UI

Before implementation, I start with the ticket itself. What is in scope, what is the user or business goal, and what should be true when the work is complete? If there is a wireframe, it helps me understand the flow and the early intent behind the screen. It is also a good moment to notice what has not been decided yet.

The Figma MCP server then helps me look beyond a screenshot. I can check the frame, the component being used, its states, the spacing and type around it, and how the layout is expected to change across screens.

That is especially useful when two design systems live in the same project. A familiar button or input may look close enough at first glance, yet belong to a different system with different tokens or behaviour. Taking a moment to check the source helps me avoid carrying that mismatch into the code.

Figma MCP does not replace a conversation with the designer. If the purpose of a state or interaction is unclear, asking is still usually the fastest way to understand it. The tool simply gives that conversation a more concrete starting point.

Let Playwright cover the repeatable checks

Once the UI is implemented, Playwright helps protect the behaviour that should keep working. It is useful for the main user flow, as well as loading, empty, error, or permission states when those are part of the ticket.

test("shows the empty state when there are no items", async ({ page }) => {
  await page.route("**/api/items*", (route) => route.fulfill({ json: [] }));
  await page.goto("/items");
  await expect(page.getByText("No items yet")).toBeVisible();
});

I do not expect a test suite to describe the whole experience. It is better at checking what a browser can repeat reliably: an action opens the right screen, a form submits, a state appears, or a regression stays fixed. That makes it easier to change a UI with a little more confidence, especially when another part of the product depends on the same component.

Keep a manual pass at the end

Before I push code and hand a ticket over, I still open the product and test it by hand. This is the last step in the loop, not a fallback for missing automation.

I look at the screen as a user might:

• Is the hierarchy clear?
• Does the interaction feel natural?
• Does real content change the layout?
• Does the UI still match the intended design?

I also check smaller screens and the less obvious states that are difficult to capture fully in a test.

This is often where small issues appear. A button may be technically correct but sit too close to another action. A loading state may work but feel abrupt. A screen may be using the wrong design-system component. These are usually small adjustments, but catching them before handover keeps the ticket from passing that work on to someone else.

Make quality a shared habit

This workflow is still evolving, but it has helped me keep the steps visible: understand the intent, protect the repeatable behaviour, then review the built result with fresh eyes.

On a project with UI work spread across several frontend repositories and more than one design system, that habit matters more than a perfect checklist. Figma MCP, Playwright, and manual testing each cover a different part of the work. Used together, they make it a little easier to hand over a ticket with care.