I’m a former medical student from Italy, currently transitioning into Data Science and Bioinformatics. During my clinical rotations, I noticed a huge issue: medical software often looks like a chaotic 1990s database, causing severe cognitive overload for doctors.
To solve this, I built NeuroDiag-AI, a proof-of-concept probabilistic diagnostic tool for psychiatric and neurological preliminary stratification.
Dynamic st.session_state (“Onion Triage”): I wanted to mimic a real doctor’s progressive interview. The forms are deeply nested. Broad screening questions appear first; specific clinical follow-up questions (like HAM-D or UPDRS criteria) only render if the user toggles a positive response. This keeps the UI incredibly clean.
Theming & UI: Used custom medical-grade color coding and progress bars to guide the user naturally without overwhelming them.
Visual Outputs: Integrated Radar Charts to visually explain the AI’s probabilistic output.
(Note: The underlying model is trained on 10,000 synthetic patients generated with strict clinical rules to ensure zero privacy/GDPR issues).
My Ask: I’d love your feedback on the UI/UX! Specifically, how do you usually handle complex, multi-level nested forms using session_state without making the code too messy? Any tips on optimizing my approach?
This is a thoughtful build. The “onion triage” idea makes a lot of sense for clinical workflows because it mirrors how a real interview narrows rather than overwhelming the user all at once. A lot of healthcare software still behaves like a database with a pulse, so it’s nice to see someone treating cognitive load as a design problem instead of just a technical one.
I work in healthcare UX/human factors, so this is very much my area. I’d be interested in what you learned about where nested logic starts to break down for users and how you decided when to branch versus when to keep context visible.
Thanks for sharing the app and great app overall! I tested the app and here are my thoughts.
Upon loading the app, I noticed that the background color may not have been set. It seems that you may have designed the app for a light theme. By default, the loads by using the “system” theme (my computer is in dark mode so the app is displayed using the dark theme). As a result, I see the white spacer box and some of the text in buttons/input box widgets are not visible as it is text are the same color as the widget (see attached screenshot).
I like the progress bar that updates as the user progresses through the survey. Perhaps having an accompanying text that explicitly tells the user how far they are in the survey like 5/50 may be helpful.
For each of the question, sometimes they are occupying 2 lines and sometimes 1 line. As a result the vertical location of the 3 answer buttons would shift up and down, which may require moving the cursor up and down to press the buttons. Perhaps, the number of lines that the questions are displayed on could be fixed to the same value like 2 lines for all questions. As a result, the buttons would not move with each progressing questions.
Your definition of EMRs as a “database with a pulse” is incredibly accurate—and brutally honest. That’s exactly the pain point I wanted to address. Coming from a clinical background, I know firsthand that doctors don’t think in SQL tables; they think in decision trees.
To answer your great questions regarding the UX:
1. Where nested logic breaks down: I found that the “Inception effect” starts after 2, maximum 3 levels of depth. If a doctor has to click through >3 nested toggles, they lose the “clinical big picture” of the patient. The cognitive load shifts from evaluating the patient to navigating the software. To prevent this, if a specific condition requires a very deep dive (e.g., a full UPDRS evaluation for Parkinson’s), I avoid nesting it further. Instead, I trigger a completely separate, focused module or modal, signaling a shift in context.
2. Branching vs. Visible Context: My rule of thumb is based on the traditional medical triage. “Red flags”, chief complaints, and core systemic parameters must always remain visible on the main screen (the context). I only branch (hide behind a toggle) the specialized, secondary criteria (like specific psychiatric scales such as HAM-D) that are useless noise for 80% of the patients but vital for the remaining 20%.
Since Healthcare UX is your specific domain, your feedback is incredibly validating for me. I’m currently transitioning from medicine to clinical data science, and I’d love to connect on LinkedIn to follow your work and insights, if you are open to it!
Hi there, thank you so much for taking the time to thoroughly test the app and for this incredibly constructive feedback!
You hit the nail on the head with all three points:
The Dark Mode bug: You are completely right. I developed and tested it on a Light theme and forgot that Streamlit defaults to the system theme. I’m adding the config.toml right now to force the Light theme and fix the widget visibility.
Progress Text: Excellent point. A visual bar is good, but explicit numbers (e.g., 5/50) reduce uncertainty. I will add that metric.
The “Button Jumping”: This is a brilliant UX observation. I hadn’t noticed the vertical shift, but you are absolutely right: it breaks the flow for rapid data entry by forcing the user to reposition the cursor. I will fix the container height so the answer buttons remain perfectly anchored in the exact same spot across all questions.
I really appreciate you catching these UX friction points. It’s exactly the kind of feedback I was hoping for. Thanks again!
