The problem
Design extends beyond what we see.
The SAP Fiori Design Systems team wanted to explore new sounds and tones for enterprise software. I reviewed existing research, worked with sound samples supplied by a music producer, and outlined a study plan.
The research focused on how people used sound at work, how work environments had changed during the pandemic, and how sounds matched expectations for interface events.
Who it affects
People using enterprise software in their work environments.
The research explored how people used sound professionally and personally, how their environment affected those choices, and how sound samples matched expectations for interface events.
Decisions & tradeoffs
The study setup shaped the response.
Give the sounds a context
Participants found it hard to categorize sounds in isolation. I asked them to imagine a familiar work application and their everyday work setting.
Keep the rating sequence consistent
Ratings could shift after a sound was associated with an event. The revised procedure collected the initial rating immediately after listening, before categorization.
Clarify overlapping labels
“Alert” and “notification” were interpreted differently. Brief descriptions and examples helped clarify what those categories meant within the activity.
The tradeoff behind collecting an initial rating before contextual categorization, or another choice I can explain with a specific example from the study.
Progress & learning
Listen, react, rate, and categorize.
The sessions began with questions about professional and personal sound use: when participants turned notifications on or off, which devices they used, and how their working environments affected those choices.
Participants then listened to sound samples, shared immediate reactions, rated them, and sorted them into interface-event categories. They could also create categories or identify missing sounds.
Test the sounds inside an interaction.
The qualitative feedback captured how participants described sounds, what they associated them with, and how they reacted. The study setup also highlighted practical limitations: tools such as Mural and FigJam did not support the audio workflow I needed, so I used PowerPoint for playback.
The proposed next step was to build an interactive prototype with engineers and test the most consistently categorized sounds in context. This study does not claim that the sound system was implemented or validated in a shipped product.
Success criteria
The study examined initial reactions, sound ratings, and associations with interface events. The proposed next step was to test candidate sounds in an interactive prototype against users’ expectations.
The existing case study does not establish that the sound system was implemented or validated in a shipped product.
A concrete finding that informed a recommendation, how it would be validated in context, and any later outcomes if available.