Cheers! Designing a peer-to-peer recognition feature.

Alex Mathers
Jul 23 · 10 min read

At Nudge Rewards, we’re gearing up to release a new feature called ‘Cheers’. The feature provides a new vector for peer-to-peer recognition in our app, by allowing users to give and receive digital Pins, each with their own associated meaning. It’s a great new feature that I’m hoping will have wide ranging benefits to both our users and their employers, and I thought it would be a great opportunity to showcase a bit of our design process here at Nudge.

Feature Development

Before we get to the actual design phase, we need something to work on! The product team is largely responsible for deciding what gets built and when, so I’ll start with a quick overview of how that happens.

  1. Ideas: The very beginning of any feature that we build at Nudge is of course an idea. Those ideas come from all sorts of places: our product team, our customers, our users, feedback from the sales and marketing teams, competitor research and more.
  2. Steering: The product team collects all these ideas as they come in. They catalog and categorize them, and engage with senior members of all departments in a process we call ‘steering’. I won’t get into the details, but the result of this steering is a roadmap for feature development.
  3. Requirements: Once we’ve decided to build a feature our product team begins to rough out a feature sheet. Along with outlining the goal of the feature, how it fits into a larger business strategy, the problems we’re solving, and the value we’re adding — the feature sheet also generates a list of requirements. This list of requirements details a series of user stories that describe how the feature, at a minimum, should work.

This is roughly the kick-off point for design. Having a detailed list of requirements for the feature gives enough context to begin research and start roughing out the shape of the feature. Here are a few of the design-centric requirements for the new Cheers feature.

Cheers Library
As a Nudge user, I can select a Cheers from a list of pre-defined Cheers so I can recognize or thank one of my colleagues.

Customize Cheers Message
As a Nudge user, I can customize my Cheers by writing a personalized message / note to the recipient

Display Cheers on Public Profile
As a Nudge user who has received a Cheers, I can display my Cheers on my profile page

Search Users
As a Nudge user, I can access a& search a list of users for the specific users I want to give a Cheers to

One last piece that often accompanies a feature sheet, is a rough mockup of how the feature might look. This is less about describing button placement and specific UI decisions, and more about giving some visual aid to the user requirements.

A rough mockup by our Product Manager of what the Cheers feature might look like, given the feature requirements.

Time to design, but where to start?

The first step when designing a new feature is almost always to reach for a pen and some paper (or in this case, an iPad). The goal here is to go through an ideation phase. What that means exactly depends on the feature, but in this case I had a few questions coming out of the feature sheet, and I find the easiest way to begin answering them is just to write down whatever I’m thinking. In the notes below you can see I’m brainstorming about what the Cheers might look like, the different types of Cheers, and since we didn’t have a name at this point, what to call the whole thing.

A few notes exploring different ideas for the look and naming of the feature.

At the same time, I wanted to think about how this feature would fit into the larger context of the app. Pen and paper can work for this, but it’s easy to get caught up in unnecessary details, so I find creating a basic flow diagram with can help speed things along.

A flow diagram describing where the feature will exist in the current app, and the basic organization of the screens.

A good start, but what does everybody else think?

At this point, the Product team has already done a good amount of research to determine what this feature should be, and how it could impact the product. But after the ideation phase we’re usually left with some more specific questions, and are looking to validate (or contradict) our ideas and any presumptions we’ve made so far. This is where good user research becomes invaluable.

We started by running an internal survey to get answers around a few key topics, specifically: how might people want to recognize, or be recognized by their colleagues? And what sort of accomplishments or contributions do they care most about recognizing?

In order to make sure we answered those questions thoroughly, we went about asking them in a few different ways, and made sure to leave lots of room for write in content in case there were any key points we were missing. Here are some of the results:

Would you rather recognize a colleague Privately or Publicly?”
96% answered ‘Publicly’, 4% answered ‘Privately’

Would you rather be recognized by a colleague Privately or Publicly?”
84% answered ‘Publicly’, 16% answered ‘Privately

These results tell us that overwhelmingly, the respondents want to be recognized in front of their colleagues, and supports our decision to display Cheers prominently on user profiles.

“Do you remember a time you were recognized by someone, or that you gave someone recognition?”
100% answered ‘Yes’

“How would you rate that experience?” (0 to 5 stars)
64% answered 5, 32% answered 4, 4% answered 3, 0% answered 2 or 1 (Avg. 4.6★)

This helped affirm that recognition is important, and that it’s generally a positive experience, with very few if any respondents having a negative experience.

“What were (you / they) being recognized for?” (write-in)

This question resulted in a number of answers, however by far the most prominent were variations on “Going above and beyond”. Now, it could be that because this was a write-in answer, respondents that were eager to finish the survey were looking for a shorthand to use. However, this question was placed before anything that mentioned different types of recognition, so it’s worth noting that these respondents all independently came up with the same shorthand.

A few examples of write-in answers for the question: “What were (you / they) being recognized for?”

“If you could change one thing about that experience what would it be?” (write-in & optional)

