TIMELINE
Sept 2025 - Dec 2025
ROLE
Product Designer
TEAM
CEO (Aude.ai)
Product Manager (Aude.ai)
7 Designers
TLDR
Aude.ai surfaces AI-powered performance insights for engineering teams, but users didn't trust what it was showing them and struggled to act on those insights together. Designed experiences to make AI-generated insights transparent and actionable, and introduced a coaching feature to bring human connection back to performance evaluation.
IMPACT
38% Increase
in perceived transparency of the platform
14% Increase
task success rate
Context
What is Aude.ai?
Aude is an AI-powered performance evaluation platform that integrates with tools like GitHub, Jira, and Slack to capture work patterns and deliver personalized, actionable insights for engineering teams.
Engineers are the primary recipients of this value, using the platform to understand their own performance, get feedback, and improve.
!
Despite this, Aude noticed that adoption among engineers remained low and the platform wasn't being used the way it was intended.
understanding the problem
What was going wrong?
We conducted 8 in-depth interviews with software engineers, 2 with engineering managers, and a digital ethnographic study across Reddit. Three themes kept coming up.
1
AI Insights felt like a black box
Engineers couldn't see where data came from or why suggestions were made, making it hard to trust anything the platform surfaced.
2
Disconnect from the real world
Performance evaluation involves teammates and cross-team collaborators, but the platform had no way to capture or surface that input.
3
AI suggestions lead nowhere
The platform told engineers what to improve but gave them no infrastructure to act on it, leaving them without support to actually grow.
How might we make performance insights more transparent, actionable, and meaningful to an engineer's growth?
challenge 01
Engineers had no reason to trust what they were seeing
Engineers were receiving AI-generated suggestions but had no visibility into what data they were based on or why they were being surfaced. Without that context, suggestions usually felt arbitrary and something you couldn't interrogate, you couldn't trust.
Suggestions
Add clear context and examples in your PR descriptions to speed up reviews. This helps reviewers understand the changes without needing extra clarification
Goal: Engineering Excellence | Criteria: Code Quality & Review Efficiency
Add as Action
Generated: 10/19
In 3 of your recent PRs, edge case failures were caught post-merge by teammates. Proactively flagging known risks in your PR descriptions can prevent downstream issues and demonstrate ownership of quality.
Goal: Trust & Integrity | Criteria: Integrity & Prioritizing the Right Outcome
Add as Action
Generated: 10/19
You've had 4 async threads in the last month where decisions were made without documenting the reasoning. Sharing a brief rationale keeps your team aligned and reduces re-litigating decisions later
Goal: Trust & Integrity | Criteria: Building Team Trust
Add as Action
Generated: 10/19
For me to be okay with it, I'd like to know exactly the reason behind this… you have some black box judging you.
I personally would love some insights, but I need to figure out what I’m supposed to do with them.
The suggestions feel vague. I can’t tell where they’re coming from.
So, We redesigned the suggestions card
to show engineers exactly where data was pulled from, why the suggestion was generated, and what to do next.
challenge 02
Aude's evaluation flow had one blind spot, It only captured what a manager could see.
Engineers working across teams, in code reviews, in Slack threads, in cross-functional projects, weren't getting that visibility surfaced anywhere.
What if the most useful feedback wasn't coming from your manager or an AI, but from your teammates?
— Engineering manager
Research told us what we were already sensing: peer feedback tends to be more accurate than manager-only reviews, but most platforms had no real way to capture or surface it when it matters.
The feedback was always there. We just made it visible.
We designed a view where AI combs through all the peer feedback, finds what keeps coming up, and shows it to the engineer. Bigger circle means more people flagged it. Each one has steps attached so they know where to start.
Patterns recognized from feedback
AI summarized
4 themes derived from 40 mentions across 11 reviewers. Updated 2 hours ago.
Size proportional to mentions
Share updates earlier in the sprint
Improve documentation on PRs
Follow consistent code formatting
Communicate blockers sooner
Selected Theme
Share updates earlier in the sprint
Teammates consistently mention that progress visibility drops mid-sprint. They want earlier signals, not end-of-week writeups.
Actions based on this feedback
Initiate Coaching
Break larger tasks into smaller tickets and share what you will pick up first.
Post a Tuesday mid-sprint update with blockers, wins, and next 48h.
Bring up blockers during daily standup instead of waiting until the end of the week.
challenge 03
!
Coaching was a gap even our project sponsors named upfront. They knew it needed to exist on the platform but didn't know what it should look like.
Our interviews told us two important things
1
Engineers never asked for coaching directly, but mentioned that they would seek help from their manager when they weren't sure how to act on a suggestion.
2
Managers described their 1:1s as where real growth happened, not in any tool.
So instead of trying to build an AI coach, We built a space for humans to coach each other.
Engineers can initiate a coaching session directly from an AI suggestion or a peer feedback pattern they want to work on. That request goes to their manager, who accepts it and schedules the first call.
The manager accepts the coaching request
They get on their first call and align on the challenge
Together they set the milestones, tasks, and a plan to work toward
Coaching
Coaching Session with
Clark
This board is shared between you and Clark
Settings
Current Challenge
Breaking large features into smaller pieces
Description
I understand I need to plan features more carefully before writing code, but I'm unsure what that actually looks like in practice. My last two features needed mid-sprint rewrites because the structure wasn't clear early on, and I want to figure out a consistent approach that works before I start the next one.
Milestones
Align on what "ready to implement" looks like for Clark’s features
Write a pre-implementation breakdown for the next assigned feature
Consistently explain scope and structure in PR descriptions before requesting review
Upcoming Meeting Agenda
Walk through Clark’s breakdown of upcoming feature work.
Review the pre-implementation outline he drafted this week.
Check if the format is sustainable and adjust if needed.
Discuss how to flag scope creep early before it causes rewrites.
Summary of the Nov 12, 10 AM meeting
Reviewed two recent features where structure broke down mid-implementation.
Identified that planning was skipped due to time pressure, not lack of ability.
Tasks
Draft a one-page breakdown of the next feature before writing any code.
Add a "Scope & Structure" section to PR descriptions for reviewers.
Flag to Alicia when a feature feels too large to plan in one sitting.
Created by HideMaru
from the Noun Project
Home
My Performance
My Team
Coaching
Performance Criterias
Administration
User Management
Performance
Team Management
Integrations
Alicia Walter
alicia@aude.ai
result
Engineers and managers appreciated having more context, more input, and a human in the room
I really appreciated the pattern cluster feature in the peer feedback view because it provides a more holistic view of actionable areas an engineer can focus on
— Engineering manager, usability testing
I really like the idea of keeping humans in the loop during coaching instead of relying solely on AI , I don’t fully trust AI on its own yet
— Engineer, usability testing
reflection
What I'd do differently
1
Design flexible coaching flows
Testing showed engineers come with different needs, some want 1:1s, others need structured resources, and coaching style differs per manager.
2
Explore better visualizations
The bubble chart made intuitive sense to some engineers but confused others. Frequency as a signal isn't always obvious at first glance.
What this project taught me
AI is only as useful as the trust behind it
Transparency isn't optional when AI touches something as sensitive as performance evaluation. Even with solid data sources, users need to understand the reasoning before they'll act on it.
Done is better than perfect
This project kept reminding me that trying to perfect something before putting it in front of users slows everything down. The best feedback came after something was in people's hands.
Designs need a path to production
I learned to keep one foot in what's actually buildable, not to limit ideas, but to make sure they have a real path to production.