For the past 25 years, Bullhorn has dedicated itself to building industry-leading, cloud-based software for the staffing and recruitment industry. Through partnerships with 10,000 customers globally, Bullhorn has built a vast knowledge base of recruitment best practices and deep domain expertise to help firms scale their businesses. Founder-led and headquartered in Boston, Bullhorn employs 1,600 people across 14 countries focused on delivering an incredible customer experience, its core mission.

My Role

As UX Manager at Bullhorn, I manage a team of eight UX designers and am responsible for the UX across all Bullhorn products. The product portfolio is a large offering of solutions, both home-grown and obtained by acquisition.

I am responsible for the UX on the following products:

Career Progression Documentation

One of the first projects I took on as UX Manager was building a career progression framework for the team. The framework defines progression expectations on both the IC track (Designer through Principal) and the Manager track, with depth at each level: competencies, behaviors, and the kinds of outputs that signal readiness to advance. It also bridges UX-specific expectations with Bullhorn's broader leveling, so my designers can be evaluated fairly against company norms while still being held to the standards of the discipline.

This year I updated the framework to integrate AI fluency expectations across every role level. The discipline is changing faster than career documents typically track, and the team's growth path needs to reflect the skills they actually need going forward, not the skills the role required when the document was first written.

Growing the Team

The framework defines the destination at each level. The day-to-day practices that get designers there are where I spend most of my time. I run a full annual review cycle for each direct report, pairing performance evaluation with SMART goal-setting that ties to both individual development and team outcomes. The 1:1s with each designer are where most of the actual coaching happens, week by week.

Direct feedback delivered with care is a craft I treat as one of my own ongoing growth areas. I am explicit with the team about that, partly because giving and receiving feedback is a skill they are developing too, and partly because being open about my own growth invites them to do the same.

Resources and Standards

Each team member brings different experience and skills to Bullhorn, and consistency in how we operate is something I have to design for rather than assume. I have built a set of internal resources to support this: standards documentation covering practices like research facilitation and findings reporting, technical references for designers building their coding skills, and templates for the documents and decks we share internally and with stakeholders. These resources level up the team's baseline and free individual designers to focus their energy on the work itself rather than on reinventing scaffolding.

The BHUX Academy

To promote continued learning and keep the team aligned on key topics, I created an Academy to house our standards documentation and assess the team's comprehension across the subjects. The Academy is a platform I developed to be educational and fun at the same time. It pairs valuable content and quizzes with a humorous, gamified presentation that promotes friendly competition and a more memorable experience. I developed six interaction patterns to vary the quiz content and keep engagement high.

The Academy and the standards documentation it houses have been well received on the UX team. They have also been valuable in building the reputation of UX across the rest of the Bullhorn org, since they promote transparency and communicate UX's function and value clearly.

Cross-Functional Leadership

UX delivers value when it is embedded in the broader product organization, not when it operates as a service desk. I work closely with leaders across Product, Engineering, and Customer Success on shared roadmaps, joint research, and the operating model that determines how design work moves through the company.

A few examples of that work in practice:

• I run a leadership UX review that brings cross-functional leaders together on a recurring basis to align on design direction and surface blockers early.
• I established an agreed-upon design process with Product and Engineering, and worked through the Jira process itself to guarantee design is inserted at the proper stages of every project, rather than being asked to catch up after decisions have already been made.
• I initiated the Silver Bull peer recognition program for the Product organization, which gives anyone in Product a lightweight way to recognize colleagues for work that often goes unseen, and has become part of how the team marks contributions across functions.

The BHUX Intranet Site

To raise the visibility of UX inside Bullhorn and make the team's work more accessible to the rest of the org, I created an intranet site that serves as both a showcase and a knowledge hub. It details the team's capabilities and the services we offer, so any team in the company can see what UX can do for them. The site also catalogs our research findings, leadership meeting recordings, the full persona deck, and the interactive tools we have built around the personas.

The site is hand-coded throughout. I built most of it myself, with additional sections contributed by team members as I taught them HTML, CSS, and JavaScript. It doubles as a learning platform for designers building their coding skills, and as a playground where we experiment with design and interaction patterns before bringing them to product work.

The intranet has been an important channel for the UX team's profile across Bullhorn. It gives partners in product, engineering, and customer success a clear view of what we do and lowers the friction of bringing UX into new initiatives.

How I am using AI at Bullhorn

Two projects from my work leading the BHUX team that show how AI shapes my UX practice today. One turns research into a dynamic part of product development. The other makes the prototype itself the decision tool. The tooling is changing fast, so this is where the practice is today.

