Skip to main content

Back to top

Scroll to Top

Visit more pages:

Go to the Work page for brendankelly:

http://www.brendankellyux.com/work

Go to the About page for brendankelly:

http://www.brendankellyux.com/about

Read Brendan’s Cisco Case Study:

http://www.brendankellyux.com/cisco-case-study

Read Brendan’s ExxonMobil Case Study:

http://www.brendankellyux.com/exxonmobil-case-study

Read Brendan’s Panasonic Case Study:

http://www.brendankellyux.com/panasonic-case-study

Read Brendan’s Verizon Case Study:

http://www.brendankellyux.com/verizon-case-study

Read Brendan’s RWJF Case Study:

http://www.brendankellyux.com/rwjf-case-study

Client

A research-led redesign of an internal tool to manage 631 digital properties

631

ecosystem digital properties

1 system

designed end-to-end

3 roles

represented in user research

60%

fewer monthly support requests

What I contributed:

RESEARCH

Co-led stakeholder research

Helped shape the interview guide, led two of three interviews, and worked alongside strategy to understand how staff actually managed the ecosystem.

SYNTHESIS

Identified priorities from user insights

Built and presented the findings, translating search habits, pain points, and improvised workflows into product priorities.

PRODUCT DESIGN

Designed the complete experience

Owned UX and UI for the centralized ecosystem, including search, filtering, property details, status visibility, and management workflows.

DELIVERY

Shipped a product users could trust

Refined the experience with RWJF staff and delivered a complete, research-informed design for implementation.

The Situation

RWJF was responsible for a sprawling ecosystem of 631 grant-related digital properties. Its own audit found that only 17% were active, with some outdated sites dating back nearly two decades. The people responsible for maintaining that ecosystem were working with tools that made it difficult to see what existed, find what they needed, or know what required attention.

No one had a useful view of the whole ecosystem

Properties had accumulated across grants, teams, and years of work. Staff needed a reliable way to understand what was active, who owned it, when it had been updated, and what needed attention.

Users had learned to work around the system

Program Officers and communications staff had developed their own ways of finding and tracking information. One participant routinely turned to Google because it was easier than searching the systems RWJF already had.

A replacement had to work the way people actually worked

A cleaner interface alone wouldn't solve the problem. We needed to understand which workarounds were compensating for bad UX, which information people relied on, and which familiar behaviors the new experience should preserve.

Timeline

2024 Q2 - 2025 Q2

Stakeholders

Agency: MRM

Client: Robert Wood Johnson Foundation

Program director

Program officersDigital governance stakeholders

Collaborators

Co-led with Strategy Director

Process

Letting user behavior shape the experience, not the other way around

Summarized interview findings from our participants

I co-led the research with our strategist, Haylee. Together we shaped an interview guide around the jobs people were actually trying to do: finding properties, understanding ownership, checking status, sharing information, and keeping hundreds of sites from disappearing into the cracks.

I conducted two of three stakeholder interviews and joined the third. We spoke with a Program Officer, a Team Director, and a Senior Communications Officer, then I synthesized the findings into a deck and presented them back to RWJF.

Their workarounds were more revealing than any feature request. One Program Officer regularly used Google because it was easier than searching RWJF's own systems. Others relied on Salesforce, memory, or their own methods to answer basic questions about the ecosystem.

Why this approach

Years ago, while researching for my Master's thesis, I interviewed Denver teachers who were abandoning new curriculum tools for pencil and paper. The tools were more efficient on paper. They just didn't work the way teachers actually worked.

That stuck with me. A replacement doesn't earn adoption by being technically better. It has to earn trust.

At RWJF, my research partner and I treated the Program Officers' workarounds as evidence. Instead of designing the "ideal" workflow and asking people to adapt, we looked for what their improvised processes were already telling us.

Turning the hacks into requirements

The research findings became design requirements, with each major interaction tied back to a behavior or pain point we heard in interviews.

The interviews gave us a much clearer definition of the product. People didn't need more data. Much of the information already existed. They needed a better way to see it, search it, and understand what required action.

