Unifying Admin Settings across products in Business Data Cloud

context

Business Data Cloud unified three products under one platform. The admin experience needed to follow.

Business Data Cloud brings together SAP Analytics Cloud (SAC), Datasphere (DSP), and BDC under one platform. Each product has its own Administration area used by administrators to maintain their tenant, including configuring SSO settings, managing system information, and controlling how the product appears in the browser.

Differences in admin settings structure across products created a noticeable inconsistency for administrators managing multiple products. Rather than addressing each issue separately, two parallel workstreams were scoped together: one focused on compliance for browser and tenant appearance, and one focused on unifying the admin page layout itself. Running them in parallel meant both problems could be tackled at once, with shared learnings feeding into each.

problem

Two separate compliance and consistency problems, addressed together.

Workstream 1 — Browser integration & tenant appearance

Both SAC and DSP had compliance gaps in how they handled browser-level product identity and tenant appearance settings. On top of that, the settings for managing these features lived in different places across products with no shared entry point or interaction pattern, creating an inconsistent experience for administrators.

Workstream 2 — Admin page template

Across SAC and DSP's administration tabs, there was no consistent way to save changes, no shared layout structure, and no shared component conventions. Each tab had been built independently, and it showed. The goal was to define a single standard that all admin settings tabs could adopt going forward.

goals

Fix compliance, align structure, and give every admin tab the same foundation.

Workstream 1

Resolve compliance gaps across SAC and DSP and align both products to a shared standard for browser integration and tenant appearance settings. Create a single spec covering both products so development teams spread across multiple countries could understand the full scope. Design a rollout plan that handled existing and new customers differently without breaking either experience.

Workstream 2

Establish a single layout standard for all admin settings tabs across SAC, DSP, and eventually BDC. Unify save behaviour across every tab, standardize component usage, and produce migration guidelines for teams updating existing tabs to the new standard.

process

Workstream 1 — Auditing and scoping compliance fixes

I started by auditing the current state of browser integration and appearance settings across SAC and DSP, mapping where compliance gaps existed and what a compliant version would look like. The audit identified several affected components, all using hardcoded values where SAP's themeable variables were required.

The design proposal introduced a new settings section that consolidated appearance-related controls into one predictable location. The rollout plan accounted for existing customers separately from new customers to avoid disrupting established workflows. Edge cases around theming and the interaction between different appearance settings were worked through and documented before handoff.

The spec was structured to cover SAC and DSP together, with clear callouts for which changes applied to which product, so multiple development teams could reference a single document rather than coordinating across separate specs.

Workstream 1 — Stakeholder feedback and iteration

Feedback from the UXC lead and senior designer shaped several decisions around the rollout plan and layout direction. The spec format was also refined based on feedback, shifting to a structured presentation format so the development lead could follow the flow without navigating the design file directly.

A follow-up review with the development lead surfaced additional edge cases around save state behaviour and how appearance settings would render under different browser and theme configurations. These were incorporated into the spec before handoff.

Workstream 2 — Establishing the layout standard

The admin page template work began with a high-level audit of how settings were being saved and displayed across all administration tabs. Multiple inconsistent patterns were in use with no shared convention. The goal was to consolidate these into a single, predictable pattern applied consistently across the page.

A layout standard was defined based on an established SAP floorplan, giving every admin tab a shared structure for sections, content width, and save behaviour. The footer was standardized to surface a consistent set of actions across all tabs.

Component usage was also audited across all tabs. Several components were being used outside their intended pattern, and migration guidelines were written to help tab owners apply the new standard correctly, covering layout, content guidelines, responsiveness, and how to handle existing custom elements.

Working across teams

Both workstreams involved coordinating across UX, User Assistance (UA), project managers, and development, with team members spread across different product areas. I worked with the UA designer to align on content and label standards. Scope changes mid-project, including a project manager transition and phasing decisions around what to include in scope, were incorporated without restarting the work. Regular check-ins with the UXC lead and developers ensured both specs met cross-platform standards and feasible implementation throughout the process.

outcome

Both specs completed and handed off to development.

Both specs were completed and handed off to development. Full case study details are available on request.

reflections

Decisions take time, and that's okay

Even small design decisions can involve multiple stakeholders, reviews, and back-and-forths before a direction is locked. Working at enterprise scale taught me to separate the design work from the decision-making process. Keeping specs well-documented meant that when decisions finally landed, implementation could move quickly.

How you present work matters as much as the work itself

I learned early on that the format you use to present to developers shapes how well they understand the design intent. A Figma file works in a design review, but a structured spec or a live prototype is what actually moves things forward in a dev handoff. Developers respond well to being able to interact with the design directly rather than interpreting static screens. Finding the right format for the right audience became a skill in itself.

Leading design conversations and advocating for decisions

Working with developers and project managers on a regular basis gave me hands-on experience presenting design rationale and defending decisions in a professional setting. One thing I underestimated early on was assuming stakeholders remembered the full context of the project. In reality, everyone is juggling multiple workstreams, and coming into a review with full context, not just the latest changes, made conversations more productive and helped move decisions forward faster.