Friborg Reports

UX Audit

BuildPulse UX Audit

A polished presentation version of the BuildPulse UX audit: verdict, friction points, mobile fit, and next product moves.

12 May 2026Appwrite-backedPresentation view
01 / 17

BuildPulse UX Audit

A presentation view of the 2026-05-12 UX audit for BuildPulse: what works, what is risky, and what should ship next.

02 / 17

BuildPulse UX/UI Audit — 2026-05-12

Executive summary

BuildPulse has a strong product idea: a calm cockpit that turns scattered ideas into scoped AI-building work. The current v0.4.1 app proves the core mechanics — Plan, Roadmap, Park, Pulse, Export, AI triage, Appwrite sync — but it is still harder to use than the product promise. The interface asks users to understand the system model before it helps them complete the next action.

The blunt diagnosis: BuildPulse is currently a useful internal tool wearing the costume of a product. It has too many top-level concepts, too much visible metadata, and too many equal-weight actions. The most valuable loop is simple — capture idea → classify → decide → hand off → record result — but the UI spreads that loop across five tabs, several modal/sheet patterns, and a lot of cockpit language.

The redesign should be inspired by Oikos-style ease: fewer choices at once, obvious next action, friendly plain-language flows, and mobile-first cards that feel safe to tap. BuildPulse should not become prettier Jira. It should become an idea-to-agent session funnel with a lightweight evidence trail.

Recommended direction:

  1. Make Today the home screen: current goal, active release, current focus feature, next recommended action.
  2. Collapse the product around one primary loop: Capture → Decide → Build → Record.
  3. Move Roadmap, Export, and System Status out of primary navigation; surface them contextually.
  4. Replace raw board-first UX with a guided “what do you want to do?” front door.
  5. Make AI handoff and result capture a single session workflow, not an export page.
  6. Cut visible metadata aggressively. Details belong behind focused sheets.
  7. Build mobile first: one card, one decision, one clear CTA per screen.

If v0.4 is about handoff hardening, the next improvement should not be another prompt preset. It should be a complete session loop: choose feature → generate brief → copy/log INTENT → paste result → classify RESULT/BLOCKER/TEST_RESULT → update feature state.

03 / 17

Evidence inspected

  • Live public app: https://build.friborg.uk
  • Live health endpoint: https://build.friborg.uk/api/health returned Appwrite-backed OK.
  • Live state endpoint: https://build.friborg.uk/api/state showed schema 0.3.0, 6 features, 7 parking items, 11 pulses, 8 phases, 3 releases.
  • Repo inspected: /home/openclaw/.openclaw/workspace/buildpulse
  • Main UI files inspected:
    • src/App.tsx
    • src/index.css
    • src/features/project/projectDefaults.ts
    • src/store/types.ts
    • docs/UI_SPEC.md
    • docs/PRODUCT_BRIEF.md
    • docs/ROADMAP.md
  • Visual inspection fallback used source/API plus existing screenshot because Canvas/browser runtime reported node required.
04 / 17

1. What currently makes BuildPulse hard to use

1.1 The app exposes the data model too directly

The current primary tabs are:

  • Plan
  • Roadmap
  • Park
  • Pulse
  • Export

These are accurate database/product modules, but they are not how a solo builder thinks in the moment. The builder thinks:

  • “I have an idea.”
  • “What should I work on now?”
  • “Give an agent a clean brief.”
  • “The agent came back; what do I do with the result?”
  • “What changed?”

BuildPulse makes users navigate to nouns instead of guiding them through verbs.

1.2 Too many concepts compete for first-class attention

The current UI has all of these visible or easily reachable as major concepts:

  • Project
  • Current goal
  • Feature columns
  • Roadmap
  • Phases
  • Releases
  • Release readiness
  • Required features
  • Optional features
  • Forbidden features
  • Parking Lot
  • Risk levels
  • Pulse types
  • Sources
  • Agents
  • Handoff targets
  • Markdown package
  • JSON export
  • Appwrite sync
  • System Status
  • AI recommendations

Many are useful. Too many are first-class. The result is cockpit noise.

1.3 “Triage first” is stated, but not structurally enforced

The Plan page says “Triage first. Create later. Log always.” Good. But the UI still gives “Add Feature” next to “Triage Idea,” and manual creation remains visually available near the top. If triage is the product’s key behavior, manual creation should be secondary and slightly hidden.

Current problem: the system says one thing but offers an escape hatch with similar prominence.

