Enterprise Safety Platform
Deep Defense Solutions (DDS) is a community safety platform that enables organisations to receive, assess, and act on incident reports efficiently and responsibly.
Role
Product Design (UX/UI) Intern
Duration
3 month internship
Problem statement
Organisations need to handle safety incidents quickly and clearly, but most existing tools are either generic ticketing systems or built for government use. They are not designed for real-time incident management in enterprise settings, which leads to slow responses, confusion, and higher risk.
Users
The primary users of the DDS enterprise platform are organisation representatives responsible for receiving, assessing, and responding to safety incidents. These users operate in time-sensitive, high-risk environments and need clear information, fast decision-making, and strong accountability.
Constraints
-
High-risk context:
Safety incidents require accuracy and clarity; mistakes have real consequences
-
Complex workflows:
Incidents involve multiple states, roles, and escalation paths
-
Cognitive load:
Users often review incidents under time pressure and stress
-
Early-stage platform:
Features needed to be scoped carefully to support future growth without overbuilding
-
Data sensitivity and access control
Not every user should see everything. This affects visibility, permissions, and what information is shown by default.
Approach
I started by mapping the full incident lifecycle from intake to resolution to understand where decisions, handoffs, and risk occurred. This helped identify the critical moments that required clarity and speed for organisation representatives.
Round 1: Early iteration
Goal: Understand the incident lifecycle and identify critical touchpoints for triage.
These early-stage flows reflect the initial thinking used to understand the incident lifecycle. Later iterations were refined and expanded, but are omitted here for confidentiality.
Incident report
Notes:
how do we determine false reports?
flesh out AI & Rules engine- that’ll help us determine how to seperate and assign different threat levels
Ticket management flow
Notes:
how do we ensure that the “valid and actionable” step is actually accurate? we might need to include human review in each stage
Knowledge base flow
Notes:
leverage the knowledge base to allow user to make the best decision based on their scenario
knowledge base can also identify trends
once someone submits a ticket, how does this system provide the user with the best response to this scenario?
AI Data Ingestion
Notes:
this is backend related. let’s leave it
Round 2: Refined Flows
Goal: Address ambiguity from Round 1 and test simplified triage vs. resolution stages.
These early-stage flows reflect the initial thinking used to understand the incident lifecycle. Later iterations were refined and expanded, but are omitted here for confidentiality.
Incident report
Ticket management flow
Knowledge base flow
Round 3: Final Refined Flows
Goal: Fleshed out weak points Round 2 and got workflows ready to pitch to stakeholders
These early-stage flows reflect the initial thinking used to understand the incident lifecycle. Later iterations were refined and expanded, but are omitted here for confidentiality.
Incident report
Notes:
we added “human reviews” within the steps we believe needed them.
our thought process: the more human review we have the less likely there was an error
Ticket management flow
Notes:
Defined a criteria/history within the ticket management system
what rules makes a person a valid threat? do they have a history? did they do certain things to raise suspiscion?
this was our reason to create a criteria
Knowledge base flow
Notes:
we fleshed out the the “best steps” feature. we want the knowledge base flow to be a place to get useful info.
we really want the knowledge flow to also be able to identify the users situation and give them “recommended/ next steps”
Top 3 design decisions
-
#1
Broke incidents into clear stages
instead of one long process
-
#2
Prioritised status and severity over detailed information
-
#3
Separated initial assessment from resolution to support faster decisions
Internship Learnings
-
#1
Early structure prevents confusion and rework later
-
#2
Within enterprise environments, simpler flows lead to better decisions under pressure
this also applies to all other designs not just enterprise environments -
#3
Enterprise users value clarity and consistency instead of novelty
-
#4
Design decisions need to account for real operational risk.
we are creating a product for the safety of people so this is super important
-
#5
Iteration is about removing complexity, not adding features.
good design is simple and minimal it also gets the point across -
#6
Clear workflows matter more than polished UI in high-risk systems
good and efficient design starts with solid foundations
Conclusion