University Course: Business Development Lab

University Course:
Business Development Lab

University Course:
Business Development Lab

University Course: Business Development Lab

University Course:
Business Development Lab

A new way to manage your contacts

A new way to
manage your contacts

Concept Design & Business Development

Concept Design & Development

Meet Roly -
Your virtual Rolodex

Have you ever been annoyed or tired of browsing through a contact-lists in search of a person only to find that the information you were looking for was stored in a different app? Or did you ever find a duplicate entry in your contact list with different phone numbers listed for the same person? Roly is a contact-list managing service that allows you to find all the information you need to be stored under just one contact entry and ensures it will always be up to date.

Beginning

Before starting on this project, me and two of my friends shared the common frustration that our contact lists were spread over all kinds of apps, all containing different contact-details, and they often contained out-dated information. Furthermore, many apps share similar functionalities nowadays, such as making phone calls to each other. We decided that we wanted to design a solution to this problem and untangle the mess of all these different contact lists.

On average, students use more than 10 different apps that have their own contact lists.

We decided to focus on students as our target group for this service. Mainly because students rapidly expand their social circle and tend to use many different and distinctive social-apps (e.g., Snapchat & LinkedIn). Based on interviews we conducted, we found out that they typically made use of more than ten different social-apps with their own contact-lists, on average. Furthermore, we validated that they often experienced similar issues with their contact lists as we did.

The solution we envisioned would be capable of two different things. First of all, users would be able to import the contacts from the apps that they wished to have organized; the application would then sort them out automatically and merge the contact details under one contact entry. Second, the user would then be able to browse their new contact list, select the contact they were looking for, and open the contact related functionalities (such as calling or emailing) in the app that they would regularly use for it.

A simplified overview of the user journey map for the application we envisioned.

A simplified overview of the user journey map for the application we were envisioning

The goal of Roly was to give our users a better overview of their contact lists; a more convenient way of storing their contacts. We did not want to build yet another social-app as this would only contribute to the issue that we were aiming to fix. Therefore, the Roly-app would provide users a shortcut to reaching their contacts in the app of their choice.

The design of Roly

Roly was designed iteratively. We started with the most basic version we could think of to test how our potential users would experience the app. By starting with the basics, and only incrementally adding features, we aimed to keep the concept as lean as possible.

Our goal was to create a convenient service that would be in demand with our target group. To validate our design-choices, we conducted various user-tests on each round of iteration to validate our decisions and guide us in the right directions. The end-goal of the user tests was to find out if our target-group saw value in our idea.

For the remainder of this page, I will give some more insight into the lessons that we learned while designing Roly.

Our goal was to create a convenient service that would be in demand with our target group. To validate our design-choices, we conducted various user-tests on each round of iteration to validate our decisions and guide us in the right directions. The end-goal of the user tests was to find out if our target-group saw value in our idea.

For the remainder of this page, I will give some more insight into the lessons that we learned while designing Roly.

The initial User Interface

Initially, we iterated our wireframe design by conducting informal usability tests with an interactive low-fidelity prototype. Before the tests, the idea behind the application was explained. The task that was given the users was to set-up an account and import and merge two dummy contact lists. Once the user-test was finished, we had a small interview with the participant just to review how they liked the concept. After some minor adaptations, a high-fidelity version was designed.

Low Fidelity mock-ups of Roly that were used at the start of the project to validate the initial design of the application.

Low Fidelity mock-ups of Roly that we used at the start of the project to validate our initial design of the application.

High Fidelity mock-ups of Roly that were made after the inital design of the app was validated through user-testing.

"So what did it do?"

One thing we quickly discovered was that our initial prototype did not demonstrate the purpose of Roly fast enough. Our goal was that users would see the benefit of the app at the moment they would import their contacts; not when they would see the result. Most participants did not have an 'aha moment,' as to them, it appeared to be just a contact-list application. Once we would explain the merging of the contact-lists, after the user-tests, they mentioned they would love it, and it would be a great addition to the product! For some reason, the app failed to showcase that this was precisely what they just did.

There were two possible reasons for this. The first possibility is that our test-participants just clicked through the screen that presented how many contacts were imported, without taking the time to register what was mentioned. Second is that the apps we had chosen to be imported, Gmail & Phone Contacts, unbeknownst to us, already had their own respective contact-merge functionality in some versions of Android for this specific app-combination.

