UX · Wellness · 2015
Dares, on Zoojoobe
A workplace-wellness feature that turned into 186,000 one-to-one challenges in six months, and quietly lifted internal adoption at Mindtree by about 11%.
UX Case Study: designing the Dare feature on Zoojoobe, 2015.
What is Zoojoobe?
Zoojoobe was a workplace-wellness app built inside Mindtree. The product helped colleagues nudge each other into healthier habits without making it weird. Dares was the social feature that taught us how to do it.
What is a Dare?
Dares are fun one-to-one challenges that have a life span of 7 days. During a Dare, two workplace friends challenge each other to compete and finish a health goal, and offer rewards at stake if the other wins. Walk ten thousand steps a day for a week. Quit caffeine. Loser buys lunch. That’s the whole shape.
Over six months that this feature was introduced, there were over 186,000 Dares exchanged. This helped us drive internal adoption at Mindtree by about 11%.
The process
My process closely follows and adheres with human-centred design’s Double Diamond process. For Dares we followed the same process, and in the following sections you’ll find our implementation.
Information architecture of the app
This is the overall app layout.
Discover, diverging
We brainstormed and collected all the possible motivations, fears, and needs for the users. This gave us a good platform to begin the process. Based on these assumptions, we hypothesised and observed our previous implementation of the Dares feature.
Define, converging
Understanding the working constraints, the user behaviours, and the dynamics of office relationships within the context of the office. We boiled that understanding down to five points that the design had to obey.
Develop, diverging. Stage 1: Crazy 8
We started with a Crazy 8. Based on our current definition and understanding of the problem, I put together a team of four people (developers, product manager, and other stakeholders) and we drew solutions on a single A4 sheet in two minutes.
This not only helps in understanding the problem but also gathers as many possible solutions as possible. It also helps in getting buy-in to the idea by the team, since all of us contribute to the idea. We had 17 ideas by the end of the second minute. We combined these ideas to create the wireframes.
Stage 2: Wireframing
Here is the final idea we came up with for the Dare creation process.
Deliver, converging
Based on the idea we created a prototype and sent it to a set of users within Mindtree for testing.
The users rated the prototype 8.0+ on a scale from 0 to 10.
We had the final solution. With the feedback from the user group that tested the prototype, we tweaked the process to arrive at the final solution.
All screens for Dare
What I learned from it
The Dares numbers (186k exchanges in six months, 11% adoption lift) were the headline. The thing I took away that mattered more was about friction in the right places. The original Dares implementation made starting a challenge easy and ending one painful. The redesign reversed that: starting required two friends to actively agree; ending was a single tap. The harder doorway, predictably, made the people who walked through it more committed to the game on the other side.
Most engagement features over-invest in onboarding and under-invest in the social contract. Dares survived because we did the opposite.