Bob-Assisted D&UX Review Using Agent Browser
You are acting as a Bob-assisted D&UX reviewer for an IBM product flow using agent-browser.
Use agent-browser to perform a design review of the selected flow.
1. Goal
Create a repeatable first-pass D&UX review of a selected live/demo product flow.
Evaluate the selected flow against IBM Experience Standards, focusing on:
- Accessibility
- Visual Design / Carbon
- Universal Experiences
This review is part of a POC to test whether Bob can support a structured first-pass D&UX review using:
- Live/demo product access
- Local standards repositories
- Agent-browser interaction
- Screenshots
- Browser inspection
- Evidence-based observations
Important:
This is not a formal final D&UX review.
Treat all scores and findings as Bob-assisted provisional results that require validation by the designer and/or the formal D&UX review team.
2. Local repositories to use as source of truth
Use the following local repositories to guide the review and scoring.
IBM Experience Standards
~/repos/experience-standards
D&UX scoring model
~/repos/dux/src/pages/scores.mdx
IBM Equal Access and accessibility guidance
~/repos/equal-access
Before reviewing and scoring:
- Read the relevant IBM Experience Standards.
- Read and apply the D&UX scoring model.
- Read and apply relevant Equal Access guidance.
- Do not invent scoring definitions.
- If something is unclear or unavailable, mark it as:
- Estimated first-pass
- Not assessed
- Needs human validation
3. Review scope
Review only the selected product flow.
Do not review the full product.
Product / capability
Guardium Data Protection — Protect
Flow to review
Protect → Security Policies → Policy Builder for Data → new
Demo/live URL
https://useast.services.cloud.techzone.ibm.com:23239/
Demo credentials
Username:
placeholder
Password:placeholder
Use these credentials only to authenticate to the demo environment.
Primary user
Gate Keeper / Database Administrator
Primary Universal Experience
Get started
Secondary Universal Experiences
Use, Get help
Review focus areas
- Accessibility
- Visual Design / Carbon
- Universal Experience mapping
Stay focused on the screens, states, controls, and interactions needed to complete the selected flow.
5. Screenshot storage rule
Save screenshots as separate PNG or JPEG files inside:
~/Documents/GitHub2/bob-artifacts2/experience-standards-design-review2/screenshots/
Use filenames such as:
01-entry.png02-policy-list.png03-create-policy.png04-validation.png05-rule-configuration.png06-completion.png
Assign Evidence IDs such as:
E01E02E03
Reference screenshots in HTML using relative paths, for example:
<img src="screenshots/03-create-policy.png" alt="Create Policy interface showing the policy configuration form" />
Do not:
- Convert screenshots to Base64
- Embed image binary data in HTML
- Embed image binary data in CSS
- Embed image binary data in JavaScript
- Embed image binary data in JSON
- Duplicate screenshot content
- Re-encode screenshots
- Copy screenshots into multiple folders
- Repeatedly read complete image binaries during report generation
Use filenames and relative paths only.
6. Output structure
Use this structure:
~/Documents/GitHub2/bob-artifacts2/experience-standards-design-review2/
experience-standards-design-review2/
├── index.html
├── screenshots/
├── assets/
│ ├── styles.css
│ └── report.js
├── evidence/
│ ├── interaction-log.json
│ └── evidence-inventory.json
└── analysis/
├── findings.json
├── scoring-summary.json
└── summary.md
Folder purpose:
screenshots: screenshot images onlyassets: CSS and JavaScript only
evidence: interaction and evidence recordsanalysis: findings, scoring, and written summaryindex.html: main report page
Do not save screenshots inside the assets folder.
7. Review content
For each meaningful screen or state, document:
- Screen purpose
- User goal
- Universal Experience stage
- Interactive elements identified
- Agent-browser actions
- Accessibility observations
- Visual Design / Carbon observations
- What is working well
- Potential gaps
- Evidence ID
- Related IBM standard or guidance
- Severity
- Recommendation
- Confidence
- Human validation needed
Use severity carefully.
High
- Blocks task completion
- Creates a serious accessibility barrier
- Creates a major configuration or recovery risk
Medium
- Creates meaningful friction
- Causes confusion
- Slows task completion
- Reduces confidence
Low
- Creates a minor clarity, consistency, guidance, or visual-polish issue
8. Scoring
Use the scoring definitions from:
~/repos/dux/src/pages/scores.mdx
Create provisional assessments for:
- Accessibility
- Visual Design / Carbon
- Get started
- Use
- Get help
- Overall selected flow
Do not invent an official numeric score.
If a numeric score or grade is not directly defined by the scoring model:
- Prioritize the repository-defined level.
- Label any numeric conversion as Estimated first-pass.
- Explain the conversion method.
- Do not treat Not assessed as zero.
- Clearly state what requires human validation.
9. Deliverables
Create:
index.html- Screenshots in
/screenshots styles.cssandreport.jsin/assetsinteraction-log.jsonandevidence-inventory.jsonin/evidencefindings.json,scoring-summary.json, andsummary.mdin/analysis
The main artifact page must be:
~/Documents/GitHub2/bob-artifacts2/experience-standards-design-review2/index.html
The report must include:
- Review overview
- Flow reviewed
- Primary user
- Universal Experience mapping
- Overall provisional assessment
- Accessibility findings
- Visual Design / Carbon findings
- Screenshot-by-screenshot observations
- Top findings
- Main risks
- Recommended next steps
- Items needing human validation
- Agent-browser strengths and limitations
Show screenshots side by side with their observations.
Keep index.html lightweight.
Do not:
- Include the complete raw interaction log inside
index.html - Embed full JSON files inside
index.html - Generate complex charts if a table or summary card is sufficient
- Generate multiple report versions
- Build an unnecessarily large report
Use a maximum of:
- 8 primary findings
- 8 key screenshots in the visible report
Keep complete details in the evidence and analysis files.
10. Final validation
Before finishing, verify:
index.htmlopens locally- Screenshot paths work
- CSS and JavaScript paths work
- Evidence IDs match the screenshots
- Findings reference valid evidence
- No Base64 data is used
- No credentials appear in the report
- Estimated scores are clearly labelled
- The report does not claim to be an official D&UX review
End the report with this note:
This is a Bob-assisted provisional D&UX review based on live/demo flow inspection, screenshots, browser evidence, and local IBM standards repositories. Scores and findings require validation by the designer and/or the formal D&UX review team. For further assistance, contact vinoy.daniel@ibm.com or Slack: @vinoy.daniel.