Spiralist AI UI/UX Evaluation

Full report

On this page

Executive Summary: The Spiralist AI site offers a rich persona-creation toolkit, but we identified numerous UI/UX issues. Navigation and labeling are inconsistent, form controls lack proper accessibility attributes, and the visual design is crowded in places. For example, the header search bar is confusing and unlabeled, and form elements like the “Working style” toggles are plain text without checkboxes (see table below). We recommend mandatory changes: add semantic HTML/ARIA for all interactive elements (buttons, links, form fields), improve color contrast and focus indicators, clarify labels (e.g. “Generate Persona” instead of “Use it now”), and reorganize spacing for readability. Each fix below includes priority, effort, and UX impact, with links to WCAG/ARIA guidelines and performance metrics. We also supply a sitemap (Mermaid) and a UI component table comparing current vs recommended designs.

graph LR
  Home["Home"] --> Library["Personality Library"]
  Home --> Examples["Examples"]
  Home --> PersonaDay["Persona of the Day"]
  Home --> RemixGallery["Remix Gallery"]
  Home --> Compare["Compare Personas"]
  Home --> FindMatch["Find Your Match"]
  Home --> ImmersionLab["Immersion Lab"]
  Home --> WeeklyChallenge["Weekly Challenge"]
  Home --> About["About"]
  Home --> Privacy["Privacy"]
  Home --> DevDocs["Developer Documentation"]
  Home --> AgentAccess["AI Agent Access"]
  Home --> Terms["Terms & Usage Boundaries"]
  Library --> PersonaBuilder["AI Persona Builder"]
  Examples --> PersonaBuilder
  PersonaDay --> PersonaBuilder
  WeeklyChallenge --> PersonaBuilder
  FindMatch --> PersonaBuilder
  RemixGallery --> PersonaBuilder
  Compare --> PersonaBuilder

Figure: Site sitemap and navigation flows. All pages (Home, Library, Examples, etc.) link to the AI Persona Builder for creating or viewing personas.

Navigation & Information Architecture

• Menu & Header: The top “Navigate” menu and Skip to content link must be fully accessible. Use semantic elements (<header>, <nav>, <main>) or ARIA landmarks (e.g. role="banner", role="navigation"). Ensure the hamburger toggle has aria-controls/aria-expanded and a descriptive aria-label="Toggle navigation menu". The Skip to content link should be the first focusable element, and visible on focus. Priority: Critical; Effort: Small; Impact: High.

• Search Function: The header “Search site” box is confusing (it displays “Create a Persona” inside the field). The search input needs a proper <label> or aria-label="Search site", and a clear placeholder (e.g. “Search personas or guides”). Remove duplicate static text “Search” and fix the link that currently pre-fills “Create a Persona”. On the Library page, each filter (Name, Archetype, Domain, etc.) needs a visible <label> so the field purpose is programmatically determinable. Priority: High; Effort: Small; Impact: Medium.

• Breadcrumbs & Flow: Current breadcrumbs appear on subpages (e.g. “Home > Personality Library”), which is good. Ensure all multi-step actions (like the Quiz or Compare flows) have a clear flowchart/paths for users. For example, the Compare page should guide the user: the “First persona” and “Second persona” selectors need label and instructions (e.g. “Choose two personas to compare”). Without labels, screen readers cannot identify these fields. Priority: High; Effort: Medium; Impact: Medium.

Visual Design (Layout, Typography, Color, Spacing)