I translated the research into a small set of experience priorities: one view of the ecosystem, search and filtering based on the attributes people already relied on, clear ownership and lifecycle status, and a property detail view that surfaced useful context without forcing people into multiple systems.

Those priorities became the structure for the product. Search could filter by status, last update, and point of contact. Summary views exposed active and outdated properties. Detail views brought the information needed for the next decision into one place.

Why this approach

The temptation with a large enterprise system is to expose everything because the data exists.

Research pushed us in the opposite direction. The important question became: what does someone need to know right now to make the next decision?

That gave me a much cleaner way to organize the experience than reproducing the structure of the underlying databases.

Designing the system people had been asking for

The final handoff carried the research through the full UX and UI, from ecosystem-level visibility down to individual property management.

From there, I owned the UX and UI for the ecosystem experience end to end.

I designed the dashboard, search and filtering patterns, property records, status and ownership views, and the interactions that tied them together. The goal was to make a large, messy system feel understandable without hiding the complexity people genuinely needed to manage.

We didn't have a formal usability-testing phase, so I kept the people closest to the work involved as the designs developed. I reviewed the experience with the Program Manager and one of the Program Officers, used their feedback to refine the workflows, and carried the final experience through design handoff.

Why this approach

Research only matters if you can trace it into the thing you build.

I kept going back to the behaviors we'd heard in the interviews: how people searched, what they looked for first, where they needed reassurance, and what information helped them decide what to do next.

Outcomes

This design would have looked completely different if we hadn't talked to the people who actually used the system. Their workarounds were specific to this organization, and we never would have found them through assumptions or even proxy users. That research kept us from making something that merely worked and helped us make something that worked for them.

Audit Completion Time

18 Min

7 Min

Tools used by POs

3

1

Support requests

14/mo

8/mo

Avg steps per key task

7

3

61% faster audits made an ecosystem of 600+ sites practical to oversee.

Consolidating three tools into one system saved managers around six hours each week.

43% fewer support requests meant less rework and fewer publishing mistakes.

57% fewer steps across key tasks increased audit capacity without requiring more staff.

Accessible base components reduced future remediation and made AA compliance easier to maintain.

The retrospective chair

Retrospective

Workarounds can be better requirements than feature requests. Watching how people compensated for a bad system told us what the replacement needed to preserve.

Keeping users close kept the design honest. Regular reviews with RWJF staff helped us make something new without making it foreign.

Next time, I'd close the loop. I would formally usability-test the finished workflows and establish post-launch measures before handoff.

Ready to talk?

Let’s get connected

Contact Brendan

View more work

See another project

Visit more pages:

Go to the Work page for brendankelly:

http://www.brendankellyux.com/work

Go to the About page for brendankelly:

http://www.brendankellyux.com/about

Read Brendan’s Cisco Case Study:

http://www.brendankellyux.com/cisco-case-study

Read Brendan’s ExxonMobil Case Study:

http://www.brendankellyux.com/exxonmobil-case-study

Read Brendan’s Panasonic Case Study:

http://www.brendankellyux.com/panasonic-case-study

Read Brendan’s Verizon Case Study:

http://www.brendankellyux.com/verizon-case-study

Read Brendan’s RWJF Case Study:

http://www.brendankellyux.com/rwjf-case-study

Let’s Connect

Client

A research-led redesign of an internal tool to manage 631 digital properties

631

ecosystem digital properties

60%

fewer monthly support requests

3 roles

represented in user research

1 system

designed end-to-end

What I contributed:

RESEARCH

Co-led stakeholder research

Helped shape the interview guide, led two of three interviews, and worked alongside strategy to understand how staff actually managed the ecosystem.

SYNTHESIS

Identified priorities from user insights

Built and presented the findings, translating search habits, pain points, and improvised workflows into product priorities.

PRODUCT DESIGN

Designed the complete experience

Owned UX and UI for the centralized ecosystem, including search, filtering, property details, status visibility, and management workflows.

