FireAndStorm Portal UI UX Improvement Report

Full report

On this page

Executive Summary

This review covers the public FireAndStorm portal estate on fireandstorm.com while intentionally excluding the homepage from recommendation scope. Based on the crawl, the public estate includes six authentication or access-request routes, three role-based demo dashboards, three role-specific claim-detail demos, two legal pages, one demo selector, two legacy technical demo paths that now point back to the selector, and one generic /demo/claims/ fallback route. The production experience that exists _after_ authentication was not publicly accessible; the only post-login-like experiences available to evaluate were the public demo dashboards and claim-detail previews. The www host also canonicalizes to the apex host on the publicly opened routes.

The portal architecture has several strong foundations. Role separation is clear. Each role gets a dedicated summary of purpose. Demo workspaces display concrete “next actions,” status summaries, and role-specific tool sets such as Upload photos / Schedule visit / View estimate for owners, Upload evidence / Submit invoice / Onboarding for contractors, and Review estimate / Request info for adjusters. Forms consistently warn against entering highly sensitive information in public pages, and the demo data is clearly described as redacted and read-only. All of that is directionally good for trust, task clarity, and least-privilege presentation.

The most important UX problems are structural rather than aesthetic. Every public login and registration page includes the full portal chooser below the core form, which dilutes the task and creates unnecessary page length. The login pages also contain a severe microcopy contradiction: they ask for a password but simultaneously say “Do not enter … passwords” in the page instructions. The action strips and tab rows appear dense and linearly packed, especially on demo pages, creating likely mobile and accessibility strain. CTA language is inconsistent across roles: Request Access, Sign Up, Registration, and Access goal do not form one coherent vocabulary. The legal pages are too thin to inspire confidence for a portal that is clearly framed as dealing with restoration-claim workflows.

The most important SEO and best-practice issue is that public demo dashboards, legacy technical demo paths, and even role-specific claim-detail demo pages with query parameters are discoverable in search. Google’s documentation is explicit that route-level indexing should be controlled with noindex via a robots meta tag or HTTP header when pages should not appear in search results. For this portal, public demo and access flows should almost certainly be treated as non-indexable utility routes, while only the true public marketing site should be indexed.

From a heuristic and accessibility perspective, the estate is currently closer to a promising, lightweight MVP than a polished multi-role portal system. The strongest immediate improvements are to separate auth pages from chooser pages, standardize role language and CTA wording, apply semantic tab/dialog implementations, tighten mobile hierarchy, noindex all login/register/demo/legacy routes, and add clearer status language plus help expectations. If those fixes are made first, the portal can keep its existing role clarity while becoming materially more trustworthy, more accessible, and more conversion-efficient.

Scope, Crawl Inventory, and Page Snapshots

The crawl below is based on publicly reachable routes discovered through the portal chooser, indexed route discovery, and public demo navigation. The homepage was used only as a discovery source and is not included in recommendations. Because live HTML screenshot capture was not available from this environment, the inventory uses rendered-page snapshots and semantic DOM reconstructions derived from the rendered page output. Public production pages beyond login/access-request were not accessible; the public demo routes were the only role-specific workspaces available for review.

Authentication and legal routes

Demo selector and role dashboards

Claim-detail and fallback routes

Two inventory findings are strategically important. First, the portal uses a very shallow IA, which is good for comprehension. Second, because the public site exposes not only chooser pages but also role dashboards, claim-detail demos, and legacy technical routes in search discovery, the portal’s “public utility” versus “customer-ready public content” boundary is currently too porous.

Information Architecture and Key User Flows

At the highest level, FireAndStorm currently has three public conceptual layers: a portal chooser, a set of role-specific access pages, and a public demo workspace that acts as the only publicly visible stand-in for the real authenticated portals. That is a workable foundation, but the line between “live portal access” and “demo preview” is not strong enough. The auth forms still visually contain the chooser, and the legacy technical demo paths remain publicly reachable, which weakens certainty about where a user “really is” in the product.

flowchart TD
    A[Portal chooser] --> B[Property Owner Login]
    A --> C[Property Owner Access Request]
    A --> D[Contractor Login]
    A --> E[Contractor Registration]
    A --> F[Adjuster Login]
    A --> G[Adjuster Registration]
    A --> H[Demo role selector]

    H --> I[Owner demo dashboard]
    H --> J[Contractor demo dashboard]
    H --> K[Adjuster demo dashboard]

    I --> L[Owner claim detail demo]
    J --> M[Contractor claim detail demo]
    K --> N[Adjuster claim detail demo]

    A --> O[Privacy]
    A --> P[Terms]

    Q[Legacy demo routes] --> H
    R[Generic demo claims fallback] --> A