Persona refresh and operationalization

Bullhorn's existing personas were five years old and not informing product decisions. The deeper problem was structural: they sat on a wiki where nobody consulted them at the moments they would have mattered.

I used AI as a co-author rather than a drafting assistant. Claude and Gemini independently generated fresh persona sets for the current Bullhorn suite. Each model then examined three sources side by side: its own draft, the other's draft, and our existing five-year-old personas. After several rounds of cross-model critique, I had a draft set ready for SME validation.

The critique loop. Each model evaluated all three sources before recommending changes.

I validated through 20-plus interviews with Customer Success reps, Product Managers, and leadership. The central deliverable across the series was a persona deck, one slide per persona, each with an AI-generated headshot produced in Gemini for visual consistency. AI wrote the research script, consolidated session data, and updated the deck after each interview so the personas evolved across the series. Where SMEs gave conflicting input, AI surfaced the conflict and recommended a consensus position with visible reasoning. The final set was 19 personas covering the Bullhorn suite.

Building Custom AI Tools for the Team

The more interesting work began once the personas existed. To make them dynamic rather than static, I built three tools using Claude as a coding partner:

• A persona chat experience. Anyone in the org can ask questions to a specific persona and get answers in that persona's voice.
• A persona recommendation tool. The user supplies a feature description, requirements doc, or Jira story, and the tool returns the personas most important to consider, with reasoning.
• A persona design feedback tool. The user provides screenshots or a URL and a chosen persona responds with that persona's assessment of the design.

What makes these tools more valuable than a typical persona document is that all three have the full interview transcripts loaded as context. The nuance and minority views that did not make the final deck are still in play when the tools generate answers. A persona giving design feedback is not reciting summary attributes, it is drawing on what an actual recruiter said about her day. The personas become a dynamic part of the product development process rather than a static artifact you hope people will reference.

AI-assisted prototyping for design decisions

Static comps make poor decision tools. They look done before they behave done, so user feedback stays shallow. They freeze options in time, so stakeholder reviews circle the same choices. AI-assisted coding lets me build interactive prototypes fast enough that the prototype itself becomes the iteration medium.

The larger of these has been a modernization exploration of the Bullhorn ATS. The product's design system is several years old, and we needed to determine what to change, add, or update to align with current UI and UX conventions. I worked across Claude, Gemini, and ChatGPT to evaluate options and generate ideas, alongside directional input from leadership. I then built a working prototype with Claude, where the build itself was an ideation loop. Claude proposed design solutions, I evaluated them against the design intent and redirected, and the prototype emerged through that exchange rather than from a pre-set design.

The most valuable feature was a control panel built into the prototype that lets viewers toggle options and design treatments on and off. Instead of walking stakeholders through static comp variations in sequence, I could put the prototype in a meeting, switch between treatments live, and let the discussion converge on a direction. The exploration moved from a vague modernization brief to a concrete vision that Product is now taking forward with engineering and the user base.

The prototype is not the deliverable. The decisions it unlocks are.

Across the rest of the work

Beyond these two projects, AI shows up across the team's day-to-day practice. Designers and researchers use it to take notes during user sessions, consolidate findings across studies, surface themes that would otherwise sit buried in raw data, and generate ideas for follow-up exploration. The Search and Match Next Gen research, where I ran 11 sessions across three prototype iterations with junior recruiters, leaned on AI heavily in that synthesis loop. On the management side, I use AI to draft and pressure-test team goals, performance feedback, and the BHUX career framework as it evolves.

The space is moving fast and I am genuinely excited about where it is heading. At the same time, I treat the current generation of tools with clear eyes about what they do well and what they do not. The goal is not to use AI everywhere it could plausibly fit. The goal is to use it where it raises the quality of the work the team ships, and to keep adjusting that line as the tools change.

Background

My role at Johnson & Johnson is quite varied and dynamic. The division I am part of was previously a small start-up that was acquired by J&J and so there is a blend of start-up and corporate methodology and culture. As such, my role as Sr. Manager of UXUI Design encompasses a broad range of responsibilities, from direction and team management to individual contributor.

The primary products my team is responsible for are what make up the C-SATS platform. C-SATS is designed to help surgeons of all levels improve their proficiency through performance analytics, self-learning opportunities, and peer-to-peer interactions. This platform consisted of a SaaS web app, a mobile app, and an in-OR device.