Recommendation: default to one primary CTA: Add idea. Inside that flow, let the user choose “Skip AI / manual feature” as a quiet secondary option.

1.4 The board starts too far down the screen

The working area is pushed below:

  • header
  • sync/status strip
  • tab bar
  • home card
  • breadcrumbs
  • counts
  • project details disclosure
  • tap hint

This is especially costly on mobile. The product promise is “what now?” but the board and current work do not get enough top priority.

1.5 Metadata is over-visible

Feature cards currently show title, priority, status, criteria count, column, roadmap badges, triage time, and “tap to open.” This makes scanning harder.

For the list/card view, keep only:

  • title
  • one-line outcome / description
  • status
  • one urgency/priority marker
  • next action or blocker

Move phase/release/criteria/triage metadata into the detail sheet.

1.6 “Export” is a product smell

Export is important, but as a primary tab it frames the product as a data utility. The real user need is not “export.” It is:

  • “Start an AI session.”
  • “Brief an agent.”
  • “Save a backup.”

Export should become a contextual action inside feature/release/session flows. Backup/import can live under Settings or Project.

1.7 Roadmap is powerful but too administrative

The Roadmap tab exposes phases, releases, definitions of done, forbidden lists, required/optional feature linking, readiness, blockers, pulses. This is good structure, but it feels like configuration work.

The solo builder should mainly see:

  • current release
  • progress
  • blockers
  • what is forbidden right now
  • “edit release plan” if needed

The detailed release editor should be a secondary sheet, not a full primary workflow.

1.8 Pulse Log is treated as a database, not a behavior

Pulse is one of BuildPulse’s strongest ideas. But asking users to visit a Pulse tab and compose generic pulse records is too abstract.

Pulse should be captured at the moment of work:

  • after triage decision
  • after handoff copy
  • after agent result paste
  • after manual test
  • after blocker found
  • after feature shipped

The Pulse Log should remain as history, but pulse creation should be contextual and templated.

1.9 Current visual language is cohesive but too loud in the wrong places

The dark cockpit style is attractive and on-brand, but many surfaces share similar card treatments, glows, pills, borders, and gradients. The active nav can visually overpower primary work actions.

The app needs stronger hierarchy:

  • one dominant action per screen
  • quieter navigation
  • fewer pills
  • less decorative contrast inside dense workflows
  • clearer difference between “content,” “control,” “metadata,” and “system status”

1.10 Mobile is improved, but still structurally desktop-minded

The CSS has meaningful mobile work: bottom nav, sheets, stacking cards, clipping guards. Good. But the product model is still desktop-board-first. Four columns, release editors, markdown previews, filter rows, and large forms remain heavy on a phone.

Mobile should not be “desktop stacked.” It should be a different task rhythm:

  • Today
  • Add idea
  • Review recommendation
  • Start session
  • Record result
  • Browse history only when needed
05 / 17

2. Ideal end-to-end user flow for the full product

The full BuildPulse product should feel like a guided loop, not a dashboard.

2.1 Core loop

1. Open BuildPulse
2. See Today: goal, current release, current focus, next recommended action
3. Capture raw idea or choose current feature
4. AI classifies idea / system shows scope fit
5. User decides: Now, Next, Later, Park, Reject, Merge, Clarify
6. BuildPulse logs DECISION pulse automatically
7. If working now, BuildPulse creates or updates a feature with acceptance criteria
8. User starts an AI session from that feature
9. BuildPulse generates target-specific brief and logs INTENT pulse
10. User runs agent externally
11. User pastes agent result back into BuildPulse
12. BuildPulse classifies result: RESULT, BLOCKER, TEST_RESULT, SESSION_END
13. User confirms update to feature/release state
14. BuildPulse updates Today and Pulse history

2.2 The future product should have four user-facing verbs

Capture

For raw ideas, bugs, risks, notes, possible features.

Primary UI:

  • one text box
  • optional context
  • “Classify” button

Decide

For AI recommendation review.

Primary UI:

  • recommendation
  • why
  • smallest safe version
  • risk
  • duplicate warning
  • one main action
  • secondary actions

Build

For active scoped work.

Primary UI:

  • current feature
  • acceptance criteria
  • constraints
  • start agent session
  • session mode

Record

For what happened.

Primary UI:

  • paste result
  • choose/change classification
  • update feature status
  • log pulse

2.3 Ideal daily use

A user opens BuildPulse and sees:

Today
Current goal: Ship v0.4 handoff loop
Current release: v0.4 — Handoff Workflow Hardening
Focus: One-tap target-specific handoffs
Next best action: Record result from last agent session

