Autodesk
Intelligent Activity Log Analyzer
An AI-powered layer that turns raw Autodesk Account activity logs into structured, human-readable insights and proactive alerts for admins.
Role
UX Designer
Vibe Coder
Skills
Prototyping
AI Integrated Design
Team
Rishi Ashar (Me)
Vardnan Sivarajah
UX Engineer - Autodesk
Timeline
2 weeks
August 2025
Design and Prototype
Tools
Figma MakeContext
What is Autodesk Account?
Autodesk Account is where organizations control everything related to Autodesk software: users, teams, admin roles, licenses, product access, billing, and activity. It is used by IT administrators and program managers who manage access for engineers, architects, designers, consultants, and contractors across projects.
Admins use it to:
- Assign and revoke licenses
- Manage who has access to what
- Control who can make changes
- Track activity across teams
The Problem
What admins see today
The Activity Log records every action, but it was never designed to help admins interpret behavior.
What is Activity Log?
The Activity Log is the place where every action inside Autodesk Account is recorded. It tracks events like user additions and removals, license assignments, project creation, admin role changes, and access updates.
Admins face these core problems
Buried in data
Thousands of rows of events gave admins a record, but no story or summary.
No early warning
Risky behavior like sudden license revocations, admin role changes, or self-assignments could go unnoticed until work was already blocked.
The system stores information. It does not create "Understanding"
Key Insights
The biggest friction isn't action. It's awareness.
Admins can make changes easily, but they struggle to understand what actually happened after something goes wrong, who caused it, and whether it was a normal action or a risky one.
1.When things break, admins find out too late
Admins only realize something is wrong after real work is already blocked. By the time they reach the Activity Log or support forums, users are locked out and productivity is already damaged. The system does not help prevent problems. It only records them after they happen.
2.No clear accountability for critical actions
There is no clear way to understand who changed what and why. Admins are left guessing whether an action was intentional, accidental, or malicious because the Activity Log shows events without context or accountability.
Lack of visibility into who changed account ownership or access
Solution
Turning the admin homepage into an early warning system
The solution adds an AI-powered layer that transforms raw activity logs into structured, human-readable insights and proactive alerts.
The solution works in two layers
1. The Early Signal (Awareness Layer)
A small, focused message tells admins something important has changed and their attention may be needed. It appears on the homepage, where decisions already happen, instead of hiding inside reports.
2. Actionable Insights (Where Decisions Happen)
This is where the Activity Log stops being a record and starts being a guide. The system no longer just shows what happened. It explains what it means.
These insight cards are not fixed. What shows up depends on what is happening inside the account.
Some weeks, there is no unusual behavior at all. The page stays quiet and focuses on structural changes like projects or member updates. Other weeks, patterns emerge that deserve attention, and those insights naturally move to the top.
Decision Logic
How does the system decide what deserves attention?
In the existing experience, patterns were buried inside the activity log as individual rows. Admins could technically find them, but only if they already knew what they were looking for. Most of the time, they discovered something was wrong only after someone could not log in or a project came to a halt.
Unusual Activity brings those patterns to the surface.
For example, when an admin repeatedly removes people's access from a particular product or self-assigns a role, the system can flag the pattern as unusual and show it before it becomes a support issue.
Design Decisions
Clicking revealed more information, but not understanding
In an early version, clicking the message expanded a summary inside the Activity Log. It grouped recent changes into a readable block instead of forcing admins to scan every row. That helped, but only partially.
In reality, that is not how problems show up. Admins do not open logs proactively. They open them after something breaks. When users lose access, licenses disappear, or projects stop working, the question is not "what happened this week?" It is "what just went wrong?"
That gap made the limitation clear. Surfacing a better summary inside the Activity Log was useful, but it still relied on admins to notice problems on their own.
Instead of waiting for admins to come to the log, the system needed to speak up first, directly on the homepage where decisions already happen.
Reducing text and increasing structure
The first version of the Activity Log tried to answer every question at once. All the information was technically correct, but it came through as a dense block of text.
That is how Facebook and Amazon handle AI summaries today: they place a concise interpretation above the raw comments or reviews.
Critical signals were buried alongside routine updates, and everything looked equally important. To make sense of it, admins had to slow down, read carefully, and already know what they were looking for.
Feedback from my mentors pushed me to rethink how information was being presented.
Instead of asking admins to read paragraphs, I focused on structure. Modern LLMs are naturally good at producing structured outputs like JSON, so I leaned into that strength. Rather than generating prose, the system outputs clearly defined chunks: categories, counts, and short statements that can be mapped directly to UI components.
Build Process
How I vibe coded the prototype
I treated AI-assisted coding as part of the design process, not a separate engineering handoff. The visual direction started in Figma, Figma Make translated the designed frames into code using the existing design system, and Cursor became the place where I connected the screens and added motion.
- Design
Figma
Frame + design system
I started from the Autodesk Account frame, with the product system already living in Figma.
- Generate
Figma Make
Pixel-matched pages
Figma Make used that system to generate the first screen, then I repeated the same flow for Activity Log.
HomepageActivity Log - Prototype
Cursor
Joined pages + motion
I downloaded the code, opened it in Cursor, and prompted through routing, transitions, and animation.
The important shift was choosing what each tool was responsible for. Figma Make handled the design-system-aware translation from frame to code. Cursor handled the behavior: joining the generated pages, adding animation, and turning the static screens into a working prototype.
Learnings
1.An insight should lead somewhere
An insight without a clear next step still adds mental effort. The moments that worked best were when the insight quietly pointed to what to do next, like viewing users, checking affected projects, or reviewing a suspicious admin action.
2.AI output needs product structure
The design became stronger when the AI was treated less like a paragraph writer and more like a system that could sort, classify, and prioritize account activity into stable interface patterns.
Account Settings Redesign
Next case study
Account Settings Redesign
The next Autodesk case study zooms out from activity insights into a clearer structure for Team Settings.