React Selection Guide
A visitor who does not already know your part numbers will not read a forty-row comparison table — they will leave. This asks a handful of questions in their language, then names one part and explains why it was chosen.
Find the right crypto core
Three questions, one recommendation.
What are you targeting?
Silicon area and clock budget differ enormously between the two.
Installation
Props
| Prop | Type | Description |
|---|---|---|
| title | string | Heading above the progress bar |
| description | string | Optional supporting line |
| questions | GuideQuestion[] | { id, question, help?, options } |
| resolve | (answers: Record<string,string>) => GuideResult | Maps answers to the recommendation |
GuideResult is { title, subtitle?, partNumber?, reasons?, specs?, cta? }. Because resolve is a plain function, the tree can be a lookup table, a scoring model, or a handful of if statements — whatever matches how your application engineers actually reason.
Writing good questions
Three rules, learned the hard way:
- Ask about the application, not the spec. "Is the device physically accessible to attackers?" converts; "Do you need first-order DOM masking?" does not.
- Keep it to three or four questions. Every additional step costs completions.
- Always show your reasoning. The
reasonschecklist is what makes the recommendation credible enough to act on — without it the result reads as a guess.
Send the result straight into the RFQ Builder, or let visitors adjust the details in the Product Configurator.
New components every week
Get the week's new Kelvin UI components and templates in one short email. No spam, unsubscribe anytime.