[Record Agent Result] [Start AI Session] [Add Idea]

Below that:

  • 1 active feature card
  • 2-3 next candidates
  • recent decisions
  • parked risk warnings only if important

Everything else is drill-down.

06 / 17

3. Information architecture recommendation

3.1 Current IA

Plan
Roadmap
Park
Pulse
Export
Status (hidden but reachable)

This is implementation-centric.

3.2 Recommended IA for v0.4/v0.5

Primary navigation:

Today
Ideas
Build
History

Secondary/global:

Project / Settings
Backup / Import
System Status

Contextual actions:

Start AI Session
Export Brief
Record Result
Edit Release
Edit Feature
Park
Reject

3.3 What each section owns

Today

Purpose: answer “what now?”

Contains:

  • current goal
  • current release
  • focus feature
  • next recommended action
  • recent activity summary
  • parking warnings if urgent

Does not contain:

  • full markdown exports
  • full roadmap editing
  • raw sync controls

Ideas

Purpose: capture and sort incoming thoughts.

Contains:

  • Add idea flow
  • AI recommendations pending decision
  • Parking Lot
  • Next/Later candidates
  • duplicate/scope warnings

Build

Purpose: active work and handoff.

Contains:

  • Now features
  • selected focus feature
  • acceptance criteria
  • session launcher
  • result recorder
  • release readiness snapshot

History

Purpose: evidence trail.

Contains:

  • Pulse timeline
  • filters
  • decisions
  • test results
  • blockers
  • session records

3.4 Where Roadmap goes

Roadmap should become part of Project/Release settings and appear contextually:

  • Today shows current release summary.
  • Build feature detail shows phase/release link.
  • Release detail sheet edits definition of done, forbidden work, required features.

No primary Roadmap tab until multi-project or team workflows justify it.

3.5 Where Export goes

Export should split into:

  • Start Session — feature/release brief generation.
  • Backup — full JSON/import.
  • Developer package — advanced action in Project menu.

No primary Export tab.

07 / 17

4. Interaction model

4.1 Use a “wizard sheet” for decisions

AI triage is already close to this. Keep going.

Pattern:

Step 1: Input
Step 2: Recommendation
Step 3: Decision
Step 4: Done / Next action

But simplify the decision screen:

  • One primary recommendation CTA.
  • Two secondary alternatives.
  • “Edit details” collapsed.
  • “Reject” as quiet destructive action.

Example:

AI recommends: Park this
Reason: high scope risk for v0.4
Smallest safe version: Add to v0.6 candidate list

[Park idea] primary
[Create feature anyway] secondary
[Ask clarification] secondary
[Reject] quiet danger

4.2 Use contextual pulse templates

Do not make users choose from ten pulse types in a generic composer unless they open Advanced.

Examples:

From feature detail:

  • “Start session” → INTENT
  • “Record result” → RESULT
  • “Mark blocker” → BLOCKER
  • “Add test result” → TEST_RESULT
  • “Mark done” → RESULT + feature status update

From triage:

  • Accept/Park/Reject → DECISION

From release:

  • “Ready to ship” → DECISION
  • “Ship release” → RESULT

4.3 Replace generic forms with progressive disclosure

Feature creation should ask for minimum viable fields first:

  1. Title / raw idea
  2. Outcome
  3. Acceptance criteria
  4. Placement

Advanced fields collapsed:

  • phase
  • release
  • release role
  • priority
  • scope notes
  • trace IDs

4.4 Make session handoff a closed loop

Current v0.4.1 does copy/preview/INTENT reasonably well. The missing half is result intake.

Recommended flow:

Feature detail
→ Start AI Session
→ choose target and mode
→ preview/copy brief
→ INTENT pulse logged
→ session appears as “awaiting result”
→ paste result
→ AI or rules classify it
→ user confirms updates
→ RESULT/BLOCKER/TEST_RESULT logged

This will make BuildPulse feel like a product instead of an export utility.

4.5 Support “inbox” for unresolved items

Create an internal queue for:

  • pending AI recommendations
  • sessions awaiting result
  • blockers needing decision
  • features missing acceptance criteria
  • duplicate parked ideas

Surface this queue on Today as “Needs decision.”

08 / 17

5. Navigation recommendations

5.1 Primary nav should be four items max

Recommended:

Today | Ideas | Build | History

Mobile bottom nav can support these four cleanly.

5.2 Kill or demote current top-level tabs

