CMS ACTIVITY
TRACKER
CMS ACTIVITY
CMS ACTIVITY
TRACKER
TRACKER
Designing an internal audit log dashboard for HashtagCMS
to track who changed what, when, and where
Designing an internal audit log dashboard for HashtagCMS
to track who changed what, when, and where
Designing an internal audit log dashboard for HashtagCMS
to track who changed what, when, and where
project overview
project overview
project overview
An internal CMS logs dashboard to track who changed what, when, and where—built to cut debugging time and bring clarity and accountability for product, marketing, and engineering teams.
An internal CMS logs dashboard to track who changed what, when, and where—built to cut debugging time and bring clarity and accountability for product, marketing, and engineering teams.
An internal CMS logs dashboard to track who changed what, when, and where—built to cut debugging time and bring clarity and accountability for product, marketing, and engineering teams.
problem statement
CMS changes directly impact the live app, but when multiple teams had access, it was hard to trace edits and establish ownership during incidents.
To reduce risk, access was restricted to a small group of CMS owners—creating a single point of dependency and shifting operational load onto 2–3 people alongside their core engineering work.
We needed a clear activity trail showing who changed what, when, and where, so troubleshooting is faster, accountability is clear, and access can scale safely without increasing production risk
1.
Low change traceability
2.
Direct production impact
3.
Access restriction created bottlenecks
4.
Operational overload
5.
Slow incident resolution
6.
Limited safe scaling
1.
Low change traceability
2.
Direct production impact
3.
Access restriction created bottlenecks
4.
Operational overload
5.
Slow incident resolution
6.
Limited safe scaling
1.
Low change traceability
2.
Direct production impact
3.
Access restriction created bottlenecks
4.
Operational overload
5.
Slow incident resolution
6.
Limited safe scaling
proposed
Solution
I designed, implemented, and deployed an internal CMS Activity Tracker dashboard that provides a reliable audit trail of CMS changes. It records who made a change, what was changed, when it happened, and where it occurred across modules—so issues can be traced quickly and ownership stays clear.
The solution reduces debugging time and enables safer scaling of CMS access.
Centralized activity log capturing all CMS changes across modules
Clear audit trail showing who changed what, when, and where
Advanced filtering by user, module, action type, and time range
Detailed change view to inspect updates and understand impact
Built and deployed end-to-end with validation and senior review
user research
It was done through quick interviews and workflow walkthroughs with internal CMS users across Product, Marketing, QA, and Engineering. The insights highlighted gaps in traceability and ownership during incidents, shaping a dashboard focused on speed, accountability, and audit visibility.
results found
results found
results found
Research revealed that most production delays were not caused by fixing issues, but by identifying what changed and who made the change. Limited access reduced risk but created operational bottlenecks, while broader access increased risk without accountability. Teams needed a faster, more reliable way to trace changes without depending on a few CMS owners.
Finding what changed took longer than fixing the issue.
Research revealed that most production delays were not caused by fixing issues, but by identifying what changed and who made the change. Limited access reduced risk but created operational bottlenecks, while broader access increased risk without accountability. Teams needed a faster, more reliable way to trace changes without depending on a few CMS owners.
Finding what changed took longer than fixing the issue.
Research revealed that most production delays were not caused by fixing issues, but by identifying what changed and who made the change. Limited access reduced risk but created operational bottlenecks, while broader access increased risk without accountability. Teams needed a faster, more reliable way to trace changes without depending on a few CMS owners.
Finding what changed took longer than fixing the issue.
user
user
user
persona
persona
persona
Aditi
Aditi frequently updates banners, offers, and content through the CMS to support business and marketing needs. Many changes are time-sensitive and need to go live quickly, often without technical validation.
Age: 28
ROLE : Product Manager
Aditi
Aditi frequently updates banners, offers, and content through the CMS to support business and marketing needs. Many changes are time-sensitive and need to go live quickly, often without technical validation.
Age: 28
ROLE : Product Manager
Aditi
Aditi frequently updates banners, offers, and content through the CMS to support business and marketing needs. Many changes are time-sensitive and need to go live quickly, often without technical validation.
Age: 28
ROLE : Product Manager
Goals
Goals
Goals
Push content changes quickly to meet business deadlines
Update offers, banners, and configurations without engineering dependency
Ensure changes reflect correctly on the live app
Push content changes quickly to meet business deadlines
Update offers, banners, and configurations without engineering dependency
Ensure changes reflect correctly on the live app
Push content changes quickly to meet business deadlines
Update offers, banners, and configurations without engineering dependency
Ensure changes reflect correctly on the live app
Behaviors
Behaviors
Behaviors
Makes frequent CMS updates, sometimes under time pressure
Relies on trial-and-error when changes don’t behave as expected
Assumes issues will be handled by engineering later
Makes frequent CMS updates, sometimes under time pressure
Relies on trial-and-error when changes don’t behave as expected
Assumes issues will be handled by engineering later
Makes frequent CMS updates, sometimes under time pressure
Relies on trial-and-error when changes don’t behave as expected
Assumes issues will be handled by engineering later
Frustrations
Frustrations
Frustrations
No visibility into which changes may have caused issues
Changes made under urgency sometimes lead to production incidents
Difficult to trace ownership when multiple teams access CMS
No visibility into which changes may have caused issues
Changes made under urgency sometimes lead to production incidents
Difficult to trace ownership when multiple teams access CMS
No visibility into which changes may have caused issues
Changes made under urgency sometimes lead to production incidents
Difficult to trace ownership when multiple teams access CMS
Needs
Needs
Needs
Clear visibility into what was changed and by whom
Confidence that changes can be audited and reverted if needed
Reduced risk while making fast updates
Clear visibility into what was changed and by whom
Confidence that changes can be audited and reverted if needed
Reduced risk while making fast updates
Clear visibility into what was changed and by whom
Confidence that changes can be audited and reverted if needed
Reduced risk while making fast updates
Rahul
Rahul is responsible for maintaining app stability. When production issues occur without a new release, he often investigates CMS data to identify what caused the problem.
Age: 25
ROLE : Software Engineer
Rahul
Rahul is responsible for maintaining app stability. When production issues occur without a new release, he often investigates CMS data to identify what caused the problem.
Age: 25
ROLE : Software Engineer
Goals
Quickly identify the root cause of production issues
Understand recent CMS changes without guesswork
Reduce debugging time during incidents
Behaviors
Manually checks CMS data and compares timestamps
Cross-checks with multiple teams to identify recent changes
Spends significant time during incidents investigating “what changed”
Frustrations
No clear record of what changed in the CMS Difficult to correlate
CMS updates with app crashes
Debugging takes longer than fixing the actual issue
Needs
Clear visibility into what was changed and by whom
Confidence that changes can be audited and reverted if needed
Reduced risk while making fast updates
Rahul
Rahul is responsible for maintaining app stability. When production issues occur without a new release, he often investigates CMS data to identify what caused the problem.
Age: 25
ROLE : Software Engineer
Rahul
Rahul is responsible for maintaining app stability. When production issues occur without a new release, he often investigates CMS data to identify what caused the problem.
Age: 25
ROLE : Software Engineer
Rahul
Rahul is responsible for maintaining app stability. When production issues occur without a new release, he often investigates CMS data to identify what caused the problem.
Age: 25
ROLE : Software Engineer
Goals
Goals
Quickly identify the root cause of production issues
Understand recent CMS changes without guesswork
Reduce debugging time during incidents
Quickly identify the root cause of production issues
Understand recent CMS changes without guesswork
Reduce debugging time during incidents
Behaviors
Behaviors
Manually checks CMS data and compares timestamps
Cross-checks with multiple teams to identify recent changes
Spends significant time during incidents investigating “what changed”
Manually checks CMS data and compares timestamps
Cross-checks with multiple teams to identify recent changes
Spends significant time during incidents investigating “what changed”
Frustrations
Frustrations
No clear record of what changed in the CMS
Difficult to correlate CMS updates with app crashes
Debugging takes longer than fixing the actual issue
No clear record of what changed in the CMS
Difficult to correlate CMS updates with app crashes
Debugging takes longer than fixing the actual issue
Needs
Needs
Manually checks CMS data and compares timestamps
Cross-checks with multiple teams to identify recent changes
Spends significant time during incidents investigating “what changed”
Manually checks CMS data and compares timestamps
Cross-checks with multiple teams to identify recent changes
Spends significant time during incidents investigating “what changed”
empathy map
empathy map
empathy map
This empathy map captures the shared experience of engineers and CMS owners during production incidents. A lack of visibility into CMS changes created stress, delayed debugging, and dependency on a few individuals. These insights reinforced the need for a transparent, reliable activity tracker that enables faster investigation and clear accountability.
Our process at Epic combines creativity with strategy
Our process at Epic combines creativity with strategy, starting with understanding your goals and moving through careful planning
and innovative design.
Thinking
Something changed in production, but there was no release.
Is this a CMS update or a backend issue?
Who touched this module last?
Why is debugging harder than fixing the issue?
Thinking
Something changed in production, but there was no release.
Is this a CMS update or a backend issue?
Who touched this module last?
Why is debugging harder than fixing the issue?
Thinking
Something changed in production, but there was no release.
Is this a CMS update or a backend issue?
Who touched this module last?
Why is debugging harder than fixing the issue?
Hearing
Marketing pushed an urgent CMS update.
The app is behaving unexpectedly after a content change.
Nothing new was deployed — must be CMS.
Can someone check what changed?
Hearing
Marketing pushed an urgent CMS update.
The app is behaving unexpectedly after a content change.
Nothing new was deployed — must be CMS.
Can someone check what changed?
Hearing
Marketing pushed an urgent CMS update.
The app is behaving unexpectedly after a content change.
Nothing new was deployed — must be CMS.
Can someone check what changed?
Pains
No clear visibility into CMS changes
Difficult to correlate CMS updates with production issues
Debugging takes longer due to missing ownership data
Dependency on a few CMS owners for every investigation
High stress during incidents without clear answers
Pains
No clear visibility into CMS changes
Difficult to correlate CMS updates with production issues
Debugging takes longer due to missing ownership data
Dependency on a few CMS owners for every investigation
High stress during incidents without clear answers
Pains
No clear visibility into CMS changes
Difficult to correlate CMS updates with production issues
Debugging takes longer due to missing ownership data
Dependency on a few CMS owners for every investigation
High stress during incidents without clear answers
Gains
Clear log of who changed what, when, and where
Faster root-cause identification during incidents
Reduced back-and-forth between teams
Confidence to scale CMS access safely
Less off-hours debugging and firefighting
Gains
Clear log of who changed what, when, and where
Faster root-cause identification during incidents
Reduced back-and-forth between teams
Confidence to scale CMS access safely
Less off-hours debugging and firefighting
Gains
Clear log of who changed what, when, and where
Faster root-cause identification during incidents
Reduced back-and-forth between teams
Confidence to scale CMS access safely
Less off-hours debugging and firefighting
Saying & Doing
Checking CMS data manually to trace changes
Asking multiple teams what was updated
Cross-verifying timestamps and modules
Spending time investigating instead of resolving
Saying & Doing
Checking CMS data manually to trace changes
Asking multiple teams what was updated
Cross-verifying timestamps and modules
Spending time investigating instead of resolving
Saying & Doing
Checking CMS data manually to trace changes
Asking multiple teams what was updated
Cross-verifying timestamps and modules
Spending time investigating instead of resolving
information architecture
information architecture
information architecture
This Information Architecture
WAS designed to support
fast investigation,
clear ownership, and
safer scaling of CMS access.
Epic is a creative agency fueled by a future and excellence.
flow chart
flow chart
flow chart
&
&
&
user flow
user flow
user flow
Wireframes
Wireframes
Wireframes
&
&
&
Prototyping
Prototyping
Prototyping
started with quick hand-drawn wireframes
to mirror how teams actually
investigate CMS-driven incidents—filters first,
then key insights, ranked views, and
finally deep-dive logs.
It helped me validate
the hierarchy early and move into
Figma + development with speed and confidence.
Epic is a creative agency fueled by a future and excellence.
low fidelity
low fidelity
low fidelity
After mapping user needs and incident workflows in detail, I translated those early ideas into structured low-fidelity wireframes. This version focuses on clarity, hierarchy, and speed — enabling teams to move from high-level signals to detailed logs without friction.
Epic is a creative agency fueled by a future and excellence.
user interface
user interface
user interface
A high-fidelity UI for an internal CMS Activity Tracker—built to make incident debugging faster
by surfacing who changed what, when, and where in a single view.
Our process at Epic combines creativity with strategy
Our process at Epic combines creativity with strategy, starting with understanding your goals and moving through careful planning
and innovative design.
This view gives teams an instant snapshot of CMS activity—filters, key insight cards, ranked views, and a live timeline—so the “what changed?” question is answered before diving into logs
Our process at Epic combines creativity with strategy
Our process at Epic combines creativity with strategy, starting with understanding your goals and moving through careful planning
and innovative design.
Once an entry looks suspicious, the drill-down panel shows full context—who, when, module, action, exact query, and before-vs-after state—making RCA and audits fast and reliable.
Our process at Epic combines creativity with strategy
Our process at Epic combines creativity with strategy, starting with understanding your goals and moving through careful planning
and innovative design.
CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard- CMS Activity Tracker Dashboard
CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard- CMS Activity Tracker Dashboard
CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard- CMS Activity Tracker Dashboard
what i learnt
YOUR start
what i learnt
I learned that internal dashboards must prioritize speed, clarity, and trust—especially during incidents.
I also learned that reliable UX starts with clean, structured logs and guardrails that prevent mistakes.
Most importantly, I learned to design for real workflows and edge cases through close collaboration with Product, QA, and Engineering.
MEMORABLE & CAPTIVATING DIGITAL — EXPERIENCES.
MEMORABLE & CAPTIVATING DIGITAL — EXPERIENCES THAT DELIVER, Partnering WITh visionaries PEOPLe & trailblazers TO innovate.
CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard- CMS Activity Tracker Dashboard
CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard- CMS Activity Tracker Dashboard
CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard- CMS Activity Tracker Dashboard
CMS ACTIVITY
TRACKER
CMS ACTIVITY
CMS ACTIVITY
TRACKER
TRACKER
Designing an internal audit log dashboard for HashtagCMS
to track who changed what, when, and where
Designing an internal audit log dashboard for HashtagCMS
to track who changed what, when, and where
Designing an internal audit log dashboard for HashtagCMS
to track who changed what, when, and where
project overview
project overview
project overview
An internal CMS logs dashboard to track who changed what, when, and where—built to cut debugging time and bring clarity and accountability for product, marketing, and engineering teams.
An internal CMS logs dashboard to track who changed what, when, and where—built to cut debugging time and bring clarity and accountability for product, marketing, and engineering teams.
An internal CMS logs dashboard to track who changed what, when, and where—built to cut debugging time and bring clarity and accountability for product, marketing, and engineering teams.
problem statement
CMS changes directly impact the live app, but when multiple teams had access, it was hard to trace edits and establish ownership during incidents.
To reduce risk, access was restricted to a small group of CMS owners—creating a single point of dependency and shifting operational load onto 2–3 people alongside their core engineering work.
We needed a clear activity trail showing who changed what, when, and where, so troubleshooting is faster, accountability is clear, and access can scale safely without increasing production risk
1.
Low change traceability
2.
Direct production impact
3.
Access restriction created bottlenecks
4.
Operational overload
5.
Slow incident resolution
6.
Limited safe scaling
1.
Low change traceability
2.
Direct production impact
3.
Access restriction created bottlenecks
4.
Operational overload
5.
Slow incident resolution
6.
Limited safe scaling
1.
Low change traceability
2.
Direct production impact
3.
Access restriction created bottlenecks
4.
Operational overload
5.
Slow incident resolution
6.
Limited safe scaling
proposed
Solution
I designed, implemented, and deployed an internal CMS Activity Tracker dashboard that provides a reliable audit trail of CMS changes. It records who made a change, what was changed, when it happened, and where it occurred across modules—so issues can be traced quickly and ownership stays clear.
The solution reduces debugging time and enables safer scaling of CMS access.
Centralized activity log capturing all CMS changes across modules
Clear audit trail showing who changed what, when, and where
Advanced filtering by user, module, action type, and time range
Detailed change view to inspect updates and understand impact
Built and deployed end-to-end with validation and senior review
user research
It was done through quick interviews and workflow walkthroughs with internal CMS users across Product, Marketing, QA, and Engineering. The insights highlighted gaps in traceability and ownership during incidents, shaping a dashboard focused on speed, accountability, and audit visibility.
results found
results found
results found
Research revealed that most production delays were not caused by fixing issues, but by identifying what changed and who made the change. Limited access reduced risk but created operational bottlenecks, while broader access increased risk without accountability. Teams needed a faster, more reliable way to trace changes without depending on a few CMS owners.
Finding what changed took longer than fixing the issue.
Research revealed that most production delays were not caused by fixing issues, but by identifying what changed and who made the change. Limited access reduced risk but created operational bottlenecks, while broader access increased risk without accountability. Teams needed a faster, more reliable way to trace changes without depending on a few CMS owners.
Finding what changed took longer than fixing the issue.
Research revealed that most production delays were not caused by fixing issues, but by identifying what changed and who made the change. Limited access reduced risk but created operational bottlenecks, while broader access increased risk without accountability. Teams needed a faster, more reliable way to trace changes without depending on a few CMS owners.
Finding what changed took longer than fixing the issue.
user
user
user
persona
persona
persona
Aditi
Aditi frequently updates banners, offers, and content through the CMS to support business and marketing needs. Many changes are time-sensitive and need to go live quickly, often without technical validation.
Age: 28
ROLE : Product Manager
Aditi
Aditi frequently updates banners, offers, and content through the CMS to support business and marketing needs. Many changes are time-sensitive and need to go live quickly, often without technical validation.
Age: 28
ROLE : Product Manager
Aditi
Aditi frequently updates banners, offers, and content through the CMS to support business and marketing needs. Many changes are time-sensitive and need to go live quickly, often without technical validation.
Age: 28
ROLE : Product Manager
Goals
Goals
Goals
Push content changes quickly to meet business deadlines
Update offers, banners, and configurations without engineering dependency
Ensure changes reflect correctly on the live app
Push content changes quickly to meet business deadlines
Update offers, banners, and configurations without engineering dependency
Ensure changes reflect correctly on the live app
Push content changes quickly to meet business deadlines
Update offers, banners, and configurations without engineering dependency
Ensure changes reflect correctly on the live app
Behaviors
Behaviors
Behaviors
Makes frequent CMS updates, sometimes under time pressure
Relies on trial-and-error when changes don’t behave as expected
Assumes issues will be handled by engineering later
Makes frequent CMS updates, sometimes under time pressure
Relies on trial-and-error when changes don’t behave as expected
Assumes issues will be handled by engineering later
Makes frequent CMS updates, sometimes under time pressure
Relies on trial-and-error when changes don’t behave as expected
Assumes issues will be handled by engineering later
Frustrations
Frustrations
Frustrations
No visibility into which changes may have caused issues
Changes made under urgency sometimes lead to production incidents
Difficult to trace ownership when multiple teams access CMS
No visibility into which changes may have caused issues
Changes made under urgency sometimes lead to production incidents
Difficult to trace ownership when multiple teams access CMS
No visibility into which changes may have caused issues
Changes made under urgency sometimes lead to production incidents
Difficult to trace ownership when multiple teams access CMS
Needs
Needs
Needs
Clear visibility into what was changed and by whom
Confidence that changes can be audited and reverted if needed
Reduced risk while making fast updates
Clear visibility into what was changed and by whom
Confidence that changes can be audited and reverted if needed
Reduced risk while making fast updates
Clear visibility into what was changed and by whom
Confidence that changes can be audited and reverted if needed
Reduced risk while making fast updates
Rahul
Rahul is responsible for maintaining app stability. When production issues occur without a new release, he often investigates CMS data to identify what caused the problem.
Age: 25
ROLE : Software Engineer
Rahul
Rahul is responsible for maintaining app stability. When production issues occur without a new release, he often investigates CMS data to identify what caused the problem.
Age: 25
ROLE : Software Engineer
Goals
Quickly identify the root cause of production issues
Understand recent CMS changes without guesswork
Reduce debugging time during incidents
Behaviors
Manually checks CMS data and compares timestamps
Cross-checks with multiple teams to identify recent changes
Spends significant time during incidents investigating “what changed”
Frustrations
No clear record of what changed in the CMS Difficult to correlate
CMS updates with app crashes
Debugging takes longer than fixing the actual issue
Needs
Clear visibility into what was changed and by whom
Confidence that changes can be audited and reverted if needed
Reduced risk while making fast updates
Rahul
Rahul is responsible for maintaining app stability. When production issues occur without a new release, he often investigates CMS data to identify what caused the problem.
Age: 25
ROLE : Software Engineer
Rahul
Rahul is responsible for maintaining app stability. When production issues occur without a new release, he often investigates CMS data to identify what caused the problem.
Age: 25
ROLE : Software Engineer
Rahul
Rahul is responsible for maintaining app stability. When production issues occur without a new release, he often investigates CMS data to identify what caused the problem.
Age: 25
ROLE : Software Engineer
Goals
Goals
Quickly identify the root cause of production issues
Understand recent CMS changes without guesswork
Reduce debugging time during incidents
Quickly identify the root cause of production issues
Understand recent CMS changes without guesswork
Reduce debugging time during incidents
Behaviors
Behaviors
Manually checks CMS data and compares timestamps
Cross-checks with multiple teams to identify recent changes
Spends significant time during incidents investigating “what changed”
Manually checks CMS data and compares timestamps
Cross-checks with multiple teams to identify recent changes
Spends significant time during incidents investigating “what changed”
Frustrations
Frustrations
No clear record of what changed in the CMS
Difficult to correlate CMS updates with app crashes
Debugging takes longer than fixing the actual issue
No clear record of what changed in the CMS
Difficult to correlate CMS updates with app crashes
Debugging takes longer than fixing the actual issue
Needs
Needs
Manually checks CMS data and compares timestamps
Cross-checks with multiple teams to identify recent changes
Spends significant time during incidents investigating “what changed”
Manually checks CMS data and compares timestamps
Cross-checks with multiple teams to identify recent changes
Spends significant time during incidents investigating “what changed”
empathy map
empathy map
empathy map
This empathy map captures the shared experience of engineers and CMS owners during production incidents. A lack of visibility into CMS changes created stress, delayed debugging, and dependency on a few individuals. These insights reinforced the need for a transparent, reliable activity tracker that enables faster investigation and clear accountability.
Our process at Epic combines creativity with strategy
Our process at Epic combines creativity with strategy, starting with understanding your goals and moving through careful planning
and innovative design.
Thinking
Something changed in production, but there was no release.
Is this a CMS update or a backend issue?
Who touched this module last?
Why is debugging harder than fixing the issue?
Thinking
Something changed in production, but there was no release.
Is this a CMS update or a backend issue?
Who touched this module last?
Why is debugging harder than fixing the issue?
Thinking
Something changed in production, but there was no release.
Is this a CMS update or a backend issue?
Who touched this module last?
Why is debugging harder than fixing the issue?
Hearing
Marketing pushed an urgent CMS update.
The app is behaving unexpectedly after a content change.
Nothing new was deployed — must be CMS.
Can someone check what changed?
Hearing
Marketing pushed an urgent CMS update.
The app is behaving unexpectedly after a content change.
Nothing new was deployed — must be CMS.
Can someone check what changed?
Hearing
Marketing pushed an urgent CMS update.
The app is behaving unexpectedly after a content change.
Nothing new was deployed — must be CMS.
Can someone check what changed?
Pains
No clear visibility into CMS changes
Difficult to correlate CMS updates with production issues
Debugging takes longer due to missing ownership data
Dependency on a few CMS owners for every investigation
High stress during incidents without clear answers
Pains
No clear visibility into CMS changes
Difficult to correlate CMS updates with production issues
Debugging takes longer due to missing ownership data
Dependency on a few CMS owners for every investigation
High stress during incidents without clear answers
Pains
No clear visibility into CMS changes
Difficult to correlate CMS updates with production issues
Debugging takes longer due to missing ownership data
Dependency on a few CMS owners for every investigation
High stress during incidents without clear answers
Gains
Clear log of who changed what, when, and where
Faster root-cause identification during incidents
Reduced back-and-forth between teams
Confidence to scale CMS access safely
Less off-hours debugging and firefighting
Gains
Clear log of who changed what, when, and where
Faster root-cause identification during incidents
Reduced back-and-forth between teams
Confidence to scale CMS access safely
Less off-hours debugging and firefighting
Gains
Clear log of who changed what, when, and where
Faster root-cause identification during incidents
Reduced back-and-forth between teams
Confidence to scale CMS access safely
Less off-hours debugging and firefighting
Saying & Doing
Checking CMS data manually to trace changes
Asking multiple teams what was updated
Cross-verifying timestamps and modules
Spending time investigating instead of resolving
Saying & Doing
Checking CMS data manually to trace changes
Asking multiple teams what was updated
Cross-verifying timestamps and modules
Spending time investigating instead of resolving
Saying & Doing
Checking CMS data manually to trace changes
Asking multiple teams what was updated
Cross-verifying timestamps and modules
Spending time investigating instead of resolving
information architecture
information architecture
information architecture
This Information Architecture
WAS designed to support
fast investigation,
clear ownership, and
safer scaling of CMS access.
Epic is a creative agency fueled by a future and excellence.
flow chart
flow chart
flow chart
&
&
&
user flow
user flow
user flow
Wireframes
Wireframes
Wireframes
&
&
&
Prototyping
Prototyping
Prototyping
started with quick hand-drawn wireframes
to mirror how teams actually
investigate CMS-driven incidents—filters first,
then key insights, ranked views, and
finally deep-dive logs.
It helped me validate
the hierarchy early and move into
Figma + development with speed and confidence.
Epic is a creative agency fueled by a future and excellence.
low fidelity
low fidelity
low fidelity
After mapping user needs and incident workflows in detail, I translated those early ideas into structured low-fidelity wireframes. This version focuses on clarity, hierarchy, and speed — enabling teams to move from high-level signals to detailed logs without friction.
Epic is a creative agency fueled by a future and excellence.
user interface
user interface
user interface
A high-fidelity UI for an internal CMS Activity Tracker—built to make incident debugging faster
by surfacing who changed what, when, and where in a single view.
Our process at Epic combines creativity with strategy
Our process at Epic combines creativity with strategy, starting with understanding your goals and moving through careful planning
and innovative design.
This view gives teams an instant snapshot of CMS activity—filters, key insight cards, ranked views, and a live timeline—so the “what changed?” question is answered before diving into logs
Our process at Epic combines creativity with strategy
Our process at Epic combines creativity with strategy, starting with understanding your goals and moving through careful planning
and innovative design.
Once an entry looks suspicious, the drill-down panel shows full context—who, when, module, action, exact query, and before-vs-after state—making RCA and audits fast and reliable.
Our process at Epic combines creativity with strategy
Our process at Epic combines creativity with strategy, starting with understanding your goals and moving through careful planning
and innovative design.
CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard- CMS Activity Tracker Dashboard
CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard- CMS Activity Tracker Dashboard
CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard- CMS Activity Tracker Dashboard
what i learnt
YOUR start
what i learnt
I learned that internal dashboards must prioritize speed, clarity, and trust—especially during incidents.
I also learned that reliable UX starts with clean, structured logs and guardrails that prevent mistakes.
Most importantly, I learned to design for real workflows and edge cases through close collaboration with Product, QA, and Engineering.
MEMORABLE & CAPTIVATING DIGITAL — EXPERIENCES.
MEMORABLE & CAPTIVATING DIGITAL — EXPERIENCES THAT DELIVER, Partnering WITh visionaries PEOPLe & trailblazers TO innovate.
CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard- CMS Activity Tracker Dashboard
CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard- CMS Activity Tracker Dashboard
CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard- CMS Activity Tracker Dashboard
CMS ACTIVITY
TRACKER
CMS ACTIVITY
CMS ACTIVITY
TRACKER
TRACKER
Designing an internal audit log dashboard for HashtagCMS
to track who changed what, when, and where
Designing an internal audit log dashboard for HashtagCMS
to track who changed what, when, and where
Designing an internal audit log dashboard for HashtagCMS
to track who changed what, when, and where
project overview
project overview
project overview
An internal CMS logs dashboard to track who changed what, when, and where—built to cut debugging time and bring clarity and accountability for product, marketing, and engineering teams.
An internal CMS logs dashboard to track who changed what, when, and where—built to cut debugging time and bring clarity and accountability for product, marketing, and engineering teams.
An internal CMS logs dashboard to track who changed what, when, and where—built to cut debugging time and bring clarity and accountability for product, marketing, and engineering teams.
problem statement
CMS changes directly impact the live app, but when multiple teams had access, it was hard to trace edits and establish ownership during incidents.
To reduce risk, access was restricted to a small group of CMS owners—creating a single point of dependency and shifting operational load onto 2–3 people alongside their core engineering work.
We needed a clear activity trail showing who changed what, when, and where, so troubleshooting is faster, accountability is clear, and access can scale safely without increasing production risk
1.
Low change traceability
2.
Direct production impact
3.
Access restriction created bottlenecks
4.
Operational overload
5.
Slow incident resolution
6.
Limited safe scaling
1.
Low change traceability
2.
Direct production impact
3.
Access restriction created bottlenecks
4.
Operational overload
5.
Slow incident resolution
6.
Limited safe scaling
1.
Low change traceability
2.
Direct production impact
3.
Access restriction created bottlenecks
4.
Operational overload
5.
Slow incident resolution
6.
Limited safe scaling
proposed
Solution
I designed, implemented, and deployed an internal CMS Activity Tracker dashboard that provides a reliable audit trail of CMS changes. It records who made a change, what was changed, when it happened, and where it occurred across modules—so issues can be traced quickly and ownership stays clear.
The solution reduces debugging time and enables safer scaling of CMS access.
Centralized activity log capturing all CMS changes across modules
Clear audit trail showing who changed what, when, and where
Advanced filtering by user, module, action type, and time range
Detailed change view to inspect updates and understand impact
Built and deployed end-to-end with validation and senior review
user research
It was done through quick interviews and workflow walkthroughs with internal CMS users across Product, Marketing, QA, and Engineering. The insights highlighted gaps in traceability and ownership during incidents, shaping a dashboard focused on speed, accountability, and audit visibility.
results found
results found
results found
Research revealed that most production delays were not caused by fixing issues, but by identifying what changed and who made the change. Limited access reduced risk but created operational bottlenecks, while broader access increased risk without accountability. Teams needed a faster, more reliable way to trace changes without depending on a few CMS owners.
Finding what changed took longer than fixing the issue.
Research revealed that most production delays were not caused by fixing issues, but by identifying what changed and who made the change. Limited access reduced risk but created operational bottlenecks, while broader access increased risk without accountability. Teams needed a faster, more reliable way to trace changes without depending on a few CMS owners.
Finding what changed took longer than fixing the issue.
Research revealed that most production delays were not caused by fixing issues, but by identifying what changed and who made the change. Limited access reduced risk but created operational bottlenecks, while broader access increased risk without accountability. Teams needed a faster, more reliable way to trace changes without depending on a few CMS owners.
Finding what changed took longer than fixing the issue.
user
user
user
persona
persona
persona
Aditi
Aditi frequently updates banners, offers, and content through the CMS to support business and marketing needs. Many changes are time-sensitive and need to go live quickly, often without technical validation.
Age: 28
ROLE : Product Manager
Aditi
Aditi frequently updates banners, offers, and content through the CMS to support business and marketing needs. Many changes are time-sensitive and need to go live quickly, often without technical validation.
Age: 28
ROLE : Product Manager
Aditi
Aditi frequently updates banners, offers, and content through the CMS to support business and marketing needs. Many changes are time-sensitive and need to go live quickly, often without technical validation.
Age: 28
ROLE : Product Manager
Goals
Goals
Goals
Push content changes quickly to meet business deadlines
Update offers, banners, and configurations without engineering dependency
Ensure changes reflect correctly on the live app
Push content changes quickly to meet business deadlines
Update offers, banners, and configurations without engineering dependency
Ensure changes reflect correctly on the live app
Push content changes quickly to meet business deadlines
Update offers, banners, and configurations without engineering dependency
Ensure changes reflect correctly on the live app
Behaviors
Behaviors
Behaviors
Makes frequent CMS updates, sometimes under time pressure
Relies on trial-and-error when changes don’t behave as expected
Assumes issues will be handled by engineering later
Makes frequent CMS updates, sometimes under time pressure
Relies on trial-and-error when changes don’t behave as expected
Assumes issues will be handled by engineering later
Makes frequent CMS updates, sometimes under time pressure
Relies on trial-and-error when changes don’t behave as expected
Assumes issues will be handled by engineering later
Frustrations
Frustrations
Frustrations
No visibility into which changes may have caused issues
Changes made under urgency sometimes lead to production incidents
Difficult to trace ownership when multiple teams access CMS
No visibility into which changes may have caused issues
Changes made under urgency sometimes lead to production incidents
Difficult to trace ownership when multiple teams access CMS
No visibility into which changes may have caused issues
Changes made under urgency sometimes lead to production incidents
Difficult to trace ownership when multiple teams access CMS
Needs
Needs
Needs
Clear visibility into what was changed and by whom
Confidence that changes can be audited and reverted if needed
Reduced risk while making fast updates
Clear visibility into what was changed and by whom
Confidence that changes can be audited and reverted if needed
Reduced risk while making fast updates
Clear visibility into what was changed and by whom
Confidence that changes can be audited and reverted if needed
Reduced risk while making fast updates
Rahul
Rahul is responsible for maintaining app stability. When production issues occur without a new release, he often investigates CMS data to identify what caused the problem.
Age: 25
ROLE : Software Engineer
Rahul
Rahul is responsible for maintaining app stability. When production issues occur without a new release, he often investigates CMS data to identify what caused the problem.
Age: 25
ROLE : Software Engineer
Goals
Quickly identify the root cause of production issues
Understand recent CMS changes without guesswork
Reduce debugging time during incidents
Behaviors
Manually checks CMS data and compares timestamps
Cross-checks with multiple teams to identify recent changes
Spends significant time during incidents investigating “what changed”
Frustrations
No clear record of what changed in the CMS Difficult to correlate
CMS updates with app crashes
Debugging takes longer than fixing the actual issue
Needs
Clear visibility into what was changed and by whom
Confidence that changes can be audited and reverted if needed
Reduced risk while making fast updates
Rahul
Rahul is responsible for maintaining app stability. When production issues occur without a new release, he often investigates CMS data to identify what caused the problem.
Age: 25
ROLE : Software Engineer
Rahul
Rahul is responsible for maintaining app stability. When production issues occur without a new release, he often investigates CMS data to identify what caused the problem.
Age: 25
ROLE : Software Engineer
Rahul
Rahul is responsible for maintaining app stability. When production issues occur without a new release, he often investigates CMS data to identify what caused the problem.
Age: 25
ROLE : Software Engineer
Goals
Goals
Quickly identify the root cause of production issues
Understand recent CMS changes without guesswork
Reduce debugging time during incidents
Quickly identify the root cause of production issues
Understand recent CMS changes without guesswork
Reduce debugging time during incidents
Behaviors
Behaviors
Manually checks CMS data and compares timestamps
Cross-checks with multiple teams to identify recent changes
Spends significant time during incidents investigating “what changed”
Manually checks CMS data and compares timestamps
Cross-checks with multiple teams to identify recent changes
Spends significant time during incidents investigating “what changed”
Frustrations
Frustrations
No clear record of what changed in the CMS
Difficult to correlate CMS updates with app crashes
Debugging takes longer than fixing the actual issue
No clear record of what changed in the CMS
Difficult to correlate CMS updates with app crashes
Debugging takes longer than fixing the actual issue
Needs
Needs
Manually checks CMS data and compares timestamps
Cross-checks with multiple teams to identify recent changes
Spends significant time during incidents investigating “what changed”
Manually checks CMS data and compares timestamps
Cross-checks with multiple teams to identify recent changes
Spends significant time during incidents investigating “what changed”
empathy map
empathy map
empathy map
This empathy map captures the shared experience of engineers and CMS owners during production incidents. A lack of visibility into CMS changes created stress, delayed debugging, and dependency on a few individuals. These insights reinforced the need for a transparent, reliable activity tracker that enables faster investigation and clear accountability.
Our process at Epic combines creativity with strategy
Our process at Epic combines creativity with strategy, starting with understanding your goals and moving through careful planning
and innovative design.
Thinking
Something changed in production, but there was no release.
Is this a CMS update or a backend issue?
Who touched this module last?
Why is debugging harder than fixing the issue?
Thinking
Something changed in production, but there was no release.
Is this a CMS update or a backend issue?
Who touched this module last?
Why is debugging harder than fixing the issue?
Thinking
Something changed in production, but there was no release.
Is this a CMS update or a backend issue?
Who touched this module last?
Why is debugging harder than fixing the issue?
Hearing
Marketing pushed an urgent CMS update.
The app is behaving unexpectedly after a content change.
Nothing new was deployed — must be CMS.
Can someone check what changed?
Hearing
Marketing pushed an urgent CMS update.
The app is behaving unexpectedly after a content change.
Nothing new was deployed — must be CMS.
Can someone check what changed?
Hearing
Marketing pushed an urgent CMS update.
The app is behaving unexpectedly after a content change.
Nothing new was deployed — must be CMS.
Can someone check what changed?
Pains
No clear visibility into CMS changes
Difficult to correlate CMS updates with production issues
Debugging takes longer due to missing ownership data
Dependency on a few CMS owners for every investigation
High stress during incidents without clear answers
Pains
No clear visibility into CMS changes
Difficult to correlate CMS updates with production issues
Debugging takes longer due to missing ownership data
Dependency on a few CMS owners for every investigation
High stress during incidents without clear answers
Pains
No clear visibility into CMS changes
Difficult to correlate CMS updates with production issues
Debugging takes longer due to missing ownership data
Dependency on a few CMS owners for every investigation
High stress during incidents without clear answers
Gains
Clear log of who changed what, when, and where
Faster root-cause identification during incidents
Reduced back-and-forth between teams
Confidence to scale CMS access safely
Less off-hours debugging and firefighting
Gains
Clear log of who changed what, when, and where
Faster root-cause identification during incidents
Reduced back-and-forth between teams
Confidence to scale CMS access safely
Less off-hours debugging and firefighting
Gains
Clear log of who changed what, when, and where
Faster root-cause identification during incidents
Reduced back-and-forth between teams
Confidence to scale CMS access safely
Less off-hours debugging and firefighting
Saying & Doing
Checking CMS data manually to trace changes
Asking multiple teams what was updated
Cross-verifying timestamps and modules
Spending time investigating instead of resolving
Saying & Doing
Checking CMS data manually to trace changes
Asking multiple teams what was updated
Cross-verifying timestamps and modules
Spending time investigating instead of resolving
Saying & Doing
Checking CMS data manually to trace changes
Asking multiple teams what was updated
Cross-verifying timestamps and modules
Spending time investigating instead of resolving
information architecture
information architecture
information architecture
This Information Architecture
WAS designed to support
fast investigation,
clear ownership, and
safer scaling of CMS access.
Epic is a creative agency fueled by a future and excellence.
flow chart
flow chart
flow chart
&
&
&
user flow
user flow
user flow
Wireframes
Wireframes
Wireframes
&
&
&
Prototyping
Prototyping
Prototyping
started with quick hand-drawn wireframes
to mirror how teams actually
investigate CMS-driven incidents—filters first,
then key insights, ranked views, and
finally deep-dive logs.
It helped me validate
the hierarchy early and move into
Figma + development with speed and confidence.
Epic is a creative agency fueled by a future and excellence.
low fidelity
low fidelity
low fidelity
After mapping user needs and incident workflows in detail, I translated those early ideas into structured low-fidelity wireframes. This version focuses on clarity, hierarchy, and speed — enabling teams to move from high-level signals to detailed logs without friction.
Epic is a creative agency fueled by a future and excellence.
user interface
user interface
user interface
A high-fidelity UI for an internal CMS Activity Tracker—built to make incident debugging faster
by surfacing who changed what, when, and where in a single view.
Our process at Epic combines creativity with strategy
Our process at Epic combines creativity with strategy, starting with understanding your goals and moving through careful planning
and innovative design.
This view gives teams an instant snapshot of CMS activity—filters, key insight cards, ranked views, and a live timeline—so the “what changed?” question is answered before diving into logs
Our process at Epic combines creativity with strategy
Our process at Epic combines creativity with strategy, starting with understanding your goals and moving through careful planning
and innovative design.
Once an entry looks suspicious, the drill-down panel shows full context—who, when, module, action, exact query, and before-vs-after state—making RCA and audits fast and reliable.
Our process at Epic combines creativity with strategy
Our process at Epic combines creativity with strategy, starting with understanding your goals and moving through careful planning
and innovative design.
CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard- CMS Activity Tracker Dashboard
CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard- CMS Activity Tracker Dashboard
CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard- CMS Activity Tracker Dashboard
what i learnt
YOUR start
what i learnt
I learned that internal dashboards must prioritize speed, clarity, and trust—especially during incidents.
I also learned that reliable UX starts with clean, structured logs and guardrails that prevent mistakes.
Most importantly, I learned to design for real workflows and edge cases through close collaboration with Product, QA, and Engineering.
MEMORABLE & CAPTIVATING DIGITAL — EXPERIENCES.
MEMORABLE & CAPTIVATING DIGITAL — EXPERIENCES THAT DELIVER, Partnering WITh visionaries PEOPLe & trailblazers TO innovate.
CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard- CMS Activity Tracker Dashboard
CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard- CMS Activity Tracker Dashboard
CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard - CMS Activity Tracker Dashboard- CMS Activity Tracker Dashboard