The web app and OR device are products that originated in 2014, before my tenure. Since joining J&J I have been responsible for a redesign and designing for new features. With a small team, we were able to accomplish results most thought could only be done with a larger team and budget. This was possible because of the full spectrum set of skills and experiences I brought to the team, and the positive and cooperative team environment I was able to foster. Below is an exploration of highlights of this project from a process and systems perspective.

The Product Family

The three main products my design team is responsible for are a SaaS web app, a mobile app, and a device based in the OR to facilitate the recording and uploading of surgeries.

Working Together

Creating software is a collaborative endeavor. Software production for the C-SATS platform can be visualized as a three-legged stool, where each team, Product Management, Design, and Engineering, work closely together to support the development and support for the product. Each discipline's engagement is vital for assuring a quality product and positive user experience.

I worked closely with Product Management and Engineering to develop the following process for feature development. This process maintains our user-centered approach while accommodating real world requirements from the business and development stakeholders.

Demo / Prototype

At the core of our teams alignment on product vision is the C-SATS Demo. The fully functional demo is a design and interaction sample, a source of CSS and code for engineering, and a demo environment for the Commercial and Support teams. I created and maintain the demo by writing raw HTML, CSS, and JavaScript. Its functionality far exceeds prototypes that can be created in tools such as Figma, XD, or Axure, and is less time and resource intensive.

The Demo is configurable to accurately emulate the experience for all user types and personas. It also is used to test out design solutions and act as an accurate and contextual platform for usability testing.

The C-SATS Demo is source of truth for the design team and our cross functional partners.

Design System

The design system I developed for C-SATS is more integrated and complete than you'll typically find. It lives in the C-SATS Demo which assures the design samples and system remain in-sync. It also has direct mapping to an npm (node package manager) that our software engineering team uses for development. This shared component model between the system ensures standardization across design and build.

Our design team also utilizes the Design System and references to keep patterns uniform and minimal. In our design specs, designers will name patterns using the shared component name used in the Design System and shared component library. This promotes consistency, reusability, and engineering efficiencies.

UX Team Artifacts

The UX team hands off two deliverables to Engineering: The Spec and the interaction, visual design, and code samples in the Demo. The UX spec (produced in Figma, or XD) writes out the interaction and display scenarios, contains all variations of language, and references shared components. Each of these artifacts references, and potentially creates references in, the Design System and Product requirements doc.

Keeping the User at the Center

My design team has many contacts with our end users at every stage of product and feature development. Our initial user research helps guide product management in deciding what to build. We then test solutions with representative users in a repetitive and cyclical process refining as we go, until we have high confidence in our solution. We also have multiple avenues of contact with our users once the feature is built to verify it works as expected.

My responsibility as head of the design group for Digital Solutions at J&J is to advocate for the user, illuminate their needs to the business, and find realistic and pragmatic ways to achieve both user and business satisfaction.

Summary

What I describe above is a process and system that was optimal for the C-SATS product suite. This solution and combination of processes is not necessarily the right fit for all product teams. My philosophy is to optimize for the situation and adapt appropriately and pragmatically so we make the best product possible within the given circumstances. For C-SATS, this described system is that.

The Challenge

Safeco / Liberty Mutual Insurance needed to migrate off an end-of-life back-end platform that was the backbone for all their enterprise and B2B applications. The organization charged the Safeco Online Experience team (my team) to redesign the entire suite of tools.

These tools accounted for a total of 15 billion dollars in annual revenue. Getting this right for both the Liberty Mutual captive agents, and the Safeco independent agents was imperative.

My Role and Responsibilities

Principal UX/UI Designer

• I directed and managed a team of FTE and contract UX designers (fluctuating between 7 and 14 people over 3.5 years)
• I helped guide and participated in user research
• I set the core design standards and designed the core UX and UI patterns used throughout the suite of tools.
• I created and maintained a toolkit of pattern samples and a full working prototype of the portal site that was used in requirements refinement and usability testing.
• I designed and participated in usability tests and evaluations.

The Approach

Discovery / Empathizing

We began with a large research project. We sent about twenty people (including myself) from the business group and IT, in groups of two, to visit with agents all around the country. We observed them work and interviewed them about their likes and dislikes in our current system.

Competitive Analysis

There are strict rules in the regulated insurance industry around accessing competitors' business systems. We could not ask directly about our competitors' solutions, but we did catalog general pain points and experiences that our users volunteered on their own. This data was included in our analysis.

We distilled all aquired data to suss-out high level themes with affinity mapping exercises.

Key Observations and Insights

