CASE STUDY 2: Untangling a complex product, designing the Platform Updates console

Alert fatigue. Broken trust. Opaque updates. Two design iterations and 10 usability tests later, 3,200+ ODC developers felt more in control of their platform.

The problem

OutSystems users were losing trust in their own platform. When updates rolled out automatically, applications broke without any warning. When they tried to understand what was happening, they faced a wall of opaque status emails, inconsistent terminology, and a UI that offered no sense of control or predictability.

The result was alert fatigue. Research and support data revealed a pattern: customers were ignoring platform update emails entirely. The volume was too high, the signal too low. We called it alert fatigue, and it was costing customers control over their own platform stability.

There were already fragmented update features in the product, so when the initiative came to us, the design challenge was more than visual, it was conceptual: how do you make something genuinely complex, with so many different concepts, states, and statuses, feel understandable and controllable?

My role

I contributed to the UX wireframing and conceptual design of the Platform Updates console. The primary interface customers use to monitor, schedule, and manage updates across their application portfolio. My specific ownership was the information architecture, the conceptual model underlying the UI, and the customer-facing email notification system that communicated update status across the deployment lifecycle. To accomplish this, I worked with multiple product designers, product architects, and PMs across 3 different teams.

The process

Before any wireframes could be drawn, the underlying data model needed to be understood and simplified. The system had five interconnected objects: Assets, Stages, Patches, Updates, and Breaking Changes, each with their own large attributes, conditions, types, statuses, and relationships. Different stakeholders used these terms differently. Engineers meant one thing by "update," product managers meant another, and customers meant something else entirely.

Working with product architecture, I led sessions to map and unify the full object model, defining each concept and its relationships. This became the conceptual foundation the UI was built on.

One critical decision that came out of this work: renaming "Assets" to "Platform" in the customer-facing UI. Usability testing with 10 participants across two design iterations confirmed that "Assets" created confusion. Technical customers thought it meant "code assets" versus their own portfolio of applications and libraries. Concept testing around "Platform" immediately clicked.

The core IA challenge was that customers needed to answer two fundamentally different questions depending on their role:

  • "What's happening to my stages?" (operations/infrastructure view)

  • "What's happening to my apps?" (developer/asset view)

I designed a two-tab architecture, "By stage" and "By asset," that let customers switch between these mental models without losing context. This wasn't just a UI pattern decision. It was a conceptual decision about how the product understood its own users.

One of the biggest sources of customer frustration was the email system. Customers received high volumes of generic update emails, leading them to ignore all communications, including critical action-required alerts. I designed the full email notification system from scratch, mapping every trigger point across the deployment lifecycle, writing each email template, and establishing a clear hierarchy between informational emails and action-required alerts. The goal was to reduce noise so that when a critical email arrived, customers paid attention.

Working from the conceptual model and IA, I wireframed the Platform Updates console across multiple states: the list view with severity and stage filters, the update schedule view showing deployment timelines, and the update contents panel distinguishing security fixes from bug fixes and breaking changes.

Each state was designed around a single principle: customers should always know what is happening, what will happen next, and what, if anything, they need to do.

Impact

The design was validated through 10 moderated usability tests across 2 design iterations, plus asynchronous feedback from 7 MVP users:

  • 4/5 or 5/5 ease of use scores across all testing sessions

  • Alert fatigue reduction. The email system redesign reduced overall communication noise, making action-required alerts significantly more visible

  • Conceptual clarity. The "Assets" to "Platform" rename, validated in testing, resolved a fundamental comprehension gap that had existed since the product launched

  • Projected 22% SLA compliance improvement. Fewer applications remaining unpatched past the 6-month maximum allowable cadence. This was the key success metric the team defined to measure whether the redesign actually changed user behavior

  • User satisfaction target. Sustained scores above 4/5 in surveys regarding ease of use and control

What I'd do differently

I would have pulled product architecture into the design process earlier. Data schemas and UI concepts are not the same thing, and the tension between them needs to be resolved before wireframes start, not during.

I would also push for more alignment and definition sessions earlier. The "Assets" vs "Platform" issue cost us a full design iteration that could have been avoided with earlier user research on concepts and terminology.

Suggested visuals:

  1. Full data model/ontology diagram

  2. "By stage" and "By asset" IA wireframes side by side

  3. Email notification timeline

  4. Two or three Platform Updates console screens showing different states

  5. Before/after annotation showing the "Assets" to "Platform" rename decision