I was the first embedded designer on a $400M+ product that had never had one. I led a team of four, ran the research, made the hard calls, and delivered a modernized admin experience in 12 months.
Overview
I was the first embedded designer on a $400M+ product that had never had one. I led a team of four, ran the research, made the hard calls, and delivered a modernized admin experience in 12 months.
My role
Product Design Lead
Team
Timeline
2023
Context
Content Services is a SaaS product that helps businesses securely manage content like documents, images, and audio files. It is the new experience of a legacy tool formerly called FileNet. As FileNet transitioned to SaaS, the product needed to become easier to learn, easier to navigate, and more approachable for a broader audience, while still supporting powerful admin workflows.
The challenge
How do you simplify a complex legacy admin experience into a modern SaaS product within one year, as the first designer a team has ever worked with?
FileNet was successful, but the admin experience was complex and documentation-heavy. Admins had to jump across multiple interfaces to complete work, and terminology felt too technical for new and business-oriented users. And when I joined, this PM team had never worked with a designer before. That wasn't a small detail — it meant I was also designing how the team worked.
Kickoff
Two weeks after joining, before touching Figma, I ran a two-day Enterprise Design Thinking workshop. I am a certified IBM Enterprise Design Thinking Coach, so I facilitated it myself, with Product Management, Development, Research, Content Design, and my design team in the room. The goal was to build shared understanding, surface assumptions, and align on what mattered most.

Hopes and Fears
As-Is Experience
Questions and Assumptions
User Needs
Big Ideas and Prioritization
To-Be Experience and Stages
Workshop outcomes
The workshop gave us the shape of the work: three admin workflows that everything else in Content Services depends on. Contessa's scenario became the anchor we designed against.
Manage content
Create metadata used to organize content, like labels that help sort and find documents.
Secure content
Define roles and access tied to metadata so only the right people can see sensitive content.
Configure desktops
Set up user desktop environments with the right tools, views, and access for each role.
Leadership
I was the design lead, so the plan was my responsibility before any of the design was. A twelve month deadline with a fixed MVP scope leaves no room to find out halfway through that the work does not fit. I partnered with Product Management and the lead developers to prioritise Stage 1, then kept it honest all year.
Prioritised the MVP with PM and engineering together
Not design proposing and engineering estimating afterwards. We sequenced the work in the same room, so what went into Stage 1 was already agreed to be buildable in the time we had.

The Stage 1 roadmap, agreed with Product Management and the lead developers.
Tracked every deliverable in Jira
Design work sat in the same backlog as engineering work rather than in a separate design plan. It made design a visible dependency instead of something that arrived late and surprised people.

