Zippr: Increasing user engagement through sprints

Zippr is a location management startup, based in Hyderabad. Zippr has transformed how locations are referenced, shared and found by replacing the traditionally long addresses with an 8-character digital address format. This  would be easy to store and synced across devices. The code could be used to store more information than just the location, for instance, phone numbers and persons present at the location. Concisely put, Zippr could be described as a wallet for your locations.

Between a rock and a hard place

Aditya, its CEO, came to Parallel Labs with a very interesting problem.

The short version of the problem is two words long — user engagement. This was the ditch that Zippr was stuck and needed to get out of.

The long version —

  1. Bringing new consumers to the platform
  2. Bringing continual usage
  3. To reduce dependency on partners
  4. Adding consumers and distributors

Getting the most out of a sprint

We were given the freedom to experiment with the problem of sharing locations, thinking beyond the current Zippr app. Aditya didn’t want to spend time and money developing something to find out it didn’t solve the problem in the first place. This is where the sprint format comes in.

The sprint team consisted of four people from Parallel Labs and four from Zippr. It was a very dynamic mix of people from different backgrounds such as UX, tech, operations, design and marketing.

Getting a grip on the challenges on Day 1

The original goal had been to make the Zippr app the first choice for sharing locations for any mobile user. What the current app lacked was engagement. Users would come on the app, create Zippr codes and forget about it altogether.

To begin with we defined the user’s behavior within the app. In Sprint lingo, this is known as ‘the map’.

The practice of ‘How Might We’ questions gets to the root of the challenges and more importantly, how these challenges might be turned into opportunities. Through voting, the most pertinent HMW questions are identified.

  • HMW increase Zippr usage
  • HMW make consumers and distributors interact around a location
  • HMW bring real-time context to a real-time usage of Zippr
  • HMW enrich ux of sharing a Zippr vs sharing a location
  • HMW convert consumers to distributor or creator
  • HMW make user share location without having to create a zippr code

Ideas galore on Day 2!

Today is the day (Day 2) that we chase after the golden grail of solutions. Surprisingly enough, the best ideas came from the non-designers, since they had a different and out of the box perspective on the product.

We narrowed down our scenarios to an audience that was comprised primarily of millennial users.

  • House parties
  • Movies
  • Adventure trips

Committing to a solution on Day 3

We stitch together all of the great ideas in the form a storyboard, a neat story describing the way in which the app would be used in everyday life. This brings a three-dimensionality. At the same time, it quickly reveals what features were actually necessary and which ones were in fact just adding to clutter.

Although the end result might look shabby, it is infact a goldmine of insights. The below storyboard was in the context of a house party. It also helped that characters were assigned to each team member, each of whom portrays a different scenario.

  • What if two guests arrive together?
  • What if someone had to pick things up on the way?
  • What if someone had to make a last minute change to their plan?

Prototyping on Day 4

By Day 4 with the solution agreed upon through discussion and voting, the prototype is fairly easy to make because the bulk of the work has already been done.

The moment we’ve all been waiting for…Day 5

On the day of testing we named the new app Beamer so that nobody could confuse it with current Zippr app. This is also break any preconceptions the user might come with.

While the participants were using the prototype, we were observing from the other room.

On the whole, the feedback was positive. There were feature requests and sometimes, the user just did not know how the app should be navigated. All of these points are noted down to be revisited. To reiterate — the user is never wrong.

Where to go from here

Conducting this design sprint really helped Zippr team solve a long standing problem. Although everyone began with some skepticism, we had won ourselves some converts by the end.

It is not easy to come up with ideas which can completely change user behaviour. But a difficult problem and a great team is what makes designing products a delight. As the author of the book (link) clearly mentions, “the successful test is not the end of the process” but the beginning of something really awesome.