This IA diagram is derived from the publicly crawled routes and demo navigation paths.

The role logic itself is good. Owners are guided toward status, uploads, visits, estimates, and payment visibility. Contractors are guided toward assignments, evidence, onboarding, and invoicing. Adjusters are guided toward evidence review, estimate review, and request-for-information handling. That is a sound role model and aligns well with Jakob Nielsen’s heuristic that systems should match the real world and users’ tasks. The problem is less the flow model and more the presentation density, language inconsistency, and search exposure around those flows.

flowchart LR
    A[Owner access request] --> B[Owner login]
    B --> C[Owner dashboard]
    C --> D[Open claim]
    D --> E[Upload photos or receipts]
    D --> F[Schedule visit]
    D --> G[View estimate and payment status]

    H[Contractor registration] --> I[Contractor login]
    I --> J[Contractor dashboard]
    J --> K[Open claim]
    K --> L[Confirm onboarding]
    K --> M[Upload evidence]
    K --> N[Submit invoice]

    O[Adjuster registration] --> P[Adjuster login]
    P --> Q[Adjuster dashboard]
    Q --> R[Open claim]
    R --> S[Review evidence]
    R --> T[Review estimate]
    R --> U[Request information]

These are the top public flows visible in the crawl.

Cross-Portal UX and Accessibility Evaluation

The site performs best where it is role-specific and weakest where it is trying to be both a portal chooser, a live access path, and a demo catalogue at the same time. Below is a full heuristic pass using Nielsen’s ten heuristics, followed by mobile-specific checks and a WCAG 2.1 AA audit lens. NN/g defines heuristic evaluation as judging an interface against established usability principles, and that framing fits this portal well because most of the biggest issues are discoverable without analytics.

Mobile UX needs a separate lens because smartphone use brings smaller screens, shorter sessions, and more frequent interruption. NN/g explicitly notes those constraints, and mobile-specific heuristic work likewise argues that desktop-focused heuristics miss mobile problems.

The WCAG 2.1 AA audit below distinguishes between confirmed issues visible in the crawl and high-risk issues that need live browser verification with keyboard, screen reader, Axe, and WAVE. W3C’s WCAG documentation, Deque’s axe rules, and WebAIM’s WAVE guidance all emphasize that manual checks are still required.

The three most important accessibility and form code fixes are below. They are aligned with W3C, MDN, and WAI guidance on instructions, autocomplete, tabs, and dialogs.

<!-- Auth form: clear instructions, correct autocomplete, explicit error region -->
<form id="owner-login" novalidate aria-describedby="login-help login-errors">
  <h1>Property Owner Login</h1>

  <p id="login-help">
    Use the email address and password for your FireAndStorm portal account.
    Do not enter claim numbers, policy numbers, SSNs, tax IDs, bank details,
    API keys, tokens, or unrelated financial details on this public form.
  </p>

  <label for="email">Email address</label>
  <input
    id="email"
    name="email"
    type="email"
    inputmode="email"
    autocomplete="username"
    required
  />

  <label for="password">Password</label>
  <div class="password-row">
    <input
      id="password"
      name="password"
      type="password"
      autocomplete="current-password"
      required
    />
    <button type="button" aria-controls="password" aria-pressed="false">
      Show
    </button>
  </div>

  <div id="login-errors" role="alert" aria-live="polite"></div>

  <button type="submit">Log in as Property Owner</button>
</form>

<!-- Tabs + progress steps: real relationships, not visual-only text runs -->
<nav aria-label="Claim sections">
  <div role="tablist" aria-label="Claim sections">
    <button id="tab-overview" role="tab" aria-selected="true" aria-controls="panel-overview">
      Overview
    </button>
    <button id="tab-work" role="tab" aria-selected="false" aria-controls="panel-work">
      Work
    </button>
    <button id="tab-evidence" role="tab" aria-selected="false" aria-controls="panel-evidence">
      Evidence
    </button>
    <button id="tab-timeline" role="tab" aria-selected="false" aria-controls="panel-timeline">
      Timeline
    </button>
  </div>
</nav>

<ol class="claim-steps">
  <li>Claim opened</li>
  <li aria-current="step">Evidence organized</li>
  <li>Internal review</li>
  <li>Owner update</li>
</ol>

