I'm developing an app that will work as a troubleshooter. In this, I want to ask the customers only relevant questions instead of giving them an exhaustive list.

Every option they choose will have to be linked to a new question with only a few answers, so I can distill the issue they are having effectively and without them having to try 10 different things or answering 20 questions that have little to do with the issue and amount to nothing in the end (hello Windows troubleshooter).

I have made the framework in HTML which was easy enough but the biggest thing to do is store all the strings and connect them together in a somewhat clear way, like a diagram or something. Right now, I can only think of populating a DB with the sentences but the linkage will be chaotic as hell.

So, the only question I have is: Does anyone have an idea on how to do this in a better way, perhaps some kind of visual representation software?

I tried, as a test, to add the strings as objects in a json, which works well but the linkage already got super chaotic when I went above 50 strings ish, and I will be needing much more (thinking 1000 ish at least).

Thanks in advance for any input.

EDIT: Oh wow, lots of answers, thanks all! It seems like most answers are similar, and it looks like that is what I already have. Thanks for the suggestion on YAML, I will check it out.

I made a JSON structure initially without giving it too much thought, I wanted to focus on the framework first.

I guess I will need to input a lot of data anyway, so I'm not sure if I am just wasting your time and this is as good as it gets.

The thing is, many questions will lead to the same answers, so I'd like to inter link those. I have this working with the JSON structure now.

JSON with lots of objects like:

     "ID": "3.16",
     "Step":"Have you tried turning it off and on again?",
     "NextStep": ["3.17", "3.18"]

So, if step 3.16 is triggered it will show this text and if a person says yes to that, it will show step 3.17 and 3.18

This method of inter- and cross-linking works, but get's chaotic so I just wondered if there was a better way that I am missing.

I like the DX diagnosis suggestion as well, but this does not make the structure simpler it seems? But I will probably add that as the weights would be very good to have.

  • 6
    It doesn't seem like the size of the strings is the problem, but that you're looking for ways to elegantly describe decision trees, right? Could you perhaps show an example of your current JSON schema, and explain what specific problems it has?
    – amon
    Commented Feb 7, 2023 at 8:25
  • Thanks for the reply, I amended my original post with an answer as many answers I got are similar.
    – scidhuv
    Commented Feb 8, 2023 at 10:00
  • Also, yes that is what I need, especially inter-linking an answer to multiple follow up questions. I thought your answer needed a bit more attention but I added more info to the original post :)
    – scidhuv
    Commented Feb 8, 2023 at 10:37
  • 1
    It sounds as if you have a great deal of irreducible complexity here. No amount of structure nor format can fundamentally alter this fact; any issues about maintainability and being hard to reason over are only natural and inevitable from such complex requirements. The only thing which is realistically likely to help is automated testing; partly to protect the rules from future breaking changes, but mostly to enshrine all of that complex business knowledge about the use cases within the tests, (independently of the application logic or decision-making structures). Commented Feb 8, 2023 at 14:29
  • Agreed, I just felt it had to be easier. I guess I just underestimated human interaction, our subconscious is doing so much heavy lifting! Well it is a fun project anyway. Thanks for the insights!
    – scidhuv
    Commented Feb 9, 2023 at 16:04

3 Answers 3


Hi and welcome to the board :)

I'm not exactly sure if I understand your question correctly, so let me rephrase it in my own words:

I want to help customers to troubleshoot their problems on their own. To help them to get to the right answers, I'm creating a drill-down menu where each question leads to a more detailed question, until the system can provide a answer. Something like:

  1. Question: What is your Problem? Answer: I forgot my password
  2. Q: What system did you loose access to? A: My Computer (Windows Password)
  3. Q: Do you still remember your recovery token? A: No
  4. Action: Please call IT support: 01234-12345.

To keep it small and simple, I would suggest a very simple JSON-Structure. No linking, no magic. Something like:

