Book a project call

Product & Interface Design

Product and interface design for in-app SaaS: full journeys, every state, edge cases, permissions, and the system that keeps squads coherent — with developer-ready handoff.

Part of Creation. Built for product and engineering leads on complex B2B surfaces — the product people live in after the sales call.

A demo path is easy. Real use is empty states, errors, permissions, density, and mobile. Marketing sites and conversion shells are Web Design & UX. This page is the in-app product.

Screens without states fail in production

Happy-path mockups win stakeholder reviews and lose the first week of real use. Someone hits an empty table. A permission blocks an action. An API times out. A power user needs density the first-timer cannot survive. If those moments were never designed, eng invents them under pressure, and the product feels unfinished forever.

We design the product people live in after the sales call.

Who it's for

  • SaaS and platform teams with real workflows and real accountability
  • Products that work in the pitch and break in production states
  • Multi-role products (admin / member / guest) where one UI cannot serve everyone the same way
  • Teams who need handoff eng will not rewrite

Objections we clear

  • “Design only did the happy path”
  • “Eng never knows what happens if X”
  • “Every squad invents its own UI”
  • “Power users and first-timers both lose”
  • “Onboarding dumps features instead of getting someone to first value”

What we tackle

Journey mapping

We identify the journeys that pay the bills. Activate, configure, invite, complete the core job: and cut the rest from the first release of the engagement.

States & edge cases

Empty, loading, partial, error, success, permission denied, offline. Designed on purpose so eng is not guessing.

Dense product UI

Tables, builders, filters, multi-step tools. Clarity under complexity, not decoration on top of chaos.

Handoff for engineering

Specs that answer behavior questions in the file, variants, constraints, acceptance: not Slack archaeology after sprint planning.

What you get

  • Journey maps and specs for paying flows
  • Empty, loading, error, and permission states designed on purpose
  • Hi-fi UI for critical surfaces (and responsive where the product requires it)
  • Component language aligned with your system or foundations we start together
  • Developer-ready handoff (specs, behavior, edge cases)
  • Typical multi-journey work as a defined project; a single dense surface can start as a 1–3 week sprint, see Rates

How it works

1. Map the bills-paying journeys: cut the rest. *Deliverable: journey inventory + scope cut list.* 2. Design states, not screens: including failure. *Deliverable: flows, wires, state matrix.* 3. Systematize: components and rules. *Deliverable: UI + component notes.* 4. Handoff with eng: questions answered in the file. *Deliverable: handoff package, walkthrough, open issues logged.*

When the problem is fuzzy, we start with a UX Audit. When the UI is decades of accretion, see Legacy UX Modernization.

Engagement shapes

  • Product UI project: multiple journeys and a coherent system language
  • Surface sprint: one dense tool (builder, inbox, settings) under time-box
  • Embedded cadence: phased delivery alongside your eng roadmap (scoped quarters, not open-ended “staffing” theater)

Proof

Sendoso. Touch builder, marketplace, tracker: complex B2B made operable. Unlayer: editor depth without chaos. Governata. Complex data made usable. SaaS buyers: For SaaS.

Fit / not for

For products with workflows and accountability. Not for visual-only reskins that refuse to touch IA or states. Not for “just make the dashboard pretty” when the job-to-be-done is still undefined.

Frequently asked questions

How is this different from Web Design & UX?

Product & Interface Design is in-app SaaS: workflows, states, permissions, density, and eng handoff. [Web Design & UX](/services/creation/web-design-ux) is the public shell — marketing site, conversion paths, responsive product face. Same studio, different surface. We sequence them when you need both.

What is product design versus interface design?

Interface design focuses on screens and interaction. Product design covers the full journey, states, edge cases, and system. Strong product work includes both. We do not ship a gallery of disconnected screens.

Why do empty and error states matter?

Real use is full of them. A product that only handles the ideal path feels broken the moment reality intervenes. Designing those states is what makes a product feel finished.

Can you work with our engineering team?

Yes. We design for handoff, specs, systems, and judgment: so engineers can ship without guessing. That is a core buying reason for this SKU.

How does this relate to a design system?

Product UI without a system decays. We either extend your system or start foundations via Design Systems. The goal is adoption, not a pristine Figma library nobody opens.

Do you design mobile apps as well as web?

Yes when the product requires it. We design for the surfaces your users actually use. Web app, responsive web, or native flows scoped into the engagement.

How do you handle multi-role products?

We design role-aware journeys and permissions early. One “average user” persona usually fails B2B products. Admin, member, and guest often need different paths through the same system.

What about AI features inside the product?

AI is product UX, not a widget. If you are adding assistive or generative features, see [Creation](/services/creation), trust, recovery, and oversight designed in.

How long does a typical engagement take?

A single dense surface can move in a 1–3 week sprint. Multi-journey SaaS work is usually a phased project over weeks to a few months. We estimate against journey count and unknowns, not vibes.

Scope SaaS product UI

Bring the journeys that generate revenue or retention risk. We will tell you what fits a sprint versus a project, and what to cut.

Book a project call
Contact us