Setup complexity blocks adoption

Users who want the product stop during setup, and support requests pile up before anyone has seen the product work.

A frequent cause is a missing state between not configured and live.

• Many more sign-ups than completed configurations is the clearest sign.
• Support volume peaks during onboarding.
• Setup screens that mirror the settings model show every option at once.
• Defaults can be unsuitable for a particular setup; Redbrix shows the assumptions that affect the result.

All options at once. Setup screens mirror the settings model and show every option. New users cannot tell the few that matter from the many with good defaults.

Implementation terms. Labels such as token types, hosting modes and connection tiers require an understanding of the architecture.

• Many more sign-ups than completed configurations
• Support volume peaks during onboarding
• A configuration looks complete and behaves unexpectedly
• Users ask which options they can skip

What helps:

• Visible, reversible states: not connected, connected, scoped, active
• Validation at each input, naming the specific error
• Defaults that produce a working setup, with the assumptions shown
• Optional settings moved out of the first run

The tensions:

• Defaults can be unsuitable for a particular setup; Redbrix shows the assumptions that affect the result. Showing which defaults were applied lets those users catch the problem early.
• Moving options out of the first run shortens setup and sends experienced administrators looking for settings they expected to see.

• Showing the full settings model on the first run
• Starting processing the moment a source is connected
• Validating only at the end of setup
• Reporting a failed connection without saying which input caused it

Where Redbrix has worked on this

• Bito: AI developer platform