Product design & UX

The interface works. The product still does not make sense.

Software can be technically correct and hard to use. The buttons work. The API returns what the tests expect. The database has the right rows. Users still cannot finish an ordinary task. They cannot find the feature. They do not understand why an action failed. They abandon a workflow because the next step is not obvious. They contact support for something the application was supposed to make easier.

Teams often treat that as polish to do after the engineering is finished. How people understand the system, and how they act on it, is part of the design.

I help businesses and engineering teams turn complicated requirements into products that hold together. I find out what users are trying to do, design the workflows that support those goals, and build interfaces that stay clear across the full range of application behavior: state, permissions, latency, validation, errors, and consequences. I work across product thinking, interaction design, visual design, and frontend engineering, because an interface is not a stack of screens. It is a working relationship between a person and a system.

The product should be easier to understand, easier to use, and easier to change as it grows.

The pattern I walk into is engineers explaining the interface to customers, every new feature adding another navigation item, or users finding paths nobody intended.

A confusing screen is often a confusing product decision

A team can spend weeks on a dashboard without asking whether that information belongs together. A form has twenty fields because the table has twenty columns, not because a person needs to think about twenty things. A workflow has six steps because the application copies the org chart, and customers do not work that way.

Color, spacing, and type will not fix that. I start from the user’s objective and the system’s behavior. What are they trying to accomplish? What information do they need? Which decisions are theirs? What can the application handle? What happens when something goes wrong?

The answer might be a different screen. It might be a simpler feature, a reorganized workflow, or a requirement that should be reconsidered. I treat product design as adjacent to engineering: how people interact with the software, how complexity is shown, and how the system says what it is doing. The interface is where those decisions become visible.

What I bring

The work people are actually trying to do

Requests arrive as features. “We need a dashboard.” “Customers want bulk editing.” “Administrators need more controls.” Those can be real needs, and they still may not describe the problem.

I start with the users, their goals, and the workflows they already follow. Depending on the project that means stakeholder interviews, conversations with users, support tickets, product analytics, existing workflow docs, or watching people use the current application. I separate what they ask for from what they are trying to accomplish. More filters can mean the information is poorly organized. A dashboard request can mean one answer is hard to find. Bulk editing can mean the system forces too many repetitive actions.

Getting that distinction right stops a team from building more interface around a problem that should be solved a different way. I name the primary user groups, what they are responsible for, the tasks they do most, and the constraints they work under, before implementation starts.

Workflows, then screens

A product is a sequence of actions, decisions, and responses. People move between screens, enter information, wait, correct mistakes, and come back to unfinished work. If those transitions were never designed, you have a pile of screens.

I map the important workflows from start to finish: where a task begins, what information it needs, which decisions have to be made, and what “done” means. I also map the other paths. Required information is missing. The user needs to save and return. An operation needs approval. They lack permission. A completed action needs to be undone.

Those questions define behavior before visual detail takes over the conversation. Depending on the complexity I use flow diagrams, state diagrams, wireframes, or an interactive prototype. I want fewer unnecessary steps and transitions that are unambiguous, so people can do the work without understanding the internal architecture of the software.

Information architecture that can grow

Navigation accumulates. New capabilities land in old menus. Admin tools sit next to everyday work. Similar functions get different names. Important information scatters across screens in the order the features were built.

I organize around the concepts and tasks that matter to users: how information is grouped, how features are named, which relationships need to be visible, and how someone moves. That may mean restructuring navigation, pulling related workflows together, separating administrative functions, or making a clearer distinction between kinds of information.

I also plan for the structure to grow. Navigation that works for five features can fail at fifty. A dashboard that starts with a handful of metrics becomes unreadable as sources get added. I want a structure that can take reasonable growth without a full redesign every time you add a capability.

Hierarchy, so people can see what matters

Every screen competes for attention. Headings, navigation, controls, status, tables, charts, and explanatory text all change how fast someone understands what they are looking at. Without hierarchy, the user does the sorting.

I design layout, type, spacing, color, grouping, alignment, and where an action sits relative to the information it affects. Primary actions stay distinct from secondary ones. Important information stays distinct from supporting detail. Controls stay distinct from static content.

Data-heavy applications get extra attention. Dashboards, admin tools, and operational software often have to show a lot without burying the person using them. Removing information, or spreading it across more screens, is not always the fix. Sometimes the screen needs more density, related values grouped, comparisons made easier, or detail revealed only when it is useful. Complexity should be navigable.

The states between success and failure

Mockups show the favorable case. The dashboard has useful data. The form is valid. The network is instant. The user can do everything on the screen. Production is slower, missing data, expired sessions, invalid input, failed background work, changed permissions, and external services that are down.

I design the states that get skipped: loading, empty, error, partial success, validation, confirmation, disabled controls, permission restrictions, and recovery. For each one I decide what the application should say and which actions remain. If an upload fails, can they retry without starting over? If a payment is processing, does the interface block a second submit? If a background task takes minutes, can they leave and come back? If a record cannot be deleted, does the application say why?

Those answers affect the interface and the architecture under it. A person should not have to guess whether an action succeeded.

Patterns people can reuse

Inconsistent behavior makes people relearn the product. A confirmation dialog works one way in one section and another way elsewhere. Search filters differ. Validation fires at different times. Similar actions use unrelated icons. Each one is small. Together they make the application harder to learn and less predictable.

I set interaction patterns that can be reused: navigation, forms, tables, search, filtering, sorting, dialogs, notifications, status, and the workflows that show up everywhere. I specify when validation runs, how errors are shown, which actions need confirmation, which keyboard interactions are supported, and how the component behaves on a smaller screen.

