Skip to main content

UI/UX Feedback & Improvement Suggestions

Consolidated UI/UX observations and actionable improvement suggestions for the ClinicalDataS platform, based on workflow review across all major modules.

Last updated: 04/14/2026

Purpose: This document captures UX observations and improvement suggestions from a full review of the ClinicalDataS platform workflows. Intended audience: product team, engineering, and UX designers.

1. Navigation & Global Shell​

1.1 Dual-mode navigation is confusing (Design vs Production)​

Observation: The top bar shows Design and Production toggles with no visual explanation of what switching between them does. New users are not sure whether edits in Design mode are immediately visible in Production.

Suggestion:

  • Add a persistent tooltip or banner when in Design mode: "You are editing in Design mode. Changes will not affect live study data."
  • Color-code the header differently in Design vs Production (e.g., amber header for Design, blue for Production).

1.2 Study context is not always clear​

Observation: The breadcrumb shows Home / CARDIO-RELIEF 2025 / [Page] but there is no persistent indicator of the study status (Design / Available / Frozen) on every page.

Suggestion:

  • Display the study status badge (already shown on the study home page) persistently in the breadcrumb or top bar when inside a study context.

1.3 App navigation sidebar shows too many items with no grouping​

Observation: The left sidebar inside a study lists all installed apps alphabetically with no grouping or categorization (IMP, Medical Coding, Mobile, Monitoring Visit Report, Pre-Screening and eConsent, Queries, Randomization, SDV, Signature, Survey). With 13 apps, the list is long and hard to scan.

Suggestion:

  • Group apps by function: Data Collection (Form Builder, Survey, Pre-Screening), Clinical Operations (Queries, SDV, Monitoring), Supply & Randomization (IMP, Randomization), Compliance (e-Signature, Rule Studio), Reporting (Medical Coding).
  • Allow users to pin or reorder frequently used apps.
  • Add a search/filter field at the top of the app sidebar for large studies.

1.4 No "Go to Study" shortcut for operational workspace​

Observation: The study home page has a "Go to Study" button that opens the operational workspace (data entry/subject tracking), but no persistent quick-link exists inside the app sidebar or breadcrumb. Users navigating from an app back to the subject list have to go through the study home.

Suggestion:

  • Add a fixed "Study Workspace" link at the top of the sidebar when inside any app configuration page.

2. Study Setup​

2.1 "Build Your Study" 6-step guide is not linked from steps themselves​

Observation: The study home shows a 6-step guide (Manage CRFs → Events → Group Classes → Rules → Sites → Users), but clicking any step link takes you to the relevant setup page without any indication of where you are in the 6-step flow or a Next Step button.

Suggestion:

  • Add a progress indicator or wizard-style navigation (Step 1 of 6) when completing study setup steps.
  • Provide a "Back to Study Setup Checklist" link at the top of each setup step.

2.2 Study status change requires manual action with no checklist guard​

Observation: A study can be moved from Design to Available without any checklist validation (e.g., no check that at least 1 CRF exists, 1 site is assigned, 1 user is added). This can lead to studies going live incomplete.

Suggestion:

  • Implement a pre-flight checklist shown before status change: a list of required items that must be completed before the study can move to Available.
  • At minimum: at least 1 CRF, at least 1 site, at least 1 assigned user.

3. Apps — Configuration Pages​

3.1 Configuration pages have inconsistent layouts​

Observation: Some apps use section headers with inline Edit buttons for each section (Pre-Screening, eConsent), while others show inline editable tables (Queries), and others have a single form with a Save button at the bottom (System Settings). This inconsistency makes it harder to learn the platform.

Suggestion:

  • Standardize configuration page layout across all apps: use section cards with Edit/Save per section, or use a single-page form with one Save button — pick one pattern and apply it consistently.

3.2 "Save settings" / "Discard changes" are only at the bottom — easy to miss​

Observation: On long configuration pages (e.g., Screening Settings), the Save and Discard buttons are fixed at the bottom. Users who scroll through several sections without saving may lose work if they navigate away.

Suggestion:

  • Add a sticky footer or floating action bar that remains visible at the bottom of the viewport as users scroll.
  • Alternatively, add an unsaved changes warning dialog when navigating away.

3.3 Queries Configuration: section titles are too long and technical​

Observation: Section headers read: "Define list of common description when updating a query with type is 'Query'". This is verbose, grammatically awkward, and mixes concepts.

Suggestion:

  • Rename to cleaner labels:
    • "Reply Descriptions" (instead of "Define list… updating a query")
    • "Close Reasons" (instead of "Define list… closing a query")
    • "Reason for Change Reasons" → "Reason for Change Templates"
  • Add a one-line description below each heading explaining when it is used.

