Pages
Integrations — Ideas v5

Source: qdash /integrations — c61 simpler job + setup pass, 2026-08-13

This pass treats jobs as broad routing intents, not detailed operator outcomes. The operator already knows why they are here; the product should make what exists, what to choose, and what to do next unmistakable.

Frame

One question, then one next step

“Wake responders” and “get findings into the SOC” are useful research language, but they over-specify how a customer operates. In the product, use a broader question: What should qdash do outside qdash?

01
Show what exists
Created routes and local connections are the page. Unconfigured vendors are not.
02
Ask for intent
Use four stable movement types to narrow the catalog without guessing the customer workflow.
03
Give one verb
Add, choose, configure, test, enable, or manage. The current state determines the action.
Broad intentsSend security dataNotify peopleCreate follow-up workRetain evidence
Iteration A

Progressive setup prototype

The integration catalog is not a landing page. It is a step inside “Add connection,” after the operator has told us what kind of movement they need.

Connections
1 local connection · 0 external connections
Connection
qcontrol stream
Feeds this dashboard over loopback
Local inbound only
connected
No external connections

qdash is not sending findings, events, alerts, or evidence to another service.

Need a file instead?
Local exports stay separate from external connections.
Iteration B

The affordance is the state

Operators should not have to interpret five action buttons per job. Each connection state gets one primary verb; secondary inspection moves behind the route detail.

StateWhat the operator seesPrimary affordanceNext state
No routeExisting connections and an honest empty stateAdd connection Intent
Intent chosenOnly relevant destinationsChoose destination Configuration
ConfiguredScope, endpoint, and credential summaryTest connection Verified
VerifiedTest receipt and exact payload resultEnable connection Live
LiveHealth, last delivery, failures, and scopeManage Route detail
Iteration C

What disappears from the landing page

Simpler framing depends on subtraction. Readiness data is useful during setup and route management, but it should not compete with the first decision.

Remove from first view
All possible vendors shown before the operator asks for one
Projected volume, schema, and readiness metrics on every card
Separate inspect, simulate, export, configure, and go-live buttons
Detailed jobs that assume the customer’s operating model
Keep in first view
Created connections and their real health state
One explicit statement about whether data leaves qdash
One Add connection action
Local export as a separate, available-now tool
Coda

The recommendation

Keep the JTBD idea, but compress it to four intent filters. Lead with created connections and the truth that nothing external is configured. Make Add connection the dominant affordance, reveal destinations only after intent, and make the setup state itself determine the next verb. That gives the operator a clear path without asking them to decode the product’s internal readiness data.

Qpoint Brand Style Guide