FormaAI

Settings can become difficult to read when account connection, model selection and task assignment compete in the same place. FormaAI’s design gives each provider one card and separates the page into Providers, Usage and Language.

A provider card explains its capabilities, connection and model. The Usage section assigns transcription and analysis. This gives the page a sequence: connect and enable a provider, then choose its job.

The implementation filters the available task choices by capability and by whether a provider is both connected and enabled. An option therefore has to meet those conditions before it appears in the selector. The rule connects the interface’s promise to the application state.

A saved connection does not have to be used for every task. The design distinguishes a provider that is connected, one that is enabled and one currently selected for transcription or analysis.

Those states appear through labels and controls. Disabling a provider keeps its saved connection; removing a key is a separate action. This makes switching a service off less destructive and keeps the meaning of each control specific.

The design also puts model choice on the relevant provider card, where that decision has context. The task summary can then show which model the selected analysis provider will use.

Transcription and analysis are separate jobs with different provider requirements. Treating them separately makes the system easier to extend without asking the person using it to understand the entire provider architecture.

It also makes limits easier to explain. The web product and the proposed local transcription experience are distinct tracks. The current case concentrates on the provider settings and web workflow represented in the code and design specification.

The project combines an implemented web application with detailed settings design, provider capabilities and explicit launch preparation. Deployment configuration and external smoke tests remain separate from the work delivered in code.

The central contribution is the connection between an interaction model and its implementation: one place to manage each provider, a clear place to assign each task and visible states that describe what the product can currently use.