Product Design

UI/UX design that turns complex product ideas into clear, usable experiences.

I design web and mobile products by connecting business goals, user needs and practical implementation. The work can start with an early idea, an existing product that needs improvement, or a mature interface that needs a stronger system. My focus is not only how a screen looks. I work through structure, hierarchy, interaction, responsive behavior, reusable components and the details that help people understand what to do next.

Start a Project View related work

01Strategybefore polish

02Systembefore repetition

01Understand

Goals, users and constraints

02Structure

Flows, content and reusable patterns

03Create

High quality visual execution

04Refine

Responsive detail and delivery

How I approach UI/UX Design

Start with the problem, then build the visual system around it.

The strongest interface is the one that makes the product easier to understand while still feeling distinctive to the brand. I use visual design as a communication system: spacing creates rhythm, typography establishes priority, color communicates state, components create consistency and interaction patterns reduce uncertainty.

This service fits founders, agencies, SaaS teams, eCommerce businesses and product owners who need a new experience, a redesign, a design system or developer ready UI. Scope can range from a focused landing page to a multi role dashboard, customer portal or mobile application.

The end result is a structured set of screens and reusable decisions that can be reviewed, tested and implemented with less ambiguity. Depending on scope, I can provide user flows, low and high fidelity wireframes, interactive prototypes, responsive states, component libraries, variables, annotations and implementation guidance.

I treat the brief as the beginning of the conversation, not as a fixed collection of screens. Before production expands, I look for unanswered questions around audience, content, edge cases, ownership and technical constraints. This matters because many expensive revisions come from a requirement that was never made explicit. A short clarification early can prevent a large amount of visual and development rework later.

I also connect this work with the rest of your digital ecosystem. A service page should lead naturally to relevant portfolio work, the tools and technology library, useful blog articles and a clear contact path. Good internal linking is not only an SEO task. It helps visitors understand the relationship between what I offer, how I work and evidence from real projects.

Capabilities

What is included in the work.

Discovery and problem framing

The focus here is clarifying the product goal, target users, success criteria, content, constraints and current pain points before visual decisions begin. I treat this as part of the core service rather than an isolated extra because decisions in this area influence later layout, content and implementation choices. The exact depth depends on project size, but I make the assumptions visible so stakeholders can review the reasoning instead of only reacting to a finished visual.

The practical result is a shared definition of the problem so later screens solve a real need instead of decorating an unclear brief. During review I look at both the ideal scenario and the pressure points that can break the design, such as long content, missing data, small screens, repeated states or future additions. This helps the final solution remain useful after the first launch and gives the implementation team clearer rules for extending it.

Information architecture and user flows

The focus here is organizing content, navigation, actions, decision points and task sequences across the product. I treat this as part of the core service rather than an isolated extra because decisions in this area influence later layout, content and implementation choices. The exact depth depends on project size, but I make the assumptions visible so stakeholders can review the reasoning instead of only reacting to a finished visual.

The practical result is a logical path that lets users understand where they are, what they can do and what should happen next. During review I look at both the ideal scenario and the pressure points that can break the design, such as long content, missing data, small screens, repeated states or future additions. This helps the final solution remain useful after the first launch and gives the implementation team clearer rules for extending it.

Wireframes and interaction structure

The focus here is testing hierarchy, screen composition, form structure, states and interaction patterns without spending too early on visual polish. I treat this as part of the core service rather than an isolated extra because decisions in this area influence later layout, content and implementation choices. The exact depth depends on project size, but I make the assumptions visible so stakeholders can review the reasoning instead of only reacting to a finished visual.

The practical result is faster feedback on the product logic and fewer expensive changes after high fidelity design begins. During review I look at both the ideal scenario and the pressure points that can break the design, such as long content, missing data, small screens, repeated states or future additions. This helps the final solution remain useful after the first launch and gives the implementation team clearer rules for extending it.

Responsive web and dashboard UI

The focus here is designing layouts that adapt intentionally across desktop, tablet and mobile instead of simply shrinking the desktop screen. I treat this as part of the core service rather than an isolated extra because decisions in this area influence later layout, content and implementation choices. The exact depth depends on project size, but I make the assumptions visible so stakeholders can review the reasoning instead of only reacting to a finished visual.

