Dotta UI / UX

Build interfaces that let the person accomplish their goal with little reading, few unnecessary decisions, and a clear sense of what happened. Put care into alignment, identity, transitions, and the complete journey.

Use these principles to guide judgment. The user's current instructions and the product's design system take precedence. Adapt each recommendation to the task: a useful explanation, distinct navigation tab, or multi-step flow earns its place when it helps someone understand a choice or complete an action. Do not turn a preference for less UI into a universal ban on a particular control.

Start inside the existing product

Identify the user's natural entry point, intended outcome, and the existing screen and components that own the behavior. Inspect the current implementation before proposing a new surface; old prototypes and component previews can be obsolete.

• Reuse the actual composer, picker, file tree, connection flow, task list, and navigation components. Similar CSS on a second implementation is insufficient.
• Put a new capability where users already manage that kind of thing. A new account connection belongs with other integrations; notification preferences belong with existing notification settings. Follow the product's established navigation rather than creating a destination for every backend object.
• Apply a correction to the shared component and affected variants within the assignment. A supplied URL often identifies an example, not the only instance of the problem. Avoid unrelated redesigns.

Follow the project's design guidance, shared components, and tokens for spacing, typography, color, and motion. Inspect the production UI when documentation or previews disagree with the current product.

Make each control and sentence earn its place

Before adding a field, setting, heading, badge, paragraph, or step, identify the decision or action it enables now. Remove it if the current context already supplies the answer or the element merely narrates normal behavior.

• Omit redundant headings, repeated selections, optional naming fields without a real need, routine Active/Idle badges, unsupported capability controls, and generic explanation beneath an obvious label. Prefer a useful default to a chooser with one possible answer.
• Use familiar action language: “Connect account,” “Add project,” “Save changes.” Avoid exposing internal concepts such as reconciliation or capability negotiation as everyday product choices.
• Reveal advanced configuration and alternate input methods through a small link, disclosure, or contextual menu. Put infrequent management actions there too. Let a linked title navigate to its object instead of adding an equivalent “Open…” button alongside it.
• Keep instructions that remove real uncertainty. Put prerequisites near the top, credential directions beside their fields, and useful help icons where they can be found. Use the actual known person, app, or account name. Explain consequential choices where they are made.

Do not confuse concise with cryptic. A short “How it works” explanation, a clear warning, or a larger connection action can be appropriate when it makes the next step understandable. Do not remove required consent or materially important permission information to make a screen smaller.

Reduce ceremony and preserve context

• Reuse compatible accounts and values the person can access. First-time setup and adding another item later may need different states: do not ask someone to reselect the connection they just created. Keep a way to change it when there is a real choice. Do not broaden access permissions as a UI shortcut.
• Group steps around distinct human actions. Complex external setup may need several stable steps; a simple credential connection should stay short. Do not copy one provider's wizard onto a flow with different requirements.
• Keep inline repair, approvals, previews, and task-related work in context. Breadcrumbs should return to the current object. An image gallery or plan should open without discarding or reloading the conversation unnecessarily.
• Make the obvious action work directly: Enter submits appropriate forms, clicking a copy action copies and confirms it, single-selection questions can advance after brief visible feedback, and selectors dismiss on outside click. Preserve draft input and useful navigation state.
• Avoid unnecessary confirmations and reason fields for reversible operations. Retain concise confirmation for destructive actions. Simplifying the UI must preserve the operation's actual semantics and authorization.

Keep everyday operation calm and blockers actionable

Do not surface a backend state machine as the main experience. Routine recovery, lease renewal, ordinary working states, and bookkeeping should usually happen without new cards, warnings, or decisions for the user.