Design deliverables tracked in Jira alongside engineering work.
Monthly checkpoint with PM, the Development Lead, and management
Where we were against the plan, what had shifted, and what needed re-prioritising. New topics surfaced constantly as my team worked through the designs, so the roadmap was re-aligned rather than written once and defended.
My team designed against it
With the sequence agreed, I could split the work across my designers by functional area and let each of them own a surface end to end, rather than everyone waiting on the same decisions.
Research
To get started properly we needed to know who we were designing for. I partnered with our researcher to find out what tools admins already used, how they worked with our products, and where they got stuck. She ran secondary research with 6 internal IBMers who worked directly with Content Services clients, then 1-hour interviews with 10 content administrators.
Two findings shaped everything after. Admins leaned heavily on documentation just to begin, which meant the product had to teach as they went. And the work was split across two separate interfaces, so a single task sent them back and forth between systems.
Admins need help getting started. They did not want to depend on documentation to begin their work.
Multiple interfaces overwhelmed them. Sending admins to different UIs to complete their work caused confusion and errors.
Terminology was a barrier. Prospective users struggled with FileNet's technical language as the product shifted to business-oriented SaaS users.
Admins work in teams with different levels of expertise. The experience needed to support both new and experienced admins.
Contessa
The Content Services Administrator
An admin at a car insurance company who needs to set up the system so customer service can process auto claims. She manages metadata, secures content by role, and configures the desktop workspace for her team. Managing up to 40 sites, responsible for governance compliance, system upgrades, and training internal teams.
Contessa persona built from structured research, interviews, and IBM concept testing studies
Contessa's story
During the kickoff workshop I noticed we had no clear end-to-end user path tied to a real use case. I partnered with three product managers to craft a story around Contessa, the Content Services administrator. She works at a car insurance company, somewhere like Allstate, and her job is to make it easy for customer service to file and find claim documents.
Working through her scenario gave us the concrete list of what she has to set up before anyone else can do their job:
Six setup tasks, in the order Contessa does them. Each one became a flow we designed.
As-Is workshop activity
These four frames show the progression from the As-Is activity during the kickoff workshop: from mapping the complex legacy experience to distilling it into a simplified end-to-end story that shaped everything that followed.
This story gave the entire team a shared mental model to build against. It onboarded new designers faster, aligned stakeholders on scope, and became the anchor for every design decision throughout the year.
Onboarded the design team faster with a clear shared narrative
Built shared understanding across PM and engineering so everyone was building toward the same goal
Validated directly with users in research sessions to confirm accuracy
Before and after
Contessa's three goals break down into six flows. Each one existed in FileNet and had to survive the move to SaaS without carrying over the complexity. These are the screens side by side.
Flow 01
Contessa creates the document class "Auto claim" so the customer assistant can organize insurance claims by vehicle.


Flow 02
Properties add detail to a claim. She creates "car color" so large volumes of content can be searched and filtered.


Flow 03
A choice list turns that property into a fixed set of options, so the assistant selects a color rather than typing one.


Flow 04
Roles and permissions on the metadata keep each claim visible only to the people who should see it.


Flow 05
Retention rules define how long a claim stays in the system before deletion, matching company policy.


Flow 06
The desktop is the space the assistant works in. Contessa designs it to match company branding and surface what matters.


Homepage redesign
FileNet's legacy Home Page sent admins to two completely separate interfaces just to start their work. Content and Access Management lived in one. Desktop Configuration lived in another. One task, two systems, and no clue from the homepage which one you needed.
This was the biggest pain point in the research. Admins told us the split was the first thing that confused them and the thing they never stopped tripping over. Fixing the homepage meant fixing that split.

Content and Access Management opened in one UI. Desktop Configuration opened in another. No clear starting point, no personalization, no in-product guidance. Admins were confused and dependent on documentation.
Ideation Home Page workshop
I had already started running design critiques in the Austin studio, so the habit of getting people in a room was there. I used it. Across the Automation organization I kept seeing designers solve the same problem with different methods and different terminology, so I ran a one-hour workshop and invited everyone in the studio working on this project.

Participated in the User Needs EDT activity to discover Contessa's needs for the Home Page
Reviewed internal IBM home screens to identify best practices and what to avoid
Reviewed products we use daily to understand what makes them effective
Encouraged by the curiosity of others and the positive feedback from the workshop, I established weekly Design Critiques for any IBMer in the Austin studio, welcoming any role to share ongoing projects, gather feedback, and increase collaboration across teams.
Workshop outcome

