Benevity Workflow Manager

My Role

I acted as a player-coach across product, design, and research, responsible for:

• Problem framing, discovery, and ruthless prioritization.
• Facilitating cross-functional collaboration between UX, engineering, support, and a game-theory/automation expert.
• Designing the workflow manager experience (flows, interaction models, information architecture, and UX).
• Planning and running research (interviews, concept tests, prototype evaluations) with internal and external users.
• Driving stakeholder alignment through visuals, narratives, and regular demos.
• Training junior product designers on research and prototype testing.
• Sharing the project at an internal/external conference to broaden adoption and visibility.

Discovery

We started by mapping the reality of granting programs and the current implementation process, not just the “happy path.” Complex programs included conditional paths (e.g., nomination rounds, specialized reviewers, changing requirements over time) that were difficult to explain, document, or safely modify.

To establish a shared language, I introduced object-oriented UX framing to describe entities like applications, reviews, rules, and actions, then led workshops with stakeholders representing usability, feasibility, viability, and value. This made complexity discussable and gave us a foundation for design decisions.

Recognizing that understanding the domain was a prerequisite for building the right tool, I directed the creation of an internal infographic that visualized the end-to-end granting process. This artifact became training material for support, sales, and product, and was later reused in onboarding and client conversations.

Strategy

Our strategic shift was to move from “experts configure in code” to “experts and non-experts configure in a shared, visual language.” Inspired by best-in-class workflow tools, we anchored on these principles:

• Make workflows visible: every program should be understandable at a glance, even to someone new.
• Tell logical stories: rules, conditions, and actions should read like sentences, not system internals.
• Design for BREAD first (Browse, Read, Edit, Add, Delete) to keep early scope tight and improve safely.
• Start by listing and surfacing existing hard-coded workflows to build transparency before providing full editing power.

We also deliberately framed the project as an internal tool transformation: if the UX didn’t work for our own implementers, it wouldn’t work for clients later.

Design

We began by redefining the ideal interaction between client and Benevity employees. Instead of a back-and-forth over two weeks, we imagined a collaborative, near-real-time setup where both sides could see the same logic.

From there, I designed the first iteration of a Workflow Manager centred around rules:

• A rules list that mirrored how clients talk about their programs (e.g., “nomination rules,” “eligibility rules”).
• A rule-building interface using “if this, then that” patterns to align with how both implementers and developers already thought.
• Grouping, reordering, and scoping of rules so that complex programs still felt narrative and modular, not monolithic.

We worked in small slices of “BREAD” (Browse, Read, Edit, Add, and Delete):

Phase 1: Starting with the ability to “Browse” and “Read” only, list existing workflows and their key properties so they existed somewhere other than code. Simple, just presented as information at first.

Phase 2: Adding the ability to “Edit” and “Add,” allow safe edits to specific parameters within those workflows.

Phase 3: Enable “Delete,” and expand on the full creation, cloning, and management of workflows from scratch.

Prototyping & Testing

With a clearer product vision, we recruited:

• Internal implementers (CS & IM team members) who had lived the pain of coding workflows.
• Internal teams with experience using external workflow/automation tools.
• Stakeholders who would later be responsible for support, sales, and success enablement.

We tested low- and mid-fidelity prototypes, focusing first on comprehension:

• Can someone look at a workflow and tell a coherent story of what will happen?
• Can someone who did not create the workflow safely edit it without fear?

By continually tying flows back to simple narrative structures—conditions and actions forming logical sentences—we simplified complexity without dumbing it down. Testing revealed a shared enthusiasm for “if this, then that” mental models, so we leaned into that pattern heavily.

We iterated hundreds of blockframes, wireframes, diagrams, and prototypes, validating one area at a time (rules, steps, triggers, actions) before expanding scope. I intentionally avoided “big bang” reveals, opting for frequent internal demos and feedback loops so the system reflected how people actually thought and worked.

Solution

After multiple cycles, the Workflow Manager matured into an internal tool that:

• Visualized each client program as an understandable sequence of rules and actions.
• Allowed implementers to build workflows using a WYSIWYG rule builder instead of editing code.
• Encoded best practices directly in the UI, so good patterns were the default, not tribal knowledge.
• Created a shared artifact that support, sales, and product could reference when discussing changes or diagnosing issues.

The same artifacts we used to align internal teams—domain infographics, object models, storytelling patterns—became the conceptual backbone of the product’s interface.

Outcomes

The impact of the Workflow Manager was both operational and cultural:

• Average implementation time dropped from ~2 weeks to about 12 minutes for many programs.
• Support tickets related to “what does this program do?” and “how do I change this?” were significantly reduced, along with total support time.
• Employee engagement and product knowledge increased as non-developers could safely participate in configuring and improving programs.
• Client time-to-value decreased; they saw live, working programs much faster and could iterate more often.
• Knowledge of granting processes became durable and sharable, instead of locked in a handful of experts’ heads.
• CS team retention vastly improved with turnover falling to just 5%.

The project also served as a showcase for how thoughtful UX in internal tools can unlock automation, improve retention, and create leverage far beyond a single feature. I later presented the Workflow Manager at a conference, positioning Benevity as an example of what happens when you design automation around human understanding—not just efficiency.