Fragmented workflows
Incident, training, and policy activities could require separate tools and manual handoffs.
Enterprise SaaS · Ethics & Compliance · AI-assisted concept
Concept proposal at Mitratech · not implementedSyntrio Action Center: Turning Incident Signals into Preventive Compliance Action
A concept proposal that brought incident oversight, organisational trends, active case work, and human-reviewed training and policy guidance into one compliance workspace.
- Syntrio Action Center · enterprise desktop web application
- Product Designer · concept and prototype contributor
- Working users: compliance managers, incident managers, training administrators, and policy stakeholders
- Scope: incident oversight, trends, recommendations, recent activity, and preventive-action framing
Only the Action Center dashboard is shown publicly. Detailed incident-management, training, policy, permissions, and administrative workflows remain internal and confidential.
01
Project at a glance
Exploring a connected starting point for compliance operations
- Product
- Syntrio Action Center
- Company
- Mitratech
- Role
- Product Designer · concept and prototype contributor
- Primary user
- Compliance or Ethics Programme Manager
- Scope
- Incident oversight, trends, recommendations, recent activity, and preventive-action concept
- Public evidence
- One high-fidelity desktop Action Center design shown through full views and crops
- Status
- Concept and prototype proposal; not implemented or released
- Confidentiality
- Related product workflows are discussed at system level but not shown
Evidence boundary
The historical evidence supports the dashboard concept and proposal. The business framing, working user model, responsible-AI principles, critique, and validation plan are retrospective product work created to explain how the concept could operate as a complete enterprise experience.
02
Product opportunity
Incident data showed what had happened—but not always what the organisation should do next
Compliance teams could capture and investigate workplace incidents, but the broader work of prevention could remain split across case management, reporting, employee training, and policy-management processes.
A compliance manager who noticed a recurring concern might need to export incident information, analyse patterns outside the product, identify the affected audience, locate relevant training, contact the appropriate policy owner, and document why the intervention was initiated.
The Action Center concept explored a more connected journey from detection to prevention: one workspace for current incident operations, organisational signals, and relevant preventive guidance.
Design challenge
How might we help compliance managers move from reactive incident monitoring to timely, evidence-based preventive action while protecting sensitive report data and keeping every recommendation under human control?
Manual interpretation
Patterns could require exports and analysis outside the product before a response was coordinated.
Connected-platform opportunity
A unified feedback loop could connect detected concerns with relevant training and policy action.
03
Working user model
One compliance signal, several professional responsibilities
These are responsibility-based role profiles developed for the concept. They are not presented as personas derived from completed interviews.
Compliance Programme Manager
Reviews the backlog, identifies patterns, and coordinates authorised preventive action.
Case Owner or Investigator
Finds assigned work, understands urgency and deadlines, and continues case follow-up.
Training Administrator
Reviews approved learning content, confirms the audience, and coordinates assignment.
Policy Owner, Legal, or HR
Reviews whether existing guidance should be clarified, updated, or communicated differently.
Compliance Leader
Reviews permitted trends, unresolved risk, action ownership, and programme response.
Primary job to be done
“When I review incident activity, I need to identify what requires immediate attention and whether broader patterns justify preventive action, so I can coordinate the right response without exporting sensitive data or switching between disconnected systems.”
04
Product model
Connect the organisational signal to a responsible human decision
The Action Center was most valuable when it connected what the system observed to the next authorised decision—not when it simply displayed more metrics.
Incident reports
Permitted case and programme data
Aggregated signals
Patterns within an authorised scope
Trend or exception
Context requiring review
Suggested guidance
Approved training or policy resource
Human review
Accept, modify, dismiss, or escalate
Preventive action
Owner, scope, and due date
Audit and monitoring
Track decision, status, and future signals
Dashboard anatomy
One workspace organised into four information layers
Each crop below comes from the same original Action Center dashboard—not a separate product screen.
Overview
Summary cards provided a quick view of volume, overdue work, high-risk cases, and resolution time.
- Current workload
- Attention signals
- Operational measures
Organisational context
Filters and charts helped users examine changes by period, division, and incident category.
- Time period
- Scope filters
- Trend and category views
Operational follow-up
The incident queue linked summary information to case number, risk, priority, status, and owner.
- Active records
- Ownership
- Case actions
Preventive guidance
Training, policy, and activity panels connected case signals to broader programme response.
- Suggested training
- Potential policy reviews
- Recent organisational activity
05
Design decisions
Four decisions shaped the product proposition
01
Connected compliance
Bring reactive and preventive work into one starting point
Incident management explained what had been reported. Training and policy management supported broader prevention. The concept connected both sides so users could move from awareness to the appropriate next decision.
- Product question
- How can a signal from current case work support an organisation-level response?
- Design response
- Combine current workload, historical context, ownership, and preventive guidance in one Action Center.
- Trade-off
- A broad dashboard risks overload, so immediate operational work and supporting analysis need a clear hierarchy.
02
Data semantics
Separate current operational snapshots from historical reporting
The original screen combines a six-month filter, a 30-day report count, month-over-month changes, current overdue incidents, current high-risk incidents, and average resolution time.
- Period-based reporting
- New reports, resolved cases, trends, and resolution-time measures for a defined date range.
- Current-state snapshots
- Active overdue, high-risk, unassigned, or review-needed incidents as of a stated time.
- Why it matters
- Changing a reporting period should never hide an older unresolved incident from the active backlog.
What I would refine before validation
Show exact date ranges, last-updated time, metric definitions, comparison basis, and a direct drill-down to the matching records.
03
Operational clarity
Keep risk, priority, status, and ownership distinct
These fields answer different questions during triage. Combining them into one generic severity indicator would weaken accountability and make sorting less meaningful.
- Risk: potential significance or exposure
- Priority: operational urgency
- Status: current workflow stage
- Owner: person responsible for the next authorised action
These definitions are the conceptual model used to critique the design; the original product rules and permission model were not recovered.
04
Human-reviewed guidance
Keep recommendations explainable, advisory, and under human control
The dashboard included AI-labelled training and policy suggestions, but it did not visibly explain their basis, source, time period, affected audience, or available user action.
- Recommendation anatomy
- Resource, affected scope, “Why suggested,” aggregate signal, data period, owner, version, and review state.
- User controls
- Review evidence, accept, modify, dismiss, mark as addressed, assign an owner, and give relevance feedback.
- Critical guardrail
- A suggestion must not determine fault, change case risk automatically, close an incident, assign mandatory training, or update a policy without authorised review.
06
Responsible product model
AI could surface relevance—but responsibility remained with people
The original screen used an AI label, but the proposal did not progress far enough to establish a production AI architecture.
A credible first version would begin with transparent mappings between approved incident categories and approved learning or policy content. AI could then be evaluated as an extension for ranking, pattern summarisation, semantic retrieval, and plain-language explanation.
The choice to introduce AI should follow a demonstrated relevance problem—not the presence of an “AI-powered” heading.
Permitted aggregate signal
Approved content source
Why suggested
Human review
Accept, modify, or dismiss
Owner and audit record
Explainability
Show why a suggestion appeared, the scope it relates to, and which approved source it uses.
Privacy
Prefer aggregates, minimise data, protect reporter identity, and suppress signals that could expose individuals.
Human control
No training, policy, risk, or case decision should be executed automatically.
Permissions
Cards, charts, search, recommendations, exports, and drill-downs must share one access boundary.
Auditability
Record the signal, recommendation version, reviewer, decision, modification, owner, and resulting action.
07
Critical design review
What I would refine before putting the concept in front of users
Resolve contradictions and consequential actions
- Keep closed cases out of the default “Open Incident Reports” queue, or rename the view.
- Separate current snapshots from historical reporting and define every comparison period.
- Add due date or days overdue so the overdue summary is actionable.
- Move delete or archive into a permission-aware menu with confirmation, reason capture, and audit history.
- Explain recommendation basis, source, scope, and human-review responsibility.
Make daily work easier to interpret
- Clarify what “All Roles” filters and ensure filters never change permissions.
- Reveal bulk actions only after selection and make the selection scope explicit.
- Correct the page-size and result-range mismatch.
- Add explicit values and an accessible data view to category analysis.
- Sort activity newest first and use one case-identifier format.
- Use neutral treatment for increased report volume; more reports are not automatically positive.
- Give navigation sections distinct icons and clearer grouping.
Enterprise states
The dashboard also needed to explain when information was absent, stale, restricted, or incomplete
Loading and refresh
Preserve page structure, identify the areas still loading, and show last successful update.
No active work
Distinguish a healthy empty queue from no matching results or unavailable data.
Restricted access
Explain the available next step without revealing that a restricted record exists.
Partial failure
Isolate failed widgets, retain clearly labelled safe data where appropriate, and provide Retry.
08
Retrospective validation plan
Test whether users can move from signal to responsible action
Representative tasks
Observe behaviour before asking for opinions
- Identify the most urgent overdue incident and its owner
- Explain risk, priority, status, and the selected reporting period
- Change organisational scope without assuming access has changed
- Review why training or a policy resource was suggested
- Decide whether to accept, modify, dismiss, or escalate the suggestion
- Find the actor, rationale, owner, and audit record for the decision
Prioritisation
Correct record selected, urgent items missed, assistance required, and time to locate relevant work.
Data comprehension
Correct period interpretation, risk versus priority understanding, and filter-scope comprehension.
Recommendation comprehension
Can explain why it appeared, identify the audience, recognise human responsibility, and choose a next action.
Accessible operation
Keyboard completion, visible focus, table and chart comprehension, meaning beyond colour, and assistive-technology findings.
This validation plan was not executed during the original concept phase. Numeric targets would be set only after establishing a baseline with representative users.
09
Design outcome and boundaries
A strategic product concept—not a shipped AI system
What existed
- Syntrio Action Center concept
- High-fidelity desktop dashboard
- Incident summary and trend views
- Incident queue and recent activity
- Training and policy recommendation concept
- Internal prototype and proposal
What did not occur
- Product implementation or production release
- Live AI functionality
- Verified product integrations
- Formal user research or usability testing
- Pilot, adoption, or business measurement
- AI-performance evaluation
What the project demonstrates
- Strategic product-opportunity framing
- Enterprise dashboard and information hierarchy
- Reactive-to-preventive compliance thinking
- Human-in-the-loop AI principles
- Privacy, permissions, and audit awareness
- Critical evaluation and validation planning
Public presentation boundary
The product image shown throughout this case study is the same original Action Center dashboard at different scroll positions and crops. Related internal workflows are intentionally discussed without showing confidential product screens or recreating them as if they were historical deliverables.
10
Reflection
What this concept reinforced for me
Insight must lead to action
A dashboard creates value when a user can understand the signal, open the underlying work, and take an authorised next step.
Time models need explicit rules
Current backlog, overdue work, historical submissions, and resolved-case measures should never be mixed silently.
AI needs evidence and boundaries
The recommendation matters less than whether the user understands why it appeared and what responsibility remains with them.
Privacy shapes the experience
Access, aggregation, anonymity, audit history, and accountability are core interaction requirements in ethics and compliance products.
Strongest next step
Validate the product model before investing in recommendation technology
- Confirm the compliance manager’s real prioritisation workflow
- Define the safe data and permission model
- Establish a transparent rules-based relevance baseline
- Test whether AI improves relevance, explanation, or retrieval beyond that baseline