We received very few results for this question, likely because it was optional, however taken in conjunction with the previous rating of the experience it’s likely that most users had nothing significant to change. That’s echoed in a few responses we did get of “Nothing”.

Those who did want to change something mentioned a desire for more specificity, more publicity, and more frequency. We also got a few respondents that wished their manager knew of their accomplishments.

What this tells us is that our respondents have a bit of an ego — but making Cheers easy to give, and highly visible is key to success.

Finally we aksed “Which of the following Categories might you want to recognize a colleague for?” (select up to 5 of 13 with option to write-in)

For this question we gave our working list of possible Cheers types, with the goal of narrowing it down by which ones would be most frequently used. We made sure to allow multiple selections as well as an option to write-in anything we hadn’t though of.

The winners, ranked by percentage of |respondents were: (unsurprisingly) Going above and Beyond (96%), Great Performance (84%), Teamwork (68%), Leadership (56%), Uplifting Contributions (48%), and Teaching a Skill (44%).

After those 6 was a sharp drop off with only 28% selecting the next highest option: Generosity. Other less frequently selected options were: Working Long or Late Hours, Being Responsive or Speedy, Ingenuity, Organisation, Calming Contributions, and Efficiency.

We had zero respondents write-in another type of recognition, so we were fairly confident these responses covered all the bases.

Next up, pushing some pixels (and more research)

Now that we had our feature sheet, our initial ideation full of sketches and user flows, and our research to back it all up. It was time to start iterating on what would become final designs for the feature.

An early(ish) round of iteration on the mobile screens.

At Nudge we have a pretty robust design system in place for our mobile app, which keeps iteration quick and removes some of the decision making when it comes to things like navigation bars and button styles. On top of that, a lot of the iteration and design thinking was covered through the UX flows and previous work on the newly launched public profile, so putting together a relatively polished set of screens was quick work.

It was really important for us to get these early designs in front of our customers, so that we can address any issues before we head into development. In this case we scheduled a number of ~30 minute calls with a few customer leads (our point of contact that is usually most involved with creating and scheduling content). These sessions are great for getting feedback from people who are familiar with the app, and in this case they provided great insight into what our customers were already doing around peer recognition, and how those practices might align or conflict with the new Cheers feature.

We came out of those sessions with a better understanding of how we wanted to handle custom messages (giving control to the recipient on whether or not to show them), how to surface a comprehensive user list, and a number of future considerations around adding custom Pins.

Pins, pins, and more pins.

The last big question mark for the designs was what the Pins might look like. At this point in the process we were working with the marketing team to finalize the feature name (As you may have guessed by now, we landed on Cheers to refer to the act of giving your colleagues recognition, and the feature as a whole. While using Pins to refer to the individual items displayed on your profile). The look and feel of what would become Pins was still wide open.

A small collection of the many iterations and half-attempts at different styles for Pins.

This is where iteration is so important. Exploring a wide range of styles and metaphors is key to landing on something that will last. Early on in this process I was taking a more illustrative approach, but I eventually realized a few problems with that. First, it would be difficult to maintain legibility at smaller scales. Second, we hadn’t already established an illustrative style for other things like marketing materials where there are likely to be illustrations in the future, and this didn’t seem like the place to commit to one. And finally, we wanted Cheers to be something users were proud to receive, and display on their profile. While illustrations are nice to look at, they didn’t have the tactile, collection driven response we were looking for.

Eventually, I settled on a style that’s a little reminiscent of enamel pins. The key benefits of this style are:

  1. They can scale, and are legible at various sizes.
  2. They can be more abstract, to help showcase difficult concepts like teamwork, or leadership.
  3. They have a strong silhouette, so they can be easily differentiated from one another.
  4. Their style is easier to replicate and keep consistent. This is important incase we decide to add more options in the future, or scale the feature in a different way (something we were already actively discussing).
  5. And finally, they feel like collectibles that users will want to display on their profile.
The final Pins (from left to right): Super Star, Teamwork, Above and Beyond, Leadership, Spirit, and Mentor

Putting it all together

With the mobile screens in place, a solid user flow, and a fun style for our Pins — the Cheers feature was ready for a few rounds of final polish and validation from our tech team. This is the phase where we make sure all the corner cases are accounted for and covered in the designs; things like empty states, disabled buttons, truncating lines, and unexpected inputs all need to be discussed so that the developers know what they’re building and the product team isn’t surprised by the result.

A few of the final Cheers screens presented to developers for validation.

And there you have it! This post encapsulates most of our design process; from the Product team handing over a feature sheet, to finished designs ready for our developers. I do want to point out that this process is not nearly as linear as it appears in this post. There are countless back-and-forths between the Product team, myself (design), and the dev team. Often in the form of quick questions and sometimes long conversations. This post also doesn’t give enough credit to the huge amount of input we get from our Customer Success team, and the further rounds of validation and testing we do with the finalized designs and mobile app. Nonetheless I hope this was a useful look into our design process here at Nudge Rewards.

Thanks for reading, and if you have any questions or are interested in learning more about design at Nudge, feel free to reach out to me at or on twitter @malecks.

Alex Mathers

Written by

Illustrator, designer, and iOS Developer

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade