Designing AI-assisted tools for complex enterprise requirements work
Epiroc's Delivery team needed a better way to create, structure, and review Business Requirement Specifications. I designed and prototyped BRS Manager — the first tool within The Forge, an internal initiative focused on making complex delivery work clearer and more reviewable.
Client
Epiroc / The Forge
Year
February 2026–Present
Role
UX/UI Designer, AI-assisted prototyping
Scope
Enterprise UX, internal tools, requirements workflows, high-fidelity prototyping
Context
The Forge is Epiroc's internal innovation unit — focused on building tools that help Delivery teams work more effectively. BRS Manager is the first product: a tool for creating and managing Business Requirement Specifications on integration-heavy projects.
The problem sits at the intersection of structured enterprise process, cross-team communication, and evolving AI-assisted workflows — where the cost of ambiguity is high and the tolerance for unstructured output is low.
The challenge
01
Fragmented inputs
Requirements captured across email, documents, and conversations with no consistent structure.
02
Inconsistent outputs
BRS documents varied significantly in format, completeness, and quality across projects.
03
Difficult review
Reviewers had no clear way to compare or validate requirements across teams and integrations.
"Complex requirements work needs structure — but structure imposed at the wrong layer creates friction without clarity."
My role
Approach
Map the existing workflow
Interviewed Delivery Leads and reviewed existing documentation to understand where the BRS process broke down — fragmented inputs, inconsistent structure, and difficult cross-team review.
Define competing directions
Rather than iterate on one concept, I designed two fundamentally different interaction models — one conversational, one structured — to expose trade-offs and create a basis for real comparison.
Build working prototypes
Used Claude Code to build interactive, clickable prototypes for both directions. Moving quickly from concept to working interface meant stakeholders could test real tasks, not react to static mockups.
Validate with real users
Ran sessions with Delivery Leads using both prototypes. Focused on task completion, trust in AI suggestions, and how well each direction handled the complexity of enterprise requirement work.
Refine toward implementation
Based on clear stakeholder preference for the structured direction, refined Prototype B into a more complete design with defined states, edge cases, and component-level documentation.
Direction A
Conversational AI-assisted input
A chat-first approach where Delivery Leads describe integration needs in natural language and receive AI-guided structure in return. Low friction to start, but variable in output consistency.
Strengths
- Low initial friction
- Flexible for early exploration
- Familiar interaction pattern
Trade-offs
- Less predictable output structure
- Harder to compare and review across projects
- Output quality depended heavily on prompt quality
Direction B
Selected directionStructured smart wizard
A guided, step-based flow where users move through defined requirement sections with intelligent assistance at each stage. Prioritises consistent, reviewable output over conversational flexibility.
Strengths
- Consistent, reviewable output
- Clearer step-by-step guidance
- Better fit for repeatable enterprise workflows
- Stronger foundation for governance and auditability
Trade-offs
- Slightly more friction at the start
- Step structure requires careful design to avoid feeling rigid
Key product decisions
01
Two prototypes instead of one
Designing competing directions rather than iterating on a single concept gave stakeholders a genuine choice. It surfaced trade-offs earlier and made the final direction decision clear and defensible.
02
Structured flow over conversational input
A guided, step-based wizard provided more consistent outputs and was easier to review across projects. Conversational AI felt natural but produced variable structures that were harder to compare or audit.
03
Working prototypes over static presentations
Interactive prototypes built with Claude Code let users complete real tasks rather than imagining hypothetical ones. This made stakeholder feedback specific and grounded — not just opinions on visual design.
04
AI as assistant, not decision-maker
Keeping the Delivery Lead in control of each step, with AI surfacing suggestions rather than generating output autonomously, reduced resistance and fit better with enterprise compliance expectations.
From concept to working interface in days, not weeks
Translate the problem into a prototype brief
Define the interaction model, key flows, and what needs to be testable.
Scaffold layout and component structure
Use Claude Code to generate interface foundations — layouts, states, and navigation.
Iterate through the working interface
Refine based on feedback with each iteration happening in code, not static files.
Treat the prototype as specification
The prototype captures behavior, edge cases, and decisions before development begins.
Key screens
Workflow overview
How requirement work is broken into discrete, reviewable steps — making the process visible and auditable.
Prototype A — Conversational
Natural language input guiding the user through requirement definition. Flexible but variable in output structure.
Prototype B — Structured wizard
Step-by-step guided flow with AI assistance at each stage. Selected direction for its consistency and reviewability.
AI suggestion states
How AI surfaces contextual suggestions without taking control — keeping the Delivery Lead accountable for each decision.
Review-ready output
Structured specification output designed for stakeholder review, formatted consistently across all projects.
Component system
Reusable UI patterns forming the foundation for BRS Manager and future tools within The Forge.
Impact
Clear directional decision
Two competing working prototypes gave stakeholders a real basis for choosing a direction — not just a preference, but a tested judgment.
Earlier alignment across teams
Interactive prototypes replaced static documents in stakeholder conversations, reducing back-and-forth on intent and behaviour.
Faster from concept to testable interface
AI-assisted prototyping compressed the time between idea and something users could actually interact with and respond to.
Foundation for future tooling
The design system and interaction patterns established in BRS Manager are intended to carry into future tools within The Forge.
Reflection
The most valuable thing about this project wasn't the chosen direction — it was the process that made the choice credible.
Two working prototypes gave stakeholders something to actually react to, not just agree with in the abstract.
It also confirmed something I've come to rely on: in enterprise contexts, AI-assisted prototyping isn't about speed for its own sake. It's about making ideas testable earlier, so the decisions that matter get made on the basis of real evidence.
Interested in working together?
I'm available for new product design engagements.