← All work

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%.

Role
UX designer
Client
Zoojoobe (built inside Mindtree)
Team
4 people: developers, product manager, stakeholders
Duration
About 6 months of feature life observed
Platforms
iOS · Android
Zoojoobe, Dares feature

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.

Double Diamond design process
The frame. Two cycles of expanding and narrowing: first around the problem, then around the solution.

Information architecture of the app

This is the overall app layout.

Zoojoobe information architecture
The information architecture of Zoojoobe. Dares is one node, but the most-touched one for the duration of this work.

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.

Discover phase brainstorming
Discover phase. Motivations, fears, needs, all on the wall before anything else.
Observations and research notes
Observations from the previous Dares implementation. What was actually solving for what.

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.

Final problem statements
The final problem statements. Five constraints. Anything outside them was deferred.

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.

Crazy 8 sketches
The Crazy 8 output. Seventeen rough ideas in two minutes; the strongest threads got combined into wireframes.

Stage 2: Wireframing

Here is the final idea we came up with for the Dare creation process.

Dare creation flow
Dare creation. The flow we landed on.

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

Start a Dare
Start a Dare
Start a Dare, variant
Start a Dare, variant
Different states of tiles
Different states of the tile

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.