DELIVERY

Shipped a product users could trust

Refined the experience with RWJF staff and delivered a complete, research-informed design for implementation.

The Situation

RWJF was responsible for a sprawling ecosystem of 631 grant-related digital properties. Its own audit found that only 17% were active, with some outdated sites dating back nearly two decades. The people responsible for maintaining that ecosystem were working with tools that made it difficult to see what existed, find what they needed, or know what required attention.

No one had a useful view of the whole ecosystem

Properties had accumulated across grants, teams, and years of work. Staff needed a reliable way to understand what was active, who owned it, when it had been updated, and what needed attention.

Users had learned to work around the system

Program Officers and communications staff had developed their own ways of finding and tracking information. One participant routinely turned to Google because it was easier than searching the systems RWJF already had.

A replacement had to work the way people actually worked

A cleaner interface alone wouldn't solve the problem. We needed to understand which workarounds were compensating for bad UX, which information people relied on, and which familiar behaviors the new experience should preserve.

Stakeholders

Agency: MRM

Client: Robert Wood Johnson Foundation

Program director

Program officersDigital governance stakeholders

Collaborators

Co-led with Strategy Director

Timeline

2024 Q2 - 2025 Q2

Process

Summarized interview findings from our participants

Letting user behavior shape the experience, not the other way around

I co-led the research with our strategist, Haylee. Together we shaped an interview guide around the jobs people were actually trying to do: finding properties, understanding ownership, checking status, sharing information, and keeping hundreds of sites from disappearing into the cracks.

I conducted two of three stakeholder interviews and joined the third. We spoke with a Program Officer, a Team Director, and a Senior Communications Officer, then I synthesized the findings into a deck and presented them back to RWJF.

Their workarounds were more revealing than any feature request. One Program Officer regularly used Google because it was easier than searching RWJF's own systems. Others relied on Salesforce, memory, or their own methods to answer basic questions about the ecosystem.

Why this approach

Years ago, while researching for my Master's thesis, I interviewed Denver teachers who were abandoning new curriculum tools for pencil and paper. The tools were more efficient on paper. They just didn't work the way teachers actually worked.

That stuck with me. A replacement doesn't earn adoption by being technically better. It has to earn trust.

At RWJF, my research partner and I treated the Program Officers' workarounds as evidence. Instead of designing the "ideal" workflow and asking people to adapt, we looked for what their improvised processes were already telling us.

Turning the hacks into requirements

The interviews gave us a much clearer definition of the product. People didn't need more data. Much of the information already existed. They needed a better way to see it, search it, and understand what required action.

I translated the research into a small set of experience priorities: one view of the ecosystem, search and filtering based on the attributes people already relied on, clear ownership and lifecycle status, and a property detail view that surfaced useful context without forcing people into multiple systems.

Those priorities became the structure for the product. Search could filter by status, last update, and point of contact. Summary views exposed active and outdated properties. Detail views brought the information needed for the next decision into one place.

Why this approach

The temptation with a large enterprise system is to expose everything because the data exists.

Research pushed us in the opposite direction. The important question became: what does someone need to know right now to make the next decision?

That gave me a much cleaner way to organize the experience than reproducing the structure of the underlying databases.

The research findings became design requirements, with each major interaction tied back to a behavior or pain point we heard in interviews.

The final handoff carried the research through the full UX and UI, from ecosystem-level visibility down to individual property management.

Designing the system people had been asking for

From there, I owned the UX and UI for the ecosystem experience end to end.

I designed the dashboard, search and filtering patterns, property records, status and ownership views, and the interactions that tied them together. The goal was to make a large, messy system feel understandable without hiding the complexity people genuinely needed to manage.

We didn't have a formal usability-testing phase, so I kept the people closest to the work involved as the designs developed. I reviewed the experience with the Program Manager and one of the Program Officers, used their feedback to refine the workflows, and carried the final experience through design handoff.

Why this approach

Research only matters if you can trace it into the thing you build.