<!-- Accessible modal preview -->
<dialog id="upload-evidence-dialog" aria-labelledby="upload-evidence-title">
  <form method="dialog">
    <button type="submit" aria-label="Close upload evidence dialog">×</button>
  </form>

  <h2 id="upload-evidence-title">Upload evidence</h2>
  <p id="upload-evidence-help">
    Add photos, receipts, or status notes for this claim.
  </p>

  <label for="evidence-type">Evidence type</label>
  <select id="evidence-type" name="evidenceType" aria-describedby="upload-evidence-help">
    <option>Damage photo</option>
    <option>Receipt</option>
    <option>Work status note</option>
  </select>

  <button type="button">Upload evidence</button>
</dialog>

Beyond accessibility, the microcopy needs a disciplined rewrite. The following changes would have an immediate effect on clarity and trust:

Visual consistency is directionally good because the same shell, role cards, and utility pattern repeat across the site. That repetition is a useful seed for a design system. However, it currently repeats too much of the wrong content. The hero image, chooser content, and legal links recur beneath pages whose primary job is simply to let someone log in or request access. The result is a UI that is consistent in component presence but not consistent in task focus.

Information architecture and conversion effectiveness are similarly mixed. The chooser explains roles well, but once a user picks a role, the product should narrow to that task. Instead, auth pages immediately reintroduce every other route. That weakens conversion by turning a single-task page into a mini-site. The owner pathway is especially vulnerable because owners are the least expert audience and the most likely to be stressed by claim uncertainty.

Performance, Responsive Design, Benchmarking, and Measurement

A live Lighthouse, Axe, or WAVE run against the FireAndStorm routes was not directly executable from this research environment, so this section does not fabricate numeric current scores. Instead, it gives a route-family assessment, explicit target bands, and the most likely hotspot areas, using Chrome, Google Search Central, WAVE, and axe guidance as the measurement framework. Lighthouse audits performance, accessibility, SEO, and best practices; Lighthouse performance scores should be interpreted in score bands, and Google also notes that performance runs vary and should be medianed across repeated tests.

The highest-confidence performance and best-practice recommendations are straightforward. Remove chooser duplication from auth pages. Reduce top-bar clutter on demo pages. Collapse or lazy-render secondary preview panels instead of exposing them as always-present modal-like regions in the page stream. Add noindex, nofollow to all login/register/demo/legacy routes so search engines do not treat utility screens and query-string demo detail pages as content pages.

<!-- SEO / utility-route control -->
<meta name="robots" content="noindex, nofollow">

Responsive behavior could not be pixel-tested on live viewports here, but the page composition strongly suggests that the current density will create avoidable strain on mobile widths. Google documents that Search is mobile-first, so desktop-only clarity is not enough. Material’s responsive guidance treats breakpoints as opinionated transitions where the layout should adapt to available space and ergonomics.

Competitor and adjacent-product benchmarking shows what stronger patterns look like in the same broad problem space:

Because internal analytics are unspecified, the right move is a lean event framework tied directly to the public flows visible in the crawl. It should avoid claim numbers, free-text note payloads, and any personally sensitive values in event properties, in line with the portal’s own data-safety warnings.

Prioritized Backlog and Annotated Wireframes

The backlog below is ordered by user harm, clarity impact, and implementation leverage. Severity uses a product-risk lens rather than a purely technical severity scale.

Below are annotated sketches for the top 10 fixes.

Fix 1 — Auth page stripped to one job

┌──────────────────────────────────────┐
│ FireAndStorm Portal                  │
│ Property Owner Login                 │
│ Use your portal email and password.  │
│ [ Email address__________________ ]  │
│ [ Password________________ ][Show]   │
│ [ Log in as Property Owner ]         │
│ Need access? Request owner access →  │
│ Need help signing in?                │
└──────────────────────────────────────┘

This removes the chooser from the auth page and keeps the user in one task lane. It directly addresses the current duplicated chooser problem.

Fix 2 — Dedicated chooser with stronger role framing

┌────────────────────────────────────────────┐
│ Choose your portal                         │
│                                            │
│ [ Property Owner ]  Track status & visits  │
│ [ Contractor ]      Manage work & invoices │
│ [ Adjuster ]        Review documents       │
│                                            │
│ Secondary: Explore demo workspace →        │
└────────────────────────────────────────────┘

The demo becomes a secondary orientation path instead of competing with primary access tasks on every form page.

Fix 3 — Mobile utility header collapse

┌──────────────────────────────┐
│ FireAndStorm     ☰           │
│ Contractor Portal            │
│ [ Open claim ]               │
│ Tabs: Overview | Work | ...  │
└──────────────────────────────┘