3.4 Empty tables show "No data" with no actionable prompt​

Observation: Tables with no rows show "No data" as plain text. Users (especially new ones) may not notice the + Add button or know what to do next.

Suggestion:

  • Replace plain "No data" with an empty state component: an icon, a short label ("No descriptions added yet"), and a prominent + Add button centered in the empty table area.

3.5 IMP Configuration URL /apps/queries incorrectly redirects to IMP​

Observation: Navigating to /apps/queries (by app name in URL) redirected to the IMP module. The Queries app URL is /apps/query (without the 's'). This inconsistency between URL slug and display name is confusing.

Suggestion:

  • Standardize app URL slugs to match display names exactly, or implement URL aliases so /apps/queries and /apps/query both work.

4. e-Consent / Pre-Screening​

Observation: The Add Consent Form dialog has 7+ sections (General Info, Content, Questions, Agreement, Participant Signature, LAR, Team Member). The rich-text editor for "Content of Consent" can be very long. The dialog does not show section progress and there is no way to save a partial draft within the dialog itself.

Suggestion:

  • Split the dialog into a multi-step wizard (Step 1: General Info, Step 2: Content, Step 3: Signature settings) with a progress bar and Back / Next / Submit buttons.
  • Or add section anchors / jump navigation within the dialog so users can skip to the section they need.
  • Auto-save the draft every few minutes while the dialog is open.

Observation: The Consent forms table shows status as plain text (Draft, Published, Archived). This makes it hard to scan quickly, especially with multiple forms.

Suggestion:

  • Add status badges with colors: Draft = amber, Published = green, Archived = gray.

4.3 Auto Invite section description is very long and hard to parse​

Observation: The Auto invite section header contains the full explanation in small gray text spanning 3 lines. This important information is easy to miss and the link to the prerequisite (Email field in Screening Settings) is not visible.

Suggestion:

  • Move the long description into a collapsible info panel or a :::note admonition style (as already used in the help docs).
  • Add a direct link to Screening Settings next to the prerequisite note.

5. Queries Workspace (Operational View)​

5.1 Summary panel and table are not visually linked​

Observation: The Summary Queries panel at the top shows counts by type/status. Clicking a number in the summary panel does not filter the table below — users have to manually apply filters. This breaks the expected "drill-down" interaction.

Suggestion:

  • Make each number in the Summary panel a clickable filter that automatically filters the table to that type/status combination.

5.2 "View within record" opens a new tab but doesn't highlight the field​

Observation: Clicking "View within record" opens the CRF in a new browser tab, but the specific data item that triggered the query is not highlighted or scrolled to. Users must hunt for the field themselves.

Suggestion:

  • Deep-link directly to the specific field within the CRF and use a visual highlight (e.g., amber border or scroll-to animation) to draw attention to the relevant item.

5.3 No bulk actions on query list​

Observation: Users can only act on queries one at a time. For large studies with hundreds of open queries, there is no way to bulk-close, bulk-assign, or bulk-export.

Suggestion:

  • Add row checkboxes to the query list.
  • Add a Bulk Actions toolbar: Assign To, Close Selected, Export Selected.

6. System Settings​

6.1 "Submit" button label on System Configuration is ambiguous​

Observation: The System Configuration page uses a Submit button. In the context of a settings form, "Submit" feels like a one-time action (like submitting a form to a server). Other pages use "Save settings" which is more appropriate.

Suggestion:

  • Rename to Save settings (or Save changes) for consistency with other configuration pages.

6.2 Logo upload has no preview before save​

Observation: The Logo upload section shows a broken image placeholder before a file is uploaded and no preview after selecting a file. Users cannot see how the logo will appear before committing.

Suggestion:

  • Show a live preview of the uploaded logo (resized to fit the expected dimensions) immediately after file selection, before saving.

7. General / Cross-Cutting​

7.1 No in-app help or contextual tooltips​

Observation: Configuration fields (especially in Screening Settings and e-Consent) have no tooltip or ? icon explaining the field. Users must refer to external documentation.

Suggestion:

  • Add a ? icon next to each field label that shows a tooltip or popover with a one-sentence explanation.
  • For complex fields (e.g., Screening Code Format options), link to the relevant help center article.

7.2 No notification/audit trail for configuration changes​

Observation: When a study administrator changes a configuration setting, there is no record of who changed what and when. This is important for regulatory compliance (21 CFR Part 11 / GCP).

Suggestion:

  • Add a Configuration Audit Log per study that records: field changed, old value, new value, changed by, timestamp.
  • Surface this log in the System Settings → Audit section (separate from Login audit).