Current tab Recommendation
Plan Merge into Build, with Today summary above it
Roadmap Demote to Release/Project settings
Park Merge into Ideas
Pulse Rename History; pulse creation happens contextually
Export Replace with Start Session and Backup actions
Status Keep under system/settings only

5.3 Add a global primary action

A persistent primary action should exist on every main screen:

+ Add Idea

On Build/feature detail, the local primary action can become:

Start AI Session

5.4 Use breadcrumbs only inside multi-step flows

The current “Raw idea → AI recommendation → User decision → DECISION pulse” breadcrumbs are useful, but they should live inside triage, not occupy home-screen space permanently.

09 / 17

6. Visual/design-language recommendations

6.1 Keep the dark cockpit, reduce the cockpit noise

The dark sci-fi look is memorable. Keep:

  • dark background
  • calm neon accent
  • rounded cards
  • subtle gradients
  • high-contrast primary CTA

Reduce:

  • too many pills
  • too many glows
  • nested cards inside cards
  • equal card styling for everything
  • loud nav gradient competing with work actions

6.2 Establish a clearer visual hierarchy

Use three surface levels:

  1. Primary work surface — bright, clear, spacious.
  2. Secondary cards — quieter, lower contrast.
  3. Metadata/system — small, muted, no decorative glow.

Today should have the strongest visual weight. System status should be nearly invisible unless broken.

6.3 Use semantic color sparingly

Suggested mapping:

  • Cyan/blue: primary action / active focus
  • Green: done/safe/synced
  • Yellow: needs decision/testing
  • Orange: blocker/high risk
  • Red: dangerous/destructive only
  • Purple: later/future/parked optional

Avoid using every color on every card.

6.4 Card design: one-line scan first

Feature card recommended layout:

[Status dot] Feature title                         [Now]
Outcome or one-line description
Next: Start AI session / Record result / Add criteria

Secondary row only if useful:

Must · 3 criteria · v0.4

No phase/release/triage timestamps on default cards.

6.5 Replace “tap” language with neutral verbs

Use:

  • “Open details”
  • “Review”
  • “Start session”
  • “Record result”

Avoid:

  • “Tap to open” on desktop
  • overly cute hints when a button label could do the job

6.6 Typography

Current typography is readable but metadata-heavy. Recommendation:

  • larger section titles, fewer section titles
  • stronger body text for primary instructions
  • smaller, quieter metadata
  • avoid all-caps eyebrow labels everywhere; reserve them for mode/context
10 / 17

7. Mobile-first concerns

7.1 Mobile should not expose the kanban as the main object

On phones, the board should become a segmented list:

Build
[Focus]
[Now]
[Next]
[Later]
[Done]

Default open section: Focus/Now.

7.2 Bottom nav should have four items

Current app has five primary tabs. Five can work, but BuildPulse’s labels and workflows are too dense. Four is cleaner:

Today | Ideas | Build | History

7.3 Sheets should become full-screen task flows

The current mobile sheets are practical, but complex forms inside sheets can feel cramped.

For mobile:

  • Triage = full-screen flow.
  • Feature detail = full-screen panel with tabs/sections.
  • Handoff preview = full-screen editor with sticky copy button.
  • Roadmap editor = not primary on mobile.

7.4 Reduce text previews

Markdown package previews are hostile on mobile. Hide previews by default.

Use:

  • Copy
  • Download
  • Preview collapsed

7.5 Sticky actions matter

Every mobile task flow should have one sticky bottom action:

  • Analyze idea
  • Park idea
  • Create feature
  • Start session
  • Copy brief
  • Record result
  • Save changes

Avoid long forms where the save action disappears far below.

11 / 17

8. What should be cut or simplified

Cut from primary navigation

  • Export tab
  • Roadmap tab
  • System Status access from top header except degraded states

Cut from default card views

  • triaged timestamps
  • phase/release badges unless on Build detail
  • column labels inside a column
  • “tap to open” chips
  • evidence/source metadata outside history

Cut or hide from default forms

  • trace ID
  • confidence score manual entry
  • source/agent manual entry
  • release role on basic feature add
  • phase/release on basic feature add

Simplify naming

Current Suggested
Parking Lot Parked Ideas
Pulse Log History or Activity
Export Start Session / Backup
Feature Plan Build Plan
AI Idea Placement Idea Review or Scope Check
Release readiness Current Release

Simplify pulse type selection

Keep advanced pulse type list, but default to contextual templates:

  • Decision
  • Result
  • Blocker
  • Test result
  • Note