Menu contains:
- Public site
- Call
- Privacy
- Terms
- Switch role
- Exit demo

This turns the current crowded inline utility strip into a predictable mobile pattern.

Fix 4 — Semantic tab rail with active state

┌──────────────────────────────────────┐
│ [Overview]* [Work] [Evidence] [Docs] │
├──────────────────────────────────────┤
│ Overview panel content               │
│ Status card                          │
│ Next actions                         │
└──────────────────────────────────────┘

This replaces the current text-run impression with real tabs, a visible active state, and proper panel relationships.

Fix 5 — Owner status card with certainty language

┌──────────────────────────────────────┐
│ Claim status                         │
│ Stage: Internal review               │
│ Next update: by Tue, Jun 16          │
│ What we need from you: 2 items       │
│ [ Upload requested items ]           │
│ [ Schedule visit ]                   │
└──────────────────────────────────────┘

This replaces vague states like Visible soon or Not available yet with concrete dates and next actions.

Fix 6 — Guided access-request form

┌──────────────────────────────────────┐
│ Request Property Owner Access        │
│ Full name                            │
│ [______________________________]     │
│ Email                                │
│ [______________________________]     │
│ Phone                                │
│ [______________________________]     │
│ Why do you need access?              │
│ ( ) Check claim status               │
│ ( ) Upload requested items           │
│ ( ) Review estimate                  │
│ [ Submit request ]                   │
└──────────────────────────────────────┘

This is clearer and more role-appropriate than Name or company plus a freeform Access goal field.

Fix 7 — Accessible upload dialog

┌──────────────────────────────────────┐
│ Upload evidence                    X │
│ Add photos, receipts, or notes.      │
│ Type                                 │
│ [ Damage photo ▼ ]                   │
│ Files                                │
│ [ Choose files ]                     │
│ Note                                 │
│ [______________________________]     │
│ [ Upload evidence ]                  │
└──────────────────────────────────────┘

The visual sketch assumes proper dialog semantics, focus trap, return focus, and live error messaging.

Fix 8 — Claim detail as a two-layer workspace

┌────────────────────────────────────────────────────┐
│ Fire / Lightning Naperville   DEMO-DAILY-FIRE-001 │
│ Next action: Review photo set and estimate lines  │
├────────────────────────────────────────────────────┤
│ Left: status + documents        Right: timeline    │
│ Left: primary actions           Right: next tasks  │
└────────────────────────────────────────────────────┘

This turns the current stacked density into a more legible workspace while preserving semantic order.

Fix 9 — Embedded help and expectation card

┌──────────────────────────────────────┐
│ What happens next                    │
│ • We review your request in 1–2 days │
│ • We contact you if more info is needed
│ • You receive an email when access is ready
│ [ Read eligibility details ]         │
└──────────────────────────────────────┘

This brings support and expectation-setting to the point of need instead of hiding them behind generic help.

Fix 10 — Dashboard shortcut cluster inspired by modern claim tools

┌──────────────────────────────────────┐
│ Quick actions                        │
│ [ Call ] [ Email ] [ Upload ]        │
│ [ Notes ] [ Documents ] [ Search ]   │
└──────────────────────────────────────┘

Encircle’s mobile claim home page shows the value of operational shortcuts such as GPS, phone, email, documents, notes, search, and sync state. FireAndStorm can bring the same clarity into its role dashboards.

Open Questions and Limitations

Exact Lighthouse, Axe, and WAVE scores were not directly available in this environment, so no fabricated current scores are included. The report therefore uses official tool guidance plus public-route evidence to provide a score-ready remediation plan and target bands instead. Chrome’s Lighthouse docs confirm those tools can be run on public or authenticated pages, WAVE’s browser extension can evaluate password-protected and dynamic pages, and WebAIM as well as Deque both emphasize that automated tools do not replace manual evaluation.

Rendered HTML screenshots of live pages were not available from this environment, so the “snapshots” in this report are rendered-text snapshots plus semantic DOM reconstructions. That means visual-only issues such as exact spacing, contrast, type scale, focus styling, and breakpoint behavior still require live browser QA. WCAG contrast checks, keyboard traps, screen-reader announcements, and dialog focus handling should all be verified in-browser before release.

Finally, no authenticated production workspace beyond the public login and request pages was accessible. The role-based demo dashboards and claim-detail pages were therefore used as the only observable representation of the post-login experience. That is enough to identify the estate’s biggest structural and language problems, but it is not enough to certify the real signed-in production experience without direct testing of private routes.