The practical result is interfaces that preserve priority, readability and action clarity across different viewport sizes. During review I look at both the ideal scenario and the pressure points that can break the design, such as long content, missing data, small screens, repeated states or future additions. This helps the final solution remain useful after the first launch and gives the implementation team clearer rules for extending it.

Mobile app interface design

The focus here is designing touch friendly navigation, onboarding, forms, lists, detail views, commerce flows and app states for mobile products. I treat this as part of the core service rather than an isolated extra because decisions in this area influence later layout, content and implementation choices. The exact depth depends on project size, but I make the assumptions visible so stakeholders can review the reasoning instead of only reacting to a finished visual.

The practical result is a coherent app experience that respects smaller screens and repeated everyday interactions. During review I look at both the ideal scenario and the pressure points that can break the design, such as long content, missing data, small screens, repeated states or future additions. This helps the final solution remain useful after the first launch and gives the implementation team clearer rules for extending it.

Design systems and reusable components

The focus here is turning repeated interface patterns into components, variants, variables, tokens and documented usage decisions. I treat this as part of the core service rather than an isolated extra because decisions in this area influence later layout, content and implementation choices. The exact depth depends on project size, but I make the assumptions visible so stakeholders can review the reasoning instead of only reacting to a finished visual.

The practical result is a product that can grow without every new screen becoming a one off visual decision. During review I look at both the ideal scenario and the pressure points that can break the design, such as long content, missing data, small screens, repeated states or future additions. This helps the final solution remain useful after the first launch and gives the implementation team clearer rules for extending it.

Interactive prototyping

The focus here is connecting screens and key states so important journeys can be reviewed before development. I treat this as part of the core service rather than an isolated extra because decisions in this area influence later layout, content and implementation choices. The exact depth depends on project size, but I make the assumptions visible so stakeholders can review the reasoning instead of only reacting to a finished visual.

The practical result is a concrete way for stakeholders and developers to understand intended behavior, transitions and edge cases. During review I look at both the ideal scenario and the pressure points that can break the design, such as long content, missing data, small screens, repeated states or future additions. This helps the final solution remain useful after the first launch and gives the implementation team clearer rules for extending it.

Developer handoff and design QA

The focus here is preparing structured files, naming, assets, responsive guidance and implementation notes, then reviewing the built experience where needed. I treat this as part of the core service rather than an isolated extra because decisions in this area influence later layout, content and implementation choices. The exact depth depends on project size, but I make the assumptions visible so stakeholders can review the reasoning instead of only reacting to a finished visual.

The practical result is less interpretation during development and a final product that stays closer to the approved design. During review I look at both the ideal scenario and the pressure points that can break the design, such as long content, missing data, small screens, repeated states or future additions. This helps the final solution remain useful after the first launch and gives the implementation team clearer rules for extending it.

Process

A structured process with room for the project to evolve.

Not every engagement needs the same amount of discovery, design or development. I keep the stages flexible, but the sequence below explains how I move from uncertainty to a deliverable that can be reviewed and implemented. Smaller projects can combine stages, while larger products can repeat them feature by feature.

01Step

Understand the brief

I begin with the business objective, product context, audience, required features, technical platform, timeline and existing material.

This creates a practical scope and prevents the design from drifting into attractive screens that do not support the actual product.

At this stage I document the decision at the level the team actually needs. That can mean a simple approved direction for a small website or a more explicit set of states, components and notes for a product with several contributors. The goal is enough clarity to move forward confidently without creating documentation that nobody will maintain.

Feedback is most useful when it is tied to the objective of the stage. I separate preference from functional risk, explain tradeoffs when there are multiple valid options and refine the solution without losing the underlying hierarchy. This keeps review focused and prevents late changes from accidentally undoing earlier decisions.

02Step

Research the context

I review comparable products, relevant interaction conventions, current analytics or feedback when available, and the competitive visual landscape.

The goal is not to copy competitors. It is to understand what users may already expect and where the product can be clearer or more distinctive.

03Step

Map journeys and content

I define major user roles, tasks, entry points, navigation relationships, content groups and important decisions.

This produces a usable information structure before screen styling introduces additional complexity.

04Step

Create wireframes

I sketch or build low fidelity layouts for the key screens, prioritizing hierarchy, task completion and state coverage.

Wireframes make structural feedback faster because stakeholders can discuss the experience without being distracted by final colors or imagery.