• Users do lots of multi-tasking
• Too many active windows on screen
• Suite of tools are siloed and require separate logins and windows.
• Agents don’t want to learn new tools (don’t like change)
• Have learned workflow around current tools’ issues
• Think Safeco tools are best in class (“don’t change it”)
• Speed is crucial.
• After price, ease of use of the quoting and servicing tools is most important criteria for independent agents in selecting what insurance line to sell.

Synthesis

• Single window experience desired
• Make system customer-centric instead of policy-centric
• Reduce number of clicks to dive deep
• Tie multiple backends into one front end experience.

With this data I worked with our team to create personas to represent our end users.

Defining

To address our findings from research, we defined a new desired architecture that would help alleviate many of the pain points we discovered. Working closely with Software and Business, we defined the following new underlying framework architecture.

This new architecture was a portal type experience. In order to define a sitemap for the portal we utilized surveys, card sorting, and tree testing exercises with end users and internal SMEs.

Ideate, Prototype, Test

With this knowledge in hand we set about conceptualizing the new Agent Portal. We worked with internal SMEs to define key user needs and workflows. As soon as we felt we had a high-level structure in place for the portal, we began our first usability testing, initially using very basic wireframes.

As the testing and evaluations progressed, the prototypes advanced in complexity and detail. In addition to feature prototypes my team built in Axure, I constructed a holistic prototype of the entire portal. To learn more about this project, see the “Explore the Prototype” link below.

We conducted these first few tests within our lab in the office. We invited agents in to try some basic tasks. As we progressed, our ability to get participants to come in person became more challenging. Although not as ideal, we moved to a remote testing model to help accommodate our busy participants work schedules. We initially used Lync and it’s screen sharing/control feature, and later moved to GotoMeeting.

In total we conducted over 30 formal usability studies of user workflows using new designs of the portal and individual features. Each study consisted of between 10 and 12 end users.

The insights gained were invaluable. The cycle of integrating findings and retesting resulted in a robust, intuitive and extensible solution.

The Solution

The one window portal solution combined all content with servicing tools in one window.

The initial release of the new portal required the servicing apps to live in a separate window. This was a software framework limitation that was discovered late in the project. Adaptations were made to make this and the future migration to the target one window UI as seamless as possible. The examples below show the solution for customer servicing tools living in a child window of the parent Safeco Now portal.

The quoting tools are the “cash register” of the business. This tool is a tool our users will use several times day. It needed to be easy to master quickly but also efficient for the power user.

The screen below represents the design solution for a popular user request. Agents wanted to see all autos in a policy side-by-side. This design accommodates that request in a responsive and fluid layout. Results from testing were very positive.

All statuses of the quote are kept in the right gutter. This allows for detailed messaging without distracting the flow of operation.

Helper characters for selling advice had been used on the previous system. User research found they were well received and desired.

Measuring Results

The new software was put through UAT (User Acceptance Testing) prior to release. Some issues around performance were found that needed a front-end solution to mitigate the impact. We made rapid iterative changes during the UAT process to address the situation until it passed acceptance.

We also did workflow/task analysis between the current system and this new one. We measured time to completion and satisfaction. Despite having experience with the current system, for most workflows users were able to complete tasks quicker on the new system and with higher satisfaction than our current offering.

After passing UAT, the new platform began its nation wide rollout. This was planned as a gradual state-by-state rollout over the course of three years.

Background

The R&D group within J&J MedTech, in coordination with our internal clinical team, were working with our extensive set of our recorded surgeries to explore and discover what insights could be derived utilizing machine learning. This was an exploration to find both what could be revealed, and what would be valuable to our end user surgeons and medical professionals. Several ML models had been created and were at various stages of maturity. These were basically proofs of concept to evaluate what could be done.

The Challenge

My team was tasked to help guide where R&D resources should be prioritized. Developing these ML models would be a large investment of resources, so this research was seen as vitaly important to determine the right direction to move forward in.

These new models would be surfaced in our C-SATS SaaS app, so user-facing solutions would need to be contextualized inside of that experience. Finding the right balance of what data is interesting, valuable, and grokable for our very scientifically minded users would be crucial. They are not the type of user that would be impressed by data unless it had demonstrated value. Displaying data that was not backed up by demonstrated value would damage our reputation and their confidence in our product.

My Role and Responsibilities

• Lead Designer
• Study Designer
• Study Facilitator
• Stimuli Creator
• Prototype Builder

The Approach

