Helping employees feel seen
Designing a social recognition experience that grew from a week-long sprint into a core Fringe product—and eventually became the foundation for a larger partnership with ADP.
Fringe started primarily as a place employees went to receive points and spend them in a marketplace. Recognition asked a different question:
Could Fringe become a place where employees actually connected?
The original discovery work framed the problem in human terms: employees didn’t always feel seen in ways that were meaningful to them. Recognition could mean acknowledging someone’s work, celebrating a milestone, reinforcing their growth, or simply showing that their contribution mattered.
I helped take that problem from a week-long design sprint through prototyping, user testing, product design, and launch. What began as a social feed inside Fringe eventually became much more: a foundation for how thousands of users coming through ADP would first encounter Fringe.
Role
Senior Product Designer
Senior Product Designer
What I owned
Product design · UX/UI design · Prototyping · User testing · Interaction design · Product strategy · Cross-functional collaboration
Product design · UX/UI design · Prototyping · User testing · Interaction design · Product strategy · Cross-functional collaboration
Design sprint sketches explored recognition from several angles, including social feeds, manager reminders, AI-assisted shout-outs, recognition categories, GIFs, and team visibility. My feed concept became the foundation for the prototype we tested after the sprint.
Starting with “feeling seen”
Recognition was one of my first major projects after joining Fringe.
The discovery work started with a deceptively broad problem:
“I don’t feel seen in ways that are meaningful to me.”
Research suggested that “feeling seen” meant different things to different people. Sometimes it was about exceptional work. Sometimes it was about helping a teammate. Sometimes it had nothing to do with work at all.
The details mattered, too.
Who recognition came from mattered. Timing mattered. Some people valued public acknowledgment; others strongly preferred something private. Tangible rewards could make recognition feel more meaningful, but the wrong reward could also make the gesture feel less authentic.
For managers, another tension emerged: recognition needed to be easy enough to give in the moment without becoming so automated that it stopped feeling genuine.
The problem wasn’t simply how to send someone points.
It was how to make recognition personal, timely, expressive, and easy to give.
A week to find the idea
Our team used a week-long Product Operating Model design sprint to explore the problem. It was the first time I’d worked with the Fringe team this way, and I played the traditional designer role.
We explored a broad range of ideas: helping managers see who hadn’t been recognized recently, AI-assisted shout-outs, predefined recognition moments, different ways of celebrating accomplishments, and different approaches to delivering recognition.
My sketch took a different direction.
I imagined Recognition as a social feed.
Rather than treating recognition as a transaction hidden inside an HR tool, the feed could make appreciation visible and participatory. People could recognize a coworker, attach points when appropriate, react, comment, celebrate company values, and see recognition happening across the organization.
I started looking at familiar social products like Facebook and Twitter—not because Recognition needed to become social media, but because those products had already taught people how a feed behaves.
That gave us an interaction model people wouldn’t have to learn from scratch.
Friday sprint. Monday testing.
One problem with the schedule.
The design sprint ended Friday. User testing was scheduled to begin Monday.
There wasn’t really any design time between the two.
I left the sprint with a clear enough picture of the experience that I spent the weekend turning the paper concept into a testable Figma prototype. I pulled together familiar feed patterns and translated the sprint ideas into something users could actually react to.
By Monday, we had a working concept.
The interviews largely validated the direction and gave the team enough confidence to move forward.
The discovery-to-design cycle wasn’t long. It was closer to idea → prototype → evidence → build, compressed into days.
Over the weekend, I translated the sprint concept into a Figma prototype for Monday’s user testing. The early design established the social feed, sending flow, public and private recognition, filters, reactions, points, and team-based organization that would carry into the product.
Designing for different kinds of recognition
One of the most important decisions was allowing recognition to be public or private.
I pushed for that during the sprint because I’d seen the difference firsthand while managing teams. Public praise can be motivating for one person and deeply uncomfortable for another.
The research supported that distinction. Some employees valued company-wide visibility, while others preferred recognition to remain personal.
So we didn’t make visibility part of our definition of recognition. We made it a choice.
The same principle affected other parts of the experience. GIFs could make recognition more expressive and fun, but HR teams understandably had concerns about what might appear in a workplace product. We kept that expressive option while letting organizations turn GIFs off.
Company values also became part of the experience. Early concepts explored representing them with icons or emoji, but as we moved into implementation, we found that hashtags created a simpler, more flexible way to connect recognition to the values an organization wanted to reinforce.
The goal wasn’t to prescribe one “right” way to appreciate someone.
It was to create enough structure to make recognition easy without removing the personality that made it meaningful.
Designing in code
Once the concept was validated, I worked closely with DG, a front-end engineer who had previously been a designer, to move from Figma into production quickly.
I owned the end-to-end UX and UI, but the implementation was highly collaborative. DG understood the intent behind the prototype and could contribute ideas as he worked through the actual product.
Groups were one of those ideas.
Rather than forcing people to find the same coworkers repeatedly, users could create private groups of teammates and use them to organize the people they recognized regularly.
That wasn’t part of my original sprint concept. It emerged while we were building.
That collaboration made the product better—and reinforced something I value about product design: the design doesn’t stop when engineering starts.
Groups emerged during implementation through close collaboration with engineering, giving people a private way to organize teammates they recognized regularly.
From prototype to product
The shipped Recognition experience brought several ideas together in one system.
Employees could recognize one or more coworkers, write a personal message, attach points, connect the recognition to company values, include expressive content like GIFs, and choose whether the moment should be public or private.
The feed made those moments visible across the organization. Coworkers could react and comment. People could filter the feed, find recognition they had sent or received, and add points to recognition that resonated with them.
For HR teams and managers, Recognition could do something Fringe’s existing marketplace couldn’t:
It could turn points from something employees received into something people used to reinforce relationships and culture.
Shipping was only half the problem
Inside Fringe, Recognition caught on quickly.
The broader customer launch was slower.
In hindsight, that made sense. Before Recognition, employees didn’t have much reason to visit Fringe regularly. They might arrive when they received points, spend them in the marketplace, and not return for weeks.
Then Recognition appeared.
We designed a new behavior without doing much to introduce it.
I remember being asked why I thought adoption wasn’t stronger immediately. My answer was that we needed to promote the feature. Customers needed to know it existed, understand why it was useful, and have reasons to come back.
That was an important lesson.
A feature can be usable and valuable and still fail to become a habit if the product doesn’t create a path into it.
Recognition gradually gained traction, and Fringe later invested more intentionally in product engagement. The experience also shaped how I approached subsequent products like Challenges: shipping the interaction was only one part of creating engagement.
Learning from the product after launch
As Recognition matured, we continued looking at what helped—or prevented—people from participating.
Later research combined qualitative customer learning with product and engineering signals to distinguish several kinds of users: managers who naturally drove culture, managers who wanted to recognize people but forgot, skeptical managers, hands-on administrators, and administrators who preferred to set programs up and leave them alone.
One particularly useful moment was first-send uncertainty.
A manager might want to recognize someone and still hesitate:
What should I say?
How many points is appropriate?
What does recognition normally look like here?
How many points is appropriate?
What does recognition normally look like here?
That shifted the problem from simply making the composer easy to use toward helping people understand the social norms around using it. The research pointed toward starter language, points guidance, visible norms, and contextual nudges rather than more interface controls.
Launch hadn’t ended the design problem.
It had given us better questions.
Then ADP wanted Recognition
Fringe already had a strategic relationship with ADP when Recognition began gaining traction.
ADP was exploring a similar recognition capability. I don’t remember whether Fringe showed Recognition first or ADP raised the need first, but the connection happened quickly: Fringe already had a working product that could provide the foundation for what ADP wanted to build.
That changed the project's scale.
The core Fringe Recognition product remained relatively stable. But Recognition increasingly became the center of a much larger experience surrounding the ADP partnership.
The first practitioner experience was essentially a stripped-down version of Recognition, with navigation designed for ADP users and some Fringe-specific capabilities—such as Groups—removed.
From there, we began designing outward.
From feature to entry point
Recognition had originally been designed to help employees feel seen.
Inside the ADP relationship, it acquired another role:
It became a way to introduce HR practitioners to Fringe.
We designed a practitioner experience around the Recognition feed so someone encountering Fringe through ADP could understand what else the platform could do before committing to a broader relationship.
Over time, that grew into more complete landing and onboarding experiences. Recognition sat alongside concepts for analytics, company values, celebrations, funding and budgeting, and eventually Frankie, Fringe’s conversational AI experience.
The goal wasn’t to hide a sales funnel inside an employee feature.
It was to make the connection between the two products useful enough that Recognition could naturally lead an HR practitioner toward the larger Fringe ecosystem.
Later work explicitly explored how to move practitioners from Recognition into Fringe and how to make that transition valuable on both the first interaction and the tenth.
Recognition had become more than a feature.
It had become an entry point.
Recognition at a different scale
The larger ADP Connect program eventually reached roughly 11,500 activated accounts, 371 demo bookings, and 52 closed-won customers, with 64% of bookings described as product-led in the June 2026 analysis.
Those aren’t metrics I would attribute to Recognition alone.
They belonged to a broader system: ADP Recognition could lead someone through SSO into Fringe, where practitioner experiences created paths toward funding conversations and the larger product.
But Recognition's place at the start of that journey mattered.
What started as a sketch about helping employees appreciate each other became one of the primary ways a much larger audience encountered Fringe.
What Recognition taught me
Recognition started with a human question:
How do we help people feel seen?
The first answer was a social product. Make recognition visible when people want visibility. Make it private when they don’t. Let people add personality, connect appreciation to shared values, participate in someone else’s recognition, and attach tangible value when it makes the moment more meaningful.
But the more important lesson came after we shipped it.
Designing a useful interaction doesn’t automatically create a behavior. People need an invitation into something new. They need context, norms, reminders, and reasons to return.
And sometimes the most important outcome isn’t the one you designed for.
We didn’t begin Recognition intending to create an entry point into a larger platform partnership. We were trying to make Fringe a place where employees could acknowledge each other.
But the product proved useful enough to travel.
Recognition grew from a sprint concept into a shipped product, and from a shipped product into a capability that helped connect Fringe to a much larger ecosystem.
That changed how I think about product design.
A feature isn’t finished when the interface works.
Sometimes that’s when you finally get to see what the product can become.
