The Expert's question cards are currently all-or-nothing. QuestionsList.vue gates its Send button on every question having an answer, and it only renders radios and checkboxes, so there's no way to say something that isn't on the list.
Both of those are wrong for onboarding, where the whole point is that we're guessing at what someone's situation is. If none of four options fits, the user is stuck choosing a wrong one or abandoning the card.
Two changes:
Skippable. Drop the requirement that every question is answered. The Expert should get on with it using what it has, and treat an unanswered question as "they didn't want to say" rather than waiting.
An "Other" option with free text. Picking it reveals a text input, and whatever they type goes back as that question's answer.
Done when
- Send works with one or more questions left blank.
- An Other option accepts free text and the Expert receives it as the answer to that question.
- The Expert handles a missing answer without re-asking the same thing.
Worth knowing
There's a related problem in the same file worth fixing while it's open. compose() currently flattens every answer into one text string, "question answer1, answer2" per line, and sends it as an ordinary chat message. Which option belonged to which question isn't retained anywhere, on either side. That's fine for the Expert reading prose, but it means nothing downstream can use the structured answers, and a couple of things want to: the traits the Expert deduces about how technical the user is, and any surface treatment that shows answered questions as editable chips.
There's an existing escape valve that partly covers custom input already: the Edit button emits the composed answers into the message box so the user can rewrite before sending. Worth keeping, since it handles "your question is wrong" rather than just "your options are wrong".
The schema side needs a small change too, so the Expert knows an answer may be absent rather than assuming every question comes back filled. That part lands in the expert flows.
Use the existing ff-radio-group and ff-checkbox components for the Other option rather than raw inputs, so it stays consistent with the rest of the card.
The Expert's question cards are currently all-or-nothing.
QuestionsList.vuegates its Send button on every question having an answer, and it only renders radios and checkboxes, so there's no way to say something that isn't on the list.Both of those are wrong for onboarding, where the whole point is that we're guessing at what someone's situation is. If none of four options fits, the user is stuck choosing a wrong one or abandoning the card.
Two changes:
Skippable. Drop the requirement that every question is answered. The Expert should get on with it using what it has, and treat an unanswered question as "they didn't want to say" rather than waiting.
An "Other" option with free text. Picking it reveals a text input, and whatever they type goes back as that question's answer.
Done when
Worth knowing
There's a related problem in the same file worth fixing while it's open.
compose()currently flattens every answer into one text string,"question answer1, answer2"per line, and sends it as an ordinary chat message. Which option belonged to which question isn't retained anywhere, on either side. That's fine for the Expert reading prose, but it means nothing downstream can use the structured answers, and a couple of things want to: the traits the Expert deduces about how technical the user is, and any surface treatment that shows answered questions as editable chips.There's an existing escape valve that partly covers custom input already: the Edit button emits the composed answers into the message box so the user can rewrite before sending. Worth keeping, since it handles "your question is wrong" rather than just "your options are wrong".
The schema side needs a small change too, so the Expert knows an answer may be absent rather than assuming every question comes back filled. That part lands in the expert flows.
Use the existing
ff-radio-groupandff-checkboxcomponents for the Other option rather than raw inputs, so it stays consistent with the rest of the card.