As I evaluated the request from R&D, I realized that there were really two connected evaluations we needed to make with users. One was whether the data in general would be useful, and the other was what display of data made sense. We would need to have a variation of display solutions and contexts to get relevant feedback.

The additional design challenge was to take the best performing designs and find a way of integrating those solutions into the existing UX/UI of the site in way that was efficient and contextualize appropriately.

Discovery / Empathizing

When I first engaged with the team for this project, I was given a list and samples of the areas that R&D and clinical had identified as ML models of value and feasibility. My first order of business was to deep dive into the models to get a deeper understanding of how they worked, and what they were comprised of. I also needed to interview our clinical specialists to understand their reasoning for flagging these areas as potentially valuable for our users.

My high-level inputs an outputs for this project looked like this:

From my interviews with Clinical and Engineering, I uncovered the following findings

• Some data had potential value only on individual cases
• Some data had potential value only on a collection of cases
• Some data had potential value on both individual cases and collections
• Some data only made sense when contexualized in a timeframe inside a case
• Some data had higher confidence rates than others
• Some data might have higher value when combined with others

Utilizing data collected from my internal SMEs, I took a first pass at designing some visualizations, patterns, and interactions for the data. Many had multiple variations of display and integration into the platform.

A small sampling of the individual data visualization patterns:

After validating our understanding of the data, and initial analysis of the validity and value of the designs with SMEs, I went about designing the user evaluation series to be conducted with actual users of the platform.

User Interviews

The UX research method I chose was user interviews with stimulus reaction. To fully understand our users reaction to the stimulus being presented, I asked each user to rate each sample on both the value of the data represented, and then on the comprehensibility of the visualization. In addition I asked them to explain the rating, so as to capture more granular reasons for their reaction.

The stimulus was comprised of both static shots of visualizations in isolation, as well as some in context of the UI.

The Results

Key Observations and Insights

The design and methods of this study proved to be quite successful in revealing important information regarding what users found useful, how they wanted to visualize it, and what additionally they wanted to know about their cases. Some key general findings were:

• Some data valuable to early career surgeons, but not valuable at all to later career surgeons
• More advanced surgeons increasingly valued a combination of metrics and context over standalone metrics
• Visualizations which reveal patterns and orders in practice were valued for standardizing personal processes or teaching trainees.
• Almost everyone found value in relating metrics data to specific points in the video of the procedure, and in combination with other metrics
• Some metrics were only valuable for certain specialties and not for others

As reflected in the samples below, Displaying high-level info with the ability to drill in was a much desired display, to prevent an overwhelming amount of data, while still capturing main themes.

The video timeline design I created was the most appreciated and desired design solution in the study. The solution elegantly displays a very complex set of data in a quickly digestible visual display. The collapsed version suffices for the majority of the time, but gives enough indication if there is additional valuable data upon expansion.

Study Recommendations

Some general recommendations we made after analyzing the study data were:

• Use progressive disclosure of metrics data to allow user to grasp high-level info and drill in at their discretion.
• Show metrics in context with others that are relevant (e.g. Idle time in relation to Op time)
• Link metrics together to reveal correlations between actions, choices, and results (connect the dots for users – why does it matter?)
• Support optimization and/or customization of comparisons and visualizations (e.g. who is a peer, expert selection, and overall or deltas)

Debreif

There were definitely some surprises for our product and engineering teams coming out of this study. Some models that were thought to be very valuable to our end user surgeons just weren’t that impressive to them after all. What was a revelation was that stitching these models together and identifying trends on the combination of models was the desired state for most.

Coming out of this design and research phase, the cross functional teams together identified several roadmap items for product enhancements, and re-prioritization R&D projects in the Machine Learning work. We also approached the phased implementation UX strategy with clarity on what would constitute an MVP release for each phase.

Personal Reflection

I am very proud of what I accomplished in this project, the impact it had, and the appreciation I received. To be able to bridge a connection and solution between three very complex disciplines (machine Learning engineers and researchers, medical clinical experts, and surgeons), and successfully design UX solutions to the satisfaction of all parties involved is an achievement I won't forget, and one that I take the lessons learned forward with me.

Moving Forward

Post study, I was involved in many cross-functional discussions on prioritizing the work going forward. With solid data in hand, I was able to negotiate an acceptable path forward, from the perspective of our users.

The first feature to be released following the study was the Stapling ML model. This was an initial pared down version of what we tested, and what was put on the roadmap. Scope was reduced for technical and timing reasons, but we were confident in this MVP's value, because of the extensive study that was performed.