• Contrast & Readability: All text must meet WCAG contrast ratios (4.5:1 for normal text). Some UI text (e.g. the “0 / 160,000” counter and helper text) is light grey on white and may not meet this ratio. Adjust colors (e.g. use #333 or darker) or increase font weight. Ensure links, buttons, and labels stand out (primary CTA buttons should use a strong accent color). Likewise, “Use it now” and “Copy prompt” should be styled as buttons (e.g. background color, padding) rather than plain text links to make them easily discoverable. Priority: High; Effort: Small; Impact: High.

• Whitespace & Grouping: Some sections (like the persona example lists and “Focused mutation controls”) are very dense. Increase vertical spacing between grouped items and use headings or separators consistently. For instance, in the builder, group the “Working style” toggles with a fieldset and legend (“Working style (select up to 3)”). Similarly, align the “Goal – Preset – Seed” fields in the Immersion Lab into a clear form layout. This reduces cognitive load. Priority: Medium; Effort: Small; Impact: Medium.

• Icons & Imagery: The spiral logo (“motion mark”) adds flair, but ensure it’s marked decorative. Give its <img> an empty alt="" or ARIA hidden if it’s purely decorative. The “Pause motion” button toggles animation (good for vestibular safety), but add an aria-label="Pause animations" so screen readers understand its function. Priority: Low; Effort: Small; Impact: Low.

Interaction Design

• Buttons & Links: Use real <button> elements for all actions. E.g. “Use it now”, “Copy prompt”, “Apply settings”, “Reveal my match”, “Start the challenge” should be buttons with explicit labels, not styled text. If using non-button elements (e.g. <div> or <a>), add role="button" and keyboard handlers (Enter/Space). For example, change “Use it now” to <button> with text “Generate Persona”. This ensures proper focus and aria announcement. Priority: Critical; Effort: Small; Impact: High.

• Advanced Options Toggle: The ⚙ icon expands advanced fields. It needs aria-expanded (true/false) and aria-controls linking to the panel. When collapsed, advanced fields should be hidden (aria-hidden="true"), and aria-expanded="false" on the toggle. Update these attributes on click to follow ARIA disclosure pattern. Currently users may tab into the fields even when “Advanced” is closed. Priority: High; Effort: Medium; Impact: Medium.

• Form Controls:
• Job Role, Tone, Initiative: If these are multi-select or custom widgets, label each group with a <label> or <legend>.
• Working style: This is a “select up to 3” list of traits. Replace the plain text items with actual checkboxes (<input type="checkbox">) or at least <button role="checkbox" aria-checked="false">Warm</button> states. Ensure they toggle aria-checked and are keyboard-operable (space/enter toggles). For example:

    <button role="checkbox" aria-checked="false">Warm</button>

Priority: Critical; Effort: Medium; Impact: High (crucial for accessibility).

• Persona Examples & Actions: The persona library and examples pages list items like “Use this prompt” or “Open passport”. These actions should be clearly labeled. Currently “Use this prompt” might not convey that it will load the persona into the builder. Consider rephrasing to “Use persona” or adding an icon. Also ensure links open correctly (and add target="_blank" rel="noopener" if they open new tabs). For icon-only controls (if any), add aria-labels (e.g. the ↗ symbol should have aria-hidden="true" but the link text “Open ChatGPT” is visible which is good). Priority: Medium; Effort: Small; Impact: Medium.

• Error States & Feedback: Implement form validation feedback. For example, if the user tries to “Build Persona” with an empty prompt, show an inline error message (“Please enter a description or generate a random persona”). Use aria-live="polite" for such messages so screen readers announce them. Currently there is no visible feedback on invalid input. Priority: High; Effort: Medium; Impact: High (prevents confusion).

Onboarding & First-time Flows

• Quick Tour/Help: The “Optional quick tour” pop-ups and the “Examples Quick tour [?]” link are helpful, but need controls. Add a visible “Close” button on the tour modals (with aria-label “Close tour”) and ensure keyboard users can exit (e.g. Escape key should dismiss). Also ensure focus moves into the tour when opened, and returns appropriately when closed. The help (“?”) currently anchors to the How-It-Works page; consider an inline tooltip or modal summary for faster assistance. Priority: Medium; Effort: Medium; Impact: Medium.

• First-time Guidance: The homepage steps (1,2,3) and “Why this is different” sections are informative. Ensure the “Skip” and “Next” buttons are real buttons with clear labels. E.g. use aria-current on the current step or highlight it. This clarifies progress. Priority: Low; Effort: Small; Impact: Low.

Core Task Flows

• Persona Creation Flow: The primary user journey is to enter a prompt, click “Build” (or “Use it now” for random), then copy/open. Ensure the steps are intuitive: after “Build”, focus should move to the “Copy prompt” button (so users can easily copy/launch). Label the build button clearly (e.g. “Generate Persona”). The builder then shows the Persona Passport. Label sections (e.g. “Persona Name”, “Traits”, “Example Response”) with headings. Priority: High; Effort: Medium; Impact: High.

• Persona Passport & Sharing: The Passport page (after build) has many fields and tables. Each group (“Interaction preview”, “Mutation controls”, etc.) should have <h3> headings as currently shown. Ensure those are logical (Heading order was correct per our find results). All copy/share/export actions are buttons; e.g. “Copy Full Prompt” etc., which is good. Add aria-live feedback when copying occurs (e.g. “Prompt copied to clipboard”). Priority: Medium; Effort: Small; Impact: Medium.

• Task Completion: After copying, ensure there’s feedback like a checkmark or message “Prompt copied!” to confirm action. Similarly for downloads and shares. Priority: Medium; Effort: Small; Impact: Medium.

Advanced Features Discoverability

• Hidden Panels: Features like “Advanced options”, “Full Persona Workshop”, and “Advanced export” are behind toggles. Make these toggles obvious (the down arrow icon should rotate and indicate open/closed state via aria-expanded). Label them: e.g. the gear ⚙ could have a tooltip “Advanced settings”. Ensure all hidden menus can be opened via keyboard (Enter/Space). Priority: High; Effort: Small; Impact: High.

• Developer Docs: The link “Developer Documentation” points to extensive spec content. Consider summarizing key developer features or linking contextually (e.g. “Learn about .uai format”). Right now it’s only in “Resources”. Priority: Low; Effort: Small; Impact: Low.

Responsiveness & Viewports

• Mobile Layout: Ensure the site is responsive. The navigation should collapse into a hamburger menu on small screens, with clear touch targets (44×44px minimum). Form elements and buttons should stack vertically rather than squish horizontally. For example, the “Working style” toggles wrap poorly on narrow viewports. Use media queries to adjust font size/spacing on small screens. Priority: High; Effort: Medium; Impact: High (mobile-friendliness is crucial).

• Viewport Testing: Test on various devices. Check the Immersion Lab sliders and the builder’s wide tables (mutation controls, scenario table) for horizontal scrolling or overflow on mobile. If items shrink too small, switch to a vertical layout or accordion on small screens. Priority: High; Effort: Medium; Impact: High.

Performance & Perceived Speed

• Loading & Interactivity: The app is rich (thousands of personas, dynamic UI). Use Chrome Lighthouse to measure performance (FCP, LCP, TTI, CLS, etc.). As Google details, Largest Contentful Paint and Total Blocking Time are heavily weighted in Lighthouse. Aim for LCP < 2s and low JavaScript blocking. For example, defer non-critical JS, minify scripts, and use code-splitting if possible. Avoid large bundles; prioritize async loading of the persona library or developer docs. Priority: Medium; Effort: Large; Impact: High (improves loading speed).

• Perceived Speed: Show immediate feedback on actions. For instance, after clicking “Build”, display a loading spinner or skeleton (“Generating persona…”) so users know progress. Use CSS will-change or offscreen techniques to keep animations smooth. For example, the swirling logo is subtle, but heavy JS could drop frames; offer a “reduced motion” mode already in place. Priority: Medium; Effort: Medium; Impact: Medium.

• Performance Metrics: Track metrics like “Time to First Byte”, “Time to Interactive”, “LCP”. Tools: Lighthouse, WebPageTest. Use web-vitals (LCP, FID, CLS) monitoring. Priority: Medium; Effort: Medium; Impact: Medium.

Accessibility (WCAG 2.1 AA)

• Contrast & Color: Per WCAG 1.4.3, all text must have ≥4.5:1 contrast. Review every UI color (backgrounds, text, icons). For example, buttons should use distinct colors (not only gray-on-white). Avoid conveying meaning by color alone; if statuses use color (e.g. “Active” vs “Idle”), also include text or icons (WCAG 1.4.1).

• Keyboard Navigation: All functionality must be keyboard-operable. Tab order should follow visual order. Ensure no keyboard traps: the menu, dialogs, and any modal (like the quick tour) must allow closing via Esc or a close button. Use :focus styles (default outline or custom) so focus is always visible.

• Form Labels & Instructions: Every input and control needs a label. Use <label for="..."> or aria-label. For search inputs and filters, explicitly associate the label with the field so screen readers announce it. Provide instructions (e.g. “select up to 3 traits”) as visually visible text or aria-describedby.

• ARIA Roles and Names: Use proper roles. The header should have role="banner", navigation role="navigation", footer role="contentinfo". All buttons/links should have accessible names (the visible text is usually enough). For any custom widget (like the “Working style” toggles), use WAI-ARIA patterns (e.g. role="checkbox", aria-checked; or a <ul role="group"><li role="checkbox">…</li></ul>). Icons without text need aria-hidden="true" if decorative, otherwise an aria-label.

• Focus Visible: The site already has skip-links, but ensure every button/link has a clear focus ring. WCAG 2.4.7 requires a visible indicator when focused. For example, the “Create a Persona” header button should show outline on focus. If disabled, use disabled attribute or aria-disabled.

• Assistive Text: For actions like copying to clipboard, use aria-live="polite" to announce “Prompt copied!” as feedback. Similarly, error messages should be announced.

• Accessibility Testing: Run WAVE or Axe on each page. Typical issues to fix: missing form labels, empty links, low-contrast icons. For example, if any <img> lacks alt, fix it. Screen reader test the Persona builder: make sure each section (Passport, Mutation controls, etc.) is navigable and labeled.

Microcopy & Tone

• The tone is helpful and concise. Maintain clarity: avoid jargon where possible. For instance, change ambiguous UI text like “Use it now” to “Generate Random Persona” (clearer call-to-action). The term “Persona Passport” is fine but ensure new users understand it (the How-It-Works page explains it well).

• Button Labels: As noted, “Use this prompt” is vague; better to say “Load persona”. Likewise “Build this persona” (in Weekly Challenge) is okay, but the main create page’s “Build Persona Passport” could just say “Generate Persona”. Consistency matters: use the same verb (“Generate” or “Build”) throughout.

• Help Text: Wherever placeholder text or helper text is used (e.g. below search, in inputs), ensure it’s specific. E.g. placeholder “Describe your task…” in the prompt field (currently empty) could invite an example. The footer copy “Your persona stays in your browser…” is great for privacy reassurance – preserve such microcopy.

• Error/Tooltip Text: If hovering over icons or disabled buttons, provide a tooltip or aria-description. E.g. if “Remix” is disabled until a persona is loaded, a title “Load a persona first” would help.

Security & Privacy Cues

• Local-First Messaging: Spiralist clearly states it is local-only (no account needed). Emphasize this trust signal in the UI: perhaps a small lock icon next to “No account required” or a tooltip “All data stays on your device”. For example, the Privacy page says “the active creator state is in browser memory. Spiralist AI does not submit persona fields to a server.”. Display a short summary of this on the main page.

• HTTPS: Ensure all pages are served over HTTPS. Most modern browsers show a padlock; if not, configure SSL.

• Opt-in Analytics: Spiralist already requires explicit opt-in for analytics. Make this clear: the footer toggle “Allow anonymous counts” should be a switch control (with aria-checked) and perhaps an info icon linking to “Details” (already present). Confirm that no sensitive data is collected.

• Content Safety: The Terms page warns users to review personas. Consider a brief note or icon when exporting/sharing that reminds users, e.g. “Review content before sharing (see Terms)” with a link to the Terms page.

Analytics & A/B Testing

• Metrics to Track: Instrument key events: persona generation, prompt copying, provider-launch clicks, persona shares, and filter usage. Track funnel conversions: how many users reach (1) build, (2) copy, (3) launch. Use Google Analytics or a privacy-friendly alternative. Measure page load times (LCP, TTI) via real-user metrics. As Nielsen notes, track conversion rate, click-through rate, bounce rate, and retention rate. For example, measure what percentage of users who land on Home actually click “Build persona”.

• Post-Implementation A/B Tests: Test variations of UI elements. For instance, A/B test different CTA texts (“Generate Persona” vs. “Use it now”) or colors of the primary button (per NN/g guidelines). Test the ordering of advanced options (e.g. if “Working style” is hidden by default vs. always visible), measuring if usage of advanced features increases. Another idea: A/B test showing the quick-tour overlay on first visit vs. not showing it, then compare task success. Always define metrics (e.g. completion time, repeat usage) and use NN/g’s recommended practice of testing one change at a time.

UI Component Comparison

Table: Current vs. recommended UI components (must-change items in bold).

Image Example

Figure: Spiralist AI’s animated logo (spiral vortex). Ensure decorative images like this are marked aria-hidden="true" or have empty alt, and provide a “Pause animation” control with proper aria-label for motion sensitivity.

Conclusion

The Spiralist AI interface is feature-rich but needs targeted UI/UX fixes to meet WCAG standards and user expectations. By applying the above changes – improving labels, contrast, keyboard support, and clarity – the site will be more usable and accessible. After implementation, track performance (Lighthouse scores for FCP/LCP, conversion funnels, feature usage) and run A/B tests on CTAs and flows as described. Together these improvements will ensure Spiralist AI delivers a polished, user-friendly experience.

Sources: Spiralist AI pages and documentation were reviewed, along with W3C WCAG 2.1 guidelines, WAI-ARIA best practices, and Nielsen Norman Group (A/B testing metrics). These guided the accessibility and performance recommendations.