New homepage
Feel welcomed, greeted by name and time of day
Start creating without navigating to another UI
Get a quick overview of all her work in one screen
Follow an in-product walkthrough without depending on documentation
Organize the screen based on the task she focuses on
See a feed of teammates and what they have worked on
Use quick links based on personal preferences and learn about new product updates
DUX review
IBM's Design User Experience (DUX) review scores products across experience standards by an independent panel — it's not self-reported, not a survey, and not easy to move. Products regularly score Inadequate for years without improvement.
Before I joined, Content Services had never had a designer. The DUX baseline reflected that: Usability was a 9 (D, Inadequate), Visual Design wasn't even assessed, Content scored 14 (D+, Inadequate).
One important note: Learn, Try, Buy, and Get Started were intentionally out of scope. Those are PLG experience standards — I was pulled onto the PLG Innovation Team specifically to lead that work separately. What this project owned — Usability, Visual Design, Content, and Use — all moved significantly.
The scores: Usability moved from 9 (D, Inadequate) to 34 (C, Minimal). Visual Design went from not assessed to 72, B+, rated Good — the highest category on the scale. Content moved from 14 (D+, Inadequate) to 34 (C, Minimal). Use moved from 25 (C-) to 45 (C+). These gains happened in 12 months on a product that had never had a designer, inside one of the strictest internal design review programs at IBM.
"Clarity beats complexity. Modernizing a legacy tool is about removing confusion, not adding features."
Personal reflection from the Content Services projectRecognition
Outcomes
Product I contributed to
Redesigned a legacy enterprise platform contributing to improved experiences and customer satisfaction.
Delivered on time
Delivered a modernized foundation for Content Services SaaS within one year — on time, no scope cuts.
Visual design DUX score
Went from not assessed to 72, B+, Good — the highest DUX category — in 12 months.
Usability improvement
Usability moved from 9 (D, Inadequate) to 34 (C, Minimal) inside IBM's strictest design review program.
A design decision
During the homepage redesign, a debate emerged: should the workspace environment be called a Hub or a Desktop? It sounds small. It wasn't.
Our research showed prospective users were already struggling with FileNet's technical terminology. "Desktop" carried legacy baggage. "Hub" matched how admins actually described their work: a central place to manage everything.
The constraint
Engineering had already built components using "Desktop" as the technical term. Changing it had a cost.
I brought the research to the PM and senior dev with direct user evidence and looped in our content designer, who was working on terminology consistency across five Business Automation products. We aligned on "Hub" for the UI layer. Engineering kept "Desktop" as the internal technical identifier. I made the case that terminology confusion would cost more at scale than the rework.
User signal. Research showed admins described their workspace as a central command center, not a personal desktop.
The recommendation. "Hub" for the UI layer. "Desktop" stays as the engineering internal term.
The reflection. The most important design work is often not visual. It's knowing when to push back and why.
"Susana brought a level of design leadership and strategic thinking that elevated the entire team. Her ability to align stakeholders, drive clarity through ambiguity, and deliver high-quality work under real constraints was exceptional."
Matt Vest
Primary Product Manager & Program Director, IBM
How I led
I could not design this alone and I did not try. Content Services is genuinely complex, and nobody hands you that understanding. What made the team work was a set of standing rhythms I put in place, not any single decision. If I led a team like this again, I would set up all four on day one.
Twice-weekly n-in-a-box calls
I hosted these with Product Management, development, our researcher, the content designer, and management. We presented ongoing work and collected feedback in the same session. It kept design visible every week rather than reviewed at the end.
A smaller technical group, added when we needed it
Early on my designers did not have enough grasp of what the product could actually do, and it showed in the work. Rather than push through it, we set up a regular smaller session with engineering purely on technical capability, so designs stopped proposing things that would have been prohibitively expensive to build.
Terminology, settled with content design
FileNet's vocabulary was one of the barriers the research surfaced. I worked with the content designer to make the terms consistent across products, not just compliant with IBM's language guidelines.
Research, continuously rather than once
I supported our researcher through the year to test designs, validate Hill statements, refine terminology, run a Kano survey, and oversee final usability sessions.
What made it work. Mural templates prepared before every session, so the meeting itself was spent on the outcome rather than on setup. Small thing, but it is the difference between a workshop people attend and a workshop people contribute to.
Reflection
Lessons I carry forward
Alignment creates speed. When teams share one end-to-end story, decisions get easier and execution gets faster.
Clarity beats complexity. Modernizing a legacy tool is often about removing confusion, not adding features.
Culture is part of the work. Building relationships and trust made collaboration smoother across roles and time zones.
If I could redo one thing: I would involve customer success earlier — they had months of Contessa-level insight that took me weeks to surface through research.