05Step

Build the visual direction

I establish typography, color, spacing, component language, icon treatment and the visual character appropriate for the brand.

The interface gains personality while keeping the hierarchy and usability decisions from earlier stages intact.

06Step

Create responsive screens and components

I expand approved patterns into the required screens, responsive states, components, variants and reusable layout rules.

The design becomes a system rather than a collection of disconnected artboards.

07Step

Prototype and review

I connect important journeys, present flows in context, collect feedback and refine interaction or content where the prototype exposes friction.

The team can validate how the experience feels before implementation creates a higher cost of change.

08Step

Handoff and implementation support

I organize the Figma file, prepare assets and specifications, identify behavior that needs explanation and support implementation review when part of the engagement.

Developers receive a cleaner source of truth and the final product has a stronger chance of matching the intended experience.

Tools and technology

The tools support the process, not the other way around.

I choose tools according to the deliverable and the team that will use it next. Modern platforms offer powerful component, responsive and handoff features, but those features only help when the file or implementation is organized around understandable decisions. I keep source material structured and use reusable patterns where they reduce repeated work.

Figma

Interface design, Auto Layout, components, variables, prototypes and developer handoff

Adobe XD

Legacy or client specific interface files and prototyping workflows

Adobe Photoshop

Image preparation, compositing and interface visual assets

Adobe Illustrator

Vector assets, icon preparation and scalable graphic elements

HTML

Understanding semantic structure and implementation constraints

CSS

Responsive layout thinking, states, spacing and visual feasibility

JavaScript

Interaction feasibility and front end behavior awareness

The linked technology pages explain the tools used across my design and development work in more depth. I choose the stack around the actual service: design work may rely on collaborative visual systems, web work may use semantic frontend and server side technologies, and native mobile work uses the platform specific IDE, language and device tooling needed for the target application. The goal is maintainable delivery rather than adding technology simply because it is available.

Deliverables

What you can expect to receive.

Discovery summary and design direction

This deliverable is prepared so it can be reviewed in context and used in the next stage of the project. I keep naming and structure consistent, include the supporting states that materially affect implementation, and avoid handing over disconnected files without explaining how they relate to the wider system.

User journeys and task flows

Information architecture

Low fidelity wireframes

High fidelity responsive screens

Clickable Figma prototype

Reusable component library

Variables and design tokens where useful

Developer ready assets and specifications

Design QA notes and implementation support

Good fit for

Projects where thoughtful structure matters as much as visual quality.

New SaaS products and MVPs
Dashboard and admin experiences
Customer or client portals
eCommerce web and mobile flows
Existing products that need a UX redesign
Landing pages and marketing websites that require product level structure

Quality principles

Details I protect throughout the project.

Clarity before decoration

Every important screen should communicate purpose, priority and next action before visual effects are added. Strong aesthetics matter, but they work best when the underlying information is easy to understand. I review this principle against real content and likely future changes rather than treating it as an abstract design rule. When there is a tradeoff, I prioritize the choice that keeps the experience understandable, maintainable and aligned with the primary user task.

Consistency without monotony

Repeated patterns should behave predictably, while composition and content can still create variety. Components reduce cognitive load for users and maintenance effort for product teams. I review this principle against real content and likely future changes rather than treating it as an abstract design rule. When there is a tradeoff, I prioritize the choice that keeps the experience understandable, maintainable and aligned with the primary user task.

Responsive by intention

Mobile is not a reduced desktop screenshot. Navigation, content order, table behavior, spacing and touch targets need deliberate decisions for each meaningful breakpoint. I review this principle against real content and likely future changes rather than treating it as an abstract design rule. When there is a tradeoff, I prioritize the choice that keeps the experience understandable, maintainable and aligned with the primary user task.

Accessible contrast and states

Color should not be the only way to communicate meaning. I consider readable contrast, focus behavior, labels, interactive states, clear errors and comfortable target sizes as part of interface quality. I review this principle against real content and likely future changes rather than treating it as an abstract design rule. When there is a tradeoff, I prioritize the choice that keeps the experience understandable, maintainable and aligned with the primary user task.

Real content where possible

