Recognition at Fringe
Making employee recognition a more natural part of the workday.
I helped take Recognition from an internal design sprint to a shipped product, creating an experience that lets employees celebrate one another and strengthening its integration with ADP.
Role: Senior Product Designer
Focus: Product strategy · UX/UI design · Integrations
Outcome: Shipped recognition experience with ADP integrations
ADP Connect experiment results
+11.2%
Lift in Terms of Use acceptance in an ADP Connect experiment
4,584
Users included in the experiment
Helping employees feel seen
Fringe started as a place where employees earned points and spent 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.
The opportunity was to make recognition a natural part of the employee experience—not just another feature in the marketplace.
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.
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 about making recognition personal, timely, expressive, and easy to give.
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.
A week to find the idea
Our team used a week-long Product Operating Model design sprint to explore the problem. It was my first time working with the Fringe team in this format, and I contributed by developing concepts, sketching, and prototyping.
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 over into the product.
Designing for different kinds of recognition
One of the most important decisions was whether to make recognition public or private.
I pushed for that during the sprint because I’d seen the difference firsthand while managing teams. Public praise can motivate one person and make another deeply uncomfortable.
The research supported that distinction. Some employees valued company-wide visibility, while others preferred recognition to remain personal.
So we didn’t include visibility in 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.
We also made company values 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.
The goal 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 we implemented it collaboratively. DG understood the prototype's intent and contributed ideas as he built the actual product.
Groups were one of those ideas.
Instead of forcing people to find the same coworkers repeatedly, users could create private groups of teammates and use them to organize people they recognized regularly.
That wasn’t part of my original sprint concept. It emerged while we were building.
That collaboration improved the product—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 recognition to company values, include GIFs, and choose whether to make the moment public or private.
The feed made those moments visible across the organization. Coworkers could react and comment, 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 had designed a new behavior, but hadn’t yet created a clear path for employees to discover and adopt it.
I remember being asked why I thought adoption wasn’t stronger immediately. I answered 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 insight 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, and Fringe already had a working product that could provide the foundation.
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 streamlined version of Recognition, with navigation tailored to 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 for HR practitioners to discover Fringe.
We designed a practitioner experience around the Recognition feed so someone encountering Fringe through ADP could understand what else the platform offered before committing to a broader relationship.
Over time, that evolved 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 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.
I wouldn’t attribute metrics 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 one another 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, tie appreciation to shared values, join 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 one another.
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.