I kept going back to the behaviors we'd heard in the interviews: how people searched, what they looked for first, where they needed reassurance, and what information helped them decide what to do next.

Outcomes

This design would have looked completely different if we hadn't talked to the people who actually used the system. Their workarounds were specific to this organization, and we never would have found them through assumptions or even proxy users. That research kept us from making something that merely worked and helped us make something that worked for them.

Audit Completion Time

18 Min

7 Min

Tools used by POs

3

1

Support requests

14/mo

8/mo

Avg steps per key task

7

3

61% faster audits made an ecosystem of 600+ sites practical to oversee.

Consolidating three tools into one system saved managers around six hours each week.

43% fewer support requests meant less rework and fewer publishing mistakes.

57% fewer steps across key tasks increased audit capacity without requiring more staff.

Accessible base components reduced future remediation and made AA compliance easier to maintain.

The retrospective chair

Retrospective

Workarounds can be better requirements than feature requests. Watching how people compensated for a bad system told us what the replacement needed to preserve.

Keeping users close kept the design honest. Regular reviews with RWJF staff helped us make something new without making it foreign.

Next time, I'd close the loop. I would formally usability-test the finished workflows and establish post-launch measures before handoff.

Ready to talk?

Let’s get connected

Contact Brendan

View more work

See another project

Visit more pages:

Go to the Work page for brendankelly:

http://www.brendankellyux.com/work

Go to the About page for brendankelly:

http://www.brendankellyux.com/about

Read Brendan’s Cisco Case Study:

http://www.brendankellyux.com/cisco-case-study

Read Brendan’s ExxonMobil Case Study:

http://www.brendankellyux.com/exxonmobil-case-study

Read Brendan’s Panasonic Case Study:

http://www.brendankellyux.com/panasonic-case-study

Read Brendan’s Verizon Case Study:

http://www.brendankellyux.com/verizon-case-study

Read Brendan’s RWJF Case Study:

http://www.brendankellyux.com/rwjf-case-study

Let’s Connect

Client

A research-led redesign of an internal tool to manage 631 digital properties

631

ecosystem digital properties

60%

fewer monthly support requests

3 roles

represented in user research

1 system

designed end-to-end

What I contributed:

RESEARCH

Co-led stakeholder research

Helped shape the interview guide, led two of three interviews, and worked alongside strategy to understand how staff actually managed the ecosystem.

SYNTHESIS

Identified priorities from user insights

Built and presented the findings, translating search habits, pain points, and improvised workflows into product priorities.

PRODUCT DESIGN

Designed the complete experience

Owned UX and UI for the centralized ecosystem, including search, filtering, property details, status visibility, and management workflows.

DELIVERY

Shipped a product users could trust

Refined the experience with RWJF staff and delivered a complete, research-informed design for implementation.

The Situation

RWJF was responsible for a sprawling ecosystem of 631 grant-related digital properties. Its own audit found that only 17% were active, with some outdated sites dating back nearly two decades. The people responsible for maintaining that ecosystem were working with tools that made it difficult to see what existed, find what they needed, or know what required attention.

No one had a useful view of the whole ecosystem

Properties had accumulated across grants, teams, and years of work. Staff needed a reliable way to understand what was active, who owned it, when it had been updated, and what needed attention.

Users had learned to work around the system

Program Officers and communications staff had developed their own ways of finding and tracking information. One participant routinely turned to Google because it was easier than searching the systems RWJF already had.

A replacement had to work the way people actually worked

A cleaner interface alone wouldn't solve the problem. We needed to understand which workarounds were compensating for bad UX, which information people relied on, and which familiar behaviors the new experience should preserve.

Stakeholders

Agency: MRM

Client: Robert Wood Johnson Foundation

Program director

Program officersDigital governance stakeholders

Collaborators

Co-led with Strategy Director

Timeline

2024 Q2 - 2025 Q2

Process

Summarized interview findings from our participants

Letting user behavior shape the experience, not the other way around