Interfaces become more realistic when they are designed with representative names, prices, messages, records and edge cases rather than perfect placeholder content. I review this principle against real content and likely future changes rather than treating it as an abstract design rule. When there is a tradeoff, I prioritize the choice that keeps the experience understandable, maintainable and aligned with the primary user task.

Design for empty, loading and error states

Products are experienced between ideal moments too. I account for empty screens, incomplete data, disabled actions, validation, loading and failure states where they materially affect a user journey. I review this principle against real content and likely future changes rather than treating it as an abstract design rule. When there is a tradeoff, I prioritize the choice that keeps the experience understandable, maintainable and aligned with the primary user task.

Systems that developers can interpret

Components, variables, naming and sensible file organization make the design easier to inspect. Figma Auto Layout and reusable component behavior are used where they improve responsiveness and handoff. I review this principle against real content and likely future changes rather than treating it as an abstract design rule. When there is a tradeoff, I prioritize the choice that keeps the experience understandable, maintainable and aligned with the primary user task.

Measure success against the task

A redesign is useful when it improves comprehension, completion, trust or maintainability. Visual polish is part of the outcome, not the only definition of success. I review this principle against real content and likely future changes rather than treating it as an abstract design rule. When there is a tradeoff, I prioritize the choice that keeps the experience understandable, maintainable and aligned with the primary user task.

Collaboration and feedback

I keep collaboration visual and specific. Instead of asking for broad approval at the end, I prefer to show meaningful checkpoints where the team can react to structure, direction and detail at the right time. That makes feedback easier to act on and reduces the chance that a late preference forces the project back through several completed stages.

When several stakeholders are involved, I encourage one consolidated source of feedback. Conflicting comments are normal, but they should be resolved against the agreed product goal rather than implemented independently. I can explain why a design decision exists, what alternatives were considered and what changes would affect other parts of the system.

I also think about the person who inherits the work. A design can look excellent in a presentation and still become difficult to extend if components, templates or files are inconsistent. My handoff aims to make the logic visible so the next designer, developer or content editor can understand how the pieces are intended to work together.

After implementation, visual QA can be as important as the original design. Real browsers, real product content and real integrations reveal issues that static screens cannot. If the engagement includes build support, I review key pages and states, identify differences that affect usability or brand consistency and help prioritize what should be corrected before launch.

FAQ

Common questions about UI/UX Design.

Can you start from only an idea or rough notes?

Yes. A project does not need a finished specification before design begins. I can help turn rough requirements into screens by first identifying the audience, essential tasks, content and assumptions that need validation. The early phase is used to reduce ambiguity before high fidelity work.

The exact answer can change with project scope, platform and available access, so I confirm these details before work begins and document any important dependency that affects timeline or implementation.

Do you design both websites and mobile apps?

Yes. I design responsive websites, web applications, dashboards and mobile application interfaces. The process is adjusted to the product because a marketing website, a data heavy dashboard and a repeated mobile workflow have different navigation and interaction needs.

Will I receive a design system?

For projects with repeated patterns, I build reusable components and organize common decisions such as colors, typography, spacing and states. The depth of documentation depends on scope, but I avoid creating disconnected screens when a component based approach will make future work easier.

Can developers use the Figma file directly for handoff?

Yes. I structure final files so developers can inspect layouts, assets and reusable components. Where useful I use variables, component properties, Auto Layout and annotations. I also include implementation notes for behavior that cannot be understood from a static screen alone.

Do you conduct user research?

I can include lightweight discovery, competitive review, stakeholder interviews, flow analysis and usability oriented validation depending on the project. Large formal research programs with dedicated recruitment can be planned separately when the product needs that level of evidence.

Can you redesign an existing interface without changing the brand?

Yes. A redesign can preserve established brand elements while improving hierarchy, responsiveness, consistency and interaction. I first identify what should remain recognizable and what is causing friction so the result feels like an evolution rather than an unrelated new product.

Do you support dark mode?

Yes when the product requires it. Dark mode is treated as a coordinated color mode rather than a simple inversion. Backgrounds, surfaces, borders, text hierarchy, semantic colors and imagery need to remain readable and consistent across both modes.

Can you also build the website after designing it?

For suitable projects I can continue into WordPress, Elementor, Shopify or front end implementation work. This is especially useful when the same person needs to preserve the design intent during build. For other stacks I can provide a development ready handoff and collaborate with the implementation team.

Contact Info

UI/UX Design