Where it earns its keep, those decisions become a design system. People should be able to carry what they learned from one part of the product to another. Specialized workflows can still get special treatment when they need it.

Accessibility as part of the design

If accessibility waits for a compliance pass at the end, the structural decisions are already expensive to change. I include it throughout: semantic structure, keyboard use, focus, contrast, readable type, form labels, how errors are communicated, and how interactive components behave with assistive technology. I also look at screen size, zoom, input method, and user preferences.

Clear labels, predictable navigation, meaningful errors, and well-structured content help a wide range of people, including people who do not think of themselves as needing an accommodation. Where it is appropriate I evaluate a design or an implementation against the relevant WCAG criteria and call out what needs a fix or a specialist test.

Prototypes for the decisions that are expensive to get wrong

Some decisions cannot be judged from a requirements doc or a static mockup. A workflow looks reasonable on paper and becomes cumbersome as soon as someone tries to finish it. Navigation looks intuitive until someone has to find a specific feature. A complex interaction exposes dependencies planning never named.

I prototype so those assumptions can be tested. That might be a rough wireframe, an interactive design prototype, or a functional frontend experiment. Fidelity should match the question. A rough prototype can test the shape of a workflow. A more detailed one is warranted for complex interaction, responsive behavior, or an interface that is sensitive to performance.

I test the assumptions that matter before they become expensive engineering commitments. Not every feature needs a research program. I use the cheapest method that produces useful evidence.

Design that frontend engineering can build

Products lose consistency in the handoff. A component is specified visually and its behavior is not. A responsive layout is shown at one width. An interaction depends on application state the design never considered. Engineers fill the gaps. Sometimes that is fine. Sometimes it produces inconsistent behavior, or forces the design to be reopened late.

I work on both sides of that boundary: component architecture, state, responsive behavior, accessibility, loading, and the constraints of the application you already have. Where it helps, I turn design decisions into reusable frontend components, tokens, and conventions, and I document the intended behavior, including the edge cases and the states. Engineers should not have to reconstruct the product decisions in order to implement them.

Whether the experience actually got better

A visual change is easy to see. A usability change needs a definition of success before you make it. A cleaner workflow can add steps. Simpler navigation can hide a feature someone still needs. A new dashboard can look better and help nobody decide anything.

Depending on the product I look at task completion, time on task, error rate, abandonment, support requests, adoption, or qualitative feedback from watching people use it. Where I can, I take a baseline and compare the change to the original problem. Not every decision needs an experiment, and not every real improvement reduces to a number. The team should still be able to say why a change was made and what evidence would show that it helped.

The decisions that happen before a design tool

A product can have careful type, a considered palette, and polished motion, and still be confusing. The problem might be the workflow, the terminology, how information is organized, the permissions model, or an assumption about what users already know. Those need product thinking.

Sometimes the right move is a redesigned interface. Sometimes it is removing a step, consolidating features, changing the data model, or asking whether the feature should exist. I combine research, interaction design, information architecture, and implementation, and I am trying to make the product better, not to create more design work.

What I will not recommend

I will not recommend replacing a familiar interface because a visual trend got popular. I will not introduce unusual navigation when an established convention would be easier to learn. I will not recommend motion that slows an important workflow or makes the interface less accessible. I will not turn a data-heavy operational tool into a sparse set of oversized cards when people need to compare information. I will not propose a comprehensive design system when a small set of consistent components would solve the problem you have.

Every custom interaction has to be implemented, tested, documented, and maintained. Every departure from a convention is something new for users to learn. Those costs are worth paying when the benefit is real. I favor interfaces that are clear, predictable, and help people finish their work.

What you leave with

What you get depends on whether this is a new product, a feature, or an existing application. It may include:

• A UX assessment of the current workflows, information architecture, usability problems, accessibility concerns, and where an improvement would matter.
• User and workflow definitions: goals, task flows, responsibilities, and the interaction scenarios that matter.
• Information architecture: navigation, content relationships, and a structure that makes the product easier to understand.
• Wireframes and interactive prototypes, so a workflow can be tested before it is built.
• High-fidelity designs for the important screens, including responsive behavior and the application states that matter.
• A component system sized to the product: tokens, interaction patterns, specifications, and implementation guidance.
• Findings from review or testing, ordered by user impact and implementation effort.
• An engineering handoff: the decisions, the expected behavior, the edge cases, and what implementation has to account for.

If the engagement includes frontend development, that can also mean production-ready components and implemented interfaces. Your team should know how the experience is supposed to work, why the important decisions were made, and how to extend the product without losing consistency.

Who I do this with

Software companies whose products got more complicated as features and customers accumulated. Founders building a new application. Engineering teams without product design capacity. Organizations modernizing an internal tool or a customer-facing system.

Some teams have a clear product vision and need help turning it into workflows and interfaces. Some have a working application whose usability has not kept up with the technical capability. Some have years of interface decisions made independently by different engineers, and users feel every one of them.

I connect what users need, what the product requires, how the interface is designed, and how it will be built. Good product design makes software easier to learn, easier to move through, and more predictable. It cuts decisions that do not need to be made, makes the important information obvious, and helps people recover when something goes wrong. It also gives engineering a more consistent base for the next capability.

I account for the people using the software and the people who have to build and maintain it: the work, the workflows, the interactions, and the operational reality underneath. Often the useful move is making the product you already have make sense, and leaving the feature list alone.