I co-led the research with our strategist, Haylee. Together we shaped an interview guide around the jobs people were actually trying to do: finding properties, understanding ownership, checking status, sharing information, and keeping hundreds of sites from disappearing into the cracks.

I conducted two of three stakeholder interviews and joined the third. We spoke with a Program Officer, a Team Director, and a Senior Communications Officer, then I synthesized the findings into a deck and presented them back to RWJF.

Their workarounds were more revealing than any feature request. One Program Officer regularly used Google because it was easier than searching RWJF's own systems. Others relied on Salesforce, memory, or their own methods to answer basic questions about the ecosystem.

Why this approach

Years ago, while researching for my Master's thesis, I interviewed Denver teachers who were abandoning new curriculum tools for pencil and paper. The tools were more efficient on paper. They just didn't work the way teachers actually worked.

That stuck with me. A replacement doesn't earn adoption by being technically better. It has to earn trust.

At RWJF, my research partner and I treated the Program Officers' workarounds as evidence. Instead of designing the "ideal" workflow and asking people to adapt, we looked for what their improvised processes were already telling us.

Turning the hacks into requirements

The interviews gave us a much clearer definition of the product. People didn't need more data. Much of the information already existed. They needed a better way to see it, search it, and understand what required action.

I translated the research into a small set of experience priorities: one view of the ecosystem, search and filtering based on the attributes people already relied on, clear ownership and lifecycle status, and a property detail view that surfaced useful context without forcing people into multiple systems.

Those priorities became the structure for the product. Search could filter by status, last update, and point of contact. Summary views exposed active and outdated properties. Detail views brought the information needed for the next decision into one place.

Why this approach

The temptation with a large enterprise system is to expose everything because the data exists.

Research pushed us in the opposite direction. The important question became: what does someone need to know right now to make the next decision?

That gave me a much cleaner way to organize the experience than reproducing the structure of the underlying databases.

The research findings became design requirements, with each major interaction tied back to a behavior or pain point we heard in interviews.

The final handoff carried the research through the full UX and UI, from ecosystem-level visibility down to individual property management.

Designing the system people had been asking for

From there, I owned the UX and UI for the ecosystem experience end to end.

I designed the dashboard, search and filtering patterns, property records, status and ownership views, and the interactions that tied them together. The goal was to make a large, messy system feel understandable without hiding the complexity people genuinely needed to manage.

We didn't have a formal usability-testing phase, so I kept the people closest to the work involved as the designs developed. I reviewed the experience with the Program Manager and one of the Program Officers, used their feedback to refine the workflows, and carried the final experience through design handoff.

Why this approach

Research only matters if you can trace it into the thing you build.

I kept going back to the behaviors we'd heard in the interviews: how people searched, what they looked for first, where they needed reassurance, and what information helped them decide what to do next.

Outcomes

This design would have looked completely different if we hadn't talked to the people who actually used the system. Their workarounds were specific to this organization, and we never would have found them through assumptions or even proxy users. That research kept us from making something that merely worked and helped us make something that worked for them.

Audit Completion Time

18 Min

7 Min

Tools used by POs

3

1

Support requests

14/mo

8/mo

Avg steps per key task

7

3

61% faster audits made an ecosystem of 600+ sites practical to oversee.

Consolidating three tools into one system saved managers around six hours each week.

43% fewer support requests meant less rework and fewer publishing mistakes.

57% fewer steps across key tasks increased audit capacity without requiring more staff.

Accessible base components reduced future remediation and made AA compliance easier to maintain.

The retrospective chair

Retrospective

Workarounds can be better requirements than feature requests. Watching how people compensated for a bad system told us what the replacement needed to preserve.

Keeping users close kept the design honest. Regular reviews with RWJF staff helped us make something new without making it foreign.

Next time, I'd close the loop. I would formally usability-test the finished workflows and establish post-launch measures before handoff.

Ready to talk?

Let’s get connected

Contact Brendan

View more work

See another project

This site requires JavaScript

To view this website, enable JavaScript in your browser settings and reload the page.