Map these to formal pulse types internally.

De-duplicate parking items

Live state has repeated “AI Idea Generation Assistant” parked items. The app should detect and group duplicates in Ideas:

Possible duplicate: 3 similar parked ideas
[Merge] [Keep separate]
12 / 17

9. Prioritized redesign roadmap

Phase A — v0.4.2: close the handoff loop

Goal: make v0.4 feel complete.

Build:

  1. Add “Record Agent Result” to feature detail.
  2. Add session state after Copy + INTENT: awaiting_result.
  3. Add result paste flow.
  4. Classify pasted result as RESULT/BLOCKER/TEST_RESULT/SESSION_END.
  5. Let user update feature status during result save.
  6. Show “awaiting result” item on Plan/Today.

Do not build:

  • live agent telemetry
  • Git integration
  • WebSockets
  • multi-session dashboards

Phase B — v0.4.3: simplify navigation without rewriting everything

Goal: reduce cognitive load.

Build:

  1. Add a new Today view or convert Plan top area into Today.
  2. Move Export actions into feature detail and Project menu.
  3. Move Roadmap behind “Current Release” card.
  4. Rename Pulse to History.
  5. Make + Add Idea persistent.

This can be done incrementally while leaving old tabs accessible under an “Advanced” menu.

Phase C — v0.5: idea inbox and duplicate control

Goal: make idea maturation feel safe.

Build:

  1. Ideas screen with pending recommendations, parked ideas, Next/Later candidates.
  2. Duplicate grouping for similar parked ideas.
  3. “Needs decision” queue.
  4. Clarification loop improvements.
  5. Weekly review mode: promote, keep parked, reject, merge.

Phase D — v0.6: release cockpit, not roadmap editor

Goal: make release planning useful without admin sludge.

Build:

  1. Current Release card on Today.
  2. Release detail sheet.
  3. Required/optional/forbidden simplified editor.
  4. Release readiness checklist.
  5. “Prepare ship brief” action.

Phase E — v1.0: agent pulse ingestion

Only after manual/session loop is excellent.

Build:

  1. Simple HTTP endpoint for pulse events.
  2. Token-protected append-only ingest.
  3. Incoming pulse review queue.
  4. Feature status suggestions, not automatic mutation.
13 / 17

10. Specific UI/flow recommendations for current v0.4

10.1 Feature detail should become the v0.4 command center

Current feature sheet already has:

  • acceptance criteria
  • scope notes
  • log pulse
  • open export
  • preview/edit handoff
  • quick-copy targets

Reframe this sheet around a session workflow:

Feature detail

Status: Ready / Building / Awaiting result
Release: v0.4 — Handoff Workflow Hardening
Next action: Start AI session

[Start AI Session] primary
[Record Result] secondary if session exists
[Edit Feature] secondary

Acceptance criteria
Scope guardrails
Recent activity

Move raw edit fields behind “Edit feature.” Do not show the full editing form by default when opening a feature.

10.2 Handoff preview should have a simpler first screen

Recommended layout:

Start AI Session
Feature: One-tap target-specific handoffs
Target: [OpenClaw v]
Mode: [Implementation] [Bugfix] [QA Review] [Design Review]

Include:
[x] Acceptance criteria
[x] Release constraints
[x] Forbidden work
[x] Recent pulses
[ ] Parking lot warnings

[Preview Brief]
[Copy + Log Intent]

Then preview/edit as second step.

10.3 Add result capture immediately after INTENT

After “Copy + INTENT Pulse,” show success state:

Brief copied. INTENT logged.

When the agent finishes, paste the result here.
[Record Agent Result]
[Back to Build]

This teaches the closed loop.

10.4 Make “manual pulse” advanced

In Pulse/History, default button should be:

+ Add Note

Inside:

  • message
  • optional feature
  • type defaults to Note/Result
  • advanced fields collapsed

10.5 Reduce Plan page chrome

Current Plan should become:

Today / Build
Current goal
Focus feature card
Primary action: Start session or Add idea
Now list
Next list collapsed
Later/Done collapsed

Project details should move to Project settings.

10.6 Fix top-level nav wrapping/weight

The visual screenshot showed Export wrapping awkwardly / nav taking too much weight. If keeping five tabs temporarily:

  • reduce min width
  • use icons or shorter labels
  • make active state less visually dominant than primary CTA
  • consider “More” for Roadmap/Export/Status

10.7 Parking Lot should become part of Ideas

The current Park screen is decent, especially risk grouping. The improvement is IA, not component-level.

