The layer the spec left out - Enterprise rApps

What I Owned Across Five rApps

Ericsson and a major U.S. telecom carrier are developing rApps (Automation Applications) that run on Ericsson’s Intelligent Controller (EIC) to automate and optimize Radio Access Network operations. Each rApp was built around a different network-management purpose and workflow.

Who the document never described

The users were specialists who understood their domain far better than the tool did. The interface's role wasn't to teach the work, but to make the system's state clear. Because every decision affected live operations, confidence mattered more than speed.

What the specialist needs to see, at every step

Mapped from the moment a change is proposed to the moment its outcome is confirmed — not what the automation does at each step, but what a specialist making a live-operations decision needs the system to make clear at that exact moment.

What the legacy screens were already teaching

Before assessing the interfaces themselves, I worked closely with the client's specialists to understand how the existing tools were actually used day to day — where functionality fell short, where workflows broke down, and where legacy patterns were creating friction. Conversations with the discovery team added the technical context behind those gaps, and together they shaped the heuristic assessment below.

A few of the rApps modernised existing applications. I evaluated the legacy interfaces against core UX principles, identifying where hierarchy, navigation, terminology, and interaction patterns created unnecessary complexity. Rather than carrying old patterns forward, the findings informed a simpler, more intuitive experience.

Legacy UX Assessment

The structure everyone had to sign

Information Architecture wasn't about navigation, it was about alignment. By defining hierarchy, grouping information, and mapping workflows early, Product Owners, engineers, and stakeholders established a shared understanding of the product before interface design began. Resolving questions at this stage reduced ambiguity and created a stronger foundation for implementation.

Because the existing structure made the next step and information hierarchy difficult to understand, I used the IA to reorganise the experience around the user's workflow rather than simply reproducing the underlying system structure.

Designing for Operational Reality

Enterprise users rarely follow the happy path. Every prototype was designed to account for loading, empty, error, permission, and exception states, ensuring the experience remained clear and actionable even when things didn't go as planned. Working within the Ericsson Design System kept the focus on behaviour, helping define what users needed to see, understand, and do in every scenario.

Validating with Users

Interactive prototypes were put in front of the client's users in usability testing sessions, validating workflows, uncovering hidden assumptions, and refining the experience before implementation. Watching how people actually worked through the prototype shaped the product beyond the interface, ensuring it reflected how work was really done.

One interaction changed directly through user feedback: I initially used a modal for additional details. The user preferred to minimise clicks and retain the surrounding context, so I changed the interaction to an inline accordion. This kept the detail accessible without interrupting the user's place in the workflow.

Designing Five Products, One Process

Designing five enterprise applications within two quarters required more than efficiency, it required a different workflow. I used Figma AI to accelerate the creation of initial EDS-compliant wireframes, freeing time to focus on information architecture, interaction design, stakeholder validation, and edge-case thinking. AI became a production accelerator, while design decisions remained grounded in user needs and collaboration.

Technical Feasibility & Handover

Working closely with developers through implementation kept design decisions grounded in technical feasibility, with handoff treated as an ongoing conversation rather than a single meeting. When workflow requirements pushed against the system's existing capabilities (server-driven UI), I worked directly with engineering to understand the constraints and find practical solutions within the delivery timeline.