One thing we quickly discovered was that our initial prototype did not clearly demonstrate the purpose of Roly. The interactive prototype did not clearly show all the functionalities of the product. The participants did not have an 'aha moment' that made them aware of the value we tried to create our product.

To resolve this, we made sure to ask our users to import apps for which this feature is not already supported by the native apps (which happened to be any except for this combination). Additionally, we redesigned the screen that displays after importing contacts to summarize the events that just happened more clearly, and to make the users scroll a little bit down before they could continue to the next screen. The reason for this is that now users wouldn't be able to skip to the next screen instantly and would have more time to register what would be on the screen presented to them.

To make users more aware of the functionalities, we redesigned the message that is displayed after importing contacts to summarize the events that just happened more clearly. Furthermore, we added a pop-up that would display that the contact details of one of the contacts were recently updated.

"So how does it work?"

Now that the participants had a better understanding of the purpose of the app, we noticed that the appreciation for the idea increased tremendously. However, at the same time, they became more curious about the workings of Roly. For example, what would happen to their personal-data after giving the app access to their contact lists? Or, if any additional action on their part required after importing contacts?

We considered various ideas, but in the end, we found that a simple tutorial screen before importing contacts would already elevate most of the questions and doubts our participants had.

Now that the participants had a better understanding of the purpose of the app, we noticed that the appreciation for the idea increased tremendously. However, at the same time, they became more curious about the workings of Roly. For example, what would happen to their personal-data after giving the app access to their contact lists?

"But what if..."

Although we presented the service to be perfectly capable of merging contacts without errors (even though a full 100% accuracy would, in reality, this would unlikely to be achievable), participants were doubtful: and rightly so! In the end, the service would still need some assistance of its user in some individual cases.

Contrary to our initial hypothesis, adding a feature to guide and correct the suggestions made by the app increased the trust and value participants saw in our concept significantly. Furthermore, we added a pop-up that would show that the personal details of one of the contacts were recently updated.

Although we presented the service to be perfectly capable of merging contacts without errors (even though a full 100% accuracy would, in reality, this would unlikely to be achievable ), participants were doubtful: and rightly so! In the end, the service would still need some assistance of its user in some individual cases.

Contrary to our initial hypothesis, adding a feature to guide and correct the suggestions made by the app increased the trust and value participants saw in our concept significantly.

The end result

What lessons did we learn?

A major lesson that we learned in this project is how vital it is to communicate to your users what your product is doing for them.

At the start of this project, our goal was to create a product-service that would be as lean as possible. In the process of doing so, we went a little bit too far in this aspect. As for our first prototype, the product solved a problem for our users in the same way as it did in the final concept. However, they were not aware of how it was resolved. As a result, our potential users were not as enthusiastic as we had hoped.

However, during this iterative design process, we noticed that all we had to do to make potential users adore the idea behind this product, is to communicate what it was doing more clearly.

A major lesson that we learned in this project is how vital it is to communicate to your users what your product is doing for them.

At the start of this project, our goal was to create a product-service that would be as lean as possible. In the process of doing so, we went a little bit too far in this aspect. As for our first prototype, the product solved a problem for our users in the same way as it did in the final concept. However, they were not aware of how it was resolved. As a result, our potential users were not as enthusiastic as we had hoped.

However, during this iterative design process, we noticed that all we had to do to make potential users adore the idea behind this product, is to communicate what it was doing more clearly.

A major lesson that we learned in this project is how vital it is to communicate to your users what your product is doing for them.

At the start of this project, our goal was to create a product-service that would be as lean as possible. In the process of doing so, we went a little bit too far in this aspect. As for our first prototype, the product solved a problem for our users in the same way as it did in the final concept. However, they were not aware of how it was resolved. As a result, our potential users were not as enthusiastic as we had hoped.

However, during this iterative design process, we noticed that all we had to do to make potential users adore the idea behind this product, is to communicate what it was doing more clearly.

A major lesson that we learned in this project is how vital it is to communicate to your users what your product is doing for them.

At the start of this project, our goal was to create a product-service that would be as lean as possible. In the process of doing so, we went a little bit too far in this aspect. As for our first prototype, the product solved a problem for our users in the same way as it did in the final concept. However, they were not aware of how it was resolved. As a result, our potential users were not as enthusiastic as we had hoped.

However, during this iterative design process, we noticed that all we had to do to make potential users adore the idea behind this product, is to communicate what it was doing more clearly.