I turn product ideas into user journeys, wireframes and practical developer handoff notes. Resolve navigation, role differences and missing states before committing to implementation.
Overview
Before writing code, the best investment is clarity. I create wireframes and UX flows that map out every screen, every interaction, and every edge case — so your team is aligned, stakeholders can give feedback early, and developers have a clear blueprint to build from.
This stage saves weeks of rework downstream and dramatically improves the final product.
My Process
Step 1 — Discovery
I start by understanding your users, your goals, and your constraints. This includes:
- User persona definition (who is using this, and why?)
- Mapping core user journeys and jobs-to-be-done
- Competitive analysis of similar products
- Feature prioritization (must-have vs. nice-to-have)
Step 2 — Low-Fidelity Wireframes (Balsamiq)
Balsamiq's intentionally rough style keeps feedback focused on structure and flow, not aesthetics:
- Every screen in the product mapped out
- Navigation flows and user journeys
- Information architecture (what goes where)
- Quick iteration with client feedback — multiple rounds until the structure is right
Step 3 — High-Fidelity Design (Figma)
Once the structure is approved, I move into Figma for polished, brand-aligned screens:
- Pixel-perfect layouts matching your brand identity
- Typography, color system, and spacing defined as design tokens
- Component library built inside Figma (buttons, inputs, cards, modals, etc.)
- Responsive variants — mobile, tablet, and desktop frames
- Dark mode variants if needed
Step 4 — Clickable Prototype
I link all Figma screens into a clickable prototype:
- Stakeholders can tap/click through the full product flow
- Realistic transitions and hover states
- Shareable via Figma link — no install required
- Perfect for investor demos, client presentations, or user testing
Questions about product wireframing and ux design
What should I prepare for product wireframing and ux design?
Start with the users and the workflow that matters most. For this service, share examples related to user-role and workflow mapping, current systems and any constraints on data access. Include a target date and budget range. This makes it possible to distinguish necessary work from optional additions before proposing a milestone.
How do you estimate the wireframes ux scope?
I separate the initial workflow from secondary features, then review information architecture and the dependencies it introduces. An estimate should list assumptions, exclusions and acceptance checks. Unknowns such as missing recovery screens may need a short investigation before a fixed commitment is sensible.
Can you work with existing Figma systems?
An existing Figma implementation can be the starting point. I would review the relevant code, configuration and current behavior first, then propose a narrow change. Access to a staging environment and reproducible examples helps assess contradictory navigation paths without relying on live customer records.
How is low-fidelity screen wireframes checked?
The acceptance conditions should cover successful completion and a deliberate failure. For low-fidelity screen wireframes, we agree on representative fixtures and the expected user-visible state. Tests should verify the actual boundary rather than just the shape of a response. Any specialist compliance or security review is scoped separately.
What happens if unreviewed role differences occurs?
The application needs a defined response to unreviewed role differences. Depending on the workflow, that may be a retryable state, preserved input, an operator queue or a human handoff. We should decide which actions are safe to repeat and what evidence support staff need before accepting the design.
Who maintains the product wireframing and ux design after launch?
Ownership of the product wireframing and ux design deployment, credentials and operational checks is agreed before release. The handoff documents edge-case and empty-state coverage and the remaining support needs. Ongoing maintenance can be discussed as a separate engagement; it should not be assumed to include unlimited features, platform changes or external-provider costs.
Figma