New Ideas screen sections:

  1. Add idea
  2. Pending decisions
  3. Parked high risk
  4. Parked medium/low
  5. Rejected/duplicates collapsed

10.8 Roadmap should surface only warnings by default

On Today/Build show:

Current release: v0.4
Required: 1/2 done
Blockers: none
Forbidden right now: Live telemetry, Git sync, model router

Button:

Edit release plan

Do not put the full Roadmap editor in daily flow.

14 / 17

11. Future-phase recommendations

v0.5 — Local/cloud AI assistant

Risk: this could turn into router spaghetti.

UX rule: model choice should not be a dashboard. It should be a quiet setting with product-level labels:

  • Fast local
  • Strong local
  • Cloud reasoning
  • Auto

Expose model details only in advanced settings.

User-facing AI actions should remain verbs:

  • classify idea
  • summarize history
  • draft acceptance criteria
  • classify result
  • suggest next action

v1.0 — Agent Pulse ingestion

Risk: live ingestion can destroy trust if it mutates state automatically.

UX rule: agents submit evidence; humans approve important state changes.

Incoming pulse queue:

Agent reported TEST_RESULT for Feature X
Suggested update: status → testing
[Accept] [Edit] [Ignore]

v1.5 — Observability

Do not make a wallboard. Make a “work radar.”

Useful views:

  • Active sessions
  • Waiting on human
  • Blocked
  • Recently completed
  • Needs verification

v2.0 — Agent Pulse framework

If BuildPulse becomes a nervous system, the UX must still preserve the solo-builder cockpit:

  • human-readable decisions
  • clear ownership
  • visible constraints
  • undo/review queues
  • no mystery automation
15 / 17

12. Recommended target UX in one picture

TODAY
Current goal: Ship v0.4 handoff loop
Current release: v0.4 — Handoff Workflow Hardening

Focus
┌─────────────────────────────────────────────┐
│ One-tap target-specific handoffs             │
│ Ready for result capture                     │
│ Next: Record agent result                    │
│ [Record Result] [Start New Session]          │
└─────────────────────────────────────────────┘

Needs decision
- 1 duplicate parked idea group
- 1 feature missing acceptance criteria

Now
- Feature Plan screen          ready
- Parking Lot screen           ready
- Pulse Log screen             ready
- Export screen                ready

[+ Add Idea]

This is BuildPulse at its best: focused, scoped, alive, and not pretending to be an enterprise planning cathedral.

16 / 17

13. Implementation notes for the repo

Likely component extraction

src/App.tsx is too large for product iteration. Extract around user tasks, not data types:

src/features/today/TodayView.tsx
src/features/ideas/IdeasView.tsx
src/features/build/BuildView.tsx
src/features/history/HistoryView.tsx
src/features/session/SessionHandoffFlow.tsx
src/features/session/ResultCaptureFlow.tsx
src/features/release/CurrentReleaseCard.tsx
src/features/shared/Sheet.tsx
src/features/shared/PrimaryActionBar.tsx

Suggested state additions

Add session tracking before real agent integration:

interface BuildSession {
  id: string
  feature_id: string
  target: 'OpenClaw' | 'Claude Code' | 'Codex' | 'Generic Agent'
  mode: 'implementation' | 'bugfix' | 'qa_review' | 'design_review'
  status: 'brief_copied' | 'awaiting_result' | 'result_recorded' | 'closed'
  intent_pulse_id: string
  result_pulse_id?: string
  created_at: string
  updated_at: string
}

This keeps v0.4 honest without pretending to run agents.

Suggested CSS direction

Create tokens for:

  • surface levels
  • semantic states
  • spacing scale
  • mobile sticky action
  • card density variants

Then reduce one-off styling. The current CSS has many historical patches, especially around mobile gutters/nav. It works, but it is becoming archaeology.

17 / 17

Final verdict

BuildPulse is close to being genuinely useful because the product insight is good: AI-assisted builders need scope control, clean handoffs, and an evidence trail more than they need another task board.

But the UI should stop showing every internal organ. The next version should make the user feel guided, not briefed.

The north star: BuildPulse should open to the next sane action, protect the builder from scope creep, and make agent sessions easy to start and easy to close.

Make it simpler. Make it more opinionated. Make the happy path impossible to miss.

End

Share this URL instead of a document attachment.

Source: /home/openclaw/.openclaw/workspace/buildpulse/docs/BUILDPULSE_UX_AUDIT_2026-05-12.md