• Avoid a toast that repeats feedback already visible on the current screen. A deliberate pause or cancellation should look neutral, not like a dramatic unexpected failure. A tool retry is not automatically a task-level failure.
• Show real blockers clearly and locally, with a useful action. For example, “Automatic recovery of this task stopped. [Retry]” communicates more usefully than an internal recovery explanation. Verify that Retry actually works.
• Make waiting understandable: connection testing, importing, and long work need timely progress. A disabled Continue button with no reason is broken UX. Detect completed setup automatically when the system can observe it.
• Present useful results richly; keep raw JSON, manifests, and diagnostics available on demand. Do not claim success before it is observed or conceal a failure the person must address.

Polish the composition and the transitions

• Favor compact, aligned rows and a clear hierarchy. Use consistent row heights, control sizes, carets, baseline alignment, and tree indentation. Add breathing room between fields and the footer. Avoid gratuitous borders and separators.
• Put the primary action on the right. In setup footers, keep Save & exit or Back/Cancel on the left in the same aligned row; related secondary actions sit beside the primary. Each step owns its whole footer, including conditional loading, error, and success states.
• Use recognizable service icons and relevant avatars in lists, selections, and previews. Keep them crisp and visible after selection and at smaller sizes. Familiar secondary actions can be icons or appear on hover/focus; essential help and actions must remain discoverable with keyboard and touch.
• Use restrained, purposeful motion: selected-row feedback, copy confirmation, progress, smooth disclosure, and continuous movement between related states. Preserve an element's position through an animation. Follow product motion tokens and reduced-motion behavior.
• Treat flashes, snapping, layout jumps, unstable sorting, and unnecessary reloads as defects. Keep the shell and reading position stable through loading, streaming, opening panels, and changing selections. Watch transitions in the running UI; a settled screenshot cannot prove they are good.
• Design mobile in its real shell, including the bottom bar and keyboard. Check intermediate widths too. Prevent squeezed send buttons, clipped choices, jumping popovers, awkward wrapping, and crowded chips. Use a mobile modal or sheet for selectors when the desktop popover does not fit. Preserve identity cues and test real touch interaction, not only a narrow viewport.

Make the preview and shipped feature agree

For a substantial new UI or redesign, prefer a short interactive preview before deep implementation, using Storybook or the project's existing preview tools. Follow an explicit request to review designs first; do not invent a new approval gate when implementation is already authorized. Scale this workflow down for a small edit; adding a preview framework is not a prerequisite for every UI change.

Keep each feature's component examples and user journeys together in a discoverable feature group, following the project's directory and navigation conventions. Make both kinds of review easy to find:

1. Individual components: cover every added or changed user-facing component and its relevant variants and states, using the shared production components.
2. User journeys: show realistic full pages in the actual app shell, with interactive or sequential stories that follow a person from the natural entry point to a useful result. Keep example data consistent across journey steps.

Use clear section names or numbered groups to make the feature easy to browse. For features spanning many components or pages, add a short review guide linking component coverage and the main journeys. Keep preview source, fixtures, helpers, and required configuration with the feature so another person can reproduce it.

Show the actual component and a realistic full-page or sequential journey view using the existing app shell. Include relevant first-use, returning, populated, long-content, loading, error, and mobile states. Make example data editable when the preview tool supports it. Keep demo scaffolding and developer explanations outside the product canvas; describe the intended route in the preview's notes.

Implement the approved design in the shared production components. Do not keep a beautiful “design” story and a divergent “implemented” version, or overwrite the approved design to match an inferior implementation. Remove or update obsolete stories that create confusion.

After implementation, start at the real entry point and walk through to a useful result. Inspect every visible sentence and watch each transition. Exercise the relevant alternate states and verify the result persists or can be used next. Check keyboard and touch interaction where relevant, recovery from errors, and whether the next useful action is clear. Separate functional success from experience quality: a saved result can still come from a confusing flow. Browser observation and automated tests provide different evidence. Report what was actually tested and any limits of that evidence; if the real interface was not exercised, say so. A working isolated screen does not establish a working journey.

Before handing off, ask: What can I remove, reuse, align, move into context, or actually try to make this easier for the person using it? Fix those concrete issues within scope. Keep the handoff focused on the user-visible change and observed result.