From PRDs to production ready interfaces

When I joined Cipherome in January 2026, the challenge was immediate: deliver both a Design System and product interfaces from week one. The engineering team had already produced extensive Product Requirement Documents (PRDs) specifying interface requirements from a technical perspective. My job was to consume that documentation, understand a domain I had never worked with before — sovereign health data exchange between hospitals, research institutes, universities, and other entities — and translate it into usable interfaces.

Starting January 5th, I began delivering complete flows week by week. Each delivery cycle followed the same rhythm: study the PRDs for a given feature area, design the screens, present for review, iterate based on team discussion, and hand off to engineering. Some flows were significantly harder than others. Contract policy creation and contract definition creation, for example, required weekly discussions about how these concepts interact with each other and how to represent those relationships in the UI. This was one of the most demanding aspects of the work — understanding how a highly specific domain functions when the documentation is dense and the concepts don't map to standard UI patterns.

Maintaining and evolving the Design System

The Design System was one of my first deliverables. I maintained and evolved it throughout the project, ensuring the token pipeline from Figma to production code stayed consistent as screens multiplied. The system was organized into three variable collections: primitives (raw color values, spacing, border radii), semantics (contextual tokens like --primary, --destructive, --muted), and component-level tokens (sidebar colors, chart palettes, input states). Light and dark mode support was built into the token architecture.

Every Figma variable maps directly to a CSS custom property, which maps to a Tailwind utility, which maps to a shadcn/ui component prop. This pipeline meant design token changes could propagate from Figma to code with minimal manual translation — and engineers could build components correctly on the first pass by referencing the token system.

The component library grew to over 30 reusable components: from foundational elements (Button, Input, Select) to complex compositions (sidebar with collapsible navigation, multi-step form wizards, data tables with inline actions, timeline displays, search components, and a theming system with light/dark mode).

Designing for domain complexity

The data connector domain has a vocabulary that doesn't map neatly to standard UI patterns. A "contract negotiation" isn't a shopping cart checkout. A "policy" isn't a settings toggle. Understanding how these pieces interact required ongoing conversations with the team.

Contract Definitions needed a creation flow walking users through selecting assets, choosing policies, and defining terms — designed as a multi-step wizard with progress indication, validation at each step, and review before submission.

Contract Negotiations required a timeline view showing the back-and-forth between provider and consumer connectors. Each state transition (REQUESTED, OFFERED, AGREED, VERIFIED, FINALIZED) has distinct visual treatment so operators can scan status at a glance.

Access Policies balance power with safety. Admins have full CRUD capabilities, but the UI makes destructive actions (revoking access, deleting policies) feel appropriately weighty.

The Federated Catalog works as both a browsing experience and a search tool. Users find specific datasets across connected organizations, filter by metadata, and initiate negotiations directly from search results.

Structured QA that influenced how the team works

The QA process I established became one of the things I'm most proud of in this project. After each engineering delivery, I reviewed every implementation and maintained strict quality control. But what made the difference wasn't just reviewing — it was how the feedback was structured.

Every QA ticket I created followed a consistent format: a title that pinpointed the specific problem, followed by context about where and why it mattered, priority classification from my perspective, acceptance criteria written as actionable solution requests so developers could immediately start working on the fix, and evidence in the form of short video clips and annotated screenshots showing exactly what was wrong. I used AI tooling to help create these well-documented tickets efficiently at scale.

The impact was tangible. Developers told me directly that this structured approach significantly reduced the time and effort they spent on bug fixes. Instead of spending time trying to reproduce issues or interpret vague descriptions, they could go straight to fixing. What I didn't expect was the ripple effect: other team members started adapting their own ticket submissions to follow the same format. The QA structure I introduced became a reference for how the team communicated issues.

This systematic approach was essential for hitting the final delivery deadline on March 31st.

Working across time zones

This was my first international role — working from Brazil, with a distributed engineering team across multiple time zones. The timezone gaps meant every handoff had to be self-explanatory, every design decision documented well enough to survive asynchronous review cycles.

How I worked

Cross-functional by default: weekly discussions with engineers and stakeholders to align on how domain concepts should be represented in the UI. I consumed existing PRD documentation, translated technical requirements into interface designs, managed the full handoff pipeline, and maintained quality control through structured QA. Every design decision was grounded in the documentation and team consensus — not assumptions.