//leading question: What is your Problem?
const data = 
  {answer: 'I forgot my password',
     question: 'What system did you loose access to?',
     answers: [
       {answer: 'My Computer (Windows Password)',
        next: {/*..*/}
       {answer: 'Google (Web password for google services)',
        next: {/*..*/}
  {answer: 'My computer does not work',  next: {/*..*/}},
  {answer: 'I have a problem with a specific program', next: {/*..*/}},

Even though you might have 1000ths of items in it, I guess it is still the simplest approach. I would suggest using a json schema to prevent errors.

  • Thank you! Yes, this is sort of what I have, I added the info to my original post with what my issue is.
    – scidhuv
    Commented Feb 8, 2023 at 10:06

Given that this appears to be immutable metadata that drives the flow of the application rather than user data, it seems like it'd need to be the same in all environments, therefore worth treating it as a static asset committed alongside the source code, rather than loading it into a database (which adds deployment complexity as well as losing any guarantee of consistent structures between your environments).

You could consider representing it in an simple object modelling format such as JSON or YAML, committed alongside the code where it'd likely be easier to include in your automated testing as well as ensuring local development remains consistent with all other environments:

    text: What is your name?
    - a1
    - a2
    - a3
    text: What is your quest?
    - a4
    text: King Arthur
    next_question: q2
    text: Galahad
    next_question: q2
    text: Robin
    next_question: q2
    text: Find the Holy Grail
    next_question: q3

A lot of configuration management tools use YAML for the human-readability of the format - particularly the support for comments.

  • 1
    I'd suggest a full programming like Javascript or TypeScript is better tha JSON or YAML. It can be just as readable, and allows the programmer to add comments, plus give the option to structure and test things however they want. With Typescript or another language with static types it's easy to make the compiler check that for instance every question has both question text and answers listed.
    – bdsl
    Commented Feb 7, 2023 at 14:56
  • 1
    @bdsl YAML supports comments, however I don't find static checking particularly useful for something that's essentially defining business logic since such checks can't verify whether the logic is correct; It'd be limited only to a technical check so can still be wrong. I'd prefer full unit test coverage so that there's an additional separate, independent sanity check to ensure the actual answers align with whatever's expected in the requirements. Commented Feb 7, 2023 at 19:12
  • Thanks for the replies, I amended my original post with an answer as many answers I got are similar.
    – scidhuv
    Commented Feb 8, 2023 at 10:00

There is a rich DX diagnosis literature which covers topics like fault equivalence and diagnosibility. We have a system-under-test that is stimulated by an input vector and is comprised of components. We observe various outputs. A bad output often means we cannot achieve the goal state.

For example, a vehicle might need fuel and working transmission components in order to achieve highway speed, or to even leave a parking space. The diagnostic tasks are to verify each of the preconditions. Or sending a payment might require a positive balance and proper credentials, where again we can verify each of them.

For the various high-level goals a troubleshooting system wishes to support, it can record

  1. components needed to support the goal
  2. diagnostic tests that verify component health

Clusters of related goals often rely on common components, so a tree or other graph datastructure is often appropriate for (1.). The tests can be a combination of automated observations (ping) requiring no interaction, plus Q / A responses elicited from the customer.

The simplest approach is to just "ask everything!", even questions irrelevant to the goal, and isolate the faulted component. That is excessive, so we impose a cost function to minimize effort & risk. For example we might run all automated probes initially, and then a few seconds later we have gathered some diagnostic information at almost zero cost. Then we are faced with asking a series of questions that reduce uncertainty, narrowing the field of potentially faulted components.

Some faults are more common that others. It is better to rule them out first. Some tests are cheaper than others, e.g. "read this screen" vs "reboot". So each question should be tagged with a few attributes: prevalence, and cost to perform the test. That lets a Planner navigate the graph to identify the next test, the next question, that in expectation will arrive at a successful diagnosis. A Decision Tree can encode these concerns in a static way. For components that interact in a complex manner, dynamic re-planning of the questions to ask can arrive at a diagnosis with lower cost.

  • This is very interesting and I think this approach can make the system better. I will read up on that. For now though, it seems like you are giving me more work! But I like it (the system, not the work!).
    – scidhuv
    Commented Feb 8, 2023 at 10:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.