Planning and prototyping a mobile app

We helped a startup map their customers’ needs and prototype their mobile app

Referment is a startup that’s replacing recruiters with personal networks, where people are rewarded for referring their peers for jobs. They’d successfully bootstrapped a business model using mailing lists to send out job opportunities, and manually handling referrals. They were ready to scale up this idea, and they needed help to design a custom mobile app that supported their business and allowed them to scale.

Planning a design sprint

A Design Sprint, as defined by Google Ventures, is a short focused burst of understanding, thinking, discussion, and creativity. You start by fully understanding the problem you’re trying to solve, then brainstorming ideas, then having the hard discussions you need to decide which idea is best to prototype.

This work is intensive and exhausting, but the progress made in a short amount of time is invaluable.

Building use cases and context

We started by workshopping use cases, helping us to understand the context and the goals people would use this app for.

A collection of situations people could use the Referment app

Some comparisons were drawn to the use cases for social media, used for escapism and to kill time, but with a more productive outcome. If you’re going to kill time, why not make some money while you’re doing it?

Another use case that had been observed was “dead time” that users had throughout the day, this could be during advert breaks, waiting for a train, or at an airport.

Our “Joe” persona. What they do, think, and feel while waiting for a train at 6am

These insights help frame what we’re looking to build, and how it fits into the lives of the users.

Defining user needs

Understanding when a service is used is important, but not nearly as important as the why. With near-unlimited options how can you convince someone to use or even download your app? We started to unpick observations the Referment team had made so far.

A collection of high level user needs for the app

Interestingly, the audience they’d been serving so far didn’t value the reward money as highly as they did their time. In the financial services sector, the people with the largest networks are usually the most senior. They wanted to feel like they were making good use of their years of expertise and networking, and to feel that their time was well spent.

Another need was to feel connected again. A large audience of users for the app could be women on maternity leave who feel disconnected from their work life and have some time available where they could make referrals to help keep in touch with their professional network.

Some users also used the service to get rid of someone on their team they didn’t get on with, by “helping” them find a job elsewhere. How Machiavellian! This became an important need to address, as we had to bear in mind that some referrers wanted to remain anonymous.

Mapping the user journey

With the context and goals of users firmly in mind, we started mapping out the steps users would need to take to complete a successful registration.

We also included how we’d anticipate the users would feel at each step. We created simple personas to capture the context with human names, to make them easy to refer back to; “What would Greg think at this point?”.

An excerpt of the user journey for the app

As the Referment process involves some waiting to see if a recommendation has been successful, there are some potential dips in the experience where impatience and boredom kick in.

We also identified some areas of potential concern: “What if I recommend someone who isn’t qualified”, “What if my recommendation doesn’t appreciate me handing out their contact details?”, “What if I damage my reputation?”.

Searching for conflict

The main goal of this workshop was to get a clear idea of what the app should do and how. For the journey mapping exercise I asked every attendee to construct their own user journey separately, and then bring them together to identify any differences.

Doing this surfaces conflict very early on in the process, which allows us to have the difficult conversations before we’ve invested too much time or money building — or even thinking about — the app.

We found some conflict on where the user registration form should appear. Should registration be required to view vacancies? On one hand, you’d want to reduce the amount of time and investment users need to see if there’s anything useful for them. On the other, keeping the vacancies hidden adds an exclusive feeling to the service, and could make it more appealing.

We also found conflict in the amount of on-boarding needed into the app. We needed to keep it brief, but also explain how the process works, to set the right expectations.

Sketching screens

Once we were happy with the user journey, we could starting sketching out what we thought each of those steps would look like. Like before, we sketched out our ideas separately first, then brought them together to find conflicts.

The team, sketching out screens

We went over our sketches and used silent voting to highlight areas we thought were interesting and worth discussing. This gave everyone in the room a chance to give input, and a simple way to prioritise discussion.

A quick sketch, with discussion points highlighted using silent voting

We found conflict on the vacancy information we think is important to show that would help people assess a solid recommendation for a vacancy. Apart from the financial reward they would receive, what else would be relevant?


By the end of this exhausting workshop process, there was still polishing to be done to make sure every aspect had been considered. This is a slower process, so I produced digital wireframes that I then stitched together using Invision.

This gave the team the ability to click through each action and get a solid understanding of how the user journey flows. It also gave them a chance to make slower, considered decisions, and we went through a few quick iterations before we were happy.

The final product

Referment now had a visual, more literal definition of the app to be built. They could now hand the prototype over to a development team with a clear expectation of what they were trying to achieve.

Before and after, the wireframes and the final app, designed by Bluestep Solutions.

Project impact

“Lewis was great to work with and really helped us map out the user journey. We wanted to build an app that would be easy to use and meet our user’s needs. Working with Lewis enabled us to do that and launch an app we’re really happy with!”
Alex Odwell, Referment founder

Over the course of the design process, we surfaced some difficult but valuable questions, and challenged some assumptions. We investigated who we were building for, and what they wanted out of Referment to steer the design in the right direction.

At the end of the week, Referment had a prototype for their app they could test with potential users and hand over to a development team.

Download the Referment app here

Convivio helps organisations to work better for people

We do this by helping them transform their services using digital tools, and spreading new ways of working.

Visit our website at
Read our blog:
Follow us on twitter:
Get in touch:
[email protected]

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.