Start with a task, a role, and a useful outcome

Before deciding which screens to add, we need to understand what someone is trying to accomplish. Who creates a record? Who reviews it? What information does each person need before they can act?

I use those questions to frame the design scope. You can bring an early idea, an existing workflow, or a product with a specific problem. Existing customer feedback and product evidence help distinguish what we know from what still needs investigation.

Flows, structure, and interface decisions

Depending on the agreed scope, the work can include:

  • A problem statement and defined feature boundaries.
  • User flows and information architecture.
  • Interface designs, including relevant empty, loading, error, and success states.
  • An interactive prototype for reviewing the proposed experience.
  • Reusable components and guidance on their behavior.
  • Design files, implementation notes, and an agreed handoff or build.

For example, designing an approval flow means considering who can submit, what the reviewer sees, and what happens when an item is returned. The screen layout follows those decisions.

A first version or a focused improvement

For a new product, we identify the core task and decide what belongs in the first version. Later features stay visible without becoming part of the initial commitment.

For an existing product, we can focus on a defined journey, such as setup, reviewing information, or completing a recurring task. Share the current experience, known constraints, and evidence behind the problem so we can establish what needs to change.

If the main decisions concern a phone-based experience, see mobile app design.

Work with your developers or scope a build

For design-only work, we agree the files, interaction details, and component references your team needs. Where implementation review is included, we also define when it happens and which screens or flows it covers.

I can develop agreed parts of the experience when the requirements and technical fit are established. I use tools such as Claude Code, Codex, and Cursor where appropriate in that development workflow. Data connections, business rules, and launch responsibilities are scoped explicitly.

If your product decisions are already made and implementation is the main need, explore turning product designs into working software. Existing designs can be reviewed as the starting point for that work.

Questions about product design

Can you improve an existing product?

Yes. We can define a specific workflow or interface problem to work on. The scope depends on the current product, available evidence, and your team’s constraints.

Can you design a first version?

Yes. We start by defining the core task, intended users, and boundaries of that version. The deliverable can be designs and a prototype, with development separately agreed.

What research is included?

We agree the research questions, methods, participant access, and responsibilities before including research in the scope. Existing feedback can inform the work; new interviews or usability tests require an explicit plan.

Is a prototype ready to launch?

A prototype helps review a proposed interaction. It does not by itself establish that the product is connected to live data, ready for operational use, or validated with users.

How do you work with our developers?

We establish the implementation constraints and design references early, then agree the handoff format and any review points. A new design system is included only if the project needs and scopes one.

How are cost and timing agreed?

They depend on the flows, states, research, implementation needs, and delivery responsibilities. These are defined before a proposal is finalized.

What does your product need to make easier?

Share the product or idea, the people using it, and the task you want to improve. Let me know what your team already has and whether you need design support, development, or both.