7.3 Date/time formats are not consistently applied​

Observation: Some dates appear as 04/14/2026, others as 2026-04-14, depending on the page. The System Settings allows configuring the date format, but it is not consistently applied across all modules.

Suggestion:

  • Enforce the System Settings date format globally across all date display fields in all modules.

7.4 Roles & Permissions are not surfaced at the module level​

Observation: Users see all apps in the sidebar regardless of their role. For example, a CRC user should not see configuration-only modules (Rule Studio, IMP configuration) prominently.

Suggestion:

  • Apply role-based visibility to the sidebar: only show apps the logged-in user has access to.
  • Show a grayed-out entry (with a lock icon) for apps the user can see but not access, to prevent confusion.

7.5 Mobile responsiveness is inconsistent​

Observation: The platform is generally designed for desktop use, but the CDS Mobile App exists for participants. The configuration and operational views are not usable on mobile-sized viewports.

Suggestion:

  • Define a clear device strategy: which modules are expected to be mobile-accessible?
  • At minimum, ensure the participant-facing eConsent review and signing experience is fully responsive.

8. Pre-Screening & eConsent Workflow​

8.1 eConsent form must be Published before it appears in the Invite dialog​

Observation: When a coordinator clicks Invite on a participant record, the Document dropdown only lists Published consent forms. Forms in Draft status are silently excluded. There is no warning, error, or hint to explain the empty dropdown.

Suggestion:

  • If no Published forms exist, show an inline message: "No published consent forms found. Publish a form in e-Consent Settings first."
  • Add a direct link to the e-Consent Settings page from within the Invite dialog.

8.2 Study mode toggle (Design / Available) disrupts active workflows​

Observation: The study must be switched to Available before operational workflows (screening, enrollment) become active. Switching back to Design to change configuration then back to Available creates a disruptive cycle. There is no inline guidance explaining this requirement.

Suggestion:

  • Surface a persistent status banner when the study is in Design mode: "This study is in Design mode. Switch to Available to activate participant workflows."
  • Allow limited configuration changes (e.g., publishing a consent form) in Available mode without requiring a full mode switch.

8.3 "Send invitation: Yes" toggle is disabled without explanation​

Observation: In the consent invitation dialog, the Send invitation toggle is disabled by default and becomes enabled only after a Document is selected. No tooltip or label explains why it is disabled before a document is chosen.

Suggestion:

  • Add a tooltip on the disabled toggle: "Select a consent form document first."
  • Alternatively, make the toggle state reactive with an inline label update that explains the dependency.

Observation: The date field in the consent form signing page uses an Ant Design DatePicker, but its parent containers have overflow: hidden set, which clips and hides the calendar popup when triggered. The participant cannot select a date by clicking the calendar.

Suggestion:

  • Render the calendar popup at the document root level (via getPopupContainer={() => document.body}) to escape the overflow constraint.
  • This is a standard Ant Design prop (getCalendarContainer / getPopupContainer) and requires a one-line fix.

Observation: The consent form signing page has no visible Submit or Confirm button rendered in the DOM. The form only processes when formInstance.submit() is called programmatically. Participants who complete the signature fields have no clear call-to-action to finalize their consent.

Suggestion:

  • Add a visible, labeled Submit consent or Complete signing button at the bottom of the form.
  • Disable it until all required fields (Date, Full Name, Signature) are filled, and show a progress indicator (e.g., "2 of 3 fields complete").

8.6 Treatment Arm field in enrollment dialog has no default or guidance​

Observation: The Add Subject enrollment dialog requires selecting a Treatment Arm, but the dropdown starts empty with no default selection or hint about which arm is appropriate. In blinded studies, this field reveals allocation — there should be guidance on who should see this.

Suggestion:

  • Add placeholder text or tooltip: "Select the randomized treatment arm for this participant."
  • For blinded studies, consider whether this field should be pre-populated from the randomization module, removing the manual selection step.

Observation: The consent form submission API (POST /api/rest/v3/screenings/{id}/consentFormSetting/) rejects dates serialized as raw Ant Design / dayjs internal objects ({ $isDayjsObject: true, $y: 2026, ... }). The server returns a generic 500 error with the message "Something went wrong. Please contact admin." There is no indication that the date field is the cause.

Suggestion:

  • Normalize date field values to ISO 8601 strings (.toISOString()) before sending to the API.
  • Return a specific validation error (422 Unprocessable Entity) from the API when a date field is malformed, with a user-readable message.
  • Add client-side date serialization validation before form submission.

Last reviewed: April 2026. Based on: CARDIO-RELIEF 2025 study on test-2025.clinicaldatas.net.

FeedbackUXImprovement
In this article